Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!ai-lab!life!burley From: burley@pogo.ai.mit.edu (Craig Burley) Newsgroups: comp.lang.c++ Subject: comp.lang.c++, rms, and software patents Message-ID: Date: 14 Dec 90 17:17:48 GMT Sender: news@ai.mit.edu Distribution: comp Organization: /home/fsf/burley/.organization Lines: 102 Some people are complaining about rms@ai.mit.edu posting stuff about LPF in this newsgroup. I don't remember the context of his postings well enough to be able to comment -- it does seem reasonable that postings not specifically related to c++ not be cross-posted here, though it might be that he is responding to queries from this newsgroup. However, it is important to note the following: if, indeed, a patent has been granted on the concept of include files (textual inclusion of a common file in more than one source files), then legally speaking, pretty much everyone currently writing C++ or C code must stop using #include until they work out a license agreement with the patent holder. In practical terms, you must all stop writing any code using #include right away, since almost all C or C++ programs of any consequence use #include -- for example, #include or it's C++ equivalent (#include ?). This applies even if you are using #include for your own projects on your own home computer and never intend to release them to anyone else. So it doesn't matter that you use #include only to compile something and then sell the finished product, without its own #include facility, any more than it would matter if you used someone else's patented technique for turning iron into gold and then just sold the gold without the implementation of the technique! Clearly, if #include requires a license, then C++ (and C) will have to be changed to incorporate a new mechanism that replaces most or all of the functional capabilities of #include without using textual inclusion: for example, module interface references as found in Fortran 90 and Ada. (The implications for the cpp phase are frightening to contemplate, even worse what it means for all the existing code out there!) And, I believe a patent lawyer will tell you, all your past uses of #include are subject to a retroactive licensing fee that, obviously, you will have little control over setting (since your use of the facility will already have been established as a matter of record, so you have no bargaining position except to further an expensive legal battle). Another issue of software patents relating to C++: if you write a program in C++ using either an optimizing compiler, someone else's class library, or both, and the combination of your code with those other elements produces a program that contains a patented algorithm, you must somehow recognize this (perhaps by perusing all the assembly code output by the compiler along with a list of all "software patents" currently granted, like the exclusive-OR cursor patent or backing-store-for-occluded-windows patent). It is possible you have violated the law without you, the compiler vendor, or the class- library vendor realizing it, because the combination of tools have "conspired" to come up with something somebody else has already patented. Does this make it fit the definition of "obvious"? Probably. Can you afford the time and expense to do this analysis for every piece of software you build and use or distribute? Probably not. Will this review solve the problem? Not for patents that are pending. Is it likely this might actually happen? Who knows? The state of the art is always advancing. Do you want to risk being sued and have to prove that the patent is "obvious" in court? Be my guest. Practically speaking, C++ doesn't offer that much more risk than C, except that class libraries hide details of implementation somewhat easier than C-style procedure libraries (especially with regard to inline code). And solving the problem would require far more than could be accomplished by changing C++, unlike the #include problem, which is fairly local to C++ and C. The OO-based system I'm envisioning for myself would fairly easily and naturally come up with things that I know are currently patented, without any one person being aware of or directly contributing to those particular patented techniques (backing store for windows being a prime candidate). But with C, you are fairly safe if you stick to standard libraries, and with C++, you are only somewhat less safe depending on your dependency on other people's libraries and your understanding of exactly how they are implemented. And, you probably never have to worry about having some agency break in to your home, seize your computer and software, and use it as evidence against you that you have violated somebody's patent. I mean, they'd have to show some reasonable proof to a judge, right? Couldn't happen. (Tell that to the various people who have had this happen to them because a bunch of federal agents decided they were hackers -- though it's not a comparable example, since the government decided hacking was an outright criminal activity, which is a view it is not likely to take of inadvertent patent violators.) My main point is that the loss of free use of #include is definitely a major issue in the C++ and C communities if it indeed happens, even if it turns out to be a legal threat met and vanquished by some wealthy organization or individual (AT&T? Sun? League for Programming Freedom?). Another issue is whether C++ increases the likelihood that these "extensions of our collective thoughts" called computers might come up with something on their own that gets us into trouble because its patented; this issue probably doesn't belong in comp.lang.c++ but in some other newsgroup. (Personally, I intend to never write and release software on my own as long as there are, in effect, patents on software. I write work for hire, since the client assumes responsibility for patent violation; and I am now writing code for the Free Software Foundation, since it will be contributed to them and released by them, so they will have to defend themselves (ourselves) against patent infringement suits; but there's lots more fun things I can think about doing than leaving myself open to being sued by somebody who owns a patent for something I, or my optimizing compiler, happened to find "patently" obvious! Anyone else out there releasing software, shareware, freeware, etc, on their own? Talk to a good lawyer lately? Why are you still doing it? I'll risk developing stuff for my own use and using it to develop software for hire and for FSF, because I really doubt anyone will take me to court for violating patents in my own code I run only at home -- at least for now. But I won't release any of this software except via other organizations like the FSF.) -- James Craig Burley, Software Craftsperson burley@ai.mit.edu