Hi All,
We didn’t get a chance to discuss this on the call, so I’m sending around my thoughts as to the newly minted EPL-2.0 (which will be officially added to the SPDX License List for the next release). There were some questions on the Secondary License option. I re-read the thread previously on this (thanks all), and have noted the change in the Exhibit A wording. Below are my thoughts on this, with relevant bits of license bits.
TL;DR
The existing license expression syntax, “OR” covers the Exhibit A option, if observed. No need to add new expression or identifier.
There was some mention of an exception not on our list - if this is something that is used in the wild, please do ask for it to be added.
---------
“Secondary License” means either the GNU General Public License, Version 2.0, or any later versions of that license, including any exceptions or additional permissions as identified by the initial Contributor.
This is the definition of Secondary License which included licenses that are already on the SPDX License List, as well as probably/possibly including exceptions already on the SPDX License List.
(I also found myself a bit puzzled by 2(e), but Richard Fontana already has provided helpful context and background in this clause.)
The other key clause is in 3.2:
3.2 When the Program is Distributed as Source Code:
• a) it must be made available under this Agreement, or if the Program (i) is combined with other material in a separate file or files made available under a Secondary License, and (ii) the initial Contributor attached to the Source Code the notice described in Exhibit A of this Agreement, then the Program may be made available under the terms of such Secondary Licenses, and
Note the use of or (emphasis added) - under EPL-2.0 or under a Secondary License under certain conditions, one of which is Exhibit A is used. This to me says that if one sees Exhibit A, then anyone downstream has a choice to redistribute the Program under EPL-2.0 or under any of the Secondary Licenses as defined above.
This begs the question as to what if someone used Exhibit A and identified GPL-2.0+, for example, but the Program was not combined with other material made available under GPL-2.0+? I think that becomes an enforcement issue of the license which may have some problems, but that is a separate discussion and not relevant to SPDX and SPDX identifiers.[1]
Exhibit A explains how to do evoke the Secondary License option::
Exhibit A – Form of Secondary Licenses Notice
“This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: {name license(s), version(s), and exceptions or additional permissions here}.”
Simply including a copy of this Agreement, including this Exhibit A is not sufficient to license the Source Code under Secondary Licenses.
If it is not possible or desirable to put the notice in a particular file, then You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice.
You may add additional accurate notices of copyright ownership.
Thus, if Exhibit A is present in the source code, then one would use the proper SPDX identifiers for the license or license expression chosen EPL-2.0 OR GPL-2.0+ (or whatever the chosen Secondary License is)
I don’t see any need for a new identifier here as the existing licenses, exceptions, and license expression syntax cover this. The license is also clear that simply copying the license with the Exhibit A in it is not enough to evoke this - you must actually use Exhibit A as it was intended, fill it out, and put it somewhere else (either Source Files or something one would look for such a notice).
I’d expect that if a scanner came across Exhibit A in some files, it would flag it up in a way that someone would want to look at it further, and then the concluded license would use the SPDX license expression as appropriate Of course, if SPDX short identifiers were used in the replaceable text area of Exhibit A, that would make automated identification easier.
Lastly, Exhibit A would (obviously) not be considered the “standard header” for EPL-2.0. I thought I saw a comment by Wayne about a standard header somewhere else, but I must be getting confused now with some other discussion!
Please let me know if anyone disagrees.
Thanks,
Jilayne
[1] Just to tease this down, so as to possibly avoid a side discussion on this, if:
A released Foo under EPL-2.0
B takes Foo and evokes Exhibit A, redistributing Foo under EPL-2.0 OR GPL-2.0 but does not combine Foo with any other code under GPL-2.0
C take Foo from B and redistributes it under GPL-2.0 (just Foo)
A might not be happy with this situation and would need fix the issue with B who improperly evoked Exhibit A when B redistributed. As per the termination clause, A could argue that B has not complied with the material terms and conditions of the license (and if B didn’t fix the problem within in a reasonable period), B’s license would terminate and then A could bring an infringement suit against B (assuming B continued to distribute, for example).
Is A going to bring an infringement suit against C due to using the “wrong” license? - C’s right continue to survive B’s termination, but C is using the wrong license due to B’s initial mistake.
All told - I would really hope to NEVER see lawsuits such as this…
