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
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
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
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
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
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
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+
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.
On Mon, Aug 31, 2009 at 5:12 PM, Mounir Lamourivolk...@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
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
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
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
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
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
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
15 matches
Mail list logo
