LGPL Findings

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"