Re: LGPL Findings

Still +1 from me for LGPL.

On Thu, 2004-01-15 at 02:08, Christian Cryder wrote:

> Hi folks,
> 
> Sorry to be so long in getting back to the list with this, but it took me a
> bit to collect the data. Last weekend I emailed Dave Turner, of the Free
> Software Foundation (he's the LGPL guy mentioned in some of the links given
> previously), to seek clarification from the horse's mouth on the LGPL
> questions raised recently on the list.
> 
> Here's his first response...
> ------------------------------------------
> > My name is Christian Cryder, and I represent an open source project called
> > Barracuda that is currently considering switching to the LGPL license. We
> > have some concerns, and I'm hoping you can expand on your comments here:
> >
> http://lists.debian.org/debian-legal/2003/debian-legal-200307/msg00234.html
> >
> > Specifically, I understand your comments here to say that if a developer
> > uses LGPL Java code (ie. via jars, import statements, method calls, etc),
> > that the java developer's code does not qualify as a "derivative work" and
> > thereby does not need to be LGPL'd.
> 
> dt> I didn't say that.  I said that the LGPL specifically allows this class
> dt> of derivative works to be licensed under terms different than the LGPL.
> 
> > My question then is, "what exactly would
> > make code that uses the LGPL library fall into the 'derivative work'
> > category?"
> >
> > -if I actually change the LGPL library source (ie. I modify its core
> > functionality) and rebuild/rejar it (yes)
> 
> dt> Yes.
> 
> > -if I simply use import statements and invoke methods of objects in the
> LGPL
> > library (no)
> 
> dt> Yes, that would be a derivative work, but would not need to be licensed
> dt> under the LGPL.  Section 5 of the LGPL permits this with no restrictions
> dt> in the case where you are not distributing the LGPL library.  Section 6
> dt> of the LGPL permits it with only minor restrictions in the case where
> dt> you are distributing the library.
> 
> > -but what if I _extend_ LGPL classes which were designed for that very
> thing
> > (???)
> 
> dt> Extending classes also creates a derivative work.  It seems to me that
> dt> the boundary of a library in Java is usually the package or jar file
> dt> boundary.  So, if you add a class for loading PNG files to an image
> dt> loading library, extending the base image loading class, that would need
> dt> to be LGPL.  But if you write a special image loader which (say)
> dt> autodetects image types, and don't put it in the image loader's package,
> dt> but in your program's package, then it need not be LGPL (so long as you
> dt> follow the restrictions in section 6).
> 
> > To make the issue more clear - Barracuda is a webapp framework which by
> > design requires developers who use the framework to extend base classes
> (ie.
> > Java extension forms the backbone for developers to 'plug in' their
> > application specific functionality). We want to ensure that this would not
> > force the developer's application to be LGPL'd as well.
> 
> dt> I think in that case, the LGPL would work as you want.
> ------------------------------------------
> 
> Now, I followed this up with a couple of additional questions. Here's his
> second response...
> 
> ------------------------------------------
> > Thanks for answering my questions - I think you've cleared up most of my
> > misconceptions, but I do have one followup. Right at the tail end of
> section
> > 6, I see this paragraph:
> >
> >     For an executable, the required form of the "work that uses the
> Library"
> >     must include any data and utility programs needed for reproducing the
> >     executable from it.
> >
> > I'm wondering exactly what this means for Java. We generate .jar files,
> not
> > executables. So, let's say I have 2 jars in a web application (think
> > servlets) which I intend to sell/redistribute:
> >
> >     a) SomeLib (LGPL)
> >     b) MyApp (custom Java code that uses SomeLib by extending abstract
> > classes, implementing interfaces, etc)
> >
> > Now let's say the compiled code for each of these lives in its own jar
> file
> > (somelib.jar, myapp.jar). I understand that I need to provide the source
> for
> > SomeLib, along with a means to compile it, so the person who buys my app
> can
> > change the SomeLib implementation if they desire. Does the LGPL snippet
> from
> > section 6 (above) mean that I must also provide the source for MyApp?
> 
> dt> No.  That applies to the uncommon case of distributing statically linked
> dt> binaries (impossible in Java).
> 
> > Also, under what conditions does Section 2c kick in?
> >
> >     c) You must cause the whole of the work to be licensed at no charge to
> > all
> >     third parties under the terms of this License.
> >
> > I am assuming that if I create a custom version of SomeLib (ie. MySomeLib)
> > and then use that in conjunction with MyApp, the MySomeLib portion of the
> > resulting application must also be LGPL'd, but not MyApp. Yes?
> 
> dt> Correct.
> 
> > What I'm trying to understand is under exactly what circumstances MyApp
> > would also be required to be LGPL'd (hopefully in neither of the above
> > cases).
> 
> dt> There are no such cases, unless MyApp were not in fact an app, but just
> dt> a modified version of SomeLib.
> ------------------------------------------
> 
> Ok, so the gist of all this is that I believe LGPL is in fact safe for Java
> in all the cases we've thought of. Essentially, what it amounts to is that
> anytime you use an LGPL library, you are creating a derivative work (even if
> you are just importing etc). Now, just because its a derivative work doesn't
> mean it has to be LGPL - you can still license your resulting app under
> whatever license you want. The only real limitation is that if you choose to
> distribute your app, all you have to do is make the LGPL'd portions
> replaceable (and provide any customized source for those portions alone).
> 
> The only time you would _ever_ have to license your resulting app as LGPL
> would be if the whole thing (including the LGPL code) was a _statically
> linked library_ - what as Dave says: "[The tail end of Section 6] applies to
> the uncommon case of distributing statically linked binaries (impossible in
> Java)."
> 
> So let's say you extended Barracuda with your own custom version
> (BarracudaOnSteroids.jar) and then created an app that used it. You would
> have to release your custom Barracuda code as LGPL, but your proprietary app
> could continue to be licensed/distributed as you see fit.
> 
> The bottom line then: LGPL seems perfectly fine (and probably best) for what
> we want it to do - it allows for commercial applications to be built on top
> of Barracuda without infecting them, and yet it requires changes to the
> library to remain in the public domain.
> 
> SO...if anyone still has questions or comments, let's here them, but as for
> me, I think I'm +1 on LGPL.
> 
> Special thanks to David Turner of the Free Software Foundation for taking
> time to explain all this to me...
> 
> Christian
> ----------------------------------------------
> Christian Cryder
> Internet Architect, ATMReports.com
> Project Chair, BarracudaMVC - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda