Bug#551861: [eclim-user] Fwd: Re: RFP: eclim -- Integration between the eclipse IDE and the VIM text editor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010-10-14 06:00, Eric Van Dewoestine wrote: [...] Which implies that if a EPL'ed plugin, which is not produced by the Eclipse Foundation, is loaded side by side with the eclim plugin then your license will be violated. As an example the CMakeBuilder plugin is EPL'ed but not developed by the Eclipse Foundation. It is my guess that FSF will consider it a violation of your license in this case. That being said, this is only a problem if the resulting combination is distributed (the GPL allows you to do pretty much anything with an in-house copy of the licensed work). But as I read this, it effectively prevents anyone outside of the Eclipse Foundation to derive from your work or use (parts of) it as a library for their eclipse plugin. Yes, that should prevent bundles like aptana and myeclipse from bundling eclim as part of their eclipse distributions, but I don't mean to prevent eclim from being install along side other plugins with conflicting licenses. Perhaps altering my NOTICE a bit would help with your concerns, like removing the Permission is granted.. block and simply rolling some of that info into the gpl exception as follows: If you modify this Program, or any covered work, by linking or combining it with Eclipse (cdt, jdt, pdt, wst, and any other eclipse extension produced by the Eclipse Foundation), containing parts covered by the terms of the EPL, the licensors of this Program grant you additional permission to convey the resulting work. That should hopefully make it more clear that this is intended to cover distribution and is not intended to restrict what the user can link eclim with in their personal install, so long as they don't distribute the result of course. Is that enough to permit debian to redistribute eclim as a distinct package (excluding the vimplugin exception yet to be dealt with)? I was mostly asking because I thought you might unintentionally excluded some EPL licensed plugins. Since it was intended it is all good. Basically what is required to distribute your plugin in Debian is that it follows the spirit (not the letter) of the DFSG[1]. So all we need is a non-discriminating permission to link your work and the vimplugin code against the core part of eclipse. We will ship eclim separately from eclipse itself and other plugins (we do this with all plugins packaged in Debian so far anyway), so we would not be violating the extra permission. As I recall, if you do not distribute the resulting work, most of the restrictions of the GPL license do not apply to you. So your users probably already have the permission to install and load the other plugins. You probably do not need to reword it. (However, do note the /probably/) Anyhow, I (still) have not done a deep license analysis of your plugin yet. All my comments so far are based on your NOTICE file and such. [1] http://www.debian.org/social_contract Yes, I am being pedantic here. Unfortunately legal things tend to be this at least in some countries. Also I am not the one who has to approve the license of your project for distribution in Debian, but these people expect me to do my homework first... Totally understood and I'm certainly open to making changes to ease debian's and other's ability to distributed eclim. Awesome :) I may have to take you up on that offer, but I hope we are all good to go license-wise once you have cleared the vimplugin. I also have my reservations about packaging an embedded version of vimplugin with eclim. Optimally your changes could be merged into vimplugin itself. But then again, if the upstream of vimplugin is no longer active, this is usually not a problem as long embedding vimplugin does not become a fashion. Yeah I'd love to push all my changes upstream but unfortunately the vimplugin project is pretty much dead as far as I can tell. I highly doubt that embedding vimplugin would become a fashion since embedding vim is such a niche, and when not combined with eclim, I hardly see the point, especially with plugins like vrapper out there that add vi/vim key bindings to the existing eclipse editors. [...] Well, if wimplugin is dead, you could become the new upstream for it or simply supersede it ;) For now, lets not worry about this. ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMttCOAAoJEAVLu599gGRCj2sP/3X5kjJlE6f7qHaN/d4Iifm1 Ee7Kr/e6c5YrH3lthorkUkFjDH2DFBxx7xIiIKpbBosmcTLIl+dwgJ7ekxvc8La3 JjG35eW46o7wZvUX1TTuv+J1y+PB6rVAE0m1gF+BJM06swFlTIto5TBzAY+QEQVW H/rozWdONUytdFouD+Uvr17zI29zrXkQ9K3mMAZnxEiUPgrNlCN0I9pi7/sHS1qd dcacU8Weim/zu+Mu3vhVWl9xuR6D4tRrPdtPCAnC/xWLpNw0EmxLpAI/xGkZDrJ2 Ubqy4jbH2y8rfoT92Pz+eAzXpNf1dXfl0l8qugataZb2wzZ9SVWInOwQQWjhNWnb gLcC0oFZcZ03yS4qnjcnY4qFgWY0LkoAk4ZCUSKW6kAH9gDeP/F5XX+jp1+Rh+Se
Bug#551861: [eclim-user] Fwd: Re: RFP: eclim -- Integration between the eclipse IDE and the VIM text editor
On 2010-10-12 07:44:45, Niels Thykier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010-10-11 16:18, Eric Van Dewoestine wrote: [...] Hi Note, the expected I'm not a lawyer applies to my interpretation of these licenses: Yupe, me neither. Trust me, legal stuff is among my least favourite parts of packaging software for Debian. Nevertheless it is a requirement for distributing it in Debian, so... GPL and EPL are not compatible, but the GPL3 has the following exception: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs If you want your program to link against a library not covered by the system library exception, you need to provide permission to do that. ... Only the copyright holders for the program can legally release their software under these terms. If you wrote the whole program yourself, then assuming your employer or school does not claim the copyright, you are the copyright holder—so you can authorize the exception. The EPL also has has different interpretation of a derivative work allowing eclipse plugins to not automatically need to be licensed under the EPL: http://www.eclipse.org/legal/eplfaq.php#DERIV 26. Some free software communities say that linking to their code automatically means that your program is a derivative work. Is this the position of the Eclipse Foundation? No, the Eclipse Foundation interprets the term derivative work in a way that is consistent with the definition in the U.S. Copyright Act, as applicable to computer software. Therefore, linking to Eclipse code might or might not create a derivative work, depending on all of the other facts and circumstances. 27. I‘m a programmer not a lawyer, can you give me a clear cut example of when something is or is not a derivative work? If you have made a copy of existing Eclipse code and made a few minor revisions to it, that is a derivative work. If you've written your own Eclipse plug-in with 100% your own code to implement functionality not currently in Eclipse, then it is not a derivative work. Scenarios between those two extremes will require you to seek the advice of your own legal counsel in deciding whether your program constitutes a derivative work. For clarity, merely interfacing or interoperating with Eclipse plug-in APIs (without modification) does not make an Eclipse plug-in a derivative work. I vaguely recall the not required to use EPL for a plugin thing, but FSF insists that GPL for a plugin is a violation of the GPL unless there is extra permissions[1]. Which is what's included in my NOTICE file. You can also read the eclim NOTICE file where I attempt to comply with requirements of the licenses of software utilized by eclim: http://github.com/ervandew/eclim/blob/master/NOTICE Sweet... However your notice file makes me wonder if vimplugin has this exception. I did a short check of their SVN but I did not find something that suggest this, so all files from the vimplugin cannot be covered by your exception unless you have the permission of the copyright holders of the vimplugin. Valid point. Although vimplugin has no other purpose than to be linked with eclipse, I don't recall them explicitly granting that permission like I have. I'll see if I can contact them regarding this issue, though this could be difficult since I haven't seen any of the devs respond on their mailing list in, well, years. If you have said permission, you probably want to clarify that in your NOTICE file. Likewise, if eclim links against other plugins/libraries, if they are GPL'ed these plugins/libraries must both be compatible with GPL v3 and EPL at the same time (namely if they are GPL'ed they must have the extra permission like eclim has). Then there is the part: Permission is granted to link this work with: - Eclipse (cdt, jdt, pdt, wst, and any other eclipse extension produced by the Eclipse Foundation under the terms of the EPL). Which implies that if a EPL'ed plugin, which is not produced by the Eclipse Foundation, is loaded side by side with the eclim plugin then your license will be violated. As an example the CMakeBuilder plugin is EPL'ed but not developed by the Eclipse Foundation. It is my guess that FSF will consider it a violation of your license in this case. That being said, this is only a problem if the resulting combination is distributed (the GPL allows you to do pretty much anything with an in-house copy of the licensed work). But as I read this, it effectively prevents anyone outside of the Eclipse Foundation to derive from your work or use (parts of) it as a library for their eclipse plugin. Yes, that should prevent bundles like aptana and myeclipse from bundling eclim as part of their eclipse distributions, but I don't mean to prevent eclim from
Bug#551861: [eclim-user] Fwd: Re: RFP: eclim -- Integration between the eclipse IDE and the VIM text editor
On 2010-10-11 13:30:26, Thomas Koch wrote: @eclim: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551861 Hi Niels, The license of eclipse (EPL) and eclim (GPLv3) are not compatible so if eclim links against eclipse, then there is an issue. I have not checked whether this is this case with eclim, but it is likely. This incompatibility is acknowledged both by GNU and eclipse: http://en.wikipedia.org/wiki/Eclipse_Public_License http://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses thank you for pointing this out. I'm not sure whether this incompatibility is an issue here. AFAIK Eclim delivers a bunch of eclipse plugins, some VIM plugins and relies on nailgun[1] for the communication between VIM and Eclipse. Is it possible to package Eclipse plugins that are licensed under the GPL3? If not, we should ask the Eclim project if it could add an additional license. Should it be the Eclipse license then or would a BSD license do? [1] http://martiansoftware.com/nailgun/ Best regards, Thomas Koch, http://www.koch.ro Note, the expected I'm not a lawyer applies to my interpretation of these licenses: GPL and EPL are not compatible, but the GPL3 has the following exception: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs If you want your program to link against a library not covered by the system library exception, you need to provide permission to do that. ... Only the copyright holders for the program can legally release their software under these terms. If you wrote the whole program yourself, then assuming your employer or school does not claim the copyright, you are the copyright holder—so you can authorize the exception. The EPL also has has different interpretation of a derivative work allowing eclipse plugins to not automatically need to be licensed under the EPL: http://www.eclipse.org/legal/eplfaq.php#DERIV 26. Some free software communities say that linking to their code automatically means that your program is a derivative work. Is this the position of the Eclipse Foundation? No, the Eclipse Foundation interprets the term derivative work in a way that is consistent with the definition in the U.S. Copyright Act, as applicable to computer software. Therefore, linking to Eclipse code might or might not create a derivative work, depending on all of the other facts and circumstances. 27. I‘m a programmer not a lawyer, can you give me a clear cut example of when something is or is not a derivative work? If you have made a copy of existing Eclipse code and made a few minor revisions to it, that is a derivative work. If you've written your own Eclipse plug-in with 100% your own code to implement functionality not currently in Eclipse, then it is not a derivative work. Scenarios between those two extremes will require you to seek the advice of your own legal counsel in deciding whether your program constitutes a derivative work. For clarity, merely interfacing or interoperating with Eclipse plug-in APIs (without modification) does not make an Eclipse plug-in a derivative work. You can also read the eclim NOTICE file where I attempt to comply with requirements of the licenses of software utilized by eclim: http://github.com/ervandew/eclim/blob/master/NOTICE -- eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
