* LICENSE_{X}-xxx is parsed?
@ 2012-04-24 17:25 Andrei Gherzan
2012-04-24 17:44 ` Flanagan, Elizabeth
0 siblings, 1 reply; 9+ messages in thread
From: Andrei Gherzan @ 2012-04-24 17:25 UTC (permalink / raw)
To: openembedded
[-- Attachment #1: Type: text/plain, Size: 758 bytes --]
Hello everybody,
Is there any mechanism of parsing LICENSE variables for every provided
package in a bb file?
To be a little more clear about this.
If i have an app named myapp. Let's say the myapp_1.0.bb includes:
LICENSE = "GPLv3 & LGPLv2.1"
LICENSE_${PN} = LGPLv2.1
LICENSE_${PN} -tests = GPLv3
If this app is not whitelisted, this file will pe ignored (assuming
INCOMPATIBLE_LICENSE = GPLv3) even if the only needed package on the final
fs is the ${PN} package.
For files in these case (like gnults) we use right now WHITELIST. In this
way license checking on those packages is skipped.
If nobody works on this (or this is already done but i couldn't spot it in
the code) i can dig and propose a way to solve this issue.
@g
[-- Attachment #2: Type: text/html, Size: 1004 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: LICENSE_{X}-xxx is parsed? 2012-04-24 17:25 LICENSE_{X}-xxx is parsed? Andrei Gherzan @ 2012-04-24 17:44 ` Flanagan, Elizabeth 2012-04-24 21:15 ` Andrei Gherzan 0 siblings, 1 reply; 9+ messages in thread From: Flanagan, Elizabeth @ 2012-04-24 17:44 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, Apr 24, 2012 at 10:25 AM, Andrei Gherzan <andrei@gherzan.ro> wrote: > Hello everybody, > > Is there any mechanism of parsing LICENSE variables for every provided > package in a bb file? > > To be a little more clear about this. > > If i have an app named myapp. Let's say the myapp_1.0.bb includes: > LICENSE = "GPLv3 & LGPLv2.1" > LICENSE_${PN} = LGPLv2.1 > LICENSE_${PN} -tests = GPLv3 > > If this app is not whitelisted, this file will pe ignored (assuming > INCOMPATIBLE_LICENSE = GPLv3) even if the only needed package on the final > fs is the ${PN} package. > As you have package level licensing set, it will actually check the LICENSE_${PN}. See: bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and use the PN level license to determine if it should be excluded. If no PN level exists it should fall back to LICENSE > For files in these case (like gnults) we use right now WHITELIST. In this > way license checking on those packages is skipped. > > If nobody works on this (or this is already done but i couldn't spot it in > the code) i can dig and propose a way to solve this issue. > > @g > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > -- Elizabeth Flanagan Yocto Project Build and Release ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: LICENSE_{X}-xxx is parsed? 2012-04-24 17:44 ` Flanagan, Elizabeth @ 2012-04-24 21:15 ` Andrei Gherzan 2012-04-24 21:25 ` Andrei Gherzan 2012-04-24 22:38 ` Flanagan, Elizabeth 0 siblings, 2 replies; 9+ messages in thread From: Andrei Gherzan @ 2012-04-24 21:15 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1915 bytes --] On Tue, Apr 24, 2012 at 20:44, Flanagan, Elizabeth < elizabeth.flanagan@intel.com> wrote: > On Tue, Apr 24, 2012 at 10:25 AM, Andrei Gherzan <andrei@gherzan.ro> > wrote: > > Hello everybody, > > > > Is there any mechanism of parsing LICENSE variables for every provided > > package in a bb file? > > > > To be a little more clear about this. > > > > If i have an app named myapp. Let's say the myapp_1.0.bb includes: > > LICENSE = "GPLv3 & LGPLv2.1" > > LICENSE_${PN} = LGPLv2.1 > > LICENSE_${PN} -tests = GPLv3 > > > > If this app is not whitelisted, this file will pe ignored (assuming > > INCOMPATIBLE_LICENSE = GPLv3) even if the only needed package on the > final > > fs is the ${PN} package. > > > > As you have package level licensing set, it will actually check the > LICENSE_${PN}. See: > bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and > use the PN level > license to determine if it should be excluded. If no PN level exists > it should fall back to LICENSE > > I realize this but still, what about the rest for packages provided in a bb file? > > For files in these case (like gnults) we use right now WHITELIST. In > this > > way license checking on those packages is skipped. > > > > If nobody works on this (or this is already done but i couldn't spot it > in > > the code) i can dig and propose a way to solve this issue. > > > > @g > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > > -- > Elizabeth Flanagan > Yocto Project > Build and Release > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > [-- Attachment #2: Type: text/html, Size: 3082 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: LICENSE_{X}-xxx is parsed? 2012-04-24 21:15 ` Andrei Gherzan @ 2012-04-24 21:25 ` Andrei Gherzan 2012-04-24 22:38 ` Flanagan, Elizabeth 1 sibling, 0 replies; 9+ messages in thread From: Andrei Gherzan @ 2012-04-24 21:25 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 2146 bytes --] Digging into your commit i realized that this is already done. Thank you. @g On Wed, Apr 25, 2012 at 00:15, Andrei Gherzan <andrei@gherzan.ro> wrote: > On Tue, Apr 24, 2012 at 20:44, Flanagan, Elizabeth < > elizabeth.flanagan@intel.com> wrote: > >> On Tue, Apr 24, 2012 at 10:25 AM, Andrei Gherzan <andrei@gherzan.ro> >> wrote: >> > Hello everybody, >> > >> > Is there any mechanism of parsing LICENSE variables for every provided >> > package in a bb file? >> > >> > To be a little more clear about this. >> > >> > If i have an app named myapp. Let's say the myapp_1.0.bb includes: >> > LICENSE = "GPLv3 & LGPLv2.1" >> > LICENSE_${PN} = LGPLv2.1 >> > LICENSE_${PN} -tests = GPLv3 >> > >> > If this app is not whitelisted, this file will pe ignored (assuming >> > INCOMPATIBLE_LICENSE = GPLv3) even if the only needed package on the >> final >> > fs is the ${PN} package. >> > >> >> As you have package level licensing set, it will actually check the >> LICENSE_${PN}. See: >> bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and >> use the PN level >> license to determine if it should be excluded. If no PN level exists >> it should fall back to LICENSE >> >> > I realize this but still, what about the rest for packages provided in a > bb file? > > >> > For files in these case (like gnults) we use right now WHITELIST. In >> this >> > way license checking on those packages is skipped. >> > >> > If nobody works on this (or this is already done but i couldn't spot it >> in >> > the code) i can dig and propose a way to solve this issue. >> > >> > @g >> > _______________________________________________ >> > Openembedded-core mailing list >> > Openembedded-core@lists.openembedded.org >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> > >> >> >> >> -- >> Elizabeth Flanagan >> Yocto Project >> Build and Release >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> > > [-- Attachment #2: Type: text/html, Size: 3628 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: LICENSE_{X}-xxx is parsed? 2012-04-24 21:15 ` Andrei Gherzan 2012-04-24 21:25 ` Andrei Gherzan @ 2012-04-24 22:38 ` Flanagan, Elizabeth 2012-04-24 22:53 ` Chris Larson 1 sibling, 1 reply; 9+ messages in thread From: Flanagan, Elizabeth @ 2012-04-24 22:38 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, Apr 24, 2012 at 2:15 PM, Andrei Gherzan <andrei@gherzan.ro> wrote: > On Tue, Apr 24, 2012 at 20:44, Flanagan, Elizabeth > <elizabeth.flanagan@intel.com> wrote: >> >> On Tue, Apr 24, 2012 at 10:25 AM, Andrei Gherzan <andrei@gherzan.ro> >> wrote: >> > Hello everybody, >> > >> > Is there any mechanism of parsing LICENSE variables for every provided >> > package in a bb file? >> > >> > To be a little more clear about this. >> > >> > If i have an app named myapp. Let's say the myapp_1.0.bb includes: >> > LICENSE = "GPLv3 & LGPLv2.1" >> > LICENSE_${PN} = LGPLv2.1 >> > LICENSE_${PN} -tests = GPLv3 >> > >> > If this app is not whitelisted, this file will pe ignored (assuming >> > INCOMPATIBLE_LICENSE = GPLv3) even if the only needed package on the >> > final >> > fs is the ${PN} package. >> > >> >> As you have package level licensing set, it will actually check the >> LICENSE_${PN}. See: >> bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and >> use the PN level >> license to determine if it should be excluded. If no PN level exists >> it should fall back to LICENSE >> > > I realize this but still, what about the rest for packages provided in a bb > file? The rest of the packages in the bb should be inheriting LICENSE if no PN level license is set. Which obviously causes problems for the above example. In a case like above you'd want to do either of the following: a. Call out each package's license individually (better but can be painful for recipes with lots of packages) b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so undefined package level licensing inherits the correct LICENSE. I'd personally do the first choice as it's cleaner. -b > >> >> > For files in these case (like gnults) we use right now WHITELIST. In >> > this >> > way license checking on those packages is skipped. >> > >> > If nobody works on this (or this is already done but i couldn't spot it >> > in >> > the code) i can dig and propose a way to solve this issue. >> > >> > @g >> > _______________________________________________ >> > Openembedded-core mailing list >> > Openembedded-core@lists.openembedded.org >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> > >> >> >> >> -- >> Elizabeth Flanagan >> Yocto Project >> Build and Release >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > -- Elizabeth Flanagan Yocto Project Build and Release ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: LICENSE_{X}-xxx is parsed? 2012-04-24 22:38 ` Flanagan, Elizabeth @ 2012-04-24 22:53 ` Chris Larson 2012-04-24 23:13 ` Flanagan, Elizabeth 0 siblings, 1 reply; 9+ messages in thread From: Chris Larson @ 2012-04-24 22:53 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth <elizabeth.flanagan@intel.com> wrote: > The rest of the packages in the bb should be inheriting LICENSE if no > PN level license is set. Which obviously causes problems for the above > example. > > In a case like above you'd want to do either of the following: > > a. Call out each package's license individually (better but can be > painful for recipes with lots of packages) > b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so > undefined package level licensing inherits the correct LICENSE. I wonder if a partially specified set of individual package settings should be identified by some sanity check (an explicit, rather than implicit, one, like recipe_sanity) as a potential bug / source of confusion. I suspect most of the time it should be one or the other, either no individual package LICENSEs are defined, or they all should be. -- Christopher Larson ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: LICENSE_{X}-xxx is parsed? 2012-04-24 22:53 ` Chris Larson @ 2012-04-24 23:13 ` Flanagan, Elizabeth 2012-04-25 8:17 ` Richard Purdie 0 siblings, 1 reply; 9+ messages in thread From: Flanagan, Elizabeth @ 2012-04-24 23:13 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, Apr 24, 2012 at 3:53 PM, Chris Larson <clarson@kergoth.com> wrote: > On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth > <elizabeth.flanagan@intel.com> wrote: >> The rest of the packages in the bb should be inheriting LICENSE if no >> PN level license is set. Which obviously causes problems for the above >> example. >> >> In a case like above you'd want to do either of the following: >> >> a. Call out each package's license individually (better but can be >> painful for recipes with lots of packages) >> b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so >> undefined package level licensing inherits the correct LICENSE. > > I wonder if a partially specified set of individual package settings > should be identified by some sanity check (an explicit, rather than > implicit, one, like recipe_sanity) as a potential bug / source of > confusion. It's something I've been thinking heavily about how over the past few month. How to implement full package level license support without requiring too many recipe changes. The current setup licensing moves us in the right direction, without having to do too many recipe changes, but there are some inadequacies in it and we may have to address them sooner or later. > I suspect most of the time it should be one or the other, > either no individual package LICENSEs are defined, or they all should > be. I would tend to agree. One thing I think we may want to start considering (even if it does make me cringe a bit) is that if we go this route, we may want to support LIC_SRC_URI_${PN} as well. It means quite a few recipe changes, but it yet another step in more accurate license auditing. -b > -- > Christopher Larson > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Elizabeth Flanagan Yocto Project Build and Release ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: LICENSE_{X}-xxx is parsed? 2012-04-24 23:13 ` Flanagan, Elizabeth @ 2012-04-25 8:17 ` Richard Purdie 2012-04-25 16:04 ` Flanagan, Elizabeth 0 siblings, 1 reply; 9+ messages in thread From: Richard Purdie @ 2012-04-25 8:17 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, 2012-04-24 at 16:13 -0700, Flanagan, Elizabeth wrote: > On Tue, Apr 24, 2012 at 3:53 PM, Chris Larson <clarson@kergoth.com> wrote: > > On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth > > <elizabeth.flanagan@intel.com> wrote: > >> The rest of the packages in the bb should be inheriting LICENSE if no > >> PN level license is set. Which obviously causes problems for the above > >> example. > >> > >> In a case like above you'd want to do either of the following: > >> > >> a. Call out each package's license individually (better but can be > >> painful for recipes with lots of packages) > >> b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so > >> undefined package level licensing inherits the correct LICENSE. > > > > I wonder if a partially specified set of individual package settings > > should be identified by some sanity check (an explicit, rather than > > implicit, one, like recipe_sanity) as a potential bug / source of > > confusion. > > It's something I've been thinking heavily about how over the past few > month. How to implement full package level license support without > requiring too many recipe changes. The current setup licensing moves > us in the right direction, without having to do too many recipe > changes, but there are some inadequacies in it and we may have to > address them sooner or later. I like the idea that LICENSE is the default and is used where no other LICENSE is set. If our LICENSE field building code is clever enough to be able to find any LICENSE_xxx variables that are set now, we could just define LICENSE to be the default LICENSE unless something else is set. It would then be up to the license handling code to create the xxx & xxx expressions where needed. This keeps things simpler for the recipes but still gets us where we need to be. I don't think forcing users to set LICENSE for every subpackage will be particularly useful, nor is having the top LICENSE field being a complete summary when we could calculate that. > > I suspect most of the time it should be one or the other, > > either no individual package LICENSEs are defined, or they all should > > be. > > I would tend to agree. One thing I think we may want to start > considering (even if it does make me cringe a bit) is that if we go > this route, we may want to support LIC_SRC_URI_${PN} as well. It means > quite a few recipe changes, but it yet another step in more accurate > license auditing. Please, no ;-). Do something like the SRC_URI checksums (name the urls, then apply extra information to them, or use parameters in the urls. Cheers, Richard ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: LICENSE_{X}-xxx is parsed? 2012-04-25 8:17 ` Richard Purdie @ 2012-04-25 16:04 ` Flanagan, Elizabeth 0 siblings, 0 replies; 9+ messages in thread From: Flanagan, Elizabeth @ 2012-04-25 16:04 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Wed, Apr 25, 2012 at 1:17 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Tue, 2012-04-24 at 16:13 -0700, Flanagan, Elizabeth wrote: >> On Tue, Apr 24, 2012 at 3:53 PM, Chris Larson <clarson@kergoth.com> wrote: >> > On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth >> > <elizabeth.flanagan@intel.com> wrote: >> >> The rest of the packages in the bb should be inheriting LICENSE if no >> >> PN level license is set. Which obviously causes problems for the above >> >> example. >> >> >> >> In a case like above you'd want to do either of the following: >> >> >> >> a. Call out each package's license individually (better but can be >> >> painful for recipes with lots of packages) >> >> b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so >> >> undefined package level licensing inherits the correct LICENSE. >> > >> > I wonder if a partially specified set of individual package settings >> > should be identified by some sanity check (an explicit, rather than >> > implicit, one, like recipe_sanity) as a potential bug / source of >> > confusion. >> >> It's something I've been thinking heavily about how over the past few >> month. How to implement full package level license support without >> requiring too many recipe changes. The current setup licensing moves >> us in the right direction, without having to do too many recipe >> changes, but there are some inadequacies in it and we may have to >> address them sooner or later. > > I like the idea that LICENSE is the default and is used where no other > LICENSE is set. If our LICENSE field building code is clever enough to > be able to find any LICENSE_xxx variables that are set now, we could > just define LICENSE to be the default LICENSE unless something else is > set. It would then be up to the license handling code to create the xxx > & xxx expressions where needed. > > This keeps things simpler for the recipes but still gets us where we > need to be. I don't think forcing users to set LICENSE for every > subpackage will be particularly useful, nor is having the top LICENSE > field being a complete summary when we could calculate that. > I don't necessarily disagree, however, it is a change to how that field has been historically used from my understanding. If people are fine with using it that way, let's document it, let everyone know about it and start looking at which recipes need to be updated to do it correctly. >> > I suspect most of the time it should be one or the other, >> > either no individual package LICENSEs are defined, or they all should >> > be. >> >> I would tend to agree. One thing I think we may want to start >> considering (even if it does make me cringe a bit) is that if we go >> this route, we may want to support LIC_SRC_URI_${PN} as well. It means >> quite a few recipe changes, but it yet another step in more accurate >> license auditing. > > Please, no ;-). Do something like the SRC_URI checksums (name the urls, > then apply extra information to them, or use parameters in the urls. Ahhh, yes. That's a much better idea. :) -b > > Cheers, > > Richard > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Elizabeth Flanagan Yocto Project Build and Release ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-04-25 16:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-24 17:25 LICENSE_{X}-xxx is parsed? Andrei Gherzan
2012-04-24 17:44 ` Flanagan, Elizabeth
2012-04-24 21:15 ` Andrei Gherzan
2012-04-24 21:25 ` Andrei Gherzan
2012-04-24 22:38 ` Flanagan, Elizabeth
2012-04-24 22:53 ` Chris Larson
2012-04-24 23:13 ` Flanagan, Elizabeth
2012-04-25 8:17 ` Richard Purdie
2012-04-25 16:04 ` Flanagan, Elizabeth
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.