[yocto] Automated license incompatibility checks

[Paul Eggleton]

Hi Clemens,

On Wednesday 28 January 2015 09:52:14 Clemens Lang wrote:
> I have written a bbclass that does license conflict checking before
> building images for distribution. I am wondering if that is something
> you as a project would be interested in integrating, e.g. into poky.
> 
> I am also looking for feedback to my approach and ideas on how to handle
> corner cases, such as the OpenSSL exception. To give you a short and
> rough overview and to avoid wasting your time with a code review before
> we discussed the general approach, here's the commit message for my
> 
> local change implementing this:
> > Implement automatic license conflict checking as QA check. This check
> > adds a hook to the do_rootfs task, gathers a list of packages to be
> > installed into the root file system, their licenses and dependency
> > relations. It then walks this list and removes all licenses or part of
> > license expressions that are not satisfiable using licenses from a
> > configurable whitelist. For example,
> > 
> >   (GPL-3.0 & LGPL-3.0+) | GPL-2.0
> > 
> > with a whitelist of "GPL-2.0" will be transformed to
> > 
> >   GPL-2.0
> > 
> > before running license conflict checking. This ensures none of the
> > licenses you don't want to distribute in your image is required to
> > fulfill all license constraints.
> > 
> > Afterwards, each package's license is checked against those of its
> > dependencies one by one. To detect conflicts, the two license
> > expressions are converted into conjunctive normal form, concatenated
> > with all relevant license conflicts read from a configuration file and
> > handed over to a SAT solver (currently minisat via the satispy python
> > library). If the solver indicates the expression is satisfiable, there
> > is no license conflict. If the expression cannot be solved, the
> > licenses conflict.

This sounds like something we should be handling in our INCOMPATIBLE_LICENSE 
check code, although it's not clear that we currently handle where 
alternatives to an incompatible license are available for a recipe/package, so 
that looks like it would be new functionality. You haven't mentioned 
INCOMPATIBLE_LICENSE - does your solution build on that, or replace it?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre