Programming Freedom - August 1992 - Number 5

Editor: Spike R. MacPhee (spiker@prep.ai.mit.edu)
Assistant Editor: Andy Oram (oram@hicomb.hi.com)

Reproduction of Programming Freedom via all electronic media is encouraged. To reproduce a signed article individually, please contact the author for permission.

Table of Contents

Heckel - Gabriel debate

The publicity flyer for my debate with Heckel read:

"Special Interest Group on Freedom, Privacy and Technology: A public forum co-sponsored by BMUG and CPSR/Berkeley, May 31.

Software patent proponent Paul Heckel goes head to head with Dr. Richard P. Gabriel, of the League for Programming Freedom to discuss the realities of software patents...

Paul Heckel, author of the book "The Elements of Friendly Software Design" (Sybex books, second edition, 1991) and owner of HyperRacks, Inc., pioneered the card and stack computer metaphor. He developed Zoomracks, which is recognized as a predecessor to HyperCard by Apple Computer (among others), who licensed his patents.

Dr. Richard P. Gabriel is Chief Technical Officer and principal founder of Lucid, Inc, a Unix software company specializing in object technology. He is a regular columnist for AI Expert. His research accomplishments include the first high-performance supercomputer Lisp system, the definition of the Common Lisp language, the Gabriel Benchmarks for measuring Lisp system performance, the design and implementation of Qlisp (the first compiler-based parallel Lisp implementation), assisted with the definition of the Common Lisp Object System (CLOS), and the architecture of Lucid's integrated programming environment."

I felt that he self-destructed again, and basically the whole crowd (only 20 people) ended up attacking him. He had two questions he couldn't respond to, neither of which I had heard before (I'll present the second as a statement, but it was in the form of a question at the debate):

1. what program, system, or technique did we get that we wouldn't have got without patents?
2. In other areas, the cost of patents is in the cost of parts. So, when I build a computer, I buy a chip and the cost of the licensed patent is included. If I use a lot of chips, then the patent's value is accurately reflected by the cost to me, and if the computer sells well, the added revenue (cost) accurately reflects the value of the patent. This can't happen with software, because if I use a patented technique for a small purpose and the patent-holder charges a percentage royalty, I get screwed because the cost of the patent to me is inaccurate with regard to its cost. And if the patent-holder charges a fixed price and I sell a lot of product with the patent, the value of the patent to the product with regard to its cost is inaccurate. This is a direct result of software patents being about ideas and not about property.

News: IBM and Microsoft cross-license

Apple and Quorum patents

The Macintosh system uses a simple compressed representation for regions (two-dimensional shapes). Fundamentally, a region is represented by a bitmap; the compression technique consists of run-length encoding first in the x-direction and then in the y-direction. It is possible to do boolean operations on compressed regions operating directly on the compressed form; this is faster than generating the full bitmap.

This representation is patented by Apple; the patent number is 4,622,545.

The result is to cause a problem for any Macintosh-compatible system. Applications contain actual regions represented in this format, and any method of executing the application correctly must infringe the patent.

So what have emulator-writers done? One company, Quorum, decided to handle stored regions in applications only approximately; they expand the region to a rectangle, ignoring its detailed shape. This seems to work well enough in practice--apparently most applications make little use of saved constant regions.

But this approximation method brings a vulnerability: Apple can develop applications that explicitly refuse to work if the system handles regions approximately. If important applications don't work at all, the emulator will be useless. Apple could even pressure other developers into doing this. Apple is known for placing obnoxious restrictions on its approved developers, and this particular imposition would not be out of character.

Meanwhile, Quorum uses another representation for regions, and another method for doing boolean operations. And Quorum is patenting this technique. Yesterday's underdog has become tomorrow's bully.

Because Quorum is a small company, it may respond to public disapproval. Two years ago a few LPF members convinced Solbourne to back down on an interface copyright claim. We may be able to convince Quorum to back down if we give them a response that is surprisingly strong.

