burley@pogo.ai.mit.edu (Craig Burley) (12/15/90)
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 <stdio.h> or it's C++ equivalent (#include <iostream.h>?). 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
Bruce.Hoult@bbs.actrix.gen.nz (12/16/90)
As a matter of interest: to whom was this patent awarded? 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. -- Bruce.Hoult@bbs.actrix.gen.nz Twisted pair: +64 4 772 116 BIX: brucehoult Last Resort: PO Box 4145 Wellington, NZ
henry@zoo.toronto.edu (Henry Spencer) (12/16/90)
In article <BURLEY.90Dec14121748@pogo.ai.mit.edu> burley@pogo.ai.mit.edu (Craig Burley) writes: >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... No, the languages can stay the same. Only the implementations would have to change. There is no reason not to use #include to signify invocation of the new mechanism. Indeed, ANSI C does not actually guarantee that, say, `#include <stdio.h>' is implemented by textual inclusion. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
burley@pogo.ai.mit.edu (Craig Burley) (12/18/90)
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.eduburley@pogo.ai.mit.edu (Craig Burley) (12/18/90)
In article <1990Dec15.235642.10008@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: In article <BURLEY.90Dec14121748@pogo.ai.mit.edu> burley@pogo.ai.mit.edu (Craig Burley) writes: >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... No, the languages can stay the same. Only the implementations would have to change. There is no reason not to use #include to signify invocation of the new mechanism. Indeed, ANSI C does not actually guarantee that, say, `#include <stdio.h>' is implemented by textual inclusion. Are you prepared to say that this is definitive legal opinion that: 1) "Tokenizing" preprocessors, as compared to text-substituting preprocessors (the standard allows for both, I believe), will not be viewed by the courts as effectively the same technique as covered by the patent? (After all, the #include mechanism still pulls in the file byte-by-byte; or are you talking about "precompiling" all #include files so what gets #include'd is a "precompiled" file, but never a text file?) 2) This (perhaps mythical) include-file patent covers only strict inclusion, byte-by-byte, of a text file? 3) Even given that the answers to the above two questions are YES, that retroactive licensing fees will not be levied against anyone who used text-substituting include technology in the past N years, which would include most of us? 4) Even given that the answer to #3 is YES, that we won't have to go to court to make it so, and spend lots of money in the process of defending ourselves? 5) Even given that the answer to #4 is YES, that corporations won't decide to avoid the risk in any case and make every programmer in their employ switch to Pascal, Ada, and/or Modula II/III (or whatever languages avoid the include-file paradigm) until viable alternatives to #include are widely incorporated in C (and Fortran 90 becomes widespread for Fortran users)? My point is not that you don't have a good point. You have an excellent one. What you state is almost exactly what should be truth. "Almost" because what SHOULD be truth is that patents on obvious things (like include) and "laws of nature" should never be allowed -- i.e. most software patents. The problem is, you aren't in charge of the Patent Office or the courts, and patent lawyers keep telling us that the best way for the industry to work out the issues regarding software patents is via a lot of long- lasting, hugely expensive court cases. Who wants to be the defendants in these cases? The line forms on the right...and might well "include" C/C++ compiler vendors and even people who've created great applications using C/C++ compilers because of "#include". Again, though, it is entirely speculative until somebody posts, say, a patent number for this (still mythical?) include patent. Then we all can go to a library (or wherever) and read it ourselves, and find out who owns it and maybe call them and find out what they're planning to do to enforce it. -- James Craig Burley, Software Craftsperson burley@ai.mit.edu
dwithers@ncratl.Atlanta.NCR.COM (Dave Witherspoon) (12/20/90)
In article <1990Dec15.235642.10008@zoo.toronto.edu>, henry@zoo.toronto.edu >(Henry Spencer) writes: > In article <BURLEY.90Dec14121748@pogo.ai.mit.edu> burley@pogo.ai.mit.edu >(Craig Burley) writes: > >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... > > No, the languages can stay the same. Only the implementations would have > to change. There is no reason not to use #include to signify invocation > of the new mechanism. Indeed, ANSI C does not actually guarantee that, say, > `#include <stdio.h>' is implemented by textual inclusion. My very limited understanding of patent law indicates that the essence of patents is that "... you cannot patent an idea, but only the expression of an idea". It took me about 3 days of pondering on this concept to get me to the point where I thought I knew the difference between patentable and unpatentable. Unfortunately, I have no skill in relating this new understanding to anybody else. -------------------------------David Witherspoon------------------------------- David.Witherspoon@Atlanta.NCR.COM | I'm working on the world's longest NCR E&M Atlanta: (404) 623-7713 | palindrome...I'm almost half-way MY OPINIONS...ALL MINE!!! | done.
tma@osc.COM (Tim Atkins) (12/27/90)
As a software engineer I find the concept of software patents quite laughable, especially for mere program fragments such as include files. In my opinion, patenting such a thing would be equivalent to patenting a method for extract square roots in mathematics. Last I heard, discoveries in the realm of basic knowledge are most certainly not patentable. As I understand it the courts have used this to cover almost all scientific discoveries as distinquished from technological applications of same which are patentable. Include files are very much a basic and even trivial software discovery. If they could be patented, then the retroactive gathering of fees that has been talked about would seem to me to fall into the domain of retroactive law. This is a legal situation where you can be punished today for doing what was not illegal when you did it. It is expressly forbidden by our legal system as I understand it. In short, to patent software techniques as opposed to programs and perhaps application types, would as surely choke the software industry to death as similar mechanisms would have halted all progress in the sciences. - Tim
burley@pogo.ai.mit.edu (Craig Burley) (12/28/90)
In article <4113@osc.COM> tma@osc.COM (Tim Atkins) writes:
As a software engineer I find the concept of software patents quite
laughable, especially for mere program fragments such as include files.
In my opinion, patenting such a thing would be equivalent to patenting
a method for extract square roots in mathematics. Last I heard, discoveries
in the realm of basic knowledge are most certainly not patentable. As I
understand it the courts have used this to cover almost all scientific
discoveries as distinquished from technological applications of same which
are patentable. Include files are very much a basic and even trivial software
discovery.
Agreed, except last you heard isn't the latest. Software patents do exist,
laws of nature now are patentable, and the patent office still (to my
knowledge) refuses to allow a Comp Sci degree-holder to handle patent
applications in the area of computers. I also remember hearing they allowed
a patent on a "faster" FFT (Fast Fourier Transform), which I gather is a
purely mathematical or algorithmic refinement of the FFT technique. What
if a smart optimizer built on Macsyma or Mathematica managed to come up with
the same technique? Then that optimizer (in other words, the _user_ of
that optimizer) probably would be liable for licensing fees. Note also that
mice, for example, are patented -- the "Harvard mouse", a genetically
engineer white mouse. Theoretically, this means that if you keep white
mice and do classic genetic engineering -- via breeding -- and happen
to come up with a genetically identical (within some level of tolerance
determined by the courts) mouse that seems useful enough to sell as
breeding stock, you would be in violation of the patent, apparently!
(Seriously, I assume that while the press talks about the patent being
on a mouse or its DNA, it really is on some process that produces a
particularly useful breed of mouse -- without preventing someone from
using a different process to produce the same result. But I might well
be wrong about this.)
If they could be patented, then the retroactive gathering of fees that has
been talked about would seem to me to fall into the domain of retroactive
law. This is a legal situation where you can be punished today for doing
what was not illegal when you did it. It is expressly forbidden by our
legal system as I understand it.
The constitution permits the patent system to exist. Retroactive gathering
of fees is part of that. Just ask Kodak -- $900 million is what they are
paying to Polaroid for violating the latter's patent, and when this judgement
was announced, Polaroid's stock _dropped_ -- because analysts had been
predicting a _larger_ judgement. That might be a case of knowingly violating
a patent -- as with the Ford intermittent windshield-wiper case -- but
the patent system itself, as far as I know, makes no distinction between
knowingly and unknowingly violating patents, although I expect the courts
might do so when setting licensing fees and/or punitive awards.
By the way, one of the funniest arguments against worrying about this issue
goes along the lines of "well, only the rich'll get sued -- if you don't have
a successful product, nobody's gonna sue you; if you do, then you have the
resources to deal with it"! What a laugh. How're you gonna find someone
to finance your potentially successful product when it becomes generally
recognized that unless you already have a huge buildup of "patent-violation
retroactive license fee" funds, you're taking a significant risk with a
rather unbounded level of damages -- and taking your investors with you?
Oh wow -- another great opportunity for insurance companies to soak us!
In short, to patent software techniques as opposed to programs and perhaps
application types, would as surely choke the software industry to death as
similar mechanisms would have halted all progress in the sciences.
Agreed, and you're right, it will. Preventing C++ programmers from using
#include files without their licensing the "technology", if it indeed does
happen, will prove to be simply the tip of the iceberg. I still haven't
seen anyone post anything "definitive" about whether such a patent really
exists, though, so I'm not losing any sleep over it!
And if you can come up with a definition of "programs and perhaps
application types" as opposed to "software techniques" that'll be useful,
please post it -- remember that the software industry is built
by taking yesterday's programs and applications and using them as today's
software techniques!
However, suppose several large companies such as AT&T, Borland, and so on,
patented all the obvious ways to implement C++'s features -- then greatly
increased the cost of their compilers, knowing that you couldn't legally
switch to using GNU C++ (because they'd sue the FSF out of existence for
violating their patents by distributing it under the GPL terms) or write
your own (unless you managed to find yet another obvious way to implement
C++ features -- in which case you'd better spend the bucks to patent THAT
before someone else does)!
Nothing in the current behavior of the Patent Office or the courts in
which these issues will be settled suggests that this scenario, or one
like it, is unlikely.
Now that software is patentable, in essence, there is no limit to the
number of things that can be trivially patented if one simply has the
money and time to go through the process. In so doing, much of what we
ordinarily do in creating software will become a tangled nightmare of
licensing restrictions. C++ is an excellent target in this arena.
So, I think, is Fortran 90.
--
James Craig Burley, Software Craftsperson burley@ai.mit.edu