summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/en/funding-art-vs-funding-software.html
blob: 4d6a0ff0acf12b85b9d48fc508aefb7e1a682539 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
<!--#include virtual="/server/header.html" -->
<!-- Parent-Version: 1.84 -->
<title>Funding Art vs Funding Software
- GNU Project - Free Software Foundation</title>
<!--#include virtual="/philosophy/po/funding-art-vs-funding-software.translist" -->
<!--#include virtual="/server/banner.html" -->

<h2>Funding Art vs Funding Software</h2>

<p>by <a href="http://www.stallman.org/"><strong>Richard
Stallman</strong></a></p>

<p>I've proposed two new systems to fund artists in a world where we have
legalized sharing (noncommercial redistribution of exact copies) of
published works.  One is for the state to collect taxes for the
purpose, and divide the money among artists in proportion to the cube
root of the popularity of each one (as measured by surveying samples
of the population).  The other is for each player to have a
&ldquo;donate&rdquo; button to anonymously send a small sum (perhaps
50 cents, in the US) to the artists who made the last work played.
These funds would go to artists, not to their publishers.</p>

<p>People often wonder why I don't propose these methods for free
software.  There's a reason for that: it is hard to adapt them to
works that are free.</p>

<p>In my view, works designed to be used to do practical jobs must be
free.  The people who use them deserve to have control over the jobs
they do, which requires control over the works they use to do them,
which requires the four freedoms (see <a
href="/philosophy/free-sw.html">
http://www.gnu.org/philosophy/free-sw.html</a>).  Works to do practical
jobs include educational resources, reference works, recipes, text
fonts and, of course, software; these works must be free.</p>

<p>That argument does not apply to works of opinion (such as this one) or
art, because they are not designed for the users to do practical jobs
with.  Thus, I don't believe those works must be free.  We must
legalize sharing them, and using pieces in remix to make totally
different new works, but that doesn't include in publishing modified
versions of them.  It follows that, for these works, we can tell who
the authors are.  Each published work can specify who its authors are,
and changing that information can be illegal.</p>

<p>That crucial point enables my proposed funding systems to work.  It
means that if you play a song and push the &ldquo;donate&rdquo;
button, the system can be sure who should get your donation.  Likewise,
if you participate in the survey that calculates popularities, the
system will know who to credit with a little more popularity because
you listened to that song or made a copy of it.</p>

<p>When one song is made by multiple artists (for instance, several
musicians and a songwriter), that doesn't happen by accident.  They
know they are working together, and they can decide in advance how to
divide up the popularity that song later develops&mdash;or use the
standard default rules for this division.  This case creates no
problem for those two funding proposals because the work, once made,
is not changed by others.</p>

<p>However, in a field of free works, one large work can have hundreds,
even thousands of authors.  There can be various versions with
different, overlapping sets of authors.  Moreover, the contributions
of those authors will differ in kind as well as in magnitude.  This
makes it impossible to divide the work's popularity among the
contributors in a way that can be justified as correct.  It's not just
hard work; it's not merely complex.  The problem raises philosophical
questions that have no good answers.</p>

<p>Consider, for example, the free program GNU Emacs.  Our records of
contributions to the code of GNU Emacs are incomplete in the period
before we started using version control&mdash;before that we have only
the change logs.  But let's imagine we still had every version and
could determine precisely what code contribution is due to each of
the hundreds of contributors.  We'd still be stuck.</p>

<p>If we wanted to give credit in proportion to lines of code (or should
it be characters?), then it would be straightforward, once we decide
how to handle a line that was written by A and then changed by B.  But
that assumes each line as important as every other line.  I am sure
that is wrong&mdash;some pieces of the code do more important jobs
and others less; some code is harder to write and other code is
easier.  But I see no way to quantify these distinctions, and the
developers could argue about them forever.  I might deserve some
additional credit for having initially written the program, and
certain others might deserve additional credit for having initially
written certain later important additions, but I see no objective way
to decide how much.  I can't propose a justifiable rule for dividing
up the popularity credit of a program like GNU Emacs.</p>

<p>As for asking all the contributors to negotiate an agreement, we can't
even try.  There have been hundreds of contributors, and we could not
find them all today.  They contributed across a span of 26 years, and
never at any time did all those people decide to work together.</p>

<p>We might not even know the names of all the authors.  If some code was
donated by companies, we did not need to ask which persons wrote that
code.</p>

<p>Then what about the forked or modified variants of GNU Emacs? Each
one is an additional case, equally complex but different.  How much of
the credit for such a variant should go to those who worked on that
variant, and how much to the original authors of the code they got
from other GNU Emacs versions, other programs, and so on?</p>

<p>The conclusion is that there is no way we could come up with a
division of the credit for GNU Emacs and justify it as anything but
arbitrary.  But Emacs is not a special case; it is a typical example.
The same problems would arise for many important free programs, and
other free works such as Wikipedia pages.</p>

<p>These problems are the reasons I don't propose using those two funding
systems in fields such as software, encyclopedias or education, where
all works ought to be free.</p>

<p>What makes sense for these areas is to ask people to donate to
<em>projects</em> for the work <em>they propose to do</em>.  That
system is simple.</p>

<p>The Free Software Foundation asks for donations in two ways.  We
ask for <a href="https://my.fsf.org/donate/"> general donations to
support the foundation's work</a>, and we invite <a
href="https://my.fsf.org/donate/directed-donations"> targeted
donations for certain specific projects</a>.  Other free software
organizations do this too.</p>

</div><!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.html" -->
<div id="footer">
<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 submitting 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 submitting 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; 2013, 2017 Richard Stallman</p>

<p>This page is licensed under a <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/">Creative
Commons Attribution-NoDerivatives 4.0 International License</a>.</p>

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

<p class="unprintable">Updated:
<!-- timestamp start -->
$Date: 2017/08/27 14:56:06 $
<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>