Comparação de licenças de código aberto

Resumo : Este guia detalhado oferece uma comparação efetiva de licenças de código aberto. Com as licenças de código aberto explicadas aqui, ele deve ajudá-lo a escolher a licença de código aberto correta para o seu projeto.

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

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

A resposta curta para essa última questão é fácil: sim, você realmente precisa de uma licença. Quanto a qual Licença você precisa, posso até fazer uma resposta mais curta: depende .

Mas se você é sério sobre o seu projeto, você provavelmente quer um pouco mais de detalhes. Então leia adiante - e lembre-se: você está entrando em território de guerra santa agora!

Preciso de uma licença? E o que é uma licença depois de tudo?

Uma Licença é uma permissão oficial concedida pelo proprietário de algum Trabalho (o “Licenciante”) a outras pessoas (o “Licenciado”) e rege como o Licenciado pode usar o Trabalho do Licenciante.

Isso assume a forma de um contrato, ambas as partes têm que concordar. Hoje em dia, a aceitação é bastante implícita: apenas usando algum trabalho, você tem a reputação de concordar com sua licença de uso.

Apenas para tornar as coisas claras, ao liberar seu próprio trabalho, o Licenciante é você . E o Licenciado, qualquer um usando seu código. De um modo geral, isso inclui duas categorias principais: desenvolvedores e usuários finais .

E para consertar mais alguns termos de vocabulário, modificando seu Trabalho, um Licenciado está criando o que é chamado de Trabalho Derivado. Nem todas as licenças concordam, entretanto, se o uso de seu trabalho em um trabalho maior o qualificará como um Trabalho Derivado ou não. Como você verá abaixo, algumas licenças abordam especificamente esses problemas.

Qual é o objetivo 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 copiar seu trabalho, mas não modificá-lo de qualquer maneira. Ou até mesmo exigir que o trabalho derivado seja lançado sob os mesmos termos do trabalho original.

Por outro lado, a Licença é uma forma de proteger o Licenciado também. Ao declarar claramente como ele pode usar seu Trabalho, ele não corre o risco de ver você inesperadamente pedindo royalties ou outra forma de compensação por ter usado seu trabalho. Algo que é crítico para a sua adoção no trabalho.

Portanto, a licença protegerá seu trabalho. Protegerá o licenciante. Mas vai proteger você também. Quero dizer você pessoalmente . Por exemplo, limitando a responsabilidade do Licenciante pelos possíveis danos 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 o seu trabalho. Isso é exatamente o oposto: sem qualquer licença específica, você, o autor, não renunciou a QUALQUER um dos seus direitos conforme garantido pela 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 um aviso de isenção de responsabilidade escrito em TODAS AS LETRAS MAIÚSCULAS sobre as garantias fornecidas com um produto - ou, mais frequentemente, a ausência de garantia? Isso é para proteger o proprietário do trabalho contra garantias implícitas ou suposições do usuário. A última coisa que você quer é ser processado como consequência de liberar seu trabalho de 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? Todos eles?) Ter precedência sobre as leis territoriais. Daí a dificuldade em fazer valer os direitos de licenciamento em um mundo globalizado. Seria provavelmente mais fácil (quero dizer, menos difícil) defender uma licença “padrão” perante um juiz. De fato, tais casos já foram defendidos em diversas jurisdições e podem ser citados como precedentes. Obviamente, algo que não pode ser feito com uma licença personalizada.

Além disso, Licenças Personalizadas (às vezes apelidadas de Licenças de Vaidade) podem criar incompatibilidades com outras licenças, resultando em uma baixa compatibilidade do seu Trabalho legalmente.

Posso usar várias licenças?

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

Outro uso do multi-licenciamento é aumentar a compatibilidade, permitindo que o seu Trabalho seja combinado com trabalhos publicados em termos diferentes ou para satisfazer diferentes necessidades ou requisitos do usuário. Esta é uma 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 em conjunto! Mais uma vez, eu iria desencorajá-lo de reinventar a roda, ficando com licenças compatíveis conhecidas, se você quiser ir por esse caminho.

Posso mudar a licença “mais tarde”?

