The LGPL and Java:

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that -- people who modify the library are responsible for making it work.

That's why the LGPL is no good; this is an exploitable hole to allow people to modify a library and start reverse engineering your code, it would seem. I'm not real sure why that's bad, but I do know it's not something I'd particularly want butting up next to my proprietary code.

Perhaps this is why a number of pay-to-play companies run a secondary, "Free as in Mozilla Public License" codebase. Having grown out of the need to recreate Netscape, not to become part of an idealistic Hurd, the MPL watches companies' backs well. Too well.

Here's the metaphor I heard that got me interested in the LGPL (IANAL):

You're making a calculator. You've got every button down except the square root button. You decide to look at external libraries to save time.

GPL Square Root -- You can embed the function and sell your software, but now every bit of your calculator, plus, minus, 1s, 5s, the whole thing, must be released with full source code. Now anyone can take your code and sell your application. Anyone. Not necessarily a bad thing, unless you like to make money. Everyone can use your first-rate natural log function, but do remember that they, too, can't sell this [legally] without showing the code to anything they've added. Great for promoting passive collaboration.

LGPL Square Root -- Originally, before the Java issue, I thought the LGPL went like this: You can add this square root function, release and sell your app. You only have to include source to the square root function; everything else can stay proprietary. Let's say, however, that you find a bug in the square root function, say it thinks the square root of 49 is 8, but gets everything else right -- or that it only goes to 5 decimal places. If you fix the bug or extend its accuracy to 10 decimal places, you have to release the source to those improvements with your app. Personally, that's great so far. I like it. If you only have the function b/c of someone else's contribution, you owe it to him/her/them to release your improvements for all to use. It enables passive collaboration, but still allows you to protect your investment. Nobody "deserves" your fancy natural log function if you don't want to give it to them. It was entirely your work. Keep it. The "rights" to the code are protected from both sides, and fairly. You'd also owe the 'LGPL' a big thank you, of course, but you get the point.

BSD Square Root -- Take it. Sell your app. You might have to acknowledge the project whose work you took, but that's it. It's yours. Take it from 5 to 10 decimal places of accuracy, heck, take it to 2000, and you don't have to share a keystroke. Great for greedy people who don't want to be bothered, but I'd hope they'd feel a little bad about taking work to which they didn't -- nor will -- contribute.

MPL Square Root -- You can take this square root function, release, and sell your app.  In fact, you could (afaict) take your own square root implementation, take a few files from the MPL version, and put those together to be released.  Your own, wholly original code could stay closed, and only changes you made to MPL files would need to be released.  Initially, I thought the MPL was like BSD.  As is obvious here, it's not.  It's sort of like the LGPL in that your code can be released in support of and as part of a closed source product, but it's "file-level" in that any file of your library could potentially be taken and used in a new context.  But it's as close to the LGPL as you can get if you want to allow someone to compile your code alongside proprietary code, and it doesn't seem exceptionally evil.  It's a good deal less protective than the LGPL, but just good enough that I still like it.  (MPL section added 20131011.)

Okay, comparison over. But now, following the relatively dated quote about Java issues, above, (iff the Java issue is legit) the LGPL forces anyone using the square root function to allow anyone to decompile their entire app that uses the square root function to "bug check" against their code.

That's simply not a place I want people going. Short of the square root function, it's my code. Stay out. If you want my code to work, use the old library that thinks 49's square root is 8. If you can upgrade the lib to work with 49, great, but why should I have to give you any rights to my code downstream of the square root function to make that happen? You didn't make the investment in app, and I want to protect it. That should be my right. You shouldn't get to peek at my natural log function if I've used LGPL code elsewhere. If your change to the square root -- and who knows how inane that change might be; perhaps it also now doesn't do 36 correctly -- breaks compatibility with my app, that's my problem. I'll fork the square root lib if I have to.

Oh well, guess I'll eventually have to start my GNG (GNG's Not GNU) movement with an LGPL done, if not right, then fair. Might be as easy as slashing Section 6 in the LGPL; I'll have to check sometime. Now, on to UO (I'm on sabbatical from WoW)!

Labels: , ,