[Dev] [Voting] Package freedom guidelines draft two

Michał Masłowski mtjm at mtjm.eu
Mon Jan 7 20:06:09 GMT 2013


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.

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.

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

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

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.

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.

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.

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

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

== PKGBUILD repositories are free ==

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

D. Non-head revisions of their VCS repositories are unsupported and
might contain nonfree software.

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.

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

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

F. == Naming of replacement packages ==

1. If the exact package name is needed, keep it.
2. If we change upstream "a" to "b", change "a" to "b" in the name.
3. If there is no "-libre" in the resulting name and the package of
   the current upstream is changed for these guidelines, append
   "-libre".

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)

G. == Naming of replacement packages ==

1. If we change upstream "a" to "b", change "a" to "b" in the name.
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.

Many existing replacement packages have different names, they should
not be changed just for this rule.

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.

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

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

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

(I won't have much time for hacking before the second half of February.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20130107/96ef179d/attachment.sig>


More information about the Dev mailing list