IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New LGPL Considered Viral in Java
Looks like the FSF considers linking an LPGL licensed jar file into a Java app using "import" to cause the code importing the jar file to become LGPL also.

[link|http://linuxintegrators.com/hl30/blog/technology/?permalink=LGPL+in+Java.html|link]
New Re: LGPL Considered Viral in Java
From [link|http://www.gnu.org/copyleft/lesser.html|http://www.gnu.org/copyleft/lesser.html]:
5. 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.

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.

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.)

Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.

6. As an exception to the Sections above, 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.

You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
[...]
  • b) Use 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.
Emphasis mine. I am not a lawyer, this is not legal advice, but it seems to me that 1) The portion I highlighted has significance in making the decision and 2) even if it is a "work that uses the Library", then if falls under section 6b).

Regardless, this is the Apache Software Foundation's opinion only. Most other open source groups do not take such a conservative view with Java.

Also, reading the [link|http://superlinksoftware.com/text/lgpl.txt|email] lends a different interpretation. Read Turner's comment at the very end of the blog:
Comment by: David Turner -
Left on: Thu Jul 17 23:07:14 EDT 2003

Jonabell, I'm not a lawyer. I'm a licensing guy. I know how to program in Java (although I prefer Perl or Python). I understand, at an operational level, how Java does libraries. My message is that the LGPL works basically the way everyone has always thought it does -- that it is not the same as the GPL. Of course, not everyone knew about the reverse engineering stuff in Section 6, but it's not a secret -- it's mentioned in the GPL Quiz on FSF's site, for instance. Fred Grott, the CPL is much closer to the GPL than the LGPL.

Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Re: LGPL Considered Viral in Java
Emphasis mine. I am not a lawyer, this is not legal advice, but it seems to me that 1) The portion I highlighted has significance in making the decision and 2) even if it is a "work that uses the Library", then if falls under section 6b).

Regardless, this is the Apache Software Foundation's opinion only. Most other open source groups do not take such a conservative view with Java.


I was under the same impression as you. We are starting development on a commercial application and I need to be very careful it doesn't accidently get open sourced. I've urged my manager to pass the licenses past the company laywers as cover. I'll post any results if I can.

Regards,
John
New Not by the FSF
The FSF does not consider the LGPL to be viral, i.e. Java software using the LGPL may use any licensing scheme they desire as long. They just have to make sure that the end user can link in modified versions of the LGPL software used by the main program (a trivial requirement in Java). This is no different for Java than for any other language.

FSF Executive Director Bradley M. Kuhn explicitly and publically agrees with this interpretation:
[link|http://developers.slashdot.org/article.pl?sid=03/07/17/2257224&mode=thread&tid=108&tid=117&tid=126&tid=156&tid=99|http://developers.sl...26&tid=156&tid=99]
--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
New Yabut...
Here's what Dave Turner from the FSF said on Andy Oliver's [link|http://linuxintegrators.com/hl30/blog/general/?permalink=LGPL+clarification.html&page=comments|blog]:
Dave: Section 6 of the LGPL is not the same hereditary thing as section 2 of the GPL -- what it says is that your program, which links against the library, does not need to be licensed under the LGPL. But you do have some obligations -- you need to allow people to relink your code with new versions of the library, for example.

Andy: So Dave... My ASL project: [link|http://jakarta.apache.org/poi|http://jakarta.apache.org/poi]. Lets say we link in a library using LGPL. Lets say then IBM links POI in to WebSphere. Does this mean that THEY have to follow section 6? No biggy if POI does, its whether the NEXT guy linking in POI (We're talking java imports and jars when I say link) has to follow section 6. This if he does...its "viral". I understood you to say this was INDEED true for Java imports/jars.

Dave: [copied from email I sent you, quoted here for posterity. One word removed because it was unclear.] I would say that the answer is "yes" here. But let me explain a few things to qualify this. First, I'm not sure that you understand section 6 of the LGPL. Section 6 says: "...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. " Note that this does not require the provision of source code, nor does it require allowing the program or modifications thereof to be distributed. This isn't the same as GPL's section (2)(b), which is the engine of the GPL's hereditary nature. Second, it's clear that a larger work which links to POI also links to the LGPL'd libFoo -- it may not directly call methods from libFoo objects, but the whole work is clearly derived from libFoo (along with POI and, in all probability, many other works). To say otherwise would be to open up a loophole in the licensing.
It sounds like LGPL doesn't force me to open source my project but it does require me to allow the user to relink newer versions of the LGPL'd lib into the application and require me to allow reverse engineering of my application. Calling it viral is the wrong choice of words. It is looking like it's something to be avoided in a commercial app though.

Regards,
John

New Re: Yabut...
John: It sounds like LGPL doesn't force me to open source my project but it does require me to allow the user to relink newer versions of the LGPL'd lib into the application and require me to allow reverse engineering of my application. [...] It is looking like it's something to be avoided in a commercial app though.

If the LGPL library is a separate JAR, it is trival to relink. In fact, I'm not sure how you would prevent it in Java. And the reverse engineering is only to debug compatibility issues with the replacement library, which doesn't seem to me to be unreasonable terms, even for a comercial app.

(aside, perhaps you were speaking in general, not just about Java. If the LGPL library is provided as a DLL/SO library, then relinking is still easy.)

--
-- Jim Weirich jweirich@one.net [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
New Breaks our copyright
And the reverse engineering is only to debug compatibility issues with the replacement library, which doesn't seem to me to be unreasonable terms, even for a comercial app.

I took a look out our copyright and it includes a clause forbiding reverse engineering. My guess is the lawyers aren't going to let us use LGPL libraries.

Regards,
John
New What is commercially unreasonable?
If you are a company, you are in the business of doing (hopefully legal) activity X at a profit.

Anything which gets in the way of your making a profit is therefore not in your interests, and you are going to find it unreasonable to be required to do it.

Now as most of us know well, software companies stand to make a lot more money when customers are locked in - in fact theory says that the maximum profit that companies can extract from this desirable situation is the sum of their customers' switching costs. So anything that increases lock-in is a Good Thing™ from the point of view of a company. (Though not, obviously, from the view of the customers.)

Therefore the provisions in the LGPL, which are intended to make it easier to unlock people by creating a free alternative, is a Bad Thing™. Thus they don't want to do it. Which is why the FSF found it worthwhile to release software under a license which attempts to extract that behaviour modification from would-be users.

In short, if it was something that companies would normally find reasonable to do, then the FSF would have no reason to bother getting companies to do it.

Cheers,
Ben
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
     LGPL Considered Viral in Java - (johnu) - (7)
         Re: LGPL Considered Viral in Java - (admin) - (1)
             Re: LGPL Considered Viral in Java - (johnu)
         Not by the FSF - (JimWeirich) - (4)
             Yabut... - (johnu) - (3)
                 Re: Yabut... - (JimWeirich) - (2)
                     Breaks our copyright - (johnu)
                     What is commercially unreasonable? - (ben_tilly)

Inquiring minds want to scream.
81 ms