Re: INCOMPATIBLE_LICENSE mechanism

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Thursday, 26 July 2018 5:14:05 PM BST Richard Purdie wrote:
> On Thu, 2018-07-26 at 13:16 +0000, Peter Kjellerstedt wrote:
> > This is related to a similar problem we are seeing with the use of
> > “or” for licenses. We use the archiver.bbclass to export all open
> > source code we use. However, for recipes that specify multiple
> > licenses using “or”, we would like to specify the one under which we
> > are using the code. E.g., if the LICENSE is “GPL-2.0 | Proprietary”,
> > we would like to treat the code as “Proprietary”, but when it comes
> > to the archiver.bbclass, even if we have told it to ignore packages
> > with Proprietary licenses, it will include the package due to the
> > alternative GPL-2.0 license.
> >  
> > The idea we have is to allow to specify a USED_LICENSE (e.g., in a
> > bbappend or a separate configuration file), which should take the
> > actually used license. This should be verified to be one of the
> > allowed licenses specified in LICENSE (in case LICENSE changes and no
> > longer allows the chosen license), and after that, LICENSE should be
> > treated as if this was the value it had been given. This does,
> > however,  not take into account the use of the same package in
> > multiple images with different licensing requirements (we only build
> > one image so that is not a problem for us).
> 
> Just thinking out loud you could have something like a 
> 
> gplv3-license-incompatible.inc:
> 
> LICENSE_pn-<some-recipe> = "MIT"
> LICENSE_pn-<some--other-recipe> = "GPLv2"
> INCOMPATIBLE_LICENSE = "GPLv3"

That was my first thought, but the issue is that you won't get any warning in 
future if the LICENSE value within the recipe changes to no longer provide the 
option you've selected. 

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre