[gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michał Górny]

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

Hi,

It seems that we suffer a major problem of developers wrongly
attributing *GPL-[23] licenses to ebuilds, when the correct variant is
*GPL-[23]+.  In proxy-maint, every second new package with LICENSE=GPL-
[23] is plain wrong.  I suspect part of the problem is that GitHub has
poor man's license recognition that does not distinguish between 'vN
only' and 'vN or newer' license variants, and similarly that a number of
contributors don't bother checking the license beyond COPYING/README.

Another part of the problem is that we don't have a really good way of
distinguishing verified correct uses of *GPL-[23].  So in the end, I end
up verifying the same packages over and over again unless I remember
that I've verified them.

Therefore, I would like to suggest the following:

1. introducing additional *-only licenses that explicitly indicate that
a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.

2. annotating the unsuffixed licenses with a warning that they may mean
either x-only or x+ due to frequent mistake.

3. make repoman warn whenever non-specific variant is used, telling
developers to verify whether it's x-only or x+.

4. start migrating packages to x-only or x+ appropriately.

5. eventually, remove the non-specific licenses and make repoman error
out with clear explanation.

What do you think?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Mart Raudsepp]

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

Ühel kenal päeval, P, 26.08.2018 kell 12:39, kirjutas Michał Górny:
> Hi,
> 
> It seems that we suffer a major problem of developers wrongly
> attributing *GPL-[23] licenses to ebuilds, when the correct variant
> is
> *GPL-[23]+.  In proxy-maint, every second new package with
> LICENSE=GPL-
> [23] is plain wrong.  I suspect part of the problem is that GitHub
> has
> poor man's license recognition that does not distinguish between 'vN
> only' and 'vN or newer' license variants, and similarly that a number
> of
> contributors don't bother checking the license beyond COPYING/README.
> 
> Another part of the problem is that we don't have a really good way
> of
> distinguishing verified correct uses of *GPL-[23].  So in the end, I
> end
> up verifying the same packages over and over again unless I remember
> that I've verified them.
> 
> Therefore, I would like to suggest the following:
> 
> 1. introducing additional *-only licenses that explicitly indicate
> that
> a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
> 
> 2. annotating the unsuffixed licenses with a warning that they may
> mean
> either x-only or x+ due to frequent mistake.
> 
> 3. make repoman warn whenever non-specific variant is used, telling
> developers to verify whether it's x-only or x+.
> 
> 4. start migrating packages to x-only or x+ appropriately.
> 
> 5. eventually, remove the non-specific licenses and make repoman
> error
> out with clear explanation.
> 
> What do you think?

The common issue here is that upstream COPYING files really do only
talk about one of the versions. And then you get to validate or source
files to be sure that they do have a "or later" clause in them. And
then on each bump you ideally should validate it again, etc, that no
sources without "or later" allowance are in there...
In many cases you can trust upstreams that do make it explicit
somewhere though (toplevel meson.build, README.md, CONTRIBUTING.md,
etc).
Otherwise good idea, but I'm not sure how we are supposed to keep up
with monitoring non-"or later" sources creeping in in new upstream
versions.

There are plenty of wrong LICENSE tags in this regard under my co-
maintenance too, and it's a pain to validate all the source files, and
it's just a best effort of "hopefully my grep magic covered it and they
haven't used a non-standard file copyright header".


Mart

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan, Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 1103 bytes --]

On 26/08/2018 12:53, Mart Raudsepp wrote:
> The common issue here is that upstream COPYING files really do only
> talk about one of the versions. And then you get to validate or source
> files to be sure that they do have a "or later" clause in them. And
> then on each bump you ideally should validate it again, etc, that no
> sources without "or later" allowance are in there...

Yup, precise tracking of license metadata can be a pain.

I'm not really sure if that level of it is worth for us as a distro. For
_importing_ other project's source code directly into one's project
precise license compatibility matters a lot. That's not the scenario
we're in. I see LICENSES as mostly a mechanism for end users to accept
or reject EULAs etc, and I'm curious what are other common scenarios.

Michał, could you elaborate on why not distinguishing more precisely
between these GPL variants in LICENSES is a _problem_ ? I can certainly
see the information is not always accurate, but it's not obvious to me
how severe is the downside, what are the consequences in practice.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michał Górny]

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

