[OE-core] [RFC] LICENSE Standards

[Mark Hatle]

On 12/23/11 10:44 AM, Paul Eggleton wrote:
> Hi Beth,
>
> Great work on this. A few comments below:
>
> On Tuesday 20 December 2011 08:17:22 Flanagan, Elizabeth wrote:
>> - 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.
>
> Do you have a feeling as to how common this is? I've not done any
> comprehensive study but presumably this is the exception rather than the rule?
> (Perhaps this is only a matter of wording in the above.)

This is common enough, in my experience, that we have to have a way to support 
it.  The primary example I have is gettext.  The core gettext binary is GPLv3, 
while the libraries are still LGPLv2.1.  This can make a huge impact when 
someone is evaluating weather that can use the current version of gettext or not 
in a system.

>> - The LICENSE operands need to be dealt with through a license
>> priority map. The plan is to implement this within the next few weeks.
>
> Could you elaborate on what the license priority map is?

I'd not commented on this before, but I'm not sure that is possible.  Most 
licenses, that offer multiple choice, are written that it's up to the user to 
choose the appropriate license.  I believe we can set reasonable defaults within 
the OE environment.  But in the end the user has to choose the license they want 
to use for a particular package.  (Some packages I've seen allow you to choose 
the license on the configure line, which has a side effect of disabling certain 
functionality -- this is very rare though.)

Perhaps a companion variable to LICENSE that the user can set, that details 
their choice.  (Other then the existing black listed license, in the future I 
can see someone write an audit tool that looks for possible licensing conflicts 
-- it's more likely to be needed then.)

>> 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.
>
> Sounds reasonable, I think that we additionally ought to put in warnings for
> mapped licenses now if we go ahead with this - perhaps if we're going to
> update oelint.bbclass (something I came across recently) it could be extended
> to understand and report mappings?

I firmly believe using SPDX naming is a good first approach.. specifically for 
the items listed below.  (For items outside of the SPDX naming, there should be 
a way to specify "other" and what that other means..  consider it a namespace, 
with the default namespace being SPDX.)

>> 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.
>
> I think OE history has shown we're not great at this by ourselves so this
> definitely sounds good.

Whenever the SPDX tooling and license data starts to be produced, we'll want to 
have a way to include this with the recipes.  I suspect we have enough 
facilities today to be able to do this, so nothing special will be needed.

>> 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
>
> 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).
>
> I'm wondering about another possibility - for those pieces of software where
> we cannot get permission for a generic license, have a mechanism for the
> recipe to point to the license file within the source that should be copied to
> the output, thus avoiding "uncommon" licenses being copied into the common
> license dir. It could even be as simple as an additional flag for one of the
> files listed in LIC_FILES_CHKSUM. Would that work and be worthwhile?

That seems reasonable.  Annoying as it is, I've seen a few packages where the 
license text is simply a magic URL.  So adding the facility to fetch the license 
text from a URL and include it is likely a good idea as well.  (Since my 
understanding is you are bound by the license at the time you download the 
software -- so matching the download to the license text is a good safety net. 
This could also have ramifications of caching/mirroring downloads as well..) 
Again, this is rare, but something I've run into before.  (It seems fairly scary 
to me that the only license text for a program would be on a web page that the 
copyright holder is allowed to modify at any time they choose.. which is why 
mirroring the text is important in that case.)

>> - 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.
>
> Unless "alternative" is a term SPDX uses I would suggest using "other" or some
> other word since "alternative" implies some form of choice. Otherwise this
> sounds reasonable.

Let me clarify something about SPDX.  There is no such thing as an 
"spdx-license".  What they have done is created a set of common names that refer 
to common license texts.  It's up to the recipe creator to verify that the 
common text is what is within the package.

SPDX really refers to an XML format for meta data related to a given software 
package.  This file will include the standardized naming for a given license (if 
there is one), along with key information relating to copyright and license 
statements within every source file in that package.  The SPDX data is designed 
to go down to the file level and give someone performing a license audit all of 
the information they may potentially need to determine the (legal) suitability 
of a piece of software for their needs.

>> 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
>
> Clearly this is just an example, but I imagine we would want to be more
> specific as I'm sure like many commercial vendors, Adobe has many licenses
> under which they have released software.

Going back to the namespace idea.. perhaps:  Other:Adobe   This would clearly 
label the item as not being in the SPDX namespace.

>> 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.
>
> Sounds like it should cover all the bases.
>
>> 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.

& and | I believe are "obvious".  And cover the case of the "/", "&&" and "," 
above.  I'm not sure exactly how using the "+" and "()" will be.  The single 
"license" field has to the cover the package as whole -- anything at a split 
level will need to be covered by license_pn -- and anything that is file level 
will need to be rolled up into the license_pn for the associated split item.

I would expect in the gettext example that something like the following is in 
the recipe:

LICENSE = "GPLv3 & LGPLv2.1"
LICENSE_gettext = "GPLv3"
LICENSE_libgettext = "LGPLv2.1"

That way it's clear what the overall source license is, as well as the split 
package licenses.  (Of course this is a corner case, as most things the package 
license and the split package license are the same.)

--Mark

>
> Definitely agreed.
>
> Cheers,
> Paul
>