appendix-IV: Refactor the license expression appendix #37

wking · 2017-09-13T22:17:18Z

This is a large diff, but I aimed for restructuring/polishing without changing the end result. I did make a few minor, intentional changes:

Extended license-id to include appendix I.3 (deprecated licenses). We don't want folks using these in license expressions (because they're deprecated), but they are valid (or we would have removed them instead of just deprecating them). That means that in some cases the nature of a string is unclear. For example GPL-1.0+ could be the depreacted license-id, or it could be a simple-expression using the non-deprecated GPL-1.0 license-id and the + operator. I don't think that's a problem though, because I can't think of a case where the ambiguity would matter.
I've allowed + for license-ref (it used to be only for license-id). There could be external licenses which offer a choice between only-this-version and or-later grants, and allowing + for license-ref makes it easier to support those licenses as they transition into the SPDX License List. This isn't a big deal, but it avoids needing separate license-refs for the only-this-version and or-later grants if you need both.
I've added explicit whitespace handling, vs. the previous version which just discussed it in the text. That way the ABNF is the sole source of normative syntax information.
I've added enclosed-license-expression, so consumers like the tag:value format can suggest/require it. This allows for more precision in consumers (e.g. appendix V should be updated to require enclosed-license-expression), but I've left those other sections alone for this commit. Ideally the tag:value line would be moved to a separate section that defined the tag-value format, but we don't have such a section yet.

Also, it seems odd that there's no way to define an external license exception (LicenseExceptionRef?). But I haven't touched that in this commit.

The RDF/XML bindings seem to have some holes around the + and WITH operators. I've left some FIXMEs where I think we need adjustments.

wking · 2017-10-12T23:12:57Z

Cross linking:

An old spdx Bugzilla issue with ABNF discussion.
What does the spec say about parentheses? jslicense/spdx-expression-parse.js#20 with ABNF discussion.

sschuberth · 2017-10-16T07:33:01Z

FYI, I already had implemented LicenseExpressionParser: Allow "+" as part of license-refs as part of spdx/tools#66, but back then we couldn't reach a consensus about that on the mailing list IIRC, so I closed my PR unmerged.

goneall · 2017-10-19T16:09:48Z

@sschuberth - Do you recall where we left the conversation? I couldn't easily find the email thread. In reviewing your pull request, the tool changes look reasonable but I don't recall if there was a concern raised earlier.

wking · 2017-10-19T16:19:15Z

Some previous discussion in [1,2,3,4]. [4] looks like #16. But I haven't gone through those threads carefully enough to post a summary yet. [1]: https://lists.spdx.org/pipermail/spdx-tech/2015-October/002855.html Subject: Is "+" a valid character of a LicenseRef idstring? Date: Wed Oct 28 09:28:20 UTC 2015 [2]: https://lists.spdx.org/pipermail/spdx-tech/2015-November/002874.html Subject: Is "+" a valid character of a LicenseRef idstring? Date: Mon Nov 2 09:56:47 UTC 2015 [3]: https://lists.spdx.org/pipermail/spdx-tech/2015-December/002966.html Subject: [Bug 1333] New: SPDX SPEC fails to discuss whitespace Date: Tue Dec 8 16:54:54 UTC 2015 [4]: https://lists.spdx.org/pipermail/spdx-tech/2015-December/002986.html Subject: [Bug 1326] Inconsistency whether "+" is a valid character in LicenseRef ID strings Date: Tue Dec 22 18:17:39 UTC 2015

sschuberth · 2017-10-19T16:20:27Z

@goneall, I also couldn't find the email thread again, but AFAIR my PR would need to take the SPDX version into account, which would have made the already quite ugly code even more ugly, so I decided to not further work on this.

goneall · 2017-10-19T21:44:32Z

After reading through the history, it looks like we decided to deprecate the + in the license ID's which would allow for it to be used in license-ref's for version 2.1 or later.

I'll think about the code a bit more - I agree with @sschuberth that it would be quite messy to check for the version. That being said, we should update the tools to handle this case.

goneall

Made a complete pass through and suggested items for FIXME's plus a few additional comments

goneall · 2017-10-19T22:00:26Z

chapters/appendix-IV-SPDX-license-expressions.md

