| Re: [epl-discuss] Draft changes |
This doesn’t strike me as achieving clarity in licensing, if that’s the goal (and I think it should be). 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?) 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. 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. On the last paragraph, I tend to agree with Terry for the most part, but because some of our colleagues in the EU or other jurisdictions may have good reasons for wanting their own law to apply, and far be it from me to tell some non-US based coder he needs to use my law, I might allow authors to set a choice of law which is different than a default in NY - perhaps through the use of an external choice of law selector (a file like I used in the UPL, a designator in the license text, or some other mechanism). -- Jim |