On Wed, Jul 15, 2026 at 11:56 AM Joshua Watt <[email protected]> wrote:
> > > 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. > FWIW, the code was already really close to doing this. I implemented it quickly here: https://git.openembedded.org/openembedded-core-contrib/commit/?h=jpew/spdx-licenses&id=7f9837f6ca5b016610674d3ed72f4572990f087d so see if that makes sense. > > >> >> 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 (#241035): https://lists.openembedded.org/g/openembedded-core/message/241035 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]] -=-=-=-=-=-=-=-=-=-=-=-
