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

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

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

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

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

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

Ulrich Mueller wrote:
> IMHO the main disadvantage is that ebuilds would have to be converted
> to EAPI-4 for this,

Why do they _have_ to? I understand that it's optional and that we can
take time with it until a new license (e.g. GPL-4) arrives.
Also, scripts/tools can help with the transition.

> which is quite an effort for a very small
> improvement.

- It's reducing future maintenance costs on new license arrival
- It's adding clarity and allows us to express the actual license
of "GPL 2 or later" packages much better.
- It increases chances of correct labeling of future ebuilds

Sebastian

Rémi_Cardona · External Since: Dec 10, 2004 Posts: 20

Le 06/09/2009 02:34, Thomas Anderson a écrit :
> Ciaran's really not making homework up for gentoo. Why, remi stated himself that
> we have homework to do(and we sometimes don't do that homework)

I did, but I also stated upstream might have some homework to do
themselves. Here's a list of things that :

- COPYING automagically copied by automake (that would make the file
be GPL-2+ or GPL-3+)
- code "stolen" from other projects under a non-compatible/viral license
- bundled libraries
- code that's so old, no-one really knows what the original license
(XFree86/Xorg) is or who the copyright holders are (Mozilla)

And I haven't even had my morning coffee yet.

Even if _we_ do our homework, all those reasons above might mislead us
into thinking a package has license ABC, while in fact it's under
license ABC+ and XYZ.

I don't see how a new EAPI will help us with all the aforementioned
issues. And for the proposed LICENSE sets to work correctly, the whole
tree needs to be audited, and each new _version_ of each package needs
to be rigorously checked if we want to provide something users can _trust_.

Cheers,

Rémi

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

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. 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 made a bug from that so it doesn't get lost.

https://bugs.gentoo.org/show_bug.cgi?id=287192

Sebastian

volkmar · External Since: Oct 01, 2009 Posts: 2

On Thu, Oct 01, 2009 at 04:01:29AM +0200, Sebastian Pipping wrote:
> 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. 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 made a bug from that so it doesn't get lost.
>
> https://bugs.gentoo.org/show_bug.cgi?id=287192

Actually, it's not lost. I've write a patch for the GLEP-23 and I'm
waiting for an answer from the glep team.

--
Mounir