RE: New License/Exception Request: EPL-2.0

[Wheeler, David A]

Regarding EPL-2.0 at ...

Richard Fontana:
> 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. ...
> Thus I think SPDX could simply use an OR expression instead of coming up with 
> some special purpose notation. ...

I agree that the text in exhibit A, by itself, is just an "OR" if invoked.  It 
may be wordy but it looks like a simple dual license:
> This Source Code is also Distributed under one or more Secondary Licenses, as 
> those terms are defined by the Eclipse Public License, v. 2. ...

So a project that added a secondary license would just be notated as "(EPL-2.0 
OR GPL-2.0+)" under this understanding.  That sounds straightforward.  If 
that's true, then we should do that!


However, 2(e) makes me wonder:
> e) Notwithstanding the terms of any Secondary License, no Contributor makes 
> additional grants to any Recipient (other than those set forth in this 
> Agreement) as a result of such Recipient's receipt of the Program under the 
> terms of a Secondary License (if permitted under the terms of Section 3).

It's not clear to me that this EPL-2.0 clause adds a conflict with GPL-2.0 or 
GPL-3.0.  For argument's sake I'll assume it doesn't, in part because I expect 
that the EPL-2.0 drafters would have noticed this.  However, there's a 
weirdness: This text seems to add a constraint that a *future* version of the 
GPL might conceivably conflict with.  My crystal ball is murky today :-).

If my understanding is correct (and it might not be), then "(EPL-2.0 OR 
GPL-2.0+)" is *NOT* correct, because you can't necessarily just use arbitrary 
later versions of the GPL after 2.0 and ignore the EPL-2.0 text.

If this is true, I *also* think we should avoid creating new operators.  I 
think the EPL-2.0 is better represented in SPDX as two parts:
1. The main EPL version 2.0 license, call that "EPL-2.0"
2. A constraint on secondary licenses imposed by the EPL-2.0 *when* secondary 
licenses are used; call that "EPL-SECONDARY-2.0".  Tools can be taught that 
"EPL-2.0 with GPL implies something special" if they're trying to figure it out.

Then, if you use the GPL-2.0+ secondary license with EPL-2.0, you can represent 
that as this SPDX license expression:
(EPL-2.0 OR (GPL-2.0+ AND EPL-SECONDARY-2.0))

If you're *confident* that GPL-2.0 and GPL-3.0 comply as-is, you can also write 
it as:
(EPL-2.0 OR GPL-2.0 OR GPL-3.0 OR (GPL-4.0+ AND EPL-SECONDARY-2.0))

So: If this is really just a dual-license, then let's PLEASE use simple 
expressions like "(EPL-2.0 OR GPL-2.0+)".  If it's more than that, then let's 
try to find a simple way to represent it in the existing system.

--- David A. Wheeler

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: EPL-2.0

[Richard Fontana]

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"  
To: "Richard Fontana"  
Cc: "David A Wheeler" , "Kate Stewart" 
, "SPDX-legal"  
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 

Re: New License/Exception Request: EPL-2.0

[Phil Odence]

Most folks on this list are a lot more hands-on with these issues than I, but 
I’ve studied it a little so will risk tossing in my 2 cents. I conclude that 
the EPL-2.0 introduces a new concept not correctly handled by any of current 
operators and therefore requires a new operator. I don’t have a great name to 
offer, so let’s say WITHOPTIONAL for now. Then if the initial contributor opted 
for a set of secondary licenses, the syntax would be:

EPL-2.0 WITHOPTIONAL ((Secondary License X Expression) OR (Secondary License Y 
Expression) OR etc.)


From:  on behalf of Wayne Beaton 

Date: Tuesday, August 22, 2017 at 2:43 PM
To: Richard Fontana 
Cc: Kate Stewart , SPDX-legal 

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 
> 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" >
To: "Kate Stewart" 
>, "Gàry 
O'Neall" >
Cc: "SPDX-legal" >
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