On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> On 26/08/2018 12:53, Mart Raudsepp wrote:
> > The common issue here is that upstream COPYING files really do only
> > talk about one of the versions. And then you get to validate or source
> > files to be sure that they do have a "or later" clause in them. And
> > then on each bump you ideally should validate it again, etc, that no
> > sources without "or later" allowance are in there...
> 
> Yup, precise tracking of license metadata can be a pain.
> 
> I'm not really sure if that level of it is worth for us as a distro. For
> _importing_ other project's source code directly into one's project
> precise license compatibility matters a lot. That's not the scenario
> we're in. I see LICENSES as mostly a mechanism for end users to accept
> or reject EULAs etc, and I'm curious what are other common scenarios.
> 
> Michał, could you elaborate on why not distinguishing more precisely
> between these GPL variants in LICENSES is a _problem_ ? I can certainly
> see the information is not always accurate, but it's not obvious to me
> how severe is the downside, what are the consequences in practice.
> 

I'm not aware of any major implications.  However, I think that if we
provide for the distinction, the distinction should be used correctly.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Roy Bamford]

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

On 2018.08.26 12:15, Michał Górny wrote:
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > On 26/08/2018 12:53, Mart Raudsepp wrote:
> > > The common issue here is that upstream COPYING files really do
> only
> > > talk about one of the versions. And then you get to validate or
> source
> > > files to be sure that they do have a "or later" clause in them.
> And
> > > then on each bump you ideally should validate it again, etc, that
> no
> > > sources without "or later" allowance are in there...
> > 
> > Yup, precise tracking of license metadata can be a pain.
> > 
> > I'm not really sure if that level of it is worth for us as a distro.
> For
> > _importing_ other project's source code directly into one's project
> > precise license compatibility matters a lot. That's not the scenario
> > we're in. I see LICENSES as mostly a mechanism for end users to
> accept
> > or reject EULAs etc, and I'm curious what are other common
> scenarios.
> > 
> > Michał, could you elaborate on why not distinguishing more precisely
> > between these GPL variants in LICENSES is a _problem_ ? I can
> certainly
> > see the information is not always accurate, but it's not obvious to
> me
> > how severe is the downside, what are the consequences in practice.
> > 
> 
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.
> 
> -- 
> Best regards,
> Michał Górny
> 

Michał,

How far do you want to dig?
Every upstream file or do you trust the upstream top level licence?

What about bundled libs?
Do you trust upstream to have that that right too?

It looks like a lot of work for what is at most, a convenience to users.

What matters most is the licensing for things we distribute as binaries.
That would make an interesting and more manageable test case.

As has already been pointed out. Fixing it is one thing, keeping it fixed
is another.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Rich Freeman]

On Sun, Aug 26, 2018 at 7:15 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > On 26/08/2018 12:53, Mart Raudsepp wrote:
> > > The common issue here is that upstream COPYING files really do only
> > > talk about one of the versions. And then you get to validate or source
> > > files to be sure that they do have a "or later" clause in them. And
> > > then on each bump you ideally should validate it again, etc, that no
> > > sources without "or later" allowance are in there...
> >
> > Yup, precise tracking of license metadata can be a pain.
> >
> > I'm not really sure if that level of it is worth for us as a distro. For
> > _importing_ other project's source code directly into one's project
> > precise license compatibility matters a lot. That's not the scenario
> > we're in. I see LICENSES as mostly a mechanism for end users to accept
> > or reject EULAs etc, and I'm curious what are other common scenarios.
> >
> > Michał, could you elaborate on why not distinguishing more precisely
> > between these GPL variants in LICENSES is a _problem_ ? I can certainly
> > see the information is not always accurate, but it's not obvious to me
> > how severe is the downside, what are the consequences in practice.
> >
>
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.
>

IMO QA policy ought to be that the license is correct.

How much time/effort goes into policing the policy in the case of
2/3/2+/3+ is a different matter.  If people want to do it, great, but
IMO it isn't adding tremendous value.  I doubt we have any users
relying on license filtering to distinguish between GPL2/2+.  If
somebody files a bug pointing out an incorrect license it should be
fixed as a matter of policy, but I'm not sure more than that is
necessary in this particular case.  If we were talking about nonfree
licenses being missed that would be more critical.

-- 
Rich

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Ulrich Mueller]

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

