[RFC] LICENSE Standards

[RFC] LICENSE Standards

[Flanagan, Elizabeth]

[-- Attachment #1: Type: text/plain, Size: 6929 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 7818 bytes --]

Re: [RFC] LICENSE Standards

[Paul Eggleton]

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.)

> - 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?

> 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?

> 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.

> 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?

> - 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.

> 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.

> 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.

Definitely agreed.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [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
>

Re: [RFC] LICENSE Standards

[Flanagan, Elizabeth]

On Fri, Dec 23, 2011 at 9:05 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
> 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.)

I was thinking more in the lines of what shadow's license is. BSD | Artistic.

In that case, at least how I'm reading it, the choice is give to the
distributor in
how they deal with licensing. Which, to me, does mean writing it like:

LICENSE = "(BSD) | (Artistic)"

Which is what priority mapping should be. A decision from the packager
side. When we hit
multi-licensed software where the decision is on the end user side,
perhaps the way to do it
would be:

LICENSE = "BSD | Artistic"

>
>
>>> 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 ... ?
>>

Copy past edit forget.

>>> - 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.)

That's a good way to approach the licenses that do that. We should
still have a defined
naming convention for those licenses.

>
>
>>> - 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.

other is fine by me.

>
>
> 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.

That should probably read "spdx provided license text". One thing we should also
discuss is eventually looking for the spdx spec file. If it exists, we should:

a. Audit against it
b. if it says our LICENSE is wrong, throw a warning.
c. use the spec file instead.

>
>
>>> 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.

perhaps Other:Adobe:${PN} ?

>
>
>>> 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.

+ is for those Licenses that have an automatic upgrade path (or greater).
Parens for decisions that need to be made from the distributor side.

> 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
>>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
Elizabeth Flanagan
Yocto Project
Build and Release

Re: [RFC] LICENSE Standards

[Paul Eggleton]

On Friday 23 December 2011 11:05:01 Mark Hatle wrote:
> > 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.

I guess all I was questioning was the wording, I agree we need the mechanism. 
If we say something like "Some recipes may produce output packages where some 
of the packages have a distinct license, in which case the individual package 
licenses should be specified separately using LICENSE_<package_name>".

> >> - 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.)

I guess this might be what the priority map is supposed to do, assuming the 
user can configure the map...?

> 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.)

I was thinking along these lines and I know Beth was also. Whatever scheme is 
used, IMO the user needs to be warned when the system makes a LICENSE 
selection, particularly if the "reasonable defaults" are being used.

> 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.)

I would say when we come across such packages we should be strongly 
encouraging the authors to include the license within the distributed source. 
Of course they may very likely just ignore our request, but we should make it 
all the same.

> >> - 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.

Sure, I understand this.

> 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.

Right, I recall reading about this part of SPDX that we don't yet make use of 
in the past.

> >> 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.

That could work, yes. I'm a little bit wary of introducing any more complexity 
to the LICENSE field but if we're adopting SPDX license naming then having a 
separate "namespace" (perhaps we ought to just use the word "prefix" to keep 
things simple) would be a useful distinction.

> & and | I believe are "obvious".  And cover the case of the "/", "&&" and
> "," above.  I'm not sure exactly how using the "+" and "()" will be.

If you want to express the "GPL, version 2 of the license or (at your option) 
any later version" then you need +, or the field just becomes too unweildy. The 
brackets start to make things complicated, but there are some pieces of 
software out there where the authors have made the licensing very complicated; 
if & and |  are to be combined in the one LICENSE field you need to make it 
clear which "operator" applies first.

> 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.)

If we express it this way and continue to have the INCOMPATIBLE_LICENSE check 
at recipe selection time, we will continue to need a whitelist for gettext 
(unless this check is changed to use only the projected package contents of 
the image).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC] LICENSE Standards

[Mark Hatle]

