On Wed, Jul 15, 2026 at 11:11 AM Paul Barker <[email protected]> wrote:
> 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.
>
My reason for getting rid of it was along the same lines as trying to get
rid of "PD" as a license; there is certainly some license text that is
relevant, and the exact text might vary by jurisdiction so having a single
identifier that tries to lump it all together may not be a good idea. For
example, in the US, I might have something like "Copyright Joshua Watt, all
rights reserved". It should be noted that a LicenseRef- licenses can
reference something in a layer LICENSE_DIR, so I can for example create a
file named "JoshuaProprietaryLicense" in my layer, then use
"LicenseRef-JoshuaProprietaryLicense" in my LICENSE expression to refer to
it as necessary. We _could_ potentially make a "CLOSED" file in oe-core
with the text "All rights reserved" in it, then recipes could use
"LicenseRef-CLOSED" in it; but that strays into legal territory and I don't
really want to assume that's the correct "closed" license text in all
jurisdictions.
CLOSED is not a valid SPDX license identifier, so it can't really be
propagated around in SPDX license expressions. That said, if we want to
treat the line 'LICENSE = "CLOSED"' to effectively mean "no license" (where
you simply get no SPDX license expression when you parse it) that should be
doable.
>
> After applying this series there is still handling for "CLOSED" in
> several places such as populate_lic_qa_checksum() in insane.bbclass.
>
Some of them are kept around for compatibility with "legacy" license
expressions, and some I probably just missed.
>
> Best regards,
>
> --
> Paul Barker
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#241032):
https://lists.openembedded.org/g/openembedded-core/message/241032
Mute This Topic: https://lists.openembedded.org/mt/120285146/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
