Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker.mit.edu!ai-lab!life!burley From: burley@pogo.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.c++ Subject: Re: comp.lang.c++, rms, and software patents Message-ID: Date: 18 Dec 90 14:35:09 GMT References: <1990Dec15.161944.19970@actrix.gen.nz> Sender: news@ai.mit.edu Distribution: comp Organization: /home/fsf/burley/.organization Lines: 122 In-reply-to: Bruce.Hoult@bbs.actrix.gen.nz's message of 15 Dec 90 16:19:44 GMT In article <1990Dec15.161944.19970@actrix.gen.nz> Bruce.Hoult@bbs.actrix.gen.nz writes: As a matter of interest: to whom was this patent awarded? I don't know, and I do feel kind of bad even wasting bandwidth on what might just be a National-Enquirer type rumor. If anyone has some reasonably definitive info on "the include-file patent" rumors we keep seeing, please post it! Also, it seems to me that you've got things a little backwards. If someone sells you a knick-knack that uses a patented method (say: a non-jarring, zero effort hammer), then it is the manufacturer of the hammer that can be sued by the patent holder, not you as the customer, and certainly not someone who's house you built using the hammer. If I am correct in this then it is only the compiler vendor who is potentially liable, for including the offending technique (include files) in their product. Actually using the product is probably risk-free. You've got a very good point. Two observations: 1) The point with free software is that you're free to make copies of it, change and recompile it, and so on, for yourself, your friends, and so on. If, in the process of doing this, or even using the product, you in effect continue to reuse the patented technique, then I believe you could be in violation of the license agreement. For example, if you obtain X-windows, then MIT is forced to stop distributing it or must change it or must pay licensing fees on all copies distributed so far, then you, as a user, should not be affected unless you do something like: make a copy for a friend (especially for a fee); change it and distribute it as a new product, even within the confines of any X license, because now you're effectively creating a new product using a patented but unlicensed (by you) technology; take portions of it, including the patented technology, towards making your own program even if you don't distribute it; or read the code, see the backing-store hack created by MIT but patented by AT&T (without being aware of it), and reimplement it in your own application. 2) Unlike hammers, with software you expect (almost demand) new versions as bugs are fixed and such. Will you be happy if a new version of X (in my example) that fixes annoying bugs also ends up being a lot slower because MIT can't afford the licensing fees on a free product? Then, if you "add back" the patented technology to the bug-fixed version (or, equivalently, make the same bug fixes in your older version), I suspect the courts would see it as patent violation. The problem with "free" software violating patents is that, as far as I know, it's a whole new ball game. We don't have any idea, really, of how far the patent holders or the courts will go to impose and retrieve licensing fees. If it is true that free software that violates patents will somehow be "protected" by the courts in that they won't permit the plaintiff to reclaim licensing fees for copies made outside the direct distribution channels, and/or they won't permit the retroactive licensing fees to exceed some percentage (< 100%) of the prices charged for official distributions, and/or they won't permit the plaintiffs to go after people making "friendly" copies of the violating software, changing it for their own use, and so on, then the free software industry is well-poised to render many ridiculous software patents useless anyway. How? By simply "distributing" only one copy to a "friend" of everyone else's, and thus being liable for only that copy. Then everyone else can ftp or make tapes from that "friend", that person's "friends", and so on. The very existence of this possible scenario suggests that patent lawyers and the courts will see to it that "free" software will not get any, or even most, of these "breaks". The likely targets would first be distributors like the Free Software Foundation -- so, as rms predicts, expect that Project GNU, along with gcc, g++, and emacs, might effectively go away because patent-violation charges are (or might be) brought against them and the Foundation does not have the resources to resolve the potential problems. (Does the possible non-existence of g++ have any important to the comp.lang.c++ community? I'd think so, even though existing versions could be copied around, because C++ is an evolving language and the availability of a contemporary g++ probably keeps prices down on commercial compilers.) So, sure, as an individual user of a given version of a given free software package, you should be "safe" if you stay within the same bounds of usage pretty much imposed by proprietary software distributors (i.e. don't do anything with X in terms of copying, looking at/changing source, and so on that you couldn't legally do with, say, Lotus 1-2-3, Microsoft Excel, Aldus Pagemaker, and so on). But if you take advantage of the freedoms free software offers, there might indeed be a risk depending on how these silly patents are dealt with by the courts. Certainly, the original point that C++ users need to worry about include file patents holds, because in addition to the fact that C++ would, in effect, violate the patent by including the process of text-file inclusion as an unlicensed feature of the language, the issue is that most users of C++ (and C, of course) would be employing that licensed technology to build their own things, and I expect that since there's no way for anyone owning a patent holder on include files to retrieve licensing fees simply for the existence of C++ as a language, they'd have to go after anyone distributing a C++ compiler (actually the preprocessor) and perhaps anyone using the feature in building their own products. I think here there would be a case made for the distinction between using a product that incorporates a technique (the hammer scenario you mention; the X-with-backing-store scenario I mention) and directly using a technique provided for by another product to perform a process (the case with #include). The risk is that the courts, too, would see the distinction, and that as a result they'd permit retroactive licensing fees on anyone who ever used #include, Fortran's INCLUDE, and so on. Assuming that no-one can show "prior art" sufficiently to the courts' satisfaction (as appears to have happened with AT&T's backing-store patent), I know of no reason we should assume this risk is low: after all, if include files are really patentable, and have been patented, then we all legally owe a huge "debt of gratitude" (i.e. money) to the patent holder. The fact that we didn't know we'd have to "owe" it, and would have used an alternate techology if we had, is precisely why many of us find software patents so frightening as a concept. But without definitive information on include files, I guess all this speculation is not particularly useful. -- James Craig Burley, Software Craftsperson burley@ai.mit.edu