-For instance, the following expression:
+### IV.3.1 The `+` Operator <a name="IV.3.1"></a>
+
+FIXME: How are you supposed to cover this in XML?


The following text can be added:
The + operator can be expressed in XML via a <spdx:OrLaterOperator> element, with a single spdx:member property for the license preceeding the + operator.

<spdx:OrLaterOperator> <spdx:member rdf:resource="http://spdx.org/licenses/GPL-2.0"/> </spdx:OrLaterOperator>

Addressed in cf8decf → 9c8d189.

goneall · 2017-10-19T22:08:06Z

chapters/appendix-IV-SPDX-license-expressions.md


-A conjunctive license can be expressed in RDF via a `<spdx:ConjunctiveLicenseSet>` element, with an spdx:member property for each element in the conjunctive license. Two or more members are required.
+    FIXME: I don't think this element makes sense.  What you want is a way to represent a `simple-expression` based on `WITH`.  This subsection seems to be focused on defining exceptions, but it does not cover *consuming* those license exceptions.  And “and exception … to which the exception applies” is really not clear; is it the left or right `WITH` operand?  What happens for licenses/exceptions that are not in the SPDX License List?


There is another SPDX class that needs to be described. The With operator:

The WITH operator can be expressed in XML via a <spdx:WithExceptionOperator> element, with an spdx:member property for the license and an spdx:licenseException property for the exception.

<spdx:WithExceptionOperator> <spdx:member rdf:resource="http://spdx.org/licenses/GPL-2.0"/> <spdx:licenseException rdf:resource="https://spdx.org/licenses/FLTK-exception"> </spdx:WithExceptionOperator>

The WITH operator can be expressed in XML via a <spdx:WithExceptionOperator> element…

That makes sense to me. But I expect we want to drop the <spdx:LicenseException> element, because as far as I can tell we provide no other way for authors to define exceptions. They can only use exceptions from our list, or they can define a LicenseID-* that includes both the license and the exception. But I see nowhere outside of this appendix that suggests they can define their own exceptions.

The reference for the <spdx:LicenseException> is still of value for those wanting to parse the details out of the exception. We may want to move this to a different section, however, so we don't confuse the reader as to whether they can define license exceptions. Feel free to remove it for now and we can add it back in when we document the other fields.

goneall · 2017-10-19T22:11:20Z

chapters/appendix-IV-SPDX-license-expressions.md

+simple-expression           = license ["+"] [space "WITH" space license-exception-id]
+binary-compound-operator    = "AND" / "OR"
+license-expression          = simple-expression
+                            / license-expression space binary-license-operator space license-expression


binary-license-operator -> binary-compound-operator

binary-license-operator -> binary-compound-operator

I'll go with binary-expression-operator because the arguments are license-expressions.

Addressed in cf8decf → 9c8d189.

goneall · 2017-10-19T22:15:11Z

chapters/appendix-IV-SPDX-license-expressions.md


