Patrik Stridvall ps@leissner.se writes:
For example: void CryptFoo() { CRYPT32_CryptFoo(); }
and release the code above under the LGPL.
That's the square root example. If you do that, you have to make sure that the use of CRYPT32_CryptFoo is optional and that the function still behaves properly if your CRYPT32 function is not available.
Forget for a moment I was trying to circumvent the LGPL.
Lets say I just found a crypto library called CRYPTO32 under a proprietory license that I wished to use. It so happends that they had almost 100% the same functions as the Crypto API.
So almost all functions would look like void CryptFoo() { #if HAVE_LIBCRYPTO32 CRYPT32_CryptFoo(); #else /* Old Wine code */ #endif }
with a few minor exception.
So you mean that I can't legally do that despite the fact that the LGPL is meant to allow linking to proprietary licenses.
I think you have misunderstood something seriously. Please, this is the absolute worst argument from you as of yet. You can't seriously believe this.
Also note that the code that I wrote above was supplied under the LGPL, so I don't see how you can claim that I violated the LGPL.
The company that wrote the proprietory library neither knew about the me nor about Wine so how can they have violated the LGPL.
They had a goal and I'm sure a lot of competent people did the best they could be accieve it.
However, you can do the impossible no matter how hard you try.
Strangely there are thousands of people, including lawyers, who seem to think that the LGPL does what it claims to do. If the problems are so obvious, how come no one else sees them? Could it be that maybe, just maybe, it is because all these people are right and you are wrong?
Could it be that they rely on that that the dotrine of derived work will save them from people trying to use the lopeholes in the licenses?