Question about multiple licenses

Question about multiple licenses

[Arun Isaac]

I'm packaging linkchecker.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27468

Different files of linkchecker have different license headers. The
license field of the package is as follows:

(license (list l:gpl2+
               l:bsd-2 ; linkcheck/better_exchook2.py
               l:bsd-3 ; linkcheck/colorama.py
               l:psfl  ; linkcheck/gzip2.py
               l:expat ; linkcheck/mem.py
               l:isc   ; third_party/dnspython
               l:asl2.0))

gpl2+ is a stricter license than the other licenses, and covers the
"program as a whole". So, do we really need to mention the other
licenses, especially those licenses which cover only one source file? Is
it a good idea to hide the multiple licenses from the user, and just
mention gpl2+ as the license of the whole package?

Re: Question about multiple licenses

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]

Arun Isaac <arunisaac@systemreboot.net> writes:

> I'm packaging linkchecker.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27468
>
> Different files of linkchecker have different license headers. The
> license field of the package is as follows:
>
> (license (list l:gpl2+
>                l:bsd-2 ; linkcheck/better_exchook2.py
>                l:bsd-3 ; linkcheck/colorama.py
>                l:psfl  ; linkcheck/gzip2.py
>                l:expat ; linkcheck/mem.py
>                l:isc   ; third_party/dnspython
>                l:asl2.0))
>
> gpl2+ is a stricter license than the other licenses, and covers the
> "program as a whole". So, do we really need to mention the other
> licenses, especially those licenses which cover only one source file? Is
> it a good idea to hide the multiple licenses from the user, and just
> mention gpl2+ as the license of the whole package?

OK, maybe this is a little bit late... But I would like to share my
opinions. I think there are actually two cases: 1. combining (L)GPL with
(L)GPL and 2. combining (L)GPL with non-(L)GPL.

For case 1, yes, the whole work can be re-licensed under the "stricter"
license, providing that we have the "or later" clause. So GPLv2+ with
LGPLv3+ can be re-licensed to GPLv3+, but GPLv2 with LGPLv3+ cannot be
re-licensed to GPLv3+, since the GPLv2 license does not have the
"or later" clause. For details, see the GPL compatibility matrix[0].

For case 2, well, the idea is the same. Unless the non-(L)GPL license
has an explicit clause allowing it to (recursively) re-license to
(L)GPL. For instance, CC-BY-SA-4.0 can be re-license to GPLv3, but BSD-2
cannot be re-license to GPLv3+.

Based on the above general argument, I think we should list all the
licenses instead of just GPLv2+ since it would be inaccurate to say that
the whole program is under just GPLv2+.

Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
we actually need to take advantage of the "or later" clause, and
"upgrades" it to "GPLv3+". Listing the license as GPLv2+ would confuse
the user that GPLv2 covers the program, but in fact it is "effectively"
GPLv3.

Of course, I am not a lawyer. I only get the info from reading the
web. So I could be saying nonsense...

[0]: https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Question about multiple licenses

[Arun Isaac]

Alex Vong writes:

> Based on the above general argument, I think we should list all the
> licenses instead of just GPLv2+ since it would be inaccurate to say that
> the whole program is under just GPLv2+.

Listing all the licenses does seem like the safest thing to do.

> Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
> we actually need to take advantage of the "or later" clause, and
> "upgrades" it to "GPLv3+".

Is there any Guix package where we have actually done such a license
upgrade?

> Listing the license as GPLv2+ would confuse the user that GPLv2 covers
> the program, but in fact it is "effectively" GPLv3.
>
> Of course, I am not a lawyer. I only get the info from reading the
> web. So I could be saying nonsense...
>
> [0]: https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility

Re: Question about multiple licenses

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On Mon, Aug 28, 2017 at 10:55:34PM +0530, Arun Isaac wrote:
> 
> Alex Vong writes:
> 
> > Based on the above general argument, I think we should list all the
> > licenses instead of just GPLv2+ since it would be inaccurate to say that
> > the whole program is under just GPLv2+.
> 
> Listing all the licenses does seem like the safest thing to do.
> 
> > Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
> > we actually need to take advantage of the "or later" clause, and
> > "upgrades" it to "GPLv3+".
> 
> Is there any Guix package where we have actually done such a license
> upgrade?
> 

