Installshield 6 (inter-proc) patches. LGPL hole.

[Dan Kegel]

David Elliott wrote:
> Dimitrie, this is exactly what Patrick and I have been trying to argue
> against.  If you read the LGPL it does state that you can statically link
> as long as you provide the means for your users to statically link with a
> newer version.  One way to do this would be to provide the object files
> from the compiler, or a .a file with all of the combined objects that can
> be relinked with a newer version of Wine.
> 
> The example we have been using is that you could write a proprietary
> CryptoAPI and link it with the rest of the advapi32 to come up with a
> libadvapi32.so which includes CryptoAPI.  You can call all the functions
> in the rest of advapi32 (i.e. the LGPL part) that you want to.  So long as
> you provide a way to update the LGPL components you are in the clear.
> This is covered by section 7 which states that you may place library
> functions that are a work based on the library (i.e. the original LGPL
> ADVAPI32) ... in a single library together with other library facilities
> not covered by this license.  The single library would be the libadvapi32
> including the proprietary cryptoapi.  In order to do this you must a)
> provide a copy of the work based on the library not linked with the
> non-LGPL stuff. and b) give prominent notice as usual.
> 
> 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.
> 
> 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.  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)"...
> 
> 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.

Thanks for explaining what Patrik has been going on about. 
In summary:

Consider a proprietary application which ships as a proprietary library 
which is statically linked with LGPL libraries at install time in a way 
that lets users supply new versions of the LGPL libraries.  This lets them
fix bugs in the LGPL'd code and thus in the proprietary app.
The harm you see is that a vendor could, once he found a Winelib function
with a bug, simply do his own clean-room implementation of that function,
and use it instead of the Winelib version of it, and keep the improvement
to himself -- which would also deprive the user of the ability to fix
bugs in the proprietary reimplementation of that particular WineLib function.

Did I get it right?  
- Dan