I was disappointed by the lack of quality in Richard Hsu’s "Viewpoint" ("Maintaining High Living Standards Through Innovation, Strong Patents," Oct. 1998, p. 27).
Hsu fails to mention what he believes are the strengths and weaknesses of patent systems, implying that strong patent systems are flawless. He attacks faceless groups of "critics" (who I guess is anybody wanting changes in patent legislation, good or bad).
Most important, his use of facts and data is outrageous. His key theme is "strong patents equal strong economies." This correlation is extremely difficult to establish. Three positive datapoints are not statistically significant (indeed, the significance levels for the hypothesis are not calculated).
I would also like to know how causation was established. Do strong patent systems cause economic growth? Do strong economies impose obscene patent controls?
I also found the article somewhat naive: Software patents were completely avoided.
Timothy D. Prime
Sunnyvale, CA
Richard Hsu makes a dubious argument for strong patents, even going so far as to claim that "those countries having the highest standard of living … also have, not coincidentally, the strongest patent systems." The problem is he never offers a convincing argument that this arrangement isn’t purely coincidental. Hsu seems to have some problems with causality here, especially since he doesn’t address the issue of nations with weak patent systems that nevertheless have high standards of living.
The entire concept of patents begins with the notion that people won’t do anything without being assured of monetary recompense—implying that the work itself must be intrinsically unrewarding. This is an extraordinarily behaviorist way to view the world. What’s more, it is difficult to reconcile such developments as Linux, C, Emacs, Apache, TCP/IP, the Web, email, and the Internet (and thousands of other freeware products) itself with the notion that people don’t create useful things unless guaranteed to receive money for their efforts. Many more motivators beside money are out there. Even if money were the most efficient one (which is not the case), I doubt most would agree it’s the best motivator. There are many others, including love, friendship, duty, intellectual curiosity, or sheer humanitarianism.
Justus Pendleton
Cambridge, MA
As a patent attorney, I am biased with Hsu’s opinion, nevertheless I found his points to be well-reasoned. The computer industry in particular has become somewhat suspect of the patent system (sometimes for good reason), but those who wish to do away with it altogether for software and computer technology are not always well advised regarding the issues. The system is certainly not perfect, but still (in my opinion) provides much more good than harm.
Thanks for a well-written article.
Greg Kirsch
Atlanta, Georgia
I run a consulting firm that does a fair amount of patent analysis support. One of my clients is a large SV patent law firm, and I support them in such areas as analysis of software patents and responses to "Office Actions."
I also have worked with them to help convince reticent programmers that patents are basically good, as opposed to "crippling innovation." In the case of one prospect we were able to create 17 patents based on their technology. Of course, now that they are going for venture capital, they tell everyone about their "foresight" in patenting their software!
Lyle P. Bickley
Mountain View, CA
Y2K vs. SSNs
I was struck by some evidently incorrect statements in the "Forum" letter by Eric Weiss (Sept. 1998, p. 24).
Weiss says that the foreseeable end of new Social Security numbers is a threat to the world. Since this problem affects only the U.S., which contains only a few percent of the world’s population, this is a strong overstatement. Other countries may have similar problems.
Weiss claims the SSN problem dwarfs the Y2K computer problem (and the problems of the Internet address system). Even if we ignore the point that the Y2K problem concerns all countries, this claim looks erroneous on two accounts, as follows.
As far as I can imagine, there are hardly any systems that deal with SSNs but not with dates. In contrast, many systems handle dates but have nothing to do with SSNs, and most are probably not built to run smoothly into the next millennium. It’s presented as one of the largest threats of Y2K, affecting embedded systems and computer hardware—and that people are not even aware of all the threatened systems, much less ready to take preventive action.
According to Weiss’s estimate, the U.S. government will run out of new SSNs around 2100. Thus, there is ample time to act, and I (more likely my great-grandchildren) will be surprised unless all significant information systems handling data about persons will not be thoroughly updated or completely replaced at least once in the meantime.
An optimist would suggest a further reason why a change in SSNs could be less expensive than Weiss fears. Namely, if software systems are built using better principles of software engineering than those from past decades, making such modifications should be relatively easy. If the principles of modularity and data hiding are strictly followed, only one or a few source modules will need changes to accommodate a different SSN format, no matter the total size of the software is.
Conversion of existing databases and data files will be a huge task. However, in some parts of the world, at least in the European Union, current legislation severely restricts the storage and use of SSNs in all kinds of files and registers, manual as well as computerized. Such restrictions, especially if they become more common in the next century, should decrease the volume of data that needs conversion.
Apart from the exaggerations, the warning given by Weiss is appropriate. One major factor already in the Y2K computer problem is that systems are often used far longer than their original designers imagined, although a service life over 100 years seems unlikely. Also, the SSN problem requires that U.S. (and any other affected countries) decide early enough on the exact format of the new identifiers, otherwise it is more difficult to anticipate the change. In the Y2K case, everybody already knew in principle what would come after 1999.
Markku Sakkinen
Jyvaskyla, Finland
What Else Separates Men from Women
I just read how "men and Women View Ethics" (Sept. 1998, p. 70). The article was certainly interesting, but (having taken several courses in women’s studies), I’m always a little worried when a study focuses solely on gender differences.
Experience shows that, in many cases, the differences along other axes may be just as great as those between women and men. The authors should have commented on the possibility of other important differences, such as social background, race, marrital status, and age.
Jakob Engblom
Uppsala, Sweden
Mosaic Timeline
While providing a history of browser development in "Who Won the Mosaic War?" (Oct. 1998, p. 13), Hal Berghel skips a piece of the timeline when he writes, "Andreessen went on to cofound Netscape Communications." The correct information would be that Andreessen went on to cofound Mosaic Communications, which, because of a dispute over the name with the University of Illinois, later changed its name to Netscape Communications.
Howard L. Funk
Katonah, NY
The ethnic cleansing in Bosnia involved some of the worst atrocities in the Western World since the Holocaust. To make even a metaphoric comparison between the humanitarian disasters of that war and the "battle" over an operating system for toasters and televisions shows a serious lack of perspective.
Communications should pull its head out of the digital sand.
John Rieman
Boulder, CO
Redundancy’s Design Value
Having studied civil enginneering and computer science at the undergraduate level, I would like to point out one very important difference between the two disciplines that Richard Gisselquist omitted in "Engineering in Software" ("Technical Opinion," Oct. 1998, p. 107). As a computer science student, I was constantly admonished to look for shortcuts and remove any redundancies. ACM even celebrates this concept with its "Most Convoluted C Program" contest. As a civil engineering student, I was constantly told to solve problems clearly and neatly, using established methodologies wherever possible, because "You might have to explain your design to a jury some day." Redundancy was essential.
Software companies release a new product and expect to send out bug fixes a few weeks later; it’s less expensive that way. Bridge engineers know their products have to work correctly the first time and every time. Flaws in testing must be repaired at any cost before a bridge is "released" to the public. Until software developers (and their managers) have to defend themselves in court, they will not truly embrace absolute product quality.
Joy Davis
Atlanta, GA
Double the Headaches
This note is in response to the News Track item "Canadian Hacker Headaches" (Nov. 1998, p. 7).
As a programmer for a large corporation, one of my duties is being a security coordinator responsible for ensuring proper licensing of PC software and compliance with PC security and "clean desk" policies within my organization.
The item states that Web hacking against Canadian companies has doubled. I do not agree with this statement. The statistics in the article said 300+ companies participated in the survey, 68% connected to the Internet in 1997, 95% connected to the Internet in 1998, 4% reported hacking attempts in 1997, and 8% reported hacking attempts in 1998. It’s true that the percentage of reported hacking attempts has doubled. But with the number of companies connected to the Internet increasing, actually almost tripled the number of reported hacking attempts (closer to 2.79 times). I believe the comment, "The jump was due in part to a major increase in the number of Canadian companies now connected to the Internet" plays down the significance of this problem. If the number was the same as 1997 with the only factor changing that more companies are connected to the Internet, then the new percentage would still be 4%. A jump to 8% shows a significant problem.
David Balok
Rochester, NY
Join the Discussion (0)
Become a Member or Sign In to Post a Comment