Introdução às licenças de código aberto

As licenças de código aberto são acordos legais que definem como o software de código aberto pode ser usado, modificado e distribuído. Cada projeto de código aberto inclui uma licença que especifica os direitos concedidos aos usuários e quaisquer obrigações que eles devem cumprir. Compreender as licenças é essencial para a implementação legal e segura de software de código aberto em contextos organizacionais.

O que as licenças de código aberto definem

Uma licença de código aberto é um documento legal que acompanha o código-fonte e especifica:

Permissões concedidas

As licenças concedem explicitamente aos utilizadores determinados direitos:

• Direitos de utilização: Permissão para usar o software para qualquer finalidade, incluindo aplicações comerciais.
• Direitos de modificação: Permissão para modificar o código-fonte para atender a necessidades específicas, corrigir bugs ou adicionar recursos.
• Direitos de distribuição: Permissão para compartilhar o software com outras pessoas, seja na forma original ou modificada.
• Direitos de sublicenciamento: Em alguns casos, permissão para licenciar o software para outros sob termos diferentes.

Sem uma licença explícita, a lei de direitos autorais proíbe o uso, modificação ou distribuição de software. A licença fornece permissão legal para essas atividades.

Obrigações impostas

As licenças normalmente impõem requisitos aos usuários:

• Requisitos de atribuição: Deve preservar os avisos de direitos autorais e o texto de licença em cópias distribuídas.
• Divulgação do código-fonte: Algumas licenças exigem o fornecimento de código-fonte ao distribuir binários.
• Preservação da licença: Deve incluir o texto da licença com cópias distribuídas.
• Licenciamento de trabalho derivado: Algumas licenças exigem trabalhos derivados para usar a mesma licença (copyleft).
• Concessão de patentes: Algumas licenças incluem concessões explícitas de patentes ou cláusulas de rescisão defensiva.

Isenções de responsabilidade e garantia

Quase todas as licenças de código aberto se isentam de responsabilidade e garantias:

• Sem garantia: O software é fornecido "no estado em que se encontra" sem garantias de comercialização, adequação à finalidade ou não violação.
• Sem responsabilidade: Os autores e detentores de direitos autorais não são responsáveis por danos resultantes do uso do software.
• Risco do utilizador: Os utilizadores aceitam todos os riscos associados à utilização do software.

Essas isenções de responsabilidade protegem os desenvolvedores de código aberto de responsabilidade legal, reconhecendo que o software normalmente é fornecido livremente sem compensação.

A definição de código aberto

A Open Source Initiative (OSI) mantém a definição autorizada de código aberto que especifica os critérios para que as licenças sejam consideradas verdadeiramente de código aberto:

Requisitos principais

De acordo com a definição de código aberto, as licenças de código aberto devem:

Redistribuição gratuita:

• Sem restrições: As licenças não podem restringir ninguém de vender ou dar o software como parte de uma distribuição agregada.
• Sem royalties: As licenças não podem exigir royalties ou taxas por tais vendas.

Inclusão do código-fonte:

• Disponibilidade: Os programas distribuídos devem incluir código-fonte ou fornecer instruções claras para obtê-lo sem nenhum custo.
• Formulário preferido: O código-fonte deve estar na forma preferida para modificações.
• Sem ofuscação: O código-fonte deliberadamente ofuscado não satisfaz o requisito.

Trabalhos derivados:

• Modificações permitidas: As licenças devem permitir modificações e trabalhos derivados.
• Mesmos termos: As licenças devem permitir a distribuição de modificações nos mesmos termos do software original.

Integridade do código-fonte do autor:

• Arquivos de patch: As licenças podem exigir modificações para serem distribuídas como arquivos de patch ao lado da fonte original.
• Nomeação: As licenças podem exigir que obras derivadas usem nomes ou números de versão diferentes do original.

Não discriminação de pessoas ou grupos:

