Patrik Stridvall ps@leissner.se writes:
There will be very little reason for companies to enter the market at that time and why try to make it difficult for the few
that might.
On the contrary, there will be a lot more reasons. The main market is not in developing Wine; frankly there isn't that much money to be made on that. The main market is in using Wine to make money on applications, and the more complete Wine gets the easier this will be.
If the applications is are already proprietary I they can affort to pay to get the whole way to 100% functionallity.
If they are open source they have an incentitive to work making Wine complete.
I don't really see the problem.
But if Wine never gets complete because some parts are held proprietary by other companies, it won't be possible to enter that market.
So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it.
In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented.
You can't seriously believe this?
Patrik Stridvall ps@leissner.se writes:
So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it.
No, I'm not saying they won't work on it when it's almost complete. I'm saying that there may not be enough incentive to complete it if all the parts are available under more or less proprietary licenses. Maybe I'm wrong, but your reasoning that it's OK for people who want games to have to pay for it certainly doesn't reassure me.
In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented.
It would not be a disaster, but it is certainly a potential problem too. It is a smaller problem first because making the dlls run is about as much work as reimplementing them, and because they are completely proprietary, not half-way open source. But yes, I do think a number of features could have improved faster if people didn't use native dlls to work around the problems.
On 17 Dec 2001 11:54:46 -0800, Alexandre Julliard julliard@winehq.com wrote:
Patrik Stridvall ps@leissner.se writes:
So you mean that all the people that are current voluntering to work of Wine won't work on Wine if it is almost complete just because somebody else have done the parts they need to run their applications and that they will happily pay for the right to use it.
No, I'm not saying they won't work on it when it's almost complete. I'm saying that there may not be enough incentive to complete it if all the parts are available under more or less proprietary licenses. Maybe I'm wrong, but your reasoning that it's OK for people who want games to have to pay for it certainly doesn't reassure me.
In that case it would be disasterous to make Wine run all Microsoft implemented non-core Wine DLL:s because then everybody would just be happy to use the Microsoft DLL:s and nothing beyond non-core would ever be implemented.
It would not be a disaster, but it is certainly a potential problem too. It is a smaller problem first because making the dlls run is about as much work as reimplementing them, and because they are completely proprietary, not half-way open source. But yes, I do think a number of features could have improved faster if people didn't use native dlls to work around the problems.
I am just a watcher, though I have dreams of being an active developer someday.... when I don't need my day job.
During the recent discussions, it struck me that the legal opinions being offered are a red herring. Projects such as Wine depend much more on the sociology of the situation than the legal fine points.
To that end, Alexandre has a critical choke hold on Wine development. All proposed patches flow through him. [Logically that could be a small subset of people with CVS update rights.] He can make decisions based on technical, artistic, developmental reasoning.
So, if some other entity [OE] is doing something not in the best interest of the whole project, he can simply refuse to cooperate with them. That means not engage in technical discussions, not take patches, etc. As the OE source base drifts away from Wine, their cost do doing business will steadily increase compared to a cooperative stance. If the OE is named as a non-cooperator, most other developers will tend to ignore their problems, also increasing their cost of doing business. It doesn't have to be anything dramatic. Cooperation will decrease their cost of doing business in the long term. They can take short term advantage but long term the cost will be severe.
Best wishes,
john alvord
I've initially wanted to reply to one of the messages in the thread, but I realized that we're going in circles.
Let's recap, and look at the spirit (i.e. the intent) of the two licenses in question: 1. BSD = here is the code, you can do whatever you want with it. 2. LGPL = here is the code, use it however you want, but if you make modifications to it, contribute it back.
Technicalities aside, the LGPL spirit seems to be accepted by most people. 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. In fact, it's defined by Microsoft, and well accepted by the world at large.
Now, that being said, there seems to be two camps: -- the BSD camp, which maintains that BSD is good enough, and that people will in fact do what the LGPL wants. -- the LGPL camp, which says 'well, if that's the case, why not have it formalized in the license'?
The only reason that seems to be invoked by the BSD camp, is that the BSD license works in practice just like the LGPL, but moreover, it is somehow friendlier towards the commercial folks.
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. 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? 1. If so, isn't the LGPL _spirit_ in Wine's best interest? 2. If so, why shouldn't we formalize it in the license?
When answering these questions, let's try to leave the commercial aspect out of it for a second. That is a separate discussion. You see, the reason we care about the commercial aspect is that we hope (from Wine's selfish point of view -- as it should be!), that the commercial world will actually _help_ in the development of Wine (that is, having a commercial universe around Wine would be in Wine's best interest). Now, I claim that the LGPL is _way_better_ for the commercial interests in the long term, but I will leave that to a future email (if people care to discuss it).
All I have to say is that for me, the conclusion is unescapable: we should switch to LGPL.
-- Dimi.
"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.
Hi there,
I have been watching this thread quietly for some time now but I feel I should probably put my opinion forward ... now or never. Warning - it's longish and covers a few things that might be considered a little bit "left field".
I have worked at more than one company in the capacity of an "open source programmer", however you choose to read that. My primary open source involvement has been with the OpenSSL project, but I've ventured forth bits and pieces to other projects too.
The following note struck a chord with me;
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.
I think the essence here is pretty spot on, but I'd like to take it a step further. I have worked on source code in a company that for various reasons (outside it's control I might add) was using essentially a "forked" development tree. The reason is that proprietary code (including external elements they had no permission to open to the wide world) was being used as a supplement to the public code at a certain point in time. During only a short period of time, they did not have adequate resources to pay attention to this problem let alone rectify it. As a result, the open source project had continued forth to the point that not only was the proprietary tree left behind, much of the change in the public tree had in fact conflicted massively with the proprietary code. In this case they hadn't wanted to keep the proprietary code to themselves, but even in cases where the retention of corporate development is by choice - the maintenance curve can easily get steeper than the perceived benefit of doing so.
This is not that uncommon - maintaining proprietary patches to open source projects is always a pain in the ass, and the only positives (when there are any) are commercial. And you should know full well that when commercial considerations have chosen to win out over technical and/or logistical considerations, you can discuss the differences between LGPL/X11/BSD/etc until you are blue in the face and it won't, in all reality, make a shred of difference to what such companies do. As has been adequately demonstrated in many posts already - you can wrap up proprietary code in any number of ways and the practical hurdles of separating that from "public" code are probably minimal (and reasonably constant over time). So the LGPL-vs-BSD differences in that respect are unlikely to amount to much IMHO - especially given the component-oriented nature of wine.
"Forcing" those companies (if one believes the LGPL assertions) that are planning to retain (some of) their wine improvements to at least provide static libs of their proprietary code makes, IMHO, no great difference. The only noticable difference AFAICS is that it improves their users' experience anyway - because they can use the company's product but benefit (perhaps) from improvements in the public code ... but ... if you look at it - helping users of those company's products is hardly doing anything to "deter" the behaviour we all agree should be discouraged, is it? It simply improves the user-experience of these companies and rewards the business model. Again, I doubt the LGPL in reality discourages this behaviour any more than the current license.
I'm not going to "vote" on the wine licensing issue at the end of the day - I'm a casual user and certainly have *not* contributed anything to it - so to my mind, I have no right to do so.
However, if I might wax extreme for a moment, my out-there suggestion would be to stick with a BSD style license but to put an advertising clause *in*. This leaves companies/users/etc basically with their existing freedoms, but provides a P-R feedback loop that might discourage companies who were looking to peddle their wares as "better and other than wine" - it would instantly show them up as being "wine + stuff we didn't contribute back" rather than anything completely independant of the public project. This might also allay fears companies might have about contributing - ie. would Transgaming fear other companies profiting from their work if those other companies also had to 'fess up to using the public wine project themselves? Would not the kudos from sponsoring/contributing/maintaining the D3D work in the public wine project more than offset the fact that other companies would then have the same functionality? I don't think so - especially as the public version would also have it.
Under such a license, what companies contribute back and what they don't is still their choice, but there is a counter-balance to the temptation some might have to withhold their own improvements whilst harnessing the work of others.
The rest of the suggestion I would like to make may seem somewhat surprising; dual license this BSD+adv-clause with the GPL. Not LGPL, but GPL. GPL is an enormous hunk of trouble I know, but under a dual license you're only bound by it if you choose to use it instead of the alternative. The GPL would then exist as an alternative for those who can not work with the BSD (and/or the advertising) clauses - eg. some of those GPL and LGPL projects that have a "no additional restrictions" viral element. If they don't like BSD/adv-clause, they could always go with GPL but would then be stuck with the *ultimate* counter-balance, they have to open up *everything* else they do and stay with the GPL from then on. Given that the most stark conflict with a BSD+adv-clause license is the GPL itself, this would provide a clean fit into GPL projects. Those that can't handle using the GPL option (we shall call this "the sane world") would then have all the freedoms of that BSD-style alternative - with the simple proviso that they have to 'fess up from the get-go that their product is built using wine. In other words; if your commercial product can run win32foo.exe and the public version of wine can not, that means you have supplemented or edited the wine code but didn't contribute it back. Customers can then judge for themselves.
From my experience, I would expect that there are those who would *not* want to use a "mutant" wine just to get paid-up support or an extra feature or two - the simple reason is that you've always got a smoother upgrade path and wider support/info resources available to you if the commercial product hasn't frankensteined the public version. From a Q/A point of view, do you prefer your employees/children/uncle/whoever buying supported products that are known to be forward compatible with a public open source project, or do you prefer them buying products that have no future the moment their subscription lapses or the company goes under?
If you don't know it's based on wine, you probably think you've got no choice. If you know it's based on wine, you're more likely to wait for the public wine itself to catch up (or you will buy your supported product for the support services but will switch to the public version as/when it matures enough to solve your needs).
Anyway ... sorry for the blurt - I realise such a scheme may be off the radar for most people, but thought I should at least mention it. At least it might inject a fresh "something" into this thread (though what that something is remains to be seen ...)
Cheers, Geoff
Geoff Thorpe wrote:
However, if I might wax extreme for a moment, my out-there suggestion would be to stick with a BSD style license but to put an advertising clause *in*.
The problem with this is that it would make it incompatible with *GPLed components as an ad clause conflicts with an Open Source definition.
The rest of the suggestion I would like to make may seem somewhat surprising; dual license this BSD+adv-clause with the GPL. Not LGPL, but GPL. GPL is an enormous hunk of trouble I know, but under a dual license you're only bound by it if you choose to use it instead of the alternative. The GPL would then exist as an alternative for those who can not work with the BSD (and/or the advertising) clauses - eg. some of those GPL and LGPL projects that have a "no additional restrictions" viral element. If they don't like BSD/adv-clause, they could always go with GPL but would then be stuck with the *ultimate* counter-balance, they have to open up
But most apps wine will run *cannot* use a GPLed component. GPL expressly forbids being linked to a nonGPLed component. *GPL does not only cover the source, but rather the USE of the components as well. Read the license. It's quite an eye opener.
-r
On Wednesday 19 December 2001 00:34, Roger Fujii wrote:
Geoff Thorpe wrote:
However, if I might wax extreme for a moment, my out-there suggestion would be to stick with a BSD style license but to put an advertising clause *in*.
The problem with this is that it would make it incompatible with *GPLed components as an ad clause conflicts with an Open Source definition.
Which is why I made the suggestion of dual-licensing with GPL.
But most apps wine will run *cannot* use a GPLed component. GPL expressly forbids being linked to a nonGPLed component. *GPL does not only cover the source, but rather the USE of the components as well. Read the license. It's quite an eye opener.
I'd argue (though IANAL) that a nonGPLed win32 executable running under wine is not being "linked" to any GPL component - wine itself may be linking to its own GPL components at run-time depending on what's going on with the win32 executable. But in terms of true linkage, I'd have viewed the win32 executable as more like a document that causes the host application (wine) to load appropriate sub-components with which to process the document. MS Word (to use an example) might have to dynamically link in a special MS Word component to process specifics in my document, it doesn't mean my document is "linked" with the MS Word component does it?
Of course, we could all ask RMS his opinion but we all know he'll interpret it (once again) to mean whatever is required to spread his GPL tenderhooks as far as possible. Living in Wellington, NZ I'm having to fight back hard the temptation to make a "Sauron" joke here ... :-)
Cheers, Geoff
On 2001.12.18 06:13 Geoff Thorpe wrote: [BIG SNIP]
The rest of the suggestion I would like to make may seem somewhat surprising; dual license this BSD+adv-clause with the GPL. Not LGPL, but GPL. GPL is an enormous hunk of trouble I know, but under a dual license you're only bound by it if you choose to use it instead of the alternative.
Umm, didn't I suggest dual-license Original BSD (w/ Advertising Clause) and LGPL in one of the first mails of this thread????
Or maybe I was thinking that and never actually sent the mail out.
Now why you would want to dual license Original BSD/GPL is beyond me. GPL is just simply not at all suitable for Wine.
Honestly, the dual-license Original BSD/LGPL seems very ideal to me. TransGaming could continue business as usual. Any future users of Wine would be required to disclose the fact that they were using Wine (which IMHO is a good thing) and we would still remain (L)GPL compatible since we would also be licensed as LGPL.
This dual licensing also has the advantage that it would put Patrick's arguments to rest since I could not see any person or company willing to push the LGPL to the limits simply to remove an advertising clause. Although I am sure Patrick will be more than happy to come up with an ongoing argument against this.
The only disadvantage to this method is that it really doesn't give us much protection. The only thing it offers us is that people who want to avoid the LGPL will have to make it known that they did so.
If we do go this route, I would highly suggest specifying a very prominent advertising clause. That is to say something like anywhere the application displays information about itself it should include a phrase such as "developed with Wine technology, visit http://www.winehq.com/ for information". Examples of places would be splash screens, about boxes, etc. for GUI apps and maybe a line or two output for CLI apps that already display their name in their output.
E.g. a CLI tool known as Foo application might display: Foo Application v1.0 Copyright 2001 Bar Corporation Developed using Wine technology, visit http://www.winehq.com/
This would also hold true for something like Lindows. During startup I assume it would display something like "Starting Lindows" so it should also be required to say something like "Developed using Wine technology, etc..."
Companies or individuals who would prefer not to have the advertising clause can simply abide by the LGPL license.
-Dave
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?
it would appear thats changing and I hope this isn't duplication ( according to mozills site this re-licensing began 9/2001) =============
http://www.mozilla.org/MPL/relicensing-faq.html
latre lee -==
lee wrote:
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?
it would appear thats changing and I hope this isn't duplication ( according to mozills site this re-licensing began 9/2001) =============
They still don't use it *exclusively*. They are doing this to reconcile the problems created by the *GPL covered components. Notice the last sentence of the first paragraph: "in particular identified Mozilla-related license issues that could arise with developers using the GNU Lesser General Public License (LGPL) for their own code." (whatever that means in the mozilla context).
-r
On Tue, 18 Dec 2001, Roger Fujii wrote:
lee wrote:
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?
it would appear thats changing and I hope this isn't duplication ( according to mozills site this re-licensing began 9/2001) =============
They still don't use it *exclusively*. They are doing this to reconcile the problems created by the *GPL covered components.
And your point is??? Mozilla _is_ using the LGPL, and it seems to have won over the MPL for whatever reasons. Developers prefer it. Which makes it better. Why should we p*ss against the wind? Just to get wet?
-- Dimi.
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.
Try reading section 2C of the LGPL and tell me how it's good for commercial companies.
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.
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???
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.
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.
-- Dimi.
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
David Elliott wrote:
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)"...
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.
Thanks for explaining what Patrik has been going on about. 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 improvement to himself -- which would also deprive the user of the ability to fix bugs in the proprietary reimplementation of that particular WineLib function.
Did I get it right? - Dan
On 2001.12.19 11:43 Dan Kegel wrote: [BIG SNIP]
Thanks for explaining what Patrik has been going on about. 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 improvement to himself -- which would also deprive the user of the ability to fix bugs in the proprietary reimplementation of that particular WineLib function.
Did I get it right?
- Dan
Well, you got my argument right.
-Dave
David Elliott dfe@tgwbd.org writes:
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.
Actually the fact that they are internal or not doesn't make a difference, I wasn't clear on that point. If your code is linked to the library it is considered a derivative work, and by default the whole has to be released under the LGPL. Now there are cases where you don't need to do that: one is if your app is considered a work that uses the library (section 6), the other is if you are placing your code side-by-side with the library (section 7).
So if you don't want your code to fall under the LGPL, you have two choices: one is to put it in some part of your app that only links to the library, but in that case you cannot have other parts of the library depend on your code (this is the square root example). This would work for the crypto API, probably not for CreateWindow since the rest of user32 needs CreateWindow.
The other solution is to put your code side-by-side in the library; but this is only possible if your code is not covered by the license, which means it isn't a derivative work of the library, which in turns means it cannot use any functions or data (exported or not) of the library. This would work for the crypto API as long as you don't use anything from the rest of libadvapi32.
On 2001.12.19 12:32 Alexandre Julliard wrote:
David Elliott dfe@tgwbd.org writes:
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.
Actually the fact that they are internal or not doesn't make a difference, I wasn't clear on that point. If your code is linked to the library it is considered a derivative work, and by default the whole has to be released under the LGPL. Now there are cases where you don't need to do that: one is if your app is considered a work that uses the library (section 6), the other is if you are placing your code side-by-side with the library (section 7).
So if you don't want your code to fall under the LGPL, you have two choices: one is to put it in some part of your app that only links to the library, but in that case you cannot have other parts of the library depend on your code (this is the square root example). This would work for the crypto API, probably not for CreateWindow since the rest of user32 needs CreateWindow.
Okay, that makes a bit more sense. Although couldn't one argue that it still does work since it could fall back to the original LGPL createwindow?
The other solution is to put your code side-by-side in the library; but this is only possible if your code is not covered by the license, which means it isn't a derivative work of the library, which in turns means it cannot use any functions or data (exported or not) of the library. This would work for the crypto API as long as you don't use anything from the rest of libadvapi32.
Right.
-Dave
David Elliott dfe@tgwbd.org writes:
Okay, that makes a bit more sense. Although couldn't one argue that it still does work since it could fall back to the original LGPL createwindow?
Sure, if this is the case it's OK. You can perfectly provide a user32_better library that implements a new CreateWindow, and links to user32 for the rest. But the modified user32 you ship must work properly, it cannot be dependent on your proprietary user32_better for its own functionality.
Hi, I'm following this list for a while, and even if I still haven't found time to devote to the project itself, I've seen few things in this thread that I would like to comment on.
Please note that I will be referring to the 2.1 version of the LGPL.
Il mer, 2001-12-19 alle 07:41, David Elliott wrote: [snip]
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)"
I don't think so.
After all, with regards to a Windows Executable (and more so for winelib ones) this is a library. This means that it has a well-defined interface with a well-defined behaviours (btw, in our case, well-defined means "as it can be defined by the code itself, not by some documents") that you need to use to access its facilities. If you are crossing these lines, you aren't simply using the library, you are actively changing its semantics, or its expected behaviour. And I think that this can clearly interpreted as a derived work.
More so, the 2.d provision in the LPGL says that:
"If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, you must make a good faith effort ensure that in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful".
Please note that the "other than as argument" is quite clear regarding its applicability. It means that both dynamic and static linking are subject to this requirement, as well as that the magnitude of the changes you can do is quite limited in functionality, or you will never be able to fullfill it.
Another problem is that your modifications to the semantic of the library will be quite obviously refused by the mantainers of the library, so you will need to maintain them by yourself, and since your ipothetic function is using an internal interface that you have just changed to an external one, you are even exposed to all nastyness related to the changes that the original maintainers/developers can introduce to this interface.
I don't think this approach can work, as indirectly confirmed by the last mail of Gavriel State with the regards to their current situation. If you think of all problems they are having now with the current license scheme, with a license like the LGPL this can easily become a real nightmare.
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.
this can done only if the impacted portion of code remains "meaningful" even when you don't provide the rewritten function. If your function is providing something that is not replaceable under the current form of the library (as stated by 2.5), you cannot do such thing.
The provision of 5 are available only if you comply with their premises ("A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library""). This means that your modifications to the library cannot be distributed together with the program, but they must be distributed with the library or as an additional package (I've just read the reply from Alexandre and it seems that he's interpretation is similar).
I think that even if the LGPL can be flawed, it is a minor one, since the sheer size of the effort required to work-around this flaw and to abuse the license wording, as well as to survive to the public outrage that this will trigger, will require way too much time and money to be done, especially with such a fleeble premise.
BTW IANAL.
bye,
/pietrobo
-
Alexandre Julliard -
Dan Kegel -
David Elliott -
Dimitrie O. Paun -
Geoff Thorpe -
John Alvord -
lee -
Marco Pietrobono -
Patrik Stridvall -
Roger Fujii