[Dev] [Voting] Package freedom guidelines draft two

[Luke T. Shumaker]

At Mon, 07 Jan 2013 21:06:09 +0100,
Michał Masłowski wrote:
> Hello.  I have written a new draft of the package freedom guidelines
> based on the discussion at [0].  I have also added a new section based
> on [1] (the mail contains a justification of option G).
> 
> [0] https://lists.parabolagnulinux.org/pipermail/dev/2012-December/thread.html#1037
> [1] https://lists.parabolagnulinux.org/pipermail/dev/2013-January/001056.html

> Specific variants to choose
> ===========================
> 
> - A, B or C text of the license rules.
> 
> - D or E.  E needs history rewriting, write if you want to do it if
>   you choose this option.
> 
> - F or G.
> 
> - H or I, not needed if A.
> 
> Some other sections might be controversial (e.g. source inclusion and
> build from source requirements), I assume they are supported unless
> there are specific comments against them.
> 
> (There probably are also many opportunities for wording improvements.)
> 
> My motivation and explanation of the TeXLive and GNU exceptions
> ===============================================================
> 
> I want these rules to be possible to comply with, without ignoring
> many potential problems.  I believe it is better to explicitly state
> the compromises that we make.

I sort-of agree, more on that later.

> My other motivation is to help make a blacklist rewrite similar to the
> one that we discussed before, to make it easier to find why we blacklist
> some packages and to share this information with other distros.

As someone poking around with libretools, abs/abslibre/pbs, and
dbscripts, please make sure I am involved in any related discussions! :-)

> Package freedom guidelines wiki page draft
> ==========================================
> 
> These guidelines document our interpretation of what software should not
> be included in the distribution according to the
> [[Parabola/GNU_Linux_Social_Contract]] and how the included software
> should be provided.
> 
> A. == License rules for source and binary packages ==
> 
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works] unless they
> are correctly GNU FDL-licensed documentation ("correctly" implies that
> e.g. a manual that consists only of invariant sections isn't accepted)
> or GNU packages (with e.g. nonmodifiable works of opinion).

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

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.

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.

> B. == License rules for source and binary packages ==
> 
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works].

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.

