www-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

www/philosophy funding-art-vs-funding-software....


From: Robert Musial
Subject: www/philosophy funding-art-vs-funding-software....
Date: Wed, 30 Jan 2013 23:11:06 +0000

CVSROOT:        /web/www
Module name:    www
Changes by:     Robert Musial <musial>  13/01/30 23:11:06

Added files:
        philosophy     : funding-art-vs-funding-software.html 

Log message:
        added funding-art-vs-funding-software.html
        basic content and formatting added
        cleaning up.

CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/philosophy/funding-art-vs-funding-software.html?cvsroot=www&rev=1.1

Patches:
Index: funding-art-vs-funding-software.html
===================================================================
RCS file: funding-art-vs-funding-software.html
diff -N funding-art-vs-funding-software.html
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ funding-art-vs-funding-software.html        30 Jan 2013 23:11:05 -0000      
1.1
@@ -0,0 +1,165 @@
+<!--#include virtual="/server/header.html" -->
+<!-- Parent-Version: 1.71 -->
+<title>Funding Art vs Funding Software</title>
+<!--#include virtual="/server/banner.html" -->
+<!--#include virtual="" -->
+<h2>Funding Art vs Funding Software </h2>
+
+<p>by <a href="http://www.stallman.org/";><strong>Richard
+Stallman</strong></a></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 "donate"
+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.
+
+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.
+
+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
+http://www.gnu.org/philosophy/free-sw.html). Works to do practical
+jobs include educational resources, reference works, recipes, text
+fonts and, of course, software; these works must be free.
+
+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.
+
+That crucial point enables my proposed funding systems to work. It
+means that if you play a song and push the "donate" 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.
+
+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.
+
+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.
+
+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 -- 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.
+
+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.
+
+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.
+
+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.
+
+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?
+
+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.
+
+These problems are the reasons I don't propose using those two funding
+systems in fields such as software, encyclopedias or education, were
+all works ought to be free.
+
+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.
+
+The Free Software Foundation asks for donations in two ways. We ask
+for general donations to support the foundation's work, and we invite
+targeted donations for certain specific projects. Other free software
+organizations do this too.
+
+</div><!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.html" -->
+<div id="footer">
+
+<p>Please send general FSF &amp; GNU inquiries to <a
+href="mailto:address@hidden";>&lt;address@hidden&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:address@hidden";>&lt;address@hidden&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:address@hidden";>
+        &lt;address@hidden&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>
+
+<p>Copyright &copy; 2013 Richard Stallman</p>
+
+<p>This page is licensed under a <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/3.0/us/";>Creative
+Commons Attribution-NoDerivs 3.0 United States License</a>.
+</p>
+
+<p>
+Updated:
+<!-- timestamp start -->
+$Date: 2013/01/30 23:11:05 $
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+</body>
+</html>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]