[Dev] [RFC] Package freedom requirements clarification

Joshua Ismael Haase Hernandez hahj87 at gmail.com
Sun Nov 25 01:24:33 GMT 2012


I agree with this course of action. One question tough: Would this
require us to maintain a public repo with non-free sources?

Michał Masłowski <mtjm at mtjm.eu> writes:

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

It is true that we have stricter requirements and we should make those
statements public.

> There are also Parabola- or Arch-specific packaging issues that
> obviously aren't explained by the FSDG which I believe should be
> documented.
>
> 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
> mips64el-specific.
>
> 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
>   them
>
> - 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
> _______________________________________________
> Dev mailing list
> Dev at lists.parabolagnulinux.org
> https://lists.parabolagnulinux.org/mailman/listinfo/dev
-------------- 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/e28ff9fb/attachment.sig>


More information about the Dev mailing list