[Dev] [Voting] Package freedom guidelines draft two

[Luke T. Shumaker]

At Tue, 08 Jan 2013 09:57:37 +0100,
Michal Maslwski wrote:
> > It is ridiculous to have an exception for GNU packages.  Given that
> > GNU is normally freely-license, we need to match whatever exceptions
> > they have.  Therefore, we need exceptions for:
> >
> >  * license works
> >  * works of opinion
> 
> We have an exception for licenses.  These ND-like works remain:
> 
> 0. separate works of opinion, e.g. RMS interviews, essays, sex jokes in
>    the Emacs distribution
> 1. FDL cover texts
> 2. FDL invariant sections
> 3. copyright, license or attribution notices
> 
> 0 and 3 are obvious to handle, I think 1 could be considered acceptable
> attribution; 2 could have a separate exception based on how the FDL
> defines these sections.

I'd also say that the FDL exceptions are only OK in some situations
(the situations RMS thinks are OK).  I believe that this is "invariate
sections are OK only for secondary sections"; whatever that means.

But we can simplify this: we only require editability for "technical
writing".  ND Opinion? Fine. ND License? Fine. ND section of manual
explaining the GFDL? Fine. ND section of manual about the software?
Not fine.

> > And probably others.  If ever we decide that we need to blacklist a
> > GNU package, that means that the policy that decided that is broken;
> > not that we need to give GNU an exception.
> 
> There were real licensing problems in GNU packages, e.g. Emacs sources
> not including sources of generated parsers, the Sun RPC issue of glibc,
> or Enscript not including the license of Adobe font metrics, these are
> fixed quickly.

These are/were bugs with the GNU packages, not places where our
policies conflicted.

> > That applies to any time we want to make an exception for a package.
> > Instead of making an exception, we need to fix the policy.
> 
> It might result in much more complex policies allowing some worse
> decisions.  I don't know if it will be so in this case.

Our policies don't need to be "code"; we can be fairly broad.  If we
get to adding too many little clauses; we should look for what they
all have in common.

> > Parabola has always *supported* and *preferred* free culture, but
> > has always allowed in nonfree cultural works.  And quite frankly,
> > enforcing this is unfeasible.
> >
> > That said, I do believe that we should formalize our support of free
> > culture.
> 
> How would we formalize it?  The DFSG discourages forbidding distribution
> of modified sources (i.e. only unmodified sources + patches), maybe this
> should be stated similarly?

I'm not sure; it's something we definately need to discuss.  But my
contribution is that blacklisting non-free-culture goes too far.
Perhaps just writing down that we prefer it, and to use free-cultrue
when there is an option.

> >> H. GNU FDL manuals with cover texts are not accepted.
> >> 
> >> I. GNU FDL manuals with cover texts but no invariant sections are
> >> accepted.
> >
> > This would require us to modify GNU packages, which is neither
> > feasable, nor something that I think policy should ask of us.
> 
> Debian does this, maybe we could use their sources, it still won't be
> easy.

Debian also has compile farms, and FAR more manpower than we do.

> >> == Packages are built from source ==
> >> 
> >> All architecture-specific files in binary packages must be built from
> >> source.  Architecture-independent files in a form that cannot be
> >> easily edited must have a source included if they are software,
> >> otherwise they should.  These files should be built from source by
> >> automated scripts called by the PKGBUILD, to make modifying the
> >> packages easier for users.
> >
> > Replace "easily edited" with "preferred format for editing" or
> > whichever phrase the GNU GPL uses.
> >
> > I'm going to refer to files that don't meet this as "binaries", even
> > if they are not actually binary, just to avoid wordyness.  A file that
> > actually is in a binary format (such as a .XCF) does not count as a
> > binary in this context.
> >
> > And, I STRONGLY object to a policy which allows for distributing
> > binaries which are not generated in a PKGBUILD.  I will allow a policy
> > which places them as low-priority bugs that do not require
> > blacklisting while they are fixed; but they must be bugs, on a to-do
> > list to fix.
> 
> This is too confusing, "binaries" can refer to:
> 
> - arch-specific noneditable binaries: your "binaries"?
> - arch-specific editable binaries
> - arch-independent noneditable binaries: your "binaries"?
> - arch-independent editable binaries: "sources"

I defined what I meant binary to mean for the sake of wordyness. But,
to make you happy:
  s/binary/file not in the preferred format for editing/g

The line from the GPL that I mentioned is:

  The source code for a work means the preferred form of the work for
  making modifications to it.

So:
  I believe that a file may only be included in in a binary package if
  it meets one of the following conditions:
   1. It is "source code" as defined by the GNU GPL, version 2.
   2. It is generated as the result of running a PKGBUILD.

> I don't want to write scripts to build all arch-independent editable
> files in TeXLive built from more easily editable files.  (The only
> similar cases in other packages that I know are files not used in binary
> packages or compiled into other binaries, e.g. tables of generated
> constants, parsers or configure scripts.)

The situation with Java packages is actually very similar.

A reliable/working build script is an important part of the "source",
and we can't forget that just because it's convenient.  Arch doesn't
build java packages from source because they don't have policies about
strict source-availability; we do.

