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