copying.paper

windows版本的emacs

This is psychosocial harm associated with the material harm of
discouraging use of the program.

   Many users unconsciously recognize the wrong of refusing to share, so
they decide to ignore the licenses and laws, and share programs anyway.
But they often feel guilty about doing so.  They know that they must
break the laws in order to be good neighbors, but they still consider
the laws authoritative, and they conclude that being a good neighbor
(which they are) is naughty or shameful.  That is also a kind of
psychosocial harm, but one can escape it by deciding that these licenses
and laws have no moral force.

   Programmers also suffer psychosocial harm knowing that many users
will not be allowed to use their work.  This leads to an attitude of
cynicism or denial.  A programmer may describe enthusiastically the
work that he finds technically exciting; then when asked, "Will I be
permitted to use it?", his face falls, and he admits the answer is no.
To avoid feeling discouraged, he either ignores this fact most of the
time or adopts a cynical stance designed to minimize the importance of
it.

   Since the age of Reagan, the greatest scarcity in the United States
is not technical innovation, but rather the willingness to work together
for the public good.  It makes no sense to encourage the former at the
expense of the latter.

Obstructing Custom Adaptation of Programs
=========================================

   The second level of material harm is the inability to adapt programs.
The ease of modification of software is one of its great advantages over
older technology.  But most commercially available software isn't
available for modification, even after you buy it.  It's available for
you to take it or leave it, as a black box--that is all.

   A program that you can run consists of a series of numbers whose
meaning is obscure.  No one, not even a good programmer, can easily
change the numbers to make the program do something different.

   Programmers normally work with the "source code" for a program, which
is written in a programming language such as Fortran or C.  It uses
names to designate the data being used and the parts of the program, and
it represents operations with symbols such as `+' for addition and `-'
for subtraction.  It is designed to help programmers read and change
programs.  Here is an example; a program to calculate the distance
between two points in a plane:

     float
     distance (p0, p1)
          struct point p0, p1;
     {
       float xdist = p1.x - p0.x;
       float ydist = p1.y - p0.y;
       return sqrt (xdist * xdist + ydist * ydist);
     }

   Here is the same program in executable form, on the computer I
normally use:

     1314258944      -232267772      -231844864      1634862
     1411907592      -231844736      2159150         1420296208
     -234880989      -234879837      -234879966      -232295424
     1644167167      -3214848        1090581031      1962942495
     572518958       -803143692      1314803317

   Source code is useful (at least potentially) to every user of a
program.  But most users are not allowed to have copies of the source
code.  Usually the source code for a proprietary program is kept secret
by the owner, lest anybody else learn something from it.  Users receive
only the files of incomprehensible numbers that the computer will
execute.  This means that only the program's owner can change the
program.

   A friend once told me of working as a programmer in a bank for about
six months, writing a program similar to something that was commercially
available.  She believed that if she could have gotten source code for
that commercially available program, it could easily have been adapted
to their needs.  The bank was willing to pay for this, but was not
permitted to--the source code was a secret.  So she had to do six
months of make-work, work that counts in the GNP but was actually waste.

   The MIT Artificial Intelligence lab (AI lab) received a graphics
printer as a gift from Xerox around 1977.  It was run by free software
to which we added many convenient features.  For example, the software
would notify a user immediately on completion of a print job.  Whenever
the printer had trouble, such as a paper jam or running out of paper,
the software would immediately notify all users who had print jobs
queued.  These features facilitated smooth operation.

   Later Xerox gave the AI lab a newer, faster printer, one of the first
laser printers.  It was driven by proprietary software that ran in a
separate dedicated computer, so we couldn't add any of our favorite
features.  We could arrange to send a notification when a print job was
sent to the dedicated computer, but not when the job was actually
printed (and the delay was usually considerable).  There was no way to
find out when the job was actually printed; you could only guess.  And
no one was informed when there was a paper jam, so the printer often
went for an hour without being fixed.

   The system programmers at the AI lab were capable of fixing such
problems, probably as capable as the original authors of the program.
Xerox was uninterested in fixing them, and chose to prevent us, so we
were forced to accept the problems.  They were never fixed.

   Most good programmers have experienced this frustration.  The bank
could afford to solve the problem by writing a new program from
scratch, but a typical user, no matter how skilled, can only give up.

   Giving up causes psychosocial harm--to the spirit of self-reliance.
It is demoralizing to live in a house that you cannot rearrange to suit
your needs.  It leads to resignation and discouragement, which can
spread to affect other aspects of one's life.  People who feel this way
are unhappy and do not do good work.

   Imagine what it would be like if recipes were hoarded in the same
fashion as software.  You might say, "How do I change this recipe to
take out the salt?", and the great chef would respond, "How dare you
insult my recipe, the child of my brain and my palate, by trying to
tamper with it?  You don't have the judgment to change my recipe and
make it work right!"

   "But my doctor says I'm not supposed to eat salt!  What can I do?
Will you take out the salt for me?"

   "I would be glad to do that; my fee is only $50,000."  Since the
owner has a monopoly on changes, the fee tends to be large.  "However,
right now I don't have time.  I am busy with a commission to design a
new recipe for ship's biscuit for the Navy Department.  I might get
around to you in about two years."

