On 2002.02.09 18:31 Brett Glass wrote:
At 04:06 PM 2/9/2002, David Elliott wrote:
Yes, the purpose of LGPL is to force proprietary components to be in
seperate relinkable object files.
I wouldn't call this its "purpose," just one of its many requirements. The purpose of the FSF is to eliminate all commercial software and compromise programmers' livelihoods (as Stallman specifically writes in many places, including his "GNU Manifesto").
Really???? The FSF's purpose is to elimnate all proprietary software???? Who'da thunk it? Is there someone who doesn't know this.. it's written all over the website.. jesus, you act like it's some big secret.
The only symbols you'll have to export from these proprietary
[Snip]
Not proprietary, but commercial.
No, proprietary. You can both sell and develop free software as a commercial entity. End of discussion. Everything CodeWeavers has put into Wine is commercial, but it is not proprietary.
I see you seemed to concede my point that you only need show the symbols you are exporting.
And don't be concerned about looking at LGPL code either. I too develop
proprietary software and I develop some of that software using free (LGPL) libraries. There is nothing preventing me from looking at the source to these libraries I am using.
Yes, there is. If you write anything like it -- ever -- the owner of the copyright on the code you have perused can claim that what you wrote is a derivative work and demand that you forfeit all rewards from it. This is one of the many hidden "booby traps" in the GPL and LGPL.
This is classic FUD. Fits the definition perfectly. Fear, Uncertainty, and Doubt.
As the licenses' viral spread has continued, the FSF and other zealots have gradually gotten bolder and bolder. While they have not played this card yet, they can -- and will -- if they see it as being to their advantage in their war against commercial software developers everywhere.
The FSFs purpose and goals are irrelevant. The Wine developers purpose and goals are what is relevant.
I see you are clearly interested in not helping Wine, but instead making sure that Wine stays both free software and free for you to fold into proprietary products.
-Dave
At 07:31 PM 2/9/2002, David Elliott wrote:
No, proprietary. You can both sell and develop free software as a commercial entity.
You can sell *discs* on which there are copies of GPLed software for money. You cannot license GPLed software for money, however. The license prohibits this. Again: while the plastic disc can be a commercial product, GPLed software cannot be commercial.
I see you seemed to concede my point that you only need show the symbols you are exporting.
Not so. Object files also contain other information, including symbolic information for debuggers and other information that makes the code not only easier to link but easier to disassemble.
This is classic FUD. Fits the definition perfectly. Fear, Uncertainty, and Doubt.
What I'm saying is not FUD at all. It is simply true according to the basic principles of copyright law. It's been affirmed by several lawyers we've consulted. No programmer who writes commercial software can look at GPLed code without creating huge risks for himself and his organization.
But while we're on the subject of FUD: One of the FSF's primary ways of advancing its agenda is by spreading FUD.
One of its most common scare tactics is to claim that anyone who uses publicly available code in a program for which he or she does not reveal code is "taking it private" or "closing" it. This is complete FUD, since the original source is still available.
The FSFs purpose and goals are irrelevant.
They are quite relevant. Jeremy White said, in an earlier message, that he had consulted with Eben Moglen, the FSF's attorney. Moglen's goal is not to help the WINE project but to advance the FSF's agenda even if it hurts the WINE project.
The Wine developers purpose and goals are what is relevant.
Both are relevant. If they adopt the FSF's license, the WINE developers will be advancing the FSF's agenda at their own expense.
I see you are clearly interested in not helping Wine, but instead making sure that Wine stays both free software
It is important for it to be truly free software, not "fake" free software (i.e. licensed under the FSF's licenses).
and free for you to fold into proprietary products.
I have no interest in folding WINE into any product of my own. However, I take an interest in this discussion because I would like to be able to recommend WINE to my clients and readers, to fix bugs in it, and perhaps to contribute to it. I will not be able to do any of these things if it is licensed under one of the FSF's licenses (or any other that is similarly discriminatory and viral).
--Brett Glass
This is the end of this discussion as far as I am concerned. I am not going to cry my eyes out if you don't recommend Wine because it may be LGPLed. And I'm getting really sick of fuelling Troll Wars 2002.
-Dave
On Sat, 9 Feb 2002, Brett Glass wrote:
At 07:31 PM 2/9/2002, David Elliott wrote:
[...]
The FSFs purpose and goals are irrelevant.
They are quite relevant. Jeremy White said, in an earlier message, that he had consulted with Eben Moglen, the FSF's attorney. Moglen's goal is not to help the WINE project but to advance the FSF's agenda even if it hurts the WINE project.
[...]
The Wine developers purpose and goals are what is relevant.
Both are relevant. If they adopt the FSF's license, the WINE developers will be advancing the FSF's agenda at their own expense.
As you yourself admitted you are not a Wine devlopper. You may pose yourself as a 'potential developper' to try to gain legitimacy, but the truth is you are nothing more than a third party, just like the FSF and Richard Stallman. This makes your comments no more relevant than those of any other third party, Richard Stallman and the FSF included.
Furthermore, it should be clear to anyone who has read your emails that you are on a personal crusade against Richard Stallman, the FSF and the *GPL licenses, and that you will post any propaganda that serves your purpose. Anyone reading your emails should keep this in mind as it is unclear that you do put Wine's best interests before those of your campaign.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ La terre est une bêta...
At 12:09 PM 2/10/2002, Francois Gouget wrote:
As you yourself admitted you are not a Wine devlopper. You may pose yourself as a 'potential developper' to try to gain legitimacy, but the truth is you are nothing more than a third party, just like the FSF and Richard Stallman. This makes your comments no more relevant than those of any other third party, Richard Stallman and the FSF included.
This is what's known as arguing ad hominem. The relevance of a comment does not depend upon who makes it.
--Brett Glass
On Sun, 10 Feb 2002, Brett Glass wrote:
At 12:09 PM 2/10/2002, Francois Gouget wrote:
As you yourself admitted you are not a Wine devlopper. You may pose yourself as a 'potential developper' to try to gain legitimacy, but the truth is you are nothing more than a third party, just like the FSF and Richard Stallman. This makes your comments no more relevant than those of any other third party, Richard Stallman and the FSF included.
This is what's known as arguing ad hominem. The relevance of a comment does not depend upon who makes it.
Wine developpers have all proved that they care enough about Wine to devote time to it. Some Wine users have proved that they care enough about Wine to take the time to report bugs or even to help developpers track them. In contrast, as you yourself admit, you never contributed to Wine in any way. So it is unclear whether you came here because you really care about Wine or because you are on a personal crusade against *GPL licenses and you just happened to see a headline on Slashdot that said 'WINE May Change To LGPL'. And since you start questioning other people's motives, including other third parties that have done nothing to influence people on this forum, it is only fair that your own motives be considered, and to recommend that people reading your emails assess them for themselves.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
At 02:07 PM 2/10/2002, Francois Gouget wrote:
Wine developpers have all proved that they care enough about Wine to devote time to it. Some Wine users have proved that they care enough about Wine to take the time to report bugs or even to help developpers track them.
And I care about WINE, too, for many reasons. I want it to do the maximum amount of good for the greatest possible number of users. I want to be able to contribute to it, fix bugs in it, and continue to advocate it (an important contribution that I have already been making).
Your last several messages have been personal attacks and are out of place in a rational discussion. If you care about the WINE project, don't attack someone who advocates it and has a strong desire to see it succeed and remain open source software.
--Brett
I'm a non-Wine developer but I've taken an interest in this debate since I could possibly work on it in a commerical way and would prefer to see it truly open for everyone.
Rather than debate GPL vs BSD license, first get a consensus on what the *goal* and purpose of a license would be. E.g., attracting commercial development, maintaining control, philosophical reasons, etc.
Forget the philosophical and semantic arguments over "free", "open", etc. if I was a member of the Wine group I would want to maintain control over it. Using a *GPL style license would seem to insure more control over the code, as opposed to a commercial third-party taking control and benefit from the work already done.
From what I've seen Wine is such a huge undertaking that there are still
large areas that are incomplete or in need of much improvement. That seems different than some of the more well known examples of BSD licensed projects that's cited as examples of doing fine with a BSD license. In other words, let's say Wine is "half-way" done (or more). Who would you want to complete it? Yourselves or companies that would not contribute their code back to the community?
Didn't the fragmentation of Unix come from several companies using a BSD or proprietary licensed codebase? That fragmentation hasn't been a problem with Linux since it was GPL from day one. So Linus and the community are still the ones with control and ownership of Linux, not any single company.
If several different *competing* companies take off with the existing Wine code it will without doubt fragment. In fact it seems like it already has. If there are several different proprietary Wines floating around without improvements and code available then the Wine group's leverage of being the "official source" would diminish in a way that Linux, GNU, KDE, etc have manged to maintain with the *GPL license.
jasonp San Diego, CA
At 04:10 PM 2/10/2002, jasonp wrote:
From what I've seen Wine is such a huge undertaking that there are still large areas that are incomplete or in need of much improvement. That seems different than some of the more well known examples of BSD licensed projects that's cited as examples of doing fine with a BSD license.
There are many projects using a BSD-style license, at every conceivable level of maturity. Such a license is not at all a hindrance to a project that's still incomplete; in fact, it can be a big help. Look at how much help Apache got from individuals and corporations in its early days -- and has continued to get from major players such as IBM today! WINE can only hope to be as successful.
In other words, let's say Wine is "half-way" done (or more). Who would you want to complete it?
Alas, WINE will probably never be "complete." Microsoft is sure to keep the Windows APIs a moving target, as it has since the release of Windows 3.1.
Yourselves or companies that would not contribute their code back to the community?
Why do you assume that companies will not contribute code back? The BSDs, Apache, and X11 have all received major contributions from companies. And these companies have all benefited from contributing, because the project maintains the code and they do not have to re-integrate patches with each new version.
Didn't the fragmentation of Unix come from several companies using a BSD or proprietary licensed codebase?
The greatest fragmentation of UNIX happened at the hands of AT&T itself. AT&T created System V in an attempt to wrest control of the UNIX standard back from BSD. It intentionally changed things just to make them different, not to make them better. Vendors who had been licensing UNIX from AT&T tried to find a way to bridge the old and the new, each adopting different portions of each "standard." This caused the "Tower of Babel" effect.
Fortunately, the fragmentation has since diminished. POSIX, the reincarnation of BSD as a family of complete operating systems, and the creation of tools which handle the minor differences between UNIX-like operating systems have spanned virtually all of the gaps. Nearly every open source program for UNIX (including very major apps like Sendmail, OpenSSH, etc.) now compiles under every UNIX-like OS.
That fragmentation hasn't been a problem with Linux since it was GPL from day one.
Actually, Linux is more fragmented than the rest of the UNIX world. This is due to the many, many vendors who are trying to differentiate their distributions from one another. The BSDs are far more compatible with one another, and with commercial UNIXes, than the many Linuxes (I think there are about 60 distros right now) are with one another or with other UNIX-like OSes. This shows that the GPL does nothing to prevent fragmentation and forking.
So Linus and the community are still the ones with control and ownership of Linux, not any single company.
Linus only controls the kernel, and only just barely. There have been splits between him and Alan Cox -- for example, during the recent controversy over the VM system. And several parties whose patches have been "dropped on the floor" due to Linus' limited bandwidth are now moving to create a fork that uses a "real" revision control system such as CVS. It's been said, though I haven't been following minute-by-minute developments, that Linus may finally capitulate and support the adoption of a revision control system, as the BSDs did many years ago. But if he doesn't, the kernel will fork.
The vendors of the 60 or so distributions control what users see when they install, and introduce major differences such as changes to the directory tree. This causes MUCH more fragmentation in Linux han there is in the BSD world. The BSDs share code, bug fixes, and refinements both in the kernels and in their "userlands" very freely. Even though they've diverged due to specialization, code for one will run on another with few, if any changes. And there is a movement toward a common API/ABI specification.... This was discussed with great enthusiasm at Usenix in Boston.
If several different *competing* companies take off with the existing Wine code it will without doubt fragment.
Not necessarily. It's doubtful that that there will be anywhere near as many vendor-specific WINE implementations as there are distributions of Linux. If the vendors are smart, they'll contribute back everything that isn't absolutely strategic. And even if they don't contribute a feature back, the group of core developers will implement it themselves if it's important enough. We've seen this work very well with the BSDs.
--Brett
On Sun, 10 Feb 2002, jasonp wrote: [...]
From what I've seen Wine is such a huge undertaking that there are still large areas that are incomplete or in need of much improvement. That seems different than some of the more well known examples of BSD licensed projects that's cited as examples of doing fine with a BSD license. In other words, let's say Wine is "half-way" done (or more). Who would you want to complete it? Yourselves or companies that would not contribute their code back to the community?
Didn't the fragmentation of Unix come from several companies using a BSD or proprietary licensed codebase? That fragmentation hasn't been a problem with Linux since it was GPL from day one. So Linus and the community are still the ones with control and ownership of Linux, not any single company.
If several different *competing* companies take off with the existing Wine code it will without doubt fragment. In fact it seems like it already has. If there are several different proprietary Wines floating around without improvements and code available then the Wine group's leverage of being the "official source" would diminish in a way that Linux, GNU, KDE, etc have manged to maintain with the *GPL license.
This is a very important point. So much so that it is worth expanding, even if it means repeating it somewhat.
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own. These are the rules of the game with BSD/X11 licenses and I see nothing morally wrong with them. But I believe that the results will be bad for Wine: * only companies that don't depend on Wine will return their code. Examples are Corel, Borland and other software vendors who released products based on Wine. They are few and far between. * other companies will keep their code to themselves, trying to lock users into their own version of Wine to insure future revenue, and this will cause the fragmentation of Wine. This has already happened: we have Lindows and to a certain extent CodeWeavers and Transgaming.
Fragmentation is not only bad because it causes duplication of work when the resources of the Wine community (companies included) are already limited. It also lowers the value of each of these Wine clones since they only handle a subset of the Windows applications. This is bad for the users too since it forces them to choose one or the other, or to buy Wine multiple times. For companies that want to deploy Wine on a series of computers the problem is compounded.
Switching Wine to the LGPL will not cause the fragmentation to disappear right away. But it puts in place a framework where each company can return its changes to the core Wine while being assured that the other companies will do the same. It garantees that they will benefit as much from the work of others as others benefit from their work. This makes it reasonable for them to share their modifications.
As Jason pointed out this effect of the *GPL licenses can be viewed very clearly in the Unix kernels.
The original Unix was under a license similar to the current Wine license (with some proprietary components). Each Unix vendor took the code and modified it, which is fine. But this resulted into multiple versions of Unix, each tied to a specific architecture, each locking users into a specific version of Unix. Had they cooperated, today's computing world would certainly be very different. But there was no incentive for them to cooperate, no framework that would foster trust.
Contrast this with the Linux kernel. The GPL which provides the framework of trust. As a result we see many companies working together on the kernel, both small like Connectiva and RedHat, and big long time competitors like IBM and SGI. The GPL did not prevent them from working on the kernel, and it provides them with a kernel which evolves at a higher rate than each of them could achieve separately and lets them offer better products to their clients.
There is still a lot of work to do to get Wine where we want it. Some dismiss Wine by saying it will never succeed because Windows is a moving target. I do not believe in this argument because what counts is whose APIs that are actually used by applications and this changes more slowly. Still Windows is evolving. Wine's shortcomings when it comes to COM and the InstallShield 6 installers is here to remind us of it. And no one can deny that Microsoft can put a lot of resources behind Windows.
This means it is important that all the Wine players work together rather going each their own way, each trying to complete Wine on their own. None of us have resources to match those of Microsoft, so separately we don't stand a chance. The LGPL can do for Wine what the GPL did for the Linux kernel: provide the framework of trust that allows all players, including companies, to work together towards a common goal.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
At 08:47 PM 2/10/2002, Francois Gouget wrote:
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own.
That's why they won't release everything. But that's OK. They still have an incentive to release absolutely as much as they can without forfeiting their competitive edge.
Switching Wine to the LGPL will not cause the fragmentation to disappear right away. But it puts in place a framework where each company can return its changes to the core Wine while being assured that the other companies will do the same.
And because the LGPL won't allow them to compete, they will either (a) use wrapper functions to circumvent the LGPL, or (b) leave the business altogether and stop contributing to WINE. In both cases, WINE loses.
--Brett
Brett Glass wrote:
At 08:47 PM 2/10/2002, Francois Gouget wrote:
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own.
That's why they won't release everything. But that's OK. They still have an incentive to release absolutely as much as they can without forfeiting their competitive edge.
I doubt they would release "absolutely as much as they can" because releasing *anything* can potentially forfeit a part of competitive advantage. I'm sure a CodeWeavers-like company that didn't have the ties to the community that CodeWeavers itself does, wouldn't hesitate to keep all of their code in house. (Lindows being a prime example.)
Let me explain that a bit. Having worked in a corporate programming environment for quite a while now I've had a chance to see how a lot of decisions get made. The absolute one thing that can kill a project is uncertainty. With a BSD type license you have a LOT of uncertainty. "If I release this code to [insert reason here], my competitors may take it to their advantage and give nothing back." They don't know. And, more often than not, a decision will be made favoring an option that has a lower level of uncertainty instead of a *potential* higher rate of return.
Think about it. You're a company like Lindows. You can:
a) keep all of your code in house. You can still merge in changes from the community (although it may take a bit of work) and there is no chance at all of potential competitors taking what you've done and using it against you. Or, you can, b) release parts of your code. Ok, so it helps the community, and helps you a bit in keeping things up to date and reducing duplication between you and the community. Of course, at the same time, someone can take those changes and do whatever they want with them, including compete against you, which could in the end, cost you a lot of money or even drive you out of buisness.
Basically, option (a) is the only case that you have a known quantity, for which you can plan the future. With (b) you can plan, hope and cross your fingers and all you get out of it is some extra code that you could have done in house anyway (albeit at a cost).
Switching Wine to the LGPL will not cause the fragmentation to disappear right away. But it puts in place a framework where each company can return its changes to the core Wine while being assured that the other companies will do the same.
And because the LGPL won't allow them to compete, they will either (a) use wrapper functions to circumvent the LGPL, or (b) leave the business altogether and stop contributing to WINE. In both cases, WINE loses.
Well, in case (a) WINE still wins (somewhat), because that means that someone could get part of their functionality and plug it in with other bits. It could take some work, but if, say, CodeWeavers and Transgaming both did this, you could concievably, make a patch that, if you paid for both, you could use both. Or perhaps even, Transgaming and CodeWeavers would get together and create such a patch because of user demand. I think that's a win, at least from the user perspective.
In (b), well, it doesn't matter. What would happen right now if Lindows droped off the map. All the work they did on WINE goes down the tubes, and no one benefits on either side. Great, Lindows made a quick buck off of WINE and contributed nothing in return. If WINE were (L)GPL, at least then the WINE project would have the fruits of their labours.
Just a few points.
Regards, Marcus Brubaker marcus.brubaker@utoronto.ca
On Mon, 11 Feb 2002 01:24:00 -0500, Marcus Brubaker marcus.brubaker@utoronto.ca wrote:
In (b), well, it doesn't matter. What would happen right now if Lindows droped off the map. All the work they did on WINE goes down the tubes, and no one benefits on either side. Great, Lindows made a quick buck off of WINE and contributed nothing in return. If WINE were (L)GPL, at least then the WINE project would have the fruits of their labours.
That is about what happened with the Corel effort. Corel has dropped off the map Linux and WINE-wise but the project benefitted from their temporary involvement.
john alvord
At 11:24 PM 2/10/2002, Marcus Brubaker wrote:
I doubt they would release "absolutely as much as they can" because releasing *anything* can potentially forfeit a part of competitive advantage.
Not true. There's always a cost/benefit analysis to be done. Since NOT contributing code incurs a heavy cost in manpower, and also (if it's a bug fix) reduces the public's confidence in WINE and derivatives of it, it really pays to do so unless the code is highly strategic. Witness what has happened in the BSD world.
Let me explain that a bit. Having worked in a corporate programming environment for quite a while now I've had a chance to see how a lot of decisions get made. The absolute one thing that can kill a project is uncertainty. With a BSD type license you have a LOT of uncertainty.
Not so. With a BSD license you have a simple license that says what it says and has been upheld in court. With an FSF license you have a huge document, with a long block of misleading propaganda at the top that could invalidate the whole thing (if the "recitals" in a contract are false or misleading, the entire contract is often invalid). The FSF licenses have NEVER been upheld or even fully interpreted by the courts. Want to talk about uncertainty? With one of the FSF's licenses, you truly do not know where you stand. Even if you ignore the fact that they're discriminatory (and discriminate against you as a programmer!), this should be sufficient reason to stay far, far away from these licenses.
--Brett Glass
On Wed, 13 Feb 2002, Brett Glass wrote:
At 11:24 PM 2/10/2002, Marcus Brubaker wrote:
I doubt they would release "absolutely as much as they can" because releasing *anything* can potentially forfeit a part of competitive advantage.
Not true. There's always a cost/benefit analysis to be done. Since NOT contributing code incurs a heavy cost in manpower, and also (if it's a bug fix) reduces the public's confidence in WINE and derivatives of it, it really pays to do so unless the code is highly strategic.
This is the crux of the issue. What if the business model relies upon retaining the IP-rights associated with the in-house written code? There the cost/benefit balance would be tipped towards non-disclosure.
Paul.
On Sun, 10 Feb 2002 19:47, Francois Gouget wrote:
On Sun, 10 Feb 2002, jasonp wrote: [...]
From what I've seen Wine is such a huge undertaking that there are still large areas that are incomplete or in need of much improvement. That seems different than some of the more well known examples of BSD licensed projects that's cited as examples of doing fine with a BSD license. In other words, let's say Wine is "half-way" done (or more). Who would you want to complete it? Yourselves or companies that would not contribute their code back to the community?
Didn't the fragmentation of Unix come from several companies using a BSD or proprietary licensed codebase? That fragmentation hasn't been a problem with Linux since it was GPL from day one. So Linus and the community are still the ones with control and ownership of Linux, not any single company.
If several different *competing* companies take off with the existing Wine code it will without doubt fragment. In fact it seems like it already has. If there are several different proprietary Wines floating around without improvements and code available then the Wine group's leverage of being the "official source" would diminish in a way that Linux, GNU, KDE, etc have manged to maintain with the *GPL license.
This is a very important point. So much so that it is worth expanding, even if it means repeating it somewhat.
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own. These are the rules of the game with BSD/X11 licenses and I see nothing morally wrong with them. But I believe that the results will be bad for Wine:
- only companies that don't depend on Wine will return their code.
Examples are Corel, Borland and other software vendors who released products based on Wine. They are few and far between.
This is a falsehood. Transgaming did not need to release their code. IBM did not need to release their code for Apache. BSDi did not need to release their code to FreeBSD.
- other companies will keep their code to themselves, trying to lock
users into their own version of Wine to insure future revenue, and this will cause the fragmentation of Wine. This has already happened: we have Lindows and to a certain extent CodeWeavers and Transgaming.
Fragmentation is not only bad because it causes duplication of work when the resources of the Wine community (companies included) are already limited. It also lowers the value of each of these Wine clones since they only handle a subset of the Windows applications. This is bad for the users too since it forces them to choose one or the other, or to buy Wine multiple times. For companies that want to deploy Wine on a series of computers the problem is compounded.
The duplication of work you mention does not really exist. Someone in the WINE community would have to write it anyway regardless of anything outside the WINE CVS tree.
Did you decide to stop writing code just because a closed-source version of code existed? If people thought this way, GCC would never have been written.
Switching Wine to the LGPL will not cause the fragmentation to disappear right away. But it puts in place a framework where each company can return its changes to the core Wine while being assured that the other companies will do the same. It garantees that they will benefit as much from the work of others as others benefit from their work. This makes it reasonable for them to share their modifications.
As Jason pointed out this effect of the *GPL licenses can be viewed very clearly in the Unix kernels.
The original Unix was under a license similar to the current Wine license (with some proprietary components). Each Unix vendor took the code and modified it, which is fine. But this resulted into multiple versions of Unix, each tied to a specific architecture, each locking users into a specific version of Unix. Had they cooperated, today's computing world would certainly be very different. But there was no incentive for them to cooperate, no framework that would foster trust.
As Brett pointed out, UNIX forked for other reasons (AT&T).
Contrast this with the Linux kernel. The GPL which provides the framework of trust. As a result we see many companies working together on the kernel, both small like Connectiva and RedHat, and big long time competitors like IBM and SGI. The GPL did not prevent them from working on the kernel, and it provides them with a kernel which evolves at a higher rate than each of them could achieve separately and lets them offer better products to their clients.
In this area, aren't IBM and SGI mainly hardware companies? Aren't AIX and IRIX operating systems written to sell the hardware?
There is still a lot of work to do to get Wine where we want it. Some dismiss Wine by saying it will never succeed because Windows is a moving target. I do not believe in this argument because what counts is whose APIs that are actually used by applications and this changes more slowly. Still Windows is evolving. Wine's shortcomings when it comes to COM and the InstallShield 6 installers is here to remind us of it. And no one can deny that Microsoft can put a lot of resources behind Windows.
The only comment I recall about this is Brett saying WINE will probably never match Windows 100%. It is very hard to match 100% a moving target.
Sean -------------- scf@farley.org PGP key: http://www.farley.org/~sean/pgp.key
On Mon, 11 Feb 2002 00:35:10 -0600 (CST), Sean Farley sean@farley.org wrote:
On Sun, 10 Feb 2002 19:47, Francois Gouget wrote:
On Sun, 10 Feb 2002, jasonp wrote: [...]
From what I've seen Wine is such a huge undertaking that there are still large areas that are incomplete or in need of much improvement. That seems different than some of the more well known examples of BSD licensed projects that's cited as examples of doing fine with a BSD license. In other words, let's say Wine is "half-way" done (or more). Who would you want to complete it? Yourselves or companies that would not contribute their code back to the community?
Didn't the fragmentation of Unix come from several companies using a BSD or proprietary licensed codebase? That fragmentation hasn't been a problem with Linux since it was GPL from day one. So Linus and the community are still the ones with control and ownership of Linux, not any single company.
If several different *competing* companies take off with the existing Wine code it will without doubt fragment. In fact it seems like it already has. If there are several different proprietary Wines floating around without improvements and code available then the Wine group's leverage of being the "official source" would diminish in a way that Linux, GNU, KDE, etc have manged to maintain with the *GPL license.
This is a very important point. So much so that it is worth expanding, even if it means repeating it somewhat.
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own. These are the rules of the game with BSD/X11 licenses and I see nothing morally wrong with them. But I believe that the results will be bad for Wine:
- only companies that don't depend on Wine will return their code.
Examples are Corel, Borland and other software vendors who released products based on Wine. They are few and far between.
This is a falsehood. Transgaming did not need to release their code. IBM did not need to release their code for Apache. BSDi did not need to release their code to FreeBSD.
At the time, I remember that IBM wanted to use the Apache code in products. The Apache group only agreed under the condition that IBM "paid" by giving back source code changes. That has led to a history of cooperation.
john alvord
On Monday 11 February 2002 5:25 pm, John Alvord wrote:
At the time, I remember that IBM wanted to use the Apache code in products. The Apache group only agreed under the condition that IBM "paid" by giving back source code changes. That has led to a history of cooperation.
IBM was already allowed to do what they have done without any negotiation with the Apache group - so why would either side wish to negotiate a more restrictive license for IBM than they have for every other entity on earth, including Microsoft?
James.
On Mon, 11 Feb 2002 17:52:07 +0000, James jas88@cam.ac.uk wrote:
On Monday 11 February 2002 5:25 pm, John Alvord wrote:
At the time, I remember that IBM wanted to use the Apache code in products. The Apache group only agreed under the condition that IBM "paid" by giving back source code changes. That has led to a history of cooperation.
IBM was already allowed to do what they have done without any negotiation with the Apache group - so why would either side wish to negotiate a more restrictive license for IBM than they have for every other entity on earth, including Microsoft?
Going only from memory, IBM wanted to get a license to use to code... a written license - the IBM lawyers insisted. Apache is a non-profit corporation and they didn't want to make give such a special license, not even for monetary consideration. After discussion, they agreed to give a written license on the condition that IBM contributed some Apache code which made NT operation much better performing. Since that initial lawyer-forced cooperation, things have been a lot more informal.
Just knowing the circumstances, I suspect the IBM programming guys used the situation as a club against their management to allow them to give the source changes to Apache. IBM hadn't done a lot of that in the past. Since then things have opened up quite a bit... you see big slabs of code coming from IBM Linux development into the Linux base code all the time. In one recent example, the RCU code (locking scheme) was covered by a patent owned by a company which IBM had bought. It took only a week for IBM to send a letter permitting use of the patented scheme to the developer and to Linus... to avoid any question of problem.
john alvord
john
Francois Gouget wrote:
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own. These
Isn't this the same principle problem for all open source projects?
Fragmentation is not only bad because it causes duplication of work when the resources of the Wine community (companies included) are already limited. It also lowers the value of each of these Wine clones since they only handle a subset of the Windows applications. This is bad for the users too since it forces them to choose one or the other, or to buy Wine multiple times. For companies that want to deploy Wine on a series of computers the problem is compounded.
What companies are developping for Wine? What is the gain for a company when selling wine? Wine is a windows emulator, so wine is a side product that allows windows programms to run on linux. This seems to me as if companies should be interested in returning code to wine because I think that for most comapnies it is not their goal to sell wine, it is their goal to increase their market for their own software and it is a good argument if sombody wants to buy some piece and you can tell him that you can run it on linux also because this company made sure it runs on wine. Are there actually companies selling wine as a single product?
higher rate than each of them could achieve separately and lets them offer better products to their clients.
That's the point and I think that this is also true for wine.
There is still a lot of work to do to get Wine where we want it. Some dismiss Wine by saying it will never succeed because Windows is a moving target. I do not believe in this argument because what counts is whose APIs that are actually used by applications and this changes more
I also don't think that Wine will never finished. Maybe we can't incorporate every single call, but we can implement so many calls that
90% of the applications will run. And if there are some strategically important applications like MS-SQL, Word, Office and such, then wine is a real alternative.
slowly. Still Windows is evolving. Wine's shortcomings when it comes to COM and the InstallShield 6 installers is here to remind us of it. And no one can deny that Microsoft can put a lot of resources behind Windows.
More then a big OS community? I doubt that. :)
Francois Gouget wrote:
Didn't the fragmentation of Unix come from several companies using a BSD or proprietary licensed codebase? That fragmentation hasn't been a problem with Linux since it was GPL from day one. So Linus and the community are still the ones with control and ownership of Linux, not any single company.
If several different *competing* companies take off with the existing Wine code it will without doubt fragment. In fact it seems like it already has. If there are several different proprietary Wines floating around without improvements and code available then the Wine group's leverage of being the "official source" would diminish in a way that Linux, GNU, KDE, etc have manged to maintain with the *GPL license.
This is a very important point. So much so that it is worth expanding, even if it means repeating it somewhat.
With the current license, if a company returns code to Wine it has no garantee that its competitors will do the same. Quite the opposite, it has all reasons to expect its competitors to take all that code, and put it in their products while not releasing any code of their own. ... Switching Wine to the LGPL will not cause the fragmentation to disappear right away. But it puts in place a framework where each company can return its changes to the core Wine while being assured that the other companies will do the same. It garantees that they will benefit as much from the work of others as others benefit from their work. This makes it reasonable for them to share their modifications.
As Jason pointed out this effect of the *GPL licenses can be viewed very clearly in the Unix kernels.
The original Unix was under a license similar to the current Wine license (with some proprietary components). Each Unix vendor took the code and modified it, which is fine. But this resulted into multiple versions of Unix, each tied to a specific architecture, each locking users into a specific version of Unix. Had they cooperated, today's computing world would certainly be very different. But there was no incentive for them to cooperate, no framework that would foster trust.
Contrast this with the Linux kernel. The GPL which provides the framework of trust. As a result we see many companies working together on the kernel, both small like Connectiva and RedHat, and big long time competitors like IBM and SGI. The GPL did not prevent them from working on the kernel, and it provides them with a kernel which evolves at a higher rate than each of them could achieve separately and lets them offer better products to their clients. ...
This means it is important that all the Wine players work together rather going each their own way, each trying to complete Wine on their own. None of us have resources to match those of Microsoft, so separately we don't stand a chance. The LGPL can do for Wine what the GPL did for the Linux kernel: provide the framework of trust that allows all players, including companies, to work together towards a common goal.
Hear, hear!
Francois describes the central issue well: the LGPL will provide a way for the vendors to trust each other.
Let those of us who understand this simply start releasing our Wine changes under the LGPL, regardless of what anyone else does. That should make it clear which way the main tree should go. - Dan
At 09:50 AM 2/11/2002, Dan Kegel wrote:
Francois describes the central issue well: the LGPL will provide a way for the vendors to trust each other.
No; the LGPL would provide a way for the vendors to sabotage one another -- and, most likely, ALL fail as businesses.
--Brett Glass
Brett Glass wrote:
At 09:50 AM 2/11/2002, Dan Kegel wrote:
Francois describes the central issue well: the LGPL will provide a way for the vendors to trust each other.
No; the LGPL would provide a way for the vendors to sabotage one another -- and, most likely, ALL fail as businesses.
Sabotage? Brett, you might be getting a bit carried away here.
IMHO the BSD vs. LGPL debate is a bit like those between members of opposing political parties. Reasonable people can disagree on these sorts of issues.
The LGPL will provide a way for service-oriented businesses like Codeweaver or Red Hat, who write code for others for a living, to thrive.
Intellectual-property-oriented businesses might not be so happy philosophically with the LGPL, but if you believe the arguments of Patrik and Roger from Dec 18th or so, which say the LGPL is powerless to prevent companies from linking in proprietary extensions, they ought to be able to cope.
- Dan
On Wednesday 13 February 2002 5:20 pm, Dan Kegel wrote:
The LGPL will provide a way for service-oriented businesses like Codeweaver or Red Hat, who write code for others for a living, to thrive.
Just as they can under the current license...
Intellectual-property-oriented businesses might not be so happy philosophically with the LGPL, but if you believe the arguments of Patrik and Roger from Dec 18th or so, which say the LGPL is powerless to prevent companies from linking in proprietary extensions, they ought to be able to cope.
So, two possibilities:
1. The LGPL allows companies to make proprietary changes and sell the result, just as they can now. i.e. no change, no point in changing...
2. The LGPL does prevent TransGaming, Corel and others using and contributing to Wine in the way they have been, and presumably deters others in future with similar ideas. Worse than the current situation: significantly harms Wine development.
With the exception of the original "I think Wine is being hurt by not using the LGPL, but can't say why", can anyone point to a real example of Wine losing out? Corel, Transgaming, Codeweavers and Lindows have all contributed to Wine; 3 of those 4, it seems, could/would not have done so under the LGPL. Does Wine gain ANYTHING from such a change? (Apart from protecting from theoretical threats which have never been sighted in real life, despite the number of other projects under similar licenses, that is!)
I don't buy much of Brett's conspiracy theory - AFAICS, neither RMS nor the FSF have any hand here - but equally, I can't see any reason to change a license which has, so far, benefitted Wine considerably. If it ain't broke, why try to "fix" it?
James.
At 10:20 AM 2/13/2002, Dan Kegel wrote:
No; the LGPL would provide a way for the vendors to sabotage one another -- and, most likely, ALL fail as businesses.
Sabotage? Brett, you might be getting a bit carried away here.
No, I'm not. Richard Stallman himself has stated that the purpose of the GPL's "poison pill" is to turn developers against their colleagues and the organizations for which they work. His writings even urge programmers to put GPLed code into the work they do for their employers for the express purpose of forcing them to give away the code!
The LGPL will provide a way for service-oriented businesses like Codeweaver or Red Hat, who write code for others for a living, to thrive.
No company that has adopted an FSF license for its main work product has EVER thrived. Even Red Hat has lost millions.
Intellectual-property-oriented businesses might not be so happy philosophically with the LGPL,
It's not just a philosophical problem. The FSF licenses are designed to destroy them, and have done a good job of it everywhere they've taken root.
but if you believe the arguments of Patrik and Roger from Dec 18th or so, which say the LGPL is powerless to prevent companies from linking in proprietary extensions, they ought to be able to cope.
It's not clear that the LGPL actually allows this. The FSF has rattled its saber and forced companies to back down on such strategies before.
--Brett Glass
No company that has adopted an FSF license for its main work product has EVER thrived. Even Red Hat has lost millions.
Actually, Cygnus has made good money for over 10 years doing GCC ports and paid support, and they're one of the reasons Red Hat was able to report a profit recently.
At 11:16 AM 2/13/2002, Ian Schmidt wrote:
Actually, Cygnus has made good money for over 10 years doing GCC ports and paid support, and they're one of the reasons Red Hat was able to report a profit recently.
Interesting that you should say that. Cygnus was privately held and so it's hard to figure out if it was proftable or not, but it was definitely not "greatly profitable." However, it's easy to do a back-of-the-envelope calculation based on its $20M in annual revenues and 180 employees (reported by Red Hat at the time of the acquisition). The cost of maintaining 180 employees in a technology company in the SF Bay Area is more than $18M annually. And this is not counting other costs of doing business. So, if the company was profitable at all, it was just squeaking through. (And $20M in annual revenues after ten years of existence is no one's idea of "good money" for a company that size.)
Bill Barr, a former Cygnus employee, recently posted the following to a mailing list:
The support model is marginally profitable, but far from lucrative. When I worked at Cygnus Solutions, the company had experienced some really tough years in the past and was trying to transition to a product model. It's much harder to sell support than it is to sell a box. Moreover, the overwhelming majority of revenues came from semi-conductor manufacturers and embedded systems shops, not the desktop/server software development community. Overall, trying to sell support for free software tools to software developers was pretty much a complete bust.
Mandrake, too, is losing money. According to its financial disclosure, as imperfectly translated by BabelFish:
Since its creation in November 1998 the company recorded losses. The cumulated amount of the overdrawn turnover of the group accounts between September 30, 1999 and 31 March 2001 amounted to 13,7 MEuros is approximately three times the amount of the turnover over the period. In spite of a strong progression envisaged of its turnover, MANDRAKESOFT considers a benefit only at the end of the exercise closed at June 30 2003....
Red Hat has had a couple of quarters in which it reported earnings of pennies per share, mainly due to accounting tricks. But it has lost millions over its lifetime.
--Brett Glass
On Wednesday 13 February 2002 01:28 pm, Brett Glass wrote:
business. So, if the company was profitable at all, it was just squeaking through. (And $20M in annual revenues after ten years of existence is no one's idea of "good money" for a company that size.)
Sure, but they did stay in business for 10 years and were in no reported danger of going out of it. Not bad by any metric for a license you can't make money off of ;-)
Anyway to steer back toward my point, can you name any pure-BSD/X11 players that are profitable?
See, I think there's a more basic problem, which is that no known business model works really well for source-available software when the software is targeted at technically savvy users. Things like the Aladdin license are a nice compromise, but ultimately won't lead to Microsoft levels of profitability.
The solution as I see it is for GPL/BSD/whatever programmers to actually cough up something non-technical users not only would use, but would *prefer*. *Then* support and selling binaries becomes a worthwhile proposition. Codeweavers is leaning in this direction with CrossOver - even though you could probably duplicate their work eventually with the current Wine CVS, the installer and overall ease of use make it well worth paying for if you value your time at all (I bought it and I love it, if you can't tell).
To put this back on topic, I don't see any immediate benefits from a LGPL license. If we knew what the threat to Wine Jeremy hinted at was, it might make for a more informed discussion. I also liked Gav's idea about WineCorp a lot as a compromise, and I'd love to see more dicussion of that and less licensing flaming.
At 11:52 AM 2/13/2002, Ian Schmidt wrote:
Anyway to steer back toward my point, can you name any pure-BSD/X11 players that are profitable?
The two most high profile ones I can think of are Wind River Systems and Whistle Communications (now part of IBM). Of course, neither gives/gave EVERYTHING away for free, but what they did (and, in the case of Wind River, do) give away was all BSD-licensed.
See, I think there's a more basic problem, which is that no known business model works really well for source-available software when the software is targeted at technically savvy users.
To put it more broadly, you can't make decent money without building up intellectual capital and insisting that people pay you to use your work. This is just basic business sense. This isn't to say that you can't give SOMETHING away, but you can't give away your strategic IP. The purpose of the GPL is to force companies to give away their strategic IP, and hence fail.
Things like the Aladdin license are a nice compromise,
The Aladdin license is an extreme. It is even more viral than the GPL in that it attempts to infect other products on the same disc.
To put this back on topic, I don't see any immediate benefits from a LGPL license. If we knew what the threat to Wine Jeremy hinted at was, it might make for a more informed discussion.
I keep wondering whether it involves investors. John Gilmore, an advocate of the GPL, is apparently a significant investor in CodeWeavers. Is he forcing their hand?
--Brett
On 2002.02.13 13:52 Ian Schmidt wrote:
[BIG SNIP]
To put this back on topic, I don't see any immediate benefits from a LGPL
license. If we knew what the threat to Wine Jeremy hinted at was, it might make for a more informed discussion. I also liked Gav's idea about WineCorp a lot as a compromise, and I'd love to see more dicussion of that and less licensing flaming.
Agreed. In my private mail to Alexandre I mentioned that we need some sort of "Wine Foundation". Apparently Gav has the same idea and at least one other person (you) seems to like it too.
Personally while I can't say if the LGPL would be absolutely wonderful for Wine I don't think it'd be horrible and thus I'll support whatever is chosen.
The main problem with LGPL is that once we go there we can never go back. Well, we can if all the people who made LGPL contributions agree to a license change, but unlike the last license change where this was possible because there wasn't anybody (to my knowledge) attached to the old license, there may very well be contributors to an LGPL codebase who would NOT want to release under X11.
Thus what we really need is some entity that will always have an unlimited license to the complete wine codebase to do with it as it decides. I question assigning copyrights away from myself and to anyone else, is there some reason why signing an unlimited use license wouldn't be acceptable (and thus developers would still retain their own copyright) or is that effectively how it works anyway?
Wine cannot stay X11 free-for-all forever. Reminds me of one of Roger Ebert's columns about the movie "It's a Wonderfull Life". Because the movie is now public domain, anyone can use the original print for whatever purpose. This includes colorizing it and then selling the colorized version for a lot of cash (thanks Ted... yeah right). The colorized version is a bastardization of the movie and is one of those cases where you almost wish that copyrights didn't expire. Especially considering that the director and the much of the cast were still alive to see this horrible, horrible thing. Wine is very much in the same position here. While we are not quite public domain we are so close that any distinction is a moot point.
However, the X11 license has the great advantage that it is extremely flexible. So flexible that anyone who wanted to could take the tree and release it under any other license. If we were to switch the tree to LGPL we would loose this advantage and would essentially be locked into terms that will always be at least as restrictive as the LGPL. If we were to set up some sort of Wine Foundation, or WineCorp as Gav calls it, then we could require contributors to license their code to WineCorp with unlimited rights knowing that WineCorp is established to act in the best interest of the Wine project. Perhaps a board could vote on whether to allow companies like TransGaming or Lindows to make a binary release and perhaps they could set conditions to the contracts. In order to get these types of licenses the companies would have to at least fork over some cash which would be used to cover the costs of running WineCorp. I would suggest that WineCorp be legally incorporated as a non-profit organization.
Looking at some of the more popular BSD-type licensed projects, many of them have this sort of non-profit set-up. Apache would be the one that springs to mind immediately, I'm sure there are others.
Anyway, I think I have written enough for now. I am really interested in discussing this, and I hope that by writing this I will have sparked some sort of discussion among the rest of the developers. I'm hoping the reason Gav didn't get very much response is more because everyone was waiting for the next guy to respond and not because no-one would be interested.
-Dave
At 06:48 PM 2/13/2002, David Elliott wrote:
The main problem with LGPL is that once we go there we can never go back.
I agree.
Wine cannot stay X11 free-for-all forever.
Why not? BSD has. X11 has. Apache has.
Reminds me of one of Roger Ebert's columns about the movie "It's a Wonderfull Life". Because the movie is now public domain, anyone can use the original print for whatever purpose. This includes colorizing it and then selling the colorized version for a lot of cash (thanks Ted... yeah right). The colorized version is a bastardization of the movie and is one of those cases where you almost wish that copyrights didn't expire. Especially considering that the director and the much of the cast were still alive to see this horrible, horrible thing.
I happen to agree, though I don't think it's "horrible" -- just weird. The best thing we can do is vote with our feet and not buy or rent that version. The same would be true of a bad commercial version of WINE.
However, the X11 license has the great advantage that it is extremely flexible. So flexible that anyone who wanted to could take the tree and release it under any other license.
Actually, no. You can't change the license on existing code. But you can combine it with code that's licensed differently.
Looking at some of the more popular BSD-type licensed projects, many of them have this sort of non-profit set-up. Apache would be the one that springs to mind immediately, I'm sure there are others.
FreeBSD and NetBSD do as well. But they administer the trademarks and handle contributions; they don't try to restrict access to the code.
--Brett
In article 20020213204809.A30749@biscuit.chronic, David Elliott dfe@tgwbd.org writes
On 2002.02.13 13:52 Ian Schmidt wrote:
[BIG SNIP]
To put this back on topic, I don't see any immediate benefits from a LGPL
license. If we knew what the threat to Wine Jeremy hinted at was, it might make for a more informed discussion. I also liked Gav's idea about WineCorp a lot as a compromise, and I'd love to see more dicussion of that and less licensing flaming.
Agreed. In my private mail to Alexandre I mentioned that we need some sort of "Wine Foundation". Apparently Gav has the same idea and at least one other person (you) seems to like it too.
I would really like _this_ part of the thread to continue too (*), with comments from Codeweavers, and some of the other wine heavies perhaps guiding 'us' with their insights.
Bob Hall (lurker :-) )
* (and other licence issues to be continued elsewhere, preferably off- list)
On Wed, Feb 13, 2002 at 10:56:52AM -0700, Brett Glass wrote:
At 10:20 AM 2/13/2002, Dan Kegel wrote:
No; the LGPL would provide a way for the vendors to sabotage one another -- and, most likely, ALL fail as businesses.
Sabotage? Brett, you might be getting a bit carried away here.
No, I'm not. Richard Stallman himself has stated that the purpose of the GPL's "poison pill" is to turn developers against their colleagues and the organizations for which they work. His writings even urge programmers to put GPLed code into the work they do for their employers for the express purpose of forcing them to give away the code!
You keep on making unsubstantiated claims like this.
Post some *exact* references (not quotes) to papers or transcriptions which support each of your points or I do not see how anyone on this list can continue to take you seriously.
Plato
(Do not CC me, please. I am on the list)
At 01:38 AM 2/14/2002, Plato wrote:
No, I'm not. Richard Stallman himself has stated that the purpose of the GPL's "poison pill" is to turn developers against their colleagues and the organizations for which they work. His writings even urge programmers to put GPLed code into the work they do for their employers for the express purpose of forcing them to give away the code!
You keep on making unsubstantiated claims like this.
You can find them as well as I can. Just go to Stallman's gnu.org site. However, because you seem to insist on having me do your research for you, Stallman actually says this in an essay called "What is Copyleft." Until January 1999, the version of the essay posted on the FSF site said the following:
People who write improvements in free software often work for companies or universities that would do almost anything to get money. A programmer may want to contribute her changes to the community, but her employer may 'see green' and insist on turning the changes into a commercial product.
When we explain to the employer that it is illegal to distribute the improved version except as free software, the employer usually decides to release it as free software rather than throw it away.
In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away.
Interestingly, in a case of almost Orwellian revisionism, Stallman removed the bit about "seeing green" from the version of the essay that's now published at http://www.gnu.org/copyleft/copyleft.html . He did this after I cited it on a public mailing list as an example of his strongly anti-business agenda. (However, the Web remembers: mirrors of the original text may be found throughout the Internet.) The revised essay still encourages programmers to incorporate GPLed code in their work as a way of "monkey wrenching" organizations, but it is now more subtle.
--Brett Glass
On Thu, Feb 14, 2002 at 10:41:05AM -0700, Brett Glass wrote:
At 01:38 AM 2/14/2002, Plato wrote:
[snip still unsubstantiated claim]
You keep on making unsubstantiated claims like this.
You can find them as well as I can. Just go to Stallman's gnu.org site. However, because you seem to insist on having me do your research for you, Stallman actually says this in an essay called
Well actually it's your research because they are your claims. Do you not know how debates work?
"What is Copyleft." Until January 1999, the version of the essay posted on the FSF site said the following:
People who write improvements in free software often work for companies or universities that would do almost anything to get money. A programmer may want to contribute her changes to the community, but her employer may 'see green' and insist on turning the changes into a commercial product.
When we explain to the employer that it is illegal to distribute the improved version except as free software, the employer usually decides to release it as free software rather than throw it away.
In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away.
No that is completely untrue. It is clear to me from reading this passage that Stallman is talking about modifications to code already GPLed. He is *not* referring to putting GPLed code into proprietary products.
Plato
*** N.B. PLEASE DO NOT CC ME ON REPLIES
At 10:58 AM 2/14/2002, Plato wrote:
No that is completely untrue. It is clear to me from reading this passage that Stallman is talking about modifications to code already GPLed.
Not true. Stallman specifically asks programmers to put the code in for the EXPRESS PURPOSE of forcing it to be given away.
Again, it would be a good idea for you to READ Stallman's essays (particularly the older versions, since some of the more recent ones have been toned down by his PR people even though his goals remain the same) before commenting.
--Brett
On Thu, Feb 14, 2002 at 11:18:20AM -0700, Brett Glass wrote:
At 10:58 AM 2/14/2002, Plato wrote:
[Snip easy to understand quote]
No that is completely untrue. It is clear to me from reading this passage that Stallman is talking about modifications to code already GPLed.
Not true. Stallman specifically asks programmers to put the code in for the EXPRESS PURPOSE of forcing it to be given away.
Don't be silly. He doesn't.
Again, it would be a good idea for you to READ Stallman's essays [...]
If you would attempt to win an argument, it would be a good idea that you post references rather than spouting the same rhetoric again and again.
I have had enough of listening to you and attempting to correct you. You seem determined to misrepresent someone or something whenever you speak.
I shall not waste any more of the Wine developers precious time by posting to the list.
You clearly have nothing useful to contribute. I recommend that everyone ignore you from now on.
I hope the Wine developers can keep up the good work whatever license they choose. I wish you well guys.
Goodbye,
Plato
P.S. For the last time, please do not reply to me directly: only to the list. PLEASE!
On 2002.02.14 15:25 Plato wrote: [BIG SNIP]
P.S. For the last time, please do not reply to me directly: only to the list. PLEASE!
Actually, the ettiquette on this list is to hit Reply All and thus post both directly to the people involved in the discussion and also to the mailing list.
Personally I prefer this, and I was actually about to write an e-mail to Brett bitching about him replying to one of my mails, twisting my words around, and sending it only to the list.
I filter the list based on the headers from the list server. So if the mail came through the list it goes into the wine-devel mailbox. However when you send a mail both to me and cced to the list I get two copies.. one in my normal inbox which I can read and reply to immediately, and one which is in with the rest of the stuff in the mailbox for the list.
There have been lots of discussions about this in the past, so please don't flame someone (even if he is a flamer in all senses of the word) for doing what everyone else on the list does.
-Dave
The longer I read your posts on this mailing list, the more I think you don't like Open Source or Free projects. You like commercial projects, with lawyers, profits and copy protection.
Why don't you say that Linux is a sabotage of HP,IBM, Microsoft,(non-exhaustive list) OS providers ?
Note that closed source programs are consuming time, employees,money... and are slowing the development.
_All_ the code that is not free is today forked somewhere in a vendor's program. Every company reinvents the wheel.
In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away.
If I were a the boss of an ecologic team, I would urge my colleagues to respect the nature... Wouldn't you ? :-)
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr
At 12:02 PM 2/14/2002, Sylvain Petreolle wrote:
The longer I read your posts on this mailing list, the more I think you don't like Open Source or Free projects.
Not true. I'm very much in favor of a truly free intellectual commons, and I'm very thankful for the existence of code such as BSD and Apache. But (L)GPLed code is neither open source nor "free." That the FSF says otherwise cannot change this fact.
You like commercial projects, with lawyers, profits and copy protection.
I do like some commercial products very much, and I like the companies that make them to make profits so that the products will continue to be improved. I like coding for a living, and I do not want the FSF and its licenses to succeed in its agenda, which consists of wiping out all commercial software and destroying decent jobs for programmers.
On the other hand, I strongly support the notions of fair use and the first sale doctrine, and I don't buy copy protected software.
As for lawyers: Hiring them is sometimes a necessary expense (for example, if you're negotiating a contract). But I wouldn't say that I "like" using them.
Why don't you say that Linux is a sabotage of HP,IBM, Microsoft,(non-exhaustive list) OS providers ?
Anything that's GPLed throws a "monkey wrench" into the relevant market, and (if it's any good) eventually destroys all competition. GCC is great example. It's a mediocre compiler, but notably *better* compilers -- the ones I need for some of the work I do -- are not selling.
GCC was one of the very first FSF projects. The others, as they progress, are beginning to have similar effects on the markets which they have invaded. The progression leads, inexorably, to the extinction of alternatives and the elimination of user choice.
Note that closed source programs are consuming time, employees,money... and are slowing the development.
I disagree.
In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away.
If I were a the boss of an ecologic team, I would urge my colleagues to respect the nature... Wouldn't you ? :-)
Yes. And the purpose of the GPL is to poison the well of truly free software that existed long before Stallman founded the FSF. That ecology was balanced. The GPL injects a "poison pill" designed to destroy the commercial players, destroying the delicate symbiosis between commercial and freely available software.
--Brett
--- Brett Glass brett@lariat.org a écrit : >
Not true. I'm very much in favor of a truly free intellectual commons, and I'm very thankful for the existence of code such as BSD and Apache. But (L)GPLed code is neither open source nor "free." That the FSF says otherwise cannot change this fact.
Would you say that Linux is not free ?
I do like some commercial products very much, and I like the companies that make them to make profits so that the products will continue to be improved. I like coding for a living, and I do not want the FSF and its licenses to succeed in its agenda, which consists of wiping out all commercial software and destroying decent jobs for programmers.
What could you say about Microsoft trying to destroy the concurrence ? For example Netscape ? A programmer can be paid even he makes free code. And these are other commercial ways : distribution & packaging services, on-line services... If you say that companies distributing free software are loosing money, look RedHat and consider : why is it not dead after years and years ?
On the other hand, I strongly support the notions of fair use and the first sale doctrine, and I don't buy copy protected software.
As for lawyers: Hiring them is sometimes a necessary
expense (for example, if you're negotiating a contract). But I wouldn't say that I "like" using them.
Anything that's GPLed throws a "monkey wrench" into the relevant market, and (if it's any good) eventually destroys all competition. GCC is great
example.
It's a mediocre compiler, but notably *better*
compilers
the ones I need for some of the work I do -- are not selling.
GCC was one of the very first FSF projects. The others, as they progress, are beginning to have similar effects on the markets which they have invaded. The progression leads, inexorably, to the extinction of alternatives and the elimination of user choice.
Note that closed sources are slowing development.
I disagree.
In this case, qualify the time Linux has taken to become as today. Windows took 20 years and so.
In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it
must
be given away.
Yes. And the purpose of the GPL is to poison the well of truly free software that existed long before Stallman founded the FSF. That ecology was balanced. The GPL injects a "poison pill" designed to destroy the commercial players, destroying the delicate symbiosis between commercial and freely available
software. It's not destruction, it's only the competition
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr
On Wed, 13 Feb 2002 09:20, Dan Kegel wrote:
Intellectual-property-oriented businesses might not be so happy philosophically with the LGPL, but if you believe the arguments of Patrik and Roger from Dec 18th or so, which say the LGPL is powerless to prevent companies from linking in proprietary extensions, they ought to be able to cope.
If this is true, why change the license? The proposal to change the license sited that the LGPL would prevent this. Since it does not appear that it can, there is no reason to change what is working just fine.
Sean -------------- scf@farley.org
Sean Farley wrote:
On Wed, 13 Feb 2002 09:20, Dan Kegel wrote:
Intellectual-property-oriented businesses might not be so happy philosophically with the LGPL, but if you believe the arguments of Patrik and Roger from Dec 18th or so, which say the LGPL is powerless to prevent companies from linking in proprietary extensions, they ought to be able to cope.
If this is true, why change the license? The proposal to change the license sited that the LGPL would prevent this. Since it does not appear that it can, there is no reason to change what is working just fine.
It may not matter too much how IP-oriented businesses feel about the issue, since (according to many prognosticators) the future is in services.
I feel quite certain the LGPL sets up a framework which will result in increased contributions to the Wine project, and maximizes the likelihood of a vibrant Wine community and happy Wine users.
- Dan
At 07:10 PM 2/13/2002, Dan Kegel wrote:
It may not matter too much how IP-oriented businesses feel about the issue, since (according to many prognosticators) the future is in services.
Wasn't this fallacy about as thoroughly debunked as possible by the dot.com bust?
--Brett Glass
Brett Glass wrote:
At 12:09 PM 2/10/2002, Francois Gouget wrote:
As you yourself admitted you are not a Wine devlopper. You may pose yourself as a 'potential developper' to try to gain legitimacy, but the truth is you are nothing more than a third party, just like the FSF and Richard Stallman. This makes your comments no more relevant than those of any other third party, Richard Stallman and the FSF included.
This is what's known as arguing ad hominem. The relevance of a comment does not depend upon who makes it.
--Brett Glass
Mr. Glass,
Your explaination of your concerns with viewing GPL code was excellent. Although I do not completely share those concerns, I understand them.
However, this comment clearly shows two things. First, you have used ad hominem attacks on RMS several times in this argument, making claims that have been refuted both here and by his own actions. In fact, the FSF itself sells software; they are not against commercialization of software, as you have claimed. Neither is Stallman. So your comment shows lack of understanding of yourself.
Secondly, this demonstrates you do not grok the dynamics of Free software projects. Of *course* degree of involvement in a project directly affects the validity of one's opinion concerning that project. My degree of involvement is essentially zero; yours is apparently less than that. Our opinions count for nothing, other than as interested third parties.
You have not just expressed an opinion; you have started (and fanned) a flame war concerning the validity of software licenses on a development list. I have contributed more than my share of flamage, so I too am guilty. Yes, you see your concerns as valid; from your philosophical and political bent, the *are* valid.
But, as a mere user of Wine, your concerns have devolved into browbeating. If you were an active developer, your opinions would carry more weight; after all, the developers are the ones putting huge effort into this project. *They* are the ones who should decide how their labor of love can and cannot be used. If they decided to take the code private and turn it into a commercial project, no-one can stop them. It is *their* work. And if they don't want parasites making money off their hard work, it is *their* perogotive, not yours or mine. If they want to release it to the public domain (the only truly free, unencumbered "license" out there), that is their perogotive. If they want to add a clause that says, "This code is usable by everyone but Tony and Brett," that is also their perogotive. After all, it is *their* work, and they have every right to decide how it is to be used.
You have made very good arguments. Let it stand, and abide their decision.
As for me: I apologize to the dev team for my contributions to this flame war. I will now go back to lurking, and using Wine. Thank you all for your work on Wine. This is a monumental piece of software, and you deserve the right to decide how it is used.
Sincerely, Tony
At 02:17 PM 2/10/2002, Anthony Taylor wrote:
Mr. Glass,
Your explaination of your concerns with viewing GPL code was excellent. Although I do not completely share those concerns, I understand them.
Thank you.
However, this comment clearly shows two things. First, you have used ad hominem attacks on RMS several times in this argument, making claims that have been refuted both here and by his own actions.
Actually, I have taken great pains only to repeat assertions that Stallman himself has made regarding his intentions and the design goals of the FSF's licenses. I am not attacking him; I am repeating faithfully what he himself has stated. If people mistake this for an attack, it is perhaps because they are incredulous; they find it hard to believe that his views could be so extreme! But anyone who knows him -- including some contributors to WINE such as Jeremy White -- can vouch for what I say: those really are his views and intentions.
In fact, the FSF itself sells software; they are not against commercialization of software, as you have claimed.
This is, alas, not quite true. The FSF sells CDs and tapes containing *copies* of software. The software itself is not licensed for money, and the FSF is vehemently opposed to any such practice.
The FSF has no problem with anyone being in the menial, commodity business of manufacturing plastic discs or magnetic tapes. But being in the business of developing software or other intellectual property and then licensing it for money is, according to Richard Stallman and Bradley Kuhn, "evil" and "wrong." (I've put the words in quotes, by the way, because they ARE quotes. They're the words that both men use in public forums.)
You have not just expressed an opinion; you have started (and fanned) a flame war concerning the validity of software licenses on a development list.
Since the developers will be making the decision regarding the licensing of the software they write, it's appropriate that there be a discussion about that here.
I agree wholeheartedly that such discussion shouldn't be a constant distraction or devolve into a "flame war." I have taken great pains to express my point of view very carefully and to make sure that nothing I've posted could be construed as "flamage." Alas, it is often true -- especially on Internet mailing lists -- that people who want to quash intelligent discussion will start to flame, hoping that the entire exchange will devolve into a flame war. By doing so, they hope to get others to call for an end to discussion. If they're successful, they can successfully silence the expression of views do not like. I'm not accusing you personally of doing this; you've challenged my assertions (which is fine!) but haven't been flaming. Some other messages aimed at me have been pure flames, though.
But, as a mere user of Wine, your concerns have devolved into browbeating. If you were an active developer, your opinions would carry more weight; after all, the developers are the ones putting huge effort into this project. *They* are the ones who should decide how their labor of love can and cannot be used.
I agree, as I have said above, that the developers have the right to make the decision. But because they are doing the entire project for the benefit of users as well as for themselves, they certainly should care about how users feel. What's more, if they are seeking bug fixes or help with development, they certainly should care how potential contributors feel. Finally, they should care about how advocates of the project feel. While advocacy does not expand the code base, it does expand the base of users and testers. Hence, it plays an important role in any collaborative software project.
You have made very good arguments. Let it stand, and abide their decision.
I am about to leave on a trip during which my connectivity will be limited, and so this will happen by itself shortly. But I did want to state the case for continued truly free licensing of WINE -- for the benefit not only of myself and other users and advocates but of the WINE project.
As for me: I apologize to the dev team for my contributions to this flame war. I will now go back to lurking, and using Wine. Thank you all for your work on Wine. This is a monumental piece of software, and you deserve the right to decide how it is used.
I agree. If anyone has considered any of my messages to be a "flame" rather than rational discussion, I apologize; nothing I've written was meant to be a "flame." I really do want to be able to continue to work with, advocate, and (hopefully) contribute to, WINE, and this has been the reason for the volume of passionate messages I've posted over the past few days.
--Brett Glass
-
Anthony Taylor -
Brett Glass -
Dan Kegel -
David Elliott -
Francois Gouget -
Gerhard W. Gruber -
Ian Schmidt -
James -
James A Sutherland -
jasonp -
John Alvord -
Marcus Brubaker -
Paul Millar -
Plato -
robert w hall -
Sean Farley -
Sean Farley -
Sylvain Petreolle