-compound-expression = 1*1(simple-expression /
+Tag:value authors SHOULD use `enclosed-license-expression` instead of the more general `license-expression`.


SHOULD -> MUST - this is a rule we agreed to to enable machine parsing

SHOULD -> MUST - this is a rule we agreed to to enable machine parsing

But 2.1 uses:

For the Tag:value format, any license expression that consists of more than one license identifier and/or LicenseRef, should be encapsulated by parentheses

I think making this stricter without a major version bump is a bit dicey, especially with wild exceptions that don't set those enclosing parens.

On the other hand, the tag:value format is currently poorly spec'ed, so I guess we can always tell broken docs and tools “sorry, but you should have known you were making assumptions about the eventual format once it was spec'ed out”.

@wking Good point - I would like to "correct" the 2.1 spec.

This was highly debated at the time, but I believe there was a consensus to require the parenthesis. I do know that my parser would break without the parenthesis and I believe the syntax is ambiguous making it unreliable for any implementation of a parser for tag/value @kestewart - let me know if you agree we can change this to "must".

I do know that my parser would break without the parenthesis and I believe the syntax is ambiguous making it unreliable for any implementation of a parser for tag/value…

Parsers can be patched, but the data they're parsing may be historical (like the wild example I link above). I'm interested in having new parsers be able to parse as many existing declarations as is reasonably possible. I'm less worried about breaking existing parsers.

@wking This was discussed and resolved during 2.1 development that tag/value files need parenthesis if the expression is complex. I consider it a defect in the spec that this wasn't worded as a must. The reference to parsers is just pointing out the implications of not documenting what was agreed to.

Since you disagree, why don't you keep it as should and I'll create my own pull request after yours is complete to change it to must. That way it will not appear that you are requesting a change that you disagree with. We can then pick up the debate on the new pull request.

IMHO In most cases parens are not needed and just make the expression heavier and ugly looking for no good reason. I think that rather than mandating them, we should relax their use in upcoming spec versions.

Also in the common case it never makes sense to have multi-line expressions .... so we should IMHO state that expression MUST be a single line. In doing so you make things cleaner and simpler.

IMHO In most cases parens are not needed and just make the expression heavier and ugly looking for no good reason.

“We want an unambiguous way to identify the end of this value” is a good reason. Requiring (or at least strongly recommending) enclosing parens is one way to do that. Defining clear folding-whitespace rules (#44, #45) is another way. Forbidding newlines in values is a third way. All of those approaches have pros and cons, especially in the context of (backwards) compatibility.

And debating this particular issue was not a priority for this PR. Just tell me what I need to say here to get this landed, and we can come back and kick this particular point around in follow-up work (e.g. #44 and #45).

goneall · 2017-10-19T22:18:27Z

chapters/appendix-IV-SPDX-license-expressions.md

+
+### IV.3.3 Conjunctive `AND` Operator <a name="IV.3.3"></a>
+
+A [conjunctive license](#IV.2.3) can be expressed in XML via a `<spdx:ConjunctiveLicenseSet>` element, with an `spdx:member` property for each element in the conjunctive license.  Two or more members are required.

    <spdx:ConjunctiveLicenseSet>
        <spdx:member rdf:resource="http://spdx.org/licenses/GPL-2.0"/>
        <spdx:ExtractedLicensingInfo rdf:about="http://example.org#LicenseRef-EternalSurrender">


I think this is a missing spdx:member which should enclose the ExtractedLicensingInfo

Addressed in cf8decf → 9c8d189.

This is a large diff, but I aimed for restructuring/polishing without changing the end result. I did make a few minor, intentional changes: * Extended license-id to include appendix I.3 (deprecated licenses). We don't want folks using these in license expressions (because they're deprecated), but they are valid (or we would have removed them instead of just deprecating them). That means that in some cases the nature of a string is unclear. For example 'GPL-1.0+' could be the depreacted license-id, or it could be a simple-expression using the non-deprecated GPL-1.0 license-id and the + operator. I don't think that's a problem though, because I can't think of a case where the ambiguity would matter. * I've allowed + for license-ref (it used to be only for license-id). There could be external licenses which offer a choice between only-this-version and or-later grants, and allowing + for license-ref makes it easier to support those licenses as they transition into the SPDX License List. This isn't a big deal, but it avoids needing separate license-refs for the only-this-version and or-later grants if you need both. * I've added explicit whitespace handling, vs. the previous version which just discussed it in the text. That way the ABNF is the sole source of normative syntax information. * I've added enclosed-license-expression, so consumers like the tag:value format can suggest/require it. This allows for more precision in consumers (e.g. appendix V should be updated to require enclosed-license-expression), but I've left those other sections alone for this commit. Ideally the tag:value line would be moved to a separate section that defined the tag-value format, but we don't have such a section yet [1]. * I've added Gary's documentation for spdx:OrLaterOperator [2]; previously there was no way to represent the + operator in RDF/XML. Also, it seems odd that there's no way to define an external license exception (LicenseExceptionRef?). But I haven't touched that in this commit. The RDF/XML bindings seem to have a hole around the WITH operators. I've left a FIXME where I think we need adjustments. The HTML comment avoids the ambiguous four-space indent after the list. Without the comment, it could be parsed as a code block (which is what we want) [3] or a second paragraph of the final list entry [4] (which is not what we want). The HTML comment closes the list to resolve the ambiguity. [1]: spdx#22 (comment) [2]: spdx#37 (comment) [3]: https://daringfireball.net/projects/markdown/syntax#precode "To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab" [4]: https://daringfireball.net/projects/markdown/syntax#list "Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab"

wking · 2017-10-20T19:07:03Z

I've pushed cf8decf → 9c8d189 addressing some of @goneall's points and including a few more copy-edits. Outstanding issues are:

Whether we want to keep <spdx:LicenseException> now that we're adding <spdx:WithExceptionOperator> (thread).
Whether we want SHOULD or MUST for tag:values using enclosed-license-expression (thread).

This is a large diff, but I aimed for restructuring/polishing without changing the end result (much). I did make a few intentional changes: * Extended license-id to include appendix I.3 (deprecated licenses). We don't want folks using these in license expressions (because they're deprecated), but they are valid (or we would have removed them instead of just deprecating them). That means that in some cases the nature of a string is unclear. For example 'GPL-1.0+' could be the depreacted license-id, or it could be a simple-expression using the non-deprecated GPL-1.0 license-id and the + operator. I don't think that's a problem though, because I can't think of a case where the ambiguity would matter. * I've allowed + for license-ref (it used to be only for license-id). There could be external licenses which offer a choice between only-this-version and or-later grants, and allowing + for license-ref makes it easier to support those licenses as they transition into the SPDX License List. This isn't a big deal, but it avoids needing separate license-refs for the only-this-version and or-later grants if you need both. * I've added explicit whitespace handling, vs. the previous version which just discussed it in the text. That way the ABNF is the sole source of normative syntax information. * I've added enclosed-license-expression, so consumers like the tag:value format can suggest/require it. This allows for more precision in consumers (e.g. appendix V should be updated to require enclosed-license-expression), but I've left those other sections alone for this commit. Ideally the tag:value line would be moved to a separate section that defined the tag-value format, but we don't have such a section yet [1]. * I've added Gary's documentation for spdx:OrLaterOperator [2]; previously there was no way to represent the + operator in RDF/XML. * I've added Gary's documentation for spdx:WithExceptionOperator [3]. I think it's a bit odd that the XML operator represetation are using URLs instead of the SPDX IDs that the license expression syntax calls for. That means you cannot convert between the two representations without an ID <-> URL map. But we can address that later. * I've removed spdx:LicenseException, because we currently provide no other way for authors to define license exceptions. We do define a way for them to define their own licenses [4], and currently authors have to use that to give a LicenseRef to a license+exception pair if their exception is not in our list. Gary feels like we may return to this later (and I'd be happy giving users a way to define their own exceptions), but we're removing it for now [5]. The HTML comment avoids the ambiguous four-space indent after the list. Without the comment, it could be parsed as a code block (which is what we want) [6] or a second paragraph of the final list entry [7] (which is not what we want). The HTML comment closes the list to resolve the ambiguity. [1]: spdx#22 (comment) [2]: spdx#37 (comment) [3]: spdx#37 (comment) [4]: https://github.com/spdx/spdx-spec/blob/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/6-other-licensing-information-detected.md#6.1 [5]: spdx#37 (comment) [6]: https://daringfireball.net/projects/markdown/syntax#precode "To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab" [7]: https://daringfireball.net/projects/markdown/syntax#list "Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab"

wking · 2017-10-20T23:32:19Z

I've pushed 9c8d189 → 922031a dropping <spdx:LicenseException> and adding <spdx:WithExceptionOperator> now that @goneall gave that a green light. We may come back to external extention definitions in follow-up work.

We've also agreed to punt the tag:value enclosed-license-expression SHOULD/MUST to follow-up work.

I'm not aware of any outstanding change requests for this PR.

goneall · 2017-10-21T00:46:13Z

@wking thanks for all the updates. I like the current state of the files.

@kestewart if you get a chance - could you review as well? I would like to merge this in so that I can re-raise the must/should parenthesis discussions.

pombredanne · 2017-11-14T08:29:57Z

I've allowed + for license-ref (it used to be only for license-id). There could be external licenses which offer a choice between only-this-version and or-later grants, and allowing + for license-ref makes it easier to support those licenses as they transition into the SPDX License List. This isn't a big deal, but it avoids needing separate license-refs for the only-this-version and or-later grants if you need both.

This does not make sense to me at all. A ref is a ref. This is not an ID. This is easy to implement but just has no clear basis. And it opens a can of worms that make things complicated otherwise. Should you have one text for each of a + and base ref version or only one?

wking · 2017-11-14T09:21:04Z

On Tue, Nov 14, 2017 at 08:29:58AM +0000, Philippe Ombredanne wrote: > I've allowed + for license-ref (it used to be only for license-id)… This does not make sense to me at all. A ref is a ref. This is not an ID.

I see very little space between license identifiers defined on the license list (e.g. ‘GPL-3.0’) and a license identifier defined by a third party (e.g. ‘LicenseRef-MIT-Style-1’) besides whether you have commit rights to the SPDX license list. In both cases, there is a license, and somebody is giving it a handful of characters as an identifier. I don't see a reason to support operators for identifiers coined by the SPDX but then to not support those same operators for identifiers coined by someone else.

And it opens a can of worms that make things complicated otherwise. Should you have one text for each of a + and base ref version or only one?

Only one. This is somewhat up in the air with [1]'s hard-coded approach which removes the + operator entirely (or maybe just in some cases?). But regardless of how that shakes out, the motivation here is to treat SPDX-created IDs and third-party-created IDs with the same logic. So however many copies of the GPL 2.0 the SPDX wants to keep to support its various versioned grants, third parties should be able to keep that many as well, and use the same operators to craft grants based on their LicenseRef identifiers. [1]: https://wiki.spdx.org/view/Legal_Team/Minutes/2017-11-09#Agenda

This is a large diff, but I aimed for restructuring/polishing without changing the end result (much). I did make a few intentional changes: * Extended license-id to include appendix I.3 (deprecated licenses). We don't want folks using these in license expressions (because they're deprecated), but they are valid (or we would have removed them instead of just deprecating them). That means that in some cases the nature of a string is unclear. For example 'GPL-1.0+' could be the depreacted license-id, or it could be a simple-expression using the non-deprecated GPL-1.0 license-id and the + operator. I don't think that's a problem though, because I can't think of a case where the ambiguity would matter. * I've allowed + for license-ref (it used to be only for license-id). There could be external licenses which offer a choice between only-this-version and or-later grants, and allowing + for license-ref makes it easier to support those licenses as they transition into the SPDX License List. This isn't a big deal, but it avoids needing separate license-refs for the only-this-version and or-later grants if you need both. * I've added explicit whitespace handling, vs. the previous version which just discussed it in the text. That way the ABNF is the sole source of normative syntax information. * I've added enclosed-license-expression, so consumers like the tag:value format can suggest/require it. This allows for more precision in consumers (e.g. appendix V should be updated to require enclosed-license-expression), but I've left those other sections alone for this commit. Ideally the tag:value line would be moved to a separate section that defined the tag-value format, but we don't have such a section yet [1]. * I've added Gary's documentation for spdx:OrLaterOperator [2]; previously there was no way to represent the + operator in RDF/XML. * I've added Gary's documentation for spdx:WithExceptionOperator [3]. I think it's a bit odd that the XML operator represetation are using URLs instead of the SPDX IDs that the license expression syntax calls for. That means you cannot convert between the two representations without an ID <-> URL map. But we can address that later. * I've removed spdx:LicenseException, because we currently provide no other way for authors to define license exceptions. We do define a way for them to define their own licenses [4], and currently authors have to use that to give a LicenseRef to a license+exception pair if their exception is not in our list. Gary feels like we may return to this later (and I'd be happy giving users a way to define their own exceptions), but we're removing it for now [5]. * I've fleshed out the documentation for the + operator to explain how it works with the AGPL-1.0. Without this explaination, I think there's a risk that folks misinterpret ${ROOT}-${BASE_VERSION}+ as "allows ${ROOT}-${VERSION} for any ${VERSION} >= ${BASE_VERSION}", but that's not true. Instead the proper interpretation is "allows ${ROOT}-${VERSION} and any other licenses allowed by ${ROOT-VERSION} which are based on 'any later version' grant". For example, if the AGPL-2.0 had not been released, you could distribute AGPL-1.0+ code under the GPL-3.0+, but *not* under the AGPL-3.0+. The HTML comment avoids the ambiguous four-space indent after the list. Without the comment, it could be parsed as a code block (which is what we want) [6] or a second paragraph of the final list entry [7] (which is not what we want). The HTML comment closes the list to resolve the ambiguity. [1]: spdx#22 (comment) [2]: spdx#37 (comment) [3]: spdx#37 (comment) [4]: https://github.com/spdx/spdx-spec/blob/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/6-other-licensing-information-detected.md#6.1 [5]: spdx#37 (comment) [6]: https://daringfireball.net/projects/markdown/syntax#precode "To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab" [7]: https://daringfireball.net/projects/markdown/syntax#list "Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab"