Obstructing Software Development
================================

   The third level of material harm affects software development.
Software development used to be an evolutionary process, where a person
would take an existing program and rewrite parts of it for one new
feature, and then another person would rewrite parts to add another
feature; in some cases, this continued over a period of twenty years.
Meanwhile, parts of the program would be "cannibalized" to form the
beginnings of other programs.

   The existence of owners prevents this kind of evolution, making it
necessary to start from scratch when developing a program.  It also
prevents new practitioners from studying existing programs to learn
useful techniques or even how large programs can be structured.

   Owners also obstruct education.  I have met bright students in
computer science who have never seen the source code of a large
program.  They may be good at writing small programs, but they can't
begin to learn the different skills of writing large ones if they can't
see how others have done it.

   In any intellectual field, one can reach greater heights by standing
on the shoulders of others.  But that is no longer generally allowed in
the software field--you can only stand on the shoulders of the other
people *in your own company*.

   The associated psychosocial harm affects the spirit of scientific
cooperation, which used to be so strong that scientists would cooperate
even when their countries were at war.  In this spirit, Japanese
oceanographers abandoning their lab on an island in the Pacific
carefully preserved their work for the invading U.S. Marines, and left a
note asking them to take good care of it.

   Conflict for profit has destroyed what international conflict spared.
Nowadays scientists in many fields don't publish enough in their papers
to enable others to replicate the experiment.  They publish only enough
to let readers marvel at how much they were able to do.  This is
certainly true in computer science, where the source code for the
programs reported on is usually secret.

It Does Not Matter How Sharing Is Restricted
============================================

   I have been discussing the effects of preventing people from copying,
changing and building on a program.  I have not specified how this
obstruction is carried out, because that doesn't affect the conclusion.
Whether it is done by copy protection, or copyright, or licenses, or
encryption, or ROM cards, or hardware serial numbers, if it *succeeds*
in preventing use, it does harm.

   Users do consider some of these methods more obnoxious than others.
I suggest that the methods most hated are those that accomplish their
objective.

Software Should be Free
=======================

   I have shown how ownership of a program--the power to restrict
changing or copying it--is obstructive.  Its negative effects are
widespread and important.  It follows that society shouldn't have
owners for programs.

   Another way to understand this is that what society needs is free
software, and proprietary software is a poor substitute.  Encouraging
the substitute is not a rational way to get what we need.

   Vaclav Havel has advised us to "Work for something because it is
good, not just because it stands a chance to succeed."  A business
making proprietary software stands a chance of success in its own narrow
terms, but it is not what is good for society.

Why People Will Develop Software
********************************

   If we eliminate intellectual property as a means of encouraging
people to develop software, at first less software will be developed,
but that software will be more useful.  It is not clear whether the
overall delivered user satisfaction will be less; but if it is, or if
we wish to increase it anyway, there are other ways to encourage
development, just as there are ways besides toll booths to raise money
for streets.  Before I talk about how that can be done, first I want to
question how much artificial encouragement is truly necessary.

Programming is Fun
==================

   There are some lines of work that few will enter except for money;
road construction, for example.  There are other fields of study and
art in which there is little chance to become rich, which people enter
for their fascination or their perceived value to society.  Examples
include mathematical logic, classical music, and archaeology; and
political organizing among working people.  People compete, more sadly
than bitterly, for the few funded positions available, none of which is
funded very well.  They may even pay for the chance to work in the
field, if they can afford to.

   Such a field can transform itself overnight if it begins to offer the
possibility of getting rich.  When one worker gets rich, others demand
the same opportunity.  Soon all may demand large sums of money for doing
what they used to do for pleasure.  When another couple of years go by,
everyone connected with the field will deride the idea that work would
be done in the field without large financial returns.  They will advise
social planners to ensure that these returns are possible, prescribing
special privileges, powers and monopolies as necessary to do so.

   This change happened in the field of computer programming in the past
decade.  Fifteen years ago, there were articles on "computer
addiction": users were "onlining" and had hundred-dollar-a-week habits.
It was generally understood that people frequently loved programming
enough to break up their marriages.  Today, it is generally understood
that no one would program except for a high rate of pay.  People have
forgotten what they knew fifteen years ago.

   When it is true at a given time that most people will work in a
certain field only for high pay, it need not remain true.  The dynamic
of change can run in reverse, if society provides an impetus.  If we
take away the possibility of great wealth, then after a while, when the
people have readjusted their attitudes, they will once again be eager
to work in the field for the joy of accomplishment.

   The question, "How can we pay programmers?", becomes an easier
question when we realize that it's not a matter of paying them a
fortune.  A mere living is easier to raise.

Funding Free Software
=====================

   Institutions that pay programmers do not have to be software houses.
Many other institutions already exist which can do this.

   Hardware manufacturers find it essential to support software
development even if they cannot control the use of the software.  In
1970, much of their software was free because they did not consider
restricting it.  Today, their increasing willingness to join
consortiums shows their realization that owning the software is not
what is really important for them.

   Universities conduct many programming projects.  Today, they often
sell the results, but in the 1970s, they did not.  Is there any doubt
that universities would develop free software if they were not allowed
to sell software?  These projects could be supported by the same
government contracts and grants which now support proprietary software
development.