Question about WineX licences

Ove Kaaven ovehk at ping.uio.no
Tue Sep 30 08:16:46 CDT 2003


tir, 30.09.2003 kl. 09.39 skrev Jonathan Wilson:
> > Everything that's LGPL should be listed on the above page. Additionally,
> > code in ReWind is X11. Anything else in WineX may be assumed AFPL, but
> > may also be released as X11 at TransGaming's discretion. I think most
> > non-DirectX code (and even a limited subset of the DirectX code) could
> > be released as X11 on request, although that's up to Gav.
> To me it makes sense for TransGaming to give back everything except DirectX 
> since the focus of WineX is gaming and its the DirectX code and the copy 
> protection support that is the bits that are making transgaming the money.

Perhaps. That is also what would happen if Wine was still under the X11
license, but the world isn't that simple. Now the LGPL-ness of Wine
actually makes it an advantage to hold code back from Wine in some
circumstances, whether you and I like it or not. For the core WineX for
Linux product, this is because

1) things like the copy protection support patches have to be kept
secret, therefore any code it touches can't be LGPL

2) the copy protection support affects a lot of the code - it even
affects the way WineX DLLs are built - therefore it's an advantage to
have as many DLLs as possible non-LGPL to allow those DLLs to be
copy-protection-compatible

3) therefore, it's an advantage to use as little LGPL code as possible,
and keep the number of LGPL-ed DLLs to the minimum

4) therefore, since Wine is LGPL, any Wine progress usually can't be
shared by WineX, but Wine progress does make Wine a competitor, and
therefore it is a disadvantage for TransGaming to help Wine progress

So the fact that TransGaming still does it sometimes should be taken as
good will, not as "too little", "they don't get it, that's not how OSS
works", or "they're sinister and evil".

TransGaming also does Mac ports on contract from game companies, and
there the issues may be a little less obvious, but there are certain
extra issues with the LGPL there, too. Perhaps issues CodeWeavers tried
to avoid by LGPL-ing Wine, but for game companies, saying something to
the effect of "no we can't add your non-free copy/hacking-protection and
code encryption layer because Wine is LGPL" would probably mean no
contract in 100% of the cases. This is not the exact issue, but I don't
think I can discuss the specifics.

> One advantage is that then TransGaming could move more of the "support 
> dlls" (things like ole32, oleaut32 & so on) up to the latest WINE LGPL code 
> (since they would no longer have any custom modifications to those dlls) 
> and both base WINE and WineX would get better as a consequence.

That's not exactly how LGPL works. The LGPL requires not only the source
and changes to it to be available, it also pretty much requires this
source to be able to be compiled by the user as a drop-in replacement,
basically. This is not possible if the build system is secret, as is the
case with the copy protection support applied. Again, this explanation
is admittedly vague, but I can't discuss the specifics.

> OTOH, there may be valid reasons for TransGaming not to licence things like 
> OLE/COM improvements back as X11 or LPGL.

The OLE/COM improvements have already all been licensed to Wine (they're
also under the X11), they just haven't been merged in. Mike Hearn was on
it last I heard, since I've turned out not to have the time to adapt it
for Wine.




More information about the wine-devel mailing list