I think you're right about the intent. The annoying thing here is the ceremonial wording of Exhibit A says nothing about compatibility as such and instead seems to merely express the traditional concept of a dual license (which admittedly is one way to achieve compatibility), which has a well understood translation into SPDX expressions. I hesitate to call this a "mistake" but if I'd noticed it before I would have brought it to the Eclipse Foundation's attention.
The Exhibit A notice says: " This Source Code is also Distributed under one or more Secondary Licenses, as those terms are defined by the Eclipse Public License, v. 2.0: {name license(s),version(s), and exceptions or additional permissions here}.” Thinking about it some more, I think this was intended to be understood in such a way that the "Source Code" is the Source code of the Program at a given iteration downstream, and not just the initial version. If that's right, that means at all times the source code is "also Distributed under" some form of Secondary License, say GPLv2 with the Classpath Exception. It may be that in some cases it will be formally noncompliant with the What 3.2 says is "[the source code] 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". But this is just saying that the Exhibit A notice applies to all subsequent nominally-EPL-2.0 contributions. So this is the same thing as dual-licensing under EPL and the Secondary License, just through one particular sanctioned mechanism. Thus I think SPDX could simply use an OR expression instead of coming up with some special purpose notation. I don't think that was necessarily intended by Eclipse but that would be the plain interpretation of Exhibit A. It says it *is* distributed under the Secondary License -- it doesn't say "the Program may potentially be distributed under" the Secondary License. If prior to EPL 2.0 one had seen EPL 1.0 code used with a statement "This Source Code is also Distributed under one or more Secondary Licenses, namely GPLv2 with the Classpath Exception", wouldn't everyone have agreed that this was "EPL-1.0 OR (GPL-2.0 WITH Classpath-exception-2.0" in SPDX-speak? I guess otherwise one would have to have the legal conclusion that while Exhibit A says "is also Distributed under" it doesn't really mean "is also Distributed under" but rather means "is potentially Distributed under even though it is not actually Distributed under right now". Not sure it matters all that much in the scheme of things, but I am kicking myself for not noticing this before. :) Richard ----- Original Message ----- From: "Wayne Beaton" <wayne.bea...@eclipse-foundation.org> To: "Richard Fontana" <rfont...@redhat.com> Cc: "David A Wheeler" <dwhee...@ida.org>, "Kate Stewart" <kstew...@linuxfoundation.org>, "SPDX-legal" <spdx-legal@lists.spdx.org> Sent: Tuesday, August 22, 2017 2:43:12 PM Subject: Re: New License/Exception Request: EPL-2.0 I actually did mean WITH, but may have been clumsy with my selection of terms. Using OR is basically saying that the content is dual-licensed which is not the intent (please correct me if my understanding is wrong). My understanding (based on section 3.2a of the license) is that the intent with the secondary license is provide a switch that says that the license is compatible with some particular version (or versions) of the GPL and some set of exceptions. That is, the content can be compiled and linked with GPL code (at which point the output becomes GPL). e.g. (EPL-2.0 WITH GPL-2.0-Compatibility-exception) where the secondary license is GPL-2.0. Perhaps we can define a more generic "secondary-license-exception" as meaning something like "compatibility with GPL-2.0+" and just chain other exceptions, e.g. (EPL-2.0 WITH secondary-license-exception WITH Classpath-exception-2.0). As I think about this more, I'm leaning more towards something that's similar to the solution adopted for the MPL-2.0. i.e. the straight up EPL-2.0, and the EPL-2.0 with an escape hatch (EPL-2.0-with-secondary-license-exception). The problem is that the escape hatch is dynamic for EPL-2.0 ("exhibit A" requires that the secondary license and any exceptions be explicitly listed), but is static for MPL-2.0 ("exhibit B" is a blanket removal of secondary license support). Are we able to provide the right level of precision with just two license codes? Does it make sense to do this in two pieces? e.g. push forward to get EPL-2.0 defined and then sort out the alternatives? Wayne On Tue, Aug 22, 2017 at 1:36 PM, Richard Fontana < rfont...@redhat.com > wrote: I think there's something a little odd about the EPL 2.0 opt-in GPL compatibility feature I hadn't paid attention to before (despite having reviewed the license closely during its drafting and the OSI approval process). The way the opt-in GPL compatibility works, the initial licensor of 'the Program' has to include a notice which seems to say, in effect, that the code from that initial licensor is disjunctively dual-licensed under EPL and some particular allowed GPL-family license. Subsequent licensors downstream are inheriting a feature that is not really obvious from the text of the required notice from the initial licensor, which I read as allowing pure-EPL-2.0 code to be distributed under the GPL-family license instead. So, for example, in a scenario where the initial licensor wanted to allow compatibility with GPLv2 + Classpath Exception, the correct SPDX description of the Program would seem to be, potentially: (EPL-2.0 OR (GPL-2.0 WITH Classpath-exception-2.0)) AND (EPL-2.0 WITH whatever-SPDX-were-to-call-the-Built-in-EPL-2.0-GPL-copyleft-escape-hatch) This is odd because it seems to imply that the EPL 2.0 compatibility provision is unnecessary. The initial licensor is dual licensing the initial EPL code anyway, so it would always have been possible for subsequent contributions to the Program to be combinable with other GPLv2 + Classpath Exception code. The only difference seems to be that the subsequent EPL 2.0 licensors can present their code as "pure EPL 2.0" code and still benefit from the compatibility feature - i.e. they can avoid having to worry about being careful not to be seen as removing the upstream dual license feature. Maybe I'm not reading it correctly or need a second cup of coffee but I'm not really seeing how the above SPDX expression would be different from (EPL-2.0 OR (GPL-2.0 WITH Classpath-exception-2.0)) though. Richard From: "David A Wheeler" < dwhee...@ida.org > To: "Kate Stewart" < kstew...@linuxfoundation.org >, "Gàry O'Neall" < g...@sourceauditor.com > Cc: "SPDX-legal" < spdx-legal@lists.spdx.org > Sent: Tuesday, August 22, 2017 1:02:51 PM Subject: RE: New License/Exception Request: EPL-2.0 Kate Stewart: <blockquote> Possibly you're using WITH (which is restricted to only refer to exceptions when you mean to use AND?? Does the following look like what you're trying to represent? EPL-2.0 EPL-2.0 AND GPL-2.0 EPL-2.0 AND (GPL-2.0 with Classpath-exception-2.0) Those are *syntactically* fine SPDX license expressions, of course. However - do they really *mean* "EPL-2.0 AND GPL-2.0"?!? That would mean that recipients would have to comply with *both* licenses. Perhaps they meant "EPL-2.0 OR GPL-2.0". That way, recipients could choose which one could be used. --- David A. Wheeler _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal _______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal </blockquote> -- Wayne Beaton Director of Open Source Projects The Eclipse Foundation
_______________________________________________ Spdx-legal mailing list Spdx-legal@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx-legal