>>>>> On Sun, 26 Aug 2018, Michał Górny wrote:

> 1. introducing additional *-only licenses that explicitly indicate
> that a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.

I don't like this at all, because LICENSE="GPL-2" means exactly the
above, namely GPL version 2, no later version. Therefore, "GPL-2-only"
would be completely redundant to it.

What we could do (and what already exists in several ebuilds) is to add
a *comment* to the LICENSE line, like "# GPL-2 only". This could be
required for every new ebuild.

> 2. annotating the unsuffixed licenses with a warning that they may
> mean either x-only or x+ due to frequent mistake.

I don't think that's a good idea either. Also we're not allowed to
change the license documents:
"Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed."

> 3. make repoman warn whenever non-specific variant is used, telling
> developers to verify whether it's x-only or x+.

Repoman could check for a comment in the LICENSE line as well, I guess?

> 4. start migrating packages to x-only or x+ appropriately.

See above. We could instead migrate ebuilds with "GPL-2" to either:
LICENSE="GPL-2+"
or:
LICENSE="GPL-2" # GPL-2 only

Optionally, the comment can be removed once all ebuilds have been
converted.

> 5. eventually, remove the non-specific licenses and make repoman error
> out with clear explanation.

Ulrich

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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan, Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 555 bytes --]

On 26/08/2018 13:15, Michał Górny wrote:
> I'm not aware of any major implications.  However, I think that if we
> provide for the distinction, the distinction should be used correctly.

Makes sense.

Note that this might also be an argument for _not_ providing such
fine-grained distinction (unless there's corresponding value in it).

If in doubt, at least my intuition is to err on the side of simplicity.

I also like Rich's opinion on this,
<https://archives.gentoo.org/gentoo-dev/message/477f3d666e719a82b3ffc891d95f1b2b>

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michał Górny]

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

On Sun, 2018-08-26 at 17:50 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 26 Aug 2018, Michał Górny wrote:
> > 1. introducing additional *-only licenses that explicitly indicate
> > that a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
> 
> I don't like this at all, because LICENSE="GPL-2" means exactly the
> above, namely GPL version 2, no later version. Therefore, "GPL-2-only"
> would be completely redundant to it.
> 
> What we could do (and what already exists in several ebuilds) is to add
> a *comment* to the LICENSE line, like "# GPL-2 only". This could be
> required for every new ebuild.

Sure, I suppose that would work.

> > 2. annotating the unsuffixed licenses with a warning that they may
> > mean either x-only or x+ due to frequent mistake.
> 
> I don't think that's a good idea either. Also we're not allowed to
> change the license documents:
> "Everyone is permitted to copy and distribute verbatim copies
> of this license document, but changing it is not allowed."

I don't think adding an annotation on top or bottom is equal to changing
it.

> 
> > 3. make repoman warn whenever non-specific variant is used, telling
> > developers to verify whether it's x-only or x+.
> 
> Repoman could check for a comment in the LICENSE line as well, I guess?

Proper handling of comments would be rather hard, especially given that
by definition they have no specific form and therefore users can use
them in weird ways.

> 
> > 4. start migrating packages to x-only or x+ appropriately.
> 
> See above. We could instead migrate ebuilds with "GPL-2" to either:
> LICENSE="GPL-2+"
> or:
> LICENSE="GPL-2" # GPL-2 only

One thing where this would fail would be e.g.:

  LICENSE="GPL-2+
    bar? ( GPL-2 )
    foo? ( GPL-3+ )" ^ you can't put a comment on the right line

> 
> Optionally, the comment can be removed once all ebuilds have been
> converted.
> 
> > 5. eventually, remove the non-specific licenses and make repoman error
> > out with clear explanation.
> 
> Ulrich

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Mart Raudsepp]

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

Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
> One thing where this would fail would be e.g.:
> 
>   LICENSE="GPL-2+
>     bar? ( GPL-2 )
>     foo? ( GPL-3+ )" ^ you can't put a comment on the right line

LICENSE="GPL-2+ "
LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
LICENSE+="foo? ( GPL-3+ )"

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 445 bytes --]

