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

Ove Kaaven <[email protected]> writes:

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

I think it's pretty clear that it was already considered valuable
material that wasn't going to be released anyway (as Gav made clear
for the COM stuff), long before the LGPL switch. I don't buy the
argument that Transgaming would suddenly want to release everything
but are prevented by the license switch. And as I said before, you
don't need to do a merge to release code, people will happily merge it
for you.

Obviously before the license switch Codeweavers and others weren't
forced to release anything at all, so this would have made your code
even more valuable as bargaining material. The truth is that you have
put yourselves in a position where helping Wine is bad for your
business, and _that_ is the real problem. The license has very little
to do with it.

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

Of course it's not a complete loss. But it's clear that gaming support
is very important for Wine: a couple of years ago there was a lot of
activity in this area, tons of patches being submitted, websites
devoted to the issue, etc.  All of that is dead today, and that's a
major loss. It definitely isn't compensated by the fact that
developers can do something else while waiting for Transgaming to
maybe someday release something.

And yes, the problem is precisely that you are promising to give the
code back someday, and the uncertainty caused by this. It would be
better for Wine if Transgaming simply said "this is proprietary, you
can't have it"; then people could go on with the business of improving
Wine without being discouraged by the perspective that their work will
be thrown away when/if Transgaming release theirs.

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

You have to only because you choose to play that blackmail game, which
is also the only reason you can't use the LGPL. You don't have to do
it that way: if Transgaming really wanted to help Wine and do the
right thing, you could release everything today and adopt the LGPL
tree like the other companies are doing. It would be better for
everybody involved, _including_ Transgaming, as you will hopefully
realize sooner or later (and don't give me the copy protection excuse;
we can work around that if there's a willingness on your part to have
a real collaboration).

-- 
Alexandre Julliard
[email protected]