So please write letters to the president of Quorum, deploring this patent and saying that if they sink to Apple's level then you will say the same bad things about them that you do about Apple.

Sheldon Breiner, President
Quorum Software Systems, Inc.
4700 Bohannon Drive, Suite 125
Menlo Park, CA 94025

Urge Quorum to give the patent to the public, or to adopt a non-aggression policy for it. (A non-aggression policy means they won't use the patent against you unless you use patents against them.)

Send a copy of your letter to a magazine that Quorum might advertise in, and mark this fact on the letter.

Status of the LPF Apple boycott

One of our members asked: Now that Apple is no longer pursuing a look-and-feel lawsuit, is the boycott over?
- David J. Camp (campfire!david@wupost.wustl.edu)

- cdh@prep.ai.mit.edu, LPF Secretary and Director

LPF position on latest in Apple vs. Microsoft/HP case

Recently, Judge Walker threw out most of Apple's complaints against Microsoft and HP. He cited concerns about overbroad monopoly as part of the reason.

This is definitely a step in the right direction, and a win for programmers' freedom, but it does not completely eliminate the danger from Apple--for several reasons:

• Not all of the lawsuit has been thrown out. A few of Apple's claims still remain to be decided.
• Part of the reason most claims were rejected was that Microsoft had signed a contract with Apple, years ago. In fact, the judge did not decide for certain that the features in Apple's list were uncopyrightable; he said that *either* they are uncopyrightable *or* Microsoft's license covers them. Only another trial will tell us which one it is!

* Apple may appeal the decision; we cannot regard any of it as final.

LPF publicity: Cons, media mentions, & volunteer efforts

May 31 Berkeley
Richard P. Gabriel debates Paul Heckel
Report by Gabriel in this issue.

June 1 Computerworld
Viewpoint column by rms (reprinted here).

karl@cs.umb.edu (Karl Berry) reports:

"Here's a small (tiny) thing I did. I got a typical questionnaire from Dartmouth, my alma mater, asking their alumni about directions for the future. I suggested they support the LPF's boycott of Apple, and join the LPF as an institutional member. (Since Dartmouth essentially requires each student buy a PC or Mac, and many buy Macs, their supporting the boycott might actually make Apple pay attention.) I also sent them the LPF position papers."

LPF's position on ATT/BSDI suit

People have asked why the LPF hasn't said anything about the lawsuit by USL (a subsidiary of AT&T) against the University of California at Berkeley and against BSDI.

The reason is because we don't yet know whether this lawsuit falls within the scope of concern of the LPF. This is because the USL allegations are vague. The crucial claim is that

27. This statement is likewise materially false and misleading in that, to the extent the BSDI "LICENSED PROGRAM" is (as BSDI claims) based upon Berkeley's Networking Release 2, it is in fact based upon, copied from or derived from AT&T's code, such that users of the BSDI program require a license from AT&T or its successor, USL.

This could be an allegation that actual code was copied, in which case the issue is not one of concern to the LPF. The LPF stands for the freedom to write software, but it is not opposed to owning individual programs that one has written, and this includes USL.

On the other hand, perhaps an interface copyright claim is lurking within "otherwise derived". Or USL could interpret it this way if other interpretations prove unfavorable. This would bring the case directly within the LPF's area of concern.

However, the case may fall into the area of programming freedom in a wider sense, as an example of using the power of money to harass. For several reasons, the actions of USL would be an abuse even if the allegation were true:

• NET2 is a collection of many different programs and parts of programs written by different people and institutions. While they work together, they are unrelated as regards authorship. To charge that NET2 as a single entity infringes some (unspecified) right is like pointing at a bookstore and saying that its entire contents are illegal because of unidentified books.
• USL has not even specified what sort of illegality they allege; they want BSDI to be judged as vaguely in the wrong, disregarding what sort of copying and distribution the law permits.
• USL originally sued BSDI, alleging misconduct by UCB, not by BSDI. At the time, UCB had received no word of complaint from USL about the releases of free software, which had begun in 1988. The release of NET2 took place about a year before the lawsuit against BSDI.
• UCB made assiduous efforts to avoid including any AT&T code in the NET2 release, and this included several attempts over a period of years to ask USL whether they regarded certain programs as in any way violating their copyrights or trade secrets. USL refused to answer.
• USL has sued the lawyers of BSDI and UCB, merely for raising objections to the questions that USL wanted Mike Karels to answer.

Also, the main focus of the LPF is on changing the legal system for software, not on individual cases, and it is not clear what change in the system we should advocate to solve these problems. This case does not suggest a need for changes in copyright or trade secret law for software because the defendants will probably win under existing law--provided they can manage to last until the case is decided.

LPF News: voicemail still down, due back soon

Chris Hofstader adds: "...I finally heard from ... Dictronics ... who purchased MessageNet. Previously MessageNet purchased VoiceTek. I, with the cooperative and patient assistance of Bill at Mail Boxes Etc., have spent much of the summer chasing corporate ownership of our phone number. We finally found a person with the authority to release the number to us.

NETel is setting up a system for us that will at first forward our calls to a different rented number. We will in the coming weeks purchase an answering system and put it in a stable home with a very inexpensive "incoming" only line attached.

This problem is finally solved... Bankruptcy and corporate takeovers are a complete hassle to trace through."

The number was and will be 617-243-4091. It is a voice-mail phone, so please leave your name and phone number or address, and your question or request, and our person will get back to you.

LPF bibliography & on-line index continues

[Two people have since volunteered to maintain this important resource. I included all of Mike's description to show how much work he has done on the index for the LPF. We thank you for your efforts, Mike.]

For the past few year and a half I have been maintaining two files for the League for Programming Freedom: a partial list of software patents and an online index to the League's hardcopy files. Other commitments (and the possibility that I will soon leave the Boston area) force me to delegate these tasks to someone else, and I am looking for volunteers to take over responsibility for one or both of the files. (One person doesn't necessarily have to manage both of them.)

I spend several hours every month going through new acquisitions which are placed in a file in 545 Technology Square (the FSF headquarters), deciding in which physical file folder to store them, and indexing them electronically. When I come across references to, or articles about, software patents or user interface copyrights, I place them in the electronic index as well and hunt them down if it's convenient. I often read or skim articles and patents so that I can provide a precis along with information about the title, author, and date of publication; this makes the index much more useful. When I update the files, I send diffs of the changes to a set of interested people.

I hope that someone will be willing to take over this responsibility, for at least two reasons. First, it is essential to keeping the League's extensive set of hardcopy files in order; without some organization and an index, they would be nearly useless (as they were before I started). Second, I would hate to see my significant investment of time go to waste if the present organization was allowed to fall before entropy.

If you'd like to look at the files, either to use them or because you are interested in possibly taking them over, you can find them for anonymous ftp in the directory mintaka.lcs.mit.edu:/mitlpf/ai, files index and patent-list.

Michael Ernst
mernst@theory.lcs.mit.edu

Another way to publicize the LPF

WOW what a response.... using a question instead of just a signature works far better for recruiting purposes. I have had this signature :

Frank P. Bresz  |PCD Simulators Department, Westinghouse Electric Corporation
fpb@ittc.wec.com|My opinions are mine, WEC pays big money for official opinions
uunet!ittc!fpb  |Member: League for Programming Freedom (LPF) | STOP Software |
+1 412 733 6749 |For more information on the 'LPF' send mail  |  Patents Now  |

I have already received 2 or 3 responses and at least 1 'Yep, looks like I better join', after sending the papers.

Just thought I would let the folks know that it really works and it is worth the few minutes it takes to do it.

[the signature publicity is also expanding; we now get 10 to 20 requests for info in a week stating that they "saw us in a .sig." - spiker]

LPF email lists - who and what they are for

This moderated mailing list:

league-activists@prep.ai.mit.edu

and its two sub-lists:

league-activists-boston@prep.ai.mit.edu league-activists-remote@prep.ai.mit.edu

These lists are filtered by a moderator to:

• insure this use;
• minimize the number of messages;
• remove items meant for the list's -request address;
• forward items that should have been sent to another list.

League-tactics@prep.ai.mit.edu is for discussion of LPF directions and is not moderated.

If you want to subscribe, change your eddress (email address), or be removed from either list, please use:

league-activists-request@prep.ai.mit.edu league-tactics-request@prep.ai.mit.edu

Viewpoint: Software Patents - Boom or Bane?

If you develop software, or even if you use software, software patents are a threat to your work.

Patents in software provide little benefit to society: past experience shows that many new algorithms were published and many new features tried out, in the absence of patents. The burden they impose is immense: every design decision now carries the risk of being sued for infringing a patent; most new techniques and features are off-limits for seventeen years. As Bank of America has learned, even the users of popular software packages can be sued.

When people first learn about the problem of software patents, their attention is often drawn to the absurd patents that cover techniques already widely known---such as "natural order recalculation" in spreadsheets.

Focusing on these examples can lead some people to ignore the rest of the problem. They are attracted to the position that the patent system is basically correct and needs only "reforms" to carry out its own rules properly. For example, they propose a data base of prior art for patent examiners to study. But how much good would this do? Let's consider an example.

In April 1991, software developer Ross Williams began publishing a series of data compression programs using new algorithms of his own devising. Their superior speed and compression quality soon attracted users.

The following September, use of these programs in the United States was halted by a newly issued patent, number 5,049,881. Dean Gibson and Mark Graybill had applied for the patent on June 18, 1990.

Under the current patent rules, the validity of the patent depends on whether there is "prior art": whether the basic idea was published before that date in 1990. Williams's publication in April 1991 came after that date, so it does not count.

Ghiora Drori, a student at the University of San Francisco, described a similar algorithm in 1988/9 in a class paper, but it was not published. This doesn't count either.

Reforms to make the patent system work "properly" would be no help here---because the patent would still exist. There is no prior art for it. It is not close to obvious, as the patent system interprets the term. (Like most patents, it is neither revolutionary nor trivial, but somewhere in between.) The fault is in the rules themselves, not their execution.

Between this and other data compression patents, it is now difficult to design any high-quality compression program that is unambiguously lawful---because it is not easy to tell just how far a given patent stretches.

In the US legal system, patents are intended as a bargain between society and individuals; society is supposed to gain through the disclosure of techniques that would otherwise never be available. It is clear that society has gained nothing by issuing patent number 5,049,881.

Under current rules, our ability to use Williams's programs depends on whether anyone happened to publish the same idea before April 1991. More fundamentally, it depends on when various people happened to have this idea. That is to say, it depends on luck. This system is good for promoting the practice of law rather than that of software.

Teaching the Patent Office to look at more of the existing prior art might prevent some outrageous mistakes. It will not cure the greater problem, which is the patenting of every new wrinkle in the use of computers, like the one that Williams and others independently developed.

This will turn software into a quagmire. Even an innovative program will use dozens of known techniques and features, and each is likely to be off limits if it is less than two decades old. Our ability to use each wrinkle will depend on luck, and if we are unlucky half the time, few programs will escape infringing a large number of patents. Navigating the maze of patents will be harder than writing software. As The Economist says, software patents are simply bad for business.

A reform substantial enough to solve this problem would have to eliminate nearly all software patents. Since the problem is grave, we should not wait to decide which handful do benefit society, if any. We should abolish them all without delay, and leave the tuning for later.

LPF Boutique: Materials Available from the League