-----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 68xeG+CEojy2WRYMHSBVrw+mj7ViRSSz77F0L3CzkO2c9Ay9mABKB6+M8jCDsEb/ p5GftDnm8SwKT3oeqqeOhWt0ZBYUhm9zA65T1FAv5JmPufOW/qdAhp0xc9kkgr9z XO6EqWl2dFWTycvQJ77E4F1qzjRhJ3BGHgg3jPsB8JkAXFPsGLX+fiMZz/eDOJ9R BkCkgAsr0JQ4vClRmYfWUm62BoC32H8Jb/91wJRLkJpJSWAmdHCo1s6S1oGGJjRN 5+/TlCe4Xt1lXJJsXewS =NOiG -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cb6d08f.6070...@thykier.net
