[Dev] [RFC] Package freedom requirements clarification
fauno at kiwwwi.com.ar
Sun Nov 25 22:23:41 GMT 2012
Michał Masłowski <mtjm at mtjm.eu> writes:
> 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 
> 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.
i think this should be coded into PBS:
* we'll get pkgbuild updates directly from upstream and merge them with
our freedom-related and/or port changes
* this can be done by automated tools so it's less boring work for us
and the intermediate probably-unfree-steering pkgbuilds won't be
* your listed benefits
> 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  or 
> 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?
discussing freedom related issues with upstream (without trolling) is
better. we had discussed this with encyclomundi when the syslog-ng guys
got angry because we blacklisted them iirc, and also guestone reported a
mislicensed art for a game that would go unnoticed if we had just
> 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.
i remember lxo asking if we'd provide source dvds too.
i think it's ok but the social contract should add the clarification in
favor of free cultural works too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: not available
More information about the Dev