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

[Gavriel State]

Alexandre Julliard wrote:
 > I fail to see how the fact that the driver was written by a Rewind
 > supporter instead of a Wine supporter should make any difference from
 > Transgaming's point of view. And I personally don't see Wine as being

Indeed - it has nothing to do with anything.

The situation with the ALSA driver is this:
   - We offered Eric money to do the ALSA driver
   - Eric asked instead that we put the money towards something else
     to benefit Wine
   - That money (and other money) is going to go towards our sponsorship
     of a method to speed up the WineServer / Client interface, ie: via
     a kernel module if that make sense
   - I've been trying to find the time to write up a detailed proposal
     for said sponsorship, as well as proposals for trades of other code
     but my time has been limited lately.  We've done a fair bit of
     research on a Kenel module approach, but we need to put together
     more cohesive documentation on the results so far.

 > "against Transgaming", or Rewind as being "against Wine"; and if
 > that's how you see it I find that pretty sad. I also don't understand
 > how this method of holding code back and blackmailing other developers
 > can be considered a good thing either for Wine, or for Rewind, or for
 > Transgaming.

What we are proposing is not "blackmail" but *trade*.

Really, the economic problem in this licensing situation comes down to a
question of accounting (most economic problems do).  What value do you place
on a contribution to the project, whether it is your own or someone else's?

The LGPL license that Wine is currently using is effectively saying that
the value of your current contribution is equal to the expected value
of any future contributions.  IE: All contributions and contributors,
current and future are equivalent.  Certainly this simplifies the accounting,
but at a serious loss in accuracy.

As we've already stated, TransGaming can't operate within that framework,
for a wide variety of reasons.  Instead, we're going to be making the
value picture more specific.  We would like access to some code that's
currently licensed under the LGPL by copyright holders like yourself and
CodeWeavers.  In particular, we would like to see address space separation
work made available under the X11/ReWind license.  That would be a boon
for everyone, as it would allow easy interchangability between Wine and
ReWind (and WineX) DLLs.  There are a few other things that would be
nice as well.

In exchange, we have a number of things that we would be happy to contribute
to ReWind, and thus to the Wine tree.  These things include our new DIB engine
work, COM/DCOM work, selected portions of our work on copy protection, and a
number of other significant features.  We're also quite happy to work on any
DLLs that need additional seperation work.

What has to get figured out is simply this: exactly what do current Wine
copyright holders want to have for the things that we want from you?

I'd like to resolve this question soon, and establish some kind of ongoing
framework for how to manage this cooperation in the future.  I hope to
have a detailed proposal for the Wine LGPL-only contributors shortly.

Take care,
   -Gav

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