On Tue, Feb 12, 2002 at 04:21:59PM -0500, Roger Fujii wrote:
Read: http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/0203.html I don't think that LGPL and GPL differ in this regard.
[Summary of link: discussion of whether including binary-only firmware in the Linux kernel is a violation of the GPL.]
In this regard, they do not differ. However, whereas the GPL is mostly 'symmetric', placing the same limitations on anything that's linked to GPL code (except for the "standard system facilities" exemption), the LGPL quite explicitly only places limits on the licensing and source-availability of other code on which the LGPLed code is made to depend.
it also restricts the ways and means of binary distribution.
To give a concrete technical example (but not an authoritative legal one, as IANAL), it is my understanding of the LGPL that if someone has released a library under the LGPL, a third party cannot distribute a modified version of this library that has been linked against a proprietary library[1]. I think because of the reduced scope of the LGPL, there's also less room for ambiguity on questions of aggregation vs. derived works.
I believe your case falls under the "work as a whole" clause. The problem in the wine context is that it is NOT clear that any propriatary library doesn't fall under that clause unless you make it as a dropin replacement for something that's already there. And, if it's NEW functionality you're adding, you must do it in such a way that it can be removed at runtime. So, if your business model is to develop a value-add, LGPL is not your friend.
yes, but studying can be done in a non 'open source' license too (like AFPL). This is why using the word "contribute" is really a misnomer which is why I said "show your work".
The difference is that in the case of the LGPL, a third party can only erect certain limited sorts of technical barriers to reintegrating the sources, at some cost to them in terms of programmer time; whereas under the BSD license, a third party can erect legal barriers to reintegration.
if you can make a propriatary extension, it holds that you can license the source code for it some other way too. If the point was that with enough effort, you can roll (some of) the changes back in, then I agree. But is this practical?
There is an important difference between LGPL/GPL and standard EULAs for proprietary software. An EULA requires a user to give up freedoms they would otherwise have; the LGPL and GPL give additional freedoms TO users which under copyright law would normally be reserved for the author.
this is a perceptual difference. the legal mechanism for both is simply conditions of the transfer of the copyright since neither case makes any difference to anyone who doesn't distribute what they have to the public.
If a third party does not accept the terms of the GPL, and they have been granted no other license to modify/redistribute, then they're guilty of copyright infringement -- and copyright infringement is far easier to prosecute than tort or breach of contract.
well, not according to that calif. ruling (in certain cases).
Eben Moglen has expounded on this point quite persuasively in the past. Whatever flaws the xGPL licenses might have, I assure you that unenforcability is not among them.
I don't believe anyone has said there is NO legal basis. What has been said is that there is little legal PRECEDENT. There are various parts to *GPL that are quite arbitrary (like, why is it legal to link with a .so, but not a .a, or a .o? what is being linked is the same) and is not clear it will stand a good challenge. As such, it's pointless to argue what it means except in the cases that it's absolutely clear on. For all other cases, you are in untested territory.
To the question of the LGPL being unclear: your example at the top cites discussion among a number of non-lawyers. The fact that they disagree about the meaning of "aggregation" may merely be a reflection of the fact that no party to that discussion is an expert in IP law.
until there is case law, what those words mean in the software context is open to interpretation. "Aggregation" of books may not be considered the same as aggregation of programs. If you need convincing of this, look at the consent degree between the justice dept and M$ with IE in win98.
Any company that's considering working with Open Source software as any part of their business model should seek legal advice; just because the BSD license seems clear to most informed laymen doesn't guarantee that it's free from legal pitfalls.
would you care to enumerate one that is the result of the license?
So while an easily understandable license may be helpful to some, it doesn't eliminate the need for corporate lawyers.
you must know some INCREDIBLE lawyers. The ones I have dealt with always makes something simple really complicated. If you know of someone that can make something complicated simple, I'd like to have their #.
If the company is one like, say, Lindows.com, and they have a business model based on selling a branded, enhanced version of Wine, there are rational reasons for possibly not wanting to use an LGPLed code base. There are several different options for such a company. Some might choose to risk the LGPLity, and decide to see if they can make a profit just from selling people something they can already get for free. This is not out of the question; every Linux vendor is doing this today, and if 90% marketing + 10% programming works for Microsoft, it should work for others too, right?
a) M$ can charges for their work b) it works for linux (I presume you mean distributions) vendors because most others sell a propriatary value add (like transgaming) which does not fall under your description for this case. The linux vendors have an advantage that what they are replacing (nt, solaris, aix...) are a rather expensive. The problem wine solves (for most people) is the cost of a PC (US$400). There isn't much of a margin here. Can you show me any example of successful companies using this business model?
Judging by his posts here, it sounds like Michael Robertson believes his own company's business model is already very close to this.
If lindows was just a branded version of wine, why are people getting so bent out of shape about them contributing?
I wonder if he would say Lindows.com's hopes for profitability stand on the ability to maintain a competitive advantage over other Wine vendors by keeping their changes proprietary, or on value-added features such as integration into an easy-to-install product?
I would presume a little of both.
There's still lots of room for proprietary value-add with an LGPL Wine; and I'm not arguing that this is a bad thing. I just think that having companies create value-added products by making closed-source modifications to the Wine *core* is a bad thing.
'lots of'? I really think you are overstating the case. Gav doesn't think so. I think Michael Robertson has implied he didn't think so either - the pie just isn't that big...
(I just love how people use 'steal' in reference to something freely given away - I guess the same people ask for interest when they do charity work)
As someone who gave his assent (however insignificant) to the current Wine license, *I* do not use the word "steal" to refer to the actions of such companies.
you may not have, but this statement has either been said or implied by many in the *GPL camp. It is a pervasive attitude that always makes this topic more imflamatory than it needs to be.
So, given the world of (using "contribute" meaning code that can be easily worked back into the common tree):
- Evil companies that won't contribute no matter what
- Companies that contribute some, but not all of what they do
- Companies that contribute
The only thing a license change will do is stop #2. If this is what you want, we can stop arguing now.
I disagree with this breakdown. Assuming there are "evil" companies involved[2], they will find it more difficult to do evil things with Wine under the LGPL than they would under the BSD license;
this is a given, but they CAN still exist. The notion that LGPL will prevent that kind of behavior is just not true.
and at least some of the companies that don't contribute at all do so because they're misguided, not because they're evil, so the LGPL would cause them to contribute back to our mutual benefit. Both of these results are wins.
the misguided ones I think (MHO) eventually will contribute back, for the very same reason you have stated (problems with keeping the trees synced). Regardless, the whole point boils down to this:
Is the code you are going to coerce out worth the code that is lost by entities either unwilling or unable to abide by *GPL?
There has been ample statements made saying that the latter part of the question is not insignificant.
[2] Not a very sustainable business model, btw; on the whole, being evil is no more profitable than being altruistic.
I agree that it's self-defeating, but there is nothing altruistic if you EXPECT to be paid, whether it's cash, or code. I haven't seen any arguments for *GPL made here on altruistic grounds (not to say that *GPL can't be used for such purposes - take quake from Id software for example, but this is when you take something propriatary and *GPL it). All I see are pretty selfish - which is fine, as long as it's not being passed as being altruistic.
-r
-
Roger Fujii