[OE-core] [PATCH] license.bbclass base.bbclass: support for 'or' operand in LICENSE and for SPDX license names

Andrei Gherzan andrei at gherzan.ro
Tue Jan 10 18:13:17 UTC 2012


On Tue, Jan 10, 2012 at 18:34, Chris Larson <clarson at kergoth.com> wrote:

> On Tue, Jan 10, 2012 at 9:12 AM, Andrei Gherzan <andrei at gherzan.ro> wrote:
> > No worries. Anyway, you are right about the "+" mechanism but right now
> this
> > is a fast and complete solution.
>
> Indeed, nice work on this.
> --
> Christopher Larson
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

On Tue, Jan 10, 2012 at 19:05, Chris Larson <clarson at kergoth.com> wrote:

> On Tue, Jan 10, 2012 at 9:55 AM, Flanagan, Elizabeth
> <elizabeth.flanagan at intel.com> wrote:
> > Agreed!
>

Thank you.



On Tue, Jan 10, 2012 at 19:05, Chris Larson <clarson at kergoth.com> wrote:

> On Tue, Jan 10, 2012 at 9:55 AM, Flanagan, Elizabeth
> <elizabeth.flanagan at intel.com> wrote:
> > Agreed! One note about "+". There is still a discussion about "or
> > greater" licensing within the SPDX community about how "or greater"
> > should be dealt with.
> >
> >
> http://www.spdx.org/wiki/proposal-2010-11-16-1-or-later-version-licensing
> > https://bugs.linuxfoundation.org/show_bug.cgi?id=591
>
> Interesting.
>
> > I'm partial to, as a stop gap, re-including L/GPL-x.0+ license files
> > into common-licenses until they hash it out and treating "+" as just
> > part of the license name. It's not a perfect solution but it should
> > solve most "or greater" use cases.
>
> I've been thinking about something like this.
>
> LICENSE_EXPANSIONS += "GPL-2.0+:GPL-2.0,GPL-3.0"
>
> Then process the license, turning GPL-2.0+ into an OR operation.
> Replace with (GPL-2.0 | GPL-3.0).
>
> Perhaps coupled with something like https://gist.github.com/1590028 to
> express distributor preferences, we then get a sanitized, SDPX, flat
> string with the licenses we're going to be using for this. Then we run
> this against each binary package's LICENSE (if different than recipe)
> and ensure our emitted binary packages match up with our license
> choices.
> --
> Christopher Larson
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
Christopher's solution crossed my mind as well. Actually i tried something
like this but i didn't want to modify more from this patch and i didn't
really know how to define those expansions.
Another problem here that i faced and dropped the idea for, was the the
scenario where a developer wants to exclude only GPLv3+. This case needed a
another couple of "if"s and so on.

So my solution seemed to deal most of the situations even if it looks a
little... childish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120110/49594b72/attachment-0002.html>


More information about the Openembedded-core mailing list