Fascinating interview by Richard Stallman at KTH on emacs history and internals

[bolega]

http://www.gnu.org/philosophy/stallman-kth.html

RMS lecture at KTH (Sweden), 30 October 1986

(Kungliga Tekniska Högskolan (Royal Institute of Technology))
Stockholm, Sweden

Arranged by the student society
“Datorföreningen Stacken”
30 October 1986

[Note: This is a slightly edited transcript of the talk. As such it
contains false starts, as well as locutions that are natural in spoken
English but look strange in print. It is not clear how to correct them
to written English style without ‘doing violence to the original
speech’.]

It seems that there are three things that people would like me to talk
about. On the one hand I thought that the best thing to talk about
here for a club of hackers, was what it was like at the MIT in the old
days. What made the Artificial Intelligence Lab such a special place.
But people tell me also that since these are totally different people
from the ones who were at the conference Monday and Tuesday that I
ought to talk about what's going on in the GNU project and that I
should talk about why software and information can not be owned, which
means three talks in all, and since two of those subjects each took an
hour it means we're in for a rather long time. So I had the idea that
perhaps I could split it in to three parts, and people could go
outside for the parts they are not interested in, and that then when I
come to the end of a part I can say it's the end and people can go out
and I can send Jan Rynning out to bring in the other people. (Someone
else says: “Janne, han trenger ingen mike” (translation: “Janne, he
doesn't need a mike”)). Jan, are you prepared to go running out to
fetch the other people? Jmr: I am looking for a microphone, and
someone tells me it is inside this locked box. Rms: Now in the old
days at the AI lab we would have taken a sledgehammer and cracked it
open, and the broken door would be a lesson to whoever had dared to
lock up something that people needed to use. Luckily however I used to
study Bulgarian singing, so I have no trouble managing without a
microphone.

Anyway, should I set up this system to notify you about the parts of
the talk, or do you just like to sit through all of it? (Answer:
Yeaaah)

When I started programming, it was 1969, and I did it in an IBM
laboratory in New York. After that I went to a school with a computer
science department that was probably like most of them. There were
some professors that were in charge of what was supposed to be done,
and there were people who decided who could use what. There was a
shortage of terminals for most people, but a lot of the professors had
terminals of their own in their offices, which was wasteful, but
typical of their attitude. When I visited the Artificial Intelligence
lab at MIT I found a spirit that was refreshingly different from that.
For example: there, the terminals was thought of as belonging to
everyone, and professors locked them up in their offices on pain of
finding their doors broken down. I was actually shown a cart with a
big block of iron on it, that had been used to break down the door of
one professors office, when he had the gall to lock up a terminal.
There were very few terminals in those days, there was probably
something like five display terminals for the system, so if one of
them was locked up, it was a considerable disaster.

In the years that followed I was inspired by that ideas, and many
times I would climb over ceilings or underneath floors to unlock rooms
that had machines in them that people needed to use, and I would
usually leave behind a note explaining to the people that they
shouldn't be so selfish as to lock the door. The people who locked the
door were basically considering only themselves. They had a reason of
course, there was something they thought might get stolen and they
wanted to lock it up, but they didn't care about the other people they
were affecting by locking up other things in the same room. Almost
every time this happened, once I brought it to their attention, that
it was not up to them alone whether that room should be locked, they
were able to find a compromise solution: some other place to put the
things they were worried about, a desk they could lock, another little
room. But the point is that people usually don't bother to think about
that. They have the idea: “This room is Mine, I can lock it, to hell
with everyone else”, and that is exactly the spirit that we must teach
them not to have.

But this spirit of unlocking doors wasn't an isolated thing, it was
part of an entire way of life. The hackers at the AI lab were really
enthusiastic about writing good programs, and interesting programs.
And it was because they were so eager to get more work done, that they
wouldn't put up with having the terminals locked up, or lots of other
things that people could do to obstruct useful work. The differences
between people with high morale who really care about what they're
trying to do, and people who think of it as just a job. If it's just a
job, who cares if the people who hired you are so stupid they make you
sit and wait, it's their time, their money but not much gets done in a
place like that, and it's no fun to be in a place like that.

Another thing that we didn't have at the AI lab was file protection.
There was no security at all on the computer. And we very consciously
wanted it that way. The hackers who wrote the Incompatible Timesharing
System decided that file protection was usually used by a self-styled
system manager to get power over everyone else. They didn't want
anyone to be able to get power over them that way, so they didn't
implement that kind of a feature. The result was, that whenever
something in the system was broken, you could always fix it. You never
had to sit there in frustration because there was NO WAY, because you
knew exactly what's wrong, and somebody had decided they didn't trust
you to do it. You don't have to give up and go home, waiting for
someone to come in in the morning and fix the system when you know ten
times as well as he does what needs to be done.

And we didn't let any professors or bosses decide what work was going
to be done either, because our job was to improve the system! We
talked to the users of course; if you don't do that you can't tell
what's needed. But after doing that, we were the ones best able to see
what kind of improvements were feasible, and we were always talking to
each other about how we'd like to see the system changed, and what
sort of neat ideas we'd seen in other systems and might be able to
use. So the result is that we had a smoothly functioning anarchy, and
after my experience there, I'm convinced that that is the best way for
people to live.

Unfortunately the AI lab in that form was destroyed. For many years we
were afraid the AI lab would be destroyed by another lab at MIT, the
Lab for Computer Science, whose director was a sort of empire builder
type, doing everything he could to get himself promoted within MIT,
and make his organization bigger, and he kept trying to cause the AI
lab to be made a part of his lab, and nobody wanted to do things his
way because he believed that people should obey orders and things like
that.

But that danger we managed to defend against, only to be destroyed by
something we had never anticipated, and that was commercialism. Around
the early 80's the hackers suddenly found that there was now
commercial interest in what they were doing. It was possible to get
rich by working at a private company. All that was necessary was to
stop sharing their work with the rest of the world and destroy the MIT-
AI lab, and this is what they did despite all the efforts I could make
to prevent them.

Essentially all the competent programmers except for me, at the AI lab
were hired away, and this caused more than a momentary change, it
caused a permanent transformation because it broke the continuity of
the culture of hackers. New hackers were always attracted by the old
hackers; there were the most fun computers and the people doing the
most interesting things, and also a spirit which was a great deal of
fun to be part of. Once these things were gone, there is nothing to
recommend the place to anyone new, so new people stopped arriving.
There was no-one they could be inspired by, no-one that they could
learn those traditions from. In addition no-one to learn how to do
good programming from. With just a bunch of professors and graduate
students, who really don't know how to make a program work, you can't
learn to make good programs work. So the MIT AI lab that I loved is
gone and after a couple of years of fighting against the people who
did it to try to punish them for it I decided that I should dedicate
my self to try to create a new community with that spirit.

But one of the problems I had to face was the problem of proprietary
software. For example one thing that happened at the lab, after the
hackers left, was that the machines and the software that we had
developed could no longer be maintained. The software of course
worked, and it continued to work if nobody changed it, but the
machines did not. The machines would break and there would be no-one
who could fix them and eventually they would be thrown out. In the old
days, yes we had service contracts for the machines, but it was
essentially a joke. That was a way of getting parts after the expert
hackers from the AI lab fixed the problem. Because if you let the
field-service person fix it it would take them days, and you didn't
want to do that, you wanted it to work. So, the people who knew how to
do those things would just go and fix it quickly, and since they were
ten times as competent as any field service person, they could do a
much better job. And then they would have the ruined boards, they
would just leave them there and tell the field service person “take
these back and bring us some new ones”.

In the real old days our hackers used to modify the machines that came
from Digital also. For example, they built paging-boxes to put on the
PDP-10's. Nowadays I think there are some people here [in Stockholm]
who do such things too, but it was a pretty unusual thing in those
days. And the really old days, the beginning of the 1960's people used
to modify computers adding all sorts of new instructions and new fancy
timesharing features, so that the PDP-1 at MIT by the time it was
retired in the mid-seventies had something like twice as many
instructions as it had when it was delivered by Digital in the early
sixties, and it had special hardware scheduler assisting features and
strange memory-mapping features making it possible to assign
individual hardware devices to particular timesharing jobs and lots of
things that I hardly really know about. I think they also built in
some kind of extended addressing modes they added index registers and
indirect addressing, and they turned it essentially from a weak
machine into a semi-reasonable one.

I guess it is one of the disadvantages of VLSI that it's no longer so
feasible to add instructions to your machines.

The PDP-1 also had a very interesting feature, which is that it was
possible to write interesting programs in very few instructions. Fewer
than any other machine since then. I believe for example that the
famous display hack “munching squares” which made squares that get
bigger and break up into lots of smaller squares which gets bigger and
break up into smaller squares. That was written in something like five
instructions on the PDP-1. And many other beautiful display programs
could be written in few instructions.

So, that was the AI lab. But what was the culture of hackers like
aside from their anarchism? In the days of the PDP-1 only one person
could use the machine, at the beginning at least. Several years later
they wrote a timesharing system, and they added lots of hardware for
it. But in the beginning you just had to sign up for some time. Now of
course the professors and the students working on official projects
would always come in during the day. So, the people who wanted to get
lots of time would sign up for time at night when there were less
competition, and this created the custom of hackers working at night.
Even when there was timesharing it would still be easier to get time,
you could get more cycles at night, because there were fewer users. So
people who wanted to get lots of work done, would still come in at
night. But by then it began to be something else because you weren't
alone, there were a few other hackers there too, and so it became a
social phenomenon. During the daytime if you came in, you could expect
to find professors and students who didn't really love the machine,
whereas if during the night you came in you would find hackers.
Therefore hackers came in at night to be with their culture. And they
developed other traditions such as getting Chinese food at three in
the morning. And I remember many sunrises seen from a car coming back
from Chinatown. It was actually a very beautiful thing to see a
sunrise, cause' that's such a calm time of day. It's a wonderful time
of day to get ready to go to bed. It's so nice to walk home with the
light just brightening and the birds starting to chirp, you can get a
real feeling of gentle satisfaction, of tranquility about the work
that you have done that night.

Another tradition that we began was that of having places to sleep at
the lab. Ever since I first was there, there was always at least one
bed at the lab. And I may have done a little bit more living at the
lab than most people because every year of two for some reason or
other I'd have no apartment and I would spend a few months living at
the lab. And I've always found it very comfortable, as well as nice
and cool in the summer. But it was not at all uncommon to find people
falling asleep at the lab, again because of their enthusiasm; you stay
up as long as you possibly can hacking, because you just don't want to
stop. And then when you're completely exhausted, you climb over to the
nearest soft horizontal surface. A very informal atmosphere.

But when the hackers all left the lab this caused a demographic
change, because the professors and the students who didn't really love
the machine were just as numerous as before, so they were now the
dominant party, and they were very scared. Without hackers to maintain
the system, they said, “we're going to have a disaster, we must have
commercial software”, and they said “we can expect the company to
maintain it”. It proved that they were utterly wrong, but that's what
they did.

That was exactly when a new KL-10 system was supposed to arrive, and
the question was, would it run the Incompatible Timesharing System or
would it run Digital's Twenex system. Once the hackers were gone who
probably would have supported using ITS, the academic types chose to
run the commercial software, and this had several immediate effects.
Some of them weren't actually so immediate but they followed
inevitably as anyone who thought about it would see.

One thing was that that software was much more poorly written, and
harder to understand; therefore making it harder for people to make
the changes that were in fact needed. Another was, that that software
came with security, which had the inevitable effect of causing people
to cooperate with each other less. In the old days on ITS it was
considered desirable that everyone could look at any file, change any
file, because we had reasons to. I remember one interesting scandal
where somebody sent a request for help in using Macsyma. Macsyma is a
symbolic algebra program that was developed at MIT. He sent to one of
the people working on it a request for some help, and he got an answer
a few hours later from somebody else. He was horrified, he sent a
message “so-and-so must be reading your mail, can it be that mail
files aren't properly protected on your system?” “Of course, no file
is protected on our system. What's the problem? You got your answer
sooner; why are you unhappy? Of course we read each other's mail so we
can find people like you and help them”. Some people just don't know
when they're well off.

But of course Twenex not only has security, and by default turns on
security, but it's also designed with the assumption that security is
in use. So there are lots of things that are very easy to do that can
cause a lot of damage, and the only thing that would stop you from
doing them by accident, is security. On ITS we evolved other means of
discouraging people from doing those things by accident, but on Twenex
you didn't have them because they assumed that there was going to be
be strict security in effect and only the bosses were going to have
the power to do them. So they didn't put in any other mechanism to
make it hard to do by accident. The result of this is that you can't
just take Twenex and turn off the security and have what you'd really
like to have, and there were no longer the hackers to make the changes
to put in those other mechanisms, so people were forced to use the
security. And about six months after the machine was there they
started having some coups d'etat. That is, at first we had the
assumption that everyone who worked for the lab was going to have the
wheel bit which gave full powers to override all security measures,
but some days you'd come in some afternoon and find out that the wheel
bits of just about everybody had been turned off.

When I found out about those, I overthrew them. The first time, I
happened to know the password of one of the people who was included
among the elite, so I was able to use that to turn everyone back on.
The second time he had changed his password, he had now changed his
sympathies, he was now part of the aristocratic party. So, I had to
bring the machine down and use non-timeshared DDT to poke around. I
poked around in the monitor for a while, and eventually figured out
how to get it to load itself in and let me patch it, so that I could
turn off password checking and then I turned back on a whole bunch of
people's wheel bits and posted a system message. I have to explain
that the name of this machine was OZ, so I posted a system message
saying: “There was another attempt to seize power. So far the
aristocratic forces have been defeated—Radio Free OZ”. Later I
discovered that “Radio Free OZ” is one of the things used by Firesign
Theater. I didn't know that at the time.

But gradually things got worse and worse, it's just the nature of the
way the system had been constructed forced people to demand more and
more security. Until eventually I was forced to stop using the
machine, because I refused to have a password that was secret. Ever
since passwords first appeared at the MIT-AI lab I had come to the
conclusion that to stand up for my belief, to follow my belief that
there should be no passwords, I should always make sure to have a
password that is as obvious as possible and I should tell everyone
what it is. Because I don't believe that it's really desirable to have
security on a computer, I shouldn't be willing to help uphold the
security regime. On the systems that permit it I use the “empty
password”, and on systems where that isn't allowed, or where that
means you can't log in at all from other places, things like that, I
use my login name as my password. It's about as obvious as you can
get. And when people point out that this way people might be able to
log in as me, i say “yes that's the idea, somebody might have a need
to get some data from this machine. I want to make sure that they
aren't screwed by security”.

And an other thing that I always do is I always turn of all protection
on my directory and files, because from time to time I have useful
programs stored there and if there's a bug I want people to be able to
fix it.

But that machine wasn't designed also to support the phenomenon called
“tourism”. Now “tourism” is a very old tradition at the AI lab, that
went along with our other forms of anarchy, and that was that we'd let
outsiders come and use the machine. Now in the days where anybody
could walk up to the machine and log in as anything he pleased this
was automatic: if you came and visited, you could log in and you could
work. Later on we formalized this a little bit, as an accepted
tradition specially when the Arpanet began and people started
connecting to our machines from all over the country. Now what we'd
hope for was that these people would actually learn to program and
they would start changing the operating system. If you say this to the
system manager anywhere else he'd be horrified. If you'd suggest that
any outsider might use the machine, he'll say “But what if he starts
changing our system programs?” But for us, when an outsider started to
change the system programs, that meant he was showing a real interest
in becoming a contributing member of the community. We would always
encourage them to do this. Starting, of course, by writing new system
utilities, small ones, and we would look over what they had done and
correct it, but then they would move on to adding features to
existing, large utilities. And these are programs that have existed
for ten years or perhaps fifteen years, growing piece by piece as one
craftsman after an other added new features.

Sort of like cities in France you might say, where you can see the
extremely old buildings with additions made a few hundred years later
all the way up to the present. Where in the field of computing, a
program that was started in 1965 is essentially that. So we would
always hope for tourists to become system maintainers, and perhaps
then they would get hired, after they had already begun working on
system programs and shown us that they were capable of doing good
work.

But the ITS machines had certain other features that helped prevent
this from getting out of hand, one of these was the “spy” feature,
where anybody could watch what anyone else was doing. And of course
tourists loved to spy, they think it's such a neat thing, it's a
little bit naughty you see, but the result is that if any tourist
starts doing anything that causes trouble there's always somebody else
watching him. So pretty soon his friends would get very mad because
they would know that the continued existence of tourism depended on
tourists being responsible. So usually there would be somebody who
would know who the guy was, and we'd be able to let him leave us
alone. And if we couldn't, then what we would do was we would turn off
access from certain places completely, for a while, and when we turned
it back on, he would have gone away and forgotten about us. And so it
went on for years and years and years.

But the Twenex system wasn't designed for this sort of thing, and
eventually they wouldn't tolerate me with my password that everybody
knew, tourists always logging in as me two or three at a time, so they
started flushing my account. And by that time I was mostly working on
other machines anyway, so eventually I gave up and stopped ever
turning it on again. And that was that. I haven't logged in on that
machine as myself … [At this point RMS is interrupted by tremendous
applause] … for.

But when they first got this Twenex system they had several changes in
mind that they wanted to make. Changes in the way security worked.
They also wanted to have the machine on both the ARPA network and the
MIT-chaos network, and it turns out that they were unable to do this,
that they couldn't get anyone who was sufficiently competent to make
such changes. There was no longer talent available to do it, and it
was to hard to change. That system was much harder to understand,
because it was to poorly written, and of course, Digital wouldn't do
these things, so their ideas that a commercial system would
essentially maintain itself, proved to be mistaken. They had just as
much need for system hackers, but they had no longer the means to
entice system hackers. And nowadays at MIT there are more people
interested in hacking on ITS than there are interested in hacking on
Twenex.

And the final reason why this is so, is that Twenex can't be shared.
Twenex is a proprietary program and you're only allowed to have the
sources if you keep them secret in certain nasty ways, and this gives
them a bad flavor. Unless a person is oblivious (which some people in
computers are, there's some people who'll do anything if it's fun for
them, and won't think for a minute whether they're cooperating with
anyone else, but you'd have to be pretty oblivious to not to notice
what a sad thing it is to work on a program like that, and that is a
further discouragement). And if that isn't enough there is the fact
that every year or so they're going to give you a new release full of
50 000 additional lines of code all written by monkeys. Because they
generally follow the “million monkeys typing, and eventually they'll
come up with something useful” school of system development.

It was clear to me from what I saw happening to these proprietary
systems that the only way we could have the spirit of the old AI lab
was to have a free operating system. To have a system made up of free
software which could be shared with anyone. So that we could invite
everyone to join in improving it. And that's what led up to the GNU
project. So I guess we've arrived at the second part of the talk.

About three and a half year ago it was clear to me that I should start
developing a free software system. I could see two possible kinds of
systems to develop: One: A LISP-machine-like system, essentially a
system just like the MIT LISP machine system that had just been
developed, except free, and running on general purpose hardware, not
on special LISP machines. And the other possibility was a more
conventional operating system, and it was clear to me that if I made a
conventional operating system, I should make it compatible with Unix,
because that would make it easy for people all around to switch to it.
After a little while, I concluded I should do the latter and the
reason was, that I saw that you can't have something really like the
LISP machine system on general purpose hardware. The LISP machine
system uses special hardware plus special writable microcode to gain
both good execution speed and robust detection of errors at runtime,
specially data-type errors. In order to make a LISP system run fast
enough on ordinary hardware, you have to start making assumptions.
Assuming that a certain argument is the right type, and then if it
isn't the system just crashes.

Of course you can put in explicit checks, you can write a robust
program if you want, but the fact is that you are going to get things
like memory addressing errors when you feed a function an argument of
the wrong type if you did NOT put in things to check for it.

So the result is then that you need something running underneath the
LISP system to you catch these errors, and give the user the ability
to keep on running, and debug what happened to him. Finally I
concluded that if I was going to have to have a operating system at a
lower level, I might as well make a good operating-system—that it was
a choice between an operating system and the lisp, or just an
operating system; therefore I should do the operating system first,
and I should make it compatible with Unix. Finally when I realized
that I could use the most amusing word in the English language as a
name for this system, it was clear which choice I had to make. And
that word is of course GNU, which stands for “Gnu's Not Unix”. The
recursive acronym is a very old tradition among the hacker community
around MIT. It started, I believe, with an editor called TINT, which
means: “Tint Is Not Teco”, and later on it went through names such as
“SINE” for “SINE Is Not Emacs”, and FINE for “Fine Is Not Emacs”, and
EINE for “Eine Is Not Emacs”, and ZWEI for “Zwei Was Eine Initially”,
and ultimately now arrives at GNU.

I would say that since the time about two and a half years ago when I
actually started working on GNU, I've done more than half of the work.
When I was getting ready to start working on the project, I first
started looking around for what I could find already available free. I
found out about an interesting portable compiler system which was
called “the free university compiler kit”, and I thought, with a name
like that, perhaps I could have it. So, I sent a message to the person
who had developed it asking if he would give it to the GNU project,
and he said “No, the university might be free, but the software they
develop isn't”, but he then said that he wanted to have a Unix
compatible system too, and he wanted to write a sort of kernel for it,
so why didn't I then write the utilities, and they could both be
distributed with his proprietary compiler, to encourage people to buy
that compiler. And I thought that this was despicable and so I told
him that my first project would be a compiler.

I didn't really know much about optimizing compilers at the time,
because I'd never worked on one. But I got my hands on a compiler,
that I was told at the time was free. It was a compiler called PASTEL,
which the authors say means “off-color PASCAL”.

Pastel was a very complicated language including features such as
parametrized types and explicit type parameters and many complicated
things. The compiler was of course written in this language, and had
many complicated features to optimize the use of these things. For
example: the type “string” in that language was a parameterized type;
you could say “string(n)” if you wanted a string of a particular
length; you could also just say “string”, and the parameter would be
determined from the context. Now, strings are very important, and it
is necessary for a lot of constructs that use them to run fast, and
this means that they had to have a lot of features to detect such
things as: when the declared length of a string is an argument that is
known to be constant throughout the function, to save to save the
value and optimize the code they're going to produce, many complicated
things. But I did get to see in this compiler how to do automatic
register allocation, and some ideas about how to handle different
sorts of machines.

Well, since this compiler already compiled PASTEL, what i needed to do
was add a front-end for C, which I did, and add a back-end for the
68000 which I expected to be my first target machine. But I ran into a
serious problem. Because the PASTEL language was defined not to
require you to declare something before you used it, the declarations
and uses could be in any order, in other words: Pascal's “forward”
declaration was obsolete, because of this it was necessary to read in
an entire program, and keep it in core, and then process it all at
once. The result was that the intermediate storage used in the
compiler, the size of the memory needed, was proportional to the size
of your file. And this also included stack-space, you needed gigantic
amounts of stack space, and what I found as a result was: that the
68000 system available to me could not run the compiler. Because it
was a horrible version of Unix that gave you a limit of something like
16K words of stack, this despite the existence of six megabytes in the
machine, you could only have 16Kw of stack or something like that. And
of course to generate its conflict matrix to see which temporary
values conflicted, or was alive at the same time as which others, it
needed a quadratic matrix of bits, and that for large functions that
would get it to hundreds of thousands of bytes. So i managed to debug
the first pass of the ten or so passes of the compiler, cross compiled
on to that machine, and then found that the second one could never
run.

While I was thinking about what to do about these problems and
wondering whether I should try to fix them or write entirely new
compiler, in a roundabout fashion I began working on GNU Emacs. GNU
Emacs is the main distributed portion of the GNU system. It's an
extensible text editor a lot like the original emacs which I developed
ten years ago, except that this one uses actual LISP as its extension
language. The editor itself is implemented in C, as is the LISP
interpreter, so the LISP interpreter is completely portable, and you
don't need a LISP system external to the editor. The editor contains
its own LISP system, and all of the editing commands are written in
LISP so that they can provide you with examples to look at for how to
write your own editing commands, and things to start with, so you can
change them into the editing commands that you really want.

In the summer of that year, about two years ago now, a friend of mine
told me that because of his work in early development of Gosling
Emacs, he had permission from Gosling in a message he had been sent to
distribute his version of that. Gosling originally had set up his
Emacs and distributed it free and gotten many people to help develop
it, under the expectation based on Gosling's own words in his own
manual that he was going to follow the same spirit that I started with
the original Emacs. Then he stabbed everyone in the back by putting
copyrights on it, making people promise not to redistribute it and
then selling it to a software-house. My later dealings with him
personally showed that he was every bit as cowardly and despicable as
you would expect from that history.

But in any case, my friend gave me this program, and my intention was
to change the editing commands at the top level to make them
compatible with the original Emacs that I was used to. And to make
them handle all the combinations of numerical arguments and so on that
one might expect that they would handle and have all the features that
I wanted. But after a little bit of this, I discovered that the
extension language of that editor, which is called MOCKLISP, was not
sufficient for the task. I found that that I had to replace it
immediately in order to do what I was planning to do. Before I had had
the idea of someday perhaps replacing MOCKLISP with real LISP, but
what I found out was that it had do be done first. Now, the reason
that MOCKLISP is called MOCK, is that it has no kind of structure
datatype: it does not have LISP lists; it does not have any kind of
array. It also does not have LISP symbols, which are objects with
names: for any particular name, there is only one object, so that you
can type in the name and you always get the same object back. And this
tremendously hampers the writing of many kinds of programs, you have
to do things by complicated string-manipulation that don't really go
that way.

So I wrote a LISP interpreter and put it in in place of MOCKLISP and
in the process I found that I had to rewrite many of the editor's
internal data structures because I wanted them to be LISP objects. I
wanted the interface between the LISP and the editor to be clean,
which means that objects such as editor buffers, sub-processes,
windows and buffer-positions, all have to be LISP objects, so that the
editor primitives that work on them are actually callable as LISP
functions with LISP data. This meant that I had to redesign the data
formats of all those objects and rewrite all the functions that worked
on them, and the result was that after about six months I had
rewritten just about everything in the editor.

In addition, because it is so hard to write things in MOCKLISP, all
the things that had been written in MOCKLISP were very unclean and by
rewriting them to take advantage of the power of real LISP, I could
make them much more powerful and much simpler and much faster. So I
did that, and the result was that when I started distributing this
program only a small fraction remained from what I had received.

At this point, the company that Gosling thinks he sold the program to
challenged my friend's right to distribute it, and the message was on
backup tapes, so he couldn't find it. And Gosling denied having given
him permission. And then a strange thing happened. He was negotiating
with this company, and it seemed that the company mainly was concerned
with not having anything distributed that resembled what they were
distributing. See, he was still distributing, and the company where he
worked, which is Megatest, was still distributing the same thing he
had given me, which really was an old version of Gosling Emacs with
his changes, and so he was going to make an agreement with them where
he would stop distributing that, and would switch to using GNU Emacs,
and they would then acknowledge that he really had the permission
after all, and then supposedly everyone would be happy. And this
company was talking to me about wanting to distribute GNU Emacs, free
of course, but also sell various sorts of supporting assistance, and
they wanted to hire me to help do the work. So it's sort of strange
that they then changed their mind and refused to sign that agreement,
and put up a message on the network saying that I wasn't allowed to
distribute the program. They didn't actually say that they would do
anything, they just said that it wasn't clear whether they might ever
someday do something. And this was enough to scare people so that no
one would use it any more, which is a sad thing.

(Sometimes I think that perhaps one of the best things I could do with
my life is: find a gigantic pile of proprietary software that was a
trade secret, and start handing out copies on a street corner so it
wouldn't be a trade secret any more, and perhaps that would be a much
more efficient way for me to give people new free software than
actually writing it myself; but everyone is too cowardly to even take
it.)

So I was forced to rewrite all the rest that remained, and I did that,
it took me about a week and a half. So they won a tremendous victory.
And I certainly wouldn't ever cooperate with them in any fashion after
that.

Then after GNU Emacs was reasonably stable, which took all in all
about a year and a half, I started getting back to other parts of the
system. I developed a debugger which I called GDB which is a symbolic
debugger for C code, which recently entered distribution. Now this
debugger is to a large extent in the spirit of DBX, which is a
debugger that comes with Berkeley Unix. Commands consist of a word
that says what you want to do, followed by arguments. In this
debugger, commands can all be abbreviated, and the common commands
have single character abbreviations, but any unique abbreviation is
always allowed. There are extensible HELP facilities, you can type
HELP followed by any command or even subcommands, and get a lengthy
description of how to use that command. Of course you can type any
expression in C, and it will print the value.

You can also do some things that are not usual in symbolic C
debuggers, for example: You can refer to any C datatype at any memory
address, either to examine the value, or to assign the value. So for
example if you want to store a floating point value in a word at a
certain address, you just say: “Give me the object of type FLOAT or
DOUBLE at this address” and then assign that. Another thing you can do
is to examine all the values that have been examined in the past.
Every value examined gets put on the “value history”. You can refer to
any element in the history by its numerical position, or you can
easily refer to the last element with just dollar-sign. And this makes
it much easier to trace list structure. If you have any kind of C
structure that contains a pointer to another one, you can do something
like “PRINT *$.next”, which says: “Get the next field out of the last
thing you showed me, and then display the structure that points at”.
And you can repeat that command, and each time you'll see then next
structure in the list. Whereas in every other C debugger that I've
seen the only way to do that is to type a longer command each time.
And when this is combined with the feature that just typing carriage-
return repeats the last command you issued, it becomes very
convenient. Just type carriage-return for each element in the list you
want to see.

There are also explicitly settable variables in the debugger, any
number of them. You say dollar-sign followed by a name, and that is a
variable. You can assign these variables values of any C datatype and
then you can examine them later. Among the things that these are
useful for are: If there's a particular value that you're going to
examine, and you know you are going to refer to it a lot, then rather
than remember its number in the history you might give it a name. You
might also find use for them when you set conditional breakpoints.
Conditional breakpoints are a feature in many symbolic debuggers, you
say “stop when you get to this point in the program, but only if a
certain expression is true”. The variables in the debugger allow you
to compare a variable in the program with a previous value of that
variable that you saved in a debugger variable. Another thing that
they can be used for is for counting, because after all, assignments
are expressions in C, therefore you can do “$foo+=5” to increment the
value of “$foo” by five, or just “$foo++” you can do. You can even do
this in a conditional breakpoint, so that's a cheap way of having it
break the tenth time the breakpoint is hit, you can do “$foo--==0”.
Does everyone follow that? Decrement foo and if it's zero now, break.
And then you set $foo to the number of times you want it to skip, and
you let it go. You can also use that to examine elements of an array.
Suppose you have an array of pointers, you can then do:

PRINT X[$foo++]

But first you do

SET $foo=0

Okay, when you do that [points at the “Print” expression], you get the
zeroth element of X, and then you do it again and it gets the first
element, and suppose these are pointers to structures, then you
probably put an asterisk there [before the X in the PRINT expression]
and each time it prints the next structure pointed to by the element
of the array. And of course you can repeat this command by typing
carriage-return. If a single thing to repeat is not enough, you can
create a user-defined-command. You can say “Define Mumble”, and then
you give some lines of commands and then you say “end”. And now there
is defined a “Mumble” command which will execute those lines. And it's
very useful to put these definitions in a command file. You can have a
command file in each directory, that will be loaded automatically when
you start the debugger with that as your working directory. So for
each program you can define a set of user defined commands to access
the data structures of that program in a useful way. You can even
provide documentation for your user-defined commands, so that they get
handled by the “help” features just like the built-in commands.

One other unusual thing in this debugger, is the ability to discard
frames from the stack. Because I believe it's important not just to be
able to examine what's happening in the program you're debugging, but
also to change it in any way conceivable. So that after you've found
one problem and you know what's wrong, you can fix things up as if
that code were correct and find the next bug without having to
recompile your program first. This means not only being able to change
the data areas in you program flexibly, but also being able to change
the flow of control. In this debugger you can change the flow of
control very directly by saying:

SET $PC=<some number>

So you can set the program counter. You can also set the stack
pointer, or you can say

SET $SP+=<something>

If you want to increment the stack pointer a certain amount. But in
addition you can also tell it to start at a particular line in the
program, you can set the program counter to a particular source line.
But what if you find that you called a function by mistake and you
didn't really want to call that function at all? Say, that function is
so screwed up that what you really want to do is get back out of it
and do by hand what that function should have done. For that you can
use the “RETURN” command. You select a stack frame and you say
“RETURN”, and it causes that stack-frame, and all the ones within it,
to be discarded as if that function were returning right now, and you
can also specify the value it should return. This does not continue
execution; it pretends that return happened and then stops the program
again, so you can continue changing other things.

And with all these things put together you thus have pretty good
control over what's going on in a program.

In addition one slightly amusing thing: C has string constants, what
happens if you use a string constant in an expression that you're
computing in the debugger? It has to create a string in the program
you were debugging. Well it does. It sets up a call to MALLOC in that
debugged program, lets MALLOC run, and then gets control back. Thus it
invisibly finds a place to put the string constant.

Eventually when this debugger is running on the real GNU system, I
intend to put in facilities in the debugger to examine all of the
internal status of the process that is running underneath it. For
example to examine the status of the memory map, which pages exist,
which are readable, which are writable, and to examine the inferior
program's terminal status. There already is a bit of a command; this
debugger, unlike the debuggers on Unix, keeps the terminal status
completely separate for the debugger and the program you're debugging,
so that it works with programs that run in raw mode, it works with
programs that do interrupt driven input, and there's also a command
that enables you to find out something about the terminal settings at
the program you're debugging is actually using. I believe that in
general a debugger should allow you to find out everything that's
going on in the inferior process.

There are two other main parts of the GNU system that already exist.
One is the new C compiler, and one is the TRIX kernel.

The new C compiler is something that I've written this year since last
spring. I finally decided that I'd have to throw out PASTEL. This C
compiler uses some ideas taken from PASTEL, and some ideas taken from
the University of Arizona Portable Optimizer. Their interesting idea
was to handle many different kinds of machines by generating simple
instructions, and then combining several simple instructions into a
complicated instruction when the target machine permits it. In order
to do this uniformly, they represent the instructions in algebraic
notation. For example, an ADD instruction might be represented like
this:

  r[3]=r[2]+4

This would be a representation inside their compiler for instruction
to take the contents of register two, add four and store it in
register three. In this fashion you can represent any possible
instruction for any machine. So they actually did represent all the
instructions this way and then when it came time to try to combine
them, they would do this by substituting one expression into another,
making a more complicated algebraic expression for the combined
instruction.

Sometimes depending on whether the result of the first instruction had
any further use, it might be necessary to make a combined instruction
with two assignment operators. One for this value [pointing at ???]and
another one with this value [pointing at ???] substituted in it with
what came from the second instruction. But if this value was only used
that once, you could eliminate it after substituting for it; there'd
be no need to compute it any more. So it's actually somewhat
complicated doing the substitution correctly checking that the
intervening instructions don't change any of these values and other
such things. When you support such things as auto-increment and auto-
decrement addressing, which I do now, you also have to do various
checks for those to check for situations where what you're doing is
not value preserving.

But after checking all those things, then you take the substituted
combined expression and put it through a pattern matcher, which
recognizes all the valid instructions of your chosen target machine.
And if it's recognized, then you replace those two instructions with
the combined one, otherwise you leave them alone. And their technique
is to combine two or three instructions related by data flow in this
way.

In the Arizona compiler, they actually represent things as text
strings like this, and their compiler is horribly slow. First I had
some idea of just using their compiler and making changes in it, but
it was clear to me I had to rewrite it entirely to get the speed I
wanted, so I have rewritten it to use list structure representations
for all these expressions. Things like this:

     (set (reg 2)
          (+ (reg 2)
             (int 4)))

This looks like Lisp, but the semantics of these are not quite LISP,
because each symbol here is one recognized specially. There's a
particular fixed set of these symbols that is defined, all the ones
you need. And each one has a particular pattern of types of arguments,
for example: “reg” always has an integer, because registers are
numbered, but “+” takes two subexpressions, and so on. And with each
of these expressions is also a data type which says essentially
whether it's fixed or floating and how many bytes long it is. It could
be extended to handle other things too if you needed to.

And the way I do automatic register allocation is that when I
initially generate this code, and when I do the combination and all
those things, for every variable that conceivably go into a register,
I allocate what I call a pseudo register number, which is a number
starting at sixteen or whatever is too high to be a real register for
your target machine. So the real registers are numbered zero to
fifteen or whatever and above that comes pseudo registers. And then
one of the last parts of the compiler consists of going through and
changing all the pseudo registers to real registers. Again it makes a
conflict graph, it sees which pseudo registers are alive at the same
point and they of course can't go in the same real register, and then
it tries packing pseudo registers into real registers as much as it
can, ordering them by priority of how important they are.

And finally it then has to correct the code for various problems, such
as happen when there were pseudo registers that don't fit in the real
registers, that had to be put into stack slots instead. When that
happens on certain machines, some of the instructions may become
invalid. For example on the 68000 you can add a register into memory
and you can add memory into register, but you can't add one memory
location into another. So if you have an ADD instruction, and you're
headed for a 68000 and both of the things end up in memory, it's not
valid. So this final pass goes through and copies things into
registers and out of registers as needed to correct those problems.

Problems can also arise with index registers. If you're trying to
index by something, then most of the time that code will become
invalid if the index quantity is in memory, except in a few cases on
some machines where you can it with indirect addressing. In the cases
when you're doing auto-increment on an index register you may have to
copy the value into a register, do the instruction, and then copy the
incremented value back to the memory slot where it really lives.

There's got room for a lot of hair, and I've not finished implementing
all the hair needed to make really fully efficient.

This compiler currently works by having a parser which turns C code
into effectively a syntax tree annotated with C datatype information.
Then another pass which looks at that tree and generates code like
this [LISP like code]. Then several optimization passes. One to handle
things like jumps across jumps, jumps to jumps, jumps to .+1, all of
which can be immediately simplified. Then a common subexpression
recognizer, then finding basic blocks, and performing dataflow-
analysis, so that it can tell for each instruction which values are
used in that instruction and never used afterward. And also linking
each instruction to the places where the values it uses were
generated, so if I have one instruction which generates pseudo
register R[28], and then another instruction later which uses R[28]
and it's the first place to use R[28], I make the second one point
back to the first one, and this pointer is used to control the
attempts to combine the instructions. You don't combine adjacent
instructions, you combine an instruction that uses a value with the
instruction that produced that value. Even if there are other
instructions in between, they don't matter for this, you just have to
check them to make sure they don't do anything to interfere. Then
after the combiner comes the dynamic register allocator, and finally
something to convert it into assembly code.

In the Arizona compiler the instruction recognizer was generated with
LEX. Your machine description was simply a LEX program that LEX would
turn into a C function to recognize valid instructions as strings.
What I have is instead a special purpose decision tree that's
generated from a machine description written in this syntax as if it
were LISP. And this recognizer is used as a subroutine for many
different parts of the compiler.

Currently this compiler runs about as fast as PCC. It runs noticeably
faster if you tell it not to do the hairy register allocation, in
which case it allocates registers the same way as PCC does. In its
super hairy mode it does a much better job of allocating registers
than PCC, and I observe that for the VAX it generates the best code
I've seen from any C compiler on the VAX.

For the 68000 the code is still not ideal. I can see places where
early stages do things that are not the best, because it can't fully
look ahead. It has a choice in an early stage, and it does the thing
that it thinks is going to be best, but really if it did the other
one, a later stage is actually smart enough to do something even
better. But the early stage doesn't know what the later stage is going
to do, so I have more work to do on some of these things.

Sometimes this causes it to free up registers unnecessarily. Because
when things wind up in memory and it needs to copy them into
registers, it needs to get registers to copy them into. This means
taking registers that it has already allocated to, and kicking those
temporary quantities out to stack slots. Of course this may invalidate
more instructions now that those things are in memory, not registers,
so it has to check again and again. Sometimes it thinks it has to copy
things to registers and really it isn't going to have to, so it may
free up too many things and thus not use all the registers that it
could.

(Question: Do you have a code generator for 32000?) Not yet, but
again, it's not a code generator it's just a machine description that
you need. A list of all the machine instructions described in this
[LISP like] form. So in fact aside from the work of implementing the
idea of constraints on which arguments can be in registers and which
kind of registers, which is something which was needed for the 68000
and was not needed for the VAX, the work of porting this compiler from
the VAX to the 68000 just took a few days. So it's very easy to port.

The compiler currently generates assembler code and it can generate
debugging information either in the format that DBX wants, or in the
special internal format of GDB. I'd say the only work needed on this
compiler is in three areas. One: I have to add a “profiling” feature,
like the one that the Unix compilers have. Two: I have to make these
register allocation things smarter, so that I can stop seeing stupid
things appearing in the output. And three: There are various bugs,
things that doesn't handle correctly yet, although it has compiled
itself correctly. I expect this will just take a few months, and then
I will release the compiler.

The other sizable part of the system that exist, is the kernel.
(Question: A pause?) Ah, yeah I guess we've forgotten about breaks.
Why don't I finish talking about the kernel, which should only take
about five minutes, and then we can take a break.

Now, for the kernel I am planning to use a system called TRIX (it
doesn't stand for anything that I know of) which was developed as a
research project at MIT. This system is based on Remote Procedure
Call. Thus programs are called domains. Each domain is a address space
and various capabilities, and a capability is none other than the
ability to call a domain. Any domain can create “capability ports” to
call it, and then it can pass these ports to other domains, and there
is no difference between calling the system and calling another user
domain. In fact you can't tell which you have. Thus it is very easy to
have devices implemented by other user programs. A file system could
be implemented by a user program, transparently. It's also transparent
to communicate across networks. You think that you're directly calling
another domain, but really you're calling the network server domain.
It takes the information that you gave in the call, and passes this
over the network to another server program which then calls the domain
that you're trying to talk to. But you and that other domain see this
as happening invisibly.

The TRIX kernel runs, and it has a certain limited amount of Unix
compatibility, but it needs a lot more. Currently it has a file system
that uses the same structure on disk as the ancient Unix file system
does. This made it easier to debug the thing, because they could set
up the files with Unix, and then they could run TRIX, but that file
system doesn't have any of the features that I believe are necessary.

Features that I believe must be added include: Version numbers,
undeletion, information on when and how and where the file was backed
up on tape, atomic superseding of files. I believe that it is good
that in Unix when a file is being written, you can already look at
what's going there, so for example, you can use “tail” to see how far
the thing got, that's very nice. And if the program dies, having
partly written the file, you can see what it produced. These things
are all good, but, that partly written output should not ever be taken
for the complete output that you expected to have eventually. The
previous version of that should continue to be visible and used by
everyone who tries to use it, until the new version is completely and
correctly made. This means that the new version should be visible in
the file system but not under the name it is supposed to have. It
should get renamed when it's finished. Which is by the way what
happens in ITS, although there each user program has to do this
explicitly. For Unix compatibility with the user programs, it has to
happen invisibly.

I have a weird hairy scheme to try to make version numbers fit with
the existing Unix user programs. And this is the idea that you specify
a file name leaving the version number implicit, if you just specify
the name in the ordinary way. But if you wish to specify a name
exactly, either because you want to state explicitly what version to
use, or because you don't want versions at all, you put a point at the
end of it. Thus if you give the filename “FOO” it means “Search the
versions that exists for FOO and take the latest one”. But if you say
“FOO.” it means “use exactly the name FOO and none other”. If you say
“FOO.3.” it says “use exactly the name FOO.3 ” which of course is
version three of FOO and none other. On output, if you just say “FOO”,
it will eventually create a new version of “FOO”, but if you say
“FOO.” it will write a file named exactly “FOO”.

Now there's some challenges involved in working out all the details in
this, and seeing whether there are any lingering problems, whether
some Unix software actually breaks despite feeding them names with
points in them and so on, to try to make it get the same behavior.

I would expect that when you open a file for output whose name ends in
a point, you should actually open that name right away, so you get the
so you get the same Unix behavior, the partially written output is
immediately visible, whereas when you output a name that doesn't end
in a point, the new version should appear when you close it, and only
if you close it explicitly. If it gets closed because the job dies, or
because the system crashes or anything like that, it should be under a
different name.

And this idea can be connected up to “star matching”, by saying that a
name that doesn't end in a point is matched against all the names
without their version numbers, so if a certain directory has files
like this:

  foo.1 foo.2 bar.8

If I say “*”, that's equivalent to

  foo bar

because it takes all the names and gets rid of their versions, and
takes all the distinct ones. But if I say “*.” then it takes all the
exact names, puts a point after each one, and matches against them. So
this gives me all the names for all the individual versions that
exist. And similar, you can see the difference between “*.c” and
“*.c.” this [the first] would give you essentially versionless
references to all the “.c” files, whereas this [the second] will give
you all the versions … well this actually wouldn't, you'd have to say
“*.c.*.”. I haven't worked out the details here.

Another thing, that isn't a user visible feature and is certainly
compatible to put in, is failsafeness in the file system. Namely, by
writing all the information on disk in the proper order, arranging
that you can press “halt” at any time without ever corrupting thereby
the file system on disk. It is so well known how to do this, I can't
imagine why anyone would neglect it. Another idea is further redundant
information. I'm not sure whether I'll do this or not, but I have
ideas for how to store in each file all of its names, and thus make it
possible if any directory on disk is lost, to reconstruct it from the
rest of the contents of the disk.

Also I think I know how to make it possible to atomically update any
portion of a file. Thus if you want to replace a certain subrange of a
file with new data in such a fashion that any attempt to read the file
will either see only the old data, or only the new data. I believe I
can do that, without any locking even.

For network support, I intend eventually to implement TCP/IP for this
system. I also think it's possible to use KERMIT to get something
effectively equivalent to UUCP.

A shell I believe has already been written. It has two modes, one
imitating the BOURNE shell, and one imitating the C-shell in the same
program. I have not received a copy of it yet, and I don't know how
much work I'll have to do on it. Also many other utilities exists. A
MAKE exists, LS, there's a YACC replacement called BISON which is
being distributed. Something pretty close to a LEX exists, but it's
not totally compatible, it needs some work. And, in general what
remains to be done is much less that what's been done, but we still
need lots of people to help out.

People always ask me “When is it going to be finished?” Of course I
can't know when it's going to be finished, but that's the wrong
question to ask me. If you were planning to pay for it, it would make
sense for you to want to know exactly what are you going to get and
when. But since you're not going to pay for it, the right question for
you to ask is “how can you help make it get finished sooner?” I have a
list of projects, it is on a file at MIT, and people who are
interested in helping could send me mail at this Internet address, and
I will send back a list of projects. (I wonder if this is will work
(looking at the chalk)). Is this readable? This is “RMS@GNU.ORG” (just
follow the bouncing ball.) And now let's take a break, and after the
break, I will say some really controversial things. So don't leave
now. If you leave now, you're going to miss the real experience.

[Here we had a 15 min. break]

I've been asked to announce how you can get copies of GNU software.
Well, one way of course is if you know a friend who has a copy, you
can copy it, but if you don't know a friend who has a copy, and you're
not on the Internet, you can't FTP it, then you can always order a
distribution tape, and send some money to the Free Software
Foundation. Of course free programs is not the same thing as free
distribution. I'll explain this in detail later.

Here I have an EMACS manual, of the nicely printed variety. It has
been phototypeset and then offset printed. Although you can also print
it yourself from the sources that come in the EMACS distribution, you
can get these copies from the Free Software Foundation. You can come
afterwards and look at this and also this contains an order for you
might copy some information from, and this [front] picture has also
sometimes been enjoyed. This [pointing at a figure being chased by RMS
riding a gnu] is a scared software hoarder, I'll be talking about him
in a moment.

Software is a relatively new phenomenon. People started distributing
software perhaps thirty years ago. It was only about twenty years ago
that someone had the idea of making a business about it. It was an
area with no tradition about how people did things, or what rights
anybody had. And there were several ideas for what other areas of life
you might bring traditions from by analogy.

One analogy that is liked by a lot of professors in Europe, is that
between programs and mathematics. A program is sort of a large
formula. Now, traditionally nobody can own a mathematical formula.
Anybody can copy them and use them.

The analogy that's most meaningful to ordinary people is with recipes.
If you think about it, the thing that you have in ordinary life that's
most like program is a recipe, it's instructions for doing something.
The differences come because a recipe is followed by a person, not by
a machine automatically. It's true there's no difference between
source code and object code for a recipe, but it's still the closest
thing. And no-one is allowed to own a recipe.

But the analogy that was chosen was the analogy with books, which have
copyright. And why was this choice made? Because the people that had
the most to gain from making that particular choice were allowed to
make the decision. The people who wrote the programs, not the people
who used the programs, were allowed to decide, and they decided in a
completely selfish fashion, and as a result they've turned the field
of programming into an ugly one.

When I entered the field, when I started working at MIT in 1971, the
idea that programs we developed might not be shared was not even
discussed. And the same was Stanford and CMU, and everyone, and even
Digital. The operating system from Digital at that time was free. And
every so often I got pieces of program from Digital system such as a
PDP-11 cross assembler, and I ported it to run on ITS, and added lots
of features. It was no copyright on that program.

It was only in the late seventies that this began to change. I was
extremely impressed by the sharing spirit that we had. We were doing
something that we hoped was useful and were happy if people could use
it. So when I developed the first EMACS, and people wanted to start
use it outside of MIT, I said that it belongs to the EMACS “Commune”,
that in order to use EMACS you had to be a member of the commune, and
that meant that you had the responsibility to contribute all the
improvements that you made. All the improvements to the original EMACS
had to be sent back to me so that I could incorporate them into newer
versions of EMACS, so that everyone in the community could benefit
from them.

But this started to be destroyed when SCRIBE was developed at CMU, and
then was sold to a company. This was very disturbing to a lot of us at
many universities, because we saw that this was a temptation placed in
front of everyone, that it was so profitable to be uncooperative and
those of us who still believed in cooperation had no weapon to try to
compel people to cooperate with us. Clearly, one after another, people
would defect and stop cooperating with the rest of society, until only
those of us with very strong consciences would still cooperate. And
that's what happened.

The field of programming has now become an ugly one, where everyone
cynically thinks about how much money he is going to get by not being
nice to the other people in the field, and to the users.

I want to establish that the practice of owning software is both
materially wasteful, spiritually harmful to society and evil. All
these three things being interrelated. It's spiritually harmful
because it involves every member of society who comes in contact with
computers in a practice that is obviously materially wasteful to other
people. And every time you do something for your own good, which you
know is hurting other people more that it helps you, you have to
become cynical in order to support such a thing in your mind. And it's
evil because it is deliberately wasting the work done in society and
causing social decay.

First I want to explain the kinds of harm that are done by attempts to
own software and other information that's generally useful, then I'll
go on to rebut the arguments made to support that practice, and then I
want to talk about how to fight that phenomenon, and how I'm fighting
it.

The idea of owning information is harmful in three different levels.
Materially harmful on three different levels, and each kind of
material harm has a corresponding spiritual harm.

The first level is just that it discourages the use of the program, it
causes fewer people to use the program, but in fact it takes no less
work to make a program for fewer people to use. When you have a price
on the use of a program this is an incentive, that's the word these
software hoarders love to use, the price is an incentive for people
not to use the program, and this is a waste. If for example only half
as many people use the program because it has a price on it, the
program has been half wasted. The same amount of work has produced
only half as much wealth.

Now in fact, you don't have to do anything special to cause a program
to get around to all the people who want to use it, because they can
copy it themselves perfectly well, and it will get to everyone. All
you have to do after you've written the program is to sit back and let
people do what they want to do. But that's not what happens; instead
somebody deliberately tries to obstruct the sharing of the program,
and in fact, he doesn't just try to obstruct it, he tries to pressure
other people into helping. Whenever a user signs a nondisclosure
agreement he has essentially sold out his fellow users. Instead of
following the golden rule and saying, “I like this program, my
neighbor would like the program, I want us both to have it”, instead
he said, “Yeah, give it to me. To hell with my neighbor! I'll help you
keep it away from my neighbor, just give it to me!”, and that spirit
is what does the spiritual harm. That attitude of saying, “To hell
with my neighbors, give ME a copy”.

After I ran into people saying they wouldn't let me have copies of
something, because they had signed some secrecy agreement, then when
somebody asked me to sign a thing like that I knew it was wrong. I
couldn't do to somebody else the thing that had made me so angry when
it was done to me.

But this is just one of the levels of harm. The second level of harm
comes when people want to change the program, because no program is
really right for all the people who would like to use it. Just as
people like to vary recipes, putting in less salt say, or maybe they
like to add some green peppers, so people also need to change programs
in order to get the effects that they need.

Now, the software owners don't really care whether people can change
the program or not, but it's useful for their ends to prevent people.
Generally when software is proprietary you can't get the sources, you
can't change it, and this causes a lot of wasted work by programmers,
as well as a lot of frustration by users. For example: I had a friend
who told me how she worked for many months at a bank where she was a
programmer, writing a new program. Now, there was a commercially
available program that was almost right, but it was just not quite the
thing they needed, and in fact as it was it was useless for them. The
amount of change it would have taken to make it do what they needed
was probably small, but because the sources of that program were not
available, that was impossible. She had to start over from scratch and
waste a lot of work. And we can only speculate about what fraction of
all the programmers in the world are wasting their time in this
fashion.

And then there is also the situation where a program is adequate make
do, but it's uncomfortable. For example: The first time we had a
graphics printer at MIT, we wrote the software ourselves, and we put
in lots of nice features, for example it would send you a message when
your job had finished printing, and it would send you a message if the
printer ran out of paper and you had a job in the queue, and lots of
other things that were what we wanted. We then got a much nicer
graphic printer, one of the first laser printers, but then the
software was supplied by Xerox, and we couldn't change it. They
wouldn't put in these features, and we couldn't, so we had to make do
with things that “half worked”. And it was very frustrating to know
that we were ready, willing and able to fix it, but weren't permitted.
We were sabotaged.

And then there are all the people who use computers and say that the
computers are a mystery to them, they don't know they work. Well how
can they possibly know? They can't read the programs they're using.
The only way people learn how programs should be written, or how
programs do what they do, is by reading the source code.

So I could only wonder whether the idea of the user who just thinks of
the computer as a tool is not actually a self-fulfilling prophecy, a
result of the practice of keeping source code secret.

Now the spiritual harm that goes with this kind of material harm, is
in the spirit of self-sufficiency. When a person spends a lot of time
using a computer system, the configuration of that computer system
becomes the city that he lives in. Just as the way our houses and
furniture are laid out, determines what it's like for us to live among
them, so that the computer system that we use, and if we can't change
the computer system that we use to suit us, then our lives are really
under the control of others. And a person who sees this becomes in a
certain way demoralized: “It's no use trying to change those things,
they're always going to be bad. No point even hassling it. I'll just
put in my time and … when it's over I'll go away and try not to think
about it any more”. That kind of spirit, that unenthusiasm is what
results from not being permitted to make things better when you have
feelings of public spirit.

The third level of harm is in the interaction between software
developers themselves. Because any field of knowledge advance most
when people can build on the work of others, but ownership of
information is explicitly designed to prevent anyone else to doing
that. If people could build on other people's work, then the ownership
would become unclear, so they make sure each new entry to the field
has to start from the beginning, and thus they greatly slow down the
advance of the field.

So we can see: How many spreadsheet systems were made all by different
companies, all without any benefit of understanding how it was done
before? Yes it's true, the first spreadsheet written wasn't perfect.
It probably only ran on certain kinds of computers, and it didn't do
some things in the best possible way. So there were various reasons
why certain people would want to rewrite parts of it. But if they had
only to rewrite the parts that they really wanted to improve, that
would have made for a lot less work. You may see how to make one
aspect of a system better, you may not see how to make another aspect
of the same system any better, in fact you might have a great deal of
trouble doing it as well. Now if you could take the part that you like
and redo only the part that you have an inspiration for, you could
have a system that's better in all ways, with much less work than it
now takes to write a completely new system. And we all know that a
system can often benefit from being completely rewritten, but that's
only if you can read the old one first.

Thus, the people in the programming field have evolved a way of
wasting a lot of their time and thus making apparently a need for more
programmers than we really need. Why is there a programmer shortage?
Because with intellectual property programmers have arranged to waste
half the work they do, so we seem to need twice as many programmers.
And so, when people point to the system of intellectual property and
say “look at the large employment statistics, look at how big this
industry is” what that really proves is that people are wasting a lot
of money and time. If they talk about looking for ways to improve
programmer productivity, they're happy to do this if it involves
superior tools, but to improve programmer productivity by getting rid
of the explicit things that is done to reduce programmer productivity,
that they're against. Because that would reduce the number of
programmers employed. There's something a little bit schizophrenic
there.

And the spiritual harm that corresponds to this level of material harm
is to the spirit of scientific cooperation, which used to be so strong
that scientists even in countries that were at war would continue
cooperating, because they knew that what they were doing had nothing
to do with the war, it was just for the long term benefit of humanity.
Nowadays, people don't care about the long term benefit of humanity
any more.

To get an idea of what it's like to obstruct the use of a program,
let's imagine that we had a sandwich, that you could eat, and it
wouldn't be consumed. You could eat it, and another person could eat
it, the same sandwich, any number of times, and it would always remain
just as nourishing as originally.

The best thing to do, the thing that we ought to do with this sandwich
is carry it around to the places where there are hungry people;
bringing it to as many mouths as possible, so that it feeds as many
people as possible. By all means, we should not have a price to eat
from this sandwich, because then people would not afford to eat it,
and it would be wasted.

The program is like this sandwich, but even more so because it can be
in many different places at once being eaten, used by different people
one after the other. It is as if this sandwich was enough to feed
everyone, everywhere, forever, and that were not allowed to happen,
because someone believed he should own it.

Now, the people who believe that they can own programs, generally put
forward two lines of argument for this. The first one is “I wrote it,
it is a child of my spirit, my heart, my soul is in this. How can
anyone take it away from me? Wherever it goes it's mine, mine,
MINE!!”. Well, it's sort of strange that most of them signs agreements
saying it belongs to the company they work for.

So I believe this is one of the things you can easily talk yourself
into believing is important, but you can just as easily convince
yourself it doesn't matter at all.

Usually, these people use this argument to demand the right to control
even how people can change a program. They say: “Nobody should be able
to mess up my work of art”. Well, imagine that the person who invented
a dish that you plan to cook had the right to control how you can cook
it, because it's his work of art. You want to leave out the salt, but
he says “Oh, no. I designed this dish, and it has to have this much
salt!” “But my doctor says it's not safe for me to eat salt. What can
I do?”.

Clearly, the person who is using the program is much closer to the
event. The use of the program affects him very directly, whereas it
only has a sort of abstract relation to the person who wrote the
program. And therefore, for the sake of giving people as much control
as possible over their own lives, it has to be the user who decides
those things.

The second line of argument they make is the economic one. “How will
people get payed to program?” they say, and there's a little bit of
real issue in this. But a lot of what they say is confusion. And the
confusion is, it's not at all the same to say “if we want to have a
lot of people programming we must arrange for them not to need to make
a living in any other fashion” on the one hand, and to say “We need to
have the current system, you need to get rich by programming” on the
other hand. There's a big difference between just making a living wage
and making the kind of money programmers, at least in the US make
nowadays. They always say: “How will I eat?”, but the problem is not
really how “Will he eat?”, but “How will he eat sushi?”. “How will I
have a roof over my head?”, but the real problem is “How can he afford
a condo?”.

The current system were chosen by the people who invest in software
development, because it gives them the possibility of making the most
possible money, not because it's the only way anyone can ever come up
with money to support a system development effort. In fact, even as
recently as ten and fifteen years ago it was common to support
software development in other ways. For example, those Digital
operating systems that were free, even in the early seventies, were
developed by people who were paid for their work. Many useful programs
has been developed at universities. Nowadays those programs are often
sold, but fifteen years ago they were usually free, yet the people
were paid for their work.

When you have something like a program, like an infinite sandwich,
like a road, which has to be built once, but once it is built it
pretty much doesn't matter how much you use it, there's no cost in
using it, generally it's better if we don't put any price on using it.
And there are plenty of those things that we develop now, and pay
people to build. For example, all the streets out there. It's very
easy to find people who will program without being paid; it really is
impossible to find people who will build streets without being paid.
Building streets is not creative and fun like programming. But we have
plenty of streets out there, we do come up with the money to pay them,
and it's much better the way we do it than if if we said: “Let's have
companies go and build streets and put toll booths up, and then every
time you turn another street corner, you pay another toll. And then
the companies that picked the good places to put their streets, they
will be profitable, and the others will go bankrupt.”

There's a funny thing that happens whenever someone comes up with a
way of making lots of money by hoarding something. Until that time
you've probably had lots and lots of people who were really
enthusiastic and eager to work in that field, the only sort of
question is how can they get any sort of livelihood at all. If we
think of mathematicians for example, there are a lot more people who
want to be pure mathematicians than there is funding for anybody to be
pure mathematicians. And even when you do get funding, you don't get
very much, they don't live well. And for musicians it's even worse. I
saw a statistics for how much the average musician, the average person
devoting most of his time trying to be a musician, in Massachusetts
made; it was something like half the median income or less. It is
barely enough to live on, it's difficult. But there are lots of them
trying to do that. And then, somehow when it gets generally possible
to get very well paid to do something, all those people disappear, and
people start saying “nobody will do it unless they get paid that
well”.

And I saw this happen in the field of programming. The very same
people who used to work at the AI lab and get payed very little and
love it, now wouldn't dream of working for less than fifty thousand
dollars a year. What happened? When you dangle before people the
possibility of making lots of money, when they see that other people
doing similar work are getting paid that much money, they feel that
they should get the same, and thus no-one is willing to continue the
old way. And it's easy after this has happened to think that paying
people a lot of money is the only way it could be, but that's not so.
If the possibility of making a lots of money did not exist, you would
have people who would accept doing it for a little money, specially
when it's something that is creative and fun.

Now I saw the unique world of the AI lab destroyed, and I saw that
selling software was an intrinsic part of what had destroyed it, and I
saw also, as I explained before, how you need to have free software in
order to have a community like that. But then thinking about it more,
I realized all these ways in which hoarding software hurts all of
society, most specially by pressuring people to sell out their
neighbors and causing social decay. The same spirit that leads people
to watch while somebody in the street is getting stabbed and not tell
anyone. The spirit that we can see so many companies all around us
displaying all the time. And it was clear to me I had a choice, I
could become part of that world and feel unhappy about what I was
doing with my life, or I could decide to fight it. So I decided to
fight it. I've dedicated my career to try to rebuild the software
sharing community, to trying to put an end to the phenomenon of
hoarding generally useful information. And the GNU system is a means
to this end. It is a technical means to a social end. With the GNU
system, I hope to vaccinate the users against the threat of the
software hoarders.

Right now the hoarders essentially claims the power to render a
person's computer useless. There used to be people in the US, most
commonly about fifty years ago, they were in the Mafia, they would go
up to stores and bars, especially bars when bars were illegal of
course. They would go up and say: “A lot of places around here have
been burning down lately. You wouldn't want your place to burn down,
would you? Well we can protect you from fires, you just have to pay us
a thousand dollars a month, and we'll make sure you don't have a fire
here”. And this was called “the protection racket”. Now we have
something where a person says “You got a nice computer there, and
you've got some programs there that you're using. Well, if you don't
want those programs to disappear, if you don't want the police to come
after you, you better pay me a thousand dollars, and I'll give you a
copy of this program with a license”, and this is called “the software
protection racket”.

Really all they're doing is interfering with everybody else doing what
needs to be done, but they're pretending as much to them selves as to
the rest of us, that they are providing a useful function. Well, what
I hope is that when that software Mafia guy comes up and says, “You
want those programs to disappear on your computer?”, the user can say
“I'm not afraid of you any more. I have this free GNU software, and
there's nothing you can do to me now.”

Now, one of the justifications people sometimes offer for owning
software, is the idea of giving people an incentive to produce things.
I support the idea of private enterprise in general, and the idea of
hope to make money by producing things that other people like to use,
but it's going haywire in the field of software now. Producing a
proprietary program is not the same contribution to society as
producing the same program and letting it be free. Because writing the
program is just a potential contribution to society. The real
contribution to the wealth of society happens only when the program is
used. And if you prevent the program from being used, the contribution
doesn't actually happen. So, the contribution that society needs is
not these proprietary programs that everyone has such an incentive to
make, the contribution we really want is free software, so our society
is going haywire because it gives people an incentive to do what is
not very useful, and no incentive to do what is useful. Thus the basic
idea of private enterprise is not being followed, and you could even
say that the society is neurotic. After all when an individual
encourages in others behavior that is not good for that individual we
call this a neurosis. Here society is behaving in that fashion,
encouraging programmers to do things that is not good for society.

I'm unusual. I'd rather believe that I'm a good member of society and
that I'm contributing something, than feel that I'm ripping society
off successfully, and that's why I've decided to do what I have done.
But every one is at least a little bit bothered by the feeling that
they are getting paid to do what's not really useful. So let's stop
defending this idea of incentives to do the wrong thing and let's at
least try to come up with arrangements to encourage people to do the
right thing, which is to make free software.

Thank you.

[After this RMS answered questions for about an hour. I have only
included a very few of the questions and answers in this version. The
tape was bad, and I didn't have the time to do a proper job on all of
it]

Q: Has anyone tried to make problems for you?

    A: The only time anyone has tried to make a problem for me was
those owners, so called, self-styled owners of Gosling Emacs. Aside
from that they have no grounds to do so, so there is not much they can
do. By the way, I'd like to call everyone's attention to the way in
which people use language to try to encourage people to think certain
thoughts and not think of others. Much of the terminology current in
the field was chosen by the self-styled software owners to try to
encourage you to try to make you see software as similar to material
objects that are property, and overlook the differences. The most
flagrant example of this is the term “pirate”. Please refuse to use to
use the term “pirate” to describe somebody who wishes to share
software with his neighbor like a good citizen.

    I forgot to tell you this: The idea of copyright was invented
after the printing press. In ancient times authors copied from each
other freely, and this was not considered wrong, and it was even very
useful: The only way certain authors works have survived, even in
fragments, is because some of them were quoted at length in other
works which have survived.

    This was because books were copied one copy at the time. It was
ten times as hard to make ten copies as it was to make one copy. Then
the printing press was invented, and this didn't prevent people from
copying books by hand, but by comparison with printing them, copying
by hand was so unpleasant that it might as well have been impossible.

    When books could only be made by mass production, copyright then
started to make sense and it also did not take away the freedom of the
reading public. As a member of the public who didn't own a printing
press, you couldn't copy a book anyway. So you weren't losing any
freedom just because there were copyrights. Thus copyright was
invented, and made sense morally because of a technological change.
Now the reverse change is happening. Individual copying of information
is becoming better and better, and we can see that the ultimate
progress of technology is to make it possible to copy any kind of
information. [break due to turning of tape]

    Thus we are back in the same situation as in the ancient world
where copyright did not make sense.

    If we consider our idea of property, they come from material
objects. Material objects satisfy a conservation law, pretty much. Yes
it's true I can break a chalk in half, that's not it, and it gets worn
down, it gets consumed. But basically this is one chair [pointing at a
chair]. I can't just sort of snap my finger and have two chairs. The
only way to get another one is to build it just the way the first one
was build. It takes more raw materials, it takes more work of
production, and our ideas of property were evolved to make moral sense
to fit these facts.

    For a piece of information that anyone can copy, the facts are
different. And therefore the moral attitudes that fit are different.
Our moral attitudes comes from thinking how much it will help people
and how much it will hurt people to do certain things. With a material
object, you can come and take away this chair, but you couldn't come
and copy it. And if you took away the chair, it wouldn't be producing
anything, so there's no excuse. I somebody says: “I did the work to
make this one chair, and only one person can have this chair, it might
as well be me”, we might as well say: “Yeah, that makes sense”. When a
person says: “I carved the bits on this disk, only one person can have
this disk, so don't you dare take it away from me”, well that also
make sense. If only one person is going to have the disk, it might as
well be the guy who owns that disk.

    But when somebody else comes up and says: “I'm not going to hurt
your disk, I'm just gonna magically make another one just like it and
then I'll take it away and then you can go on using this disk just the
same as before”, well, it's the same as if somebody said: “I've got a
magic chair copier. You can keep on enjoying your chair, sitting in
it, having it always there when you want it, but I'll have a chair
too”. That's good.

    If people don't have to build, they can just snap their fingers
and duplicate them, that's wonderful. But this change in technology
doesn't suit the people who want to be able to own individual copies
and can get money for individual copies. That's an idea that only fits
conserved objects. So they do their best to render programs like
material objects. Have you wondered why, when you go to the software
store and buy a copy of a program it comes in something that looks
like a book? They want people to think as if they were getting a
material object, not to realize what they have really got in the form
of digital copyable data.

    What is a computer after all but a universal machine? You've
probably studied universal Turing machines, the machines that can
imitate any other machine. The reason a universal machine is so good
is because you can make it imitate any other machine and the
directions can be copied and changed, exactly the things you can't do
with a material object. And those are exactly what the software
hoarders want to stop the public from doing. They want to have the
benefit of the change in technology, to universal machines, but they
don't want the public to get that benefit.

    Essentially they are trying to preserve the “material object age”,
but it's gone, and we should get our ideas of right and wrong in sync
with the actual facts of the world we live in.
Q: So it boils down to ownership of information. Do you think there
are any instances where, your opinion, it's right to own information?

    A: With information that's not generally useful, or is of a
personal nature, I would say it's OK. In other words not information
about how to do things, but information about what you intend to do.
Information whose only value to others is speculative, that is they
can take some money away from you, but they can't actually create
anything with it. It's perfectly reasonable I'd say to keep that sort
of thing secret and controlled.

    But in terms of creative information, information that people can
use or enjoy, and that will be used and enjoyed more the more people
who have it, always we should encourage the copying.