Signing a typical software license agreement means betraying your neighbor: “I promise to deprive my neighbor of this program so that I can have a copy for myself.” People who make such choices feel internal psychological pressure to justify them, by downgrading the importance of helping one’s neighbors—thus public spirit suffers. This is psychosocial harm associated with the material harm of discouraging use of the program.
Many users unconsciously recognize the wrong of refusing to share, so they decide to ignore the licenses and laws, and share programs anyway. But they often feel guilty about doing so. They know that they must break the laws in order to be good neighbors, but they still consider the laws authoritative, and they conclude that being a good neighbor (which they are) is naughty or shameful. That is also a kind of psychosocial harm, but one can escape it by deciding that these licenses and laws have no moral force.
Programmers also suffer psychosocial harm knowing that many users will not be allowed to use their work. This leads to an attitude of cynicism or denial. A programmer may describe enthusiastically the work that he finds technically exciting; then when asked, “Will I be permitted to use it?” his face falls, and he admits the answer is no. To avoid feeling discouraged, he either ignores this fact most of the time or adopts a cynical stance designed to minimize the importance of it.
Since the age of Reagan, the greatest scarcity in the United States is not technical innovation, but rather the willingness to work together for the public good. It makes no sense to encourage the former at the expense of the latter.
Obstructing Custom Adaptation of Programs
The second level of material harm is the inability to adapt programs. The ease of modification of software is one of its great advantages over older technology. But most commercially available software isn’t available for modification, even after you buy it. It’s available for you to take it or leave it, as a black box—that is all.
A program that you can run consists of a series of numbers whose meaning is obscure. No one, not even a good programmer, can easily change the numbers to make the program do something different.
Programmers normally work with the “source code” for a program, which is written in a programming language such as Fortran or C. It uses names to designate the data being used and the parts of the program, and it represents operations with symbols such as ‘+’ for addition and ‘-’ for subtraction. It is designed to help programmers read and change programs. Here is an example; a program to calculate the distance between two points in a plane:
float distance (p0, p1) struct point p0, p1; { float xdist = p1.x - p0.x; float ydist = p1.y - p0.y; return sqrt (xdist * xdist + ydist * ydist); }
Precisely what that source code means is not the point; the point is that it looks like algebra, and a person who knows this programming language will find it meaningful and clear. By contrast, here is same program in executable form, on the computer I normally used when I wrote this:
1314258944 -232267772 -231844864 1634862 1411907592 -231844736 2159150 1420296208 -234880989 -234879837 -234879966 -232295424 1644167167 -3214848 1090581031 1962942495 572518958 -803143692 1314803317
Source code is useful (at least potentially) to every user of a program. But most users are not allowed to have copies of the source code. Usually the source code for a proprietary program is kept secret by the owner, lest anybody else learn something from it. Users receive only the files of incomprehensible numbers that the computer will execute. This means that only the program’s owner can change the program.
A friend once told me of working as a programmer in a bank for about six months, writing a program similar to something that was commercially available. She believed that if she could have gotten source code for that commercially available program, it could easily have been adapted to their needs. The bank was willing to pay for this, but was not permitted to—the source code was a secret. So she had to do six months of make-work, work that counts in the GNP but was actually waste.
The MIT Artificial Intelligence Lab (AI Lab) received a graphics printer as a gift from Xerox around 1977. It was run by free software to which we added many convenient features. For example, the software would notify a user immediately on completion of a print job. Whenever the printer had trouble, such as a paper jam or running out of paper, the software would immediately notify all users who had print jobs queued. These features facilitated smooth operation.
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.”
Obstructing Software Development
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.
