On 2001.12.15 20:01 Alexandre Julliard wrote:
David Elliott dfe@tgwbd.org writes:
The crypto part of ADVAPI32 was the example I used. Let's say I were to write a CryptoAPI implementation as a set of seperate source files. With the LGPL I could compile all of that stuff and refer to it as a library. What is a library? I would say one or more object files linked together form a library. I could then take my CryptoAPI library, link it with the rest of Wine's ADVAPI32 and distribute a libadvapi32.so that could be dropped into a wine install.
If it is a completely separate library that doesn't contain portions that are derivative work of ADVAPI32, then yes you can do that. But you cannot for instance decide to reimplement CreateWindow and not release it simply by putting it into a separate file, which was what Patrik suggested; because your new CreateWindow will necessarily use internal functions and variables of USER32, and thus would be considered a derivative work.
Yes, I now realize in the mail I just sent out a few seconds ago that Patrick seemed to misunderstand me a little bit. You seem to be thinking more like I am.
While I am thinking about this, there are some interesting things in the LGPL. One of these is that you can modify the LGPL library to work with your code. The catch is that you have to release source to the modifications and that the modifications must not require that your proprietary component be included. The text of the license mentions that if you modify a function that computes square roots to hook into your proprietary components that the function must still compute square roots. But in Wine's case, many functions don't do what they are supposed to do, or they do what they are supposed to do but that's not what actually needs to be done. This stuck out like a sore thumb to me, but maybe it's not such a big deal.
Apparently my cryptoapi example was very clean cut. From my point of view it would only make sense that people would be allowed to make a proprietary section of a DLL as long as it was a seperate libary as specified by the LGPL. Your example is a bit more of a gray area. While I would hope that it couldn't be done, I am not seeing any language in the license preventing one from doing it. If CreateWindow were implemented from scratch as a proprietray "library" and called into functions provided by the LGPL library (Whether internal or not I would think) the LGPL would allow this. Accessing data I would think would also be allowed, again, whether internal or not I don't think makes a difference.
Basically what we need to know is how much protection is offered by the LGPL and is it worth it. And by how much protection I mean after all the various interpretations of the LGPL have been brought out in court what can people get away with and what is clearly and most definitely going to be protected.
-Dave