wking · 2017-12-28T17:33:00Z

I've pushed 922031a → eafa739 which restores semantic docs for + (which I'd accidentally dropped with 922031a) and adds a new explanation of the AGPL-1.0+ based on this reasoning.

This is a large diff, but I aimed for restructuring/polishing without changing the end result (much). I did make a few intentional changes: * Extended license-id to include appendix I.3 (deprecated licenses). We don't want folks using these in license expressions (because they're deprecated), but they are valid (or we would have removed them instead of just deprecating them). That means that in some cases the nature of a string is unclear. For example 'GPL-1.0+' could be the depreacted license-id, or it could be a simple-expression using the non-deprecated GPL-1.0 license-id and the + operator. I don't think that's a problem though, because I can't think of a case where the ambiguity would matter. * I've allowed + for license-ref (it used to be only for license-id). There could be external licenses which offer a choice between only-this-version and or-later grants, and allowing + for license-ref makes it easier to support those licenses as they transition into the SPDX License List. This isn't a big deal, but it avoids needing separate license-refs for the only-this-version and or-later grants if you need both. * I've added explicit whitespace handling, vs. the previous version which just discussed it in the text. That way the ABNF is the sole source of normative syntax information. * I've added enclosed-license-expression, so consumers like the tag:value format can suggest/require it. This allows for more precision in consumers (e.g. appendix V should be updated to require enclosed-license-expression), but I've left those other sections alone for this commit. Ideally the tag:value line would be moved to a separate section that defined the tag-value format, but we don't have such a section yet [1]. * I've added Gary's documentation for spdx:OrLaterOperator [2]; previously there was no way to represent the + operator in RDF/XML. * I've added Gary's documentation for spdx:WithExceptionOperator [3]. I think it's a bit odd that the XML operator represetation are using URLs instead of the SPDX IDs that the license expression syntax calls for. That means you cannot convert between the two representations without an ID <-> URL map. But we can address that later. * I've removed spdx:LicenseException, because we currently provide no other way for authors to define license exceptions. We do define a way for them to define their own licenses [4], and currently authors have to use that to give a LicenseRef to a license+exception pair if their exception is not in our list. Gary feels like we may return to this later (and I'd be happy giving users a way to define their own exceptions), but we're removing it for now [5]. * I've fleshed out the documentation for the + operator to explain how it works with the AGPL-1.0. Without this explaination, I think there's a risk that folks misinterpret ${ROOT}-${BASE_VERSION}+ as "allows ${ROOT}-${VERSION} for any ${VERSION} >= ${BASE_VERSION}", but that's not true. Instead the proper interpretation is "allows ${ROOT}-${VERSION} and any other licenses allowed by ${ROOT-VERSION} which are based on 'any later version' grant". For example, if the AGPL-2.0 had not been released, you could distribute AGPL-1.0+ code under the GPL-3.0+, but *not* under the AGPL-3.0+. The HTML comment avoids the ambiguous four-space indent after the list. Without the comment, it could be parsed as a code block (which is what we want) [6] or a second paragraph of the final list entry [7] (which is not what we want). The HTML comment closes the list to resolve the ambiguity. [1]: spdx#22 (comment) [2]: spdx#37 (comment) [3]: spdx#37 (comment) [4]: https://github.com/spdx/spdx-spec/blob/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/6-other-licensing-information-detected.md#6.1 [5]: spdx#37 (comment) [6]: https://daringfireball.net/projects/markdown/syntax#precode "To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab" [7]: https://daringfireball.net/projects/markdown/syntax#list "Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab"

