TransGaming LGPL clarifications

Gavriel State gav at transgaming.com
Mon Feb 18 15:19:16 CST 2002


"Dimitrie O. Paun" wrote:
> 
> > AFAIK, Transgaming will have big problems with LGPL. It is Codeweavers that
> > will still be viable.
> 
> And why is that? In fact, Gav failed to even hint at why a LGPLed Wine
> would invalidate TG's current business model.

I had thought that I articulated our issues with the LGPL in my previous 
postings, but I'm happy to reiterate my concerns.  Keep in mind that there
is a distinction between our current business model, and the business we may
do in the future.  There are several things we're doing that we haven't talked
about publicly yet.

My LGPL concerns are:

 1) We support copy protected CDs in our WineX binary releases.  This support
    required changes at a fairly low level: the cdrom code, exception handling
    code, and the wineserver.  We cannot release this code (at least as it stands
    now) due to concerns over the DCMA, etc.  If the WineHQ core went LGPL, we
    would not be able to apply our copy-protection patches and release a binary-only
    package.

    More generally, this problem applies to anyone who wants to combine Wine code
    with any custom systems or interfaces that might be protected by NDA or other 
    such legal restriction.  

 2) While much of our DirectX work is confined to the core DirectX DLLs, some of 
    it also occurs in places like the X11drv - much of the code to deal with 
    specific hardware extensions (like NVidia's Vertex Array Range capabilities)
    is there.  Additionally, we still don't have complete DLL seperation, so it 
    is not at all clear that all our work could be neatly isolated into non-LGPLed
    DLLs.

 3) If the codebase had been LGPLed earlier we would not have been able to start
    TransGaming in the first place, since we would not be able to attract any end
    users to the street-performer-protocol model.  The incentive of helping us afford
    to make the code free is a very powerful one, and is central to our busines.  
    Why should end users contribute to us if we would just have to give the code away 
    anyway?   Furthermore, if we had had to LGPL our initial code, there would be 
    nothing stopping large gaming companies from making use of our work without 
    contributing to it's creation.  

    As I've said before, having another company's code is *not* good enough reward
    for us: we need cash in order to pay people.  Our developers can't eat electrons.

 3) The LGPL would have prevented us from doing any of the work on DCOM.  If we had 
    known that we would have no way to recoup our costs, we could not have afforded 
    to do the work.  With the LGPL, the only way that we could have recouped costs
    would have been to pre-sell the code before it worked.  IE: Only the consulting-shop
    model would be allowed.

 4) Most importantly, the LGPL is a one way road.  Once we start down that path, it
    will be next to impossible to go back.  If the LGPL would have prevented any of 
    the work that TransGaming has contributed up until now, who knows what other 
    companies or models it will prevent from forming in the future?

Additionally, I would like to remind people of the contributions that TransGaming has
made to the project so far:

 o Since TransGaming was started, we have contributed close to 2Mb worth of patches
   to the public tree; that's around 5% of all patches to Wine in that period.  Not
   bad, considering our size, I think.

 o We contributed a full restructuring of the DirectDraw code, nicely seperating
   it into the user and driver side, and making possible new innovations like the
   SDL driver that we posted earlier.  We added implementations for newer 2D 
   APIs that were previously unsupported.

 o We contributed a significant rewrite of the DirectSound code, adding in HEL 
   support, amongst other things.

 o We contributed a great deal of code to speed up DIBSections and related 2D
   functions.  We had been considering doing a product very similar to CodeWeavers'
   QuickTime crossover work, and tuned a fair bit of code to work better with 
   QuickTime.  CodeWeavers seems happy enough selling that code now.

 o As part our DCOM work, we did extensive bugfixing in the code for Typelibs, 
   safearray, RPC, etc.  That code was contributed back, and is used in other's
   commercial products.

If the main tree goes LGPL, or if there is a significant LGPLed fork, we are going 
to need to seriously rethink how (or if) we make any further contributions.

That said, I believe that my WineCorp suggestions address both my concerns as well 
as the issues raised by the LGPL camp.  The WineCorp model would effectively be like 
the LGPL, but with additional options for different commercial opportunities. Most
importantly, it would have the flexibility to address any future business models 
that have not yet been considered.  

 -Gav

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




More information about the wine-devel mailing list