[Dev] [RFC] Package freedom requirements clarification

Michał Masłowski mtjm at mtjm.eu
Sat Nov 24 22:11:48 GMT 2012


We have many free packages, many new ones added and some being found
nonfree and replaced.  We also get questions why some packages are
included or not, some examples are nonfree game data (ND or NC) and
documentation being a nonfree cultural work (e.g. GNU manuals or POSIX
man pages; I'm probably the only user asking about these).

I haven't found any specific policy clearly explaining what software (or
non-software work) is allowed and what isn't.  The Social Contract [0]
is sometimes used to explain this, although it provides no answer other
than referring to the FSDG, while we have stricter unwritten
requirements on ND non-functional data.

There are also Parabola- or Arch-specific packaging issues that
obviously aren't explained by the FSDG which I believe should be

We solve some freedom-related issues on mips64el, while there is
completely no need for this when the x86 ports provide free PKGBUILDs
and sources for packages.

Therefore I propose introducing the four rules listed below so we will
save developers' time by having these policies written and not having
multiple different interpretations of them and by making less changes

0. Do not fetch nonfree sources in PKGBUILDs

I believe this is needed for FSDG compliance.  This can be implemented
using SRCBUILDs or similar technologies.  Having patches containing
whole nontrivial nonfree files in abslibre is IMO also not acceptable.

1. Blacklist source packages/PKGBUILDs, not binary packages

We shouldn't have PKGBUILDs providing non-FSDG packages.  This would
include deprecating rePKGBUILDs.

This change is also needed for the blacklist rewrite I proposed many
months ago.  The recent blacklisting activity and questions for the
reasons why old packages were blacklisted remind me of this being
useful, I will update that proposal.

Some possible benefits:

- all PKGBUILDs are known to have worked at some time

- builds are more reproducible, they don't depend on how the Arch
  packages with nonfree parts were built

- non-x86 ports don't have to do the same changes separately nor merge

- no need to split a PKGBUILD for a single package that was replaced
  (this currently would save much time for mips64el KDE builds)

Why I don't consider rePKGBUILDs important:

- modern non-mips64el machines are fast, while mips64el already needs to
  build the package from source

- we have multiple active x86_64 packages, i686 packages can be built
  too on x86_64 hosts

Examples of affected packages: sqlite, kdebase, kdeutils, kdenetwork.

2. Accept only free cultural works and GNU FDL-licensed documentation

I.e. require all nontrivial non-license works to comply with [1] or [2]
unless they are correctly FDL-licensed documentation (so e.g. a manual
that consists only of invariant sections isn't accepted).

Is there a better way to express our support for free culture without
including too many nonfree works?

3. Provide sources for all packages

We have source tarballs for some packages.  Should these sources be
complete (i.e. so having only abs, all binary packages, the source
tarball and no network access it is possible to build the binary package
From exactly the same source)?  I believe that they should, this might
need VCS packaging standards changes.

This change would benefit from scripts to use our source repos instead
of PKGBUILD-specified mirrors (these aren't always online when repo is,
some URLs have broken while the package needs building on mips64el or is
available on x86), to check the completeness of the source repo and to
upload the source when releasing a package.

Any questions or comments?

[0] https://wiki.parabolagnulinux.org/Parabola/GNU_Linux_Social_Contract
[1] https://www.gnu.org/philosophy/free-sw.html
[2] http://freedomdefined.org/Definition
-------------- 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/20121124/94b3c341/attachment.sig>

More information about the Dev mailing list