copying.paper

windows版本的emacs

(For more information about the GNU project and free software,
look at the files `GNU', `COPYING', and `DISTRIB', in the same
directory as this file.)


                      Why Software Should Be Free

                          by Richard Stallman

                      (Version of April 24, 1992)

     Copyright (C) 1991, 1992, Free Software Foundation, Inc.
     Verbatim copying and redistribution is permitted
     without royalty; alteration is not permitted.

Introduction
************

   The existence of software inevitably raises the question of how
decisions about its use should be made.  For example, suppose one
individual who has a copy of a program meets another who would like a
copy.  It is possible for them to copy the program; who should decide
whether this is done?  The individuals involved?  Or another party,
called the "owner"?

   Software developers typically consider these questions on the
assumption that the criterion for the answer is to maximize developers'
profits.  The political power of business has led to the government
adoption of both this criterion and the answer proposed by the
developers: that the program has an owner, typically a corporation
associated with its development.

   I would like to consider the same question using a different
criterion: the prosperity and freedom of the public in general.

   This answer cannot be decided by current law--the law should conform
to ethics, not the other way around.  Nor does current practice decide
this question, although it may suggest possible answers.  The only way
to judge is to see who is helped and who is hurt by recognizing owners
of software, why, and how much.  In other words, we should perform a
cost-benefit analysis on behalf of society as a whole, taking account of
individual freedom as well as production of material goods.

   In this essay, I will describe the effects of having owners, and show
that the results are detrimental.  My conclusion is that programmers
have the duty to encourage others to share, redistribute, study and
improve the software we write: in other words, to write "free"
software.(1)

How Owners Justify Their Power
******************************

   Those who benefit from the current system where programs are property
offer two arguments in support of their claims to own programs: the
emotional argument and the economic argument.

   The emotional argument goes like this: "I put my sweat, my heart, my
soul into this program.  It comes from *me*, it's *mine*!"

   This argument does not require serious refutation.  The feeling of
attachment is one that programmers can cultivate when it suits them; it
is not inevitable.  Consider, for example, how willingly the same
programmers usually sign over all rights to a large corporation for a
salary; the emotional attachment mysteriously vanishes.  By contrast,
consider the great artists and artisans of medieval times, who didn't
even sign their names to their work.  To them, the name of the artist
was not important.  What mattered was that the work was done--and the
purpose it would serve.  This view prevailed for hundreds of years.

   The economic argument goes like this: "I want to get rich (usually
