path: root/talermerchantdemos/blog/articles/en/stallman-kth.html

<!--#include virtual="/server/header.html" -->
<!-- Parent-Version: 1.96 -->
<!-- This page is derived from /server/standards/boilerplate.html -->
<!--#set var="TAGS" value="speeches" -->
<!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
<title>RMS lecture at KTH (Sweden), 1986
- GNU Project - Free Software Foundation</title>
<style type="text/css" media="screen"><!--
#content span { font-style: italic; color: #505050; }
--></style>
<!--#include virtual="/philosophy/po/stallman-kth.translist" -->
<!--#include virtual="/server/banner.html" -->
<!--#include virtual="/philosophy/ph-breadcrumb.html" -->
<!--GNUN: OUT-OF-DATE NOTICE-->
<!--#include virtual="/server/top-addendum.html" -->
<div class="article reduced-width">
<h2>RMS lecture at KTH (Sweden), 1986</h2>

<div class="infobox">
<p>Transcript of Richard Stallman's speech at the <i>Kungliga Tekniska
H&ouml;gskolan</i> (Royal Institute of Technology) in
Stockholm, Sweden, arranged by the student society <i>Datorf&ouml;reningen
Stacken</i> on 30&nbsp;October&nbsp;1986.
</p>
</div>
<hr class="thin" />

<div class="introduction">
<p><i>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.</i></p>
</div>

<p><b>Rms:</b> 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
<abbr title="Massachusetts Institute of Technology">MIT</abbr>
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.</p>

<p><span>[Someone else says: &ldquo;<i>Janne, han trenger ingen
mike.</i>&rdquo; (Translation: &ldquo;Janne, he doesn't need a
mike.&rdquo;)]</span></p>

<p>Jan, are you prepared to go running out to fetch the
other people?</p>

<p><b>Jmr:</b> I am looking for a microphone, and someone tells
me it is inside this locked box.</p>

<p><b>Rms:</b> 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.</p>

<p>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?  <span>[Answer:
Yeaaah]</span></p>

<p>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.</p>

<p>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: &ldquo;This room is
Mine, I can lock it, to hell with everyone else,&rdquo; and that is
exactly the spirit that we must teach them not to have.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>But one of the problems I had to face was the problem of
<a href="/philosophy/categories.html#ProprietarySoftware">proprietary
software</a>.  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
&ldquo;take these back and bring us some new ones.&rdquo;</p>

<p>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.</p>

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

<p>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 &ldquo;munching squares&rdquo; 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.</p>

<p>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.</p>

<p>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.</p>

<p>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, &ldquo;we're going to have a disaster,
we must have commercial software,&rdquo; and they said &ldquo;we can
expect the company to maintain it.&rdquo;  It proved that they were
utterly wrong, but that's what they did.</p>

<p>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.</p>

<p>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 &ldquo;so-and-so must be reading your mail, can it be that
mail files aren't properly protected on your system?&rdquo; &ldquo;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.&rdquo;
Some people just don't know when they're well off.</p>

<p>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.</p>

<p>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: &ldquo;There was another attempt to seize power.  So far the
aristocratic forces have been defeated&mdash;Radio Free OZ.&rdquo;
Later I discovered that &ldquo;Radio Free OZ&rdquo; is one of the
things used by Firesign Theater.  I didn't know that at the time.</p>

<p>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 &ldquo;empty
password,&rdquo; 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 &ldquo;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.&rdquo;</p>

<p>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.</p>

<p>But that machine wasn't designed also to support the phenomenon
called &ldquo;tourism.&rdquo;  Now &ldquo;tourism&rdquo; 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
&ldquo;But what if he starts changing our system programs?&rdquo; 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.</p>

<p>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.</p>

<p>But the ITS machines had certain other features that helped prevent
this from getting out of hand, one of these was the &ldquo;spy&rdquo;
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.</p>

<p>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 &hellip; <span>[At this point RMS is interrupted by
tremendous applause.]</span> &hellip; for.</p>

<p>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.</p>

<p>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 &ldquo;million monkeys
typing, and eventually they'll come up with something useful&rdquo;
school of system development.</p>

<p>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.</p>

<p>About three and a half year ago it was clear to me that I should
start developing a <a href="/philosophy/free-sw.html">free
software</a> 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.</p>

<p>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.</p>

<p>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&mdash;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 &ldquo;Gnu's Not
Unix.&rdquo;  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: &ldquo;Tint Is Not Teco,&rdquo; and later on
it went through names such as &ldquo;SINE&rdquo; for &ldquo;SINE Is
Not Emacs,&rdquo; and FINE for &ldquo;Fine Is Not Emacs,&rdquo; and
EINE for &ldquo;Eine Is Not Emacs,&rdquo; and ZWEI for &ldquo;Zwei Was
Eine Initially,&rdquo; and ultimately now arrives at GNU.</p>

