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 <[email protected]
> 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<http://spdx.org/news/2014-04-01/open-collaboration-changes-everything...including-spdx>,
> 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 [[email protected]]
>
> - Paul Madick [[email protected]]
>
> - Mark Gisi [m
> <[email protected]>[email protected]<[email protected]>]
>
>
>
> *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
> [email protected]
> https://lists.spdx.org/mailman/listinfo/spdx-tech
>
>
_______________________________________________
Spdx-legal mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-legal
