[OE-core] LICENSE_{X}-xxx is parsed?

[Flanagan, Elizabeth]

On Tue, Apr 24, 2012 at 2:15 PM, Andrei Gherzan <andrei at gherzan.ro> wrote:
> On Tue, Apr 24, 2012 at 20:44, Flanagan, Elizabeth
> <elizabeth.flanagan at intel.com> wrote:
>>
>> On Tue, Apr 24, 2012 at 10:25 AM, Andrei Gherzan <andrei at 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 at 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 at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
Elizabeth Flanagan
Yocto Project
Build and Release