described inaccurately as `making a living'), and if you don't allow me
to get rich by programming, then I won't program.  Everyone else is like
me, so nobody will ever program.  And then you'll be stuck with no
programs at all!"  This threat is usually veiled as friendly advice
from the wise.

   I'll explain later why this threat is a bluff.  First I want to
address an implicit assumption that is more visible in another
formulation of the argument.

   This formulation starts by comparing the social utility of a
proprietary program with that of no program, and then concludes that
proprietary software development is, on the whole, beneficial, and
should be encouraged.  The fallacy here is in comparing only two
outcomes--proprietary software vs. no software--and assuming there are
no other possibilities.

   Given a system of intellectual property, software development is
usually linked with the existence of an owner who controls the
software's use.  As long as this linkage exists, we are often faced
with the choice of proprietary software or none.  However, this linkage
is not inherent or inevitable; it is a consequence of the specific
social/legal policy decision that we are questioning: the decision to
have owners.  To formulate the choice as between proprietary software
vs. no software is begging the question.

The Argument against Having Owners
**********************************

   The question at hand is, "Should development of software be linked
with having owners to restrict the use of it?"

   In order to decide this, we have to judge the effect on society of
each of those two activities *independently*: the effect of developing
the software (regardless of its terms of distribution), and the effect
of restricting its use (assuming the software has been developed).  If
one of these activities is helpful and the other is harmful, we would be
better off dropping the linkage and doing only the helpful one.

   To put it another way, if restricting the distribution of a program
already developed is harmful to society overall, then an ethical
software developer will reject the option of doing so.

   To determine the effect of restricting sharing, we need to compare
the value to society of a restricted (i.e., proprietary) program with
that of the same program, available to everyone.  This means comparing
two possible worlds.

   This analysis also addresses the simple counterargument sometimes
made that "the benefit to the neighbor of giving him or her a copy of a
program is cancelled by the harm done to the owner."  This
counterargument assumes that the harm and the benefit are equal in
magnitude.  The analysis involves comparing these magnitudes, and shows
that the benefit is much greater.

   To elucidate this argument, let's apply it in another area: road
construction.

   It would be possible to fund the construction of all roads with
tolls.  This would entail having toll booths at all street corners.
Such a system would provide a great incentive to improve roads.  It
would also have the virtue of causing the users of any given road to
pay for that road.  However, a toll booth is an artificial obstruction
to smooth driving--artificial, because it is not a consequence of how
roads or cars work.

   Comparing free roads and toll roads by their usefulness, we find that
(all else being equal) roads without toll booths are cheaper to
construct, cheaper to run, safer, and more efficient to use.(2) In a
poor country, tolls may make the roads unavailable to many citizens.
The roads without toll booths thus offer more benefit to society at
less cost; they are preferable for society.  Therefore, society should
choose to fund roads in another way, not by means of toll booths.  Use
of roads, once built, should be free.

   When the advocates of toll booths propose them as *merely* a way of
raising funds, they distort the choice that is available.  Toll booths
do raise funds, but they do something else as well: in effect, they
degrade the road.  The toll road is not as good as the free road; giving
us more or technically superior roads may not be an improvement if this
means substituting toll roads for free roads.

   Of course, the construction of a free road does cost money, which the
public must somehow pay.  However, this does not imply the inevitability
of toll booths.  We who must in either case pay will get more value for
our money by buying a free road.

   I am not saying that a toll road is worse than no road at all.  That
would be true if the toll were so great that hardly anyone used the
road--but this is an unlikely policy for a toll collector.  However, as
long as the toll booths cause significant waste and inconvenience, it is
better to raise the funds in a less obstructive fashion.

   To apply the same argument to software development, I will now show
that having "toll booths" for useful software programs costs society
dearly: it makes the programs more expensive to construct, more
expensive to distribute, and less satisfying and efficient to use.  It
will follow that program construction should be encouraged in some other
way.  Then I will go on to explain other methods of encouraging and (to
the extent actually necessary) funding software development.

The Harm Done by Obstructing Software
=====================================

   Consider for a moment that a program has been developed, and any
necessary payments for its development have been made; now society must
choose either to make it proprietary or allow free sharing and use.
Assume that the existence of the program and its availability is a
desirable thing.(3)

   Restrictions on the distribution and modification of the program
cannot facilitate its use.  They can only interfere.  So the effect can
only be negative.  But how much?  And what kind?

   Three different levels of material harm come from such obstruction:

   * Fewer people use the program.

   * None of the users can adapt or fix the program.

   * Other developers cannot learn from the program, or base new work
     on it.

   Each level of material harm has a concomitant form of psychosocial
harm.  This refers to the effect that people's decisions have on their
subsequent feelings, attitudes and predispositions.  These changes in
people's ways of thinking will then have a further effect on their
relationships with their fellow citizens, and can have material
consequences.

   The three levels of material harm waste part of the value that the
program could contribute, but they cannot reduce it to zero.  If they
waste nearly all the value of the program, then writing the program
harms society by at most the effort that went into writing the program.
Arguably a program that is profitable to sell must provide some net
direct material benefit.

   However, taking account of the concomitant psychosocial harm, there
is no limit to the harm that proprietary software development can do.

Obstructing Use of Programs
===========================

   The first level of harm impedes the simple use of a program.  A copy
of a program has nearly zero marginal cost (and you can pay this cost by
doing the work yourself), so in a free market, it would have nearly zero
price.  A license fee is a significant disincentive to use the program.
If a widely-useful program is proprietary, far fewer people will use it.

   It is easy to show that the total contribution of a program to
society is reduced by assigning an owner to it.  Each potential user of
the program, faced with the need to pay to use it, may choose to pay,
or may forego use of the program.  When a user chooses to pay, this is a
zero-sum transfer of wealth between two parties.  But each time someone
chooses to forego use of the program, this harms that person without
benefiting anyone.  The sum of negative numbers and zeros must be
negative.

   But this does not reduce the amount of work it takes to *develop*
the program.  As a result, the efficiency of the whole process, in
delivered user satisfaction per hour of work, is reduced.

   This reflects a crucial difference between copies of programs and
cars, chairs, or sandwiches.  There is no copying machine for material
objects outside of science fiction.  But programs are easy to copy;
anyone can produce as many copies as are wanted, with very little
effort.  This isn't true for material objects because matter is
conserved: each new copy has to be built from raw materials in the same
way that the first copy was built.

   With material objects, a disincentive to use them makes sense,
because fewer objects bought means less raw materials and work needed
to make them.  It's true that there is usually also a startup cost, a
development cost, which is spread over the production run.  But as long
as the marginal cost of production is significant, adding a share of the
development cost does not make a qualitative difference.  And it does
not require restrictions on the freedom of ordinary users.

   However, imposing a price on something that would otherwise be free
is a qualitative change.  A centrally-imposed fee for software
distribution becomes a powerful disincentive.

   What's more, central production as now practiced is inefficient even
as a means of delivering copies of software.  This system involves
enclosing physical disks or tapes in superfluous packaging, shipping
large numbers of them around the world, and storing them for sale.  This
cost is presented as an expense of doing business; in truth, it is part
of the waste caused by having owners.

Damaging Social Cohesion
========================

   Suppose that both you and your neighbor would find it useful to run a
certain program.  In ethical concern for your neighbor, you should feel
that proper handling of the situation will enable both of you to use it.
A proposal to permit only one of you to use the program, while
restraining the other, is divisive; neither you nor your neighbor should
find it acceptable.

   Signing a typical software license agreement means betraying your
neighbor: "I promise to deprive my neighbor of this program so that I
can have a copy for myself."  People who make such choices feel
internal psychological pressure to justify them, by downgrading the
importance of helping one's neighbors--thus public spirit suffers.