Mailing List Archive

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

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

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

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

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

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

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

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

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

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

On Mon, Aug 31, 2009 at 5:12 PM, Mounir Lamouri<volkmar@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.

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.

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

To me, it's not. :)

> 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

On Fri, 04 Sep 2009 22:04:46 +0200
Rémi Cardona <remi@gentoo.org> wrote:
> 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.

Why not use EAPI 4 to make sure people have done that homework then?

--
Ciaran McCreesh

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

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

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

>>>>> 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

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

On Friday 04 of September 2009 22:08:02 Ciaran McCreesh wrote:
> On Fri, 04 Sep 2009 22:04:46 +0200

> Rémi Cardona <remi@gentoo.org> wrote:
> > 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.

> Why not use EAPI 4 to make sure people have done that homework then?

Because it won't make *upstream* do their homework.
I suppose you volunteer to make this homework for Gentoo to fulfill new EAPI
requirements as I assume your lawyer skills equals the will to propose yet
another EAPI.
Therefore I fully support this idea.

--
regards
MM

On Sat, 5 Sep 2009 16:03:25 +0200
Maciej Mrozowski <reavertm@poczta.fm> wrote:
> > Why not use EAPI 4 to make sure people have done that homework then?
>
> Because it won't make *upstream* do their homework.

If upstream won't tell you the licence under which something is
distributed, how does Gentoo know whether it's allowed to mirror source
tarballs or include the package on binary CDs?

--
Ciaran McCreesh

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

>>>>> On Sat, 05 Sep 2009, Mounir Lamouri wrote:

> 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

IMHO the main disadvantage is that ebuilds would have to be converted
to EAPI-4 for this, which is quite an effort for a very small
improvement. And I guess that there are quite a few packages currently
labelled as GPL-2 that are really "GPL 2 or later".

> But if everybody think groups are better, that will be fine.

I would prefer a pragmatic solution, like adding new licence files
as suggested in [1].

Ulrich

[1] <http://archives.gentoo.org/gentoo-dev/msg_6c004fd342c57062d71455109fa52ac0.xml>

Mounir Lamouri wrote:
> 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)

It's just a natural thing to do, given the use case, so I'm not sure
that I'd consider it a "disadvantage".

> - devs will have to maintain new groups

It actually has potential ease maintenance because of the "code
sharing" aspect. You only have to update the group definition in
order to update all consumers of the group.

> - group support in LICENSE has no other need that managing versioned
> licenses

Not necessarily. I can imagine other cases where the "code sharing"
aspect might be useful. Also, imagine a case such as a version
range. Doing that with operators could get messy, but it's quite
simple using groups. Considering that licenses tend to have
relatively few versions (compared to packages, for example),
operators might introduce unnecessary complexity while not having
the flexibility that groups have.
--
Thanks,
Zac