Wine license change

[Steve Langasek]

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