<p>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 &ldquo;the free university compiler kit,&rdquo; 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 &ldquo;No, the university might be
free, but the software they develop isn't,&rdquo; 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.</p>

<p>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 &ldquo;off-color PASCAL.&rdquo;</p>

<p>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 &ldquo;string&rdquo; in that language was a
parameterized type; you could say <code>string(n)</code> if you
wanted a string of a particular length; you could also just say
<code>string</code>, 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.</p>

<p>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
<code>forward</code> 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>(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.)</p>

<p>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.</p>

<p>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.</p>

<p>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: &ldquo;Give me the object of type FLOAT
or DOUBLE at this address&rdquo; 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 &ldquo;value
history.&rdquo;  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
<code>PRINT&nbsp;*$.next</code>, which says: &ldquo;Get
the next field out of the last
thing you showed me, and then display the structure that points
at.&rdquo;  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.</p>

<p>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 &ldquo;stop when you get to this point in the program, but only if
a certain expression is true.&rdquo;  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
<code>$foo+=5</code> to increment the value of <code>$foo</code> by
five, or just <code>$foo++</code> 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
<code>$foo--==0</code>.  Does everyone follow that?  Decrement foo
and if it's zero now, break.  And then you set <code>$foo</code> 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:</p>

<pre><code>PRINT X[$foo++]</code></pre>

<p>But first you do</p>

<pre><code>SET $foo=0</code></pre>

