Installshield 6 (inter-proc) patches

[David Elliott]

On 2001.12.15 20:01 Alexandre Julliard wrote:
> David Elliott <dfe at tgwbd.org> writes:
> 
> > The crypto part of ADVAPI32 was the example I used.  Let's say I were
> > to write a CryptoAPI implementation as a set of seperate source files.
> > With the LGPL I could compile all of that stuff and refer to it as a
> > library.  What is a library? I would say one or more object files
> > linked together form a library.  I could then take my CryptoAPI
> > library, link it with the rest of Wine's ADVAPI32 and distribute a
> > libadvapi32.so that could be dropped into a wine install.
> 
> If it is a completely separate library that doesn't contain portions
> that are derivative work of ADVAPI32, then yes you can do that. But
> you cannot for instance decide to reimplement CreateWindow and not
> release it simply by putting it into a separate file, which was what
> Patrik suggested; because your new CreateWindow will necessarily use
> internal functions and variables of USER32, and thus would be
> considered a derivative work.
> 

Yes, I now realize in the mail I just sent out a few seconds ago that 
Patrick seemed to misunderstand me a little bit.  You seem to be thinking 
more like I am.

While I am thinking about this, there are some interesting things in the 
LGPL.  One of these is that you can modify the LGPL library to work with 
your code.  The catch is that you have to release source to the 
modifications and that the modifications must not require that your 
proprietary component be included.  The text of the license mentions that 
if you modify a function that computes square roots to hook into your 
proprietary components that the function must still compute square roots.  
But in Wine's case, many functions don't do what they are supposed to do, 
or they do what they are supposed to do but that's not what actually needs 
to be done.  This stuck out like a sore thumb to me, but maybe it's not 
such a big deal.

Apparently my cryptoapi example was very clean cut.  From my point of view 
it would only make sense that people would be allowed to make a 
proprietary section of a DLL as long as it was a seperate libary as 
specified by the LGPL.  Your example is a bit more of a gray area.  While 
I would hope that it couldn't be done, I am not seeing any language in the 
license preventing one from doing it.  If CreateWindow were implemented 
from scratch as a proprietray "library" and called into functions provided 
by the LGPL library (Whether internal or not I would think) the LGPL would 
allow this.  Accessing data I would think would also be allowed, again, 
whether internal or not I don't think makes a difference.

Basically what we need to know is how much protection is offered by the 
LGPL and is it worth it.  And by how much protection I mean after all the 
various interpretations of the LGPL have been brought out in court what 
can people get away with and what is clearly and most definitely going to 
be protected.

-Dave