Comparação de licenças de código aberto [guia]

9 de novembro de 2019

Breve *: Este guia detalhado oferece uma comparação eficaz de licenças Open Source. Com as licenças Open Source explicadas aqui, deve ajudá-lo a escolher a licença Open Source certa para o seu projeto.

Então, você está trabalhando naquele novo projeto legal por um tempo - e você está pronto agora para fazer a mudança crítica de código fechado para código aberto .

Não parece muito mais trabalhoso do que limpar as fontes e o histórico de commits antes de enviar seu repositório para GitHub ou Bitbucket ... ... até que a questão da Licença apareça. Existem tantas opções disponíveis. Qual escolher? E você realmente precisa de uma licença, afinal?

A resposta curta a esta última pergunta é fácil: Sim, você realmente precisa de uma licença. Quanto à licença de que você precisa, posso até dar uma resposta mais curta: depende .

Mas se você leva seu projeto a sério, provavelmente quer um pouco mais de detalhes. Portanto, leia mais à frente - e lembre-se: você está entrando no território da guerra santa agora!

Eu preciso de uma licença? Afinal, o que é uma licença?

Uma Licença é uma permissão oficial concedida pelo proprietário de alguma Obra (o Licenciante) a outras pessoas (o Licenciado) e rege como o Licenciado tem permissão para usar o Trabalho do Licenciante

Isso assume a forma de um contrato, com o qual ambas as partes devem concordar. Hoje em dia, a aceitação é bastante implícita: apenas usando alguma Obra, você tem a fama de concordar com sua Licença de uso.

Só para deixar claro, ao lançar seu próprio trabalho, o Licenciante é você . E o Licenciado, qualquer pessoa usando seu código. Em termos gerais, isso inclui duas categorias principais: desenvolvedores e usuários finais .

E para corrigir mais alguns termos de vocabulário, modificando sua Obra, um Licenciado está criando o que é chamado de Obra Derivada. No entanto, nem todas as licenças concordam se o uso de sua Obra em uma obra maior qualificará esta última como uma Obra Derivada ou não. Como você verá abaixo, algumas licenças tratam especificamente desses problemas.

Qual é o propósito da Licença?

Basicamente, a Licença é uma forma de o Licenciante e o Licenciado concordarem com os direitos e obrigações de ambos . Esses direitos e obrigações associados a uma Licença podem ser qualquer coisa - até o limite permitido pela Lei . Por exemplo, um Licenciante pode exigir que o Licenciado cite seu nome ao usar seu trabalho. Ou pode autorizar a cópia de sua obra, mas não pode modificá-la de forma alguma. Ou ainda exigir que a Obra Derivada seja lançada sob os mesmos termos da Obra original.

Por outro lado, a Licença é uma forma de proteger também o Licenciado. Ao declarar claramente como ele pode usar o seu Trabalho, ele não corre o risco de vê-lo inesperadamente pedindo royalties ou outra forma de compensação pelo uso do seu trabalho. Algo que é fundamental para a adoção do seu Trabalho.

Portanto, a Licença protegerá seu trabalho. Protegerá o Licenciante. Mas vai te proteger também. Quero dizer você, pessoalmente . Por exemplo, limitando a responsabilidade do Licenciante por danos potenciais causados por seu trabalho.

E se eu não usar nenhuma licença?

Na ausência de uma Licença explicitamente associada a uma Obra, os direitos autorais padrão para a jurisdição do autor se aplicam. Em outras palavras, nunca considere a ausência de licença como uma concessão implícita para que façamos o que quisermos com seu trabalho. Este é exatamente o oposto: sem qualquer licença específica, você, o autor, não renunciou a NENHUM dos seus direitos conforme garantidos por lei.

Mas lembre-se sempre de que uma Licença rege direitos e obrigações. Você já se perguntou por que tantos textos de Licença contêm uma isenção de responsabilidade escrita em TODAS AS LETRAS EM MAIÚSCULAS sobre as garantias fornecidas com um produto - ou, mais frequentemente, a ausência de garantia? Isso é para proteger o proprietário da obra contra garantias implícitas ou suposições do usuário. A última coisa que você quer é ser processado como consequência de lançar seu trabalho em código aberto!

Posso usar uma licença personalizada?

Sim você pode. Mas você provavelmente não deveria.

Sendo um contrato, uma Licença não pode (na maioria das jurisdições? Todas elas?) Ter precedência sobre as leis territoriais. Daí a dificuldade de fazer valer os direitos de licenciamento em um mundo globalizado. Provavelmente seria mais fácil (quero dizer, menos difícil) defender uma Licença padrão diante de um juiz. Na verdade, tais casos já foram defendidos em várias jurisdições e podem ser citados como precedentes. Obviamente, algo que não pode ser feito com uma licença personalizada.

