On Thu, Mar 18, 2021, Richard Purdie <richard.purdie@...> wrote:
[...]

The worry is something like:

# SPDX-License-Identifier: MIT
LICENSE = "GPLv2 & bzip2-1.0.4"

makes for very confusing reading and can be badly interpreted.

FWIW, I have been involved with quite a few license audits for Yocto-
based products and this is already a source of confusion as it is: in
many cases knowing if a license applies to the recipe or to the package
being built by the recipe is far from obvious.

My first reaction and suggestion would be to forego using SPDX-License-
Identifier in recipes and instead to use a new variable in a recipe for
this such as this:

RECIPE_LICENSE = "MIT"
LICENSE = "GPLv2 & bzip2-1.0.4"

And if you need to have a separate license variable for patches:
PATCHES_LICENSE = "MIT"

This would be explicit, clear and nicely integratable in your tooling
IMHO. Ideally of course you'd want the content of these to be valid SPDX
license expressions. Until then I will have to have a mapping and
special detector for [1] to properly collect normalized SPDX licenses
from recipes.

And FYI while I have your attention:

We are adding support to handle Yocto recipes in ScanCode-toolkit [1]
and [2] for license and origin detection. This involves parsing and
"resolving" recipes which is not trivial without running bitbake. This
is done thanks to Konrad Weihmann (in CC:) who kindly extracted his
excellent linting-focused recipe parser in a separate library [3].

[1] https://github.com/nexB/scancode-toolkit/issues/1243
[2] https://github.com/nexB/scancode-toolkit/pull/2443
[3] https://github.com/priv-kweihmann/oelint-parser

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com