Installshield 6 (inter-proc) patches

[Roger Fujii]

"Dimitrie O. Paun" wrote:

> Technicalities aside, the LGPL spirit seems to be accepted by most people.

I have no problems with the 'spirit' of the GPL (or at least, how most
(ie, minus rms) people sees it).

> We've heard no end of discussion of what represents the code, and
> so on, but in reality (please Patrik :)), Wine is a _well_defined_ piece
> of software.

The problem is that it is *not* a 'well_defined' piece.  Is it a library?
An app?  You run it as an app, but the executable you're running it with
thinks it's a library.   Or is msword (or whatever you're running) now a
library.  I can see rational arguments either way.  

> In fact, it's defined by Microsoft, and well accepted by the world at large.

I'm not sure I would use the word 'accepted' :)

> Before I go any further, I would like to stress a very important
> point: Wine is in fact a collection of independent projects. These are the
> DLLs, and they nicely (and unequivocally) partition Wine into lovely
> little, independent components. And this means that the LGPL is
> independently contained to each and every DLL. It is the _perfect_
> position to be LGPLed.
> 
> At this point, I would like to know if people agree up to this point.

Try reading section 2C of the LGPL and tell me how it's good for commercial
companies.
If LGPL is so clean, simple and nice, why does mozilla/openoffice/apache/perl
not use it?

> The discussion has been going all over the place, so I would like to keep this
> email short and to the point:
>   0. Isn't Wine's best interest to evolve and develop as fast as it can?
yes
>   1. If so, isn't the LGPL _spirit_ in Wine's best interest?
yes
>   2. If so, why shouldn't we formalize it in the license?

because LGPL (not the spirit) has a virulent provisions that everyone seems to
gloss over.  The funky notion of "derived work" is pretty scary.

> Now, I claim that the LGPL is _way_better_ for the commercial interests in the long term,

I keep hearing this, but don't see any reasoning behind it.  

With respect to commercial companies (or people in general):
    1) They will use it and not contribute
    2) They will use it and make contributions
    3) They will not use it.

LGPL addresses #1, but at the expense of increasing #3.  The problem is that the
people that it adds to #3, would usually go into #2 (because they are told by
legal/management NOT to use *GPL stuff).  And, I am presuming the bulk of people LGPL
subtracts from #1, would just go into #3.  So, how is this useful?

> > would be).  And given that IMHO, a lot of wine work to be done 
> > (looking at Direct* and other M$ stuff) falls under the unpleasant column
> > (ie, most people won't do this for fun), discouraging commercial work
> > doesn't seem to be the way to go.
> And how, pray you tell, is that beneficial in _any_way_ to Wine, if there
> is no guarantee of seeing that code? Why should Wine care? Why should we?

If you believe all are greedy bas*ards and will just steal the code, then
you shouldn't care.  If you think that people can make a 'good faith' judgment on
what's a bug fix and what is their stuff and will contribute the former, then
you should care.   Let's say company A implements DSOUND, and contributes X bug
fixes that fix acm stuff, but keeps its DSOUND implementation.  I would say
that you are STILL better off, as you got the acm fixes.  If company A would not
have done the work because it couldn't keep what it did, then you are NOT better
off by using LGPL.  
 
> Saying 'someday' is not good enough. Without a bound, it's
> meaningless. What if M$ says: we will eventually open source Windows. Will
> that make you happy? But more importantly, does it _mean_ anything. I'm
> afraid it does not (and that can actually be proven logically:)).

er, huh?

But I do agree that this beating a dead horse.  

-- 
Roger Fujii <rmf at lookhere.com>
Underemployed, and trying to keep it that way....