Wine license change: it's about time!

[Gavriel State]

While I do want to contribute further to this debate, I need some time
to gather my thoughts.  In the meantime though, I want to address Dimitrie's
quote - and fundamental misunderstanding - of me below.

"Dimitrie O. Paun" wrote:
> A BSD license is a STRONG DETERANT for a business to contribute code
> back. The reason for this is that they have no guarantee that another
> business will not improve a little the code, and thus get a competitive
> advantage. Or that other companies will not use that code on top of the
> code they wrote but not released, and thus again, get that edge. This is a
> fantastic _deterant_ for releasing code back. In fact, Gav validated
> exactly this point when he tried to argue for the BSD license last time:
> 
>   <talking about the DCOM work>
>   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.
> 
> In other words, they needed that code. They invested some money do get
> it. They are happy with the results. Why not release the code? They have
> what they needed in the first place? The reason is clear -- it cost them
> to get there, they can not aford to bring everybody there for free. I can
> 100% understand that. But if the code was under the LGPL, it would not
> matter, because even if they brought everybody there, other companies
> could not step ahead of them, since if they did, they themselves could
> have used that code.
> 
> In other words, TG could have kept Direct3D proprietary, released
> everything else back under LGPL, and they could have _known_ they still
> have the competitive edge in the D3D work! This is why the LGPL is in fact
> an _incentive_ for such colaboration.

Quite the opposite: It is not 'competitive advantage' that concerns us, 
or others using our code without contributing their own code.  It is 
simply that we could not and cannot afford to do our development without
monetary compensation.  If the OLE DLLs had been LGPLed, we could not
have been able to afford to do any DCOM work, since we would have had 
no prospect of getting paid for it.  

Under the LGPL, the only possible business model is this:
  a) Find someone who might need some piece of code
  b) Sell them on: "We can do this for you, and release it under
     the LGPL for $x dollars. We're really good at what we do,
     honest"
  c) Do the work, and hope to actually get paid.

The current license, by contrast, allows many other alternate models that
are worth trying.  In the case of the DCOM code, there was something 
that we had a need for with our current subscriber base, but we could 
not afford to do the work just for that base, since it is not yet 
large enough.  Instead, we have this business model:
  a) Do the work up front, proving that it works, covering a small
     portion of the cost from our current subscribers.  
  b) Talk to potential sponsors who need the work
  c) If they agree on a price, release the code under the Wine 
     license.

The TransGaming subscription model is simply this writ large, trying to 
get the individual users to act collectively as sponsors of the work.  

The LGPL simply slams the door shut on that whole model, saying in effect 
"It's my way or the highway".  

At the same time, I believe that I understand the main concern of the 
LGPL proponents: the current license allows the possibility of benefiting 
from the project without any contribution.  Where I differ from them is 
that someone else's code is not enough to keep my employees eating.  
What I need as a contribution is not code, but cash.

Anyhow, I'm going to go and put my thinking cap on, and try to see if 
I can think of some arrangement that might work better for everyone.  

 -Gav

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com