Patrik Stridvall ps@leissner.se writes:
Umm. I feared that question would come. The "protection"
the LGPL (or GPL)
that Marcus proposed is IMHO largely an illusion when it
comes to libraries.
Sure we might use a strict interpretion as a weapon in a PR campaign against possible voilators but we don't have the resources to sue somebody and I very much doubt we would succed either.
I think you greatly underestimate the power of such licenses.
That is what remains to be seem. Many laws doesn't make logical sense anymore or becomes inconsistant in the new brave world and the attempts to adapt them often introduces new problems.
The attempts of various courts the interpret the uninterpretable inconsistancies, without realizing it, futuremore adds to the confusion.
Expect extreme uncertainty to be the keyword for the immediate future.
AFAIK nobody in the world is currently shipping code (except maybe by mistake) in violation of the GPL or LGPL, despite the fact that it has never been taken to court.
True, it does have some power because few wants to be named a bad boy, but that might mean less and less in the future.
And nobody in their right mind would base a business on shipping illegal code; even if they believed they could get a judge to agree with them, the risk is simply too great.
Small changes in a particular DLL then there is no clear boundaries between their boundaries between their code and ours might be risky, true.
However, in your example five companies offered one proprietary version each of five different half important DLLs.
They might even have an implementation from scratch with no Wine code at all. I can see no difference between for example their DLL and a Microsoft DLL running under Wine, regardless of Wine being GPL or LGPL or whatever.
Then we have the middle case by have say the Crypto API that is a part of ADVAPI32. Does distributing a whole file replacement of dlls/advapi32/crypt.c represent a violation of GPL or LGPL? In that case why? The Crypto API is largely independent of the rest of ADVAPI32 it could as well be a separate DLL.
Any protection that (L)GPL provides is to a large part based on myth and legend.
In addition hypocritical people at for example Slashdot also seems to wish to apply different standard at open source licenses and proprietary licenses.
So company cries that their products shouldn't be hacked (having a part replace) should be ignored despite their insistance that a paragraf of their license has been violated, while any violations of the (L)GPL doing essentialy the same thing (replacing a part) should be strictly enforced. :-)
Note that I'm not accusing you of being hypocritical, I just point out the we can't both have the cake and eat it. What if Microsoft licensed their code as is not allowed to run under an emulator or something similar?
Of course myth and legend can be a powerful ally. Just look at all thing done, good or bad, in the name of Christianity, Democracy or whatever, regardless of whether what was done was was logically consistant with whatever else was done.
However, my opposition to (L)GPL is not based primarily on that, but rather the alleged, and by you, it seems, supported, features of it. See below.
My concern is not so much about Transgaming, I trust that
Gav means to
do the right thing,
Agreed and I think we should allow them considerable time
to consider
their position as well no need to rush something.
I'm not trying to rush anything, just opening a discussion. And as I said this is not against Transgaming, any license change would not modify the current situation at all anyway, since it obviously only applies to future developments.
Agreed.
even if I don't entirely agree with his methods.
Well, money makes the world go round whether you like it or not. :-)
I like it, in fact as you may know I make money with Wine too... I'd be more than happy to see Gav or others make millions out of Wine, but I don't want to let people hurt the project, even if doing that makes them more money.
Agreed.
Now that Transgaming has done the hard work of getting
InstallShield to
work and even been kind enough provide the source code
eventhough under
a propritary license it can't be that difficult to look at it and provide an alternative implementation.
The issue is absolutely not limited to this InstallShield stuff. In fact my worry is much more about what we see happening in DirectX, where all development on the free version has stopped.
True, but that doesn't worry me so much, since very few non games depend of DirectX and this allows us concentrate on what is really important getting commonly used productivity applications to run under Wine.
Once companies are being to migrate to Linux/Wine we will hopefully get an influx of new developers to fix less important problems.
The work of companies that we don't trust is ignored and we work on as we always have.
That's true if that work is kept completely proprietary. But the thing that the Transgaming stuff should make us realize is that if that work is released under a free but non open-source license, it competes with Wine for user and developer mind share, and it hurts Wine no matter how much we try to ignore it. That is a new situation that I believe we didn't take into account when picking the current license.
That is true, but I still think we made the right choice. If we had made Wine LGPL we might have prevent Transgaming from entering the market and a change now might prevent others from doing so.
I think it is very dangerous for us to reject the help we can get to increase the mind share of Wine and derivates as a whole, inspite of any inconviences for the core Wine project.
Wine has not yet accieved the breakthrough on the desktop market that Linux did on the server market and until then we need all the allies we can yet, regardless of their actually "loyalties".
In short: We have to take the good with the bad.
Patrik Stridvall ps@leissner.se writes:
They might even have an implementation from scratch with no Wine code at all. I can see no difference between for example their DLL and a Microsoft DLL running under Wine, regardless of Wine being GPL or LGPL or whatever.
There is no difference whatsoever, as long as it is not based on Wine code. We can't (and shouldn't) prevent anybody from reimplementing a dll from scratch. What we can (and should IMO) prevent is people using our own code against us.
Then we have the middle case by have say the Crypto API that is a part of ADVAPI32. Does distributing a whole file replacement of dlls/advapi32/crypt.c represent a violation of GPL or LGPL? In that case why? The Crypto API is largely independent of the rest of ADVAPI32 it could as well be a separate DLL.
Any protection that (L)GPL provides is to a large part based on myth and legend.
I think you are very mistaken here. The protection is based strictly on copyright law, and if anything is certain it is that copyright law is going to become even stronger in the coming years.
In addition our situation is even easier since the dll interfaces are already defined for us; the difficulties you see are purely imaginary, I don't think there would be any technical problem applying the LGPL to Wine.
The GPL is another story, but we clearly don't want to go there if Wine is to remain useful for running proprietary applications.
In addition hypocritical people at for example Slashdot also seems to wish to apply different standard at open source licenses and proprietary licenses.
So company cries that their products shouldn't be hacked (having a part replace) should be ignored despite their insistance that a paragraf of their license has been violated, while any violations of the (L)GPL doing essentialy the same thing (replacing a part) should be strictly enforced. :-)
If you don't understand the fundamental difference between the GPL and a standard EULA, I'd suggest studying the issue a bit more. And www.gnu.org is probably a better reference than Slashdot to learn about this kind of things <g>
True, but that doesn't worry me so much, since very few non games depend of DirectX and this allows us concentrate on what is really important getting commonly used productivity applications to run under Wine.
In short, because you don't care about games Wine doesn't have to support them. I strongly disagree with this sentiment; even though I don't care much about games myself, I want Wine to be able to run them just like other applications. And again, DirectX is just one example of something that could happen with any other part of Wine.
That is true, but I still think we made the right choice. If we had made Wine LGPL we might have prevent Transgaming from entering the market and a change now might prevent others from doing so.
I don't think so; they would certainly have had to make some adjustments to the business model, but I think it is definitely possible to build a business on an LGPL code base. Of course these days building any kind of business is quite difficult, but I don't think LGPL vs. X11 is going to be the difference that makes otherwise successful businesses fail.
I think it is very dangerous for us to reject the help we can get to increase the mind share of Wine and derivates as a whole, inspite of any inconviences for the core Wine project.
Wine has not yet accieved the breakthrough on the desktop market that Linux did on the server market and until then we need all the allies we can yet, regardless of their actually "loyalties".
Well, I strongly disagree. Wine is supposed to be a free implementation of Windows; if making it successful requires making it non-free, we might as well stop right now.
Anyway we are not going to convince each other. I take note that you are opposed to the change, even if I admit I'm a bit surprised; it seems last time we discussed licenses you were quite favorable to the LGPL.
On 2001.12.13 18:43 Patrik Stridvall wrote:
Patrik Stridvall ps@leissner.se writes:
Umm. I feared that question would come. The "protection"
the LGPL (or GPL)
that Marcus proposed is IMHO largely an illusion when it
comes to libraries.
Sure we might use a strict interpretion as a weapon in a PR campaign against possible voilators but we don't have the resources to sue somebody and I very much doubt we would succed either.
I think you greatly underestimate the power of such licenses.
That is what remains to be seem. Many laws doesn't make logical sense anymore or becomes inconsistant in the new brave world and the attempts to adapt them often introduces new problems.
The attempts of various courts the interpret the uninterpretable inconsistancies, without realizing it, futuremore adds to the confusion.
Expect extreme uncertainty to be the keyword for the immediate future.
Patrick, is your glass always half-empty? There is no need to be completely and totally pessimistic about everything. Just look at the archives. Almost every argument you have ever made on this list begins with some statement about the courts being stupid or corrupt or something. Really dude, lay off the slashdot for a while.
With that said I'd also like to apologize for saying that (but it still needed to be said).
Alexandre is correct that you are greatly underestimating the power of the FSF licenses. Remember, the GPL and LGPL and also the X11, BSD, etc. all give you rights that by law you would not have.
AFAIK nobody in the world is currently shipping code (except maybe by mistake) in violation of the GPL or LGPL, despite the fact that it has never been taken to court.
True, it does have some power because few wants to be named a bad boy, but that might mean less and less in the future.
You are deluded if you think companies who have been in this position were only concerned about PR. Companies are concerned about only one thing: money. Any company that is not conerned about money as priority number 1 is broken. Hell, by law they have to be.
The bottom line is that someone decided that the cost of bringing their product into compliance with the (L)GPL one way or another was less than the cost of the alternatives.
And nobody in their right mind would base a business on shipping illegal code; even if they believed they could get a judge to agree with them, the risk is simply too great.
Small changes in a particular DLL then there is no clear boundaries between their boundaries between their code and ours might be risky, true.
However, in your example five companies offered one proprietary version each of five different half important DLLs.
They might even have an implementation from scratch with no Wine code at all. I can see no difference between for example their DLL and a Microsoft DLL running under Wine, regardless of Wine being GPL or LGPL or whatever.
Yeah, you're absolutely correct. If a company wants to from scratch implement a DLL and sell it then they can. Just don't do it with code from Wine. (but see below)
Then we have the middle case by have say the Crypto API that is a part of ADVAPI32. Does distributing a whole file replacement of dlls/advapi32/crypt.c represent a violation of GPL or LGPL? In that case why? The Crypto API is largely independent of the rest of ADVAPI32 it could as well be a separate DLL.
Hmm, let me think here about what the LGPL states. Let's say Advanced Crypto Systems (made up company, hereafter refered to as ACS) decides they want to write a proprietary implementation of the crypto code in ADVAPI32.
The LGPL specifically states that you may statically link LGPL code and proprietary code to form a new library provided you follow the conditions. Basically that means the same as usual, that end-users must be able to replace the LGPL part with a newer/modified version given that the interface remains the same. So ACS would be entitled to provide for example a libadvapi32.so file that could drop into an existing wine installation as long as they also at the very least provided their object code before linking it with the rest of wine which would allow an end-user to compile a newer version of wine and link in the ACS crypto support. ACS could instead provide source code, but it need not be under the (L)GPL. It could be under a license only allowing redistribution to people who have a license for the binary.
So basically to answer your question: no, it does not violate the LGPL, though it sure as hell would violate the GPL.. But as Alexandre said, the GPL is extremely inappropriate for Wine, and as such I recommend we drop the GPL issue immediately and focus on LGPL.
Any protection that (L)GPL provides is to a large part based on myth and legend.
In addition hypocritical people at for example Slashdot also seems to wish to apply different standard at open source licenses and proprietary licenses.
So company cries that their products shouldn't be hacked (having a part replace) should be ignored despite their insistance that a paragraf of their license has been violated, while any violations of the (L)GPL doing essentialy the same thing (replacing a part) should be strictly enforced. :-)
As Alexandre said in his reply to this message, these are two different things. As noted above, the (L)GPL gives you privileges you don't otherwise have. An EULA takes away rights you should have. EULAs are actually pretty questionable if you think about it. But copyright on a written work is pretty well established.
Note that I'm not accusing you of being hypocritical, I just point out the we can't both have the cake and eat it. What if Microsoft licensed their code as is not allowed to run under an emulator or something similar?
Tough cookies for them. EULA is really a questionable thing.
Of course myth and legend can be a powerful ally. Just look at all thing done, good or bad, in the name of Christianity, Democracy or whatever, regardless of whether what was done was was logically consistant with whatever else was done.
Where you are going with this I have no idea, but while your at it why not mention the people (using the term broadly here) that are doing bad stuff in the name of Islam.
However, my opposition to (L)GPL is not based primarily on that, but rather the alleged, and by you, it seems, supported, features of it. See below.
Right, so your opposition to the LGPL is not based on the first 60% of what you said... Why did you bother saying it then.
My concern is not so much about Transgaming, I trust that
Gav means to
do the right thing,
Agreed and I think we should allow them considerable time
to consider
their position as well no need to rush something.
I'm not trying to rush anything, just opening a discussion. And as I said this is not against Transgaming, any license change would not modify the current situation at all anyway, since it obviously only applies to future developments.
Agreed.
even if I don't entirely agree with his methods.
Well, money makes the world go round whether you like it or not. :-)
I like it, in fact as you may know I make money with Wine too... I'd be more than happy to see Gav or others make millions out of Wine, but I don't want to let people hurt the project, even if doing that makes them more money.
Agreed.
Now that Transgaming has done the hard work of getting
InstallShield to
work and even been kind enough provide the source code
eventhough under
a propritary license it can't be that difficult to look at it and provide an alternative implementation.
The issue is absolutely not limited to this InstallShield stuff. In fact my worry is much more about what we see happening in DirectX, where all development on the free version has stopped.
True, but that doesn't worry me so much, since very few non games depend of DirectX and this allows us concentrate on what is really important getting commonly used productivity applications to run under Wine.
I have to agree with you here Patrick, but for a different reason. Basically if transgaming wants to maintain their own version of DirectX the LGPL does not stop them from doing it. This holds true for even parts of a DLL (see above discussion using your crypto code example).
Once companies are being to migrate to Linux/Wine we will hopefully get an influx of new developers to fix less important problems.
The work of companies that we don't trust is ignored and we work on as we always have.
That's true if that work is kept completely proprietary. But the thing that the Transgaming stuff should make us realize is that if that work is released under a free but non open-source license, it competes with Wine for user and developer mind share, and it hurts Wine no matter how much we try to ignore it. That is a new situation that I believe we didn't take into account when picking the current license.
That is true, but I still think we made the right choice. If we had made Wine LGPL we might have prevent Transgaming from entering the market and a change now might prevent others from doing so.
Bullshit. The LGPL is actually pretty damn liberal. I think one advantage here is that it would actually require the transgaming peices to be in different object files so they could be relinked, or in different source files (possibly under the AFPL) so that they can be recompiled and then relinked.
I think it is very dangerous for us to reject the help we can get to increase the mind share of Wine and derivates as a whole, inspite of any inconviences for the core Wine project.
Wine has not yet accieved the breakthrough on the desktop market that Linux did on the server market and until then we need all the allies we can yet, regardless of their actually "loyalties".
In short: We have to take the good with the bad.
Sorry, I totally disagree with this. Wine exists because developers like us enjoy hacking on it. Is the goal really to try to bring as many people away from MS Windows regardless of what platform the move to. What if people decide to move away from Windows and to some other proprietary WinAPI platform. Has this really furthered the Wine project? With the risk of sounding too much like Stallman, I think the real goal is to get as many people using free software as the base system. I will stop with that because I don't think at this point forcing the issue of free software for everything (including applications) is going to work.
In any case, going LGPL would not affect TransGaming horribly. They would still be free to release proprietary components such as the DirectX libraries. And by my reading of the LGPL they would even be able to implement parts of a DLL as long as they are in seperate objects.
Furthermore, moving to LGPL is not as bad as moving from the original license to X11 was. As has been mentioned the only thing that needs to be done is to make new contributions LGPL. I will actually extend this idea. Give developers a choice of whether they want to use LGPL or X11 for their contributions. The idea being that to use Wine as a whole you must comply with the LGPL, but for any existing code and for any new contributions under X11 a user or developer could use the code for anything. The only thing that needs to be done to make this happen is for Alexandre to start accepting code licensed under the LGPL into the Wine tree.
-Dave
Well, it might be a bit offtopic, but circulating rumors are that the Lindows guys (who will release their Lindows probably next month or so) will have a special wine version, hacked by chinese developers (and I mean tons of hacks all the way) to make Office 2K work with wine perfectly as well as some other apps. Again - this is a rumor (although I heard it 3 times from different people)..
Do you think that Lindows will be thrilled to give their wine modifications back to the wine developers? I seriously doubt that, but I'll be more then happy to see that I'm wrong here...
BTW: their selling model is quite interesting - you buy licenses per person, not per machines...
They said they would honour any licences given - of course, the BSD license doesn't mean they'll be releasing the source. But they seem like decent people, so we can only hope! :)
I believe a few of their developers are on the list, of course. Any word guys?
- Ender
Well, it might be a bit offtopic, but circulating rumors are that the Lindows guys (who will release their Lindows probably next month or so) will have a special wine version, hacked by chinese developers (and I mean tons of hacks all the way) to make Office 2K work with wine perfectly as well as some other apps. Again - this is a rumor (although I heard it 3 times from different people)..
Do you think that Lindows will be thrilled to give their wine modifications back to the wine developers? I seriously doubt that, but I'll be more then happy to see that I'm wrong here...
BTW: their selling model is quite interesting - you buy licenses per person, not per machines...
-- Hetz
-
Alexandre Julliard -
David Elliott -
Hetz Ben Hamo -
J.Brown (Ender/Amigo) -
Patrik Stridvall