It was in our July issue, if you recall, that I announced the Kent Porter Scholarship for college students working toward degrees in computer science. Now that the school year is underway, I'm honored to award scholarships (in the amount of $500 each) to the following individuals:
Congratulations to each and every one. Those of us at DDJ are glad to play at least a small part in helping you realize your goals.
I'd also like to once again thank those of you who made contributions to the scholarship fund. And don't forget that because the program is on-going, we'll be awarding scholarships for the 1991-92 school year.
It's not often that I ask you to read a particular article, but this month is an exception. For goodness sakes, turn to page 64 and read, think about, and respond in some way to the article "Software Patents." If you write software, this analysis may be one of the most important articles you'll read for a long time to come.
Is the practice of patenting algorithms dangerous and, in the end, detrimental to the spirit of innovation in the software development process? Consider this recent phone call from a DDJ reader: The small software house where the caller worked had spent nearly a year developing an application for a client. The program did what it was supposed to do very well and the client accepted it. Upon examining the source code, however, one of the client's programmers ran across an algorithm he knew to be patented. Until that time, our caller had no knowledge of any existing patents on the algorithm. Furthermore, he said, he may very well have implemented several other patented algorithms -- he just doesn't know. The algorithm in question is widely implemented, as were others in the same program. In any event, the client is now requiring licenses on all patented algorithms before accepting the package. The caller would be more than willing to pay any necessary license fees, if he just knew which algorithms were patented and who owns those patents. The first question you might ask is, what would you do if you were in the caller's shoes? After you read the article, don't stop there. Tell us what you think about the subject. Let us know if you've had problems dealing with patented programming techniques such as that described above. Or, for that matter, tell us if you hold a software patent and why you think it is important to do so.
Incidentally, the September/October 1990 issue of American Heritage magazine includes a historical perspective on how we got into the patenting mess we're in today. The article, entitled "The Power of Patents" by Oliver E. Allen, paints a not-so-pretty picture, and you can easily draw parallels between the patent process in the Industrial Age in the first part of this century and what's going on today. For further study, the author recommends The United States Patent System: Legal and Economic Conflicts in American Patent History by Floyd L. Vaughn (University of Oklahoma Press, 1956) and America by Design by David F. Noble (Alfred A. Knopf, 1977).
Nearly two years ago, DDJ proposed the Rhealstone, a suite of benchmarks for evaluating real-time systems, authored by Robin Kar. (See "Rhealstone: A Real-Time Benchmarking Proposal," February 1989 and "Implementing the Rhealstone Real-Time Benchmark," April 1990.)
Our proposal was just that -- a proposal -- and we wanted others to evaluate, criticize, refine, and continue the dialogue. With this in mind, you might want to check out the article "Shootout at the RT Corral" by Bruce Koball and Alex Novickis in Embedded Systems Programming magazine (September 1990) where the authors analyze and polish the Rhealstone (and Hartstone) benchmarks.
Victor J. Duvanenko North Carolina State University
Raleigh, North Carolina
Theresa McMurray Stephen F. Austin State University
Nacogdoches, Texas
Mark S. Kessel University of Colorado/Boulder
Boulder, Colorado
James D. Marco State University of New York
Utica, New YorkSoftware Patents
Rhealstone Lives!