On 2001.12.18 23:43 Dimitrie O. Paun wrote:
On Tue, 18 Dec 2001, Roger Fujii wrote:
"Dimitrie O. Paun" wrote:
Technicalities aside, the LGPL spirit seems to be accepted by most
people.
I have no problems with the 'spirit' of the GPL (or at least, how most (ie, minus rms) people sees it).
Excellent. In fact, I disagree with RMS violently, I've read the link you sent me (about the glibc takeover) a long time ago. But this is why we have to separate out intentions from fact. Or semantics from syntax. Or whatever you want to call it. In other words, we can use the LGPL even if we disagree violently with RMS. Just like Linus chose the GPL for Linux, even if he can't even talk to RMS.
We've heard no end of discussion of what represents the code, and so on, but in reality (please Patrik :)), Wine is a _well_defined_
piece
of software.
The problem is that it is *not* a 'well_defined' piece. Is it a
library?
An app? You run it as an app, but the executable you're running it
with
thinks it's a library. Or is msword (or whatever you're running) now
a
library. I can see rational arguments either way.
That's a separte problem. Is your claim that we can't use the LGPL because we can't define what Wine is??? If this is _your_ problem, I truely belive that can be solved. And the solution is fairly simple: whatever code uses a DLL's internal functions (that is, functions that are not exported in the DLL's spec files), is said to link directly with Wine and thus is subject to the LGPL licence. In fact, Wine is the simplest project to LGPL because its boundaries are defined by someone else! Moreover, these boundaries are fairly well documented and accepted by most of the software industry.
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)"
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!
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.
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. It's not like it says you must provide media at no cost. Hell, this is one of the main points of having a (L)GPL license.
Again, let's not look at the details of the LGPL. Let's stick to the spirit for now. It's difficult as it is to discuss about these things, if we start now to worry about every small detail, we will not get anywere anytime soon.
Why? Has anyone fundamentally disagreed with the spirit of the LGPL? I thought it was a given that everybody likes the idea, but that it's not necessarilly going to work as advertised.
If LGPL is so clean, simple and nice, why does
mozilla/openoffice/apache/perl
not use it?
If the LGPL is so scary, how come the glibc uses it, and how come that does not scare people for using Linux in a comercial setting???
This is a bit different. As Alexandre has stated, if you are using Wine to port a Windows app to UNIX then the switch to LGPL really doesn't make any difference assuming Wine works.
The difficulty comes when Wine needs to be modified in order to accomplish the port, or if you are running a business selling improved versions of Wine (e.g. TransGaming).
For example, CodeWeavers (from what I understand) makes their money through contracts with parties who wish to have their Win32 software run on UNIX. They are getting paid to do the port. Sometimes (or I would think more likely most of the time) Wine needs to be improved in order to do the port. CodeWeavers then releases those improvements to the Wine project thus improving it.
Now, look at TransGaming. Their business model seems to generate revenue essentially selling an improved version of Wine (See Gav's mail for more detailed information). Possibly switching to LGPL /HAS/ scared the shit out of them and after reading Gav's mail I definitely see why.
For another example, look at Corel. Now Gav has stated that Corel would not have touched Wine if it had been LGPL or GPL. Something about they needed to be able to use their code for Wine and also for their Win32 API on Mac thing. I fail to see why this would have made a difference. If it was Corel's code then they sure as hell have the right to use it in both places. However maybe they also borrowed some Wine code for the Win32->Mac thing which under X11 is perfectly acceptable. I personally have no interest in that and really I think any code they may have borrowed was probably much less than what they contributed to Wine and therefore overall was a win for Wine. If they didn't borrow any Wine code but merely used their own code for both programs then had wine been LGPL that should have been perfectly acceptable, of course if they did borrow some code and wine had been LGPL then we'd be seeing a front page story on Slashdot on how crappy a company Corel is for using LGPL code in a proprietary product.
Anyway, getting back on track. Corel's aim was to port their applications to Linux and the easiest way to do that was to use something like Wine. Pretty much follow the Codeweavers model above where LGPL should be fine with the possible exception of borrowing some code for other purposes.
Now, I claim that the LGPL is _way_better_ for the commercial
interests in the long term,
I keep hearing this, but don't see any reasoning behind it.
I will cover the commercial stuff in a separate email, this one's getting long as it is.
Hmm, I seem to have covered that. Depends on your business model.
Saying 'someday' is not good enough. Without a bound, it's meaningless. What if M$ says: we will eventually open source Windows.
Will
that make you happy? But more importantly, does it _mean_ anything.
I'm
afraid it does not (and that can actually be proven logically:)).
er, huh?
If you don't put a bound on time, but simply say 'eventually', it can be proven that it doesn't mean anything, because it is as if you did not say anything in the first place. It does not give any additional information.
Right, exactly.. I will eventually clean my computer room pretty much means hell will freeze over before that happens. I haven't set a bound on it and therefore I might as well have said nothing at all about cleaning my room.
Although with that strict of an interpretation of a word, maybe you should have been a lawyer.
-Dave