Além disso, as Licenças personalizadas (às vezes apelidadas de Licenças personalizadas) podem criar incompatibilidades com outras licenças, resultando em uma compatibilidade deficiente de seu trabalho, legalmente falando.

Posso usar várias licenças?

Sim. O licenciamento múltiplo - notavelmente o licenciamento duplo - não é tão incomum. Isso é especialmente verdadeiro quando você deseja criar um negócio em torno do seu Trabalho gratuito. Nesse caso, seu projeto provavelmente será lançado sob alguma licença FOSS e uma licença comercial.

Outro uso do licenciamento múltiplo é para aumentar a compatibilidade, permitindo que seu Trabalho seja combinado com trabalhos publicados em diferentes termos ou para satisfazer diferentes necessidades ou requisitos do usuário. Esta é a razão pela qual alguns projetos são lançados sob várias licenças FOSS.

Mas esteja avisado: nem todas as licenças são compatíveis juntas! Mais uma vez, eu o desencorajaria a reinventar a roda, permanecendo com licenças compatíveis bem conhecidas, se você quiser seguir esse caminho.

Posso alterar a licença mais tarde?

Sim. O detentor dos direitos autorais é responsável pelos termos de licenciamento. É bastante fácil alterar a Licença, desde que você seja o único contribuidor. Mas, para dar um exemplo extremo, se Linus Torvald quisesse lançar o kernel do Linux sob uma licença diferente, ele provavelmente precisaria primeiro da concordância dos milhares de contribuidores desse projeto. Algo impossível na prática.

Para um projeto de tamanho mais razoável, isso pode ser feito. E de fato, foi como você verá em alguns exemplos abaixo.

Qual licença de código aberto devo usar?

Qual licença de código aberto devo usar

Ok, agora você está convencido de que deve usar uma licença padrão. Mas qual escolher? A escolha final é com você. E existem comparadores muito bem feitos disponíveis na web para ajudá-lo na sua escolha. Apenas para citar meus favoritos:

Mas, como sempre acontece com as questões jurídicas, a resposta definitiva será ler - e compreender - o texto oficial da Licença. Isso pode exigir a ajuda de um advogado profissional. Algo que não sou.

Mas o que posso fazer é fornecer a você uma introdução às licenças mais comuns para orientar seus primeiros passos.

GNU General Public License (GPL)

A GPL é uma das licenças de código aberto mais populares. Ele vem em várias versões - mas para um novo projeto, você deve considerar a mais recente, que é a GPL 3 no momento em que este livro foi escrito.

Apoiando um forte copyleft, a GPL é provavelmente a licença de software livre mais protetora. Algo que pode ser elogiado ou criticado dependendo do seu ponto de vista. O conceito central por trás da GPL sendo qualquer Trabalho Derivado deve ser lançado sob a GPL também.

  • Copyleft forte
  • A Obra é adequada para uso comercial.
  • Os licenciados podem modificar o trabalho.
  • Os licenciados devem liberar a fonte juntamente com a Obra Derivada.
  • O Trabalho Derivado deve ser liberado nos mesmos termos.

Projetos populares

A GPL é a licença natural para os projetos da Free Software Foundation. Incluindo as ferramentas GNU no coração de qualquer sistema Linux. Projetos grandes - a fortiori comerciais - tendem a usar a GPL em conjunto com uma ou várias outras licenças.

  • Inkscape (Desenho vetorial): GPLv2
  • Drupal (Sistema de gerenciamento de conteúdo da web): GPLv2
  • MariaDB (Bancos de dados): GPL v2
  • MySQL (Bancos de dados): GPL e Licença Comercial
  • Qt (estrutura de aplicativo multiplataforma): LGPL, GPL e Comercial - dependendo dos módulos e do nível de contrato de serviço

Licença Pública Geral Menor GNU (LGPL)

A GPL é muito restritiva no sentido de que força qualquer Trabalho Derivado a ser liberado de código aberto sob os mesmos termos. Esta é uma preocupação especial para bibliotecas - que são blocos de construção para softwares maiores: ao lançar uma biblioteca sob a GPL, você forçará qualquer aplicativo usando essa biblioteca a ser lançado como GPL também. Algo que a LGPL aborda.

Para bibliotecas, o FSF distingue três casos:

  • Sua biblioteca implementa um padrão que compete com um padrão não livre. Nesse caso, a ampla adoção de sua biblioteca ajudará a causa do Software Livre. A FSF sugere a licença Apache bastante permissiva para esse caso (descrito mais tarde naquele artigo).
  • Sua biblioteca implementa um padrão já implementado por outras bibliotecas. Nesse caso, não há benefício para a causa do Software Livre abandonar totalmente o copyleft. Portanto, a FSF recomenda o LGPL.
  • Finalmente, se sua biblioteca não competir com outras bibliotecas ou outros padrões, a FSF recomenda a GPL.

