"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).
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.
In fact, it's defined by Microsoft, and well accepted by the world at large.
I'm not sure I would use the word 'accepted' :)
Before I go any further, I would like to stress a very important point: Wine is in fact a collection of independent projects. These are the DLLs, and they nicely (and unequivocally) partition Wine into lovely little, independent components. And this means that the LGPL is independently contained to each and every DLL. It is the _perfect_ position to be LGPLed.
At this point, I would like to know if people agree up to this point.
Try reading section 2C of the LGPL and tell me how it's good for commercial companies. If LGPL is so clean, simple and nice, why does mozilla/openoffice/apache/perl not use it?
The discussion has been going all over the place, so I would like to keep this email short and to the point: 0. Isn't Wine's best interest to evolve and develop as fast as it can?
yes
- If so, isn't the LGPL _spirit_ in Wine's best interest?
yes
- If so, why shouldn't we formalize it in the license?
because LGPL (not the spirit) has a virulent provisions that everyone seems to gloss over. The funky notion of "derived work" is pretty scary.
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.
With respect to commercial companies (or people in general): 1) They will use it and not contribute 2) They will use it and make contributions 3) They will not use it.
LGPL addresses #1, but at the expense of increasing #3. The problem is that the people that it adds to #3, would usually go into #2 (because they are told by legal/management NOT to use *GPL stuff). And, I am presuming the bulk of people LGPL subtracts from #1, would just go into #3. So, how is this useful?
would be). And given that IMHO, a lot of wine work to be done (looking at Direct* and other M$ stuff) falls under the unpleasant column (ie, most people won't do this for fun), discouraging commercial work doesn't seem to be the way to go.
And how, pray you tell, is that beneficial in _any_way_ to Wine, if there is no guarantee of seeing that code? Why should Wine care? Why should we?
If you believe all are greedy bas*ards and will just steal the code, then you shouldn't care. If you think that people can make a 'good faith' judgment on what's a bug fix and what is their stuff and will contribute the former, then you should care. Let's say company A implements DSOUND, and contributes X bug fixes that fix acm stuff, but keeps its DSOUND implementation. I would say that you are STILL better off, as you got the acm fixes. If company A would not have done the work because it couldn't keep what it did, then you are NOT better off by using LGPL.
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?
But I do agree that this beating a dead horse.