Subject: Re: free software as a delivery vehicle for lisp From: Erik Naggum <email@example.com> Date: Mon, 01 Apr 2002 20:29:19 GMT Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * David Golden <email@example.com> | Well, there's the rub - you have free software people defining | "commercial" and "free" to mean one thing, and proprietary software | people defining "commercial" and "free" to mean another thing. It'll | probably be a cold day in hell before the twain meet. Well, they are still talking about the same real world out there, so it might be worth one's while drop the emotionally laden terminology and talk about the things that they are intended to stand for. The political connotations are usually not worth dragging into a real discussion. | Well, this is true of competing against other open-source forked | projects, but not true of competing against anyone else who wants to make | a monetary profit - because Ghostscript is GPL. Thus, only Aladdin can | _sell_ alternate licenses to third parties who want to keep _their_ | product closed. Everyone else has to abide by the GPL (and thus make it | rather easy for aladdin to fold any changes back), or pay aladdin. This | is also why GPL projects are considered more "fork resistant" than most. The GPL only works well when the copyright to the modifications is transferred to the original source owner. Otherwise, all rights to the modifications not so transferred remain with their author, and may be sold for profit to a customers who applies them to his purchased product, or the right to use them by the original source owner may be retracted. The Luxcid/XEmacs fork from GNU Emacs was long considered a very serious problem and a cause of much duplication of effort and "competition" of the same stupid kind we find in the proprietary world. That happened well within the GPL. When you make some changes that the original source owner does not want, what do you do? This actually leads me to a different line of questioning the free sofrware movement: What do you do with the bad guys? Considering that bad guys run the world, being able to control them is important, and that means controlling the ability of various people to contribute "patches". In order to keep a lid on this, people are asked to provide patches for free, which may not be adopted, to a central repository where some dictator controls whether they will become official or not. Some people seem to like this, others do not. E.g., when the MULE crowd started to screw up Emacs so much it became impossible to use it, and they broke patches to fix their incompetent hacking again and again, several people left Eamcs development in disgust. I published a MultiByte Survival Kit, which got adopted by RedHat, that removed the most serious braindamage and let people use the _good_ new features Emacs 20. It took several releases before Emacs with MULE became usable. Various versions of the Linux kernel even in the supposedly "safe" 2.4 tree have been rotten and dangerous. The quality control that people expect from commercial software are simply not in place for free software -- if it has higher quality, it is a voluntary issue. Sometimes, that is not enough. | I personally think this is the fairest model - if someone else is trying | to use your work without monetary profit, then let them, if they try to | profit by closing their derived work and not making their extensions | available, then you get a cut. That's one of the things a dual | GPL/proprietary license scheme gets you. How does this actually work in practice? You only get paid for those patches that are accepted, right? Most real programming involves many non-working attempts, for which people get paid when they are employed or under contract. Having to work a lot only to see your successful patch ignored is a very strong de-motivator for future work. Therefore, a project leader feels morally obliged to include an offered patch. This is bad. If people could be paid for the work regardless, this would not be such a disincentive. | See also Trolltech (unfortunate name), makers of the Qt toolkit. Nah, a troll is a usually powerful mythological create in Norwegian folk lore. They are not particularly _nice_, but nothing like what we have on USENET, where "a troll" is a back-formation from the verb "to troll", for which Norwegian has a long "aw" sound, not a short. It is unfortunate that English lacks this distinction. :) | That's an interesting idea - except of course that the distinction | between "user" and "hacker" is, in general, rather blurred. This might be the crux of the contention between the communities. | Effectively, who decides when a user becomes a hacker? Effectively, breaking the warranty seal. (Except that the "appliance" vendors have managed to chicken out of the whole warranty thing, so this has to be understood metaphorically and abstractly.) | We're in definite agreement there, all right. Good. :) /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.