Re: Proposal: INCOMPATIBLE_LICENSE_EXCEPTION


Richard Purdie
 

On Fri, 2022-02-18 at 11:41 -0800, Saul Wold wrote:
As a follow-on to yesterday's email and replies, I would like to make
the following proposal for dealing with the changes to
INCOMPATIBLE_LICENSE and associated variables.

Current Usage:

INCOMPATIBLE_LICENSE is a list of licenses that are considered
incompatible with a distro's requirements. This is used to compare
against packages built by a given recipe.

A set of exception variables based on the license name (currently
WHITELIST_<license>) that contains a list of recipes that will be
checked against the current recipe (PN) being evaluated. If it's in
that list then all packages in that recipe will be built and included
and the rest of the evaluation will be skipped.

Otherwise, the packages (PKGS) from the recipe will be evaluated to see
if any have a package specific license (LICENSE:<pkgname>). If a package
has a license other than the INCOMPATIBLE_LICENSE the recipe will be
built and any packages with the INCOMPATIBLE_LICENSE will be excluded
from being packaged in package.bbclass via LICENSE_EXCLUSION-<pkgname>
internal variable.

The exception is predominately used for GPLv3 related packages, based on
the emails replies overnight.


Proposal:

Keep the existing INCOMPATIBLE_LICENSE variable with the same behavior.
The values in INCOMPATIBLE_LICENSE should be SDPX normalized license
strings.

As Richard has already suggested an alternative variable that is more
meaningful: INCOMPATIBLE_LICENSE_EXCEPTION with an a <pkg>:<spdx_lic>
value. Rename the LICENSE_EXCLUSION-<pkg> variable to make it clear that
it is an internal variable. The usage of the _EXCEPTION variable should
contain pkg names not recipe name. ** This would be an important change **

Clean up code as appropriate to ensure the exceptions are handled once
and identified during parsing.

I will start working on the implementation, Monday is a holiday in the
US, so this should give sometime for this to be reviewed for Tuesday.
Thanks Saul, from my perspective I think this is a good balance between cleaning
up the syntax and other issues whilst being practical to implement and test in
the time frames available.

Cheers,

Richard

Join openembedded-architecture@lists.openembedded.org to automatically receive all group messages.