Sim. O detentor dos direitos autorais é responsável pelos termos de licenciamento. É muito fácil alterar a licença, desde que você seja o único colaborador. Mas para dar um exemplo extremo, se Linus Torvald quisesse lançar o Kernel Linux sob uma licença diferente, ele provavelmente precisaria primeiro do acordo dos milhares de colaboradores para esse 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?

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 disponibilizados na Web para ajudá-lo na sua escolha. Apenas para citar meus favoritos:

  • //oss.ly/licdif
  • //choosealicense.com/ / //choosealicense.com/appendix/
  • //opensource.org/licenses
  • //tldrlegal.com/

Mas, como sempre, com assuntos legais, a resposta definitiva será ler - e entender - 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 uma introdução às licenças mais comuns para orientar seus primeiros passos.

Licença Pública Geral GNU (GPL)

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

Apoiando um copyleft forte, a GPL é provavelmente a licença de software livre mais protetora. Algo que pode ser elogiado ou criticado por depender 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
  • O trabalho é adequado para uso comercial.
  • Licenciados podem modificar o trabalho.
  • Os licenciados devem liberar a fonte juntamente com o trabalho derivado.
  • O trabalho derivado deve ser liberado sob os 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. Grandes projetos - 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 (framework de aplicações multiplataforma): LGPL, GPL e Commercial - dependendo dos módulos e nível de contrato de serviço

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

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

Para as bibliotecas, a FSF distingue três casos:

  • Sua biblioteca implementa um padrão que concorre 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 (descrita mais adiante naquele artigo).
  • Sua biblioteca implementa um padrão já implementado por outras bibliotecas. Nesse caso, não há nenhum benefício para a causa do Software Livre abandonar completamente o copyleft. Portanto, a FSF recomenda a LGPL.
  • Finalmente, se sua biblioteca não competir com outras bibliotecas nem 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 eles planejam desenvolver um negócio baseado no trabalho licenciado. Mais uma vez, o licenciamento duplo pode ser uma opção a considerar.

  • Copyleft fraco (vinculado à biblioteca vinculada dinamicamente)
  • O trabalho é adequado para uso comercial.
  • Licenciados podem modificar o trabalho.
  • Os licenciados devem liberar a fonte juntamente com o trabalho derivado.
  • Se você modificar o trabalho, deverá liberar o trabalho modificado sob os mesmos termos.
  • se você usar o Trabalho, você não precisará liberar o Trabalho Derivado nos mesmos termos.

Projetos populares

  • OpenOffice.org 3 (suite de escritório): LGPLv3 - mas o Apache OpenOffice 4 mudou para o Apache License 2.0.
  • GTK +, o kit de ferramentas do GIMP (kit de ferramentas GUI): LGPLv2.1
  • CUPS (sistema de impressão multiplataforma): GPL ou LGPLv2, com exceção dos sistemas operacionais da 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)

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

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

  • Copyleft fraco (ligado ao software "módulo")
  • O trabalho é adequado para uso comercial.
  • Os licenciados podem modificar o trabalho.
  • Se você modificar o trabalho, deverá liberar o trabalho modificado sob os mesmos termos.
  • Se você usa o Trabalho, você não precisa liberar o Trabalho Derivado nos mesmos termos.
  • Os distribuidores comerciais do software devem defender ou compensar os contribuintes originais da EPL de ações judiciais / danos causados ​​pela oferta comercial.

Projetos populares

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

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

Licença Pública Mozilla (MPL)

A Licença Pública Mozilla é uma licença usada para software desenvolvido pela fundação Mozilla. Mas certamente não está limitado a essa área. A MPL pretende ser uma etapa de compromisso entre licenças rígidas (como a GPL) e licenças permissivas (como a licença MIT).

Na MPL, a “unidade de licenciamento” é o arquivo de origem. Licenciantes não estão autorizados a restringir os direitos de usuário e acesso em qualquer arquivo coberto pelo 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 o acesso aos arquivos licenciados da MPL seja concedido.

  • Copyleft fraco (ligado a arquivos individuais)
  • O trabalho é adequado para uso comercial.
  • Licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a devida atribuição para o trabalho.
  • Licenciados podem redistribuir o trabalho derivado sob termos diferentes
  • Licenciados não podem relicenciar fontes licenciadas pela MPL
  • Os Licenciados devem distribuir o código-fonte licenciado por MPL juntamente com seu Trabalho Derivado.

