Bugzilla – Full Text Bug Listing
| Summary: | Eclipse Platform source organization incompatible with spirit of Common Public License | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | C. Lamont Gilbert <clg-business> |
| Component: | UI | Assignee: | Kevin Haaland <Kevin_Haaland> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | gunnar, ilias, mark |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
C. Lamont Gilbert
[This issue is very 'deep'. Possibly you have to wait one or two days for responses] Link to reporters forum discussion: [LICENSE] Definition of "derivative work" http://www.eclipse.org/newsportal/article.php?id=189&group=eclipse.foundation Link to a related suggestion: [LICENSE] - Clarify EPL Licensing Terms 'human readable' http://www.eclipse.org/newsportal/article.php?id=26&group=eclipse.foundation [crossposted from eclipse.foundation] I guess I would disagree on your definition of derivative work and java. IANAL either, nor an expert in licenses, but that never stopped me from having an opinion ;) All use of libraries (jars) in java are dynamicly linked. Your jar/classes never incorporate the other classes they uses externally (static linking), they are only linked by names. There is absolutely not a single byte taken from any eclipse jar into my jars that uses the eclipse jars. So, if I type (as an example was on eclipse.platform) "import org.eclipse.xx.yy" in my class does not make my class a derivative work of org.eclipse.xx.yy. if my class extend org.eclipse.actions.IAction does not make me a derivative work of IAction either, I'm just dynamicly linking to the jar without using their source directly into my product. If I change org.eclipse.actions.IAction or copy and extend the code, it is derivative work. So I would disagree with your second statements around java; in java you don't staticly link to any "header" as you probably would in c/c++. You always just dynamicly link. So the whole interface thing is not needed. c/c++ is different as you require .h header files in additions to the dll/so's. As I stated in the groups, its irrelevant how you link. If there is any linking at all, the FSF would consider it a derivative work. There is no difference between Java or C or any new languages that may arrive. If you incorporate the smallest part of the copyrighted work, within your own work, your work becomes derivative. In the case of Java, that includes any extending of classes, implementing of interfaces, calling of methods, using of reference types, etc. from the copyrighted work. While the actual byte codes of the copyrighted work are not in your .class file, the signature to the copyrighted work, which is part of the work as well, is. To make it clear, if you require it in your classpath in order to compile your code, you are creating a derivative work of it. This is not meer supposition, this fact will be reflected within your .class files and can be verified with javap. This may seem silly and extreme, but its a legal document after all, and intentions are not all that matters. IBM could define "derivative work" differently from the FSF, but I doubt they could satisfy the desires of the community or protect the eclipse source in that way. The CPL would have to incorporate language to specifically address Java, which I don't think they will or should do. the FSF's position can be seen here http://www.gnu.org/licenses/lgpl-java.html The CPL is actually reasonably clear on this issue - look at 1 b) in the license - the reference to derivative work is not the only thing issue. That said, the "derivative work" can be interpreted in different ways - whether this includes such acts as importing interfaces is up to the person reading the license. I cannot give legal advice but I'd say for sure that the GNU interpretation is not universal. I would encourage you to send e-mail to license@eclipse.org to get some assistance with issue. You are correct, NOT being a derivative work is not enough to prevent you from having to grant rights to your code. But being a derivative work is more than enough to cause you to have to grant rights to your code. I also agree that gnu's definitoin of derivative work may not be ubiquitous. But GNU is kind enough to explain exactly what they mean by the term, right there in the license. So there is no confusion. The CPL uses the term, but does not define it. I will send a question to that address, I did not know it was available. There is a salient point I wish to add here. Consider if we define derivative work such that code does not automatically become derivative work of any class included in its source path. My fear is that if you do this you create a "loophole", and one could co-opt the whole eclipse project by funnelling his connection to Eclipse through it. Thus exposing Eclipse to exploitation. This is why I don't feel defining 'derivative work' will get us out of this position, without putting us in a different but equally as undesireable one. I suppose we have agreed maintain this characteristic in the EPL. This bug should be closed as the FAQ now expresses the issue and the foundations position involving the classification of derivative works. |