Re: [OE-core][PATCH v2 00/25] Rework LICENSE to be SPDX License Expressions

[Paul Barker <paul@pbarker.dev>]

[-- Attachment #1: Type: text/plain, Size: 4239 bytes --]

On Wed, 2026-07-15 at 10:44 -0600, Joshua Watt via
lists.openembedded.org wrote:
> Reworks the way that the LICENSE variable is used so that it uses valid
> SPDX License Expressions instead of the custom expressions that were
> used previously (which are based on Python syntax). This includes
> support for the SPDX "WITH" operator which allows a license exception to
> be attached to a license identifier.
> 
> The old licenses expressions are still allowed, and will still be
> correctly parsed, however a warning will be issued that indicates the
> new license string that should be used.
> 
> Most layers should be able to use the newly-revised
> scripts/contrib/convert-spdx-licenses.py script to do the majority of
> the conversion work, although some manual work may still be required if
> conditional or complex LICENSE expressions are encountered.
> 
> SPDX License Expressions require that all licenses listed are either a
> known identifier (e.g. "GPL-2.0-or-later") or start with the prefix
> "LicenseRef-" which indicates a custom license. When converting from old
> expressions to new one this will need to be followed (the suggested new
> license in the warning and the conversion script will automatically add
> this prefix for any unrecognized license identifiers). This will most
> commonly be the case for NO_GENERIC_LICENSE files; for a good example of
> what needs to be done here see the changes to the linux-firmware recipe.
> When adding new LicenseRef- licenses to a recipe, the actual license
> name should be prefixed with the name of the recipe (e.g.
> "LicenseRef-myrecipe-mylicense") to prevent conflicts when merging
> multiple license documents together (e.g. in an image).
> 
> SPDX also introduces the "WITH" operator to add an exception to a
> license instead of using a bespoke identifier to combine the two, as was
> done with the legacy license expressions. Because of this, the logic for
> dealing with the INCOMPATIBLE_LICENSE family of variables has changed
> slightly. The main difference is that INCOMPATIBLE_LICENSE will now
> match the LHS of a "WITH" expression (where as previously this was
> "ignored" since it was a bespoke license ID). In order to allow a
> license that would normally be rejected, but can be allowed with an
> exception, specifically allowed exceptions can be added to the
> INCOMPATIBLE_LICENSE_EXCEPTIONS variable (keep in mind, EXCEPTIONS here
> means "exceptions to INCOMPATIBLE_LICENSES", not specifically SPDX
> License Exceptions). If an SPDX exception is present here, any license
> that has that exception will be allowed, even if it would normally match
> INCOMPATIBLE_LICENSE. For example, to disallow all GPLv3 except for
> those with the GCC exception, use:
> 
>     INCOMPATIBLE_LICENSE = "GPL-3.0* LGPL-3.0*"
>     INCOMPATIBLE_LICENSE_EXCEPTIONS = "GCC-exception-3.1" # This new line is required
> 
> 
> Additionally, "PD" ("Public Domain") is not allowed as a generic license
> identifier. Aside from "PD" not being a valid SPDX License Identifier,
> most "Public Domain" licenses do have some sort of text associated with
> them (see the HPND family of SPDX Licenses, or use the (SPDX License
> Match Website)[1] ). In addition, the meaning of "Public Domain" can vary
> by jurisdiction, so the actual text with a LicenseRef- or a SPDX License
> Identifier needs to be used instead.
> 
> Finally, "CLOSED" is also no longer allowed as a license expression
> (since it is not a valid SPDX License Identifier). Instead use a
> LicenseRef- to point to a file that contains the actual license text
> (usually something like "Copyright <name>, all rights reserved")

Hi Joshua,

I've had a skim through but not reviewed in detail, this looks good in
general.

I'm concerned about removing support for "CLOSED" as a license
expression though, that has been used extensively on downstream projects
I've worked on over the years. It's helpful to be able to bypass license
checking where it may not be needed.

After applying this series there is still handling for "CLOSED" in
several places such as populate_lic_qa_checksum() in insane.bbclass.

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]