Any idea when Oves interprocess patches will be put into the main Wine CVS tree?
The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support.
Regards, | Any significantly advanced technology is indistinguishable from | a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]
"J.Brown (Ender/Amigo)" ender@enderboi.com writes:
Any idea when Oves interprocess patches will be put into the main Wine CVS tree?
The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support.
It could certainly be applied, even if it's not 100% clean it will always be better than not supporting InstallShield at all, as long as it doesn't break other things. However I cannot apply anything that hasn't been submitted to me under the Wine license, so for more information you'll have to ask Transgaming.
There are several factors to that equation, and I'm afraid we don't have a firm ETA yet.
Sorry, -Gav
"J.Brown (Ender/Amigo)" wrote:
Any idea when Oves interprocess patches will be put into the main Wine CVS tree?
The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support.
Regards, | Any significantly advanced technology is indistinguishable from | a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]
Gavriel State gav@transgaming.com writes:
There are several factors to that equation, and I'm afraid we don't have a firm ETA yet.
Well, this worries me. It sounds like you are planning to do the same thing you did with your DirectX stuff: by making the code available on your site, and promising to release it at some hypothetical future date, you remove all incentive for other people to spend time improving the main Wine, thus ensuring that it always lacks some features. I don't like this at all.
If you can't/don't want to release your code, I'd strongly suggest that you reconsider your strategy of making it publicly available. If it was only available to paying customers, there would at least be a reason for other people to work on a free implementation. But if everybody who needs some feature in Wine can simply download WineX instead, no one will spend time re-implementing that feature. This is beginning to seriously hurt the project, and we need to find a way to address this issue.
Alexandre Julliard wrote:
Gavriel State gav@transgaming.com writes:
There are several factors to that equation, and I'm afraid we don't have a firm ETA yet.
Well, this worries me. It sounds like you are planning to do the same thing you did with your DirectX stuff: by making the code available on your site, and promising to release it at some hypothetical future date, you remove all incentive for other people to spend time improving the main Wine, thus ensuring that it always lacks some features. I don't like this at all.
If you can't/don't want to release your code, I'd strongly suggest that you reconsider your strategy of making it publicly available. If it was only available to paying customers, there would at least be a reason for other people to work on a free implementation. But if everybody who needs some feature in Wine can simply download WineX instead, no one will spend time re-implementing that feature. This is beginning to seriously hurt the project, and we need to find a way to address this issue.
The DCOM issues had been ignored by other Wine developers for YEARS before we came along. It's not at all clear that our work there has discouraged anyone else from working in that area. To say that our work is preventing anyone from doing a free version of DCOM is completely incorrect. To the contrary: we have already contributed substantial amounts of this code to the public tree - thousands of lines, in fact. That can only help anyone with a sudden and unexpected interest in recreating our work.
Now, it is our firm desire to see *all* of that code end up in the main version of Wine. The fact is, unfortunately, that we simply cannot afford to give everything away as soon as we write it. We only got a minimal implementation of the DCOM code working six weeks ago. We are not a rich company, with millions in VC funding to burn; this means that our DCOM work has to remain under the AFPL until we can find a sponsor willing to defray some of the tens of thousands of dollars it cost us to develop it.
Furthermore, we are committed to writing quality, robust code. We don't think it's in anyone's best interest for the current version of the code, which is effectively limited to the requirements of InstallShield, to be used as the basis of future DCOM related work. We in the midsts of working on a much more flexible architecture which will permit more than just typelib based proxying.
I don't really think this affects individual users at all. They can simply download and use the code from our website, or apply the necessary patch to WineHQ wine. They can even redistribute it all non-commercially should they wish.
Without a doubt, we are committed to the Wine project and have already contributed a great deal of code to support it. However, to maintain the quality and integrity of the project, we stand by our decision of only contributing code when it makes sense to do so (in order to allow us to continue developing quality code) and when it reaches a certain minimal degree of quality.
Publicly questioning our ethics is certainly not the right solution nor is it in the spirit of the project, especially given how much we have supported it to-date. We believe that we ARE doing the Wine user and developer community a service and propelling it further. The only people that our lack of haste in contributing code back really affects are organizations that want to make immediate commercial use of the code. These organizations include the one you work for, and its clients. If you want to see the DCOM code Wine-licensed soon, you need to talk to your boss and your clients, not me.
At this point, I think it would be best if we were to take this discussion off-line so that we can determine a solution that works for everyone.
Take care, -Gav
Hi Everyone,
Discussion on this topic seems to have somewhat bypassed what I believe are some key points:
1) Wine *needs* corporate developers.
Without the funding, code, and profile that the various corporate developers have brought to the table, the project could not be where it is today. Without continued support from companies able to afford to fund development, the future prospects of being able to keep up with Microsoft's API changes is very bleak indeed.
2) The current Wine license played a very significant role in the involvement of some of the past and current corporate players.
I can state categorically that if the Wine license had been GPL or LGPL, Corel would not have invested the millions of dollars it did into Wine development - I was the one who made that decision. There were three choices: Wine; Go it alone, based on the work we had done on the Mac; and Willows TWIN, which was LGPLed.
At the time, TWIN was much better suited for source-level porting. The reason we went with Wine was almost entirely because of the license. We knew that we would be able to take code we had developed for Wine and use it in our Mac work and elsewhere.
If the Wine license had been LGPL, TransGaming would most likely not have been started. The LGPL would not have given us the flexibility to explore the subscription/voting business model that we're using.
3) Our work has not affected other DirectX work in Wine.
Except for Direct3D, all our DirectX work goes back to Wine. We have already contributed our major DirectDraw restructuring work, and many other pieces. There is ongoing work by non-TransGaming developers on non-3D DirectX related areas in Wine, including both the x11drv and dib code.
The only thing that we are keeping back here is the D3D code. The only other developer who has ever worked on D3D in Wine is Lionel Ulmer, and the last time he did significant work on D3D was in early 1999 - on much earlier DirectX APIs. Experience with 3D development is rare. There are very few developers who have the required skill-set, and fewer still willing to volunteer their time on Open Source projects. If there is anyone out there who has the experience necessary to do D3D work, please let me know: I want to hire you.
We do have a bit of merge work pending for non-3D components, which we hope to get to soon. The delays there have nothing to do with licensing issues though - they're more about development process and CVS policy.
4) We would not have been able to afford to do the DCOM work under the LGPL.
The DCOM problems with InstallShield had been kicked around for a very long time before we finally stepped up to the plate to do something about it. We poked around a bit to try to see if there was anyone willing to do the work on the Wine side of things, sponsored by us, but didn't have much luck.
In the end, we decided to go ahead with it in the hope that along the way we could find someone to sponsor *us*. If we had known how much work was going to be required, I'm not sure that we would have done it at all.
It took months of effort for us to get DCOM working with InstallShield, and cost us tens of thousands of dollars. We're a very small company, and much of that money came directly out of my personal pocket. I haven't had an income for over 18 months, and I have an 8 month old daughter to support.
The several months worth of effort we put into DCOM also had a huge opportunity cost: that was all time that we could have spent on improving Direct3D instead, which is, in the long run, where our primary business is.
If I had thought that there would be no possibility of finding a sponsor for the work because we would have been forced by the LGPL to make the code available immediately, we would very simply have ignored the issue entirely and just continued to wait for someone else to do it while we worked on DirectX. Given the complexity of the DCOM/InstallShield issues and the amount of effort required, I believe that we would have had to wait a very long time.
The fact is, I would *love* to release the code now. I don't want us to shoulder the burden of maintaining it - that's not where we should be spending our efforts.
But there are companies out there who will benefit significantly from commercial use of this code, and who can afford to sponsor a portion of the development cost. Until such a sponsorship happens, we cannot apply the WineHQ license to that code.
Note though that we *have* contributed substantially to all kinds of related code, including typelibs, rpc, safearrays, etc. I feel that the work we have contributed so far is fair reciprocation for the work that other commercial Wine developers have brought to the table.
5) Using the LGPL may limit the abilities of those who need to work on code that cannot legally have source revealed.
One of the other non-DirectX things that we have spent significant amount of effort on is copy protection. We have extended Wine to support both SafeDisc and SecuRom protected programs. For the moment, our work on this code is not even in our AFPLed tree. Until we have a chance to make a legal determination on whether or not releasing the source code would violate the US DCMA, we have little choice but to keep it secret.
If Wine was LGPLed, we might not have the option to distribute this code at all, which would thus severly limit the utility of our entire endeavour. It's not hard to imagine other commercial efforts where similar issues might occur.
6) Additional limited AFPL-style licensing of portions of Wine could be a *good* thing for the project, not a bad thing.
The more developers there are getting paid to develop Wine code, the better. Volunteer developers alone will not be sufficient to move the project along quickly enough.
An AFPL style license that restricts only commercial redistribution of code, but permits all other use and redistribution is an excellent way of making the code available to Wine users while still allowing developers to be paid for their efforts by forcing entities that want to make commercial use of the code to contribute something in return. Ideally, things would be structured such that code would be sponsored by a commercial entity to be relicensed under the Wine license.
I would *love* to see more of the volunteer developers working full-time on Wine, supported through such a sponsorship system.
Really, that is the ultimate goal of our subscription system. With a sufficient number of users contributing to our system, we want to begin spreading some of the funding around to developers willing to work on the features our users have voted for. In fact, we're basically ready to do this right now. Anyone who wants to look at this list:
http://www.transgaming.com/pollslist.php?old=1
and who chooses to work on one of the poll items is welcome to send me a proposal for sponsoring their work. They can make their code available under the AFPL while we determine if it fits the need, and if we like it and agree to the price, we will be happy to pay to make it available under the Wine license.
I firmly believe that this kind of arrangement is going to play a key role in financing the development of all kinds of Open Source projects in the future. I could be mistaken, but at the least, I think that it is important to run the experiment and see.
-Gav
Gavriels State gav@transgaming.com writes:
We do have a bit of merge work pending for non-3D components, which we hope to get to soon. The delays there have nothing to do with licensing issues though - they're more about development process and CVS policy.
It may be a good idea for you to give some more details about that; it would probably help clear up some misunderstandings.
I understand very well that you don't have time to spend on merging, but you don't have to: all you have to do is slap the Wine license on your code, and I'm sure someone else will be happy to do the merging for you. The fact that you don't do this gives the impression that you don't want to make the code available, even if that's not your real intention.
Alexandre Julliard wrote:
We do have a bit of merge work pending for non-3D components, which we hope to get to soon. The delays there have nothing to do with licensing issues though - they're more about development process and CVS policy.
It may be a good idea for you to give some more details about that; it would probably help clear up some misunderstandings.
Sure: We have a separate CVS tree that we use for our releases, which we're now doing roughly monthly. We try to ensure that we have a period of relative stability in tree before releasing. Merging from WineHQ into our tree is very destabilizing for us, especially given some of the rearchitecture work that has taken place recently. For example, moving window-list-walking into the server gave us a 20% or higher performance loss in many games due to the increase in server-call overhead; one of the fixes in our pending queue deals with this problem.
Because of this, we tend to try to minimize the inward merges we do (our last was over 2 months ago). This, in turn, makes outward merges more difficult for us.
In addition to the above, another problem we face with merging is that the D3D code has tendrils in the core DirectDraw code which makes seperating the two for licensing purposes challenging.
On the flip side of things, you are more strict about the code that goes into WineHQ CVS than we are on our side. We have a number of changes on our side that provide useful functionality, but are not clean enough or proven enough to go into WineHQ. IE: the patch that we recently submitted for [Read/Write]ProcessMemory. It works for the problem we were experiencing (a copy-protection related thing: the various protection systems tend to use WriteProcessMemory all over the place), but you raised some concerns about other cases and wanted to see some of the trace data which we have not had the time to put together.
Some of the other things that we have in our tree that fall into a similar catagory are: - GDB Remote debugging - Gerard Patels' deferred tracing patch - Auto-detection & adding of CD-ROM devices - The heap management fix discussed in October
Note that I'm not saying you're wrong to not include these in WineHQ CVS. There are certainly many benefits to keeping the tree under strict control, as you have, but the difference in policy has a tangible effect on the ease of our merge process.
I think that the strictness may also have other effects on the speed with which the project progresses. Certainly reviewing wine-patches and doing the CVS commits and testing must take up a large portion of your own time on the project.
I understand very well that you don't have time to spend on merging, but you don't have to: all you have to do is slap the Wine license on your code, and I'm sure someone else will be happy to do the merging for you. The fact that you don't do this gives the impression that you don't want to make the code available, even if that's not your real intention.
Well, as I mentioned above, a certain amount of work on our part is required to properly separate 2D code from 3D code. Once we've had a chance to do that, I would be happy to accept help with our next outward merge. I spent a bit of time this evening preparing a diff of our code against our previous inward merge, and doing a rough first cut of code that can go to WineHQ (about 10k line of diff). If there's a real interest in helping us merge this in, I'd be happy to fix it up a bit more and post it to the mailing list under the Wine license.
-Gav
On Sun, 9 Dec 2001, J.Brown (Ender/Amigo) wrote:
Any idea when Oves interprocess patches will be put into the main Wine CVS tree?
The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support.
Well, not all of it is ugly, but some crucial bits are. Here is the biggest reason I never considered that patch eligible for inclusion into official Wine without a cleanup:
dlls/ole32/ole32.spec: @ cdecl COM_ConnectProxy(ptr ptr) COM_ConnectProxy
An internal procedure exported from ole32, to be used by oleaut32... YUCK
Another big issue is CoMarshalInterThreadInterfaceInStream, which simply can't do the right thing with the way I structured things, and I believe that is why repainting doesn't work while installing. The correct functionality requires proxying between COM apartments, without any class activation being involved, which calls for a completely different communication structure than what those hacks use.
I'm still working on the restructure that is supposed to fix these issues. So it is my preference that the current InstallShield patches *not* be applied to WineHQ, but my new upcoming code be used instead. It should be ready within a couple of weeks.
As to the political issues discussed on this thread, I'm not supposed to give any kind of official comment, but I suppose I could tell you my personal view on the situation.
I'd personally love to submit all my code directly to WineHQ under the X11 license, without hesitation, even though it did take me a long time to get that code working. However, it was Gav who gave me money I could pay my bills with during the long hours I spent working on it, so I feel obliged to help him recoup that investment in any way he can. Whatever strategy he'll use to do so, is up to him. But in my opinion, my code (the rewritten code, that is, not the old code currently in WineX) is eventually destined for WineHQ, the only negotiable issues for me are when, how, and who pays for it.
As for the license of Wine, I was among the ones opposing the LGPL last time it was discussed, and I have not changed my mind. I feel that Wine is most widely useful if it keeps the X11 license, and usefulness is more important in my mind than making it 50% harder for companies to "steal" the code. If X11 is so bad for large projects such as Wine, why is the largest project of all, XFree86 (and associated projects like DRI), still using it, even though its maintainer would have the power to switch to e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)?
I think Alexandre is not quite correct in his projection that making Wine code available under a semi-open-source license unconditionally inhibits work on the free version of Wine. I think that there's a completely *different* reason that people do not work on the free version, which is the prevention of duplicate work, in order to preserve precious development resources. The code in WineX will eventually go back to Wine, hence there's no reason to duplicate development. If people thought WineX code would never go back to Wine, I'm sure they would continue working on the free Wine. I know I would. But when the code *will* go back to Wine, having people getting paid for doing it fulltime is better than wasting precious volunteer time on duplicating that kind of work for a much slower progress... I think Wine will do well by keeping the X11 license, and I'm not speaking for my employer.
I've periodically tried to merge most of the stuff we do in WineX (other than Direct3D) back into Wine, both to make the free version as usable as possible, and make it so that people *can* work on the free version of e.g. DirectX without fear of duplicating our work (and I think Marcus and Lionel wanted to add Xv support to the free version of ddraw/x11drv HAL, they're completely free to do so now without too many conflicts, I reckon they just haven't had the time yet). However, I only do such merges when I consider the official Wine to be in a relatively stable state, which it hasn't been recently due to Alexandre's rewrites of this and that, so I haven't had the opportunity to merge everything I wanted to merge back yet...
Well, I think that's pretty much what I wanted to say. But I only speak for myself; for official TransGaming position statements, look for postings by Gav...
Ove Kaaven ovehk@ping.uio.no writes:
As for the license of Wine, I was among the ones opposing the LGPL last time it was discussed, and I have not changed my mind. I feel that Wine is most widely useful if it keeps the X11 license, and usefulness is more important in my mind than making it 50% harder for companies to "steal" the code. If X11 is so bad for large projects such as Wine, why is the largest project of all, XFree86 (and associated projects like DRI), still using it, even though its maintainer would have the power to switch to e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)?
A thing to keep in mind is that X11 got almost killed by licensing issues and the proliferation of closed source vendor versions. If the XFree86 team hadn't picked it up, there probably wouldn't be a free version of X11 available today. This is something that could happen to Wine; and if it does happen, will we find enough people to do what XFree86 has been doing for X11? Maybe, and maybe not. When I hear people like Patrik saying that it's OK for parts of Wine to become proprietary because we can't do everything anyway, I'm worried.
-
Alexandre Julliard -
Gavriel State -
Gavriels State
-
J.Brown (Ender/Amigo) -
Ove Kaaven