Dan Kegel wrote:
Patrik Stridvall wrote:
Which is my response to Rogers comment above - sure the GPL prohibits linking with a nonfree component.
Yes, but what is linking?
Don't you understand it is the vagueness of linking that is the problem.
I don't think it's vague. We can define it quite well. If bytes derived from object A end up in the same file as bytes from object B, they are statically linked. If they are in separate files, but one calls the other via a function call in the same process, they are dynamically linked.
this does not apply directly to wine, but using that definition, a shared library that contains only variables assignments (let's say it's a localization module), would be considered "statically linked". As for the latter, see next response (linux threading model sucks).
If they are in separate files, and one calls the other via a function call that crosses process boundaries (i.e. uses a remote procedure call protocol), there is no linking, at least not by current standards (and I bet this will not change).
so, given that linux's threading model creates a separate process per thread, can call calls by the thread be considered a remote call? Or in wine's case, you're going to make a distinction between server dlls and client dlls ONLY because they cross a process boundary?
If you think this is ugly, try applying this to java, where the concept of "file" (since the classes can be in a zip file) an app (since there is no concept of an 'executable' - just entry points), or even a 'process space' is vague.
Header files for LGPL'd works are interesting; if they contain macros or inline functions, those need to be provided under a more liberal license, otherwise they would fit the definition of static linking.
section 5 is SUPPOSED to address this issue, but it depends on what people think "small" means.
Patrick just doesn't like the goals of the LGPL, I think.
Guess it depends if you think LGPL is viral or not.....
-r