Installshield 6 (inter-proc) patches. LGPL hole.
ps at leissner.se
Wed Dec 19 11:36:17 CST 2001
[David Elliott explaination snipped]
> Thanks for explaining what Patrik has been going on about.
Yes, it was quite a good explaination.
> 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
> to himself -- which would also deprive the user of the ability to fix
> bugs in the proprietary reimplementation of that particular
> WineLib function.
... while this is an entirely possible scenario there is little
profit in doing what you suggest so while it is one of the holes
in LGPL it is not really a problem in pratice I think.
No, the problem as far as Wine is concerned, is that somebody might
do proprietary extension of some important part of Winelib that
enough people want so much that most people uses the proprietary
extension and under such circumstances there won't be any incentive
for people to work on Wine.
However, I neither believe this to be true, nor do I believe that
the LGPL will help to stop it other than very marginally.
More information about the wine-devel