Later Xerox gave the AI Lab a newer, faster printer, one of the first laser printers. It was driven by proprietary software that ran in a separate dedicated computer, so we couldn’t add any of our favorite features. We could arrange to send a notification when a print job was sent to the dedicated computer, but not when the job was actually printed (and the delay was usually considerable). There was no way to find out when the job was actually printed; you could only guess. And no one was informed when there was a paper jam, so the printer often went for an hour without being fixed.
The system programmers at the AI Lab were capable of fixing such problems, probably as capable as the original authors of the program. Xerox was uninterested in fixing them, and chose to prevent us, so we were forced to accept the problems. They were never fixed.
Most good programmers have experienced this frustration. The bank could afford to solve the problem by writing a new program from scratch, but a typical user, no matter how skilled, can only give up.
Giving up causes psychosocial harm—to the spirit of self-reliance. It is demoralizing to live in a house that you cannot rearrange to suit your needs. It leads to resignation and discouragement, which can spread to affect other aspects of one’s life. People who feel this way are unhappy and do not do good work.
Imagine what it would be like if recipes were hoarded in the same fashion as software. You might say, “How do I change this recipe to take out the salt?” and the great chef would respond, “How dare you insult my recipe, the child of my brain and my palate, by trying to tamper with it? You don’t have the judgment to change my recipe and make it work right!”
“But my doctor says I’m not supposed to eat salt! What can I do? Will you take out the salt for me?”
“I would be glad to do that; my fee is only $50,000.” Since the owner has a monopoly on changes, the fee tends to be large. “However, right now I don’t have time. I am busy with a commission to design a new recipe for ship’s biscuit for the Navy Department. I might get around to you in about two years.”
The third level of material harm affects software development. Software development used to be an evolutionary process, where a person would take an existing program and rewrite parts of it for one new feature, and then another person would rewrite parts to add another feature; in some cases, this continued over a period of 20 years. Meanwhile, parts of the program would be “cannibalized” to form the beginnings of other programs.
The existence of owners prevents this kind of evolution, making it necessary to start from scratch when developing a program. It also prevents new practitioners from studying existing programs to learn useful techniques or even how large programs can be structured.
Owners also obstruct education. I have met bright students in computer science who have never seen the source code of a large program. They may be good at writing small programs, but they can’t begin to learn the different skills of writing large ones if they can’t see how others have done it.
In any intellectual field, one can reach greater heights by standing on the shoulders of others. But that is no longer generally allowed in the software field—you can only stand on the shoulders of the other people
The associated psychosocial harm affects the spirit of scientific cooperation, which used to be so strong that scientists would cooperate even when their countries were at war. In this spirit, Japanese oceanographers abandoning their lab on an island in the Pacific carefully preserved their work for the invading U.S. Marines, and left a note asking them to take good care of it.
Conflict for profit has destroyed what international conflict spared. Nowadays scientists in many fields don’t publish enough in their papers to enable others to replicate the experiment. They publish only enough to let readers marvel at how much they were able to do. This is certainly true in computer science, where the source code for the programs reported on is usually secret.
I have been discussing the effects of preventing people from copying, changing, and building on a program. I have not specified how this obstruction is carried out, because that doesn’t affect the conclusion. Whether it is done by copy protection, or copyright, or licenses, or encryption, or ROM cards, or hardware serial numbers, if it
Users do consider some of these methods more obnoxious than others. I suggest that the methods most hated are those that accomplish their objective.
I have shown how ownership of a program—the power to restrict changing or copying it—is obstructive. Its negative effects are widespread and important. It follows that society shouldn’t have owners for programs.