Generic GPL linking exceptions (OpenSSL related)

[rohieb]

As I gather from #720 and #824, there are already a few OpenSSL exceptions out in the wild. To add to that, I was looking at wget, which is under GPL-3.0-or-later, and has an exception for linking against OpenSSL in their source files (e.g. src/http.c):

Additional permission under GNU GPL version 3 section 7

If you modify this program, or any covered work, by linking or
combining it with the OpenSSL project's OpenSSL library (or a
modified version of that library), containing parts covered by the
terms of the OpenSSL or SSLeay licenses, the Free Software Foundation
grants you additional permission to convey the resulting work.

This seems to be directly copied from the template which the FSF provides in its FAQ:

Additional permission under GNU GPL version 3 section 7

If you modify this Program, or any covered work, by linking or combining it 
with [name of library] (or a modified version of that library), containing 
parts covered by the terms of [name of library's license], the licensors of 
this Program grant you additional permission to convey the resulting work. 
{Corresponding Source for a non-source form of such a combination shall include 
the source code for the parts of [name of library] used as well as that of the 
covered work.}

I have so far only found this template in wget, substituted for OpenSSL. The FSF template is very generic so I'm not sure if it makes any sense to include it in SPDX with the current template variables, especially since (I think) there is no way to express template variables in SPDX License Identifiers. So after all we would only be able to express that a software is licensed under GPL-3.0-or-later with an exception to link it against some unspecified library.

The best alternative I can think of is to have one version for each library (e.g. OpenSSL), and add them to SPDX as they are found in the real world. However, this would probably yield a lot of FSF-GPL-3.0-$LIBRARY-Exception templates in the future…

[swinslow]

Hi @rohieb, thanks for catching and submitting this. It's a good question and I'm going back and forth on what makes sense as the best outcome here.

Looking through some of the other existing exceptions currently on the list, it seems that in a couple of instances where an exception has referenced a specific software project, we have not templated it and we have instead kept it as-is. Examples:

• OpenJDK-assembly-exception-1.0
• openvpn-openssl-exception

That said, I agree with your comment that if we were to include a separate entry (and identifier) for each possible instance of this, it could easily spiral out of control if this exception were to be widely used.

Given that the original text from the FSF FAQ was in templated form, I tend to think that it would be appropriate to include it as a templated exception on the license list. That would of course mean that the license identifier standing alone wouldn't convey all information necessary to utilize the exception. But I think that's okay; the presence of the identifier would indicate that there is an exception in this form, and a licensee could read the text to determine which software it applies to.

Interested in thoughts from others also -- @jlovejoy @bradleeedmondson and others, feel free to weigh in if you feel differently...

[swinslow]

We didn't have time to discuss this on the 2020-01-02 legal team call, so I will cue it up for discussion during the next call on 2020-01-16.

[bradleeedmondson]

I tend to favor adding this as a templated, "generic" exception. That's simpler, for us as well as license-list consumers, and FSF has it templated in their FAQ[1]. My only hesitation is @rohieb 's point that you can't express the scope of the exception (which library/libraries you can link with) using SPDX license identifiers. (Here, the scope is the specified list of things you can link with regardless of their GPL status, usually but not necessarily a single library.) Unless... Could this perhaps be represented using a LicenseRef similar to that recommended in the KDE-proxy GPL expression[2] in #928?

To that point, if we were to add a generic GPL exception/modifier, GPL-Link-Permission, would the following be an acceptable representation for the OpenSSL case?

* SPDX-FileCopyrightText: 2019 Jane Doe <jane@example.com>
*
* SPDX-License-Identifier: GPL-3.0-or-later OR (GPL-Link-Permission AND LicenseRef-wget-OpenSSL-linking-exception)

I'm not all that familiar with LicenseRef, but it seems that's how it was used in the other instance[2]. I would want to check with @goneall and @pombredanne , but if this is valid and adequately represents the OpenSSL scope (assuming a sufficient LicenseRef file in the package), then maybe that's all there is to it?

[1] https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs
[2] #928 (comment)

[swinslow]

I agree with the comment from @bradleeedmondson above. I like the idea of adding to the official Exceptions List a "template"-style exception for the form of exception from the FSF's FAQ.

For some users, that will be sufficient, to note that there is a GPL-Link-Permission exception present. For others, they may want to designate which specific third-party library is identified, and in that case they can define and use a LicenseRef- for the particular library.

A couple of questions and comments on the specifics here:

• @bradleeedmondson, using your example above I think it would be: SPDX-License-Identifier: GPL-3.0-or-later WITH (GPL-Link-Permission AND LicenseRef-wget-OpenSSL-linking-exception) — the difference being, WITH instead of OR since it's an exception.

• ...the problem with this, though, is that the current SPDX exception identifier syntax doesn't permit compound statements in exceptions. So, can't currently use multiple WITH's, or an AND within an exception. See syntax at [1] and recent related discussion at [2]

• So in practice, with the current syntax, I'd probably say that the options are: either use SPDX-License-Identifier: GPL-3.0-or-later WITH GPL-Link-Permission (after we add GPL-Link-Permission to the list, or course!) or else someone can define their own more specific instance, e.g. SPDX-License-Identifier: GPL-3.0-or-later WITH LicenseRef-wget-OpenSSL-linking-exception

• One more complication to ask: I note that the FSF's FAQ [3] has a bracketed section in their suggested text -- the portion beginning: {Corresponding Source for a non-source form...} If that is present, would we view it as substantively different from if it absent, such that there should be a separate identifier for when it's used? My inclination is yes, there should be a separate exception identifier when this language is present, but I could be persuaded otherwise.

Does that all make sense? We can discuss this further on today's legal team call also.

[1] https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
[2] #956 (comment)
[3] https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

[swinslow]

Discussed on 2020-01-16 legal team call, agreed to add templated version of the add'l permission from the FSF FAQ to the exceptions list.

Agreed to add as two separate permissions, one with just first sentence and the other with both the first and second sentence; based on discussion it was felt that they could have substantively different effects, so they should be added as separate entries.

Exception name and identifier should include GPL-3.0 to reflect that this exception is specifically intended for use with version 3 of the GPL. @swinslow will prep PRs for these two.

The same entry in the FSF's FAQ includes a separate text for use with GPL-2.0, which could be considered for a separate addition. Probably worth comparing that one more closely to other exceptions currently on the list, to see how close of a match it might be to existing entries.

[goneall]

using your example above I think it would be: SPDX-License-Identifier: GPL-3.0-or-later WITH (GPL-Link-Permission AND LicenseRef-wget-OpenSSL-linking-exception)

For the syntax, neither of the proposed solutions is allowed based on the license expression ABNF described in spec appendix IV.

License exception can only follow a WITH clause and WITH can only be used with a license ID.

A way to represent this would be `SPDX-License-Identifier: (GPL-3.0-or-later WITH GPL-Link-Permission AND GPL-3.0-or-later with LicenseRef-wget-OpenSSL-linking-exception)

[rohieb]

Hmmm. I'm just playing around here a bit not knowing whether someone has suggested something similar, but I'm wondering if there is a way to express this situation fully with the SPDX identifier without the need for any external (in this case, mostly boilerplate) documents. For example, I'm thinking of an additional XML tag, <param> to markup parameters in the SPDX license template, then using that parameter name in the SPDX identifier we could state the value of that parameter in the real-world template.

In our case, the license template could then become:

<exception licenseId="GPL-Link-Permission" name="GPL Link Permission">
<text>
<p>Additional permission under GNU GPL version 3 section 7</p>
<p>If you modify this Program, or any covered work, by linking or combining it 
with <param name="libraryName" /> (or a modified version of that library), containing 
parts covered by the terms of <param name="libraryLicense" />, the licensors of 
this Program grant you additional permission to convey the resulting work.</p>
</text>
</exception>

and then the (still hypothetical) SPDX expression GPL-3.0 WITH GPL-Link-Permission USING ("the OpenSSL project's OpenSSL library" AS libraryName, "the OpenSSL or SSLeay licenses" AS libraryLicense) could be used to describe the license text in comment #1 literally by giving the values for those template parameters. Also I'm using something else than <alt> here because most existing <alt> markups have a match='.*', which I think does not really apply really well here.

I haven't thought this through much yet, and this would of course need a change in the XML schema too, but I think it could make SPDX expressions much more flexible in the future without the need to add many variants of the same license text.

[goneall]

@rohieb Interesting suggestion - I don't recall this idea being proposed in the past. It would be a bit of work to add to the tooling, but it would provide for some greater flexibility.

In terms of the syntax, the only thing I would add is some type of default name that would show up in the license list text. We could use the same approach as alt with the default value inside the tags (e.g. <param name="libraryName">Library</>

[swinslow]

Thanks @rohieb and @goneall! I think for version 3.0 of the SPDX spec it's worth considering whether a change to the license expression syntax is appropriate. I'll be opening a separate issue related to this shortly, based on discussion on the last legal team call.

In the meantime, for this exception I'll be submitting a PR shortly that adds the exception based on the FSF's FAQ template language.