summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/br/funding-art-vs-funding-software.html
blob: e189731dcffd464a953f8bbd9fe9b0f01c6d39fb (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
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
<!--#set var="ENGLISH_PAGE" value="/philosophy/funding-art-vs-funding-software.en.html" -->

<!--#include virtual="/server/header.pt-br.html" -->
<!-- Parent-Version: 1.84 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Financiamento de arte vs. Financiamento de software - Projeto GNU - Free
Software Foundation</title>

<!--#include virtual="/philosophy/po/funding-art-vs-funding-software.translist" -->
<!--#include virtual="/server/banner.pt-br.html" -->
<h2>Financiamento de arte vs. Financiamento de software</h2>

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

<p>Eu propus dois novos sistemas para financiar artistas em um mundo onde
legalizamos o compartilhamento (redistribuição não comercial de cópias
exatas) de obras publicadas. Uma delas é o Estado arrecadar impostos para o
propósito e dividir o dinheiro entre os artistas proporcionalmente à raiz
cúbica da popularidade de cada um (conforme medido por amostras de pesquisa
junto à população). A outra é para cada reprodutor de mídia ter um botão
“doar” para enviar anonimamente uma pequena quantia (talvez 50 centavos, nos
EUA) para artistas cuja obra está sendo ou acabou de ser reproduzida. Esses
financiamentos iriam para artistas, não para as editoras.</p>

<p>As pessoas muitas vezes se perguntam por que não proponho esses métodos para
software livre. Há uma razão para isso: é difícil adaptá-los a obras livres.</p>

<p>Na minha opinião, obras destinadas a serem utilizadas para trabalhos
práticos devem ser livre. As pessoas que as usam merecem ter controle sobre
os trabalhos que fazem, o que requer controle sobre as obras que elas usam
para realizá-las, o que requer as quatro liberdades (veja <a
href="/philosophy/free-sw.html">
http://www.gnu.org/philosophy/free-sw.html</a>). Obras para trabalhos
práticos incluem recursos educacionais, trabalhos de referência, receitas,
fontes de texto e, é claro, software; essas obras devem ser livres.</p>

<p>Esse argumento não se aplica a obras de opinião (como esta) ou arte, porque
elas não são projetadas para as pessoas fazerem trabalhos práticos com
elas. Assim, não acredito que essas obras devam ser livres. Devemos
legalizar o compartilhamento delas e usar partes no remix para fazer novas
obras totalmente diferentes, mas isso não inclui publicar versões
modificadas deles. Daqui resulta que, para estas obras, podemos dizer quem
são os autores ou autoras. Cada obra publicada pode especificar a autoria e
a alteração dessas informações pode ser ilegal.</p>

<p>Esse ponto crucial permite que meus sistemas de financiamento propostos
funcionem. Isso significa que, se você tocar uma música e pressionar o botão
“doar”, o sistema pode ter certeza de quem deve receber sua doação. Da mesma
forma, se você participar da pesquisa que calcula as popularidades, o
sistema saberá a quem creditar com um pouco mais de popularidade porque você
ouviu essa música ou fez uma cópia dela.</p>

<p>Quando uma música é feita por um conjunto de artistas (por exemplo, vários
músicos e um compositor), isso não acontece por acaso. Tais artistas sabem
que estão trabalhando juntos e podem decidir antecipadamente como dividir a
popularidade que a música mais tarde desenvolve &ndash; ou usar as regras
padrão para essa divisão. Este caso não cria nenhum problema para essas duas
propostas de financiamento porque a obra, uma vez feita, não é alterada por
outros.</p>

<p>No entanto, em um campo de obras livres, uma grande obra pode ter centenas,
até milhares de autores e autoras. Pode haver várias versões com conjuntos
de autores e autoras diferentes e sobrepostos. Além disso, as contribuições
destes diferem em espécie e magnitude. Isso torna impossível dividir a
popularidade da obra entre autores das colaborações de uma maneira que possa
ser justificada como correta. Não é apenas trabalho duro; não é apenas
complexo. O problema levanta questões filosóficas que não têm boas
respostas.</p>

<p>Considere, por exemplo, o programa livre GNU Emacs. Nossos registros de
contribuições para o código do GNU Emacs estão incompletos no período antes
de começarmos a usar o controle de versão &ndash; antes disso, temos apenas
os registros de alterações. Mas vamos imaginar que ainda temos todas as
versões e podemos determinar com precisão qual contribuição do código é
devida a cada uma das centenas de contribuidores. Nós ainda estaríamos
travados.</p>

<p>Se quiséssemos dar crédito proporcionalmente às linhas de código (ou deveria
ser caracteres?), Então seria simples, uma vez que decidimos como lidar com
uma linha que foi escrita por A e então alterada por B. Mas isso considera
cada linha tão importante quanto todas as outras linhas. Eu tenho certeza
que isso é errado &ndash; algumas partes do código fazem trabalhos mais
importantes e outros menos; alguns códigos são mais difíceis de escrever e
outros códigos são mais fáceis. Mas não vejo maneira de quantificar essas
distinções, e desenvolvedores podem argumentar sobre elas para sempre. Eu
poderia merecer algum crédito adicional por ter inicialmente escrito o
programa, e alguns outros podem merecer crédito adicional por ter
inicialmente escrito algumas adições importantes posteriores, mas não vejo
nenhuma maneira objetiva de decidir quanto. Eu não posso propor uma regra
justificável para dividir o crédito de popularidade de um programa como o
GNU Emacs.</p>

<p>Quanto a pedir a todos os contribuidores para negociar um acordo, não
podemos nem tentar. Houve centenas de colaboradores e não poderíamos
encontrar todos atualmente. Eles contribuíram em um período de 26 anos e
nunca, em momento algum, todas essas pessoas decidiram trabalhar juntas.</p>

<p>Podemos nem saber os nomes de todos os autores. Se algum código fosse doado
por empresas, não precisaríamos perguntar a quem escreveu esse código.</p>

<p>Então, o que acontece com as variantes modificadas ou que são <em>forks</em>
do GNU Emacs? Cada um é um caso adicional, igualmente complexo, mas
diferente. Quanto do crédito para tal variante deve ser dado àqueles que
trabalharam nessa variante, e quanto a autores originais do código obtidos
de outras versões do GNU Emacs, outros programas e assim por diante?</p>

<p>A conclusão é que não há como chegarmos a uma divisão do crédito para o GNU
Emacs e justificá-lo como algo que não seja arbitrário. Mas o Emacs não é um
caso especial; é um exemplo típico. Os mesmos problemas surgiriam para
muitos programas gratuitos importantes e outras obras livres, como as
páginas do Wikipédia.</p>

<p>Esses problemas são os motivos pelos quais não proponho usar esses dois
sistemas de financiamento em campos como software, enciclopédias ou
educação, onde todas as obras deveriam ser livres.</p>

<p>O que faz sentido para essas áreas é pedir que as pessoas doem para
<em>projetos</em> para a obra <em>que se propõem a fazer</em>. Esse sistema
é simples.</p>

<p>A Free Software Foundation pede doações de duas maneiras. Pedimos por <a
href="https://my.fsf.org/donate/"> doações gerais para apoiar a atuação da
fundação</a> e convidamos <a
href="https://my.fsf.org/donate/directed-donations"> doações direcionadas
para determinados projetos específicos</a>. Outras organizações de software
livre também fazem isso.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 </div>
</div>

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

<p>Envie perguntas em geral sobre a FSF e o GNU para <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Também existem <a
href="/contact/">outros meios de contatar</a> a FSF. Links quebrados e
outras correções ou sugestões podem ser enviadas para <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>. -->
A equipe de traduções para o português brasileiro se esforça para oferecer
traduções precisas e de boa qualidade, mas não estamos isentos de erros. Por
favor, envie seus comentários e sugestões em geral sobre as traduções para
<a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
</p><p>Consulte o <a href="/server/standards/README.translations.html">Guia
para as traduções</a> para mais informações sobre a coordenação e o envio de
traduções das páginas deste site.</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>Esta página está licenciada sob uma licença <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.pt_BR">Creative
Commons Atribuição-SemDerivações 4.0 Internacional</a>.</p>

<!--#include virtual="/server/bottom-notes.pt-br.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
Traduzido por: Rafael Fontenelle <a
href="mailto:rafaelff@gnome.org">&lt;rafaelff@gnome.org&gt;</a>, 2019.</div>

<p class="unprintable"><!-- timestamp start -->
Última atualização:

$Date: 2020/05/22 22:05:25 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>