Installshield 6 (inter-proc) patches

[David Elliott]

On 2001.12.19 12:32 Alexandre Julliard wrote:
> David Elliott <dfe at tgwbd.org> writes:
> 
> > Now, here's another something to mull over.  We've pretty much
> > established that you could statically link something proprietary with
> > something LGPL.  One question I have is how much of the library are
> > you allowed to use.  Alexandre mentioned that while the CryptoAPI
> > example would be a pretty clean-cut allowed case, a proprietary
> > CreateWindow would not be allowed.  His argument was that because it
> > would necessarily use internal functions and data structures that it
> > would be a derived work and thus subject to the license.
> 
> Actually the fact that they are internal or not doesn't make a
> difference, I wasn't clear on that point. If your code is linked to
> the library it is considered a derivative work, and by default the
> whole has to be released under the LGPL. Now there are cases where you
> don't need to do that: one is if your app is considered a work that
> uses the library (section 6), the other is if you are placing your
> code side-by-side with the library (section 7).
> 
> So if you don't want your code to fall under the LGPL, you have two
> choices: one is to put it in some part of your app that only links to
> the library, but in that case you cannot have other parts of the
> library depend on your code (this is the square root example). This
> would work for the crypto API, probably not for CreateWindow since the
> rest of user32 needs CreateWindow.
> 
Okay, that makes a bit more sense.  Although couldn't one argue that it 
still does work since it could fall back to the original LGPL createwindow?

> The other solution is to put your code side-by-side in the library;
> but this is only possible if your code is not covered by the license,
> which means it isn't a derivative work of the library, which in turns
> means it cannot use any functions or data (exported or not) of the
> library. This would work for the crypto API as long as you don't use
> anything from the rest of libadvapi32.
> 
Right.

-Dave