This is a large diff, but I aimed for restructuring/polishing without changing the end result (much). I did make a few intentional changes: * Extended license-id to include appendix I.3 (deprecated licenses). We don't want folks using these in license expressions (because they're deprecated), but they are valid (or we would have removed them instead of just deprecating them). That means that in some cases the nature of a string is unclear. For example 'GPL-1.0+' could be the depreacted license-id, or it could be a simple-expression using the more-recently-deprecated GPL-1.0 license-id and the + operator. I don't think that's a problem though, because I can't think of a case where the ambiguity would matter. * I've allowed + for license-ref (it used to be only for license-id). There could be external licenses which offer a choice between only-this-version and or-later grants, and allowing + for license-ref makes it easier to support those licenses as they transition into the SPDX License List. This isn't a big deal, but it avoids needing separate license-refs for the only-this-version and or-later grants if you need both. * I've added explicit whitespace handling, vs. the previous version which just discussed it in the text. That way the ABNF is the sole source of normative syntax information. * I've added a paragraph addressing casing, based on discussion in [1]. * I've added enclosed-license-expression, so consumers like the tag:value format can suggest/require it. This allows for more precision in consumers (e.g. appendix V should be updated to require enclosed-license-expression), but I've left those other sections alone for this commit. Ideally the tag:value line would be moved to a separate section that defined the tag-value format, but we don't have such a section yet [2]. * I've added Gary's documentation for spdx:OrLaterOperator [3]; previously there was no way to represent the + operator in RDF/XML. * I've added Gary's documentation for spdx:WithExceptionOperator [4]. I think it's a bit odd that the XML operator represetation are using URLs instead of the SPDX IDs that the license expression syntax calls for. That means you cannot convert between the two representations without an ID <-> URL map. But we can address that later. * I've removed spdx:LicenseException, because we currently provide no other way for authors to define license exceptions. We do define a way for them to define their own licenses [5], and currently authors have to use that to give a LicenseRef to a license+exception pair if their exception is not in our list. Gary feels like we may return to this later (and I'd be happy giving users a way to define their own exceptions), but we're removing it for now [6]. * I've fleshed out the documentation for the + operator to explain how it works with the AGPL-1.0. Without this explaination, I think there's a risk that folks misinterpret ${ROOT}-${BASE_VERSION}+ as "allows ${ROOT}-${VERSION} for any ${VERSION} >= ${BASE_VERSION}", but that's not true. Instead the proper interpretation is "allows ${ROOT}-${VERSION} and any other licenses allowed by ${ROOT-VERSION} which are based on 'any later version' grant". For example, if the AGPL-2.0 had not been released, you could distribute AGPL-1.0-or-later code under the GPL-3.0-or-later, but *not* under the AGPL-3.0-or-later. The HTML comment avoids the ambiguous four-space indent after the list. Without the comment, it could be parsed as a code block (which is what we want) [7] or a second paragraph of the final list entry [8] (which is not what we want). The HTML comment closes the list to resolve the ambiguity. [1]: spdx#63 [2]: spdx#22 (comment) [3]: spdx#37 (comment) [4]: spdx#37 (comment) [5]: https://github.com/spdx/spdx-spec/blob/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/6-other-licensing-information-detected.md#6.1 [6]: spdx#37 (comment) [7]: https://daringfireball.net/projects/markdown/syntax#precode "To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab" [8]: https://daringfireball.net/projects/markdown/syntax#list "Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab"

wking · 2018-06-05T19:24:49Z

I've pushed 649889f -> afc5c1e, rebasing onto master (around conflicts with eafa739 and b971d8d). I've also adjusted to the new -only and -or-later forms which happend in license list v3.0 and added a paragraph addressing case-senstivity for #63. We should get spdx/license-list-XML#651 landed an a list release cut so we have a nice place to link from the spec when discussing case-uniqueness commitments. Once that happens, I'll rebase this PR again to pick up the nicer link.

iamwillbar · 2020-01-22T19:41:01Z

@goneall and @kestewart, what are your thoughts on this PR for 2.2 vs 3.0?

goneall · 2020-01-23T00:28:44Z

@iamwillbar @kestewart I'm thinking 3.0. There are a large number of issues mixed into this one PR. Resolving all of these will likely take a few tech calls.

wking · 2020-01-23T03:22:30Z

I'm happy to split this up if you want to lay out how you want it divided :)

goneall · 2020-01-29T23:13:51Z

@wking Thanks for the offer to split it up. I think the controversial items to be excluded would be the + operator changes for licenseRef's and the parenthesis "MUST" requirement.

The fixes to the RDF would be nice to get into the 2.2 release.

@kestewart Can you take a look and let us know if you agree with that split.

kestewart · 2024-02-05T17:56:01Z

Closing this as stale. If disagree, please reopen.

goneall · 2024-04-03T21:42:01Z

This PR is rather stale - closing. If we want to refactor, we should refactor the current version in the development/v3.0 branch.

wking force-pushed the license-expression-cleanup branch 2 times, most recently from 00840fe to cf8decf Compare September 13, 2017 22:27

sschuberth requested a review from tsteenbe September 18, 2017 09:18

wking mentioned this pull request Sep 22, 2017

Request to add license test files for a different use case spdx/license-test-files#2

Open

This was referenced Oct 12, 2017

Clarify use of newlines for license expressions used in source files #45

Closed

Clarify the use of newlines in license expressions in Appendix IV #44

Closed

goneall requested changes Oct 19, 2017

View reviewed changes

wking force-pushed the license-expression-cleanup branch from cf8decf to 9c8d189 Compare October 20, 2017 18:57

wking force-pushed the license-expression-cleanup branch from 9c8d189 to 922031a Compare October 20, 2017 23:29

wking mentioned this pull request Nov 9, 2017

Add “NONE” to the license expression syntax #49

Open

wking mentioned this pull request Dec 13, 2017

chapters/3: Explicit external-reference ABNF #54

Closed

wking force-pushed the license-expression-cleanup branch from 922031a to eafa739 Compare December 28, 2017 17:30

wking force-pushed the license-expression-cleanup branch from eafa739 to 649889f Compare December 28, 2017 17:35

wking mentioned this pull request Jan 1, 2018

*GPL -or-later and -only in sidebar instructions github/choosealicense.com#563

Merged

wking mentioned this pull request Jan 2, 2018

Simplify license expression grammar in Appendix IV #62

Closed

wking mentioned this pull request Jan 12, 2018

AGPL-1.0: Deprecate AGPL-1.0 in favor of -only and -or-later forms spdx/license-list-XML#599

Merged

wking force-pushed the license-expression-cleanup branch from 649889f to afc5c1e Compare June 5, 2018 19:19

This was referenced Jun 14, 2018

README: Make an explicit commitment to case-insensitive uniqueness spdx/license-list-XML#651

Closed

Update references to GNU-family licenses in spec #89

Closed

sol mentioned this pull request Jul 13, 2018

Ignore case when matching SPDX identifiers haskell/cabal#5432

Closed

4 tasks

iamwillbar added this to the 3.0 milestone Jan 23, 2020

tsteenbe added the on hold label May 17, 2022

goneall closed this Apr 3, 2024


		A conjunctive license can be expressed in RDF via a `<spdx:ConjunctiveLicenseSet>` element, with an spdx:member property for each element in the conjunctive license. Two or more members are required.
		FIXME: I don't think this element makes sense. What you want is a way to represent a `simple-expression` based on `WITH`. This subsection seems to be focused on defining exceptions, but it does not cover consuming those license exceptions. And “and exception … to which the exception applies” is really not clear; is it the left or right `WITH` operand? What happens for licenses/exceptions that are not in the SPDX License List?


		compound-expression = 1*1(simple-expression /
		Tag:value authors SHOULD use `enclosed-license-expression` instead of the more general `license-expression`.

appendix-IV: Refactor the license expression appendix #37

appendix-IV: Refactor the license expression appendix #37

Conversation

wking commented Sep 13, 2017

wking commented Oct 12, 2017

sschuberth commented Oct 16, 2017

goneall commented Oct 19, 2017

wking commented Oct 19, 2017 via email

sschuberth commented Oct 19, 2017

goneall commented Oct 19, 2017

goneall left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wking commented Oct 20, 2017

wking commented Oct 20, 2017

goneall commented Oct 21, 2017

pombredanne commented Nov 14, 2017

wking commented Nov 14, 2017 via email • edited Loading

wking commented Dec 28, 2017

wking commented Jun 5, 2018

iamwillbar commented Jan 22, 2020

goneall commented Jan 23, 2020

wking commented Jan 23, 2020

goneall commented Jan 29, 2020

kestewart commented Feb 5, 2024

goneall commented Apr 3, 2024

wking commented Nov 14, 2017 via email •

edited

Loading