On 26/08/18 19:14, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
>> One thing where this would fail would be e.g.:
>>
>>   LICENSE="GPL-2+
>>     bar? ( GPL-2 )
>>     foo? ( GPL-3+ )" ^ you can't put a comment on the right line
> LICENSE="GPL-2+ "
> LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
> LICENSE+="foo? ( GPL-3+ )"
.. and [then] enforce the ensuing format change via Repoman ..


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Francesco Riosa]

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

Il giorno dom 26 ago 2018 alle ore 20:15 Mart Raudsepp <leio@gentoo.org> ha
scritto:

> Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
> > One thing where this would fail would be e.g.:
> >
> >   LICENSE="GPL-2+
> >     bar? ( GPL-2 )
> >     foo? ( GPL-3+ )" ^ you can't put a comment on the right line
>
> LICENSE="GPL-2+ "
> LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
> LICENSE+="foo? ( GPL-3+ )"
>

Wouldn't this break metadata cache?

[-- Attachment #2: Type: text/html, Size: 840 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Francesco Riosa]

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

please ignore my previous email

>

[-- Attachment #2: Type: text/html, Size: 200 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Jonas Stein]

[-- Attachment #1.1: Type: text/plain, Size: 516 bytes --]

>> 3. make repoman warn whenever non-specific variant is used, telling
>> developers to verify whether it's x-only or x+.

> Repoman could check for a comment in the LICENSE line as well, I guess?

There are already tools to guess licenses in sourcetrees see
"How other projects work with licenses" on
https://wiki.gentoo.org/wiki/Project:Licenses

Such a tool could help a lot to list the potentially wrong LICENSES.
It would be great, if we do not have to invent the wheel again.

-- 
Best,
Jonas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Robin H. Johnson]

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

On Sun, Aug 26, 2018 at 09:43:03PM +0200, Matija Šuklje wrote:
> It is worth noting that the SPDX standard (since 3.0) has indeed changed 
> for the *GPL family of licenses
I've been wondering if we can switch outright to using SPDX-based
expressions inside our USE-flag conditionals. 

For the entries we have in licenses/ that are not presently covered by
SPDX licenses or exceptions, we'll need additions*, but it will shrink
the licenses directory significantly.

* We have some open-source exceptions & closed-source licenses that are not in SPDX
-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Ulrich Mueller]

>>>>> On Sun, 26 Aug 2018, Matija Šuklje wrote:

> It is worth noting that the SPDX standard (since 3.0) has indeed changed 
> for the *GPL family of licenses

> from
> • GPL-2.0, and 
> • GPL-2.0+

> to
> • GPL-2.0-only, and
> • GPL-2.0-or-later

> This was done by request and in coordination with the FSF.

> To quote from <https://spdx.org/licenses/> (under “Deprecated Licenses” 
> header):

>> Release 3.0 replaced previous Identifiers for GNU licenses with more 
>> explicit Identifiers to reflect the "this version only" or "any later 
>> version" option specific to those licenses. As such, the previously 
>> used Identifiers for those licenses are deprecated as of v3.0.

> Note: for all other licenses ‘+’ does the same as before.

So it's "-or-later" for the GPL family but "+" for all others?
That doesn't look like a consistent format to me.

Also, what does "GPL-2.0-or-later" mean? There is no version 2.0 of the
GPL, and by version ordering rules (ours, as well as GNU strverscmp(3)),
"2" is less than "2.0". So GPL version 2 is not matched by it.

> So, if we plan to the latest SPDX spec, we would need to introduce the 
> “-only” and ”-or-later” suffixes regardless.

Ulrich

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Ulrich Mueller]

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

>>>>> On Mon, 27 Aug 2018, Robin H Johnson wrote:

> I've been wondering if we can switch outright to using SPDX-based
> expressions inside our USE-flag conditionals. 

> For the entries we have in licenses/ that are not presently covered by
> SPDX licenses or exceptions, we'll need additions*, but it will shrink
> the licenses directory significantly.

How so? We currently have 740 licenses, but only 18 named *exception*.
That's not much potential for saving, to start with.

> * We have some open-source exceptions & closed-source licenses that
> are not in SPDX

You've answered your own question. :-) The SPDX list has only incomplete
coverage. So in any case, we will need our own labels for a large
fraction of licenses.

Also, what would we do if a license is added to the SPDX list later, but
with a label different from ours? Do we change all our ebuilds then?
What if they change their label between versions of their standard?
They've just proven that their labels aren't guaranteed to be stable,
not even for major licenses like the GPL.