<p>Okay, when you do that [points at the <code>PRINT</code>
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
<code>Define Mumble</code>, and then you give some lines of commands
and then you say <code>end</code>.  And now there is defined a
<code>Mumble</code> 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 <code>help</code> features just like the
built-in commands.</p>

<p>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:</p>

<pre><code>SET $PC=&lt;some number&gt;</code></pre>

<p>So you can set the program counter.  You can also set the stack
pointer, or you can say</p>

<pre><code>SET $SP+=&lt;something&gt;</code></pre>

<p>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 <code>RETURN</code> command. You select a stack frame and you
say <code>RETURN</code>, 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.</p>

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

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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:</p>

<pre>
  <code>r[3]=r[2]+4</code>
</pre>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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:</p>

<pre>
     <code>(set (reg 2)</code>
          <code>(+ (reg 2)</code>
             <code>(int 4)))</code>
</pre>

<p>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: <code>reg</code> always has an integer,
because registers are numbered, but <code>+</code> 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

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

<p>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 <code>.+1</code>,
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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p><span>[Question: Do you have a code generator for 32000?]</span> 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.</p>

<p>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
&ldquo;profiling&rdquo; 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.</p>

<p>The other sizable part of the system that exist, is the kernel.
<span>[Question: A pause?]</span> 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.</p>

<p>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 &ldquo;capability
ports&rdquo; 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.</p>

<p>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.</p>

<p>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 <code>tail</code> 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.</p>

<p>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 <code>FOO</code> it
means &ldquo;Search the versions that exists for FOO and take the
latest one.&rdquo;  But if you say <code>FOO.</code> it means
&ldquo;use exactly the name FOO and none other.&rdquo;  If you say
<code>FOO.3.</code> it says &ldquo;use exactly the name FOO.3&rdquo;
which of course is version three of FOO and none other.  On output, if
you just say <code>FOO</code>, it will eventually create a new
version of FOO, but if you say <code>FOO.</code> it
will write a file named exactly FOO.</p>

<p>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.</p>

<p>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.</p>

<p>And this idea can be connected up to &ldquo;star matching,&rdquo;
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:</p>

<pre>
  <code>foo.1 foo.2 bar.8</code>
</pre>

<p>If I say  <code>*</code>, that's equivalent to</p>
<pre>
  <code>foo bar</code>
</pre>

<p>because it takes all the names and gets rid of their versions, and
takes all the distinct ones.  But if I say <code>*.</code> 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
<code>*.c</code> and <code>*.c.</code> this [the first] would give
you essentially versionless references to all the <code>.c</code>
files, whereas this [the second] will give you all the versions
&hellip; well this actually wouldn't, you'd have to say
<code>*.c.*.</code>;  I haven't worked out the details here.</p>

<p>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 &ldquo;<kbd>halt</kbd>&rdquo; 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>People always ask me &ldquo;When is it going to be finished?&rdquo;
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 &ldquo;how can you help make it get
finished sooner?&rdquo; 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 &ldquo;RMS@GNU.ORG&rdquo; (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.</p>

<p><strong>
[Here we had a 15 min. break]
</strong></p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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
&ldquo;Commune,&rdquo; 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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, &ldquo;I like this
program, my neighbor would like the program, I want us both to have
it,&rdquo; instead he said, &ldquo;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!&rdquo; and that spirit is what does the spiritual harm.
That attitude of saying, &ldquo;To hell with my neighbors, give ME a
copy.&rdquo;</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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 &ldquo;half worked.&rdquo;  And it was very
frustrating to know that we were ready, willing and able to fix it,
but weren't permitted. We were sabotaged.</p>

<p>And then there are all the people who use computers and say that
the computers are a mystery to them, they don't know [how] 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.</p>

<p>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.</p>

<p>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: &ldquo;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 &hellip; when it's over
I'll go away and try not to think about it any more.&rdquo;  That kind
of spirit, that unenthusiasm is what results from not being permitted
to make things better when you have feelings of public spirit.</p>

<p>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.</p>

<p>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.</p>

<p>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 &ldquo;look at the large employment statistics, look at how big
this industry is&rdquo; 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>Now, the people who believe that they can own programs, generally
put forward two lines of argument for this.  The first one is &ldquo;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!!&rdquo;  Well, it's sort of strange that most of them
signs agreements saying it belongs to the company they work for.</p>

<p>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.</p>

<p>Usually, these people use this argument to demand the right to
control even how people can change a program.  They say: &ldquo;Nobody
should be able to mess up my work of art.&rdquo;  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 &ldquo;Oh, no.  I designed this
dish, and it has to have this much salt!&rdquo; &ldquo;But my doctor
says it's not safe for me to eat salt.  What can I do?&rdquo;</p>

<p>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.</p>

<p>The second line of argument they make is the economic one.
&ldquo;How will people get payed to program?&rdquo; 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 &ldquo;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&rdquo; on the one hand, and to say &ldquo;We need to have the
current system, you need to get rich by programming&rdquo; 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: &ldquo;How will I eat?&rdquo; but the
problem is not really how &ldquo;Will he eat?&rdquo; but &ldquo;How
will he eat sushi?&rdquo; &ldquo;How will I have a roof over my
head?&rdquo; but the real problem is &ldquo;How can he afford a
condo?&rdquo;</p>

<p>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.</p>

<p>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:
&ldquo;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.&rdquo;</p>

<p>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 &ldquo;nobody will do it
unless they get paid that well.&rdquo;</p>

<p>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.</p>

<p>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.</p>

<p>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: &ldquo;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.&rdquo;  And this was called &ldquo;the protection
racket.&rdquo;  Now we have something where a person says &ldquo;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,&rdquo; and this is called &ldquo;the software protection
racket.&rdquo;</p>

<p>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, &ldquo;You want those programs to disappear on your
computer?&rdquo; the user can say &ldquo;I'm not afraid of you any
more.  I have this free GNU software, and there's nothing you can do
to me now.&rdquo;</p>

<p>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.</p>

<p>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.</p>

<p>Thank you.</p>

<p><strong>[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.]
</strong></p>

<dl>
<dt><b>Q:</b> Has anyone tried to make problems for you?</dt>

<dd><p><b>A:</b> 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 &ldquo;pirate.&rdquo;
Please refuse to use the term &ldquo;pirate&rdquo; to describe
somebody who wishes to share software with his neighbor like a good
citizen.</p>

<p>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.</p>

<p>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.</p>

<p>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. <span>[break due to turning of tape]</span></p>

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

<p>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.</p>

<p>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: &ldquo;I did the work
to make this one chair, and only one person can have this chair, it
might as well be me,&rdquo; we might as well say: &ldquo;Yeah, that makes
sense.&rdquo;  When a person says: &ldquo;I carved the bits on this
disk, only one person can have this disk, so don't you dare take it
away from me,&rdquo; 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.</p>

<p>But when somebody else comes up and says: &ldquo;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,&rdquo; well, it's the same as if somebody said:
&ldquo;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.&rdquo;  That's good.</p>

<p>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.</p>

<p>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.</p>

<p>Essentially they are trying to preserve the &ldquo;material object
age,&rdquo; 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.</p>
</dd>

<dt><b>Q:</b> So it boils down to ownership of information.  Do you
think there are any instances where, [in] your opinion, it's right to own
information?</dt>

<dd><p><b>A:</b> 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.</p>

<p>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.</p>
</dd>
</dl>
</div>

</div><!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.html" -->
<div id="footer" role="contentinfo">
<div class="unprintable">

<p>Please send general FSF &amp; GNU inquiries to
<a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>.
There are also <a href="/contact/">other ways to contact</a>
the FSF.  Broken links and other corrections or suggestions can be sent
to <a href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p><!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">
        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and contributing translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Please see the <a
href="/server/standards/README.translations.html">Translations
README</a> for information on coordinating and contributing translations
of this article.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->

<p>
Copyright &copy; 1987, 2022 Richard Stallman and Bjrn Remseth
</p>
<p>
Permission is granted to make and distribute verbatim copies of this
transcript as long as the copyright and this permission notice appear.
</p>

<!--#include virtual="/server/bottom-notes.html" -->

<p class="unprintable">Updated:
<!-- timestamp start -->
$Date: 2022/06/10 16:48:04 $
<!-- timestamp end -->
</p>
</div>
</div><!-- for class="inner", starts in the banner include -->
</body>
</html>