Brett Glass wrote:
At 08:47 PM 2/10/2002, Francois Gouget wrote:
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own.
That's why they won't release everything. But that's OK. They still have an incentive to release absolutely as much as they can without forfeiting their competitive edge.
I doubt they would release "absolutely as much as they can" because releasing *anything* can potentially forfeit a part of competitive advantage. I'm sure a CodeWeavers-like company that didn't have the ties to the community that CodeWeavers itself does, wouldn't hesitate to keep all of their code in house. (Lindows being a prime example.)
Let me explain that a bit. Having worked in a corporate programming environment for quite a while now I've had a chance to see how a lot of decisions get made. The absolute one thing that can kill a project is uncertainty. With a BSD type license you have a LOT of uncertainty. "If I release this code to [insert reason here], my competitors may take it to their advantage and give nothing back." They don't know. And, more often than not, a decision will be made favoring an option that has a lower level of uncertainty instead of a *potential* higher rate of return.
Think about it. You're a company like Lindows. You can:
a) keep all of your code in house. You can still merge in changes from the community (although it may take a bit of work) and there is no chance at all of potential competitors taking what you've done and using it against you. Or, you can, b) release parts of your code. Ok, so it helps the community, and helps you a bit in keeping things up to date and reducing duplication between you and the community. Of course, at the same time, someone can take those changes and do whatever they want with them, including compete against you, which could in the end, cost you a lot of money or even drive you out of buisness.
Basically, option (a) is the only case that you have a known quantity, for which you can plan the future. With (b) you can plan, hope and cross your fingers and all you get out of it is some extra code that you could have done in house anyway (albeit at a cost).
Switching Wine to the LGPL will not cause the fragmentation to disappear right away. But it puts in place a framework where each company can return its changes to the core Wine while being assured that the other companies will do the same.
And because the LGPL won't allow them to compete, they will either (a) use wrapper functions to circumvent the LGPL, or (b) leave the business altogether and stop contributing to WINE. In both cases, WINE loses.
Well, in case (a) WINE still wins (somewhat), because that means that someone could get part of their functionality and plug it in with other bits. It could take some work, but if, say, CodeWeavers and Transgaming both did this, you could concievably, make a patch that, if you paid for both, you could use both. Or perhaps even, Transgaming and CodeWeavers would get together and create such a patch because of user demand. I think that's a win, at least from the user perspective.
In (b), well, it doesn't matter. What would happen right now if Lindows droped off the map. All the work they did on WINE goes down the tubes, and no one benefits on either side. Great, Lindows made a quick buck off of WINE and contributed nothing in return. If WINE were (L)GPL, at least then the WINE project would have the fruits of their labours.
Just a few points.
Regards, Marcus Brubaker marcus.brubaker@utoronto.ca