From what I understand, if you download the WineX source tree, you get code under LGPL, code under X11 and code under APL (which is basicly a licence chosen to make sure that others cant just grab those bits and use them)
Does anyone know which bits are under APL? I know the directx bits are but what else is TransGaming holding back?
tir, 30.09.2003 kl. 02.24 skrev Jonathan Wilson:
From what I understand, if you download the WineX source tree, you get code under LGPL, code under X11 and code under APL (which is basicly a licence chosen to make sure that others cant just grab those bits and use them)
Does anyone know which bits are under APL? I know the directx bits are but what else is TransGaming holding back?
The list is here: http://www.transgaming.com/license.php?source=1
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.
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.
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.
OTOH, there may be valid reasons for TransGaming not to licence things like OLE/COM improvements back as X11 or LPGL.
On Tue, 2003-09-30 at 08:39, Jonathan Wilson wrote:
OTOH, there may be valid reasons for TransGaming not to licence things like OLE/COM improvements back as X11 or LPGL.
In fact the OLE/DCOM work Ove did has been licensed back to ReWind under the X11 license, and I have a partial merge sitting on my hard disk. It worked well enough for the app I ported while at QinetiQ which did some rather advanced things with COM, but is not of merge quality yet.
Doing a proper merge though is really not that easy, in particular Ove and Marcus have duplicated quite a bit of work, and figuring out the correct "seams" to merge along is tricky.
At some point I need to make it build again, and send in a big patch like Ove did for me, so that if somebody else feels like doing a better job they can do.
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.
On September 30, 2003 09:16 am, Ove Kaaven wrote:
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.
Your argument is valid right now because there was not attempt to abstract the copy protection through some kind of interface. We've had this discussion before, and Alexandre was willing to accommodate such hooks, but the argument was put forward that this is not possible. I simply do not believe you can't abstract it, anything can be. One reason why you may not want to is that you may be afraid that if people see the interface, they will figure out how to write their own copy-protection code. But this is a business, rather then a technical or legal reason...
So yeah, you may be giving something up, but you get to use a lot more Wine code. This may not be so important to you right now, but it does look like the way to go (long term, at least). It would make it way simpler for TG, it will clarify a messy situation (with so many diverging licenses), and it will bring the community closer together. I think it would be so nice to be able to say: WineX is Wine + our proprietary Direct X work + copy-protection. Even if people figure out the copy-protection, I'm sure you will not lose a single customer, you provide enough value through your Direct X work.
tir, 30.09.2003 kl. 17.16 skrev Dimitrie O. Paun:
On September 30, 2003 09:16 am, Ove Kaaven wrote:
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.
Your argument is valid right now because there was not attempt to abstract the copy protection through some kind of interface. We've had this discussion before, and Alexandre was willing to accommodate such hooks, but the argument was put forward that this is not possible. I simply do not believe you can't abstract it, anything can be. One reason why you may not want to is that you may be afraid that if people see the interface, they will figure out how to write their own copy-protection code. But this is a business, rather then a technical or legal reason...
Well, there is a legal reason, Gav is afraid of the DMCA. There is also a licensing agreement with Macrovision that could be jeopardized by doing anything that made their copy protection scheme easier to "crack" (or whatever they're afraid of).
And it's "impossible" because the patch we're talking about does not actually implement copy protection. It only makes Wine implement certain Windows quirks. For Wine not to implement these quirks in certain APIs may be considered bugs, and how do you abstract away bugfixes?
Anyway, if you're really insistent, perhaps you can get Gav to let you sign a NDA and see the code for yourself, then come up with a way to abstract it, but you'd have to talk to him about it.
It's not certain it would do much good for the paranoid game companies that currently contract us for Mac ports though.
On September 30, 2003 11:51 am, Ove Kaaven wrote:
And it's "impossible" because the patch we're talking about does not actually implement copy protection. It only makes Wine implement certain Windows quirks. For Wine not to implement these quirks in certain APIs may be considered bugs, and how do you abstract away bugfixes?
Well, these should just be contributed back... :) That would be in the spirit of cooperation we're trying to promote.
Anyway, if you're really insistent, perhaps you can get Gav to let you sign a NDA and see the code for yourself, then come up with a way to abstract it, but you'd have to talk to him about it.
I'd be interesting, but I don't think I want to sign any NDA. You guys know the problem a lot better than I do, it seems to be there's simply lack of political will. I mean, some of the stuff you guys doing may be hard to abstract, but I doubt that we can't "free" most of the DLLs of such copy protection hacks. In other words, you're saying this stuff touches a lot of DLLs ATM, so those can't be shared with Wine. Maybe the 20/80 rule applies here as well, in the sense that with 20% of the work, 80% of these DLLs can be freed.
My guess is that Transgaming has signed an NDA with one or more of the companies that write copy protection schemes for games (eg. Safedisk), and is not even able to discuss what is required to make such hooks in Wine, or how to change the build procedure to make it possible for the scheme to work.
Mike
Your argument is valid right now because there was not attempt to abstract the copy protection through some kind of interface. We've had this discussion before, and Alexandre was willing to accommodate such hooks, but the argument was put forward that this is not possible. I simply do not believe you can't abstract it, anything can be. One reason why you may not want to is that you may be afraid that if people see the interface, they will figure out how to write their own copy-protection code. But this is a business, rather then a technical or legal reason...
-
Dimitrie O. Paun -
Jonathan Wilson -
Mike Hearn -
Mike McCormack -
Ove Kaaven