Wine license change

[Marcus Brubaker]

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 at utoronto.ca