We have a couple of packages which state "GPL" and we've chosen GPL1+ or
something similar.

> > Listing the license as GPLv2+ would confuse the user that GPLv2 covers
> > the program, but in fact it is "effectively" GPLv3.
> >
> > Of course, I am not a lawyer. I only get the info from reading the
> > web. So I could be saying nonsense...
> >
> > [0]: https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Question about multiple licenses

[Arun Isaac]

Efraim Flashner writes:

> On Mon, Aug 28, 2017 at 10:55:34PM +0530, Arun Isaac wrote:
>>
>> Alex Vong writes:
>>
>> > Based on the above general argument, I think we should list all the
>> > licenses instead of just GPLv2+ since it would be inaccurate to say that
>> > the whole program is under just GPLv2+.
>>
>> Listing all the licenses does seem like the safest thing to do.
>>
>> > Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
>> > we actually need to take advantage of the "or later" clause, and
>> > "upgrades" it to "GPLv3+".
>>
>> Is there any Guix package where we have actually done such a license
>> upgrade?
>
> We have a couple of packages which state "GPL" and we've chosen GPL1+ or
> something similar.

Hmmm. This is not quite similar to the case of multiple licenses with the
linkchecker package. I'll go ahead with listing all the licenses if
there are no objections.

Re: Question about multiple licenses

[Dave Love]

Alex Vong <alexvong1995@gmail.com> writes:

> Based on the above general argument, I think we should list all the
> licenses instead of just GPLv2+ since it would be inaccurate to say that
> the whole program is under just GPLv2+.

