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.
On 2001.12.19 12:22 Patrik Stridvall wrote: [SNIP]
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.
Nah, see next section.
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. :-)
Seems to me that section 5 pretty much takes care of making sure that things which use the work are not considered derived works. So IMHO the LGPL is basically nullifying the doctrine of derived work.
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.
I now think I know why GNU does not want people to use the LGPL. It's basically a useless license for all but a certain specific type of project.
That specific type of project would be something like glibc. Where the interface is clearly defined and the implementation is good and needs to be free software.
Wine is actually very similar in concept to glibc. I remember a few mails back I suggested that the real goal is to make sure the base system is free software because no one can expect people not to write proprietary applications. And I don't think it would be good to not have proprietary applications (unlike RMS's views). However, I consider Wine to be part of the base system since it's really not an application, but basically does for Windows applications what glibc does for POSIX applications: provides a free version of the API.
So far the discussion as seemed to center around licensing Wine as a whole. Would maybe licensing certain specific DLLs be a better idea?
For example, would licensing the really core libraries as LGPL (i.e. kernel, user, gdi) be a good start? Make each library have its own LGPL license.
Or maybe should we keep all the libraries as X11 and make the emulator itself full out GPL?
Wine is many many peices. I think to try to place the same license over the entire project is absurd, except in the case of our current X11 license.
-Dave
-
David Elliott -
Patrik Stridvall