On Fri, 2021-02-19 at 11:13 +0100, Quentin Schulz wrote: > Hi Richard, > > On Thu, Feb 18, 2021 at 04:56:40PM +0000, Richard Purdie wrote: > > Where a user adds "GPLv3" to INCOMPATIBLE_LICENSE they almost certainly > > mean both GPLv3-only and GPLv3-or-later. Update the code to handle this > > correctly. > > > > Signed-off-by: Richard Purdie <[email protected]> > > --- > > meta/classes/license.bbclass | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/meta/classes/license.bbclass b/meta/classes/license.bbclass > > index 358c716a801..be8541f20dc 100644 > > --- a/meta/classes/license.bbclass > > +++ b/meta/classes/license.bbclass > > @@ -281,6 +281,12 @@ def expand_wildcard_licenses(d, wildcard_licenses): > > wildcards from SPDXLICENSEMAP flags and AVAILABLE_LICENSES. > > """ > > import fnmatch > > + > > + # Assume if we're passed "GPLv3" it means -or-later as well > > + for lic in wildcard_licenses[:]: > > + if "*" not in lic and not lic.endswith(("-or-later", "-only")): > > + wildcard_licenses.append(lic + "-or-later") > > + > > This means that "GPLv3" will have a different meaning in recipes than in > INCOMPATIBLE_LICENSE. > > Can't we just force users to use an original SPDX (the one which ends > with -or-later or -only) instead for INCOMPATIBLE_LICENSE? This would > probably be as simple as looking if the license is in SPDXLICENSEMAP > varflags keys? > > This feels less hacky to me.
I'm torn on this, I don't think there is a perfect solution. If a user has GPLv3 in INCOMPATIBLE_LICENSE they invariably mean GPLv3* so after the recent changes, a load of GPLv3+ could "escape" into their build. That is a particularly bad scenario which I felt was worth catching. If a user really did want to exclude GPLv3-only, they can write that and it would work. In the last round of testing after I sent this patch, I found that there is also *GPLv3 which the above tweak doesn't currently work with (it really should mean *GPLv3*). I haven't decided what to do about it. I did send a patch for the GPLv2 layer which uses this but I'm torn. The main issue is that the commonly used values for this variable won't work correctly without some kind of code change and the breakage is important/bad, probably worth more to catch than being a bit hacky... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#148343): https://lists.openembedded.org/g/openembedded-core/message/148343 Mute This Topic: https://lists.openembedded.org/mt/80734227/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
