What follow is a proposal to allow our recipe LICENSE variable to be
interpreted as valid SPDX licenses expressions; as proposed the LICENSE
variables would not need to be mass converted to SPDX expressions immediately,
as there would be code in place to do a conversion from the current LICENSE
value to a valid SPDX expression.
The changes are as follows:
* There is a defined conversion for a legacy LICENSE string to a valid SPDX
expression. The conversion algorithm works as follows:
1. "&" is replaced with " AND "
2. "|" is replaced with " OR "
3. Conversion of legacy license IDs to SPDX IDs is done based on the
contents of SPDXLICENSEMAP
4. The resulting string is parsed into an SPDX abstract syntax tree,
with any unknown license identifiers preserved in the AST.
5. Any license identifiers in the resulting SPDX expression that are
not in the list of known SPDX licenses are converted to license
references (e.g. Identifiers that start with "LicenseRef-").
Any code that needs to interpret the meaning of a license string will
perform this conversion, allowing it to deal with the SPDX AST for
processing. Note that passing a license string that is already a SPDX
expression will not cause any issues, as the conversion will be a no-op in
that case and simply return the parsed AST.
* A check will be added that parses LICENSE with the above algorithm, then
converts the AST back to a string. If that string doesn't matching the
contents of LICENSE, a warning will be issued telling the user that
LICENSE is a legacy LICENSE string which needs upgraded, and will provide
the string that should be used in its place.
* For any recipes that use only known SPDX license identifiers, replacing
LICENSE with the suggested string is all that needs to be done. The only
special considerations are for recipes that end up with license references
(those that start with "LicenseRef-"). These fall into two categories:
* For bespoke recipe licenses (those that set NO_GENERIC_LICENSE), the
key in the NO_GENERIC_LICENSE variable needs to be changed to match
the new license name (with the "LicenseRef-" removed). In most cases,
this means no changes are necessary, however SPDX also doesn't allow
"_" in license names, so those are converted to "-". For example, if
a recipe has:
LICENSE = "MIT & my_bespoke"
NO_GENERIC_LICENSE[my_bespoke] = "LICENSE.txt"
it would be converted to:
LICENSE = "MIT AND LicenseRef-my-bespoke"
NO_GENERIC_LICENSE[my-bespoke] = "LICENSE.txt"
It's also suggested that these bespoke licenses have the recipe name
encoded in them (e.g. "LicenseRef-${PN}-my-bespoke") so as to prevent
conflicts with other recipe bespoke licenses or common licenses when
merging licenses.
* For non-SPDX licenses that are provided by layers as "common" licenses
(e.g. those that do not set NO_GENERIC_LICENSE), they will mostly work
as-is as the code will search for a matching license filename based on
the license name (with the "LicenseRef-" prefix removed). The only
consideration here is that the license file itself might need to be
renamed, since SPDX does not allow "_" in the license name. For
example, if a recipe has:
LICENSE = "MIT & my_common_license"
it would be converted to:
LICENSE = "MIT AND LicenseRef-my-common-license"
and there must be a file named "my-commmon-license" in the license
file search path.
* License exceptions can now be included using "WITH", for example:
LICENSE = "GPL-2.0-only WITH Linux-syscall-note"
There is no legacy operator that corresponds to "WITH", but it can be
mixed with the legacy "&" and "|" operators (although this should be
avoided in favor of upgrading to a valid SPDX license expression).
Mappings can be provided for the legacy expressions that had exceptions in
SPDXLICENSEMAP to allow the legacy license IDs to be continued to be used,
for example:
SPDXLICENSEMAP[GPL-2.0-with-Linux-syscall-note] =
"GPL-2.0-only WITH Linux-syscall-note"
* "CLOSED" is still allowed as a license type, but is deprecated and cannot
be combined with any other license type (e.g. "CLOSED AND GPL-2.0-only" is
not allowed). These should all be converted to use a bespoke license
reference instead (e.g. "LicenseRef-${PN}-closed" + NO_GENERIC_LICENSE),
even if that bespoke license text just states e.g. "Copyright John Doe.
All rights reserved".
It should be possible to write a script that does mass conversion of LICENSE
variables on a given layer that will cover most recipes correctly; the only
ones that would need manual cleanup after that would be the ones where the
license reference was converted from "_" to "-"
The general transition plan is to allow legacy LICENSE variables for now but
have the warning that prompts layer owners to update the license strings. At
some point in the future (decided by the TSC, but preferably no later than the
6.3 release), the use of legacy LICENSE strings would no longer be allowed and
only valid SPDX license expression strings would be allowed. This would in
turn allow a few things to be cleaned up (such as the removal of
SPDXLICENSEMAP).
Aside from having well formed license expressions that are compatible with
other tooling, one large benefit of converting to SPDX licenses is that it
makes it immediately obvious when a recipe is using a license that almost
certainly needs review by a lawyer, since non-SPDX licenses are always
prefixed with "LicenseRef-".
As an aside, in the process of looking through this I noticed several places
where we could make improvements to our license hygiene. I'm not proposing we
make these changes immediately, but I do think they should be cleaned up
sooner rather than later:
* Much like the "CLOSED" license, the "Proprietary" license should probably
be deprecated and removed in favor of a bespoke license
* The usage of the "PD" (Public Domain) license has a lot of variation, and
this particular license should also be deprecated and removed. I found
several recipes with the "PD" license that were actual "Public Domain with
restrictions", and even one that was actually Creative Commons Public
Domain. Several of these are using licenses that have valid SPDX
identifiers (see the HPND family), or even worse are a bespoke wording of
some license (usual HPND). On top of all this, the legally meaning of
Public Domain varies by jurisdiction, so lumping many different licenses
with different wording as "PD" is not ideal. My recommendation would be
remove "PD" as a valid license and instead either use a known SPDX
identifier, or have the recipe list its license as a bespoke license ref
(e.g. LicenseRef- + NO_GENERIC_LICENSE).
* While I realize this is perhaps controversial and not all layers can do
this, I would like openembedded-core to eventually remove all its non-SPDX
generic licenses. This means all licenses in oe-core would contain only
valid SPDX identifier, or a bespoke license (LicenseRef- +
NO_GENERIC_LICENSE). The reason that I think this makes sense for oe-core
is that it puts a defined limit on what (generic) licenses oe-core will
maintain; specifically, we would only maintain licenses files for the
licenses that the SPDX lawyers think are deserving of a SPDX license
identifier. Other layers are of course still free to introduce non-SPDX
generic licenses as that capability is not being removed (and, I know from
experience is utilized heavily by BSPs)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2359):
https://lists.openembedded.org/g/openembedded-architecture/message/2359
Mute This Topic: https://lists.openembedded.org/mt/119533872/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
