intertwingly

I posted some comments and questions at http://radio.weblogs.com/0122027/2003/07/16.html#a56.

Sometimes the world takes an odd turn.  I missed my intended ferry back from the SeaJUG meeting last night.  This was partially due to pilot error (I trusted the clock on the wall at Stella's instead of looking at my phone), and partially... [more]

Trackback from Ted Leung on the air

I suggest JMX as a more generic solution.  Also be clear: doing Class.forName("com.foo.FooDriver") would probably still bind to LGPL.  I would suggest Class.forName(myDriverFromPropertiesFile) wouldn't nor would a configured DataSource of course.

Can someone please explain to me how they have arrived at these conclusions about section 6. The way I'm reading it, Section 6 allows LGPL libraries to be used with OS projects.

Follow this quote: "distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications."

I even think that the term "modification of the work" refers to the executable. It doesn't even mention the source code of the "work" anywhere in section 6. Someone enlighten me please!

Ryan, IANAL.  That being said, the root problem appears to be that terms "executable" and "link" don't have clear mappings to Java.  This terms form the basis for the distinction between LGPL and GPL.  Without that basis, it appears that there is no distinction between the two licenses for languages like Java.

Not being a lawyer, this is not something I personally am equipped to debate.

Section 6 of the LGPL allows use in not just Free Software, but also proprietary software (so long as that software doesn't prohibit stuff like reverse engineering).

Judging from the LGPL and David Turner's reading that Java's linking falls under section 6, it seems the conclusion "applied to Java, the LGPL is equivalent to the GPL" is just plain wrong. Isn't Turner saying that Java importing is a suitable mechanism under section 6b, just like C shared libraries?

What am I missing?

David, Aaron: Every person I know of who has talked to a lawyer or directly to the FSF has come back with the same answer.  What I am told is that when it comes to contract law, ambiguity is not a good thing.

What is a Java executable?  Is it OK that simply by unpacking a Jar I get a different answer?

The two paths I alluded to above are (1) either follow the path starting from denial through to acceptance, or (2) take some action which changes the answer.

You get the same answer whether or not you unpack the jar. 

(and, BTW, this whole thing is my fault for not giving a longer answer to Andrew -- I answer licensing at gnu.org.  Sorry.)

David: from your answer, I gather that the jar itself is irrelevant.  Perhaps the fundamental unit is the class?

In any case, gathering by your comment @ Thu Jul 17 23:07:14 EDT 2003, I gather that there is a longer answer in the works that would remove any ambiguities?

If so, that would be most appreciated!

Section 5 states "A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. ...  However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."

In Java, there is no clear "executable" (unless you argue any class with a run() method is one), but it is difficult to say there is no clear definition of linking (or any clearer than in C, as the license text itself implies).

Declaring an import has two potential effects. If the import causes the java compiler to copy in code from the imported library, then this is analogous to including code from a header file from an LGPL'd library. This is what the LGPL has to say about that situation:

" When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law."

However, the license provides this caveat: "If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)"

Therefore, it seems that importing an interface (for example) to get access to a constant value, accessors, etc. is not enough to force the work to be LGPLd.

The other affect of the import is analogous to a shared-library link. This would fall under section 6. Section 6, part b, however, allows for the use of "a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with."

It is easily demonstrable in java that one can swap out an imported class with another class which is interface-compatible. Furthermore, since java does not statically link (except to inline constants and such, which was expressly allowed in Section 5), at no time would a compiled java class which imports an LGPLd class contain any of the LPGLd class (object) code.

As to the first paragraph of Section 6, since per Section 5 the java code itself is not part of the "work containing portions of the Library", the only requirement is that the work which actually links the LGPLd code (the compiled class files, via Java's import mechanism) be distributed under terms which allow for modification and reverse engineering.

Do the same issues apply to a fusion of "traditional" code and Java?

If I wrote two C shared libraries, one that contained Java shim classes and another that used a distinct API that was not class-based, would this clear the LGPL hurdle?

This is a common pattern, of course, which is why I wonder about it. The shim classes call the traditional API and create class structure where there was none. And the traditional .so linkage is already defined as ok...

If this is ok, then it would seem to suggest an implementation path.

Aaron Gaudio - please see the discussion taking place here.

David: That seems perfectly unambiguous.  (And that's a good thing).

After reading the various comment threads, and seeing Andy and David's exchange in a bit more context, I'm more confused than ever. As quoted by Andy, Roy wrote: What the FSF needs to say is that inclusion of the external interface names (methods,...

David Stutz, there is no hurdle -- if your software is linked to LGPL software, directly or indirectly, you need to follow section 6.  Section 6, however, does not require you to LGPL your software.  It just has a few minor restrictions intended to keep the library Free.

David Turner - would it be possible to clarify somewhere exactly what the word 'link' means in the context of Java?  This would go a long way towards reducing the confusion that exists in this area.

Section 6 only applies to to combined works that are distributed.  What section 6 says exactly is: "you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications."

When is your Java app "containing portions of the Library"?  Why when it is executing of course.  Therefore, section 6 applies if you are distributing a memory image of your application running with the lgpl code.

If your application is designed to work with the LGPL code but does NOT contain code from the LGPL base, then section 5 clearly spells out that this work is "isolated", and is therefore NOT subject to license restrictions.  As section 5 says:

"A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library".  Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."

This "directly" or "indirectly" linking idea is false.  The LGPL describes different rules for different linking methods.  Indirect linking, that is having none of the lgpl code in your application, but having an application that is designed to use the lgpl code, means section 6 does not apply to you.

Joe: Every person I know of who has talked to a lawyer or directly to the FSF has come back with the same answer.  What I am told is that when it comes to contract law, ambiguity is not a good thing.

Given that David Turner has said that it is section 6 that applies.  We really need a clarification, from the FSF.

It sounds like some people are getting concerned about the LGPL now. I'm ranted about my dislike of the GPL before. According to this post to POI-dev, Dave Turner (Mr License) of the FSF has decreed that the steps required to use an LGPL'd Java...

<p><a href="http://linuxintegrators.com/hl30/blog/" title="Andy Oliver's Blog">Andy</a> has finally <a href="http://article.gmane.org/gmane.comp.jakarta.poi.devel/5900" title="poi-dev@jakarta.apache.org: Re: [Followup] RE: Possibly... [more]

Trackback from Rod Waldhoff's Weblog

After <a href="http://linuxintegrators.com/hl30/blog/technology/?permalink=LGPL in Java.html... [more]

Trackback from Rod Waldhoff's Weblog

The alpha for Clover.NET is coming along nicely and we are getting some great feedback. Thanks to our alpha testers. The alpha is currently command line driven and that is not really optimal in the long term. We're working on Visual Studio...

The alpha for Clover.NET is coming along nicely and we are getting some great feedback. Thanks to our alpha testers. The alpha is currently command line driven and that is not really optimal in the long term. We're working on...... [more]

Trackback from Code Feed