[Dev] [RFC] Package freedom requirements clarification
Luke T. Shumaker
lukeshu at sbcglobal.net
Sun Nov 25 20:47:22 GMT 2012
At Sun, 25 Nov 2012 11:29:46 +0100,
Michał Masłowski wrote:
>
> > > 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.
> >
> > I'd like to change this to:
> >
> > 0.1. There should be no nonfree code by the end of `makepkg -o`"
> > 0.2. Nothing nonfree should be tracked in ABSLibre/PBS
>
> It's the same, more explicit.
>
> > Right now 0.1 means what you have; but the next version of makepkg
> > offers a `prepare()` function to prepare the sources. It works exactly
> > like our `mksource()` (currently deprecated in favor of `SRCBUILD`).
>
> The documentation suggests it being used after the source is extracted,
> while mksource and SRCBUILDs do this to make the source archive used for
> builds. Does this mean that our source mirrors would provide the
> nonfree files removed in prepare()?
I didn't think about that. Our source mirrors would mirror the
nonfree files. (But do we even do source mirrors in most cases?)
I guess the question is:
Can we download and distribute non-free code, if it is immediately
deleted at the beginning of the build process?
The only relevent part of FSDG that I could find is:
A free system distribution must not steer users towards obtaining
any nonfree information for practical use, or encourage them to do
so.
So, I think that it is at least ok by FSDG, as the non-free code isn't
being obtained for "practical use".
If we decide that we can't, I will contact the pacman devs and discuss
getting `makepkg --allsource` run `prepare()`.
> > I added 0.2 to mean that there can't be a patch file containing
> > non-free code. Which means that we must use `rm` and friends to
> > remove non-free code; which is fine in most cases.
>
> True.
Happy hacking,
~ Luke Shumaker
More information about the Dev
mailing list