Re: Problem with InstallShield (Was Re: [Bug 629] Changed - Problem with InstallShield: ole:CoTreatAsClass(stub), ole:CoGetClassObject)

Ove Kaaven <[email protected]>
Newsgroups gmane.comp.emulators.wine.license
Message-ID <[email protected]>
On 6 May 2002, Alexandre Julliard wrote:

> [discussion moved to wine-license]
> 
> Ove Kaaven <[email protected]> writes:
> 
> > Agreed. If people would stop holding code back using the LGPL, the
> > symbiosis we'd have in any case would have a friendlier feel to it.
> 
> That certainly would be nice, and it is how it worked some years
> ago. But the past year has clearly shown that the "symbiosis" with
> Transgaming (and not only them) only goes in one direction.

Well, the LGPL switch was too early to prove that for TransGaming. During
the many months of work on the much-delayed WineX 2.0, the development
tree was "frozen" during that time, so all WineHQ syncs (cvs import) were
postponed (maybe unnecessarily) for a long time. A sync was scheduled
after the release, and after merging the current state of Wine, the merged
WineX would be diffed against Wine, and a lot of work would then be
submitted to Wine. But since the LGPL switch was done before WineX 2.0 and
the unfreeze of WineX that allowed this sync, this did not happen. A sync
was done with ReWind instead, and of course, no code was released to Wine,
as now suddenly everything the TransGaming developers did for Wine had now
become valuable material to give CodeWeavers incentives to release some of
their code. It's unfortunate that it took so long, and thus that no code
flowed back to Wine during that time, but having delays is far from having
a one-way relationship.

> That by itself would not be a problem if it didn't actively harm Wine
> by discouraging development in some areas.

That must have been areas where TransGaming did plan to submit code back,
because Marcus wasn't discouraged from the COM work. But is it
inconceivale that other areas of Wine actually did benefit from having
unpaid developers focusing on other, more important, areas than the area
of trying to duplicate TransGaming's DirectX work?

> > But
> > the idea here is that, given the restrictions we now have in the LGPL, the
> > "blackmail" symbiosis we'll be entering now, will result in the most code
> > available for everyone; CodeWeavers and Wine will benefit from code
> > blackmailed out of TransGaming, and TransGaming and WineX will benefit
> > from code blackmailed out of CodeWeavers, and ReWind will benefit from
> > both. And ReWind is what's important to me personally.
> 
> I don't think blackmail will maximize the amount of code available. On
> the contrary, I think it will encourage everybody to hold their code
> back until they can get something in exchange, and break the
> collaborative nature of the project. Paradoxically it will probably
> hurt Rewind too, by causing people that would be willing to use the
> X11 license to stick to LGPL instead in the hope of getting some code
> out of someone else.

I know. We're already aware of it, and have taken it into consideration.
It's no worse than having everything LGPL-ed (which would essentially be
the case if DLL separation remains LGPL-ed).

> I think it's going to be bad for everybody in the long run, and I'm
> not going to participate in such a scheme.

Oh, fine with me. You just have to make Wine X11 again to avoid it
happening around you. Heck, I'd happily give you all transgaming's non-D3D
code (including the COM stuff), if you did, and Gav would probably go
along with that. We'd be relieved to not have to hold our code back, as we
really think that it's the wrong thing to do, but right now, we have to.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.