Os argumentos da FSF são principalmente éticos e filosóficos. Na prática, os desenvolvedores podem ter outras preocupações. Especialmente se planejam desenvolver um negócio baseado na obra licenciada. Mais uma vez, o licenciamento duplo pode ser uma opção a ser considerada.

  • Copyleft fraco (vinculado à biblioteca vinculada dinamicamente)
  • A Obra é adequada para uso comercial.
  • Os licenciados podem modificar o trabalho.
  • Os licenciados devem liberar a fonte juntamente com a Obra Derivada.
  • se você modificar a Obra, deve liberar a Obra Modificada sob os mesmos termos.
  • se você usar a Obra,_não precisa_para liberar a Obra Derivada sob os mesmos termos.

Projetos populares

  • OpenOffice.org 3 (suíte de escritório): LGPLv3 - mas o Apache OpenOffice 4 mudou para a licença Apache 2.0.
  • GTK +, o GIMP Toolkit (kit de ferramentas GUI): LGPLv2.1
  • CUPS (sistema de impressão multiplataforma): GPL ou LGPLv2 com exceção para sistemas operacionais Apple - dependendo dos componentes.
  • WineHQ (camada de compatibilidade do Windows): LGPLv2.1
  • GNU Aspell (Verificador ortográfico): LGPLv2.1

Licença Pública Eclipse (EPL 1.0)

Licença de código aberto Eclipse

Com um copyleft mais fraco do que o LGPL, a Licença Eclipse é mais amigável aos negócios, pois permite sublicenciar e construir software feito de código licenciado EPL e não EPL (mesmo proprietário), desde que o código não EPL seja um separado módulo [s] de software .

Além disso, a EPL adiciona proteção extra para os contribuintes do código EPL no caso de ações judiciais/danos causados por uma oferta comercial que inclua esse Trabalho.

  • Copyleft fraco (vinculado ao módulo de software)
  • A Obra é adequada para uso comercial.
  • Os licenciados podem modificar a obra.
  • Se você modificar a Obra, deve liberar a Obra Modificada sob os mesmos termos.
  • Se você usar a Obra,_não precisa_para liberar a Obra Derivada sob os mesmos termos.
  • Os distribuidores comerciais do software devem defender ou compensar os contribuidores EPL originais de ações judiciais/danos causados pela oferta comercial.

Projetos populares

Obviamente, a EPL é a licença natural para os projetos da Eclipse Foundation. Incluindo o popular IDE Eclipse. Mas ganhou alguma popularidade além disso - especialmente no mundo Java:

  • Clojure (Linguagem de programação)
  • Graphviz (pacote de visualização de gráfico)
  • Jetty (servidor de aplicativos): licença dupla EPL1.0/Licença Apache 2.0 desde Jetty 7
  • JUnit (estrutura de teste de unidade Java)

Licença Pública Mozilla (MPL)

Licença Mozilla

A Licença Pública Mozilla é a licença usada para software desenvolvido pela Fundação Mozilla. Mas certamente não se limita a essa área. A MPL visa ser uma etapa de compromisso entre licenças estritas (como a GPL) e licenças permissivas (como a Licença MIT).

No MPL, a unidade de licenciamento é o arquivo de origem. Os licenciadores não têm permissão para restringir os direitos do usuário e o acesso a qualquer arquivo coberto pela MPL. Mas o mesmo projeto também pode conter arquivos licenciados não MPL proprietários. O projeto resultante pode ser liberado sob qualquer licença, desde que seja concedido acesso aos arquivos licenciados MPL.

  • Copyleft fraco (vinculado a arquivos individuais)
  • A Obra é adequada para uso comercial.
  • Os licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a atribuição adequada para a Obra.
  • Os licenciados podem redistribuir o trabalho derivado sob diferentes termos
  • Os licenciados não podem relicenciar fontes licenciadas por MPL
  • Os licenciados devem distribuir o código-fonte licenciado por MPL junto com sua Obra Derivada.

Projetos populares

  • Mozilla Firefox (navegador da web), Mozilla Thunderbird (cliente de e-mail): MPL
  • LibreOffice (pacote de escritório): MPL2.0
  • H2 Database Engine (banco de dados): MPL2.0 e Eclipse License 1.0
  • Cairo (mecanismo gráfico 2D): MPL 1.1 ou LGPLv2.1

Licença Apache 2.0 (ASL 2.0)

Licença Apache

