TransGaming LGPL clarifications

Dimitrie O. Paun dimi at cs.toronto.edu
Mon Feb 18 16:39:56 CST 2002


On Mon, 18 Feb 2002, Gavriel State wrote:

> Keep in mind that there is a distinction between our current business
> model, and the business we may do in the future.  

BUt this is not a reasonable discussion assumption. Let's concentrate on
one issue at a time. I understand you are trying to secure an escape
route, but let's try to contain the debate.

> There are several things we're doing that we haven't talked about
> publicly yet.

... and thus I can not be aware of.

> My LGPL concerns are:
> 
>  1) We support copy protected CDs in our WineX binary releases.  This support

This is a valid issue, and I am sure that the Wine community would more
than happy to provide hooks for you for exactly this purpose. There's no
other option in this case, so I don't think it' even an issue.
 
>  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.  

Most likely the x11drv code so that useful wihtout your DirectX work, so
you could contribute it back.

>     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.

We are very close to full DLL separation. And due to the BSD-style licence
that the current Wine has, the LGPL will not start to monifest itself for
some time. Until than, we should have it. Besides, it's an incentive to
finish it up faster, so that should please Alexandre. :)

>  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. 

Sorry, but I don't see that. Your main asset is the DirectX work, and you
could have kept it proprietary, and the street-performer-protocol model
would have worked just as well. I don't see the problem.

>  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. 

I don't believe it's a valid concern, because:
  1. it's not your business model. In fact, it's not a viable business
model period;
  2. from the Wine POW, we shouldn't care, as I don't see that code
comming back to Wine.

>  4) Most importantly, the LGPL is a one way road.  

But that's one of it's features, you know... :) It's what gives people
piece of mind, and what I feel creates the level playing field. Just PD,
and BSD are manyway roads. That is, this is not a valid point. If you want
to argue that, we're stuck with BSD, period.

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

Hey, I'm not trying to hurt TG. I think you guys did good work.  But in
choosing a license we have to balance many rights: those of the users, of
the developers, of the companies involved, and last but certainly not the
least, of Wine itself.

> That said, I believe that my WineCorp suggestions address both my concerns as well 
> as the issues raised by the LGPL camp.  

I personally despise the idea, On practical, and phylosophical grounds.
And if we go that route, I don't think I'll follow.

--
Dimi.





More information about the wine-devel mailing list