Projetos populares

  • Mozilla Firefox (navegador da web), Mozilla Thunderbird (cliente de email): MPL
  • LibreOffice (suíte de escritório): MPL2.0
  • Mecanismo de Banco de Dados H2 (banco de dados): MPL2.0 e Eclipse License 1.0
  • Cairo (motor gráfico 2D): MPL 1.1 ou LGPLv2.1

Licença Apache 2.0 (ASL 2.0)

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

A ASL é a única licença usada para projetos da Apache Software Foundation. Sendo considerado favorável às empresas, ganhou ampla adoção fora dessa organização. Não é incomum ver projetos de nível corporativo a serem lançados sob o ASL.

  • Não copyleft
  • O trabalho é adequado para uso comercial.
  • Licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a devida atribuição para o trabalho.
  • Licenciados podem redistribuir o Trabalho Derivado sob termos diferentes.
  • Os Licenciados não precisam distribuir o código-fonte juntamente com seu Trabalho Derivado.

Projetos populares

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

Licença MIT

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

  • Não copyleft
  • O trabalho é adequado para uso comercial.
  • Licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a devida atribuição para o trabalho.
  • Licenciados podem redistribuir o trabalho derivado sob termos diferentes
  • Os Licenciados não precisam distribuir o código-fonte juntamente com seu Trabalho Derivado.

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): MIT License
  • AngularJS (framework de aplicação JavaScript): MIT License
  • SQLAlchemy (kit de ferramentas SQL e Object Relational Mapper para Python): Licença MIT

Licenças BSD

Licença BSD vem em três sabores. A Licença de 4 cláusulas original, a Licença de 3 cláusulas “revisada” e a Licença de 2 cláusulas “simplificada”. Tudo em espírito está muito próximo da licença do MIT. E, de fato, há muito 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 sobre reutilização de nomes e publicidade. Isso é algo a ser considerado se você quiser proteger seu produto ou marca.

  • Não copyleft
  • O trabalho é adequado para uso comercial.
  • Licenciados podem modificar o trabalho.
  • Os licenciados devem fornecer a devida atribuição para o trabalho.
  • Licenciados podem redistribuir o Trabalho Derivado sob termos diferentes.
  • Os Licenciados não precisam distribuir o código-fonte juntamente com seu Trabalho Derivado.
  • Os Licenciados não podem usar o nome ou a marca original do Autor para endossar o Trabalho Derivado (3 e 4 cláusulas BSD)
  • Os licenciados devem reconhecer o autor original em todos os materiais de publicidade que mencionem recursos ou uso do trabalho (4-cláusula BSD)

Projetos populares

  • Django (ramework da web): 3-cláusula BSD
  • Redis (armazenamento de dados): 3-cláusula BSD
  • Ruby (linguagem de programação): 2-clause BSD e custom license
  • Nginx (servidor da Web): 2-cláusula BSD
  • NetBSD (sistema operacional): 2-cláusula BSD - 4-cláusula BSD até 2008

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

Se você chegar tão longe, parabéns! Você entende agora, licenciamento é realmente um tópico enorme e complexo. Mas vale a pena dedicar um tempo para escolher a licença certa para o seu projeto - e fazer essa escolha cedo. Pode poupar-lhe muitos problemas mais tarde, para que possa utilizar o seu tempo e energia a trabalhar no seu projeto, em vez de lidar com questões de direitos de autor ou de compatibilidade legal.

Mesmo que tenha feito o possível 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 é a sua licença preferida e por quê. Ou para mencionar algumas características importantes que eu poderia ter esquecido!

Recomendado

Como Esvaziar o Lixo no Ubuntu Linux
2019
As 10 principais alternativas do Microsoft Visio para Linux
2019
Iniciante amigável baseado no Gentoo Sabayon Linux tem um novo lançamento
2019