On 28/08/2018 00:46, Michael Mol wrote:
> I can say that if the licenses are habitually misidentified, I could not use
> Gentoo's portage tree in my job without extensive and ongoing revalidation of
> the license metadata.
>
> There are, in fact, automated tools for advising about the license
On Mon, Aug 27, 2018 at 6:46 PM Michael Mol wrote:
>
> I can say that if the licenses are habitually misidentified, I could not use
> Gentoo's portage tree in my job without extensive and ongoing revalidation of
> the license metadata.
>
Keep in mind that we're just talking about GPL-2 vs 2+ and
On Sunday, August 26, 2018 7:09:41 AM EDT Paweł Hajdan, Jr. wrote:
> On 26/08/2018 12:53, Mart Raudsepp wrote:
> > The common issue here is that upstream COPYING files really do only
> > talk about one of the versions. And then you get to validate or source
> > files to be sure that they do have a
> On Mon, 27 Aug 2018, Matija Šuklje wrote:
> The GNU family was a special case and it was a very difficult and long
> discussion/negotiation about it before the consensus was made. It was
> caused by FSF’s very strong stance on this and the trade-off is that FSF
> now recommends SPDX as
> On Mon, 27 Aug 2018, Robin H Johnson wrote:
> I've been wondering if we can switch outright to using SPDX-based
> expressions inside our USE-flag conditionals.
> For the entries we have in licenses/ that are not presently covered by
> SPDX licenses or exceptions, we'll need additions*,
> On Sun, 26 Aug 2018, Matija Šuklje wrote:
> It is worth noting that the SPDX standard (since 3.0) has indeed changed
> for the *GPL family of licenses
> from
> • GPL-2.0, and
> • GPL-2.0+
> to
> • GPL-2.0-only, and
> • GPL-2.0-or-later
> This was done by request and in coordination
On Sun, Aug 26, 2018 at 09:43:03PM +0200, Matija Šuklje wrote:
> It is worth noting that the SPDX standard (since 3.0) has indeed changed
> for the *GPL family of licenses
I've been wondering if we can switch outright to using SPDX-based
expressions inside our USE-flag conditionals.
For the
>> 3. make repoman warn whenever non-specific variant is used, telling
>> developers to verify whether it's x-only or x+.
> Repoman could check for a comment in the LICENSE line as well, I guess?
There are already tools to guess licenses in sourcetrees see
"How other projects work with licenses"
please ignore my previous email
>
Il giorno dom 26 ago 2018 alle ore 20:15 Mart Raudsepp ha
scritto:
> Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
> > One thing where this would fail would be e.g.:
> >
> > LICENSE="GPL-2+
> > bar? ( GPL-2 )
> > foo? ( GPL-3+ )" ^ you can't put a comment on the
On 26/08/18 19:14, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
>> One thing where this would fail would be e.g.:
>>
>> LICENSE="GPL-2+
>> bar? ( GPL-2 )
>> foo? ( GPL-3+ )" ^ you can't put a comment on the right line
> LICENSE="GPL-2+ "
>
Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
> One thing where this would fail would be e.g.:
>
> LICENSE="GPL-2+
> bar? ( GPL-2 )
> foo? ( GPL-3+ )" ^ you can't put a comment on the right line
LICENSE="GPL-2+ "
LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
On Sun, 2018-08-26 at 17:50 +0200, Ulrich Mueller wrote:
> > > > > > On Sun, 26 Aug 2018, Michał Górny wrote:
> > 1. introducing additional *-only licenses that explicitly indicate
> > that a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
>
> I don't like this at all, because
On 26/08/2018 13:15, Michał Górny wrote:
> I'm not aware of any major implications. However, I think that if we
> provide for the distinction, the distinction should be used correctly.
Makes sense.
Note that this might also be an argument for _not_ providing such
fine-grained distinction
> On Sun, 26 Aug 2018, Michał Górny wrote:
> 1. introducing additional *-only licenses that explicitly indicate
> that a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
I don't like this at all, because LICENSE="GPL-2" means exactly the
above, namely GPL version 2, no later
On Sun, Aug 26, 2018 at 7:15 AM Michał Górny wrote:
>
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > On 26/08/2018 12:53, Mart Raudsepp wrote:
> > > The common issue here is that upstream COPYING files really do only
> > > talk about one of the versions. And then you get to
On 2018.08.26 12:15, Michał Górny wrote:
> On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> > On 26/08/2018 12:53, Mart Raudsepp wrote:
> > > The common issue here is that upstream COPYING files really do
> only
> > > talk about one of the versions. And then you get to validate or
>
On Sun, 2018-08-26 at 13:09 +0200, Paweł Hajdan, Jr. wrote:
> On 26/08/2018 12:53, Mart Raudsepp wrote:
> > The common issue here is that upstream COPYING files really do only
> > talk about one of the versions. And then you get to validate or source
> > files to be sure that they do have a "or
On 26/08/2018 12:53, Mart Raudsepp wrote:
> The common issue here is that upstream COPYING files really do only
> talk about one of the versions. And then you get to validate or source
> files to be sure that they do have a "or later" clause in them. And
> then on each bump you ideally should
Ühel kenal päeval, P, 26.08.2018 kell 12:39, kirjutas Michał Górny:
> Hi,
>
> It seems that we suffer a major problem of developers wrongly
> attributing *GPL-[23] licenses to ebuilds, when the correct variant
> is
> *GPL-[23]+. In proxy-maint, every second new package with
> LICENSE=GPL-
> [23]
Hi,
It seems that we suffer a major problem of developers wrongly
attributing *GPL-[23] licenses to ebuilds, when the correct variant is
*GPL-[23]+. In proxy-maint, every second new package with LICENSE=GPL-
[23] is plain wrong. I suspect part of the problem is that GitHub has
poor man's
21 matches
Mail list logo
