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
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: > >
Re: [JPP-Devel] GPL and LGPL (I need an attorney.) :]
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 in
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
Re: [JPP-Devel] GPL and LGPL (I need an attorney.) :]
Hi SS, If JTS used JUMP then it would need to be under GPL. GPL software such as JUMP can use non-GPL components such as JTS. The rule (I think is) if you have an application that uses GPL components, those components which utilize GPL components must also be GPL. I think a general good guiding principal is if you want to define an interface that components can implement and you want to allow proprietary implementations you should define that interface using a less restrictive license than GPL. Personally I'm not a fan of GPL due to the confusion it causes. As an open source software developer I want people to use my code not have to worry about dealing with lawyers. Paul Sunburned Surveyor wrote: > 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 f
