Path: gmd.de!Germany.EU.net!mcsun!uunet!europa.eng.gtefsd.com!emory! darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu! cis.ohio-state.edu!gnu.ai.mit.edu!rms From: r...@gnu.ai.mit.edu (Richard Stallman) Newsgroups: gnu.misc.discuss Subject: Why we decided to replace compress Date: 16 Apr 1993 00:33:26 -0400 Organization: GNUs Not Usenet Lines: 43 Sender: dae...@cis.ohio-state.edu Distribution: gnu Message-ID: <9304160433.AA07470@mole.gnu.ai.mit.edu> The LZW compression algorithm is covered by a patent owned by Unisys, and by another patent owned by IBM. If you distribute compress, either of these companies might decide to sue you tomorrow. Or perhaps they won't. The FSF does not want to put users in this sort of vulnerable situation. Our mission is to give users programs they can freely share. Which means, implicitly, that they can share without risk of being sued by IBM or Unisys. It took two years of looking to find a non-patented compression program that's comparable with compress. It happens to be better, technically, but that is a bonus. The important thing is that we are no longer vulnerable--at least from those particular patents. (One thing about patents is that you can *never* be sure you are safe.) We could have kept our heads in the sand and told ourselves, "We haven't been sued, so everything's ok." Then, if one day IBM or Unisys did threaten us (or threaten users, which would have a similar effect), it would have been too late to do anything. We could not have found a replacement program on short notice. The whole community would have been in a jam. Instead, we took warning from threats stated to others, such as the POSIX standards committee, and found an alternative *before* the problem happened. I'm not surprised patent holders advise people to relax until they themselves are actually attacked. No sensible marauder wants potential victims to take precautions in advance. :-) We were lucky to find a way around this particular software patent. That leaves about 6000 other software patents buried who-knows-where, ready to explode if we step in the wrong place. You are walking around in the same minefield. Perhaps the code you wrote today does not infringe a patent--but what about tomorrow? So don't wait till you step on a patent yourself. Anticipate the problem, join the League for Programming Freedom, and help turn off the mines before any more people step on them. Look in /doc/lpf on ftp.uu.net for files giving information, or send mail to l...@uunet.uu.net.
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net! zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!cis.ohio-state.edu! gnu.ai.mit.edu!rms From: r...@gnu.ai.mit.edu (Richard Stallman) Newsgroups: gnu.misc.discuss Subject: Why we decided to replace compress Date: 16 Apr 1993 01:09:38 -0400 Organization: GNUs Not Usenet Lines: 25 Sender: dae...@cis.ohio-state.edu Distribution: gnu Message-ID: <9304160509.AA07537@mole.gnu.ai.mit.edu> If the LZW patents did apply only to hardware implementations, they would not be software patents, and we would be safe using compress. However, Unisys sent a threatening letter to the POSIX standards committee when the committee considered specifying compress as part of the POSIX standard. The letter said anyone implementing the LZW compression algorithm in a POSIX system would have to pay Unisys. It was sent in 1990 or 1991. This threat clearly was mainly meant for software implementations. (Which would most likely be compress itself.) While someone might implement LZW compression in a POSIX system using special-purpose hardware, this wasn't likely to happen often. If Unisys officially said at some point that it would exempt software implementations and demand royalties only for special-purpose hardware, then perhaps this could be held against them in court. But that still leaves the IBM patent, which is a separate threat. There is no reason to think it applies only to hardware implementations; when I discussed it with IBM people (including Wegman, who is one of the patent applicants, and a lawyer), we took for granted that it applied to software implementations, and they never said anything to the contrary.