Dear DDJ,
The League for Programming Freedom's article opposing software patents ("Software Patents," November 1990) rather intrigued me since I have recently applied for a patent on a new type of software, a new, more efficient method of displaying text. My partner and I went through the considerable effort and expense because we realized that only by securing patent protection did we have any chance of profiting in any way commensurate with our invention's potential value. If we were to release our program with only the copyright laws to protect our efforts, as soon as we had established its usefulness others with more financial resources would quickly rewrite our program using our unprotected concepts and push us out of the market. A potential licensee has almost said as much.
In the article there is no consideration of these benefits to the creator of a new concept. Is this of no value? You seem to want the creator to share with the world his ideas and allow all the money to go to the marketer and the financier. The patent has been for 200 years the only device which has enabled the lone inventor a chance of controlling the destiny of his invention and to profit from it. It was one of the keys to America's industrial strength and it is even more important in the "Information Age."
The article details many of the problems with searching patents and going through the patent process. I can agree fully with this part of your article and could add to it. It is a mess. But rather than do away with patent protection for software, you should be advocating improvement in the system. The system needs to be completely computerized and internationalized. Similar charges could also be made against the copyright system. Wasn't it George Harrison who inadvertently rewrote someone else's song and had to pay damages? At least the patents are available and can be checked -- try that for copyright! Should you not also then call for the elimination of copyrighting of software?
A letter affords little space to answer every charge made against software patents. However, I want to at least register my strong disagreement with almost everything in the article relating to the applicability of patents to software. It must have been written by a very good lawyer, for it is rare to find writing which sounds so reasonable yet so thoroughly obscures the truth. I am sure that the author could construct equally compelling arguments questioning the applicability of copyright law to software as well. And probably has! A full explanation of why patent law is applicable to some software is beyond the scope of this letter, but the short version, as I understand it, is the following: When a program is entered into a computer, switches may be a "new and useful device," and thus the Constitution guarantees its inventor patent protection over the whole or parts of his invention. Software had been thought not to be patentable in the US because of a case where someone had tried to patent an algorithm which had no specific usefulness. This misled many to think that all software was not patentable. The patentability of some software became established not because the Patent Office wanted to patent software (they already had plenty of work), but because the courts enforced the Constitution. Only an amendment will properly succeed.
Do I see no value in the activities of The League for Programming Freedom? No, it is certainly worthwhile to work against patents which should not have been granted because of prior art. And I agree that copyright protection should not be extended to include interfaces. (Patents are applicable for these.) But I hope that they will cease their efforts to end the patent protection guaranteed to creators wisely included in our Constitution.
Howard R. Davis III
Atlanta, Georgia
Dear DDJ,
The article "Software Patents" brought to mind something that happened a couple of years after I graduated (1953). The transistor was then the promising new technology that was to free us of our everyday drudgery. At the time, I heard that one of the largest electronics companies was trying to patent transistor versions of all of the commonly used vacuum tube circuits. I am under the impression that they did not succeed in getting the patents. In many respects, the situation was similar to the present software patent situation -- the patent office was not knowledgeable of the technology being used in the patent applications. It might be worthwhile for The League for Programming Freedom to look into what happened 35 years ago.
While getting a law passed may be a laudable endeavor, I think that The League could make more of an immediate impact by lessening the value of software patents that they feel are invalid. This could be done by publishing on an update basis a review of the existing and new software patents. This review could identify the standard algorithm (with references) that is described in the patent and give a workaround to avoid infringement. These reviews ideally should be in a database that could be referenced by standard algorithm name. This would give the poor soul who is accused of infringing someone's patent an immediate source of data to fight the action. It would also get into publication and the public domain (and thus make unpatentable) ways of getting around these software patents.
One more thing -- the author mentions (page 70) the possibility of the royalties exceeding the sale price of the software product. People who license patents do it to make money -- they have an interest in the licensee staying in business and making money. I really doubt that the situation of royalties exceeding the sale price would ever happen in real life.
David L. Spooner
Wilmington, Delaware
Dear DDJ,
If software engineers such as Andy P. Bender (Letters, June 1991) want more respect, they had better get real! Comparing putting code in a buffer for money to neurosurgery is the height of hubris. And to believe that a standard university curriculum produces better-qualified people than experience is silly. Universities usually select better people to start with, but they seldom improve them much. Equating "incompetent" to "learned-it-on-the-job" is an insult to the pioneers, including Mitch Kapor, whom he quotes.
As far as "requiring...licensure [sic]" is concerned, this is a state function for the protection of the public and was not meant to be a tool for gouging the public. The requirements should be on the product, not the person creating it. (In the case of such personal services as medicine, law, the ministry, and teaching, the person is the product. This is why they are professions.) For some years now it has been next to impossible to create new licensing for any field under either state or federal law. Life and casualty actuaries have been working on it for years with limited success. When they started, they had a long history of tough qualifying examinations for membership in their organizations.
Andy admits that he waxes sarcastic and implies that there are "standards" (legal ones?) on how the working drawings for construction are produced. Are there? If so, who enforces them?
The closest you are likely to come to so-called professionalization is private organizations of people in a "discipline" with entry requirements based on education, experience, examination, or publication in reviewed journals. For most, examination is the most appropriate, but, of course, for granting tenure to professors, publication is key. In any case, efforts in this direction have had little success. I don't normally use my CDP designation.
So that Andy will know where I am coming from, I have a science and mathematics background with degrees from major universities. I worked in insurance for many years with experience in data processing, actuarial, accounting, and general management. Many of the languages I know and computers I have programmed for came along after I had already "been in this business for twenty years." Perhaps nobody could teach me anything, but I could certainly learn it. I will soon be 65 and am more up-to-date than most of the so-called professional MIS people I know.
I believe in sound techniques, but I think that standards are a bunch of crap. I believe in learning and in some (but certainly not all) education, but I think that certification and licensing are scams.
Harlow B. Staley
Northbrook, Illinois
Dear DDJ,
I am very interested in Ray Duncan's "Programmer's Bookshelf" column in your June 1991 issue. I was wondering if you could either supply me with the list of Yourdon's favorite software books or the information I need to get this list. I do agree that reading programming books can be dry and boring, so I was happy to read that someone like Yourdon would also recommend nonprogramming books.
Chamrong Chhut
McLean, Virginia
Editor's note: Contact Edward Yourdon's The American Programmer, 161 West 86 Street, Suite 9A, New York, NY 10024, or by phone at 212-769-9460.
Dear DDJ,
There were many minor points and assertions in John Derbyshire's letter ("The Mandarin Middle Management Conspiracy," September 1991) with which I might raise issue. However, having just reread his letter for the third time, I think all my reactions can be distilled into a single, concise comment: Amen, brother.
Kevin D. Weeks
Oak Ridge, Tennessee
Dear DDJ,
I read with interest Jeff Duntemann's "Structured Programming" column (June 1991), in which he discusses the UART registers.
On page 134, in the section "FIFO Control Register (FCR)," Jeff made a statement which puzzled me: "For DOS applications on fast machines they (buffered UART's) simply aren't necessary. (If they are, I suspect it means you don't know how to write a terse enough interrupt service routine.)"
We have developed an application for the PC (the "monitor") which uses the serial port to monitor and control the behavior of another computer system (the "remote") in real time. The remote and the monitor send data continuously to each other at 19,200 baud. Due to limitations in the remote, no flow control is used -- it sends data in a continuous stream in real time. The monitor is a 20-MHz 286 PC.
Our experience has been that a buffered UART is necessary to avoid loss of data coming into the monitor in this situation. The problem does not seem to be the efficiency of the ISR we wrote to service the incoming data (I wish it were, so we could correct it), but rather the efficiency (or proper design) of other software in the machine; specifically the BIOS routines which service the fixed disk and the keyboard interrupt.
As best we can tell, what happens is that the keyboard service and/or fixed disk software in some BIOS's disable interrupts just long enough to cause incoming data to occasionally be lost. We have found, for example, that AMI BIOS works fine (thousands of hours of experience), whereas Compaq loses data.
Please tell me if there is some subtle point I have missed, which would allow me to avoid data loss without having to use the buffered UART.
By the way, you might mention to your readers that the 16550AF is the chip they want, not the 16550. The 16550 is buffered, but the buffer does not work properly. This has been corrected in the 16550AF. This can be tested using Example 1.
port[base+2]:=7;
case port[base+2] and $c0 of
0: it's an 8250 or 16450
$80: it's a 16550 (bad buffer)
$c0: it's a 16550AF (buffer OK to use)
else who knows?
end;
Russ Ether
South Bend, Indiana
Dear DDJ,
The conversion routine presented in Don Morgan's "Decimal Fractional Conversion" (August 1991) can be improved significantly. Example 2 provides the same result in approximately 50 percent of the space. It is essentially sequential except for one conditional jump instruction. It avoids the penalty for clobbering the prefetch queue which is rather severe on the less powerful Intel CPUs for which the routine was designed. It may not be important but it preserves the BX and CX registers. It also corrects a harmless bug in the carry logic.
MOV DX,0001h
DigitLoop:
ADD AL,AL
DAA
XCHG AL,AH
ADC AL,AL
DAA
XCHG AL,AH
ADC DX,DX
JNC DigitLoop
SUB AX,5000h
SBB DX,-1
RET
A carry from a low byte into a high byte during addition could propagate. The ADC instruction has been designed to handle just such a situation. The convoluted carry logic used in the article works because a number added to itself will always yield an even number. A carry into an even number will never propagate but the INC instruction would not propagate it if it could occur.
To facilitate reentrancy, the calling routine should store the result. Otherwise, the revised code will produce identical results without the unwarranted complexity.
Berry Ratliff
Ann Arbor, Michigan
Copyright © 1991, Dr. Dobb's Journal