|
Jim,
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:
- Does anyone think that there is anything to be gained by
having fuzziness in the definition of Derivative Work?
- 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.
[1] http://www.eclipse.org/legal/eplfaq.php#EXAMPLE
[2] http://www.eclipse.org/legal/eplfaq.php#COMPILEWOMOD
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]
http://www.oracle.com/technetwork/developer-tools/eclipse/downloads/index.html
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.
|
