Esta tradução pode não refletir as alterações feitas desde 2022-01-02 ao original em Inglês.
Você deveria dar uma olhada nas alterações. Por favor, veja o README de traduções para informações sobre a manutenção de traduções a este artigo.
Como escolher uma licença para sua própria obra
This page is maintained by the Free Software Foundation's Licensing and Compliance Lab. You can support our efforts by making a donation to the FSF.
You can use our publications to understand how GNU licenses work or help you advocate for free software, but they are not legal advice. The FSF cannot give legal advice. Legal advice is personalized advice from a lawyer who has agreed to work for you. Our answers address general questions and may not apply in your specific legal situation.
Have a question not answered here? Check out some of our other licensing resources or contact the Compliance Lab at licensing@fsf.org.
Para ver se uma dada licença é livre ou não, veja nossa página de lista de licenças e a definição de software livre.
Introdução
As pessoas geralmente nos perguntam qual licença nós recomendamos que usem em seus projetos. Nós já escrevemos sobre isso publicamente, mas a informação foi espalhada por diferentes ensaios, entradas de FAQ e comentários sobre licenças. Esse artigo colhe todas aquelas informações em uma única fonte, para facilitar para as pessoas seguirem e terem uma referência.
Essas recomendações são para obras projetadas para fazer trabalhos práticos. Aqueles softwares, documentações e algumas outras coisas incluídas. Obras de arte, e obras que demonstram um ponto de vista, são questões diferentes; o Projeto GNU possui nenhuma posição geral sobre como eles devem ser lançados, exceto que eles devem todos ser usáveis sem software não livre (em particular, sem DRM). Porém, você pode querer seguir essas recomendações para obras de arte que vão com um programa em particular.
As recomendações se aplicam ao licenciamento de uma obra que você cria—seja essa uma modificação de uma obra existente ou uma nova obra original. Elas não resolvem a questão da combinação de material existente sob licenças diferenças. Se você está procurando por ajuda com isto, por favor verifique nosso FAQ da GPL.
Depois de ver o que nós recomendamos aqui, se você quiser conselhos, basta escrever para <licensing@gnu.org>. Note que provavelmente levará algumas semanas para a equipe de licenciamento lhe responder; se você não obter resposta em um mês, por favor tente novamente.
Contribuindo para um projeto existente
Quando você contribui para um projeto existente, você geralmente deve lançar suas versões modificadas sob a mesma licença que a obra original. É bom cooperar com os mantenedores do projeto e usar uma licença diferente para suas modificações frequentemente dificultam tal cooperação. Você deve fazer isso apenas quando há um forte motivo que o justifique.
Um caso no qual usar uma licença diferente pode ser justificado é quando você faz muitas alterações em uma obra sobre uma licença não copyleft. Se a versão que você criou é consideravelmente mais útil que a original, então vale a pena adicionar copyleft à sua obra, pelos mesmos motivos que nós normalmente recomendamos copyleft. Se você está nesta situação, por favor siga as recomendações abaixo para licenciamento de um novo projeto.
Se você escolher lançar suas contribuições sob uma licença diferente por qualquer motivo, você deve se certificar de que a licença original permite usar o material sob sua licença escolhida. Por uma questão de honestidade, mostre explicitamente quais partes da obra estão sob qual licença.
Software
Nós recomendamos licenças diferentes para projetos diferentes, dependendo basicamente no propósito do software. Em geral, nós recomendamos o uso da licença copyleft mais forte que não interfira naquele propósito. Nosso ensaio "O que é Copyleft?" explica o conceito de copyleft em mais detalhes, e porque ele é geralmente a melhor estratégia de licenciamento.
Para a maioria dos programas, nós recomendamos que você use a versão mais recente da Licença Pública Geral GNU (GPL) para seu projeto. Seu copyleft forte é apropriado para todos tipos de softwares e inclui diversas proteções para a liberdade dos usuários. Para permitir atualizações futuras, por favor, especifique “version 3 or any later verson” para que seu programa seja compatível com licença de código que pode ser lançado, no futuro, sob versões subsequentes da GPL.
Aqui você encontra mais conselhos sobre como lançar um programa sob a GNU GPL.
Agora, para as exceções, casos em que é melhor usar algumas outras licenças em vez da GNU GPL.
Programas pequenos
Não compensa o esforço para usar copyleft para a maioria dos programas pequenos. Nós usamos 300 linhas como nossa marca de referência: quando o código-fonte do pacote de um software é menor do que isso, os benefícios fornecidos pelo copyleft é geralmente pequeno demais para justificar a inconveniência de se certificar que uma cópia de licença sempre acompanhe o software.
Para aqueles programas, nós recomendamos a Licença Apache 2.0. Esta é um licença de software fraca, leniente (não copyleft) que possui termos que evitam contribuidores e distribuidores de processar por violação de patente. Isso não torna o software imune a ameaças de patentes (nenhuma licença de software pode fazer isso), mas evita detentores de patentes prepararem uma “armadilha” na qual eles lançam um software sob termos livres e, então, exigem que os destinatários concordem com termos não livres em uma licença de patente.
Dentre as licenças lenientes, Apache 2.0 é melhor; de forma que se você pretende usar uma licença fraca, independente do motivo, recomendamos usá-la.
Bibliotecas
Para bibliotecas, nós distinguimos três tipos de casos.
Algumas bibliotecas implementam formatos de dados livres que estão competindo contra formatos de dados restritos, tais como Ogg Vorbis (que compete contra áudio MP3) e WebM (que compete contra vídeo MPEG-4). O sucesso do formato livre exige permitir que muitos programas de aplicativos proprietários implemente-o no código para lidar com o formato livre. Por exemplo, queríamos que reprodutores de mídia não livre, especialmente os appliances, incluíssem o código para Ogg Vorbis bem como MP3.
Nessas situações especiais, se você você busca convencer desenvolvedores de aplicativos proprietários a usarem a biblioteca para o formato livre, você precisaria facilitar licenciando a biblioteca com uma licença fraca, como a Licença Apache 2.0.
No entanto, devemos reconhecer que essa estratégia não teve sucesso para Ogg Vorbis. Mesmo depois de alterar a licença de direitos autorais para permitir a fácil inclusão desse código de biblioteca em aplicativos proprietários, os desenvolvedores proprietários geralmente não o incluíam. O sacrifício feito na escolha da licença nos deu poucos ganhos.
Para todas as outras bibliotecas, nós recomendamos algum tipo de copyleft. Se desenvolvedores já estão usando uma biblioteca alterativa estabelecida sob uma licença não livre ou uma licença leniente, então recomendamos usar o Licença Pública Geral Menor GNU (LGPL).
Diferentemente do primeiro caso, no qual a biblioteca implementa um padrão ético superior, aqui a adoção para seu próprio bem não vai acompanhar qualquer objetivo especial, então não há motivo para evitar totalmente o copyleft. Porém, se você exigir que desenvolvedores que usam sua biblioteca lancem todo o programa sob copyleft, eles vão simplesmente usar uma das alternativas disponíveis, e isso não vai avançar em nossa causa também. A GPL Menor foi projetada para preencher o meio de campo entre esses casos, permitindo desenvolvedores de software proprietário usar a biblioteca coberta, mas fornecendo uma copyleft fraca que fornece aos usuários liberdade sobre o código da biblioteca em si.
Para as bibliotecas que fornecem facilidades especializadas e que não enfrentam competição apertada de não copyleft ou não livre, recomendamos usar a GNU GPL. Para saber o porquê, leia "Por que você não deve usar a GPL Menor para sua próxima biblioteca".
Software de servidor
Se for provável que outros farão versões melhoradas de seu programa para executá-lo em servidores e não distribuir as respectivas versões para ninguém mais, e você está preocupado que isto colocará sua versão lançada em uma desvantagem, recomendamos a Licença Pública Geral Affero GNU (AGPL). Os termos da AGPL são quase idênticos aos da GPL; a única diferença substancial é que ela possui uma condição extra para garantir que as pessoas que usam o software pela rede serão capaz de obter o código fonte dele.
Os requisitos da AGPL não resolvem os problemas que podem surgir para usuários quando eles confiam sua computação ou seus dados ao servidor de outra pessoa. Por exemplo, isso não vai impedir Software como um Substituto de Software (SaaSS)—mas a maioria dos servidores não fazem SaaSS. Para mais sobre essas questões, leia "Por que GPL Affero".
Documentação
Nós recomendamos a Licença de Documentação Livre GNU (GFDL) para tutoriais, manuais de referência e outras obras grandes de documentação. Ela é uma licença forte de copyleft para obras educacionais, inicialmente escrita para manuais de software e inclui termos que resolvem especificamente questões comuns que surgem quando essas obras são distribuídas ou modificadas.
Para obras de documentação secundárias, curtas, tal como um cartão de referência, é melhor usar a licença toda permissiva GNU, já que uma cópia da GFDL dificilmente poderia se adequar a um cartão de referência. Não use CC-BY, já que ela é incompatível com GFDL.
Para páginas man, recomendamos a GFDL se a página for longa, e a licença toda permissiva GNU se for curta.
Algumas documentações incluem código-fonte de software. Por exemplo, um manual de uma linguagem de programação pode incluir exemplos para leitores seguirem. Você deve incluí-los no manual sob os termos da FDL e lançá-los sob uma outra licença que seja apropriada para software. Fazer isto ajuda a facilitar o uso do código em outros projetos. Nós recomendamos que você dedique pequenos pedaços de código para o domínio público usando CC0, e distribui pedaços grandes sob a mesma licença que o projeto do software associado usa.
Outros dados para programas
Essa seção discute todas as outras obras por uso prático que você pode incluir com software. Para lhe dar alguns exemplos, este inclui ícones e outras imagens funcionais ou úteis, fontes e dados geográficos. Você também pode segui-los por arte, apesar de que nós não criticamos se você não o fizer.
Se você está criando essas obras especialmente para o uso com um projeto de software, geralmente recomendamos que você lance sua obra sob a mesma licença que o software. Não há problema em fazer isso com as licenças que nós recomendamos: GPLv3, LGPLv3, AGPLv3 e GPLv2 pode todas ser aplicadas a qualquer tipo de obra—não apenas software—que seja "copyrightável" e tenha uma forma preferida clara de modificação. Usar a mesma licença que o software vai facilitar a conformidade para os distribuidores e evita qualquer dúvida sobre potenciais problemas de compatibilidade. Usar uma licença livre diferente pode ser apropriado se ela fornece algum benefício prático específico, como uma melhor cooperação com outros projetos livres.
Se sua obra não está sendo criada para ser usada com um projeto de software específico, ou se não seria apropriado usar a mesma licença para sua obra. Nós temos algumas dessas listadas em nossa lista de licença. Se nenhuma licença parece especificamente apropriada, a licença Creative Commons Atribuição-CompartilhaIgual é um copyleft que pode ser usado para diferentes tipos de obras.