It would certainly be better to go with OR as it exists. Anyone familiar with
the EPL-2.0 (even if not familiar with SPDX) would be on the lookout for this
feature of the license. And, there is the Comments on License field in which
the SPDX doc creator could explain the meaning of OR in this context.
From: <spdx-legal-boun...@lists.spdx.org> on behalf of Richard Fontana
<rfont...@redhat.com>
Date: Friday, August 25, 2017 at 4:10 PM
To: Wayne Beaton <wayne.bea...@eclipse-foundation.org>
Cc: Kate Stewart <kstew...@linuxfoundation.org>, SPDX-legal
<spdx-legal@lists.spdx.org>
Subject: Re: New License/Exception Request: EPL-2.0
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
________________________________
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<mailto: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<mailto:dwhee...@ida.org>>
To: "Kate Stewart"
<kstew...@linuxfoundation.org<mailto:kstew...@linuxfoundation.org>>, "Gàry
O'Neall" <g...@sourceauditor.com<mailto:g...@sourceauditor.com>>
Cc: "SPDX-legal" <spdx-legal@lists.spdx.org<mailto: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:
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<mailto:Spdx-legal@lists.spdx.org>
https://lists.spdx.org/mailman/listinfo/spdx-legal
_______________________________________________
Spdx-legal mailing list
Spdx-legal@lists.spdx.org<mailto:Spdx-legal@lists.spdx.org>
https://lists.spdx.org/mailman/listinfo/spdx-legal
--
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
