[OE-core] [RFC] LICENSE Standards

[Flanagan, Elizabeth]

This email describes a suggested implementation of LICENSE
functionality and standards that will correct some issues within the
licensing infrastructure of OE-Core. It discusses a LICENSE standard,
both for license names and operators within the field and touches on
some issues with regards to how license.bbclass and other classes
utilize LICENSE. It suggests a path forward in correcting those issues
and finally, it describes future enhancements to the license
functionality that will give more accurate manifests and make
OE-Core's license functionality much more useful.

Overview
===========
I've identified a few known issues with how LICENSE is implemented and
used, as well as standards issues:

- Some LICENSE fields have non-versioned LICENSE values in which no
meaning can actually be deduced from them. An example of this is
references to GPL or LGPL without a version number. This currently
throws a bb.warn.

- A few LICENSE fields contain values for licenses that have no
generic license text.

- The LICENSE parser currently does not utilize operators. It grabs
all licenses mentioned within the LICENSE field. The plan is to
implement LICENSE priority, which will utilize field operators.
However, there seems to be no definition around how operators are
actually used nor does there exist an agreed upon standard.

- A few LICENSE fields have unparsable values.

- In most cases, LICENSE is set for the recipe, however, a recipe that
contains multiple packages, all of whom may have a distinct LICENSE,
would throw an inaccurate LICENSE into the manifest. We've seen a few
examples of LICENSE_<package_name>, but it is a rare occurrence.

- The LICENSE operands need to be dealt with through a license
priority map. The plan is to implement this within the next few weeks.

- There are currently two sets of names used within recipes. One, is
an undocumented but commonly used naming convention. The other is a
standard created by the SPDX project. The current OE-Core license
functionality does support compatibility with the OE naming
conventions so end users do not have to change their common LICENSE
definitions, however, a documented standard should be implemented and
a plan forward created.


Proposed Solutions
================

Decide on a standard.
------------------------------

I would suggest that new recipes follow the SPDX naming convention
with support for the OE convention maintained for a period of time (my
suggestions is 24 months to enable layer maintainers to update with
warnings turned on if this RFC is adopted). LICENSE fields not
following SPDX should be corrected as they are audited.

Adopting SPDX will do a few things for us:

- This will allow us to support an open source project dedicated to
license standards, allowing us to leverage their work and expertise.

- It will also allow us to support recipes that use (or are planning
to use) the SPDX standard .

- It gets us out of the business of maintaining a licensing standard.

While we could always spend time hashing out the OE standard (and from
my searching, I've not seen it documented anywhere, other than a few
places via email archives), I feel this is the wrong path.

The requirements for this should be:

- Any work done with LICENSES within OE-Core or Yocto must maintain
backwards compatibility with the OE naming convention. If SPDX is decided
up,
we should maintain backwards compatibility for a period of time. My
suggested timeline for removal of that compatibility is 24 months.

LICENSE audit
----------------------
Some LICENSE fields are either unparsable, have no version when one is
required (GPL/GPL-2.0), or are factually wrong. I would suggest we
spend time auditing these fields over the next few months using the
following guidelines

- All LICENSE fields must be ast parsable.

- All LICENSE fields should be updated to whatever standard is decided
upon and documented, with mapping for other conventions for a period
of time

- All LICENSE fields should support

- If a LICENSE field references a non-existent common-license, we
either add the common-license or ask the author if we may be permitted
to license under a generic (see less for an example).

- We should actually split common-licenses into spdx-licenses and
alternative-licenses. This will allow us to pull license text from
SPDX and maintain spdx-licenses as a pure form of the provided
licenses. There is already a bug opened with the SPDX group to provide
some sore of repository for this. Additional licenses that are non-OSI
compliant (like Adobe's free license) should be moved to
alternative-licenses. Licenses that are OSI compliant should be
upstreamed to SPDX.

For licenses that are non-OSI compliant, I would suggest we use the SPDX
format:

Where there is a specified version of the license:
<LICENSE_ABBREVIATION>-<VERSION>
Example: AFL-1.3

Where no specified version of the license exists:
<LICENSE_ABBREVIATION>
Example: Adobe

Field Operators
----------------------
The LICENSE parser currently does not act upon Field Operators. It
grabs all licenses mentioned within the LICENSE field. The plan is to
implement LICENSE priority, which will utilize field these operators
and decides on the correct license based on priority. For example, if
we were to weight BSD as a higher priority than GPL-2.0, when the
parser hit "BSD | GPL-2.0" it would use BSD for the package. However,
there seems to be no clear definition around how field operators are
used.

I would suggest the following:

& : This package/recipe includes multiple files with different
licenses. These licenses must be included together

| : This package/recipe is dual licensed.

+ : This package/recipe has a voluntary upgrade path

() : Used to group licenses decision parameters.

Examples:

LICENSE = “GPL-2.0+”
Meaning: This recipe may be licensed as GPL-2.0 or any greater license

LICENSE = “(BSD & LGPL-2.0) | (GPL-2.0+ & LGPL-2.0)”
LICENSE = “(BSD | GPL-2.0+) & LGPL-2.0”

Meaning: This recipe may be licensed as either BSD and LGPL-2.0 or
GPL-2.0 or greater and LGPL-2.0. The parser should support both ways
of writing this.

I've seen reference to "/" and "&&" and ",". I don't see a purpose for these
operators and short of a clear need, I would suggest their removal.

Recipe-level Licensing
-------------------------------
LICENSE is generally set for the recipe, however, a recipe that
contains multiple packages, all of whom may have a distinct LICENSE,
would throw an inaccurate LICENSE. We've seen a few examples of
LICENSE_${PN}, but it is a rare occurrence. During the audit, I would
suggest that:

- Recipes be corrected, if need.
- license and emit_pkg_data and anything that utilizes LICENSE be
fixed to take package level LICENSE_${PN} into account.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111220/b1c8b933/attachment-0002.html>