taler-merchant-demos

free-doc.html (11561B)

---

 <!--#set var="ENGLISH_PAGE" value="/philosophy/free-doc.en.html" -->
 
 <!--#include virtual="/server/header.pt-br.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="essays aboutfs extension" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Por Que Software Livre precisa de Documentação Livre - Projeto GNU - Free
 Software Foundation</title>
 
 <!--#include virtual="/philosophy/po/free-doc.translist" -->
 <!--#include virtual="/server/banner.pt-br.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.pt-br.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.pt-br.html" -->
 <div class="article reduced-width">
 <h2>Por Que Software Livre precisa de Documentação Livre</h2>
 <div class="thin"></div>
 
 <p>
 A maior deficiência em sistemas operacionais livres não é o software — é a
 falta de bons manuais livres que podemos incluir nesses sistemas. Muitos de
 nossos programas mais importantes não vêm com manuais
 completos. Documentação é uma parte essencial de qualquer pacote de
 software; quando um pacote de software livre importante não vem com um
 manual livre, isso é um grande buraco. Hoje, nós temos muitos buracos assim.</p>
 
 <p>
 Uma vez, muitos anos atrás, eu pensei que ia aprender Perl. Peguei uma cópia
 de um manual livre, mas achei difícil de ler. Quando perguntei usuários de
 Perl sobre alternativas, eles me disseram que existiam manuais introdutórios
 melhores — mas que não eram livres (não eram respeitadores de liberdades).</p>
 
 <p>
 Por que isso? Os autores dos bons manuais os tinham escrito para O'Reilly
 Associates, que os publicou com termos restritivos — era proibido copiar,
 modificar, arquivos-fonte não disponíveis — tornando-os não livres e,
 portanto, excluindo-os do Mundo Livre.</p>
 
 <p>
 Essa não foi a primeira vez que esse tipo de coisa aconteceu e, para o
 grande prejuízo da nossa comunidade, estava longe de ser a última. Editoras
 de manuais privativos seduziram muitos autores a restringir seus manuais
 desde então. Várias vezes já ouvi usuários de GNU animadamente me contar
 sobre um manual que eles estavam escrevendo, com o qual eles esperam ajudar
 o projeto GNU — e então perder minhas esperanças, quando eles me explicavam
 que haviam assinado um contrato com uma editora que restringiria o manual,
 de tal maneira que não pudéssemos usá-lo.</p>
 
 <p>
 Já que boa escrita em inglês é uma habilidade rara entre programadores, nós
 não podemos perder manuais dessa maneira.</p>
 
 <hr class="no-display" />
 <div class="announcement" role="complementary"><p>
 <a href="https://defectivebydesign.org/ebooks.html">Junte-se à nossa lista
 de discussão sobre os perigos dos livros eletrônicos (eBooks)</a>.
 </p></div>
 <hr class="no-display" />
 
 <p>
 Documentação livre, assim como software livre, é uma questão de liberdade,
 não de preço. O problema com esses manuais não foi que O'Reilly Associates
 cobrava um preço por cópias impressas — isso, por si só, não tem
 problema. (A Free Software Foundation <a
 href="https://shop.fsf.org/category/books/">também vende cópias
 impressas</a> de <a href="/doc/doc.html">manuais GNU</a> livres). Porém,
 manuais GNU também estão disponíveis na forma de código-fonte, enquanto
 esses manuais só estão disponíveis em papel. Manuais GNU vêm com permissão
 para copiar e modificar; os manuais sobre Perl não vêm. Essas restrições são
 os problemas.</p>
 
 <p>
 O critério para um manual livre é o mesmo que software livre: é uma questão
 de dar a todos usuários certas liberdades. Redistribuição (incluindo
 redistribuição comercial) deve ser permitida, para que o manual possa
 acompanhar todas as cópias do programa, on-line ou em papel. Permissão para
 modificação também é crucial.</p>
 
 <ul>
 <li><a href="/licenses/fdl.html">A Licença de Documentação Livre GNU</a></li>
 </ul>
 
 <p>
 Como regra geral, eu não acredito que seja essencial que as pessoas tenham
 permissão para modificar todo tipo de artigo e livro. As questões de escrita
 não são necessariamente as mesmas que as de software. Por exemplo, eu não
 acho que você ou eu somos obrigados a dar permissão para modificar artigos
 como este, que descreve nossas ações e opiniões.</p>
 
 <p>
 Porém, existe um motivo particular pelo qual a liberdade de modificar é
 crucial para documentação de software livre. Quando as pessoas exercem seu
 direito de modificar software, e adicionar ou mudar seus recursos, se elas
 forem conscientes, elas vão modificar o manual também — para fornecer
 documentação precisa e usável com o programa modificado. Um manual que
 proíbe os programadores de serem meticulosos ou de finalizar sua tarefa ou,
 mais precisamente, requer que eles escrevam novos manuais do zero se eles
 alterarem o programa, não preenche as necessidades de nossa comunidade.</p>
 
 <p>
 Enquanto uma proibição completa contra a modificação é inaceitável, certos
 tipos de limites no método de modificação não criam nenhum problema. Por
 exemplo, não há problemas em exigências de preservar o copyright do autor
 original, os termos da distribuição ou a lista de autores. Também não é
 problema exigir que versões modificadas incluam um aviso que foram
 modificadas, e até ter seções inteiras que não possam ser deletadas ou
 modificadas, contanto que essas seções tratem de assuntos não
 técnicos. (Alguns manuais GNU as têm)</p>
 
 <p>
 Esses tipos de restrição não são um problema porque, na prática, eles não
 impedem o programador consciente de adaptar o manual para o programa
 modificado. Em outras palavras, eles não impedem a comunidade do software
 livre de aproveitar completamente o manual.</p>
 
 <p>
 Porém, deve ser possível modificar todo o conteúdo <em>técnico</em> do
 manual, e daí distribuir o resultado por todos os meios usuais, através de
 todos os canais usuais; senão, as restrições obstruem a comunidade, o manual
 não é livre, e nós precisamos de outro manual.</p>
 
 <p>
 Infelizmente, é frequentemente difícil encontrar alguém para escrever outro
 manual quando um manual privativo já existe. O obstáculo é que muitos
 usuários pensam que um manual privativo é bom o suficiente — então eles não
 veem a necessidade de escrever um manual livre. Eles não veem que o sistema
 operacional livre tem um buraco que precisa ser preenchido.</p>
 
 <p>
 Por que será que os usuários pensam que manuais privativos são
 suficientemente bons? Algumas pessoas ainda não consideraram essa
 questão. Espero que esse artigo contribua para mudar isso.</p>
 
 <p>
 Outros usuários consideram manuais privativos aceitáveis pelo mesmo motivo
 que tantas pessoas consideram softwares privativos aceitáveis: eles julgam
 em termos puramente imediatistas, sem usar liberdade como critério. Essas
 pessoas têm direito às suas opiniões, mas já que essas opiniões derivam de
 valores que não incluem a liberdade, elas não são guia nenhum para aqueles
 entre nós que valorizamos a liberdade.</p>
 
 <p>
 Por favor, espalhe a palavra sobre essa questão. Nós continuamos a perder
 manuais para publicações privativas. Se nós espalharmos a noção de que
 manuais privativos não são suficiente, talvez a próxima pessoa que queira
 ajudar GNU escrevendo documentação perceberá, antes que seja tarde demais,
 que ele deve sobre tudo fazê-lo livre.</p>
 
 <p>
 Nós também podemos encorajar editoras comerciais a vender manuais livres,
 copylefted, ao invés de manuais privativos. Uma maneira que você pode ajudar
 é checar os termos de distribuição de um manual antes de comprá-lo, e
 preferir manuais copylefted a manuais não copylefted.</p>
 <p>
 [Nota: Nós mantemos uma <a href="/doc/other-free-books.html">página que
 lista livros livres publicados por outras editoras</a>].</p>
 </div>
 
 <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" role="contentinfo">
 <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 contributing 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 a
 contribuição com 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; 1996, 2019, 2021 Free Software Foundation, Inc.</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:
 Gustavo Lacerda <a
 href="mailto:gus@optimizelife.com">&lt;gus@optimizelife.com&gt;</a>, 2011
 <br />
 Rafael Fontenelle <a
 href="mailto:rafaelff@gnome.org">&lt;rafaelff@gnome.org&gt;</a>, 2016-2021</div>
 
 <p class="unprintable"><!-- timestamp start -->
 Última atualização:
 
 $Date: 2021/09/05 08:35:41 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>