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

Personally, I use pure auravedic grade ground hing, that way I know exactly what I'm getting.
42 ms