This email describes a suggested implementation of LICENSE<br>
functionality and standards that will correct some issues within the<br>
licensing infrastructure of OE-Core. It discusses a LICENSE standard,<br>
both for license names and operators within the field and touches on<br>
some issues with regards to how license.bbclass and other classes<br>
utilize LICENSE. It suggests a path forward in correcting those issues<br>
and finally, it describes future enhancements to the license<br>
functionality that will give more accurate manifests and make<br>
OE-Core's license functionality much more useful.<br>
<br>
Overview<br>
===========<br>
I've identified a few known issues with how LICENSE is implemented and<br>
used, as well as standards issues:<br>
<br>
- Some LICENSE fields have non-versioned LICENSE values in which no<br>
meaning can actually be deduced from them. An example of this is<br>
references to GPL or LGPL without a version number. This currently<br>
throws a bb.warn.<br>
<br>- A few LICENSE fields contain values for licenses that have no<br>
generic license text.<br>
<br>- The LICENSE parser currently does not utilize operators. It grabs<br>
all licenses mentioned within the LICENSE field. The plan is to<br>
implement LICENSE priority, which will utilize field operators.<br>
However, there seems to be no definition around how operators are<br>
actually used nor does there exist an agreed upon standard.<br>
<br>- A few LICENSE fields have unparsable values.<br>
<br>- In most cases, LICENSE is set for the recipe, however, a recipe that<br>
contains multiple packages, all of whom may have a distinct LICENSE,<br>
would throw an inaccurate LICENSE into the manifest. We've seen a few<br>
examples of LICENSE_<package_name>, but it is a rare occurrence.<br>
<br>- The LICENSE operands need to be dealt with through a license<br>
priority map. The plan is to implement this within the next few weeks.<br>
<br>- There are currently two sets of names used within recipes. One, is<br>
an undocumented but commonly used naming convention. The other is a<br>
standard created by the SPDX project. The current OE-Core license<br>
functionality does support compatibility with the OE naming<br>
conventions so end users do not have to change their common LICENSE<br>
definitions, however, a documented standard should be implemented and<br>
a plan forward created.<br>
<br>
<br>
Proposed Solutions<br>
================<br>
<br>
Decide on a standard.<br>
------------------------------<div id=":11v"><br>
I would suggest that new recipes follow the SPDX naming convention<br>
with support for the OE convention maintained for a period of time (my<br>
suggestions is 24 months to enable layer maintainers to update with<br>
warnings turned on if this RFC is adopted). LICENSE fields not<br>
following SPDX should be corrected as they are audited.<br>
<br>
Adopting SPDX will do a few things for us:<br>
<br>
- This will allow us to support an open source project dedicated to<br>
license standards, allowing us to leverage their work and expertise.<br>
<br>- It will also allow us to support recipes that use (or are planning<br>
to use) the SPDX standard .<br>
<br>- It gets us out of the business of maintaining a licensing standard.<br>
<br>
While we could always spend time hashing out the OE standard (and from<br>
my searching, I've not seen it documented anywhere, other than a few<br>
places via email archives), I feel this is the wrong path.<br>
<br>
The requirements for this should be:<br><br>
- Any work done with LICENSES within OE-Core or Yocto must maintain<br>
backwards compatibility with the OE naming convention. If SPDX is decided up,<br>
we should maintain backwards compatibility for a period of time. My<br>
suggested timeline for removal of that compatibility is 24 months.<br>
<br>
LICENSE audit<br>
----------------------<br>
Some LICENSE fields are either unparsable, have no version when one is<br>
required (GPL/GPL-2.0), or are factually wrong. I would suggest we<br>
spend time auditing these fields over the next few months using the<br>
following guidelines<br>
<br>
- All LICENSE fields must be ast parsable.<br>
<br>- All LICENSE fields should be updated to whatever standard is decided<br>
upon and documented, with mapping for other conventions for a period<br>
of time<br>
<br>- All LICENSE fields should support<br>
<br>- If a LICENSE field references a non-existent common-license, we<br>
either add the common-license or ask the author if we may be permitted<br>
to license under a generic (see less for an example).<br>
<br>- We should actually split common-licenses into spdx-licenses and<br>
alternative-licenses. This will allow us to pull license text from<br>
SPDX and maintain spdx-licenses as a pure form of the provided<br>
licenses. There is already a bug opened with the SPDX group to provide<br>
some sore of repository for this. Additional licenses that are non-OSI<br>
compliant (like Adobe's free license) should be moved to<br>
alternative-licenses. Licenses that are OSI compliant should be<br>
upstreamed to SPDX.<br>
<br>
For licenses that are non-OSI compliant, I would suggest we use the SPDX format:<br>
<br>
Where there is a specified version of the license:<br>
<LICENSE_ABBREVIATION>-<VERSION><br>
Example: AFL-1.3<br>
<br>
Where no specified version of the license exists:<br>
<LICENSE_ABBREVIATION><br>
Example: Adobe<br>
<br>
Field Operators<br>
----------------------<br>
The LICENSE parser currently does not act upon Field Operators. It<br>
grabs all licenses mentioned within the LICENSE field. The plan is to<br>
implement LICENSE priority, which will utilize field these operators<br>
and decides on the correct license based on priority. For example, if<br>
we were to weight BSD as a higher priority than GPL-2.0, when the<br>
parser hit "BSD | GPL-2.0" it would use BSD for the package. However,<br>
there seems to be no clear definition around how field operators are<br>
used.<br>
<br>
I would suggest the following:<br>
<br>
& : This package/recipe includes multiple files with different<br>
licenses. These licenses must be included together<br>
<br>
| : This package/recipe is dual licensed.<br>
<br>
+ : This package/recipe has a voluntary upgrade path<br>
<br>
() : Used to group licenses decision parameters.<br>
<br>
Examples:<br>
<br>
LICENSE = “GPL-2.0+”<br>
Meaning: This recipe may be licensed as GPL-2.0 or any greater license<br>
<br>
LICENSE = “(BSD & LGPL-2.0) | (GPL-2.0+ & LGPL-2.0)”<br>
LICENSE = “(BSD | GPL-2.0+) & LGPL-2.0”<br>
<br>
Meaning: This recipe may be licensed as either BSD and LGPL-2.0 or<br>
GPL-2.0 or greater and LGPL-2.0. The parser should support both ways<br>
of writing this.<br>
<br>
I've seen reference to "/" and "&&" and ",". I don't see a purpose for these<br>
operators and short of a clear need, I would suggest their removal.<br>
<br>
Recipe-level Licensing<br>
-------------------------------<br>
LICENSE is generally set for the recipe, however, a recipe that<br>
contains multiple packages, all of whom may have a distinct LICENSE,<br>
would throw an inaccurate LICENSE. We've seen a few examples of<br>
LICENSE_${PN}, but it is a rare occurrence. During the audit, I would<br>
suggest that:<br>
<br>
- Recipes be corrected, if need.<br>
- license and emit_pkg_data and anything that utilizes LICENSE be<br>
fixed to take package level LICENSE_${PN} into account.<div class="yj6qo ajU"><div id=":133" class="ajR" tabindex="0"><img class="ajT" src="images/cleardot.gif"></div></div></div>