David Elliott wrote:
Dimitrie, this is exactly what Patrick and I have been trying to argue against. If you read the LGPL it does state that you can statically link as long as you provide the means for your users to statically link with a newer version. One way to do this would be to provide the object files from the compiler, or a .a file with all of the combined objects that can be relinked with a newer version of Wine.
The example we have been using is that you could write a proprietary CryptoAPI and link it with the rest of the advapi32 to come up with a libadvapi32.so which includes CryptoAPI. You can call all the functions in the rest of advapi32 (i.e. the LGPL part) that you want to. So long as you provide a way to update the LGPL components you are in the clear. This is covered by section 7 which states that you may place library functions that are a work based on the library (i.e. the original LGPL ADVAPI32) ... in a single library together with other library facilities not covered by this license. The single library would be the libadvapi32 including the proprietary cryptoapi. In order to do this you must a) provide a copy of the work based on the library not linked with the non-LGPL stuff. and b) give prominent notice as usual.
Now, here's another something to mull over. We've pretty much established that you could statically link something proprietary with something LGPL. One question I have is how much of the library are you allowed to use. Alexandre mentioned that while the CryptoAPI example would be a pretty clean-cut allowed case, a proprietary CreateWindow would not be allowed. His argument was that because it would necessarily use internal functions and data structures that it would be a derived work and thus subject to the license.
I think what Patrick has been trying to get at is that that is not very clean-cut and that in fact there is little to no precedent on what exactly a derived work is. If Alexandre is indeed correct then we are pretty well protected. If it is at the opposite extreme and anyone could statically link in proprietary versions of functions then we have very little protection and it really makes it not worth it to go LGPL. At least that is what I think Patrick has been trying to say.
Let me put it to you the way I see it. Whether a function or data structure is exported or not does not matter. It would be trivial to declare an internal structure or function as exported and thus the proprietary function is simply making use of the library and therefore not a derived work. That is my argument that avoids all of Patrick's doctrine of derived work crap and gets right down to the fact that it's trivially easy to make your work fall under the work that uses the library category, so long as it is a seperate object file. That is, to put it in Slashdot terms, a "Big Gaping Hole(tm)"...
And so I emphasize my original statement now. The only thing the LGPL really prevents is the direct use of the source code. Anyone wanting to release a proprietary implementation of any function can do so fairly easily simply by 1) writing that particular function from scratch, and 2) keeping it in a seperate object file.
Thanks for explaining what Patrik has been going on about. In summary:
Consider a proprietary application which ships as a proprietary library which is statically linked with LGPL libraries at install time in a way that lets users supply new versions of the LGPL libraries. This lets them fix bugs in the LGPL'd code and thus in the proprietary app. The harm you see is that a vendor could, once he found a Winelib function with a bug, simply do his own clean-room implementation of that function, and use it instead of the Winelib version of it, and keep the improvement to himself -- which would also deprive the user of the ability to fix bugs in the proprietary reimplementation of that particular WineLib function.
Did I get it right? - Dan