Should Wine move to LGPL 3?

[Stefan Dösinger]

Am Freitag, 13. Juli 2007 17:22 schrieb Kai Blin:
> What specifically are we waiting for? Until the GPLv3 is tested in court?
> Until someone TiVolizes Wine? Christmas?
Some possible TiVolization of wine I have brought up on #winehackers with 
third party signatures:

Hypothetial:
Assumed ddraw.dll was signed by Microsoft. Now we have an app that checks for 
this signature, and refuses to run otherwise. This app is not part of wine, 
and it is not LGPLed. Now some company lures Microsoft into signing a 
compiled ddraw.dll.so, and ships a wine build which makes that picky app 
happy. They provide the source. A user recompiles, and cannot use his own 
build because the non LGPL app, not shipped by that company refuses because 
of a missing signature.

Would the company shipping the signed DLL build be in violation of the LGPL 
v3? They do not own the key, and they do not have any influence on the third 
party app that refuses to run.

Where could this apply in practise:

-> If we ever implement Vista's protected audio or video DLLs we may need a 
signature on them.

-> Parallels is shipping Wine's D3D code for Windows. Windows Vista, 
especially the 64 bit edition, is pretty picky regarding unsigned drivers. 
Wine's code in Parallels is technically not in the position of a driver, but 
it is related.

PUMA or PVP(or however the DRM in Vista is called these days) will most likely 
never work on any platform whose fundamentals are open source, so scenario 1 
is most likely moot.

Scenario 2 doesn't have any technical restrictions, but Microsoft signing Wine 
code sounds like hell freezing over. But that was said about Novell-Like 
contracts too.

So it may be unlikely, but TiVolization of Wine can happen. But are the above 
two scenarios against our interests?