Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

appendix-IV: Refactor the license expression appendix #37

Closed
wants to merge 1 commit into from

Commits on Jun 5, 2018

  1. appendix-IV: Refactor the license expression appendix

    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 committed Jun 5, 2018
    Configuration menu
    Copy the full SHA
    afc5c1e View commit details
    Browse the repository at this point in the history