Indeed.  Not only do you need to list the licences (according to all
"legal advice" I've seen for distributions), but normally also
distribute the relevant licence texts, even for permissive licences if
they require that (e.g. BSD).  I raised this recently, as it's not
generally being done, so some Guix binary packages appear to be
copyright-infringing.

> Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
> we actually need to take advantage of the "or later" clause, and
> "upgrades" it to "GPLv3+". Listing the license as GPLv2+ would confuse
> the user that GPLv2 covers the program, but in fact it is "effectively"
> GPLv3.

This possibly depends on whether the licence information refers to the
source or binary package.  Fedora explicitly says binary, for instance.

> Of course, I am not a lawyer. I only get the info from reading the
> web. So I could be saying nonsense...

Well said.  Surely things like this in a GNU project need FSF legal
advice if there's any question about them.

For what it's worth, the information for Fedora and Debian packagers is
<https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License:_field>
and
<https://www.debian.org/doc/debian-policy/index.html#copyright-debian-copyright>.
They're not necessarily consistent, and things may be somewhat different
for GNU, but they provide a reasonable indication of the legalities.

Re: Question about multiple licenses

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

Dave Love <fx@gnu.org> writes:

> Indeed.  Not only do you need to list the licences (according to all
> "legal advice" I've seen for distributions), but normally also
> distribute the relevant licence texts, even for permissive licences if
> they require that (e.g. BSD).  I raised this recently, as it's not
> generally being done, so some Guix binary packages appear to be
> copyright-infringing.
>
Yes, I think Debian has a /usr/share/doc/PKG/copyright file for each
package PKG. Also, it includes the /usr/share/common-licenses/
directory, so that those copyright files can refer to the common
licenses without copying them verbatimly.

>> Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
>> we actually need to take advantage of the "or later" clause, and
>> "upgrades" it to "GPLv3+". Listing the license as GPLv2+ would confuse
>> the user that GPLv2 covers the program, but in fact it is "effectively"
>> GPLv3.
>
> This possibly depends on whether the licence information refers to the
> source or binary package.  Fedora explicitly says binary, for instance.
>
I am unaware of this distinction. Maybe a website explaining this would
be helpful.

> For what it's worth, the information for Fedora and Debian packagers is
> <https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License:_field>
> and
> <https://www.debian.org/doc/debian-policy/index.html#copyright-debian-copyright>.
> They're not necessarily consistent, and things may be somewhat different
> for GNU, but they provide a reasonable indication of the legalities.

I think we should improve the status quote by documenting the license
accurately in the license field. What do you think?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Question about multiple licenses

[Dave Love]

Alex Vong <alexvong1995@gmail.com> writes:

> Dave Love <fx@gnu.org> writes:
>
>> Indeed.  Not only do you need to list the licences (according to all
>> "legal advice" I've seen for distributions), but normally also
>> distribute the relevant licence texts, even for permissive licences if
>> they require that (e.g. BSD).  I raised this recently, as it's not
>> generally being done, so some Guix binary packages appear to be
>> copyright-infringing.
>>
> Yes, I think Debian has a /usr/share/doc/PKG/copyright file for each
> package PKG. Also, it includes the /usr/share/common-licenses/
> directory, so that those copyright files can refer to the common
> licenses without copying them verbatimly.

Yes.  That won't work for variant licences, though, and for where you
have to maintain the copyright notice in the file.

>>> Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
>>> we actually need to take advantage of the "or later" clause, and
>>> "upgrades" it to "GPLv3+". Listing the license as GPLv2+ would confuse
>>> the user that GPLv2 covers the program, but in fact it is "effectively"
>>> GPLv3.
>>
>> This possibly depends on whether the licence information refers to the
>> source or binary package.  Fedora explicitly says binary, for instance.
>>
> I am unaware of this distinction. Maybe a website explaining this would
> be helpful.

It's in the Fedora reference.  For instance, the licence of a test
program in the distribution doesn't affect the licence of the binary
outputs if it's not shipped.

>> For what it's worth, the information for Fedora and Debian packagers is
>> <https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License:_field>
>> and
>> <https://www.debian.org/doc/debian-policy/index.html#copyright-debian-copyright>.
>> They're not necessarily consistent, and things may be somewhat different
>> for GNU, but they provide a reasonable indication of the legalities.
>
> I think we should improve the status quote by documenting the license
> accurately in the license field. What do you think?

Yes, following the Fedora example.  I'd assume it's meant to be
basically the same thing as RPM's License: field.

Re: Question about multiple licenses

[Arun Isaac]

Dave Love writes:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> Based on the above general argument, I think we should list all the
>> licenses instead of just GPLv2+ since it would be inaccurate to say that
>> the whole program is under just GPLv2+.
>
> Indeed.  Not only do you need to list the licences (according to all
> "legal advice" I've seen for distributions), but normally also
> distribute the relevant licence texts, even for permissive licences if
> they require that (e.g. BSD).  I raised this recently, as it's not
> generally being done, so some Guix binary packages appear to be
> copyright-infringing.

I pushed linkchecker with all the licenses listed. So, I guess we've
done the right thing with respect to this package.

Re: Question about multiple licenses

[Ludovic Courtès]

Dave Love <fx@gnu.org> skribis:

> Alex Vong <alexvong1995@gmail.com> writes:
>
>> Based on the above general argument, I think we should list all the
>> licenses instead of just GPLv2+ since it would be inaccurate to say that
>> the whole program is under just GPLv2+.
>
> Indeed.  Not only do you need to list the licences (according to all
> "legal advice" I've seen for distributions), but normally also
> distribute the relevant licence texts, even for permissive licences if
> they require that (e.g. BSD).  I raised this recently, as it's not
> generally being done, so some Guix binary packages appear to be
> copyright-infringing.

There’s no such thing as a “Guix binary package” though, which makes it
different from traditional distros.

In Guix a package is a Scheme object that refers to the source and build
method of upstream software.

One can always view the COPYING file by running, say:

  tar xf $(guix build -S glibc) glibc-2.25/COPYING

This is of course suboptimal because the exact incantation varies from
package to package (in some cases there’s no such file.)

Thoughts?

Ludo’.

Re: Question about multiple licenses

[Dave Love]

Ludovic Courtès <ludo@gnu.org> writes:

> Dave Love <fx@gnu.org> skribis:
>
>> Alex Vong <alexvong1995@gmail.com> writes:
>>
>>> Based on the above general argument, I think we should list all the
>>> licenses instead of just GPLv2+ since it would be inaccurate to say that
>>> the whole program is under just GPLv2+.
>>
>> Indeed.  Not only do you need to list the licences (according to all
>> "legal advice" I've seen for distributions), but normally also
>> distribute the relevant licence texts, even for permissive licences if
>> they require that (e.g. BSD).  I raised this recently, as it's not
>> generally being done, so some Guix binary packages appear to be
>> copyright-infringing.
>
> There’s no such thing as a “Guix binary package” though, which makes it
> different from traditional distros.
>
> In Guix a package is a Scheme object that refers to the source and build
> method of upstream software.

Sure, but if you use guix pack and distribute the result, it seems
clearly a copyright infringement, because even BSD requires

  2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the distribution.

> One can always view the COPYING file by running, say:
>
>   tar xf $(guix build -S glibc) glibc-2.25/COPYING
>
> This is of course suboptimal because the exact incantation varies from
> package to package (in some cases there’s no such file.)
>
> Thoughts?
>
> Ludo’.

Well, from what I know about copyright, that isn't the licence of glibc,
which is the sum of all the licences involved, and you'd have to know
how to find them if you didn't just unpack the tarball.  With pack
output in a lot of cases you don't have the information.

Re: Question about multiple licenses

[Ludovic Courtès]

Dave Love <fx@gnu.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Dave Love <fx@gnu.org> skribis:
>>
>>> Alex Vong <alexvong1995@gmail.com> writes:
>>>
>>>> Based on the above general argument, I think we should list all the
>>>> licenses instead of just GPLv2+ since it would be inaccurate to say that
>>>> the whole program is under just GPLv2+.
>>>
>>> Indeed.  Not only do you need to list the licences (according to all
>>> "legal advice" I've seen for distributions), but normally also
>>> distribute the relevant licence texts, even for permissive licences if
>>> they require that (e.g. BSD).  I raised this recently, as it's not
>>> generally being done, so some Guix binary packages appear to be
>>> copyright-infringing.
>>
>> There’s no such thing as a “Guix binary package” though, which makes it
>> different from traditional distros.
>>
>> In Guix a package is a Scheme object that refers to the source and build
>> method of upstream software.
>
> Sure, but if you use guix pack and distribute the result, it seems
> clearly a copyright infringement, because even BSD requires
>
>   2. Redistributions in binary form must reproduce the above copyright
>      notice, this list of conditions and the following disclaimer in the
>      documentation and/or other materials provided with the distribution.

[...]

> Well, from what I know about copyright, that isn't the licence of glibc,
> which is the sum of all the licences involved, and you'd have to know
> how to find them if you didn't just unpack the tarball.  With pack
> output in a lot of cases you don't have the information.

Right, ‘guix pack’ makes things more complicated—although I would argue
that, contrary to Dockerfiles and the like (which nobody seems to
complain about), Guix makes it easier to do provenance tracking since
there’s an unambiguous source → binary mapping.

How do Debian and Fedora determine the relevant files to copy?  We could
investigate ways to do that, but it won’t scale unless we have a mostly
automated way to do it.

(It won’t scale to the size of Stackage, CPAN, Pypi, etc. either…)

Thoughts?

Ludo’.

Re: Question about multiple licenses

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]

ludo@gnu.org (Ludovic Courtès) writes:

> Dave Love <fx@gnu.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Dave Love <fx@gnu.org> skribis:
>>>
>>>> Alex Vong <alexvong1995@gmail.com> writes:
>>>>
>>>>> Based on the above general argument, I think we should list all the
>>>>> licenses instead of just GPLv2+ since it would be inaccurate to say that
>>>>> the whole program is under just GPLv2+.
>>>>
>>>> Indeed.  Not only do you need to list the licences (according to all
>>>> "legal advice" I've seen for distributions), but normally also
>>>> distribute the relevant licence texts, even for permissive licences if
>>>> they require that (e.g. BSD).  I raised this recently, as it's not
>>>> generally being done, so some Guix binary packages appear to be
>>>> copyright-infringing.
>>>
>>> There’s no such thing as a “Guix binary package” though, which makes it
>>> different from traditional distros.
>>>
>>> In Guix a package is a Scheme object that refers to the source and build
>>> method of upstream software.
>>
>> Sure, but if you use guix pack and distribute the result, it seems
>> clearly a copyright infringement, because even BSD requires
>>
>>   2. Redistributions in binary form must reproduce the above copyright
>>      notice, this list of conditions and the following disclaimer in the
>>      documentation and/or other materials provided with the distribution.
>
> [...]
>
>> Well, from what I know about copyright, that isn't the licence of glibc,
>> which is the sum of all the licences involved, and you'd have to know
>> how to find them if you didn't just unpack the tarball.  With pack
>> output in a lot of cases you don't have the information.
>
> Right, ‘guix pack’ makes things more complicated—although I would argue
> that, contrary to Dockerfiles and the like (which nobody seems to
> complain about), Guix makes it easier to do provenance tracking since
> there’s an unambiguous source → binary mapping.
>
Does 'guix pack' currently included the source that uses to build the
pack? Will including the source signaficantly increases the size of the
pack? Or should we add a flag for building a "source pack"?

> How do Debian and Fedora determine the relevant files to copy?  We could
> investigate ways to do that, but it won’t scale unless we have a mostly
> automated way to do it.
>
> (It won’t scale to the size of Stackage, CPAN, Pypi, etc. either…)
>
> Thoughts?
>
> Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Question about multiple licenses

[Andy Wingo]

On Mon 11 Sep 2017 13:29, Alex Vong <alexvong1995@gmail.com> writes:

>>> Well, from what I know about copyright, that isn't the licence of glibc,
>>> which is the sum of all the licences involved, and you'd have to know
>>> how to find them if you didn't just unpack the tarball.  With pack
>>> output in a lot of cases you don't have the information.
>>
>> Right, ‘guix pack’ makes things more complicated—although I would argue
>> that, contrary to Dockerfiles and the like (which nobody seems to
>> complain about), Guix makes it easier to do provenance tracking since
>> there’s an unambiguous source → binary mapping.
>>
> Does 'guix pack' currently included the source that uses to build the
> pack? Will including the source signaficantly increases the size of the
> pack? Or should we add a flag for building a "source pack"?

It does not.  Guix's idea of "source" is larger than copyright's idea of
source I think -- i.e. the compiler doesn't impose additional copyright
concerns on binary products, but it does form part of what Guix
considers to be source.

More concretely... if this is necessary (and I suspect but don't know
that it is,) probably the easiest thing would be for each package to
install a copyright file in its output derivations.  Then a "guix pack"
would include them automatically.  It would be good to symlink/dedup
common copyright files of course, but that can be a later step.

Andy

Re: Question about multiple licenses

[Dave Love]

Andy Wingo <wingo@igalia.com> writes:

> More concretely... if this is necessary (and I suspect but don't know
> that it is,) probably the easiest thing would be for each package to
> install a copyright file in its output derivations.  Then a "guix pack"
> would include them automatically.  It would be good to symlink/dedup
> common copyright files of course, but that can be a later step.
>
> Andy

Exactly (for generalized values of "a copyright file" unless you
amalgamate multiple ones like Debian does).  There's a limit to simple
deduplication if "this notice" that you need to ship includes a
copyright notice as well as the licence text ("Copyright 2017 Fred
Bloggs ...").

Re: Question about multiple licenses

[Dave Love]

Ludovic Courtès <ludo@gnu.org> writes:

>> Well, from what I know about copyright, that isn't the licence of glibc,
>> which is the sum of all the licences involved, and you'd have to know
>> how to find them if you didn't just unpack the tarball.  With pack
>> output in a lot of cases you don't have the information.
>
> Right, ‘guix pack’ makes things more complicated—although I would argue
> that, contrary to Dockerfiles and the like (which nobody seems to
> complain about),

Well, 
they should -- I think there should be something from GNU on
the topic -- and it's what motivated the Fedora
policy to separate %licence.  That's supposed to go into containers as
I understand it, c.f. %doc, which isn't in spec files.

> Guix makes it easier to do provenance tracking since
> there’s an unambiguous source → binary mapping.

Right, though the binary can be under a subset licence, e.g. when
un-shipped tests are under a different licence.

> How do Debian and Fedora determine the relevant files to copy?  We could
> investigate ways to do that, but it won’t scale unless we have a mostly
> automated way to do it.

The submitter and reviewer have to put the right stuff in the package
definition -- %license for Fedora and the copyright file for Debian.
That should be checked to first order with licensecheck (automated in
the "fedora-review" tool).  You might be able to automate cross-checking
with Debian and Fedora to some extent.

> (It won’t scale to the size of Stackage, CPAN, Pypi, etc. either…)
>
> Thoughts?

I think it has to be got right even if they don't do so.  There's plenty
imported to Fedora and Debian from those.