Licensing response and an idea - wine-devel

12 Feb 2002


      Hi everyone,
As I mentioned, I have been considering the license issue for the last
several days.  It is a matter very near to my heart, as I believe that 
it affects not only TransGaming, but really the entire software industry.
This posting is somewhat lengthy, but please bear with me.
Open Source software has made enormous strides in the last several 
years, and incredible amounts of great code have been produced.  At the
same time, it has been unable to compete effectively with proprietary 
software vendors like Microsoft, except in those areas where sufficient
well financed companies have been able to direct full-time developer 
resources to the problem.
With the wellspring of dot com VC funding going dry, the question arises:
where will the money come from to pay full-time Open Source developers?
Just imagine where Wine would be without the code contributed by the 
half-dozen or so companies that have been involved.  Imagine where Linux
would be without the efforts of the companies paying for dozens of full-time
Kernel hackers.
And imagine where we could be if just one or two percent of Microsoft's 
annual $25 Billion in revenue were being directed at Open Source projects.
The business models capable of supporting traditional Open Source projects
are really rather limited: consulting services, technical support, and selling 
ancilary products with the software.  None of these come close to delivering 
the levels of revenue that traditional mass-market shrinkwrap software can.
So far, it is unclear whether they can support much profit at all for their 
proponents: RedHat, VA, and others bear witness to that.
TransGaming, for one, is working with some new ideas on how to do things
differently, and profitably.  There are a number of interesting possible
approaches out there, and it is important to the entire world that we 
find models that work.  Otherwise we are going to be stuck with the kind
of information police states envisioned by the RIAAs, MPAAs, and Microsoft's
of this world.
Now we are all here because we think that there are better ways to do 
software than the wholly proprietary approach.  We want to be able to 
look at the code, tear it apart, fix the bugs, and make it cooler.  And 
we want others to have the freedom to do the same.
Ultimately, the questions that need answering are these:
 o What freedoms are important to the community?
 o Can those freedoms be achieved without sacrificing other goals?
 o What is the best mechanism for ensuring those freedoms, and
   ensuring the continued development of the code?
The Wine X11-style license essentially allows the code to be used
anywhere, in any way.  Users don't need to pay, Developers can take bits 
and pieces as they deem appropriate, and corporations can sell the product 
in whatever way they feel like.  But it also has no legal mechanism to 
try to coerce further development of the project.
Current proponents of an LGPL license switch believe that a legal mechanism 
is important to protect the project.
Frankly, I am at a loss to understand the reasoning behind such a switch.  
I don't see any way in which any company could maintain their own fully 
proprietary fork of Wine without doing periodic merges into the public 
project.  It's hard enough for TransGaming to do it despite the fact that 
we deal mostly in very specific areas.  And even if someone was able to 
do so, how does it affect the Wine project any more than the existence of 
Windows or MainWin does?  At most, it would affect the userbase, but in 
the current model that doesn't matter, since that userbase doesn't 
contribute significantly to the project.  Only the developers contribute, 
and it is not at all clear to me that they would stop.
Marcus Meissner has already shown that the existance of our AFPLed DCOM 
code didn't stop him from going ahead and doing it himself.  On the 
contrary - it helped him, since he got hints from our design. It's a shame 
that he had to, since we've been working hard to find a way to contribute 
that code back, and now we may have no way to recoup our investment.  We 
still have a 2nd pass, more complete DCOM implementation under development, 
so it is possible that we be able to get a sponsor for that.  But regardless, 
it clearly shows that having code outside the WineHQ tree is no impediment to 
the community reimplementing it if necessary.
The LGPL would severely limit a number of possible commercial applications 
of Wine, such as:
o Companies or groups that might want to take a small bit of Wine 
    code here and there without taking the whole thing.  IE: Corel's 
    Mac porting work, or projects like MicroWindows or Odin (similar
    projects like Xine and ReactOS use parts of Wine this way, though 
    they're GPLed, and thus would not be affected).
o Porting Wine to platforms with NDAed APIs.  Or commercially oriented
    ports to other platforms which might not be viable under the LGPL.
o The work that TransGaming has done to support copy protection. 
    Releasing that code all at once - as would be required under the 
    LGPL - might violate the DCMA, since it reveals something of how 
    the copy protection systems work.
o New business models like TransGaming's, with conditional-future-
    release of code.
While I am open to considering license changes that have the potential to 
benefit the project, I am very very concerned about the LGPL.  Going that 
route is a one-way street with no turning back.
I've been thinking about these problems for a long time.  As much as for
any other reason, I started TransGaming with the desire to try to find good
long-term solutions to the problem of how to fund Open Source development
through the people who are actually using the code.
I have the germ of an idea that might be useful to address some of the 
concerns that the LGPL-license-change camp has had, while at the same
time leaving the doors open for a much wider variety of different commercial
activities.  I have been trying to flesh it out while at the same time 
working to some very tight deadlines, and I have not had time to really 
think through some of the the possibilities that it entails.  I am posting 
it to the list now anyway so that it's out there for people to think about.
Here's the quick and dirty version:
 o A new non-profit company is created: WineCorp
 o Developers contribute their work to WineCorp - possibly assigning
   copyright, or at least giving WineCorp the rights to do with the
   code whatever it pleases.
 o WineCorp distributes the code under an AFPL-like license - no 
   commercial redistribution allowed.
 o WineCorp has a set of standing licenses allowing for commercial 
   redistribution.  A company can redistribute commercially if it
   does one of the following things:
     - Releases source modifications to WineCorp immediately.
     - Releases source modifications within a preset timeframe 
       (maybe one year).
     - Releases source modifications with some appropriate prearranged 
       condition (ie: the TransGaming subscriber limit).
     - Pays WineCorp a pre-set royalty, which WineCorp can then 
       use to sponsor other Wine development
 o For cases that don't fall into the above conditions, the WineCorp
   board of directors can vote to allow some other licensing arrangements.
   This helps prevent the kind of one-way ticket we have with the LGPL.
 o WineCorp could also serve as a way for the userbase to direct funding
   and attention to different parts of Wine.  To my mind, this is one of
   the biggest problem Open Source projects have.  The end users get everything, 
   but many don't contribute: no code, no money, no bug reports, nothing.  The 
   more they can be encouraged to contribute, the better off everyone is.  
   WineCorp could solicit donations from users who can't contribute otherwise
   and possibly institute a subscription/voting system similar to TransGaming's.
One hard question the above idea creates is how does money gets split
fairly amongst different developers working on particular parts of the 
code?  I am sure that there are other problems as well.  That said, I 
think that the importance of new models like this go far beyond the Wine
project.  Ideally, I hope that methods like these can be profitable enough
to make proprietary software companies begin to consider opening up their
code in a similar fashion.
Just imagine the day that Microsoft makes their first contribution to Wine,
openly and without coersion by the government, because they recognize that
doing so is in their own best interests.
Food for though, anyway.
-Gav
-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav@transgaming.com