Should Wine move to LGPL 3?
stefandoesinger at gmx.at
Fri Jul 13 15:55:38 CDT 2007
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:
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
So it may be unlikely, but TiVolization of Wine can happen. But are the above
two scenarios against our interests?
More information about the wine-devel