Consider license expression syntax for selecting options

[swinslow]

(last updated 2020-02-06)

Background

A handful of license list requests have involved questions of how to select or choose among options contained within a single license -- and whether that should be articulable in the license ID / expression syntax. Here are a few examples:

• GNU Free Document Licence with no Invariant Sections #686: The GFDL licenses permit licensors to optionally designate certain content as Invariant Sections or Front-Cover / Back-Cover Texts. If any are present, then the impact and obligations for licensees is different than if they are not. (To the extent that Debian considers GFDL non-free if these are present, but free if they are not; see GNU Free Document Licence with no Invariant Sections #686 for discussion.)

• New License Request: Reserved Font Name options for OFL-1.0 and OFL-1.1 [EDITED] #724: Similarly, for OFL, the licensor can choose to designate a "Reserved Font Name", or not; if they do, the licensee obligations change.

• New license request: LGPL-2.1-or-later-or-KDE [SPDX-Online-Tools] #928: Some of the GPL family of licenses permit licensors to designate a proxy who can determine whether the code can optionally be used under future versions of the *GPL, rather than only this version.

• Similarly, the whole question of "-only" vs. "-or-later" is also in some sense a matter of choosing between two options articulated in the license, at least for *GPL.

• Generic GPL linking exceptions (OpenSSL related) #939: For a templated exception to GPL-3.0 recommended by the FSF, the licensor can specify particular libraries under particular licenses that may be linked and conveyed. The template can match all of these, but the licensor may also want to represent which libraries / licenses in the identifier expression.

Question

Should the license list, and the license identifier syntax, take these "selection" options into account in some fashion? And if so, how?

Options discussed so far

These are some of the options that were discussed on the legal team call on 2020-01-16. The advantages and disadvantages listed below are mostly my own thoughts, as informed by that discussion.

1. Don't change anything. Keep the license list focused on just identifying license texts. It is up to licensors and licensees to interpret their obligations based on knowing that the license is present. If people want to be more precise, they can use LicenseRef- identifiers to define custom meanings.

   • Advantages: Least effort for license list contributors. Keeps the license list focused and short.
   • Disadvantages: Doesn't really solve the problem articulated above. Users of LicenseRef- will define them in non-standard ways that hinder interoperability.

2. Add license list entries for all selections. If there are two different possible selections within a license, then create two different entries on the list, one for each selection. (And also possibly a third entry, to mean "I know the license is here but I'm not asserting anything about the selection.")

   • Advantages: Most precise and standardized. Can specifically articulate what is selected.
   • Disadvantages: Most significant effort. Leads to combinatorial explosion where multiple selections exist (e.g., proxy/no-proxy, invariant/no-invariant, -only/-or-later, all potentially present in the same license). Some selections can't be articulated this way because they are essentially free text (e.g., who the proxy is; what specific libraries are permitted to link).

3. Handle these via the exceptions list, and change its meaning. Use the WITH syntax to accommodate this, by changing the license exceptions list to include not just exceptions but also these "selections." E.g., Foo-2.0 WITH no-invariants-selection.

   • Advantages: The WITH syntax feels natural in some cases.
   • Disadvantages: Would lose the currently-understood meaning of "exceptions" as being a removal of obligations / granting of additional permissions; some selections could do the opposite. The current WITH syntax would need to be changed anyway, as currently it only allows a single exception to a license. Not all selections have precise corresponding text to match to, which is currently required for entries on the exceptions list. Some selections can't be articulated this way because they are essentially free text (e.g., who the proxy is; what specific libraries are permitted to link).

4. Create new license expression syntax for selections. Use a new phrase, e.g. USING, to accommodate this. E.g., Foo-2.0 USING no-invariants. The set of permitted options can be articulated within the license list entry.

   • Advantages: As new syntax, could be tailored to the particular problem without disrupting existing semantics. Could be crafted in a way that avoids e.g. needing to have specific text to match to, as would be the case for option 3 above.
   • Disadvantages: Would likely have a significant impact on tooling, so would need input from the tech team on whether (and how!) to accomplish. Could lead to more complex license expression syntax for ordinary users. Some selections can't be articulated this way because they are essentially free text (e.g., who the proxy is; what specific libraries are permitted to link).

5. (added 2020-02-06, thanks @rohieb!) Create new license expression syntax for template variable assignment: Annotate certain parts of the license entry as a template variable to be substituted by the license expression with the syntax USING ("literal text" AS template-variable-name), e.g., GPL-3.0-only WITH GPL-Link-Permission USING ("OpenSSL library" AS permitted-libraries, "OpenSSL license" as permitted-licenses). Could even be used with the currently available <alt> annotations: BSD-1-Clause USING ("ACME, Inc." AS copyrightHolderAsIs) (see BSD-1-Clause.xml)

   • Advantages: Allows expression of free text for certain variable parts of the license.
   • Disadvantages: Likely to be complex and harder to read. Would likely have a significant impact on tooling. Binary selections are more complicated to express than in option 3 or 4.

Next steps

I'd love to see input from folks as to which of the above options makes sense, and if there are other reasonable options I'm missing.

I expect this will be useful to cue up as a discussion for a joint legal / tech team call as well.

[rohieb]

The option mentioned by me in #939 (comment):

5. Create new license expression syntax for template variable assignment: Annotate certain parts of the license entry as a template variable to be substituted by the license expression with the syntax USING ("literal text" AS template-variable-name), e.g., GPL-3.0-only WITH GPL-Link-Permission USING ("OpenSSL library" AS permitted-libraries, "OpenSSL license" as permitted-licenses). Could even be used with the currently available <alt> annotations: BSD-1-Clause USING ("ACME, Inc." AS copyrightHolderAsIs) (see BSD-1-Clause.xml)

   • Advantages: Allows expression of free text for certain variable parts of the license.
   • Disadvantages: Likely to be complex and harder to read. Would likely have a significant impact on tooling. Binary selections are more complicated to express than in option 3 or 4.

[swinslow]

Thanks @rohieb! I'll add this to the list of options in the main comment so that folks see it together with 1-4.

[swinslow]

Discussed on 2020-05-21 legal team call. Consensus was that there is not at present a desire to overcomplicate things (from either a usability or a tooling perspective) by making the license expression syntax more complex.

This largely corresponds to option 2 from the list of options above.

Believe that the use cases for choices between different options in a license are relatively rare, and that the best way to handle will likely continue to be via separate identifiers for the different choices. If this results in multiple combos of options, the legal team participants can decide to what extent they warrant making license list entries for all possible combos. But generally in favor of staying explicit by creating separate entries on the list for each combo; believe this will be easier to understand for casual users of the list also.

I'll leave this issue open for a bit in case others want to weigh in with comments, though this reflects the consensus of all attendees on the legal team call so is unlikely to be modified at the present time.

[mchehab]

This largely corresponds to option 2 from the list of options above.

Believe that the use cases for choices between different options in a license are relatively rare, and that the best way to handle will likely continue to be via separate identifiers for the different choices. If this results in multiple combos of options, the legal team participants can decide to what extent they warrant making license list entries for all possible combos. But generally in favor of staying explicit by creating separate entries on the list for each combo; believe this will be easier to understand for casual users of the list also.

In the specific case of the Linux Kernel (see #686), we only use 2 types of GFDL license there. So, it needs those two new types (or something similar):

• GFDL-1.1-or-later-no-invariant
• GFDL-1.2-or-later-no-invariant

[swinslow]

The GFDL identifiers have been added to the list for the upcoming 3.10 release.

On the general discussion of selecting options, there haven't been further responses to the conclusion discussed above, so I'll go ahead and close this issue. Thanks all!