Re: [gentoo-dev] Clarify the "as-is" license?

[Rich Freeman]

On Mon, Sep 24, 2012 at 3:02 AM, Ulrich Mueller <ulm@g.o> wrote:
> Unfortunately, it's not clear from our documentation if the LICENSE
> variable applies to the source tarball or to the files that the
> package installs on the user's system.

Hmm, if these aren't the same, then more likely than not something is
wrong, but perhaps we'll have to confront this issue at some point.

>
> I tend to interpret it in the latter sense. To illustrate why, let's
> look at sci-visualization/gnuplot-4.6.0 as an example:
>
>    LICENSE="gnuplot GPL-2 bitmap? ( free-noncomm )"
>
> The bulk of the package is free software, distributed under the
> gnuplot license or the GPL-2. However, there's an additional notice
> with a no-sale clause in a single source file (src/bitmap.c).
> If LICENSE applies to installed files, than we can disable the
> functionality via USE=-bitmap and we're done.

I guess we can get away with redistributing the source files each
under their respective license, since there is no "derived work" at
this point.  However, any binaries built from such a thing would not
be redistributable.  None of those licenses are GPL-compatible.

>
> However, if we say that LICENSE covers the source tarball, then we
> either need to change it to an unconditional "gnuplot GPL-2
> free-noncomm", which has the consequence that gnuplot is no longer
> installable for users who have ACCEPT_LICENSE="-* @FREE".

Here is the thing - suppose somebody runs a Gentoo mirror but has ads
on their page and is a commercial organization.  They can't even
MIRROR that source legally because of the presence of that one file,
unless its license allows for-profit redistribution of the source.

>
> Or, we must no longer distribute pristine source from upstream, but
> repack them into a new tarball with bitmap.c removed. This would have
> to be done for every release, which isn't feasible.

Not necessarily the end of the world to be honest - how many things do
we have in the tree for which upstream only has an scm and no source
tarballs, so we have to roll our own on every release anyway due to
the prohibition on live scm packages being unmasked?

>
> Similar reasoning applies to the various Linux kernel packages that
> have LICENSE="GPL-2 !deblob? ( freedist )".
>
>> or nomirror.
>
> That's a different issue. In the case of RESTRICT="mirror" it is clear
> that it applies to the sources that we distribute.

I think the key is to make sure that the sources at least can be
distributed without getting anybody into trouble.  If so we don't need
to restrict them.  However, I don't think the final thing can be @FREE
- it isn't binary redistributable as the final built code isn't
licensed at all.  We should point this out somehow.

Rich