On 12/28/11 5:39 AM, Paul Eggleton wrote:
> On Friday 23 December 2011 11:05:01 Mark Hatle wrote:
>>> 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.
>
> I guess all I was questioning was the wording, I agree we need the mechanism.
> If we say something like "Some recipes may produce output packages where some
> of the packages have a distinct license, in which case the individual package
> licenses should be specified separately using LICENSE_<package_name>".

I'm straying (I suspect) from the original topic.. but it just occurred to me. 
In the gettext case, if we allow it to be built then the package feeds could end 
up with a GPLv3 program that could be sucked into a filesystem image in an 
unintended way.

It might make sense as part of this work, to check (while writing the packages?) 
that the licenses are not in the blacklist.  If they are, we know the item was 
needed for some compilation bit -- but has been whitelisted by the user --  we 
could then avoid actually writing the package into the deploy/feed directory.

In the case of gettext, we would write out libgettext only.

>>>> - 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.)
>
> I guess this might be what the priority map is supposed to do, assuming the
> user can configure the map...?

The users choice of license in package X may affect the behavior of package Y. 
So it's important we have a way for a user to say "I choose this" license. 
(User in this case is an oe-core user.. not an end-user!)

This is where license compliance gets complicated and it's easy to make 
mistakes.  The goal of all of this is to make it easier to prevent and/or catch 
mistakes before they cause (unintended) problems.

>> 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.)
>
> I was thinking along these lines and I know Beth was also. Whatever scheme is
> used, IMO the user needs to be warned when the system makes a LICENSE
> selection, particularly if the "reasonable defaults" are being used.
>
>> 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.)
>
> I would say when we come across such packages we should be strongly
> encouraging the authors to include the license within the distributed source.
> Of course they may very likely just ignore our request, but we should make it
> all the same.
>
>>>> - 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.
>
> Sure, I understand this.
>
>> 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.
>
> Right, I recall reading about this part of SPDX that we don't yet make use of
> in the past.
>
>>>> 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.
>
> That could work, yes. I'm a little bit wary of introducing any more complexity
> to the LICENSE field but if we're adopting SPDX license naming then having a
> separate "namespace" (perhaps we ought to just use the word "prefix" to keep
> things simple) would be a useful distinction.
>
>> &  and | I believe are "obvious".  And cover the case of the "/", "&&" and
>> "," above.  I'm not sure exactly how using the "+" and "()" will be.
>
> If you want to express the "GPL, version 2 of the license or (at your option)
> any later version" then you need +, or the field just becomes too unweildy. The
> brackets start to make things complicated, but there are some pieces of
> software out there where the authors have made the licensing very complicated;
> if&  and |  are to be combined in the one LICENSE field you need to make it
> clear which "operator" applies first.

The SPDX naming already has the "or at your option" factored into the naming in 
some way.  I believe it already uses the "+".  (I was thinking when I originally 
read that that you were saying GPLv2 + GPLv3.. which is why I didn't understand 
the context.)

I'd treat the "+" as simply part of the name of the license, with no specific 
contextual meaning.

Any tools that are created that do any type of auditing will need to know that a 
package with name XYZ is or is not compatible with a package with the name ABC. 
  Also the permutations that with the user being able to "select" a license. 
They could simply state I chose to license this as GPLv3 (even though it was a 
GPLv2+)..  Lots of permutations, I don't think we'll capture all of the corner 
cases.. but it's something to be aware of.

>> 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.)
>
> If we express it this way and continue to have the INCOMPATIBLE_LICENSE check
> at recipe selection time, we will continue to need a whitelist for gettext
> (unless this check is changed to use only the projected package contents of
> the image).

Goes back to my earlier comment.  We should have a way to generate just the 
LGPLv2.1 portion of the code.  My concern is this could be tricky if someone 
copies something directly to the sysroot and it's used for later development... 
so we need some protection around this particular corner case.

gettext itself is blacklisted, and I wouldn't want it in the feed.. but 
libgettext should be allowed....

--Mark

> Cheers,
> Paul
>