> Source packages might contain correctly GNU FDL-licensed documentation
> ("correctly" implies that e.g. a manual that consists only of
> invariant sections isn't accepted) or, if they are GNU packages,
> nonmodifiable works of opinion which are not included in the binary
> packages.

See above about GNU exceptions.

> H. GNU FDL manuals with cover texts are not accepted in binary
> packages.
> 
> I. GNU FDL manuals with cover texts but no invariant sections are
> accepted in binary packages.

It is also ridiculous to include exceptions for a specific license.
What makes cover texts acceptable?  Allow sections that do that,
without relying on a specific license.

> C.  == License rules for source and binary packages ==
> 
> All nontrivial non-license works should be
> [https://www.gnu.org/philosophy/free-sw.html free software] or
> [http://freedomdefined.org/Definition free cultural works].
> 
> 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.

> == 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.

> == PKGBUILDs do not fetch nonfree sources ==
> 
> Use SRCBUILDs to make free source archives.  Do not remove nonfree files
> in <code>build()</code>, removing recommendation of nonfree software is
> acceptable.

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.

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).

> == PKGBUILD repositories are free ==
> 
> Do not include patches containing nontrivial nonfree files (use
> <code>rm</code> in SRCBUILDs to remove them).

Again, I don't like locking us in to SRCBUILDs.  Otherwise I support
this.  Perhaps say "(use `rm` or similar to remove them instead)".

> 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".

> == Incompatible PKGBUILDs/source packages are blacklisted ==
> 
> No included PKGBUILD should provide a package incompatible with these
> guidelines.  Some in non-current revisions of the repositories might do
> this, these revisions are known to be unsupported and not recommended
> for use.
> 
> All blacklist changes are discussed on the
> dev at lists.parabolagnulinux.org list before being committed.  Unless it's
> obvious (not only for the original reporter) that the package won't be
> free, an issue report should be left open for it until the problem is
> fixed and the package is unblacklisted or it's known that no useful free
> work can be based on parts of the package.
> 
> If the package is blacklisted for non-Parabola-specific reasons
> (e.g. branding) and not solely due to Arch changes or the PKGBUILD, it
> should be reported:
> 
> * to the upstream project
> * if it does not comply with the FSDG, to the gnu-linux-libre mailing
> list to be listed at the
> [http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
> LibrePlanet list of software that does not respect the Free System
> Distribution Guidelines].  (If upstream solves the problem, it might
> still need fixing in other distributions.)

Sounds good.

> == 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.

> 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}")

> 2. If we change upstream "a" to "b", change "a" to "b" in the name.

Sounds good.

> 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.

> Examples:
> 
> filesystem -> filesystem
> linux -> linux-libre
> linux-tools -> linux-libre-tools
> firefox -> icecat, iceweasel-libre
> p7zip -> p7zip-libre
> gnustep-make -> gnustep-make (no freedom-related changes)

For example, IceCat only has minor changes made to it to make it run
on Parabola without issues.  Iceweasel-libre on the other hand, is
significantly modified from Iceweasel to address freedom issues.  To
claim that what is in iceweasel-libre is Debian Iceweasel is
misleading (pkgdesc="A libre version of Debian Iceweasel, ...").

> G. == Naming of replacement packages ==
> 
> 1. If we change upstream "a" to "b", change "a" to "b" in the name.

Sounds good, same as [F.2].

> 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.

> 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.

> Blacklist of source packages
> ============================
> 
> The aim is to rewrite blacklist.txt to list source packages and have the
> binary packages to remove automatically found by dbscripts.

I'm with you, but writing policy to software that doesn't exist yet is
not OK (though it is something I am often tempted to do as well).

> - write scripts for two-side conversion; should PKGBUILDs be sourced on
>   repo (potential security issues)?

There are various secure ways to parse PKGBUILDS; we should document
them.  Look at how namcap, parts of makepkg (some variables are
extracted by parsing the PKGBUILD, not sourcing it), and AUR does it.

> - verify that bin-to-source < blacklist.txt | source-to-bin gives the
>   same file: blacklist more packages, write more replacements
> 
> - run bin-to-source on the blacklist and commit it
> 
> - change all wiki pages mentioning it
> 
> - close relevant bugs if there are any
> 
> We could do the recfile blacklist rewrite after this change is done.
> 
> Check all libre packages for nonfree software in abslibre or sources
> ====================================================================
> 
> They already remove it from binary packages, so this should be easy to
> check.
> 
> Nearly all issues discussed here (except for nonfree nonfunctional
> data) are already fixed in [libre].  The other issues are related to
> easy to find parts of PKGBUILDs like applying p7zip-libre.patch or
> calls to rm on known nonfree font files in build().

[libre-testing] and git versions of libremakepkg enforce some of
these (and has hooks to enforce more).

I am currently working on "librenamcap", which will detect several
more of these (and will be called by libremakepkg's hooks).

Happy hacking,
~ Luke Shumaker

> Report and fix related bugs
> ===========================
> 
> I'll report and implement some of features needed for these changes if
> you support it.
> 
> If we choose B or C, many relevant changes should be ported from Debian.
> 
> My choice
> =========
> 
> - A: It's more similar to what we already do.  I think we were aware
>   of the GNU nonmodifiable works of opinion and cover texts issues and
>   had no plans to change this.
> - D: I'm not convinced that the work needed for E would be done.
> - G: It's simpler, has less problems than F, IMO F has no additional
>   benefit.
> - I: I think it's similar to accepting works requiring inclusion of a
>   license with an opinion text inside, this is accepted.
> 
> Next draft or issue reporting date
> ==================================
> 
> 2013/01/21