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.