[Dev] [RFC] Package freedom requirements clarification

[Nicolás Reynolds]

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

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

* 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
>   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?

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

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

-- 
http://kiwwwi.com.ar/pastes/para-cooptar-una-comunidad.markdown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20121125/fbe7c6cf/attachment.sig>