[gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)

Mounir Lamouri · External Since: May 12, 2009 Posts: 16

Hi,

As you should know, GLEP 23 [1] introduced USE flags conditions in
LICENSE variable and || operator in addition of licenses groups and
ACCEPT_LICENSE variable.

[1] http://www.gentoo.org/proj/en/glep/glep-0023.html

I want to show an issue in ACCEPT_LICENSE that have to be fixed with a
new operator in LICENSE variable.
Imagine we have ACCEPT_LICENSE="GPL-3", every ebuilds without GPL-3 in
LICENSE variable will be filtered even ebuilds with LICENSE="GPL-2" and
a lot of packages are actually GPL-2+, not GPL-2 "strict". That means
they should be shown if ACCEPT_LICENSE="GPL-3".
It's even worst when we try to use ACCEPT_LICENSE to have a free
operating system. Let's suppose 'free' in fsf free and osf free,
LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most
LGPL-2 licensed packages in the tree are LGPL-2+ actually.

So, what I propose is to let a license to be suffixed by the + operator.
In this case, if a newer license is accepted by ACCEPT_LICENSE, the PM
should not filter the package.

I think it's not a hard modification and it will only need an amend to
GLEP 23 (in addition of implementations in PM's).

Thanks,
Mounir

Rémi Cardona · External Since: Dec 09, 2006 Posts: 14

Le 01/09/2009 00:12, Mounir Lamouri a écrit :
> Hi,
>
> As you should know, GLEP 23 [1] introduced USE flags conditions in
> LICENSE variable and || operator in addition of licenses groups and
> ACCEPT_LICENSE variable.
>
> [1] http://www.gentoo.org/proj/en/glep/glep-0023.html

/me still thinks LICENSE should be informational _at_best_. Users who
rely on LICENSE to build an FSF-approved system will simply be mislead.

If we want to support this sort of things properly, we should have a
treewide license audit. Anything short of that will just be a disservice
to our users.

Cheers,

Rémi

Sebastian Pipping · External Since: Aug 02, 2009 Posts: 6

Mounir Lamouri wrote:
> It's even worst when we try to use ACCEPT_LICENSE to have a free
> operating system. Let's suppose 'free' in fsf free and osf free,
> LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most
> LGPL-2 licensed packages in the tree are LGPL-2+ actually.

Are you aware that we have license groups like @FSF-APPROVED?
It's set up in /usr/portage/profiles/license_groups.

> So, what I propose is to let a license to be suffixed by the + operator.
> In this case, if a newer license is accepted by ACCEPT_LICENSE, the PM
> should not filter the package.

My vote is against it. It feels like black magic to me and many
licenses are not versioned, at least not their reference names in Gentoo.

However I do notice that "GPL-2+" could make things easier.
Why not introduce a license group for it like @GPL-2+ or so, instead?
That would be transparent and use existing means.

What do you think?

Sebastian

Duncan · External Since: Jun 05, 2004 Posts: 205

Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted:

> However I do notice that "GPL-2+" could make things easier. Why not
> introduce a license group for it like @GPL-2+ or so, instead? That would
> be transparent and use existing means.

I've always thought Gentoo needed "plus" versions of the versioned
licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be
different licenses, because really, they are.

Then again, there's the various "waiver" conditions, which I /do/ see are
covered with separate licenses for many of them, already.

But someone already mentioned a license audit, which in practical terms
would be needed to really depend on the LICENSE variable in any case.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Mounir Lamouri · External Since: May 12, 2009 Posts: 16

Rémi Cardona wrote:
> Le 01/09/2009 00:12, Mounir Lamouri a écrit :
>> Hi,
>>
>> As you should know, GLEP 23 [1] introduced USE flags conditions in
>> LICENSE variable and || operator in addition of licenses groups and
>> ACCEPT_LICENSE variable.
>>
>> [1] http://www.gentoo.org/proj/en/glep/glep-0023.html
>
> /me still thinks LICENSE should be informational _at_best_. Users who
> rely on LICENSE to build an FSF-approved system will simply be mislead.
>
> If we want to support this sort of things properly, we should have a
> treewide license audit. Anything short of that will just be a
> disservice to our users.
I don't think your argument is valid. LICENSE is not informational so we
have to deal with it and as GLEP-23 has an issue, we should fix it. I
know even with this feature building a free-only system with
ACCEPT_LICENSE will not be easy but the tree cleaning or anything else
is a next step. Let's focus on what we can do now and what I propose is
clearly doable and it will not break anything.

--
Mounir

Mounir Lamouri · External Since: May 12, 2009 Posts: 16

Sebastian Pipping wrote:
> Mounir Lamouri wrote:
>
>> It's even worst when we try to use ACCEPT_LICENSE to have a free
>> operating system. Let's suppose 'free' in fsf free and osf free,
>> LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most
>> LGPL-2 licensed packages in the tree are LGPL-2+ actually.
>>
> Are you aware that we have license groups like @FSF-APPROVED?
> It's set up in /usr/portage/profiles/license_groups.
>
Groups are not fixing the problem even for free aspect. If I have a
package licensed to LGPL-2, it's not free approved but if it's LGPL-2+,
it is. So I can't add LGPL-2 to @FSF-APPROVED, we agree ?

>> So, what I propose is to let a license to be suffixed by the + operator.
>> In this case, if a newer license is accepted by ACCEPT_LICENSE, the PM
>> should not filter the package.
>>
> My vote is against it. It feels like black magic to me and many
> licenses are not versioned, at least not their reference names in Gentoo.
>
> However I do notice that "GPL-2+" could make things easier.
> Why not introduce a license group for it like @GPL-2+ or so, instead?
> That would be transparent and use existing means.
>
> What do you think?
>
I don't understand where the black magic is. I agree not so much
licenses are versioned but they probably are the most used (LGPL, GPL,
MPL, Apache, ...).
GPL-2+ as a group make the filtering with ACCEPT_LICENSE easy (even if
we have to suppose license groups are always up-to-date. However, a
group will not add the information in the ebuild. In other words, I will
have GPL-2 and GPL-3 with GPL-2+ in ACCEPT_LICENSE but I will not have
GPL-2+ packages if i set only GPL-3 in ACCEPT_LICENSE.

Anyway, I've seen an issue for licenses already named foo-NUMBER because
with this feature, PM will consider them as versioned. Not a big deal
for most of them but it could be weird like BSD-2+ to have BSD-2 and BSD-4.
ls | grep -e "-[0123456789.]*$" in the licenses directory to see the
concerned licenses
As it has to come with a new EAPI, we can rename some licenses before.

--
Mounir

Mounir Lamouri · External Since: May 12, 2009 Posts: 16

Duncan wrote:
> Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted:
>
>
>> However I do notice that "GPL-2+" could make things easier. Why not
>> introduce a license group for it like @GPL-2+ or so, instead? That would
>> be transparent and use existing means.
>>
>
> I've always thought Gentoo needed "plus" versions of the versioned
> licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be
> different licenses, because really, they are.
>
AFAIK, GPL-2 and GPL-2+ are not different, may you tell me more about that ?

Thanks,
Mounir

Rémi Cardona · External Since: Dec 09, 2006 Posts: 14

Le 03/09/2009 23:10, Mounir Lamouri a écrit :
> Duncan wrote:
>> Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as excerpted:
>>
>>
>>> However I do notice that "GPL-2+" could make things easier. Why not
>>> introduce a license group for it like @GPL-2+ or so, instead? That would
>>> be transparent and use existing means.
>>>
>>
>> I've always thought Gentoo needed "plus" versions of the versioned
>> licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be
>> different licenses, because really, they are.
>>
> AFAIK, GPL-2 and GPL-2+ are not different, may you tell me more about that ?

GPL-2+ means "GPL-2 GPL-3 GPL-4 ..."

Not quite the same thing as just "GPL-2"

Rémi

Mounir Lamouri · External Since: May 12, 2009 Posts: 16

Rémi Cardona wrote:
> Le 03/09/2009 23:10, Mounir Lamouri a écrit :
>> Duncan wrote:
>>> Sebastian Pipping posted on Tue, 01 Sep 2009 04:21:49 +0200 as
>>> excerpted:
>>>
>>>
>>>> However I do notice that "GPL-2+" could make things easier. Why not
>>>> introduce a license group for it like @GPL-2+ or so, instead? That
>>>> would
>>>> be transparent and use existing means.
>>>>
>>>
>>> I've always thought Gentoo needed "plus" versions of the versioned
>>> licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be
>>> different licenses, because really, they are.
>>>
>> AFAIK, GPL-2 and GPL-2+ are not different, may you tell me more about
>> that ?
>
> GPL-2+ means "GPL-2 GPL-3 GPL-4 ..."
>
> Not quite the same thing as just "GPL-2"
But the content of the license is the same. That only means you can use
a newer one.
I mean we do not need a new license file for that. It's up to upstream
to write somewhere if it's GPL-2 or GPL-2+, am I right ?

--
Mounir

Duncan · External Since: Jun 05, 2004 Posts: 205

Mounir Lamouri posted on Thu, 03 Sep 2009 23:27:34 +0200 as excerpted:

> Rémi Cardona wrote:
>> Mounir Lamouri a écrit :
>>> Duncan wrote:
>>>> Sebastian Pipping posted:
>>>>
>>>>> However I do notice that "GPL-2+" could make things easier. Why not
>>>>> introduce a license group for it like @GPL-2+
>>>>>
>>>> I've always thought Gentoo needed "plus" versions of the versioned
>>>> licenses, anyway. GPL-2, GPL-2+, GPL-3, and GPL-3+, should all be
>>>> different licenses, because really, they are.
>>>>
>>> AFAIK, GPL-2 and GPL-2+ are not different,
>>> may you tell me more about that ?
>>
>> GPL-2+ means "GPL-2 GPL-3 GPL-4 ..."
>>
>> Not quite the same thing as just "GPL-2"

> But the content of the license is the same. That only means you can use
> a newer one. I mean we do not need a new license file for that. It's up
> to upstream to write somewhere if it's GPL-2 or GPL-2+, am I right ?

Let me quote a different reply of yours:

> Groups are not fixing the problem even for free aspect. If I have a
> package licensed to LGPL-2, it's not free approved but if it's LGPL-2+,
> it is. So I can't add LGPL-2 to @FSF-APPROVED, we agree ?

While the license text is the same, but for the condition "or greater"
which may be written before or after the license, as you point out, the
effective difference can be quite large indeed. It's this difference
that in practice, we're worried about here. And our labels don't
specifically mean anything (aren't legally valid) anyway.

Thus, IMO we need a GPL2+ license description (and others similar), which
would incorporate the GPL2 license, with, probably, a clearly delineated
explanation at the top, "Gentoo license note: The authors license these
works under the GPL-2 or later license. Following is the GPL-2 version.
See also GPL-3, etc." Then a line of underscores or the like, clearly
separating that note from the license.

That would eliminate ambiguity and grouping problems such as you mention
above, while, I believe, being legally solid -- as long as our note is
clearly delineated from the actual license.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Rémi Cardona · External Since: Dec 09, 2006 Posts: 14

Le 03/09/2009 23:27, Mounir Lamouri a écrit :
> But the content of the license is the same. That only means you can use
> a newer one.
> I mean we do not need a new license file for that. It's up to upstream
> to write somewhere if it's GPL-2 or GPL-2+, am I right ?

Yes, that's for upstream to figure out. For instance, the kernel is
GPL-2 only while some other pacakges are 2+.

I don't want to sound like an ass, but that's why I think we shouldn't
bother too much with LICENSE and all that stuff.

We're not _lawyers_. None of us can guarantee that :
1) the LICENSE field in our ebuilds are correctly set according to what
upstream says.
2) that the actual code of the package is indeed under that license and
not tainted by some other code.

For instance, I'm still working on migrating all the X11 packages to the
"MIT" license (mainly for cleaning purposes), but in fact, each and
every package should have its own license file (like today) because the
MIT license requires that we acknowledge all major contributions to the
code. Therefore, using a template like ${PORTAGE}/licences/MIT does is
probably not a good idea from a legal point of view.

And the X code being over 15 years old, only God knows who we should be
thanking for this million lines of code.

While you're idea is very nice on paper, actually doing it requires much
_much_ more work than just adding operators and sets to portage.

Rémi

Jeremy Olexa · External Since: Aug 12, 2009 Posts: 5

On Mon, Aug 31, 2009 at 5:12 PM, Mounir Lamouri<volkmar.RemoveThis@gentoo.org> wrote:

> It's even worst when we try to use ACCEPT_LICENSE to have a free
> operating system.

FWIW: Given the state of ebuilds, I think this should never be
attempted unless the user knows it may not be accurate[1]. We should
not attempt to guarantee such statement, IMO.

> LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most
> LGPL-2 licensed packages in the tree are LGPL-2+ actually.

How are we, the non-lawyer types, suppose to know that? TBH, I don't
care and am not going to put much effort beyond reading the header of
COPYING or glancing at the HOMEPAGE to see what license they are
using. I think you are attempting to add much complexity to ebuilds
that will ultimately fail. Of course, you can volunteer to audit every
license and every ebuild. Thanks in advance for that =P

Thanks for putting work into making Gentoo better, I just am not
convinced on this subject.

-Jeremy

[1]: Look at how long bug 268796 took to get resolved. 4 months,
rather quickly too. Ebuilds stated GPL-2, when they were in fact BSD,
GPL-3, LGPL-2.

David Leverton · External Since: Apr 01, 2009 Posts: 6

On Friday 04 September 2009 16:01:41 RÃ©mi Cardona wrote:
> For instance, I'm still working on migrating all the X11 packages to the
> "MIT" license (mainly for cleaning purposes), but in fact, each and
> every package should have its own license file (like today) because the
> MIT license requires that we acknowledge all major contributions to the
> code. Therefore, using a template like ${PORTAGE}/licences/MIT does is
> probably not a good idea from a legal point of view.

Is that really a problem? I admit to not being around for the original design
decisions, but I would assume that the purpose of having LICENSE in ebuilds
is to tell users what licence the package is under (whether or not it's
accurate is a different matter), and the purpose of having the licences
themselves in the tree is so that it's easy for users to look them up and
decide whether they want to accept the conditions or not. For that purpose,
the exact list of credits is irrelevant. Also, I'm not a lawyer, but I would
think that the licence's requirement for credit is satisfied by the credits
being included in the source code - it doesn't require acknowledgement when
merely talking about the software or stating the fact that it's under a
particular licence, just when distributing it.

Rémi Cardona · External Since: Dec 09, 2006 Posts: 14

Le 04/09/2009 20:52, David Leverton a écrit :
> Is that really a problem?

To me, it's not. Smile

> I admit to not being around for the original design
> decisions, but I would assume that the purpose of having LICENSE in ebuilds
> is to tell users what licence the package is under (whether or not it's
> accurate is a different matter), and the purpose of having the licences
> themselves in the tree is so that it's easy for users to look them up and
> decide whether they want to accept the conditions or not. For that purpose,
> the exact list of credits is irrelevant.

That was just an example to show that unless we go through a precise and
thorough audit of all the packages we offer, the LICENSE variable is
_informational_ at best.

Having tools to manipulate those variables is very misleading since
users will (rightfully) assume that we've done our homework and that
upstream did too.

I don't intend to stop anyone from creating new tools, but I just want
us all to realize the limits of what is being done here.

Cheers,

Rémi

Sebastian Pipping · External Since: Aug 02, 2009 Posts: 6

Mounir Lamouri wrote:
>> However I do notice that "GPL-2+" could make things easier.
>> Why not introduce a license group for it like @GPL-2+ or so, instead?
>> That would be transparent and use existing means.
>>
> I don't understand where the black magic is.

It would be in the implementation and in the non-transparency.
How can a user understabnd that "GPL-2+" refers to a group of license
files but "GPL-2" refers to a single file? He may guess but it's not
obvious, especially if it hasn#t been like that in the past, which is
the case.

> However, a
> group will not add the information in the ebuild. In other words, I will
> have GPL-2 and GPL-3 with GPL-2+ in ACCEPT_LICENSE but I will not have
> GPL-2+ packages if i set only GPL-3 in ACCEPT_LICENSE.

I propose support for license groups in ebuilds then, I guess.

Sebastian

Zac Medico · External Since: Mar 06, 2006 Posts: 71

Sebastian Pipping wrote:
>> However, a
>> group will not add the information in the ebuild. In other words, I will
>> have GPL-2 and GPL-3 with GPL-2+ in ACCEPT_LICENSE but I will not have
>> GPL-2+ packages if i set only GPL-3 in ACCEPT_LICENSE.
>
> I propose support for license groups in ebuilds then, I guess.

That seems like a reasonable solution. So, an ebuild can do
something like LICENSE="@GPL-2+" and that will expand to whatever
the definition of the GPL-2+ license group happens to be. When a new
version of GPL license comes out, we simple add it to that group,
and none of the corresponding ebuilds have to be updated.

--
Thanks,
Zac

Duncan · External Since: Jun 05, 2004 Posts: 205

Zac Medico posted on Fri, 04 Sep 2009 18:06:09 -0700 as excerpted:

> That seems like a reasonable solution. So, an ebuild can do something
> like LICENSE="@GPL-2+" and that will expand to whatever the definition
> of the GPL-2+ license group happens to be. When a new version of GPL
> license comes out, we simple add it to that group, and none of the
> corresponding ebuilds have to be updated.

That sounds like a very good EAPI-4 candidate. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Ulrich Mueller · External Since: May 13, 2007 Posts: 27

>>>>> On Fri, 04 Sep 2009, Zac Medico wrote:
>> I propose support for license groups in ebuilds then, I guess.

> That seems like a reasonable solution. So, an ebuild can do
> something like LICENSE="@GPL-2+" and that will expand to whatever
> the definition of the GPL-2+ license group happens to be.

So "@GPL-2+" would (currently) expand to "GPL-2 GPL-3". But that would
be wrong, since what you want is "|| ( GPL-2 GPL-3 )".

Ulrich

Zac Medico · External Since: Mar 06, 2006 Posts: 71

Ulrich Mueller wrote:
>>>>>> On Fri, 04 Sep 2009, Zac Medico wrote:
>>> I propose support for license groups in ebuilds then, I guess.
>
>> That seems like a reasonable solution. So, an ebuild can do
>> something like LICENSE="@GPL-2+" and that will expand to whatever
>> the definition of the GPL-2+ license group happens to be.
>
> So "@GPL-2+" would (currently) expand to "GPL-2 GPL-3". But that would
> be wrong, since what you want is "|| ( GPL-2 GPL-3 )".

Right, so naturally, license groups inside LICENSE should expand to
|| ( licenses in group ).

--
Thanks,
Zac

Mounir Lamouri · External Since: May 12, 2009 Posts: 16

Zac Medico wrote:
> Sebastian Pipping wrote:
>
>> I propose support for license groups in ebuilds then, I guess.
>>
> That seems like a reasonable solution. So, an ebuild can do
> something like LICENSE="@GPL-2+" and that will expand to whatever
> the definition of the GPL-2+ license group happens to be. When a new
> version of GPL license comes out, we simple add it to that group,
> and none of the corresponding ebuilds have to be updated.
>
I suppose adding group license support in ebuilds will fix the problem
too. But I see a few disadvantages like:
- new behavior for @ operator: it will not only expand a group but also
adding a || operator (only for LICENSE)
- devs will have to maintain new groups
- group support in LICENSE has no other need that managing versioned
licenses
In an other hand, it will prevent us adding a new operator.
And Sébastian, I don't understand you when you said GPL-2+ will be
confusing for the user as it's a term commonly used in the FOSS world.
But if everybody think groups are better, that will be fine.

For those who think this feature is useless because we are not lawyers
and ebuilds don't care about licenses, I just want to add it will not be
a new _requirement_ but a new _possibility_. As Ciaran's said, you
already have to check for licenses at the moment. So even if some devs
do mistake (or do not update the info) as said Jeremy, we have at least
this information. If you know a package is GPL-2 licensed, you can set
LICENSE="GPL-2", it's valid, IMO. If you want to go far than that and
check if it's GPL-2+, it's better but not _needed_.
It's a small feature and it can help.

Thanks,
Mounir