Com a ASL, estamos entrando no reino das licenças gratuitas permissivas . Mas mesmo a FSF sugere a Licença Apache em alguns casos. A Licença Apache é permissiva, pois não requer qualquer Trabalho Derivado a ser distribuído sob os mesmos termos. Em outras palavras, esta é uma licença não copyleft.

O ASL é a única licença usada para projetos da Apache Software Foundation. Por ser considerado favorável aos negócios, ele foi amplamente adotado fora dessa organização. Não é incomum ver projetos de nível empresarial serem lançados sob o ASL.

  • Não copyleft
  • A Obra é adequada para uso comercial.
  • Os licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a atribuição adequada para a Obra.
  • Os licenciados podem redistribuir o trabalho derivado sob diferentes termos.
  • Os licenciados não precisam distribuir o código-fonte junto com sua Obra Derivada.

Projetos populares

  • Android (sistema operacional): ASL 2.0 com algumas exceções (principalmente em relação ao kernel Linux)
  • Apache httpd (servidor da Web): ASL 2.0
  • Apache Spark (estrutura de computação em cluster): ASL 2.0
  • Spring Framework (Framework para aplicativos empresariais baseados em Java): ASL 2.0

Licença MIT

Esta é uma licença muito popular. Provavelmente até o mais popular. Ao colocar poucas limitações na reutilização, a Licença MIT pode ser facilmente associada a outras licenças, desde a GPL até licenças proprietárias.

  • Não copyleft
  • A Obra é adequada para uso comercial.
  • Os licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a atribuição adequada para a Obra.
  • Os licenciados podem redistribuir o trabalho derivado sob diferentes termos
  • Os licenciados não precisam distribuir o código-fonte junto com sua Obra Derivada.

Projetos populares

  • node.js (ambiente de tempo de execução JavaScript): Licença MIT
  • jQuery (biblioteca JavaScript do lado do cliente): Licença MIT (até 2012, licença dupla MIT/GPL)
  • Atom (editor de texto): Licença MIT
  • AngularJS (estrutura de aplicativo JavaScript): Licença MIT
  • SQLAlchemy (kit de ferramentas SQL e Mapeador Relacional de Objetos para Python): Licença MIT

Licenças BSD

A Licença BSD vem em três opções. A Licença original de 4 cláusulas, a Licença revisada de 3 cláusulas e a Licença simplificada de 2 cláusulas. Tudo em espírito está muito próximo da Licença do MIT. E, de fato, há poucas diferenças práticas entre a Licença BSD de 2 cláusulas e a Licença MIT.

Licenças BSD de 3 e 4 cláusulas adicionam mais requisitos relativos à reutilização e publicidade de nomes. Isso é algo a considerar se você deseja proteger seu produto ou marca.

  • Não copyleft
  • A Obra é adequada para uso comercial.
  • Os licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a atribuição adequada para a Obra.
  • Os licenciados podem redistribuir o trabalho derivado sob diferentes termos.
  • Os licenciados não precisam distribuir o código-fonte junto com sua Obra Derivada.
  • Os licenciados não podem usar o nome do autor original ou marca comercial para endossar o trabalho derivado (3 e 4 cláusulas BSD)
  • Os licenciados devem reconhecer o Autor original em todos os materiais publicitários que mencionem recursos ou uso da Obra (4-cláusula BSD)

Projetos populares

  • Django (web ramework): BSD de 3 cláusulas
  • Redis (armazenamento de dados): BSD de 3 cláusulas
  • Ruby (linguagem de programação): BSD de 2 cláusulas e licença personalizada
  • Nginx (servidor da Web): BSD de 2 cláusulas
  • NetBSD (Sistema operacional): BSD de 2 cláusulas - BSD de 4 cláusulas até 2008

A última palavra sobre licenças de código aberto

Se você chegou tão longe, parabéns! Você entende agora, licenciamento é realmente um tópico enorme e complexo. Mas vale a pena escolher a licença certa para o seu projeto - e fazer essa escolha o quanto antes. Isso pode poupar muitos problemas mais tarde, para que você possa usar seu tempo e energia trabalhando em seu projeto em vez de lidar com direitos autorais ou questões de compatibilidade legal.

Mesmo que eu tenha feito meu melhor para tornar esse tópico acessível, nem sempre é fácil resumir as sutilezas das várias licenças. E além das poucas licenças principais apresentadas aqui, existem dezenas de outras mais ou menos usadas.

Então, não hesite em usar a seção de comentários abaixo para nos dizer qual é SUA licença preferida e por quê. Ou para mencionar algumas características importantes que devo ter esquecido!

Confira também a versão original desse post em inglês
Esse post foi originalmente escrito por Sylvain Leroux e publicado no site itsfoss.com. Tradução sujeita a revisão.

Open Source Licenses Comparison [Guide]

Propaganda
Blog Comments powered by Disqus.
Propaganda