You might believe me or you might not, as all people arguing against me last time. Be that as it may, that discussing is dead and I will in the future concentrate on "If the LGPL means what you say it does, we don't want the LGPL".
Actually, IYRC, and IIRC, I pretty much agreed with you that the LGPL actually WOULD allow one to implement proprietary code simply by releasing small wrapper functions as LGPL code.
Yes, but you was one of the few. Alexandre in particular seemed to believe it depended on some strange notation of whether it was intentional or.
As in:
DWORD WINAPI FooMicrosoftApi(CHAR *bar, DWORD baz) { return someotherdll_FooMicrosoftApi(bar,baz); }
Which would be LGPL, and the someotherdll_FooMicrosoftApi would be under a different license.
With this situation the stated purpose of the LGPL is still upheld. The stated purpose is to allow one to continue to update the parts of the code that are LGPL while still being able to link with proprietary components.
Exactly. However I see no reason particular reason why even less honourable companies wouldn't release the wrapper code to the us whether they were forced to or not. It is in their intrest to make it easy for Wine to use their library so they can limit the support for clueless users for example.
This even if LGPL allowed it, is not a strong argument for LGPL. In this case it would only primarily the confusion on whether this is allowed, for little gain.
Thus TransGaming does not hurt. Lindows really doesn't hurt either, and the users of Lindows win because should they need to update the LGPL components of Wine they can do so and still continue to link to Lindows binary only components.
Exactly, but they will be able to do that without the LGPL. It is in the respective companies intrest to make it so.
Now you may consider this not enough to stop the less honourable companies. Yeah, you're right. Lindows can continue to build upon wine, add their own stuff, and release a product. The only difference is that now they can't just fold all the wine code into the binary.. they have to allow the user to update the wine code. That is the purpose of the LGPL. Unlike the GPL which tries to make all software free software, the LGPL tries to keep free software as free software, and proprietary software as proprietary software.
Yes. But that is NOT an argument for using LGPL as I have said above.
Now let's say we take the stricter interpretation that you cannot do the above. That is bad I think.
How about going to LGPL and add a clause that clarifies that the above is in fact allowed?
Why confuse the company lawyer even more?
Even if I would be inclined to agree, I would rather let the FSF lawyers draw up a completely new license lets call it, hmm, MGPL (Middleware GPL), for use in, hmm, what should I call it, say two-ended libraries that Wine IMHO really is.
This MGPL should clarify that it is legal to "plug-in" proprietary application/libraries in both ends while code the middle that is the Wine source code should have some copyleft like protection and additional that sublicening the code as LGPL is allowed.
Note however I'm not really proposing this but it might be a reasonable compromise. Perhaps something for the LGPL camp to chew on.
I think it's more of an issue of people thinking too much in black/white terms and people that lean strong towards one side or the other.
Yes. Perhaps they are not nessarily thinking in black and white but their arguments are often presented that way.
I'm not entirely blameless on that point either, I will try to do better in the future.
Look no further than the US political system for a good example. You have the Republicans and the Democrats. Generally they take every issue to opposite ends of the extreme such that 99% of congress is at one extreme or the other, but 99% of the population wants neither extreme.
Exactly, but that is because:
- They want votes so they can do that they feel is right.
- The ignorant masses are not likely to understand subtle differences in opionion.
When the voters give any of them support, the problem is that they didn't really support the extreme views they presented, but they are forced to do it anyway in order of not being accussed of betraying the will of the voter.
You can thank the "liberal" media for that one. :-(
Well, that is just the symptom. The ignorant masses are the real problem IMHO.
Unfortunately, there is no serious alternative to democracy, so I'm a loss what to do. :-(
Lets return the easy problem of finding of good license for Wine. :-)
Especially see MSNBC. What a crock of shit that is.. figures, it being a MS product and all :-). The reporters on that station are just horrible. They ask a question and when they get a totally straight answer that they don't agree with they just ask it again and again changing a few words to make it seem like it's a different question.
Well, people watch the shit, so they get what the deserve.
Unfortunately it hurt us other as well, but then we really can't limit their freedom of speech, can we?
In the cases of Wine. I hope that the people working with the Wine project are not among the ignorant masses and thus really are able to understand the subtle differences between different positions.
Yeah, so far it only seems like the people who caught this story on slashdot are among the ignorant masses. :-/
I wouldn't really call them the ignorant masses but rather the I-can-almost-but-not-quite-understand-this masses. Since they don't fully understand it they assume that it is something bad and post their unordered thoughts in hope that other might make something out of it.
Essentially we could go on forver about X11/BSD vs. GPL.
It's been
discussed to death already folks. What we need are reasonable compromises. Of course you need to have people willing to compromise to do that. I suspect most developers are with the exception of the view vocal BSD people and the few vocal LGPL all the way people. I myself am certainly not at either extreme.
Even if perhaps some people won't believe me. I not really an extremist. I try to take a pragmatic view of the world.
I believe that GPL has its place, LGPL has it place and the BSD license has its place.
However my analysis of the issues at hand makes me believe that LGPL would be really bad in the particular case of Wine, for reasons that I have tried to explain.
Personally I think the LGPL is pretty damn good and fits wine pretty well but we simply need to clarify the gray areas about what is and is not allowed (see above).
That is the point we disagree on, at least partly.
I suggest that people try to think about scenarios of circumstances where possible extensions to Wine might be made. This might be business models like Transgaming or Lindows.com or just something Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It
are doing.
Just like the examples in the my last mail.
Then ask the questions:
- Do you consider his or her behavior morally or ethically
defendable?
- Does it violate the letter of the LGPL?
- Does it violate the spirit of the LGPL?
- Does it violate the letter of copyright law?
- Does it violate the spirit of copyright law?
- Do you think any reasonable Judge/Jury would find him or
her guilty?
With the spirit of copyright law I roughly mean: Is it what congress intended and/or is it constitutional? Notice the and/or: It is possible for act of congress to be constitutional without being the intention of the congress.
Hmm.. y'know that's a good idea.
At least it something concrete to do instead on arguing back on forth about abtract fears.
We should collectively think of the different scenarios and ask one very important question: Do we /really/ want to prevent this scenario from happening?
Ah, I forgot that very important question. I intend to supply it but somehow it got lost. But perhaps the question:
1. Do you consider his or her behavior morally or ethically defendable?
sums it up pretty well as well.
I can't think about anything except egoistical concerns that could make anybody want to prevent something they thought morally and ethically defendable.
Personally I have warmed up a slight bit to the idea of Lindows. At first I was a bit like.. those dickheads took wine, added a few things, and are gonna sell it for $100/seat and we're not getting any of that or even any improvements back!? That bites.
But now I realize that we need to put that emotion aside and look at how exactly lindows harms wine (which it does).
The first thing is the issue of binary-only wine that can't be changed and has absolutely no source. That really bites for the user who is thus locked into Lindows complete package and cannot even change the parts of wine that Lindows has nothing to do with.
If Lindows prevents users from updating their version of Wine it is really their and their users problems not our problem.
If we were LGPL and allowed importing functions from non-LGPL components then Lindows could still add value by implementing APIs in their own DLL or DLLs and loading them from wine. In fact, they don't need to be DLLs. They could just put all their stuff in their own closed source file, compile it, and distribute the .o so that end users (their customers) can later take that .o file plus the LGPLd modifications to wine that make it use the functions in that .o, and link it into a newer version of wine.
I don't see why we should adapt our license to cater for people that make bad choices and suffer because of it. Especially when such a license might scare other people that might help us away.
Now, the second issue, and the one Alexandre is (or maybe just was) most concerned about, was companies implementing functionality that the real wine does not have will sometimes reduce the incentive for a developer to work on it. That is to say that a good portion of developers that would otherwise be contributing to Wine making stuff work will stop if they can simply by Lindows for $100 and make that work.
Perhaps, but you will have to take the good with the bad and licenses preventing this also prevents other things.
Whether LGPL really does this or not is another question though.
Ironically moving to LGPL would actually make it easier for a wine developer to use some lindows functionality since they could update the rest of Wine. However, at least for me part of the reason I like hacking on Wine is to hack on wine to have a version that is free software. That is, let's say there had been a working closed source ASPI layer then I could've used my CD-R in Wine and maybe I wouldn't have fixed a bunch of stuff with ASPI. But doing that was a lot of fun and I would have been the one missing out by falling back to a lindows implementation and never considering actually fixing the real wine implementation. Plus in the meantime at least my CD-R would've worked so it would have been a less pressing issue and would have avoided numerous reboots for me in trying to create a free version.
Regardless of any fun you might have had. Ask this question:
Would you have consider it ethically or morally defendable if the Wine license had prevented you from using a proprietary ASPI library with Wine and distributing the result to your friends.
Anyway.. these are just two.. there are more I'm sure.. I really need to go to bed though.
Different time zones. I returned from a late breakfast to find your mail. :-)
Before I do so, I would like to point you to the wxWindows website.
According to their short license summary they use LGPL but also allow you to distribute a binary linking with wxWindows included. That exception would not be appropriate for wine (in fact, it's like the main advantage for us to use the LGPL I think). However we could do a similar style thing and say: "We're LGPL but we specifically allow you to create stub functions in our library that call out to your proprietary component.
See my suggestion about the "MGPL" instead.
Hopefully we can get this resolved this time... It's looking promising given the few and far between somewhat clear posts and disregarding the ill-informed wanna-be-on-slashdot shit.
We will see. I'm neither optimistic nor pessimistic for the moment.
On 2002.02.09 06:39 Patrik Stridvall wrote:
You might believe me or you might not, as all people arguing against me last time. Be that as it may, that discussing is dead and I will in the future concentrate on "If the LGPL means what you say it does, we don't want the LGPL".
Actually, IYRC, and IIRC, I pretty much agreed with you that the LGPL actually WOULD allow one to implement proprietary code simply by releasing small wrapper functions as LGPL code.
Yes, but you was one of the few. Alexandre in particular seemed to believe it depended on some strange notation of whether it was intentional or.
In some ways it is. Many times when entities are violating some license or law a decision is partly based on what exactly their intentions were. Although I would not like to rely on this and I think clarifying what and what is not allowed is better than leaving it up to good intentions.
As in:
DWORD WINAPI FooMicrosoftApi(CHAR *bar, DWORD baz) { return someotherdll_FooMicrosoftApi(bar,baz); }
Which would be LGPL, and the someotherdll_FooMicrosoftApi would be under a different license.
With this situation the stated purpose of the LGPL is still upheld. The stated purpose is to allow one to continue to update the parts of the code that are LGPL while still being able to link with proprietary components.
Exactly. However I see no reason particular reason why even less honourable companies wouldn't release the wrapper code to the us whether they were forced to or not. It is in their intrest to make it easy for Wine to use their library so they can limit the support for clueless users for example.
This even if LGPL allowed it, is not a strong argument for LGPL. In this case it would only primarily the confusion on whether this is allowed, for little gain.
Thus TransGaming does not hurt. Lindows really doesn't hurt either, and the users of Lindows win because should they need to update the LGPL components of Wine they can do so and still continue to link to Lindows binary only components.
Exactly, but they will be able to do that without the LGPL. It is in the respective companies intrest to make it so.
If that is so, then why aren't they doing it already?
Now you may consider this not enough to stop the less honourable companies. Yeah, you're right. Lindows can continue to build upon wine, add their own stuff, and release a product. The only difference is that now they can't just fold all the wine code into the binary.. they have to allow the user to update the wine code. That is the purpose of the LGPL. Unlike the GPL which tries to make all software free software, the LGPL tries to keep free software as free software, and proprietary software as proprietary software.
Yes. But that is NOT an argument for using LGPL as I have said above.
Sure it is. The LGPL's purpose in life is to make sure the users of the program can continue to recompile the code that was LGPL to begin with.
Now let's say we take the stricter interpretation that you cannot do the above. That is bad I think.
How about going to LGPL and add a clause that clarifies that the above is in fact allowed?
Why confuse the company lawyer even more?
Even if I would be inclined to agree, I would rather let the FSF lawyers draw up a completely new license lets call it, hmm, MGPL (Middleware GPL), for use in, hmm, what should I call it, say two-ended libraries that Wine IMHO really is.
This MGPL should clarify that it is legal to "plug-in" proprietary application/libraries in both ends while code the middle that is the Wine source code should have some copyleft like protection and additional that sublicening the code as LGPL is allowed.
Note however I'm not really proposing this but it might be a reasonable compromise. Perhaps something for the LGPL camp to chew on.
What you describe sounds to me like what I am describing. A modified and clarified LGPL. Essentially when you start adding or deleting from the LGPL you are in fact making a new license. You are saying the same thing I am.
[SNIP] [Quote Dennis Miller: Y'know.. I don't want to get off on a rant here...]
When the voters give any of them support, the problem is that they didn't really support the extreme views they presented, but they are forced to do it anyway in order of not being accussed of betraying the will of the voter.
You can thank the "liberal" media for that one. :-(
Well, that is just the symptom. The ignorant masses are the real problem IMHO.
Unfortunately, there is no serious alternative to democracy, so I'm a loss what to do. :-(
True. Actually, I think the media is more of a symptom of politicians catering to them for years now. Look at the administration now. They don't take any shit and just tell it like it is. Bush may not be an excellent speaker but he seems to say what's on his mind and doesn't try to always be the media's bitch like Billy-boy and his wife did.
Lets return the easy problem of finding of good license for Wine. :-)
Yeah, sorry, just had to get off on a little rant about the media.
Especially see MSNBC. What a crock of shit that is.. figures, it being a MS product and all :-). The reporters on that station are just horrible. They ask a question and when they get a totally straight answer that they don't agree with they just ask it again and again changing a few words to make it seem like it's a different question.
Well, people watch the shit, so they get what the deserve.
Unfortunately it hurt us other as well, but then we really can't limit their freedom of speech, can we?
Yeah, doesn't that suck. Kind of like people use proprietary software so they get what they deserve. We can't stop them from using it as that limits the freedom's of the proprietary software companies and the users who want to use that software. However what we can do is remove the need to use proprietary software. Wine is a first step towards this.
In the cases of Wine. I hope that the people working with the Wine project are not among the ignorant masses and thus really are able to understand the subtle differences between different positions.
Yeah, so far it only seems like the people who caught this story on slashdot are among the ignorant masses. :-/
I wouldn't really call them the ignorant masses but rather the I-can-almost-but-not-quite-understand-this masses. Since they don't fully understand it they assume that it is something bad and post their unordered thoughts in hope that other might make something out of it.
Yeah, sometimes a little knowledge is far worse than none at all. Usually this is only the case when people think that a little knowledge makes them an expert and get big-egos.
Essentially we could go on forver about X11/BSD vs. GPL.
It's been
discussed to death already folks. What we need are reasonable compromises. Of course you need to have people willing to compromise to do that. I suspect most developers are with the exception of the view vocal BSD people and the few vocal LGPL all the way people. I myself am certainly not at either extreme.
Even if perhaps some people won't believe me. I not really an extremist. I try to take a pragmatic view of the world.
I believe that GPL has its place, LGPL has it place and the BSD license has its place.
However my analysis of the issues at hand makes me believe that LGPL would be really bad in the particular case of Wine, for reasons that I have tried to explain.
Personally I think the LGPL is pretty damn good and fits wine pretty well but we simply need to clarify the gray areas about what is and is not allowed (see above).
That is the point we disagree on, at least partly.
/Only/ partly. Look, I am by far not an (L)GPL everything bigot. Nor am I an X11/BSD is the only way to go bigot. Anybody who has opinions that strong should really start thinking more in terms of what's best for wine, not what's best for proprietary companies who want to make binary only releases of wine, or what's best for the people who want everything to be (L)GPLed free software.
I suggest that people try to think about scenarios of circumstances where possible extensions to Wine might be made. This might be business models like Transgaming or Lindows.com or just something Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It
are doing.
Just like the examples in the my last mail.
Then ask the questions:
- Do you consider his or her behavior morally or ethically
defendable?
- Does it violate the letter of the LGPL?
- Does it violate the spirit of the LGPL?
- Does it violate the letter of copyright law?
- Does it violate the spirit of copyright law?
- Do you think any reasonable Judge/Jury would find him or
her guilty?
With the spirit of copyright law I roughly mean: Is it what congress intended and/or is it constitutional? Notice the and/or: It is possible for act of congress to be constitutional without being the intention of the congress.
Hmm.. y'know that's a good idea.
At least it something concrete to do instead on arguing back on forth about abtract fears.
yup.
We should collectively think of the different scenarios and ask one very important question: Do we /really/ want to prevent this scenario from happening?
Ah, I forgot that very important question. I intend to supply it but somehow it got lost. But perhaps the question:
- Do you consider his or her behavior morally or ethically defendable?
sums it up pretty well as well.
Sounds kind of like my.. do you think it should be allowed question, although put in a better way.
I can't think about anything except egoistical concerns that could make anybody want to prevent something they thought morally and ethically defendable.
Yes, if one thinks a behavior is at least partly morally or ethically defendable, then why prevent people from doing that?
Personally I have warmed up a slight bit to the idea of Lindows. At first I was a bit like.. those dickheads took wine, added a few things, and are gonna sell it for $100/seat and we're not getting any of that or even any improvements back!? That bites.
But now I realize that we need to put that emotion aside and look at how exactly lindows harms wine (which it does).
The first thing is the issue of binary-only wine that can't be changed and has absolutely no source. That really bites for the user who is thus locked into Lindows complete package and cannot even change the parts of wine that Lindows has nothing to do with.
If Lindows prevents users from updating their version of Wine it is really their and their users problems not our problem.
This is simply not true. This is very much Wine's problem. If I need some of Lindows's functionality to run my program but would still like to be able to hack on other parts of Wine then I, as a developer and user, am screwed.
If we were LGPL and allowed importing functions from non-LGPL components then Lindows could still add value by implementing APIs in their own DLL or DLLs and loading them from wine. In fact, they don't need to be DLLs. They could just put all their stuff in their own closed source file, compile it, and distribute the .o so that end users (their customers) can later take that .o file plus the LGPLd modifications to wine that make it use the functions in that .o, and link it into a newer version of wine.
I don't see why we should adapt our license to cater for people that make bad choices and suffer because of it. Especially when such a license might scare other people that might help us away.
Because people make mad choices every day and don't realize it. We cannot put our work on the line and say "Well, hopefully no one will make bad choices with it".
Now, the second issue, and the one Alexandre is (or maybe just was) most concerned about, was companies implementing functionality that the real wine does not have will sometimes reduce the incentive for a developer to work on it. That is to say that a good portion of developers that would otherwise be contributing to Wine making stuff work will stop if they can simply by Lindows for $100 and make that work.
Perhaps, but you will have to take the good with the bad and licenses preventing this also prevents other things.
Whether LGPL really does this or not is another question though.
Err, shouldn't have stopped reading here.. this goes with the next paragraph. I /don't/ want to stop lindows or TransGaming or CodeWeavers or anybody else from doing this. If we move to LGPL I really want it specifically stated that implementing functionality in seperate objects is okay to do.
Ironically moving to LGPL would actually make it easier for a wine developer to use some lindows functionality since they could update the rest of Wine. However, at least for me part of the reason I like hacking on Wine is to hack on wine to have a version that is free software. That is, let's say there had been a working closed source ASPI layer then I could've used my CD-R in Wine and maybe I wouldn't have fixed a bunch of stuff with ASPI. But doing that was a lot of fun and I would have been the one missing out by falling back to a lindows implementation and never considering actually fixing the real wine implementation. Plus in the meantime at least my CD-R would've worked so it would have been a less pressing issue and would have avoided numerous reboots for me in trying to create a free version.
Regardless of any fun you might have had. Ask this question:
Would you have consider it ethically or morally defendable if the Wine license had prevented you from using a proprietary ASPI library with Wine and distributing the result to your friends.
YES! That is my point. I would have done it anyway even if their was a proprietary version. And I think it is important that we allow people to use and distribute proprietary components with a free software Wine.
Anyway.. these are just two.. there are more I'm sure.. I really need to go to bed though.
Different time zones. I returned from a late breakfast to find your mail. :-)
Hmm, well, I suppose about the time I sent it I could've gone to an early breakfast since it was like 5am. What was it, like noon or 1 where you are?
Before I do so, I would like to point you to the wxWindows website.
According to their short license summary they use LGPL but also allow you to distribute a binary linking with wxWindows included. That exception would not be appropriate for wine (in fact, it's like the main advantage for us to use the LGPL I think). However we could do a similar style thing and say: "We're LGPL but we specifically allow you to create stub functions in our library that call out to your proprietary component.
See my suggestion about the "MGPL" instead.
This is really the same thing as a clarified LGPL. It's not necessary to write from the ground up a new license, but if we need to take the LGPL and strike out certain sections and/or add to it then that is far better than writing a new license completely from scratch.
Hopefully we can get this resolved this time... It's looking promising given the few and far between somewhat clear posts and disregarding the ill-informed wanna-be-on-slashdot shit.
We will see. I'm neither optimistic nor pessimistic for the moment.
Well, I /hope/ we can get this resolved since we're talking about the same things. Your only real concern at this point seems to be that if we were to move to LGPL that some companies may not like it because it's complex. They can pay lawyers to figure it out for them. Why do you think lawyers make all the money anyway.
-Dave
On Sat, 9 Feb 2002, David Elliott wrote:
This is simply not true. This is very much Wine's problem. If I need some of Lindows's functionality to run my program but would still like to be able to hack on other parts of Wine then I, as a developer and user, am screwed.
Now hang on! Mind, I won't spend any money to find out, but what is lindows exactly? Did they undo all the dll separatrion and make a single monolithic static-linked executable, or is it (stripped?) binaries lindows and linserver and a whole bunch of (stripped) "elf-pe" dll's and lindows-lib executables? If so, either they will interoperate with Wine, or we can make them do so, even if we have to add another entry to loadorder (builtin, so, lindows, native).
Ought to be easier to reverse engineer than native windows dlls, too.
Lawson
Things are never so bad that they can't get worse.
On 2002.02.09 19:36 lawson_whitney@juno.com wrote:
On Sat, 9 Feb 2002, David Elliott wrote:
This is simply not true. This is very much Wine's problem. If I need some of Lindows's functionality to run my program but would still like
to
be able to hack on other parts of Wine then I, as a developer and user,
am
screwed.
Now hang on! Mind, I won't spend any money to find out, but what is lindows exactly? Did they undo all the dll separatrion and make a single monolithic static-linked executable, or is it (stripped?) binaries lindows and linserver and a whole bunch of (stripped) "elf-pe" dll's and lindows-lib executables? If so, either they will interoperate with Wine, or we can make them do so, even if we have to add another entry to loadorder (builtin, so, lindows, native).
While it is true that you can still work on the DLL as a whole if there aren't parts you need from Lindows it still means you can't work on other functionality in the same DLL as one where you need at least part of the Lindows implementation.
Ought to be easier to reverse engineer than native windows dlls, too.
:-) Yeah, I bet you're right on that.
-Dave
-
David Elliott -
lawson_whitney＠juno.com -
Patrik Stridvall