Simplify license expression grammar in Appendix IV

[kestewart]

This was https://bugs.linuxfoundation.org/show_bug.cgi?id=1334

Kate Stewart 2015-12-08 16:57:25 UTC
From David Wheeler on December 4, 2015

The current Appendix IV is also overly complex and confusing:

• There's no need to have "compound-expression" as separate from "license-expression". The "license-expression" is defined to be either simple or compound, but a simple-expression is also a legal compound-expression, so the whole indirection is unnecessary and confusing.

• In simple-expression, the "+" should just optionally follow license-id; that's how anyone would parse it, and it's easier to explain too.

So I suggest replacing simple-expression, compound-expression (to be removed), and license-expression with this simpler spec:

simple-expression = license-id ["+"] / license-ref

license-expression =   simple-expression [ "WITH" license-exception-id ] /

  license-expression "AND" license-expression /

  license-expression "OR" license-expression /

  "(" license-expression ")"

You could change simple-expression to be:

simple-expression = license-id ["+"][ "WITH" license-exception-id ] / license-ref and omit the ["WITH...] in the following line, but I like the idea of allowing a license-ref with a standard exception. Besides, that's currently allowed, no reason to remove this functionality.

Both this and the original description are silent about left-to-right or right-to-left; I don't think it matters, but if someone wants things to be parsed identically, perhaps that should be mentioned.

I can imagine adding suffixes like "!" (I'm sure it's only this particular version of the license) or "?" (I'm not sure that it's limited to this particular version of the license), in addition to "+".

However, that's a separate discussion.

Also: is there any reason to FORBID the "+" suffix after a license-ref or license-exception-id?

In particular, someone might use a license-ref while waiting for a license to be added to the SPDX license list or exception list.

A way Would change my proposal grammar above to:

simple-expression = license-id / license-ref

license-expression =   simple-expression ["+"] [ "WITH" license-exception-id ["+"] ] /

Kate Stewart 2015-12-15 18:34:44 UTC
From discussion on 20151215 - Mark wants to confirm that the revised version still works in his encoding. Other than that, simpler is better, so once its proven out, we'll look at changing this in the 2.1 spec.

Bill Schineller 2016-05-17 17:35:11 UTC
Mark?

[kestewart]

Note: There has been recent discussion of the grammar in 2017 that needs to be added here.

[wking]

On Tue, Jan 02, 2018 at 08:04:54PM +0000, Kate Stewart wrote: * There's no need to have "compound-expression" as separate from "license-expression".

I'm dropping ‘compound-expression’ in #37.

* In simple-expression, the "+" should just optionally follow license-id; that's how anyone would parse it, and it's easier to explain too.

This is also done in #37.

simple-expression = license-id ["+"] / license-ref license-expression = simple-expression [ "WITH" license-exception-id ] / license-expression "AND" license-expression / license-expression "OR" license-expression / "(" license-expression ")"

In #37, this idea is split between ‘simple-expression’ and ‘license-expression’. I can't drop ‘simple-expression’ without breaking the unwrapped case for ‘enclosed-license-expression’, although the need for ‘enclosed-license-expression’ may depend on how #44 and #45 shake out.

I can imagine adding suffixes like "!" (I'm *sure* it's only this particular version of the license) or "?" (I'm *not* sure that it's limited to this particular version of the license), in addition to "+".

This had lots of 2017 discussion, which ended up with spdx/license-list-XML#553. And even folks like me who were in favor of versioning operators were in favor of words (e.g. ‘UNCLEAR-VERSION’) instead of single characters (e.g. ‘?’).

Also: is there any reason to *FORBID* the "+" suffix after a license-ref or license-exception-id?

This gets a bit of discussion in #37.

[kestewart]

Discussed with Steve, and since its getting into + notation, etc, we'll revisit this in 3.0.

[goneall]

There is a lot of specific pull requests which fixed part of this issue - closing this as I think it is already tracked.

@kestewart if you disagree, feel free to reopen.