• Acesso universal: As licenças não podem discriminar qualquer pessoa ou grupo de pessoas.
• Igualdade de direitos: Todos devem ter os mesmos direitos de utilização do software.

Nenhuma discriminação contra áreas de atuação:

• Qualquer finalidade: As licenças não podem restringir o uso do software em campos específicos, como negócios ou pesquisa genética.
• Uso comercial: As licenças não podem proibir o uso do software em aplicativos comerciais.

Distribuição da licença:

• Aplicação automática: Os direitos associados ao programa devem aplicar-se a todas as pessoas a quem o programa é redistribuído.
• Sem licenças adicionais: Os usuários não devem precisar executar licenças adicionais para receber esses direitos.

A licença não deve ser específica de um produto:

• Direitos autónomos: Os direitos não devem depender de o programa fazer parte de uma distribuição de software específica.
• Execução independente: Se extraído da distribuição original, o software deve ter os mesmos direitos.

A licença não deve restringir outros softwares:

• Sem contaminação: As licenças não podem impor restrições a outro software distribuído juntamente com o software licenciado.
• Agregação permitida: As licenças não podem impedir a distribuição do software juntamente com o software sob diferentes licenças.

A licença deve ser tecnologicamente neutra:

• Sem restrições de interface: As licenças não podem exigir tecnologias ou estilos de interface específicos.
• Método de execução agnóstico: As licenças não devem se importar se o software é executado clicando em ícones, linhas de comando ou interfaces da Web.

Por que esses requisitos são importantes

A Definição de Código Aberto garante que as licenças proporcionam uma liberdade significativa:

Protege a liberdade do utilizador: Os requisitos impedem que as licenças imponham restrições ocultas que prejudicariam os princípios de código aberto.

Permite o uso comercial: Ao proibir a discriminação contra campos de atuação, a definição garante que as empresas possam construir produtos usando software de código aberto.

Promove a compatibilidade: Os requisitos que limitam a forma como as licenças podem afetar outros softwares reduzem os problemas de compatibilidade.

Previne a fragmentação: Ao exigir condições razoáveis, a definição impede a proliferação de licenças quase abertas incompatíveis.

Categorias de licenças de código aberto

Embora existam muitas licenças de código aberto diferentes, elas geralmente se enquadram em duas grandes categorias:

Licenças permissivas

As licenças permissivas impõem requisitos mínimos às obras derivadas:

• Caraterísticas: Permitir a incorporação de código em software proprietário sem exigir que o software proprietário seja de código aberto.
• Prescrições: Normalmente, exigem apenas atribuição (preservando avisos de direitos autorais e texto de licença).
• Uso comercial: Totalmente compatível com o desenvolvimento de software comercial.
• Exemplos: Licença MIT, Licença Apache 2.0, Licenças BSD.

As licenças permissivas maximizam a liberdade para os usuários, permitindo-lhes criar produtos comerciais de código fechado incorporando código aberto.

Licenças Copyleft

As licenças Copyleft requerem trabalhos derivados para usar a mesma licença:

• Caraterísticas: Certifique-se de que as versões modificadas e os trabalhos derivados permaneçam de código aberto.
• Prescrições: Requer a distribuição do código-fonte e o uso da mesma licença para trabalhos derivados.
• Uso comercial: Pode ser usado em software comercial, mas os trabalhos derivados devem ser de código aberto.
• Exemplos: GNU General Public License (GPL), GNU Lesser General Public License (LGPL), Mozilla Public License (MPL).

As licenças Copyleft priorizam a liberdade de software sobre a liberdade do usuário, garantindo que o software de código aberto permaneça de código aberto mesmo enquanto evolui.

Copyleft suave

Algumas licenças ocupam um meio-termo:

• Uso da biblioteca permitido: Permitir a vinculação a bibliotecas em aplicativos proprietários sem abrir o aplicativo.
• Restrições de modificação: As modificações na própria biblioteca devem ser de código aberto.
• Exemplos: GNU LGPL, Licença Pública Mozilla.