And in more than a few cases, I've discovered that a free-software
Java program relies on a non-free package to be built.  Or even simply
a hard-to-package program that we don't have.  If we can't build a
package on our system, we have no business packaging it.

> > I'm not OK with locking us in to SRCBUILDs yet.  I think we still need
> > to find a better (technical) solution.  Ideally, something like
> > prepare(), but without the issues that were brought up in the previous
> > thread.  In fact, I just hatched a solution in my head, but I've sent
> > enough emails on this list about software that I only intend to write.
> 
> We need a solution that we will use, preferably a single one.
> Developers should be able to find what to use from the guidelines.

I agree, but I also don't think that
 1. This needs to be discussed in *this* policy.
 2. That we have found a good solution yet.

I don't think that we should policyize this until 2 is met.

> > Now, what I would be OK with is:
> >
> >   Use a reproducable method to make free source archives.  Do not remove
> >   nonfree files in <code>build()</code>, removing recommendation of
> >   nonfree software is acceptable.
> >
> > I say "reproducable method" to avoid the "log in to a Debian box and
> > do this" that ConnOS has used (for Iceweasel).  Nothing against them,
> > but that makes my skin crawl.  I spent several days figuring out how
> > to accomplish the same thing on Parabola (hence the awkard dpkg-source
> > function formerly included in the PKGBUILD).
> 
> A "reproducable method" that can be used on a machine having no software
> not provided by Parabola?

Right.  Our current methods are SRCBUILDs (run by `makesrc` in libretools) and
the mksource function.

> >> D. Non-head revisions of their VCS repositories are unsupported and
> >> might contain nonfree software.
> >
> > Again, I agree, but would reword it.
> >
> >   Non-head revisions of VCS repositories are likely include bugs that
> >   have since been fixed; including freedom and policy bugs.
> >
> >> E. Non-head revisions of their VCS repositories are unsupported and
> >> might recommend works not compliant with these guidelines while not
> >> including nontrivial nonfree works.
> >
> > I merged this into the above by adding "and policy".
> 
> If one revision has nonfree software (e.g. a patch containing unrar
> source to be removed), option D makes cloning abslibre.git distributing
> nonfree software, we might want to avoid this.

Fair enough.

> >> == Sources for all packages are provided by the repo server ==
> >> 
> >> Having only the PKGBUILD repositories, all binary packages, a source
> >> archive downloaded from the server and no network access it should be
> >> possible to build practically the same binary package as provided by
> >> us.
> >
> > I'd change this to say that network cannot be required during any
> > function defined in the PKGBUILD.  The other parts of it do not affect
> > packagers, but are handled by server scripts.
> 
> A packager can start a build, manually fix after it fails and continue.
> Or use a rePKGBUILD on an Arch-built package.

Alright, I see where you're coming from.  I just thought that your
wording was unnecessarily confusing.

> >> F. == Naming of replacement packages ==
> >> 
> >> 1. If the exact package name is needed, keep it.
> >
> > The exact package name is NEVER NEEDED.  When the exact package name
> > is significant, this can be satisfied with
> >
> >     provides+=("old-name=${pkgver}")
> 
> It wasn't needed when AIF was used?

It shouldn't have been.

> >> 3. If there is no "-libre" in the resulting name and the package of
> >>    the current upstream is changed for these guidelines, append
> >>    "-libre".
> >
> > No to this.  However based on your examples (gnustep-make), I think
> > that you meant the correct thing.
> >
> > The current undocumented policy is good (but should be documented).
> > That policy is:
> >
> >   If the source is modified significantly enough that the software in
> >   the resulting package can be considered a fork of the original
> >   software, append "-libre".
> >
> >   If the source is modified in insubstantial ways, keep the package
> >   name as it is, and increment pkgrel by a value smaller than an
> >   integer.
> 
> I didn't know this policy, seems ok.  Although naming it "a-libre"
> implies "a is not libre".

I guess "only add -libre if the changes are freedom-related".  In the
case of Iceweasel, most of the changes are freedom-changes.  If the
changes are technical in nature, another identifier should be used to
identify your fork.

> >> 2. If the resulting package cannot be used instead of the original
> >>    package, change its name so users will know this and other packages
> >>    won't use it.
> >
> > I think that this is important; a few packages have broken in the past
> > because this wasn't done.
> 
> It might need listing in F.  This implies not making the new package
> provide the old one.

A package should only provide another package if it has a drop-in,
compatable replacement for the package it provides.  For example,
icecat does not provide firefox; though they are similar, and to the
user they are nearly the same, it is not a drop-in replacement from a
packaging standpoint.

> >> Many existing replacement packages have different names, they should
> >> not be changed just for this rule.
> >
> > I'd change this to "they do not need to be immediatly changed"; the
> > next time the package is updated, I think it does need to be changed.
> 
> Ok, then it should provide the old -libre package.

provides=($pkgname-libre) and replaces=($pkgname-libre) it.

Happy hacking,
~ Luke Shumaker

Unrelated: the characters in your name break text-mode emacs in
gnome-terminal. *sigh*. Why can't these things just work?