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.

Reply via email to