summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/br/funding-art-vs-funding-software.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/br/funding-art-vs-funding-software.html')
-rw-r--r--talermerchantdemos/blog/articles/br/funding-art-vs-funding-software.html210
1 files changed, 210 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/br/funding-art-vs-funding-software.html b/talermerchantdemos/blog/articles/br/funding-art-vs-funding-software.html
new file mode 100644
index 0000000..e189731
--- /dev/null
+++ b/talermerchantdemos/blog/articles/br/funding-art-vs-funding-software.html
@@ -0,0 +1,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>