MS Word (to use an example) might have to dynamically link in a special MS Word component to process specifics in my document, it doesn't mean my document is "linked" with the MS Word component does it?
Ah, you are beginning to see the problem. :-)
What problem? A GPL program is the same as any other - GPL protects the code, not the use of said code.
Indeed. It is a not a use license.
However because of the doctrine of derived work that GPL depends upon, some use (read: linking) are considered derivation and thus a possible violation of the GPL.
There's nothing to stop a GPLed program such as, say an amiga emulator (UAE) running the emulated non-free software. As geoffs example rightly points out.
You think (read: hope) that it is not so because it would be quite absurd wouldn't it?
However if the doctrine of derived work is strong enough to prevent want the GPL hopes it will prevent namely linking, I see no reason to assume that emulation would be considered differently. After all from a technical point of view essentially that same things that happends.
And in any case, we are talking about the LGPL - a totally different matter.
Not entirely whatever power the LGPL have also derives from the doctrine of derived works eventhough is doesn't try to use it to the extent that the GPL does.
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. This is further made worse by that fact that the doctrine of derived might possible, and are very like to do, at least to some extent, place some kind of limit on what linking legal extends to.
That 'closes' the source and provides far too many ways to cheat the license.
The LGPL allows dynamic linking with a nonfree component. Remebering that the LGPL is meant to apply to LIBRARIES (hence allowing a libssh library to use nonfree crypto routines for example) not for an application.
You can cheat with both the GPL and the LGPL at I have tried to illustrate in earlier mails, but the LGPL at least as applied to Wine is a gaping hole, that hardly provides any protection at all.
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. 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).
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.
Patrick just doesn't like the goals of the LGPL, I think.
- Dan
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
Roger Fujii wrote:
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,
It doesn't. It creates a new thread that happens to share address space with some other threads. The scheduler schedules threads, not processes. Perhaps it would be clearer if I said 'address space' instead of 'process'. (IBM is working on a new threading library that will make you happy, I think; it makes use of the "thread group" feature in the 2.4 kernel.)
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?
Yes. A call that crosses an address space boundary by using a remote procedure call protocol is considered remote, and is neither static nor dynamic linking.
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.
Replace 'file' with 'class' for java. That takes care of it, I think. I don't think we need to define application. If we did, 'hunks of executable code in the same address space/process', or a collection thereof, might do.
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.
Got it. I really should read the LGPL if I'm going to pontificate about it!
- Dan
Dan Kegel wrote:
Roger Fujii wrote:
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,
It doesn't. It creates a new thread that happens to share address space with some other threads. The scheduler schedules threads, not processes.
yes, but threads and processes are not independent. Look at this: http://www.samag.com/documents/s=1148/sam0107a/0107a_s1.htm It *appears* like a process to the user in the ui (ps has separate PIDs). The problem is that words like "process" and "linking" really require some context around them and it's hard to codify that in a document.
Perhaps it would be clearer if I said 'address space' instead of 'process'. (IBM is working on a new threading library that will make you happy, I think; it makes use of the "thread group" feature in the 2.4 kernel.)
Don't think it would change all the much. Think what 'address space' means in a NUMA model. 2 threads running in the same address space MAY be running on separate processors with a copy of the address space..
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?
Yes. A call that crosses an address space boundary by using a remote procedure call protocol is considered remote, and is neither static nor dynamic linking.
So, a windows DLL under windows is neither static nor dynamically linked since the DLLs live in a funky state that is in the 'kernel' process space and not with the app (at least, this is what I remember).
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.
Replace 'file' with 'class' for java. That takes care of it, I think.
uh, nope. As java source files can compile into MANY .class files (inner classes).
I don't think we need to define application. If we did, 'hunks of executable code in the same address space/process', or a collection thereof, might do.
but this would include everything that that particular jvm is running at the time, including the "libraries" like swing, and other java.* stuff.
It really is pretty ugly trying to apply *gpl to java.....
-r
Roger Fujii wrote:
It *appears* like a process to the user in the ui (ps has separate PIDs). The problem is that words like "process" and "linking" really require some context around them and it's hard to codify that in a document.
Yes.
Perhaps it would be clearer if I said 'address space' instead of 'process'. (IBM is working on a new threading library that will make you happy, I think; it makes use of the "thread group" feature in the 2.4 kernel.)
Don't think it would change all the much. Think what 'address space' means in a NUMA model. 2 threads running in the same address space MAY be running on separate processors with a copy of the address space..
An interesting thought. I'd better sleep on that before commenting.
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?
Yes. A call that crosses an address space boundary by using a remote procedure call protocol is considered remote, and is neither static nor dynamic linking.
So, a windows DLL under windows is neither static nor dynamically linked since the DLLs live in a funky state that is in the 'kernel' process space and not with the app (at least, this is what I remember).
Most windows DLLs are pure userspace and execute in-process, so that's dynamic linking. But a windows DLL that implements an operating system service is explicitly ok to link to, even for (non-L)GPL apps. How that OS linkage is done is moot, as long as it's not static, I think.
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.
Replace 'file' with 'class' for java. That takes care of it, I think.
uh, nope. As java source files can compile into MANY .class files (inner classes).
That's ok, I think. The .class files are all related only by dynamic linking.
I don't think we need to define application. If we did, 'hunks of executable code in the same address space/process', or a collection thereof, might do.
but this would include everything that that particular jvm is running at the time, including the "libraries" like swing, and other java.* stuff.
It really is pretty ugly trying to apply *gpl to java.....
I believe that every interface provided by the Java spec and implemented by the JDK is a platform/os interface, and thus GPL and LGPL apps are specifically allowed to link to it by the GPL/LPGL os linkage exception.
- Dan
-
Dan Kegel -
Patrik Stridvall -
Roger Fujii