Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epl-discuss] Draft changes


Thanks. Answers are in-lined below.

On 30/03/2015 11:24 AM, Jim Wright wrote:
This doesn’t strike me as achieving clarity in licensing, if that’s the goal (and I think it should be).

I agree. I naively re-used the definition of Derivative Work from the ALv2, without clearly thinking about its applicability to a copyleft license, rather than a permissive one.

Some questions to the audience:
  1. Does anyone think that there is anything to be gained by having fuzziness in the definition of Derivative Work?

  2. Assuming that your answer to #1 is "no", would an approach similar to the definition of Modifications from the MPL 2.0 be helpful? E.g. spelling out exactly what we mean by "...based on (or derived from)".

If I write a program that loads an Eclipse module and requires that module in order to run, is that “based on (or derived from) the Program”?  What if it doesn’t technically require the Program to run but 90%+ of its functionality depends on the Program’s presence and characteristics?  We all know the answer when you cut and paste, but if the answer is not obvious in all other cases, what then does it depend on - what exactly my app does and how much EPL licensed code it uses vs. how much code I have written?  The nature of the interface?  (Ex: A 10 line program that just loads the IDE with some specific parameters - based on the Program?  I think many would argue yes.  How about an IDE plug-in which depends entirely on how the IDE works and isn’t good for any other purpose?  Many would also argue yes though I do not believe this is the approach you have taken to date.  How about a large substantive app that depends on EclipseLink for serialization?) 

Well, one of the EPL FAQ answers[1] already states that "... merely interfacing or interoperating with Eclipse plug-in APIs (without modification) does not make an Eclipse plug-in a derivative work." It also states that you "... may compile a Program licensed under the EPL without modification and commercially license the result in accordance with the terms of the EPL."

I have always believed that the social contract inherent in the EPL is that if you write your own code in your own files that links to and uses the Eclipse APIs, then that is not a derivative work. So it seems to me that none of your examples are derivative works. The test in those cases has nothing to do with how much EPL-licensed code you depend on. It is only whether you wrote your own code and put it into a separate module (file).

So personally, I do not have any concerns with clarifying that in the license. And, as you have likely noticed, explicitly add subclassing to the list of permissions.


In my view the answers to these questions need to be 100% obvious (to someone whose profession is not FOSS advocacy or licensing) from the text of the license in order for it to be an advance, and to my eye, the answers aren’t obvious here and can’t possibly be with the ambiguous standard of being “based on (or derived from) the Program.”  The fact is, people have different positions about what it means to be derived, which you tried to address in part with the subclassing language, but it still leaves the underlying question.  Many people interpret the EPL as weak copyleft, meaning that you can load an EPL licensed module and also require that module in order to run (e.g., a plug in for the IDE) but as long as your app is composed of separate modules, you are not required to license the entirety of the app under the EPL.  If it is your intent that this is the correct interpretation, say that, and clarify exactly what they need to do to trigger a reciprocal license obligation and the exact scope (i.e. the set of files) of that obligation. 

By "many people" I think you mean the License Steward, and the entire Eclipse ecosystem, including Oracle and its Eclipse-based products[3]? The hard part, of course, is that if the separate modules in your app are based on copies of EPL code, then you have a problem. The test is not just that "...your app is composed of separate modules...", but also that those separate modules are not based on EPL code.

[3] and click on the link to the proprietary license.

If you believe it’s stronger copyleft than that (which I’m not sure could be the case based on your subclassing approach, but still needs an answer), you can draw the line elsewhere, but wherever you draw it, it needs to be bright and clear.

I do not think that the EPL is stronger copyleft than that. Does anyone else on this list think that it is? I can point to hundreds of companies shipping thousands of proprietary products who seemingly rely upon this interpretation.

Mike Milinkovich
+1.613.220.3223 (mobile)

Back to the top