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.