Ulrich

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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Ulrich Mueller]

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

>>>>> On Mon, 27 Aug 2018, Matija Šuklje wrote:

> The GNU family was a special case and it was a very difficult and long 
> discussion/negotiation about it before the consensus was made. It was 
> caused by FSF’s very strong stance on this and the trade-off is that FSF 
> now recommends SPDX as well:
> <https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2>

I wonder what the goal of that is? If someone says "you can redistribute
under GPL version 2" (i.e. if they have removed the "or later" clause
from the boilerplate license notice), it is very clear that it is to be
distributed under GPL version 2 and no other license (like GPL-1, GPL-3,
BSD, CDDL, or any other). So I wonder why RMS's article tries to muddle
that up.

For example, we have "GNU General Public License v2" in all ebuild
headers, and no one has ever challenged that it could mean "v2 or
later". As much as I regret that it doesn't say "or later", I think
there's absolutely no room for interpretation here.

Ulrich

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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michael Mol]

On Sunday, August 26, 2018 7:09:41 AM EDT Paweł Hajdan, Jr. wrote:
> On 26/08/2018 12:53, Mart Raudsepp wrote:
> > The common issue here is that upstream COPYING files really do only
> > talk about one of the versions. And then you get to validate or source
> > files to be sure that they do have a "or later" clause in them. And
> > then on each bump you ideally should validate it again, etc, that no
> > sources without "or later" allowance are in there...
> 
> Yup, precise tracking of license metadata can be a pain.
> 
> I'm not really sure if that level of it is worth for us as a distro. For
> _importing_ other project's source code directly into one's project
> precise license compatibility matters a lot. That's not the scenario
> we're in. I see LICENSES as mostly a mechanism for end users to accept
> or reject EULAs etc, and I'm curious what are other common scenarios.
> 
> Michał, could you elaborate on why not distinguishing more precisely
> between these GPL variants in LICENSES is a _problem_ ? I can certainly
> see the information is not always accurate, but it's not obvious to me
> how severe is the downside, what are the consequences in practice.

I can say that if the licenses are habitually misidentified, I could not use 
Gentoo's portage tree in my job without extensive and ongoing revalidation of 
the license metadata.

There are, in fact, automated tools for advising about the license disposition 
of these types of things, examining source files for unfortunate edits and 
variants and flagging them, etc. It might be an interesting task at some point 
to point some of these tools at portage, look for incorrect metadata and file 
bug reports.

Not suggesting this is a worthwhile approach up front, but it might be a 
useful tool in the future for dealing with license metadata quality as a 
chronic issue. (Which, in turn, is useful for commercial consumption and 
participation.)

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Rich Freeman]

On Mon, Aug 27, 2018 at 6:46 PM Michael Mol <mikemol@gmail.com> wrote:
>
> I can say that if the licenses are habitually misidentified, I could not use
> Gentoo's portage tree in my job without extensive and ongoing revalidation of
> the license metadata.
>

Keep in mind that we're just talking about GPL-2 vs 2+ and GPL-3 vs
3+.  We're not talking about GPL vs BSD vs something that involves a
EULA.

Do you actually accept one of these without the other, such that you
would have problems if they had gotten confused?

-- 
Rich

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Paweł Hajdan, Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 1201 bytes --]

On 28/08/2018 00:46, Michael Mol wrote:
> I can say that if the licenses are habitually misidentified, I could not use 
> Gentoo's portage tree in my job without extensive and ongoing revalidation of 
> the license metadata.
> 
> There are, in fact, automated tools for advising about the license disposition 
> of these types of things, examining source files for unfortunate edits and 
> variants and flagging them, etc. It might be an interesting task at some point 
> to point some of these tools at portage, look for incorrect metadata and file 
> bug reports.
> 
> Not suggesting this is a worthwhile approach up front, but it might be a 
> useful tool in the future for dealing with license metadata quality as a 
> chronic issue. (Which, in turn, is useful for commercial consumption and 
> participation.)

Given the reality of how open source project works, I believe it's up to
people who care/need this most to do such work in Gentoo.

From what I see, nobody would be opposed to _someone_ making the
metadata more precise. On the other hand, I sense most people don't see
enough benefit to sign up for such work themselves - which I totally
understand.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]