Re: [JPP-Devel] GPL and LGPL (I need an attorney.) :]
Right, but this makes the LGPL as well, the difference is that you are allowed to let proprietary code _use_ it .. I found some conversation with gnu.org in my thesis about this matter. You'll find it from page 96 on .. http://soldin.de/about/2003-diplom/mobigis_wl_small.pdf May this clarifies things a even better. And a correction: It is of course _not_ possible to dual license your code if it is derived from GPL code. Only the solely copyright holder with a free choice of licensing (not using GPLed components) can multilicense the work. Regards ede -- On Fri, 22 Jun 2007 10:31:16 -0700, Sunburned Surveyor [EMAIL PROTECTED] wrote: This conversation has been great and has really helped me understand the difference between the GPL and LGPL licenses. I imagine that an important distinction between JUMP and GeoTools/UDig is the fact that JUMP is released under the GPL and can't be sucked-in by proprietary software. The Sunburned Surveyor On 6/22/07, Larry Becker [EMAIL PROTECTED] wrote: Right. It is the dependency that matters. JUMP depends on JTS. JTS doesn't depend on JUMP. And lawyers aren't always a bad thing. Some might say that the threat of layers is the only thing that keeps GPL code free. I might release some code under Larry's license but it would not be backed up by the threat of the Free Software Foundation suing you for violating the license. regards, Larry Becker On 6/22/07, Edgar Soldin [EMAIL PROTECTED] wrote: Simple.. as jump is derived from jts and jts LGPL does not enforce a type of license for the derived work... this is what makes it the Lesser GPL.. it declares the use of libraries to /work that uses the Library/ and excepts it from the derivation rule. see http://en.wikipedia.org/wiki/LGPL ede So how is it JTS can be released under the LGPL is JUMP uses it? Doesn't JUMP's GPL infect JTS? Or is JTS released under both the GPL and LGPL? Or does releasing JTS under the LGPL meet the viral requirement of the GPL? The Sunburned Surveyor On 6/22/07, Edgar Soldin [EMAIL PROTECTED] wrote: Hello all, unfortunately separating the code is not enough too allow a new license. At a quick glance i only found only this http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCLinkingOverControlledInterface And to my knowledge the GPL enforces itself on derived work (incl. inheritance, use of interfaces). Thats why any work based on GPLed software has to be at least licensed for GPL. Dual licensing of the same is still allowed though. Regards ede -- Sunburned Surveyor wrote: Martin, Thanks for this great clarification. I believe in my particular case I will have to release the converter code under the GPL, since I will be linking directly to JUMP code to do the conversion. I'll have to consider how important it is to use GPL for other code I write that isn't tied as directly to JUMP. I'd appreciate any thoughts on this. Does code released under the GPL discourage use and adoption in a way that code released under the LGPL does not? yes.. do it under LGPL if you can (i.e. don't rely on GPL code). what i have done (though i am still not sure if it is truly correct) is to release the mapgentoolbox code under an apache like license. But the important thing has been that i have put my code in separate *.jars and not in the jar that contains the jump-extension class stuff. I think that having two jars is the way. stefan The Sunburned Surveyor On 6/21/07, Martin Davis [EMAIL PROTECTED] wrote: I don't think you can develop code that links in GPL code under anything except GPL. See here: http://www.gnu.org/copyleft/gpl-faq.html#GPLAndPlugins LGPL is weaker than GPL, so you can't release an actual plugin class (which uses the JUMP API's) as LGPL. However, I think what you can do is package up an independent library under some other license (as long as it doesn't use any JUMP code) and then call it from a wrapper plugin which is under GPL. Sunburned Surveyor wrote: I think Paul hit the nail on the head. GeoTools is worried about including code that can't be included in commercial applications. I found an interesting article that discusses whether or not you should use the LGPL or GPL for library code at the link Sascha sent. The article is here: http://www.fsf.org/licensing/licenses/why-not-lgpl.html I'll have to think carefully about this. It seems like a very important difference. Any thoughts on whether or not we want to encourage development of OpenJUMP plug-ins and support or library code under the GPL or LGPL?
Re: [JPP-Devel] GPL and LGPL (I need an attorney.) :]
Simple.. as jump is derived from jts and jts LGPL does not enforce a type of license for the derived work... this is what makes it the Lesser GPL.. it declares the use of libraries to /work that uses the Library/ and excepts it from the derivation rule. see http://en.wikipedia.org/wiki/LGPL ede So how is it JTS can be released under the LGPL is JUMP uses it? Doesn't JUMP's GPL infect JTS? Or is JTS released under both the GPL and LGPL? Or does releasing JTS under the LGPL meet the viral requirement of the GPL? The Sunburned Surveyor On 6/22/07, Edgar Soldin [EMAIL PROTECTED] wrote: Hello all, unfortunately separating the code is not enough too allow a new license. At a quick glance i only found only this http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCLinkingOverControlledInterface And to my knowledge the GPL enforces itself on derived work (incl. inheritance, use of interfaces). Thats why any work based on GPLed software has to be at least licensed for GPL. Dual licensing of the same is still allowed though. Regards ede -- Sunburned Surveyor wrote: Martin, Thanks for this great clarification. I believe in my particular case I will have to release the converter code under the GPL, since I will be linking directly to JUMP code to do the conversion. I'll have to consider how important it is to use GPL for other code I write that isn't tied as directly to JUMP. I'd appreciate any thoughts on this. Does code released under the GPL discourage use and adoption in a way that code released under the LGPL does not? yes.. do it under LGPL if you can (i.e. don't rely on GPL code). what i have done (though i am still not sure if it is truly correct) is to release the mapgentoolbox code under an apache like license. But the important thing has been that i have put my code in separate *.jars and not in the jar that contains the jump-extension class stuff. I think that having two jars is the way. stefan The Sunburned Surveyor On 6/21/07, Martin Davis [EMAIL PROTECTED] wrote: I don't think you can develop code that links in GPL code under anything except GPL. See here: http://www.gnu.org/copyleft/gpl-faq.html#GPLAndPlugins LGPL is weaker than GPL, so you can't release an actual plugin class (which uses the JUMP API's) as LGPL. However, I think what you can do is package up an independent library under some other license (as long as it doesn't use any JUMP code) and then call it from a wrapper plugin which is under GPL. Sunburned Surveyor wrote: I think Paul hit the nail on the head. GeoTools is worried about including code that can't be included in commercial applications. I found an interesting article that discusses whether or not you should use the LGPL or GPL for library code at the link Sascha sent. The article is here: http://www.fsf.org/licensing/licenses/why-not-lgpl.html I'll have to think carefully about this. It seems like a very important difference. Any thoughts on whether or not we want to encourage development of OpenJUMP plug-ins and support or library code under the GPL or LGPL? (I'm probably opening Pandora's box with this question.) I'm really undecided as to which license I should use for my code. The Sunburned Surveyor On 6/21/07, Paul Austin [EMAIL PROTECTED] wrote: The only problem would be if you used SS's new classes in a commercial application. Which in fact would be unlikely as they would not be allowed to use the JUMP code anyway because it is GPL. I think the rule is commercial apps can use LGPL libraries but not GPL ones. I took another approach for the same problem I added a FeatureFactory to my reader components and have a JumpFeatureFactory that will create features which implement both my DataObject interface and the Jump Feature interface. This way there is no conversion required between feature models. You just set the factory based on the type of feature instance you want. The reader uses this factory to create the instances. Paul Sunburned Surveyor wrote: I was talking to Jody Garnett a little bit about a home for a converter or pair of converters that would allow developers to do the GeoTools JUMP and JUMP GeoTools Feature Model conversion. He said that there may be some issues since any code that I write will necessarily need to utilize JUMP code released under the GPL. This is an issue because GeoTools is released under the LGPL. I don't know as much about this area as I should, so I'm hoping to get some suggestions from this group. How might I be able to get code that works with JUMP code under the GPl to play nice with GeoTools code released under the LGPL? Is this even possible? Thanks for the suggestions. The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express
[JPP-Devel] GPL and LGPL (I need an attorney.) :]
So how is it JTS can be released under the LGPL is JUMP uses it? Doesn't JUMP's GPL infect JTS? Or is JTS released under both the GPL and LGPL? Or does releasing JTS under the LGPL meet the viral requirement of the GPL? The Sunburned Surveyor On 6/22/07, Edgar Soldin [EMAIL PROTECTED] wrote: Hello all, unfortunately separating the code is not enough too allow a new license. At a quick glance i only found only this http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCLinkingOverControlledInterface And to my knowledge the GPL enforces itself on derived work (incl. inheritance, use of interfaces). Thats why any work based on GPLed software has to be at least licensed for GPL. Dual licensing of the same is still allowed though. Regards ede -- Sunburned Surveyor wrote: Martin, Thanks for this great clarification. I believe in my particular case I will have to release the converter code under the GPL, since I will be linking directly to JUMP code to do the conversion. I'll have to consider how important it is to use GPL for other code I write that isn't tied as directly to JUMP. I'd appreciate any thoughts on this. Does code released under the GPL discourage use and adoption in a way that code released under the LGPL does not? yes.. do it under LGPL if you can (i.e. don't rely on GPL code). what i have done (though i am still not sure if it is truly correct) is to release the mapgentoolbox code under an apache like license. But the important thing has been that i have put my code in separate *.jars and not in the jar that contains the jump-extension class stuff. I think that having two jars is the way. stefan The Sunburned Surveyor On 6/21/07, Martin Davis [EMAIL PROTECTED] wrote: I don't think you can develop code that links in GPL code under anything except GPL. See here: http://www.gnu.org/copyleft/gpl-faq.html#GPLAndPlugins LGPL is weaker than GPL, so you can't release an actual plugin class (which uses the JUMP API's) as LGPL. However, I think what you can do is package up an independent library under some other license (as long as it doesn't use any JUMP code) and then call it from a wrapper plugin which is under GPL. Sunburned Surveyor wrote: I think Paul hit the nail on the head. GeoTools is worried about including code that can't be included in commercial applications. I found an interesting article that discusses whether or not you should use the LGPL or GPL for library code at the link Sascha sent. The article is here: http://www.fsf.org/licensing/licenses/why-not-lgpl.html I'll have to think carefully about this. It seems like a very important difference. Any thoughts on whether or not we want to encourage development of OpenJUMP plug-ins and support or library code under the GPL or LGPL? (I'm probably opening Pandora's box with this question.) I'm really undecided as to which license I should use for my code. The Sunburned Surveyor On 6/21/07, Paul Austin [EMAIL PROTECTED] wrote: The only problem would be if you used SS's new classes in a commercial application. Which in fact would be unlikely as they would not be allowed to use the JUMP code anyway because it is GPL. I think the rule is commercial apps can use LGPL libraries but not GPL ones. I took another approach for the same problem I added a FeatureFactory to my reader components and have a JumpFeatureFactory that will create features which implement both my DataObject interface and the Jump Feature interface. This way there is no conversion required between feature models. You just set the factory based on the type of feature instance you want. The reader uses this factory to create the instances. Paul Sunburned Surveyor wrote: I was talking to Jody Garnett a little bit about a home for a converter or pair of converters that would allow developers to do the GeoTools JUMP and JUMP GeoTools Feature Model conversion. He said that there may be some issues since any code that I write will necessarily need to utilize JUMP code released under the GPL. This is an issue because GeoTools is released under the LGPL. I don't know as much about this area as I should, so I'm hoping to get some suggestions from this group. How might I be able to get code that works with JUMP code under the GPl to play nice with GeoTools code released under the LGPL? Is this even possible? Thanks for the suggestions. The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list
Re: [JPP-Devel] GPL and LGPL (I need an attorney.) :]
This conversation has been great and has really helped me understand the difference between the GPL and LGPL licenses. I imagine that an important distinction between JUMP and GeoTools/UDig is the fact that JUMP is released under the GPL and can't be sucked-in by proprietary software. The Sunburned Surveyor On 6/22/07, Larry Becker [EMAIL PROTECTED] wrote: Right. It is the dependency that matters. JUMP depends on JTS. JTS doesn't depend on JUMP. And lawyers aren't always a bad thing. Some might say that the threat of layers is the only thing that keeps GPL code free. I might release some code under Larry's license but it would not be backed up by the threat of the Free Software Foundation suing you for violating the license. regards, Larry Becker On 6/22/07, Edgar Soldin [EMAIL PROTECTED] wrote: Simple.. as jump is derived from jts and jts LGPL does not enforce a type of license for the derived work... this is what makes it the Lesser GPL.. it declares the use of libraries to /work that uses the Library/ and excepts it from the derivation rule. see http://en.wikipedia.org/wiki/LGPL ede So how is it JTS can be released under the LGPL is JUMP uses it? Doesn't JUMP's GPL infect JTS? Or is JTS released under both the GPL and LGPL? Or does releasing JTS under the LGPL meet the viral requirement of the GPL? The Sunburned Surveyor On 6/22/07, Edgar Soldin [EMAIL PROTECTED] wrote: Hello all, unfortunately separating the code is not enough too allow a new license. At a quick glance i only found only this http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCLinkingOverControlledInterface And to my knowledge the GPL enforces itself on derived work (incl. inheritance, use of interfaces). Thats why any work based on GPLed software has to be at least licensed for GPL. Dual licensing of the same is still allowed though. Regards ede -- Sunburned Surveyor wrote: Martin, Thanks for this great clarification. I believe in my particular case I will have to release the converter code under the GPL, since I will be linking directly to JUMP code to do the conversion. I'll have to consider how important it is to use GPL for other code I write that isn't tied as directly to JUMP. I'd appreciate any thoughts on this. Does code released under the GPL discourage use and adoption in a way that code released under the LGPL does not? yes.. do it under LGPL if you can (i.e. don't rely on GPL code). what i have done (though i am still not sure if it is truly correct) is to release the mapgentoolbox code under an apache like license. But the important thing has been that i have put my code in separate *.jars and not in the jar that contains the jump-extension class stuff. I think that having two jars is the way. stefan The Sunburned Surveyor On 6/21/07, Martin Davis [EMAIL PROTECTED] wrote: I don't think you can develop code that links in GPL code under anything except GPL. See here: http://www.gnu.org/copyleft/gpl-faq.html#GPLAndPlugins LGPL is weaker than GPL, so you can't release an actual plugin class (which uses the JUMP API's) as LGPL. However, I think what you can do is package up an independent library under some other license (as long as it doesn't use any JUMP code) and then call it from a wrapper plugin which is under GPL. Sunburned Surveyor wrote: I think Paul hit the nail on the head. GeoTools is worried about including code that can't be included in commercial applications. I found an interesting article that discusses whether or not you should use the LGPL or GPL for library code at the link Sascha sent. The article is here: http://www.fsf.org/licensing/licenses/why-not-lgpl.html I'll have to think carefully about this. It seems like a very important difference. Any thoughts on whether or not we want to encourage development of OpenJUMP plug-ins and support or library code under the GPL or LGPL? (I'm probably opening Pandora's box with this question.) I'm really undecided as to which license I should use for my code. The Sunburned Surveyor On 6/21/07, Paul Austin [EMAIL PROTECTED] wrote: The only problem would be if you used SS's new classes in a commercial application. Which in fact would be unlikely as they would not be allowed to use the JUMP code anyway because it is GPL. I think the rule is commercial apps can use LGPL libraries but not GPL ones. I took another approach for the same problem I added a FeatureFactory to my reader components and have a JumpFeatureFactory that will create features which implement both my DataObject interface and the Jump Feature interface. This way there is no conversion required between feature models.