Licenças copyleft fracas equilibram a promoção do desenvolvimento de código aberto com a permissão do uso comercial.

Seleção de licenças por projetos

Os projetos de código aberto escolhem licenças com base em seus objetivos:

Maximizando a adoção: Os projetos que priorizam a adoção generalizada geralmente escolhem licenças permissivas que não impõem obrigações significativas aos usuários.

Garantir a liberdade: Os projetos que priorizam a liberdade de software escolhem licenças copyleft que garantem que os trabalhos derivados permaneçam de código aberto.

Prevenção de garfos proprietários: As licenças Copyleft impedem as empresas de criar versões proprietárias de software de código aberto.

Proteção por patente: Os projetos preocupados com patentes escolhem licenças com concessões explícitas de patentes (como o Apache 2.0) que fornecem direitos de patente mais claros.

Compatibilidade: Os projetos podem escolher licenças compatíveis com outro software do qual dependem ou com os quais desejam se integrar.

Várias licenças

Alguns projetos usam várias estratégias de licenciamento:

Licenciamento duplo: Ofereça software sob licenças comerciais e de código aberto, permitindo que os usuários escolham quais termos se aplicam.

Empilhamento de licenças: Diferentes componentes de um projeto podem ter licenças diferentes.

Evolução da licença: Os projetos às vezes mudam de licença ao longo do tempo, embora isso exija o acordo de todos os contribuidores.

O paradoxo da transparência

A transparência do código-fonte cria benefícios e riscos de segurança:

Benefícios da transparência em termos de segurança

O código-fonte público permite melhorias de segurança:

• Muitos olhos: Milhares de desenvolvedores podem revisar o código em busca de vulnerabilidades, aumentando a probabilidade de descoberta.
• Divulgação mais rápida: Quando são encontradas vulnerabilidades, estas podem ser divulgadas e corrigidas publicamente, informando todos os utilizadores.
• Patches comunitários: Os desenvolvedores preocupados com a segurança contribuem com patches para corrigir vulnerabilidades.
• Capacidade de auditoria: As organizações podem auditar dependências de código aberto para problemas de segurança, o que é impossível com software de código fechado.

Riscos de transparência em termos de segurança

O código-fonte público também ajuda os atacantes:

• Descoberta de vulnerabilidade: Agentes mal-intencionados podem analisar o código-fonte para encontrar vulnerabilidades exploráveis.
• Desenvolvimento de exploits: Compreender os detalhes da implementação ajuda os atacantes a desenvolver exploits.
• Identificação do alvo: Os invasores podem identificar quais aplicativos usam versões vulneráveis de componentes de código aberto.
• Exploração de dia zero: Os atacantes podem descobrir e explorar vulnerabilidades antes que elas sejam divulgadas publicamente.

O equilíbrio

A investigação sugere que a transparência proporciona benefícios líquidos em termos de segurança:

Lei de Linus: "Dado o número suficiente de olhos, todos os erros são fáceis de resolver." A revisão aberta geralmente encontra e corrige vulnerabilidades mais rapidamente do que o desenvolvimento de código proprietário.

Obscuridade não é segurança: Manter o código-fonte em segredo não impede vulnerabilidades — apenas as oculta até que os invasores eventualmente as descubram.

Divulgação responsável: A comunidade de código aberto desenvolveu práticas de divulgação responsável que equilibram segurança com transparência.

Realidade prática: As violações de segurança mais graves envolvem software de código fechado ou configuração incorreta, não vulnerabilidades de código aberto, sugerindo que a transparência não reduz inerentemente a segurança.

Compreender as licenças de código aberto e suas categorias fornece a base para avaliar licenças específicas. A próxima unidade explora as licenças comuns de código aberto em detalhes, ajudando você a entender quais termos as licenças populares impõem e como elas diferem.