Wine license change

[Patrik Stridvall]

> 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.