To give a concrete technical example (but not an authoritative legal one, as IANAL), it is my understanding of the LGPL that if someone has released a library under the LGPL, a third party cannot distribute a modified version of this library that has been linked against a proprietary library[1]. I think because of the reduced scope of the LGPL, there's also less room for ambiguity on questions of aggregation vs. derived works.
[snip]
[1] The reason for this lies in section 2d of the LGPL:
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.A library that is linked against a proprietary library cannot be used without the proprietary library; it will fail to load at runtime with a complaint of "No such file or directory".
If that was the only problem:
BOOL (*PROPRIETARY_Foo)(void) = NULL;
void call_this_init_on_dll_load(void) { HANDLE h = LoadLibrary("PROPRIETARY.DLL");
PROPRIETARY_Foo = (void *) GetProcAddress(h, "Foo"); }
BOOL WINAPI Foo(void) { if(PROPRIETARY_Foo) { return PROPRIETARY_Foo(); } else { /* The old implementation goes here */ } }
So no runtime failure any more. At least not anymore than happend before.
If "application program" as used above is understood to include other libraries (the distinction is artificial, and the LGPL 2.1 does not define "application program" to exclude this interpretation), then trying to hide proprietary functions in a separate library that an LGPLed library is made to depend on is not permitted under the LGPL.
Well, the the requirement if the function didn't exist was "the facility still operates, and performs whatever part of its purpose remains meaningful."
Observe the words "remains meaningful". It doesn't have to do the same thing as Alexandre claimed in the last discussion. Yes, I can see why he thought that since the example below paragraf d (not included in your cut) was missleading.
It should just do something that in the context of the missing function remains meaningful. It could mean using the old Wine implementation but I guess it could also mean that just doing:
SetLastError(ERROR_NOT_IMPLEMENTED); return FALSE;
since doing that is ALWAYS meaningful for a Windows API. Sure the application might not check but then this is the responsebillity of application not our problem.
Beside since the Wine likely didn't have a non-stub implementation anyway, it was probably was what it already did, so the application crashed anyway without the patch and the proprietary library.
On Wed, Feb 13, 2002 at 10:29:03AM +0100, Patrik Stridvall wrote:
To give a concrete technical example (but not an authoritative legal one, as IANAL), it is my understanding of the LGPL that if someone has released a library under the LGPL, a third party cannot distribute a modified version of this library that has been linked against a proprietary library[1]. I think because of the reduced scope of the LGPL, there's also less room for ambiguity on questions of aggregation vs. derived works.
[snip]
[1] The reason for this lies in section 2d of the LGPL:
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
A library that is linked against a proprietary library cannot be used without the proprietary library; it will fail to load at runtime with a complaint of "No such file or directory".
If that was the only problem:
BOOL (*PROPRIETARY_Foo)(void) = NULL;
void call_this_init_on_dll_load(void) { HANDLE h = LoadLibrary("PROPRIETARY.DLL");
PROPRIETARY_Foo = (void *) GetProcAddress(h, "Foo"); }
BOOL WINAPI Foo(void) { if(PROPRIETARY_Foo) { return PROPRIETARY_Foo(); } else { /* The old implementation goes here */ } }
So no runtime failure any more. At least not anymore than happend before.
Correct, and I believe doing what you describe above is compatible with the LGPL. It certainly seems to be compatible with the intent of the LGPL. Note that the LGPL does not aim to prevent people from being able to write proprietary code; it only aims to prevent people from placing proprietary restrictions on the code already written by authors choosing the LGPL.
Well, the the requirement if the function didn't exist was "the facility still operates, and performs whatever part of its purpose remains meaningful."
Observe the words "remains meaningful". It doesn't have to do the same thing as Alexandre claimed in the last discussion. Yes, I can see why he thought that since the example below paragraf d (not included in your cut) was missleading.
It should just do something that in the context of the missing function remains meaningful. It could mean using the old Wine implementation but I guess it could also mean that just doing:
SetLastError(ERROR_NOT_IMPLEMENTED); return FALSE;
If the function has already been partially-implemented in the Wine code, I think replacing that implementation with ERROR_NOT_IMPLEMENTED does, at least, attempt to undermine the spirit of the LGPL. Calling abort() is also /meaningful/, for varying definitions of meaningful, but in my humble non-lawyerly opinion, modifying an LGPLed library such that a mostly-working function has been replaced by a choice between a proprietary implementation and an exception would seem to be contrary to the requirements of the LGPL.
Beside since the Wine likely didn't have a non-stub implementation anyway, it was probably was what it already did, so the application crashed anyway without the patch and the proprietary library.
In that case, I can't see any reason the LGPL would forbid what you describe.
Steve Langasek postmodern programmer
On 2002.02.13 12:44 Steve Langasek wrote:
On Wed, Feb 13, 2002 at 10:29:03AM +0100, Patrik Stridvall wrote:
[BIG SNIP]
Beside since the Wine likely didn't have a non-stub implementation anyway, it was probably was what it already did, so the application crashed anyway without the patch and the proprietary library.
In that case, I can't see any reason the LGPL would forbid what you describe.
Yes, and this is what Patrick and I have been arguing (together, not against each other) about.
We both believe that the LGPL would still allow independent functions of a DLL to be implemented by a non-LGPL library linked to the code. Patrick, IIRC, states that because of this the LGPL offers almost no protection, and because it brings with it several other issues that overall it is bad for Wine.
Personally I feel that even though it is very, very minor protection that there's a good chance that it's just enough to be worth it. However, I'm really not interested in debating the LGPL.. I'm more interested in seeing what peoples thoughts are on my "Wine Foundation" and Gav's "WineCorp" ideas (the same thing, different name). To me this seems like a more ideal solution than a change of license to LGPL.
-Dave
-
David Elliott -
Patrik Stridvall -
Steve Langasek