Installshield 6 (inter-proc) patches

[Patrik Stridvall]

> 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.
> 
> I think what Patrick has been trying to get at is that that 
> is not very 
> clean-cut and that in fact there is little to no precedent on 
> what exactly 
> a derived work is.  If Alexandre is indeed correct then we 
> are pretty well 
> protected.  If it is at the opposite extreme and anyone could 
> statically 
> link in proprietary versions of functions then we have very little 
> protection and it really makes it not worth it to go LGPL. At 
> least that 
> is what I think Patrick has been trying to say.

Yes, approximately.

> Let me put it to you the way I see it.  Whether a function or data 
> structure is exported or not does not matter.  It would be trivial to 
> declare an internal structure or function as exported and thus the 
> proprietary function is simply making use of the library and 
> therefore not 
> a derived work.  

Indeed...

> That is my argument that avoids all of 
> Patrick's doctrine 
> of derived work crap and gets right down to the fact that 
> it's trivially 
> easy to make your work fall under the work that uses the 
> library category, 
> so long as it is a seperate object file. That is, to put it 
> in Slashdot 
> terms, a "Big Gaping Hole(tm)"

..but you are wrong that just because it falls under use,
it is clear from the doctrine of derived work. That is
the main problem, I have with it. That it might potentially
turn somekind of uses into derivation and thus potential
infringement of copyright.
 
> Look at section 5 in the LGPL.  If you use (from the header 
> files) only 
> numerical parameters, data structure layouts and accessors, and small 
> macro and inline functions then regardless of whether it would be 
> considered a derived work it remains a work that uses the library.
> 
> So that's great, after I had pretty much convinced myself 
> that the LGPL 
> was still good despite some minor problems, I now find myself 
> realizing 
> that the LGPL has major holes written into it!

Welcome to the club. :-)
 
> And so I emphasize my original statement now.  The only thing 
> the LGPL 
> really prevents is the direct use of the source code.  Anyone 
> wanting to 
> release a proprietary implementation of any function can do so fairly 
> easily simply by 1) writing that particular function from 
> scratch, and 2) 
> keeping it in a seperate object file.

Agreed.

> > > Try reading section 2C of the LGPL and tell me how it's good for
> > commercial
> > > companies.
> > 
> To respond to Roger: I fail to see how 2c makes any 
> difference.  It only 
> applies to derived works and only means that you have to release the 
> code.  

Yes, it only applies to derived works, but since it is pretty unclear
what a derived work is makes it quite unclear for commercial commpanies
what that are legal forced to release or not that can't possibly be good
when they are deciding whether to use Wine.