Installshield 6 (inter-proc) patches

[Patrik Stridvall]

> On Tue, 18 Dec 2001, Patrik Stridvall wrote:
> 
> > You forget that some "independent"(*) parts like the Crypto API are
> > parts of other DLL:s (like ADVAPI32.DLL) for no particular reason.
> 
> This is ridiculous: it is one of the few exceptions, it is 
> simply silly to
> bring the Crypto API into this discussion. If this the Crypto 
> API is the
> only problem, we can fix it in multiple ways.

It is not the only problem it is just a symptom of the gaping hole in LGPL.
  
> > > At this point, I would like to know if people agree up to 
> > > this point. 
> > 
> > I don't.
> 
> That's informative. WHAT don't you agree with? In fact, if we 
> can agree on
> WHAT we disagree, I think it would be a great step forward.

"I don't" primarily refered to the previous argument 
concerning "independent"(*) parts. 
  
> > >   0. Isn't Wine's best interest to evolve and develop as fast 
> > > as it can?
> > 
> > Yes.
> 
> This is a fundamental point. A project like Wine is just like 
> a living,
> breathing creature. And being need to be selfish to survive. Not too
> selfish, but it is essential that they have a certain level of
> selfishness.

Your analogy is flawed, Wine is not living in the meaning that
it, if it is to unselfish can die. The mechinisms are entirely
different compared to normal life.

> In Wine's case, that has to be: 'the licence 
> should be such
> that it would maximize Wine's development'.

Yes, but I don't believe that LGPL does, that I have being trying
to explain in I forgot how many mails.

> > >   1. If so, isn't the LGPL _spirit_ in Wine's best interest?
> > 
> > No, not nessararily. See different mail.
> 
> 1 follows from 0. Period. You can not agree with 0 and 
> disagree with 1, no
> matter what you write in other emails! :) Again, THE SPIRIT 
> of LGPL, not
> the letter. Again, the spirit is: 'if you improve Wine in minor ways,
> please contribute back your improvements'.

Yes, and the key is minor ways and I believe that is a absolute non-issue
as I have explained before. There is no profit in holding minor
improvements.

> > >   2. If so, why shouldn't we formalize it in the license?
> > 
> > But it isn't nessarily so.
> 
> And why is that? Quite the contrary, because:
> 
> -- For people that contribute back, would chnage nothing
> -- For people that don't contribute their changes, it's no 
> good to us, so
> we don't care  (which follows by point 0).
> 
> Tertium non datur. That is, there's no other case. QED.

OK, since you bring mathematics in to it,
I will try to explain in mathematical terms:

"The set of people is not invariant over a license change."

In fact the set of people are likely to be considerly less.
While I have no strict mathematical proof of that,
I especially point to Gavriels' reply concerning 
Corel and Transgaming.