Proposed Update to SPDX License Expression Language


Philip Odence
 

Editor’s note: Big thanks to Mark Gisi for driving this important effort.


***

In the wake of a highly productive cross-functional meeting at the Linux Collaboration Summit, the SPDX Legal Team proposes certain changes to the SPDX specification and license list.  We are now eliciting comments on the proposal for the next two weeks from the larger SPDX organization which we present below. Please send any comments or questions to the three of us.

 

Regards,

- Jilayne Lovejoy  [opensource@...]

- Paul Madick  [paul.madick@...]

- Mark Gisi  [mark.gisi@...]  


Proposal

 

Statement of the problem:  The current SPDX Specification and License List have a limited language (i.e. and/or) that is not suitable for expressing complex license situations (for examples of such complexity, see http://wiki.spdx.org/view/FileNoticeExamples ).  Additionally, the current SPDX License List currently requires the addition of multiple licenses to the list in order to capture combinations of versions, the “or later” license genre (i.e. GPL-2.0 and GPL-2.0+) and the most common exceptions (i.e. GPL-2.0+-with-autoconf-exception and GPL-3.0-with-autoconf-exception). It should be noted that the SPDX Legal Team identified more than 30 discrete exceptions. Finally, license exceptions (i.e. autoconf-exception) are generally not versioned, and therefore, accounting for changes to the license exceptions when they are part of the canonical license creates opportunity for error and confusion.  For additional background please see http://wiki.spdx.org/view/Legal_Team/License_Expression_Review_1

 

Aim:  Improve the ability to describe more license variations utilizing some operator(s) without impact to the current timeline for the next version of the SPDX Specification.

 

Proposed Solution: 

(1)    “+” to be added to the SPDX Specification as an operator to denote “or later.”  As a result, all current licenses on the SPDX License List with a “Full Name” that includes “or later” will be deprecated. Deprecated means the license entry will technically remain on the list (just moved to the Deprecated section) and list users will be highly discouraged from using them. Deprecated licenses are potentially subject to removal in a future version of the list.

·         Example: The license GPL-2.0+ will be deprecated. License entry GPL-2.0 will remain on the SDPX license list and the following is still a valid license expression “GPL-2.0+”.  This state’s GPL-2.0 or later because the +” now plays the role of a unary operator that means ‘the version of this license or a later version’. The following would also be a valid license expression as well: EPL-1.0+ which means EPL-1.0 or a later version. The change of the “+” to an operator will make even more sense once one considers license exceptions (modifiers) in the next section.

 

(2)    “WITH” binary operator (similar to AND/OR) to be added to the SPDX Specification. It denotes that the license identified by the SPDX short name identifier is modified by a well-defined exception on a new “SPDX Modifier List” as described in section (3).  As a result, all current licenses that include the term “exception” in the “Full Name” will be deprecated. 

·         Example: “GPL-2.0-with-bison-exception” will be deprecated but the following expression, which achieves the same result, is now valid: “GPL-2.0 WITH bison-exception”.

 

(3)    The Legal Team will be responsible for creating and maintaining the canonical list of SPDX License List modifiers (i.e. “auto-conf- exception, bison-exception”). It should be noted that licenses that are deprecated will be able to be expressed (more eloquently) with the new changes; hence no license will “fall off” the SPDX License List, nor will this create a compatibility issue.  URL references to all deprecated licenses will be maintained for full backward compatibility.

·         For example: the following is now a valid expression: “GPL-2.0+ WITH bison-exception” where the “+” and “WITH” operators allow a more flexible expression to be constructed. Prior to this addition this expression was not easy to express.

 

Longer Term Solution: Add capability for users to define modifier references local to an SPDX document, analogously the way LicRef is used for licenses not on the License List. This will involve adding “ModRef” to the SPDX Specification so the following would be a valid expression:  “GPL-2.0 WITH ModRef23.”  Where ModRef23 provides the text of a license modifier that does not appear on the SPDX Modifier List.  In the initial proposed solution, the way to express a file with a GPL-2.0 license with an exception, that is not included on the SPDX Modifier canonical List, will be by including the full text of the license and the exception as a single LicRef (which is the current state of affairs as well).

 

Rationale:  The proposed solution will provide the SPDX community the ability to express more licenses and license combinations in a more elegant and meaningful (human consumable) way then is currently available under the existing SPDX Specification and License List. To the extent that the SPDX community has come to rely on any of the licenses superseded by the new specifications those licenses will still be available on the SPDX License List (although deprecated).  Finally, the initial proposed solution is a major improvement to the current situation and is easily extensible to the even more flexible longer term solution without impacting the current timeline for SPDX 2.0.

 


Daniel Companeetz <dcompane@...>
 

A comment about the "+" operator.

The standard SPDX Licenst list on the Appendix 1 of the 1.2 Specification, contains entries without the version qualification.

Adaptive Public License 1.0APL-1.0

Aladdin Free Public LicenseAladdin
ANTLR Software Rights NoticeANTLR-PD
Apache License 1.0Apache-1.0


BSD 4-clause "Original" or "Old" LicenseBSD-4-Clause
BSD-4-Clause (University of California-Specific)BSD-4-Clause-UC

As such, a programatic approach to understanding the nature of the "+" would be complex. Does the "+" refer to anything that is not common ("A" on the examples above), or as inferred, anything after the "-" in the specification, and in that case, only the first "-" as a separator? 


The License Identifier (short id) definition from the spec 1.2 states 
5.1.4 Data Format: "LicenseRef-"[idString]
where
[idString] is a unique string containing letters, numbers, “.”, “-” or “+”.

I am also confused with the usage intended. There are 2 concepts that are affected: The license identifier in the License list, and the SPDX License Identifier tag. While similar, they serve different purposes.

As I understand, and just for clarification, the actions being proposed are:  
1. Remove the "+" from the License Identifiers on the Licenst List.  (http://spdx.org/licenses/)
    a. The License Identifier in the SPDX.org maintained tables should not include the "+". 
2. Add the "+" to the License Identifier tag definition specification,
    a. The SPDX License Identifier tag specification may indicate that the developer has a choice to apply either a specific license as it appears on the licenses list, or all subsequent licenses of the same kind by adding the "+" sign to SPDX filesin the SPDX License Identifier tag after the idString, and before the WITH exceptions. 
    b. Indicate that the operator only applies to the idString portion of a License Identifier, which may contain a "-" per the specification
    c. Add to the proposed specification above that the "+" operator indicates all versions that are comparable as strings bigger or equal than the identifier indicated. You may want to indicate a plain ASCII comparison, or make a reference to the matching Guidelines (https://spdx.org/spdx-license-list/matching-guidelines) for, for example, the purpose of capitalization.
3. Eliminate the "-" as a possible value of the LicenseRef (see the BSD 4 examples above. Is LicenseRef BSD-4, or just BSD? Will "BSD-2+" a tag, or "BSD+", or could be both?)
    a. Maybe the license list needs to have separate fields for the LicenseRef and the other components in the table (and one with the complete string?)
4. Make the "-[idString]" mandatory, (see Aladdin example above) 
    a. Need to define a default value to be used as -idString, in the absence of one in the specification, although it is likely that all of them have one (Aladdin is v8, as per the web page)

 I am a new member of this community, and I do not yet grasp fully the SPDX 1.2 specification, let alone the WIP 2.0. I hope I am not restating the obvious.

As a separate question, I was not able to find in spdx.org a current draft of the 2.0 specification. Is one available already?

Please feel free to contact me for questions or clarifications, or if you would like me to attend a meeting to further discuss this message.

Regards,

Daniel Companeetz




On Wed, Apr 9, 2014 at 3:35 AM, Philip Odence <podence@...> wrote:

Editor’s note: Big thanks to Mark Gisi for driving this important effort.


***

In the wake of a highly productive cross-functional meeting at the Linux Collaboration Summit, the SPDX Legal Team proposes certain changes to the SPDX specification and license list.  We are now eliciting comments on the proposal for the next two weeks from the larger SPDX organization which we present below. Please send any comments or questions to the three of us.

 

Regards,

- Jilayne Lovejoy  [opensource@...]

- Paul Madick  [paul.madick@...]

- Mark Gisi  [mark.gisi@...]  


Proposal

 

Statement of the problem:  The current SPDX Specification and License List have a limited language (i.e. and/or) that is not suitable for expressing complex license situations (for examples of such complexity, see http://wiki.spdx.org/view/FileNoticeExamples ).  Additionally, the current SPDX License List currently requires the addition of multiple licenses to the list in order to capture combinations of versions, the “or later” license genre (i.e. GPL-2.0 and GPL-2.0+) and the most common exceptions (i.e. GPL-2.0+-with-autoconf-exception and GPL-3.0-with-autoconf-exception). It should be noted that the SPDX Legal Team identified more than 30 discrete exceptions. Finally, license exceptions (i.e. autoconf-exception) are generally not versioned, and therefore, accounting for changes to the license exceptions when they are part of the canonical license creates opportunity for error and confusion.  For additional background please see http://wiki.spdx.org/view/Legal_Team/License_Expression_Review_1

 

Aim:  Improve the ability to describe more license variations utilizing some operator(s) without impact to the current timeline for the next version of the SPDX Specification.

 

Proposed Solution: 

(1)    “+” to be added to the SPDX Specification as an operator to denote “or later.”  As a result, all current licenses on the SPDX License List with a “Full Name” that includes “or later” will be deprecated. Deprecated means the license entry will technically remain on the list (just moved to the Deprecated section) and list users will be highly discouraged from using them. Deprecated licenses are potentially subject to removal in a future version of the list.

·         Example: The license GPL-2.0+ will be deprecated. License entry GPL-2.0 will remain on the SDPX license list and the following is still a valid license expression “GPL-2.0+”.  This state’s GPL-2.0 or later because the +” now plays the role of a unary operator that means ‘the version of this license or a later version’. The following would also be a valid license expression as well: EPL-1.0+ which means EPL-1.0 or a later version. The change of the “+” to an operator will make even more sense once one considers license exceptions (modifiers) in the next section.

 

(2)    “WITH” binary operator (similar to AND/OR) to be added to the SPDX Specification. It denotes that the license identified by the SPDX short name identifier is modified by a well-defined exception on a new “SPDX Modifier List” as described in section (3).  As a result, all current licenses that include the term “exception” in the “Full Name” will be deprecated. 

·         Example: “GPL-2.0-with-bison-exception” will be deprecated but the following expression, which achieves the same result, is now valid: “GPL-2.0 WITH bison-exception”.

 

(3)    The Legal Team will be responsible for creating and maintaining the canonical list of SPDX License List modifiers (i.e. “auto-conf- exception, bison-exception”). It should be noted that licenses that are deprecated will be able to be expressed (more eloquently) with the new changes; hence no license will “fall off” the SPDX License List, nor will this create a compatibility issue.  URL references to all deprecated licenses will be maintained for full backward compatibility.

·         For example: the following is now a valid expression: “GPL-2.0+ WITH bison-exception” where the “+” and “WITH” operators allow a more flexible expression to be constructed. Prior to this addition this expression was not easy to express.

 

Longer Term Solution: Add capability for users to define modifier references local to an SPDX document, analogously the way LicRef is used for licenses not on the License List. This will involve adding “ModRef” to the SPDX Specification so the following would be a valid expression:  “GPL-2.0 WITH ModRef23.”  Where ModRef23 provides the text of a license modifier that does not appear on the SPDX Modifier List.  In the initial proposed solution, the way to express a file with a GPL-2.0 license with an exception, that is not included on the SPDX Modifier canonical List, will be by including the full text of the license and the exception as a single LicRef (which is the current state of affairs as well).

 

Rationale:  The proposed solution will provide the SPDX community the ability to express more licenses and license combinations in a more elegant and meaningful (human consumable) way then is currently available under the existing SPDX Specification and License List. To the extent that the SPDX community has come to rely on any of the licenses superseded by the new specifications those licenses will still be available on the SPDX License List (although deprecated).  Finally, the initial proposed solution is a major improvement to the current situation and is easily extensible to the even more flexible longer term solution without impacting the current timeline for SPDX 2.0.

 


_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech



Mark Gisi
 

Hi Daniel,

 

The ‘+’ operator is used to represent the case we see so often:

    You may choose to use version <N> of license <L> or any later version of license <L>.

 

The intent is to provide a way to represent the source file license notice text that often accompanies the GPL and LGPL licenses. GPL-2.0+ is not so much a license, but a license choice (GPL-2.0 OR GPL-3.0).  Should there ever be a GPL-4.0 version of the GPL license then it would become a choice between GPL-2.0 or GPL-3.0 or GPL-4.0. Another common use is when one states that a source file or program is under the GPL without specifying a version. In that case, many conclude the license expression to be GPL-1.0+ (because all versions of the GPL state you can pick a version if one is not specified). On a few occasions I have seen some use the “or later version” with other licenses (e.g., EPL-1.0 or a later version) but it is not that common. As was noted previously, the importance of the “+” operator becomes even more apparent when one looks at the many different special exceptions that accompany the GPL license. Some exception notices make reference to the current version only while others state a specific version or later. This was adding complexity to the license list. Making it an operator eliminates complexity.

 

>> As such, a programatic approach to understanding the nature of the "+" would be complex.

>> Does the "+" refer to anything that is not common ("A" on the examples above), or as inferred,

>> anything after the "-" in the specification, and in that case, only the first "-" as a separator? 

 

In the current SPDX License List (1.19) and the current version of the SPDX spec (1.2) the “+” is nothing more than a valid character used to construct identifier names. That is also true for the character “-“. There is no intended semantics for these characters (in license list 1.19 or spec 1.2). For example, the current “GPL-2.0” identifier could have just as easily been called “GPLv2.0” or “GPL2”. Here even the “2” and “.” have no semantic meaning as well.

 

Moving forward, in future license lists and specs, the proposal is to remove “+” as a valid character used to craft a license identifier and LicenseRefs, and make it a unary operator that has a specific semantic meaning. This would not change the use of “-“ as a valid character for crafting license identifiers. The “-“character will continue to have no semantic meaning. So the license identifiers GPL-2.0 or LicenseRef-23 are simply aliases for the “GNU Public License Version 2” and a non-standard user defined license respectively. There was no intent in crafting the name where semantics are applied to the “-2.0” characters found in the GPL-2.0 identifier. A tool should not apply any semantics to these characters of the identifier’s name. A tool should simply map the label “GPL-2.0” to “GNU Public License Version 2”.

 

>> I am also confused with the usage intended. There are 2 concepts that are affected: The license identifier in the License list,

>> and the SPDX License Identifier tag. While similar, they serve different purposes.

 

There may not be 2 separate concepts. I think the intent is to have just one concept that is consistent with both the license list and spec identifiers. I will try to address your concerns by specifically confirming certain points below.

 

>> 1. Remove the "+" from the License Identifiers on the Licenst List.  (http://spdx.org/licenses/)

>>    a. The License Identifier in the SPDX.org maintained tables should not include the "+". 

 

This is consistent with the current proposal.

 

>> 2. Add the "+" to the License Identifier tag definition specification,

>>    a. The SPDX License Identifier tag specification may indicate that the developer has a choice to apply either a specific license as it

>> appears on the licenses list, or all subsequent licenses of the same kind by adding the "+" sign to SPDX filesin

>> the SPDX License Identifier tag after the idString, and before the WITH exceptions. 

 

In the proposal the “+” now behaves like AND and OR in that it is an operator used to construct license expressions. SPDX spec 1.2 does not make it very clear how to construct license expressions. If the proposal is accepted you should expect the “+” to be removed from the definition of idString:

      [idString] is a unique string containing letters, numbers, “.”, “-” or “+”.

And more clarification will need to be provided on how to construct license expressions using +, AND, OR, WITH and (). Gary O’Neall recently pointed out that we need to also include an order of precedence. Here is the current proposed ordering:

1- "()"

2-"+"

3-"WITH"

4-AND

5-OR

 

>> 3. Eliminate the "-" as a possible value of the LicenseRef (see the BSD 4 examples above.

>> Is LicenseRef BSD-4, or just BSD? Will "BSD-2+" a tag, or "BSD+", or could be both?)

 

As I noted above the “-“ is just a valid character use to construct License Identifiers and LicenseRef identifiers with no intended semantic meaning. The “+” was a valid character in 1.2 but we are proposing to remove it as valid character in 2.0 for both license identifiers and IdStrings.

 

>> 4. Make the "-[idString]" mandatory, (see Aladdin example above) 

>>    a. Need to define a default value to be used as -idString, in the absence of one in

>> the specification, although it is likely that all of them have one (Aladdin is v8, as per the web page)

 

I am not sure I understand this requirement. Are you suggesting that all licenses should have a version number as part of their identifier name?

 

>> I am a new member of this community, and I do not yet grasp fully the SPDX 1.2 specification, let alone the WIP 2.0.

>>  I hope I am not restating the obvious.

 

I appreciate the level of detail you have reviewed SPDX spec 1.2. Feedback at this level is particularly important to the spec’s evolution and success.

 

>> As a separate question, I was not able to find in spdx.org a current draft of the 2.0 specification. Is one available already?

 

It is not yet ready for prime time. It is being drafted and available to those participating in the technical working group. I hope you can participate.

 

Regards,

Mark

 

Mark Gisi | Wind River | Senior Intellectual Property Manager

Tel (510) 749-2016 | Fax (510) 749-4552

 

 

From: Daniel Companeetz [mailto:dcompane@...]
Sent: Wednesday, April 09, 2014 9:56 AM
To: Philip Odence; Paul Madick; Gisi, Mark; Jilayne Lovejoy; Daniel Companeetz
Cc: spdx-legal@...; spdx-tech@...; spdx-biz@...
Subject: Re: Proposed Update to SPDX License Expression Language

 

A comment about the "+" operator.

 

The standard SPDX Licenst list on the Appendix 1 of the 1.2 Specification, contains entries without the version qualification.

 

Adaptive Public License 1.0

APL-1.0

Aladdin Free Public License

Aladdin

ANTLR Software Rights Notice

ANTLR-PD

Apache License 1.0

Apache-1.0

 

 

BSD 4-clause "Original" or "Old" License

BSD-4-Clause

BSD-4-Clause (University of California-Specific)

BSD-4-Clause-UC

 

As such, a programatic approach to understanding the nature of the "+" would be complex. Does the "+" refer to anything that is not common ("A" on the examples above), or as inferred, anything after the "-" in the specification, and in that case, only the first "-" as a separator? 

 

 

The License Identifier (short id) definition from the spec 1.2 states 

5.1.4 Data Format: "LicenseRef-"[idString]

where

[idString] is a unique string containing letters, numbers, “.”, “-” or “+”.

 

I am also confused with the usage intended. There are 2 concepts that are affected: The license identifier in the License list, and the SPDX License Identifier tag. While similar, they serve different purposes.

 

As I understand, and just for clarification, the actions being proposed are:  

1. Remove the "+" from the License Identifiers on the Licenst List.  (http://spdx.org/licenses/)

    a. The License Identifier in the SPDX.org maintained tables should not include the "+". 

2. Add the "+" to the License Identifier tag definition specification,

    a. The SPDX License Identifier tag specification may indicate that the developer has a choice to apply either a specific license as it appears on the licenses list, or all subsequent licenses of the same kind by adding the "+" sign to SPDX filesin the SPDX License Identifier tag after the idString, and before the WITH exceptions. 

    b. Indicate that the operator only applies to the idString portion of a License Identifier, which may contain a "-" per the specification

    c. Add to the proposed specification above that the "+" operator indicates all versions that are comparable as strings bigger or equal than the identifier indicated. You may want to indicate a plain ASCII comparison, or make a reference to the matching Guidelines (https://spdx.org/spdx-license-list/matching-guidelines) for, for example, the purpose of capitalization.

3. Eliminate the "-" as a possible value of the LicenseRef (see the BSD 4 examples above. Is LicenseRef BSD-4, or just BSD? Will "BSD-2+" a tag, or "BSD+", or could be both?)

    a. Maybe the license list needs to have separate fields for the LicenseRef and the other components in the table (and one with the complete string?)

4. Make the "-[idString]" mandatory, (see Aladdin example above) 

    a. Need to define a default value to be used as -idString, in the absence of one in the specification, although it is likely that all of them have one (Aladdin is v8, as per the web page)

 

 I am a new member of this community, and I do not yet grasp fully the SPDX 1.2 specification, let alone the WIP 2.0. I hope I am not restating the obvious.

 

As a separate question, I was not able to find in spdx.org a current draft of the 2.0 specification. Is one available already?

 

Please feel free to contact me for questions or clarifications, or if you would like me to attend a meeting to further discuss this message.

 

Regards,

 

Daniel Companeetz

 

 

 

On Wed, Apr 9, 2014 at 3:35 AM, Philip Odence <podence@...> wrote:

Editor’s note: Big thanks to Mark Gisi for driving this important effort.

 

***

In the wake of a highly productive cross-functional meeting at the Linux Collaboration Summit, the SPDX Legal Team proposes certain changes to the SPDX specification and license list.  We are now eliciting comments on the proposal for the next two weeks from the larger SPDX organization which we present below. Please send any comments or questions to the three of us.

 

Regards,

- Jilayne Lovejoy  [opensource@...]

- Paul Madick  [paul.madick@...]

- Mark Gisi  [mark.gisi@...]  

 

Proposal

 

Statement of the problem:  The current SPDX Specification and License List have a limited language (i.e. and/or) that is not suitable for expressing complex license situations (for examples of such complexity, see http://wiki.spdx.org/view/FileNoticeExamples ).  Additionally, the current SPDX License List currently requires the addition of multiple licenses to the list in order to capture combinations of versions, the “or later” license genre (i.e. GPL-2.0 and GPL-2.0+) and the most common exceptions (i.e. GPL-2.0+-with-autoconf-exception and GPL-3.0-with-autoconf-exception). It should be noted that the SPDX Legal Team identified more than 30 discrete exceptions. Finally, license exceptions (i.e. autoconf-exception) are generally not versioned, and therefore, accounting for changes to the license exceptions when they are part of the canonical license creates opportunity for error and confusion.  For additional background please see http://wiki.spdx.org/view/Legal_Team/License_Expression_Review_1

 

Aim:  Improve the ability to describe more license variations utilizing some operator(s) without impact to the current timeline for the next version of the SPDX Specification.

 

Proposed Solution: 

(1)    “+” to be added to the SPDX Specification as an operator to denote “or later.”  As a result, all current licenses on the SPDX License List with a “Full Name” that includes “or later” will be deprecated. Deprecated means the license entry will technically remain on the list (just moved to the Deprecated section) and list users will be highly discouraged from using them. Deprecated licenses are potentially subject to removal in a future version of the list.

·         Example: The license GPL-2.0+ will be deprecated. License entry GPL-2.0 will remain on the SDPX license list and the following is still a valid license expression “GPL-2.0+”.  This state’s GPL-2.0 or later because the +” now plays the role of a unary operator that means ‘the version of this license or a later version’. The following would also be a valid license expression as well: EPL-1.0+ which means EPL-1.0 or a later version. The change of the “+” to an operator will make even more sense once one considers license exceptions (modifiers) in the next section.

 

(2)    “WITH” binary operator (similar to AND/OR) to be added to the SPDX Specification. It denotes that the license identified by the SPDX short name identifier is modified by a well-defined exception on a new “SPDX Modifier List” as described in section (3).  As a result, all current licenses that include the term “exception” in the “Full Name” will be deprecated. 

·         Example: “GPL-2.0-with-bison-exception” will be deprecated but the following expression, which achieves the same result, is now valid: “GPL-2.0 WITH bison-exception”.

 

(3)    The Legal Team will be responsible for creating and maintaining the canonical list of SPDX License List modifiers (i.e. “auto-conf- exception, bison-exception”). It should be noted that licenses that are deprecated will be able to be expressed (more eloquently) with the new changes; hence no license will “fall off” the SPDX License List, nor will this create a compatibility issue.  URL references to all deprecated licenses will be maintained for full backward compatibility.

·         For example: the following is now a valid expression: “GPL-2.0+ WITH bison-exception” where the “+” and “WITH” operators allow a more flexible expression to be constructed. Prior to this addition this expression was not easy to express.

 

Longer Term Solution: Add capability for users to define modifier references local to an SPDX document, analogously the way LicRef is used for licenses not on the License List. This will involve adding “ModRef” to the SPDX Specification so the following would be a valid expression:  “GPL-2.0 WITH ModRef23.”  Where ModRef23 provides the text of a license modifier that does not appear on the SPDX Modifier List.  In the initial proposed solution, the way to express a file with a GPL-2.0 license with an exception, that is not included on the SPDX Modifier canonical List, will be by including the full text of the license and the exception as a single LicRef (which is the current state of affairs as well).

 

Rationale:  The proposed solution will provide the SPDX community the ability to express more licenses and license combinations in a more elegant and meaningful (human consumable) way then is currently available under the existing SPDX Specification and License List. To the extent that the SPDX community has come to rely on any of the licenses superseded by the new specifications those licenses will still be available on the SPDX License List (although deprecated).  Finally, the initial proposed solution is a major improvement to the current situation and is easily extensible to the even more flexible longer term solution without impacting the current timeline for SPDX 2.0.

 


_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech

 


J Lovejoy
 

Thanks for your interest, Daniel, and thanks, Mark for your detailed response to Daniel’s questions.

 

I’ve added few bits below for further clarification in regards to other (not GNU) licenses the use of the “+” operator:

 

 

The ‘+’ operator is used to represent the case we see so often:

    You may choose to use version <N> of license <L> or any later version of license <L>.

 

The intent is to provide a way to represent the source file license notice text that often accompanies the GPL and LGPL licenses. GPL-2.0+ is not so much a license, but a license choice (GPL-2.0 OR GPL-3.0).  Should there ever be a GPL-4.0 version of the GPL license then it would become a choice between GPL-2.0 or GPL-3.0 or GPL-4.0. Another common use is when one states that a source file or program is under the GPL without specifying a version. In that case, many conclude the license expression to be GPL-1.0+ (because all versions of the GPL state you can pick a version if one is not specified). On a few occasions I have seen some use the “or later version” with other licenses (e.g., EPL-1.0 or a later version) but it is not that common. As was noted previously, the importance of the “+” operator becomes even more apparent when one looks at the many different special exceptions that accompany the GPL license. Some exception notices make reference to the current version only while others state a specific version or later. This was adding complexity to the license list. Making it an operator eliminates complexity.

[JLovejoy:] In regards to Mark’s comment about EPL:  Although when we think of the “or later” option, we mostly think of the GNU family of licenses, there are a number of other licenses (e.g., EPL, MPL) that also allow the use of “or later” versions.  When the idea of removing the “or later” (indicated by the “+” in the short identifier) license options from separate line items (i.e., licenses listed on the SPDX License List) and using the “+” as an operator, I was concerned that we would then need to indicate which licenses the “+” operator could be used with to avoid incorrect use of the “+” operator.  But discussion regarding this proposal pointed out that there is never any way to prevent all potential incorrect outcomes, and, as such, market forces (for lack of better term) in regards to trustworthiness of a given SPDX document created by a particular author would (hopefully) work to discourage such scenarios.

 

Thus, by having the “+” as an operator, one could, theoretically, apply it to *any* license on the SPDX License List (I shudder…).  Someone might, for example, declare the license for a file as:  BSD-2-Clause +

I would (vehemently) argue that this would be incorrect in the sense that nothing in the text of BSD-2-Clause explicitly allows a licensee to apply other versions of the BSD license to the licensor’s work. (Furthermore, the BSD licenses are not “versioned” in the traditional chronological sense, but their differences denoted by the number of clauses, which does not, incidentally, correspond the chronological history of the license(s).)  I would further that the only way (that I can think of at the moment and would rather not think of at all!) you could end up with a disjunctive licensing situation amongst BSD variations, is if the work stated something along the lines of, “This file is licensed under a choice of either BSD-2-Clause or BSD-3-Clause.”  (Nevermind that such a disjunctive license choice would also seem somewhat pointless…), which would/could/should be expressed in an SPDX document as the usual way: BSD-2-Clause OR BSD-3-Clause (more shuddering… One would then hope and pray that the Concluded License field provided the given choice and some kind of explanation for this ;)

 

 

>> 3. Eliminate the "-" as a possible value of the LicenseRef (see the BSD 4 examples above.

>> Is LicenseRef BSD-4, or just BSD? Will "BSD-2+" a tag, or "BSD+", or could be both?)

 

As I noted above the “-“ is just a valid character use to construct License Identifiers and LicenseRef identifiers with no intended semantic meaning. The “+” was a valid character in 1.2 but we are proposing to remove it as valid character in 2.0 for both license identifiers and IdStrings.

[JLovejoy:] If you are identifying a license that is on the SPDX License List, you would use the short identifier as seen on http://spdx.org/licenses/ - no less.  And only adding “more” to the short identifier as per the allowed operators. 

 

Incidentally, we do realize that documentation on how to apply the operators will be needed.  I think Mark’s examples are also very helpful for illustrating the need for a more robust way to express the licensing for a given work , see: http://wiki.spdx.org/view/FileNoticeExamples

 

 

I appreciate the level of detail you have reviewed SPDX spec 1.2. Feedback at this level is particularly important to the spec’s evolution and success.

[JLovejoy:] agreed!  Daniel – might you share with us how you came to know about / be interested in SPDX?

 

Hope to hear more from you in any case and we appreciate your input.

 

Cheers,

Jilayne

SPDX Legal Team co-lead

 

 

From: Daniel Companeetz [mailto:dcompane@...]
Sent: Wednesday, April 09, 2014 9:56 AM
To: Philip Odence; Paul Madick; Gisi, Mark; Jilayne Lovejoy; Daniel Companeetz
Cc: spdx-legal@...; spdx-tech@...; spdx-biz@...
Subject: Re: Proposed Update to SPDX License Expression Language

 

A comment about the "+" operator.

 

The standard SPDX Licenst list on the Appendix 1 of the 1.2 Specification, contains entries without the version qualification.

 

Adaptive Public License 1.0

APL-1.0

Aladdin Free Public License

Aladdin

ANTLR Software Rights Notice

ANTLR-PD

Apache License 1.0

Apache-1.0

 

 

BSD 4-clause "Original" or "Old" License

BSD-4-Clause

BSD-4-Clause (University of California-Specific)

BSD-4-Clause-UC

 

As such, a programatic approach to understanding the nature of the "+" would be complex. Does the "+" refer to anything that is not common ("A" on the examples above), or as inferred, anything after the "-" in the specification, and in that case, only the first "-" as a separator? 

 

 

The License Identifier (short id) definition from the spec 1.2 states 

5.1.4 Data Format: "LicenseRef-"[idString]

where

[idString] is a unique string containing letters, numbers, “.”, “-” or “+”.

 

I am also confused with the usage intended. There are 2 concepts that are affected: The license identifier in the License list, and the SPDX License Identifier tag. While similar, they serve different purposes.

 

As I understand, and just for clarification, the actions being proposed are:  

1. Remove the "+" from the License Identifiers on the Licenst List.  (http://spdx.org/licenses/)

    a. The License Identifier in the SPDX.org maintained tables should not include the "+". 

2. Add the "+" to the License Identifier tag definition specification,

    a. The SPDX License Identifier tag specification may indicate that the developer has a choice to apply either a specific license as it appears on the licenses list, or all subsequent licenses of the same kind by adding the "+" sign to SPDX filesin the SPDX License Identifier tag after the idString, and before the WITH exceptions. 

    b. Indicate that the operator only applies to the idString portion of a License Identifier, which may contain a "-" per the specification

    c. Add to the proposed specification above that the "+" operator indicates all versions that are comparable as strings bigger or equal than the identifier indicated. You may want to indicate a plain ASCII comparison, or make a reference to the matching Guidelines (https://spdx.org/spdx-license-list/matching-guidelines) for, for example, the purpose of capitalization.

3. Eliminate the "-" as a possible value of the LicenseRef (see the BSD 4 examples above. Is LicenseRef BSD-4, or just BSD? Will "BSD-2+" a tag, or "BSD+", or could be both?)

    a. Maybe the license list needs to have separate fields for the LicenseRef and the other components in the table (and one with the complete string?)

4. Make the "-[idString]" mandatory, (see Aladdin example above) 

    a. Need to define a default value to be used as -idString, in the absence of one in the specification, although it is likely that all of them have one (Aladdin is v8, as per the web page)

 

 I am a new member of this community, and I do not yet grasp fully the SPDX 1.2 specification, let alone the WIP 2.0. I hope I am not restating the obvious.

 

As a separate question, I was not able to find in spdx.org a current draft of the 2.0 specification. Is one available already?

 

Please feel free to contact me for questions or clarifications, or if you would like me to attend a meeting to further discuss this message.

 

Regards,

 

Daniel Companeetz

 

 

 

On Wed, Apr 9, 2014 at 3:35 AM, Philip Odence <podence@...> wrote:

Editor’s note: Big thanks to Mark Gisi for driving this important effort.

 

***

In the wake of a highly productive cross-functional meeting at the Linux Collaboration Summit, the SPDX Legal Team proposes certain changes to the SPDX specification and license list.  We are now eliciting comments on the proposal for the next two weeks from the larger SPDX organization which we present below. Please send any comments or questions to the three of us.

 

Regards,

- Jilayne Lovejoy  [opensource@...]

- Paul Madick  [paul.madick@...]

- Mark Gisi  [mark.gisi@...]  

 

Proposal

 

Statement of the problem:  The current SPDX Specification and License List have a limited language (i.e. and/or) that is not suitable for expressing complex license situations (for examples of such complexity, see http://wiki.spdx.org/view/FileNoticeExamples ).  Additionally, the current SPDX License List currently requires the addition of multiple licenses to the list in order to capture combinations of versions, the “or later” license genre (i.e. GPL-2.0 and GPL-2.0+) and the most common exceptions (i.e. GPL-2.0+-with-autoconf-exception and GPL-3.0-with-autoconf-exception). It should be noted that the SPDX Legal Team identified more than 30 discrete exceptions. Finally, license exceptions (i.e. autoconf-exception) are generally not versioned, and therefore, accounting for changes to the license exceptions when they are part of the canonical license creates opportunity for error and confusion.  For additional background please see http://wiki.spdx.org/view/Legal_Team/License_Expression_Review_1

 

Aim:  Improve the ability to describe more license variations utilizing some operator(s) without impact to the current timeline for the next version of the SPDX Specification.

 

Proposed Solution: 

(1)    “+” to be added to the SPDX Specification as an operator to denote “or later.”  As a result, all current licenses on the SPDX License List with a “Full Name” that includes “or later” will be deprecated. Deprecated means the license entry will technically remain on the list (just moved to the Deprecated section) and list users will be highly discouraged from using them. Deprecated licenses are potentially subject to removal in a future version of the list.

·         Example: The license GPL-2.0+ will be deprecated. License entry GPL-2.0 will remain on the SDPX license list and the following is still a valid license expression “GPL-2.0+”.  This state’s GPL-2.0 or later because the “+” now plays the role of a unary operator that means ‘the version of this license or a later version’. The following would also be a valid license expression as well: EPL-1.0+ which means EPL-1.0 or a later version. The change of the “+” to an operator will make even more sense once one considers license exceptions (modifiers) in the next section.

 

(2)    “WITH” binary operator (similar to AND/OR) to be added to the SPDX Specification. It denotes that the license identified by the SPDX short name identifier is modified by a well-defined exception on a new “SPDX Modifier List” as described in section (3).  As a result, all current licenses that include the term “exception” in the “Full Name” will be deprecated. 

·         Example: “GPL-2.0-with-bison-exception” will be deprecated but the following expression, which achieves the same result, is now valid: “GPL-2.0 WITH bison-exception”.

 

(3)    The Legal Team will be responsible for creating and maintaining the canonical list of SPDX License List modifiers (i.e. “auto-conf- exception, bison-exception”). It should be noted that licenses that are deprecated will be able to be expressed (more eloquently) with the new changes; hence no license will “fall off” the SPDX License List, nor will this create a compatibility issue.  URL references to all deprecated licenses will be maintained for full backward compatibility.

·         For example: the following is now a valid expression: “GPL-2.0+ WITH bison-exception” where the “+” and “WITH” operators allow a more flexible expression to be constructed. Prior to this addition this expression was not easy to express.

 

Longer Term Solution: Add capability for users to define modifier references local to an SPDX document, analogously the way LicRef is used for licenses not on the License List. This will involve adding “ModRef” to the SPDX Specification so the following would be a valid expression:  “GPL-2.0 WITH ModRef23.”  Where ModRef23 provides the text of a license modifier that does not appear on the SPDX Modifier List.  In the initial proposed solution, the way to express a file with a GPL-2.0 license with an exception, that is not included on the SPDX Modifier canonical List, will be by including the full text of the license and the exception as a single LicRef (which is the current state of affairs as well).

 

Rationale:  The proposed solution will provide the SPDX community the ability to express more licenses and license combinations in a more elegant and meaningful (human consumable) way then is currently available under the existing SPDX Specification and License List. To the extent that the SPDX community has come to rely on any of the licenses superseded by the new specifications those licenses will still be available on the SPDX License List (although deprecated).  Finally, the initial proposed solution is a major improvement to the current situation and is easily extensible to the even more flexible longer term solution without impacting the current timeline for SPDX 2.0.

 


_______________________________________________
Spdx-tech mailing list
Spdx-tech@...
https://lists.spdx.org/mailman/listinfo/spdx-tech

 


dmg
 


On Mon, Apr 14, 2014 at 6:38 AM, J Lovejoy <opensource@...> wrote:

Thus, by having the “+” as an operator, one could, theoretically, apply it to *any* license on the SPDX License List (I shudder…).  Someone might, for example, declare the license for a file as:  BSD-2-Clause +

I would (vehemently) argue that this would be incorrect in the sense that nothing in the text of BSD-2-Clause explicitly allows a licensee to apply other versions of the BSD license to the licensor’s work. (Furthermore, the BSD licenses are not “versioned” in the traditional chronological sense, but their differences denoted by the number of clauses, which does not, incidentally, correspond the chronological history of the license(s).)  I would further that the only way (that I can think of at the moment and would rather not think of at all!) you could end up with a disjunctive licensing situation amongst BSD variations, is if the work stated something along the lines of, “This file is licensed under a choice of either BSD-2-Clause or BSD-3-Clause.”  (Nevermind that such a disjunctive license choice would also seem somewhat pointless…), which would/could/should be expressed in an SPDX document as the usual way: BSD-2-Clause OR BSD-3-Clause (more shuddering… One would then hope and pray that the Concluded License field provided the given choice and some kind of explanation for this ;)


sorry everybody that I have been disconnected from this discussion. I hope to be of some help.

I think the + operator is a great one, but in a way it is equivalent to a "WITH +". 

From what I have seen, it is the text of the license statement of the file, not in the license itself. The license statement is the one that makes it clear what "+" is in these circumstances.

I have seen two situations where the GPL or newer version is not used in the standard way. 

Take for example this license (svnkit/TMate):


/*
 * ====================================================================
 * Copyright (c) 2004-2012 TMate Software Ltd.  All rights reserved.
 *
 * This software is licensed as described in the file COPYING, which
 * you should have received as part of this distribution.  The terms
 * are also available at http://svnkit.com/license.html.
 * If newer versions of this license are posted there, you may use a
 * newer version instead, at your option.
 * ====================================================================
 */
Notice that this is the perfect use of the + operator. However, we still don't know what the license is. In other words, it can apply to any license!!!!!
In this specific case the license is the TMate license (a hydra-like license with terms that try to make it a BSD-ish-reciprocal license) see: 
    http://svn.svnkit.com/repos/svnkit/trunk/LICENSE.txt
the other one is by the KDE foundation, and this one applies specifically to the GPL-3:
 *   This program is free software; you can redistribute it and/or modify    *
 *   it under the terms of the GNU Lesser General Public License as          *
 *   published by the Free Software Foundation; either version 2.1 of the    *
 *   License, or (at your option) version 3, or any later version accepted   *
 *   by the membership of KDE e.V. (or its successor approved by the         *
 *   membership of KDE e.V.), which shall act as a proxy defined in          *
 *   Section 6 of version 3 of the license.  
I think you need to be more careful about the + operator to avoid these situations. I feel the + operator a syntactic sugar for the more generic
"WITH any newer version of the license as defined by the license steward. For example the MPL-2 has this operator already embedded in the license (section 10.1)
I hope this makes sense

--dmg



--
--dmg

---
Daniel M. German
http://turingmachine.org


dmg
 

On Mon, Jun 9, 2014 at 5:29 PM, dmg <dmg@...> wrote:
the other one is by the KDE foundation, and this one applies specifically to
the GPL-3:

Oops. I should have said the LGPLv2.1 or the LGPLv3. So this is more
like a (LGPL v2.1 OR LGPLv3) WITH (+ modified approved by the KDE
Foundation)

--dmg


--
--dmg

---
Daniel M. German
http://turingmachine.org