Installshield 6 (inter-proc) patches

[Patrik Stridvall]

>     It would help us in several ways.  First, since we've 
> always effectively
> treated the Wine code base as though it were LGPL, we would gain
> the protection that the LGPL offers.  If someone else takes 
> the code we've
> worked on, and competes with us, we would gain back
> any improvements that they make.  For example, if Wine had been LGPL,
> then Transgaming would have been oblidged to release 
> Installshield fixes 
> back
> (after all, they do follow on work that we did).  

Not according to the David Elliot and I agree.

Even according to a strict interpretation of the LGPL
they would just have to provide their code in seperate
files so everything could be relinked when new versions
of Wine was released.

> With better 
> InstallShield
> support, for example, our CrossOver customers might  have a 
> wider range 
> of plugins
> that would successfully install.  This is a pretty minor problem; I 
> can't think of a
> significant plugin affected by this. 

:-)

Of course you claim that. Even if it was a problem you probably
wouldn't admit it since it might raise to price in any possible
negotions with Transgaming.

:-)

> Further, I think I 
> understand why 
> Gav has
> has hesitated on this issue, and I firmly believe that Transgamings 
> intentions
> with regards to the Wine project are honorable and good.

As said above the only thing it would enforce would be file
seperation so you more easily could integrate the part from
Transgaming in your CrossOver product.

Of course distributing it after that would violate Transgamings
copyright, so you really need their permission after all.

The point is LGPL wouldn't help you here.

>    However, I can imagine alternate scenarios where we could 
> have all of 
> our hard work
> used against us by others who are more ruthless than Gav, and so the
> LGPL would at least offer us some protection from that threat.

Does it? It seems you overestime any advantages of LGPL.
 
>     A second benefit is simplicity. I spend a lot of time discussing 
> license
> issues with my customers, and fighting very difficult battles to
> preserve the integrity of the Wine code base (and while that sounds
> noble and all bear in mind that a single, coherent source 
> code base that 
> I can fully
> use is a key part of my business strategy).  So, if the 
> license were LGPL,
> my negotiating requirements would be simplified.  In fact, I 
> would feel 
> free to
> encourage my clients (and my company) to ruthlessly take 
> advantage of every
> possible opportunity to create competitive advantages, because I feel
> that the LGPL would protect the integrity of Wine.

The same question here:
Are you sure you are not overestimating the protection LGPL provides?
 
>    Of course, there are a number of downsides.  First of all, it is 
> possible that
> I would have fewer clients; the LGPL is complex license,
> and it's core premise can deter many people.

That is one of my objections as well.

> It is widely 
> believed in the
> Wine community that Corel would have never touched Wine if it had
> been LGPL, and Corel's contributions to Wine were very significant
> (the irony of course, is that AFAIK, Corel treated Wine as though
> it were LGPL).

Side note: I am one of them.
 
>     Second of all, the LGPL does, oddly enough, take away some freedom
> on my part.  Today, I have a full range of choices available 
> to me with
> every product I release or help a client to build.  After a 
> switch to LGPL
> (and after enough time had passed for the LGPL'd pieces to be
> significant), I'd have to be very cirumspect every time a 
> public release
> of a product was made to be certain that I had all of my licensing
> ducks in a row.

Exactly, it increases your cost of doing business.
  
>     For example, right now, we don't provide a copy of the
> source code contained within our CrossOver Plugin Wine tree.  The only
> changes we have not published back into the main WineHQ tree are
> ones specifically required to interoperate with a 
> Linux/Netscape plugin.
> The changes we made to Wine would never have been accepted by
> Alexandre as being good or generally useful patches, and yet 
> they could
> conceivably give someone who wished to replicate our proprietary
> Linux plugin code a good insight into how to go about doing 
> so.  To be 
> honest,
> we sweat a lot of blood and tears to learn how to do that 
> right, and it 
> would
> hurt if someone were able quickly knock off CrossOver Plugin 
> because we were
> forced to show that code.

To be honest and actually say something in support of LGPL:
This wouldn't be required even with a strict LGPL interpretation.

You would have to provide object files for relinking but that
would not be much worse than providing the binary. Reverse
enginerring it will be almost as hard.

> On the other hand, we also had a 
> heck of a lot
> of work on the Plugin code that has nothing to do with Wine, and I'd
> like to see someone knock that off quickly <grin>.

:-)
 
>    With all that, speaking on behalf of CodeWeavers, I would neither 
> call for
> nor oppose a switch to the LGPL.  Since that change would 
> impact me and my
> customers somewhat slowly, I think I could make the necessary 
> adjustments in time.  

Perhaps the clarifications above might make you change your mind?

> The most important thing is for us to continue to have a vital and 
> thriving Wine community.

Agreed.
 
>     Finally, speaking strictly on a personal basis, and with 
> no corporate
> considerations whatsoever, I would welcome a change to the LGPL;
> I have always preferred it to BSD style licenses (and to the GPL,
> for that matter); with LGPL projects, I feel more certain that I know 
> exactly
> where I stand and how my code will be used.

Well, perhaps it is because you misunderstood what the LGPL means?