História do software de código aberto e suas licenças

O que é software de código aberto e de onde veio

A história do software de código aberto é, em grande parte, a história das suas licenças, porque uma licença é o único elemento que define o que pode fazer com código escrito por outra pessoa. O código era partilhado abertamente muito antes de essas licenças serem formalizadas. Deixou de ser partilhado quando passou a ser um produto, e as licenças foram criadas para garantir que a partilha se sustentava num tribunal.

Esta é a versão resumida. A versão completa é importante porque o software que executa hoje num servidor ainda conserva as marcas dessas decisões. Algumas dessas decisões foram tomadas em 1983. Outras foram tomadas no ano passado e explicam por que algumas aplicações dos nossos guias de self-hosting estão agora disponíveis em duas versões com nomes diferentes.

O software era partilhado antes de ser vendido

Nas décadas de 1950 e 1960, o software vinha com a máquina. A IBM distribuía o código-fonte com os seus sistemas, e grupos de utilizadores como o SHARE, fundado em 1955, partilhavam programas em fita. Duas mudanças acabaram com essa prática. Em 1969, a IBM anunciou que passaria a cobrar o software separadamente do hardware, criando um mercado próprio para o software. Depois, a legislação acompanhou essa mudança. O Computer Software Copyright Act de 1980 confirmou que os programas são obras protegidas por direitos de autor nos Estados Unidos. Depois de 1980, o código que não tivesse sido escrito por si passou a ser fechado por predefinição, pelo que a sua partilha exigia autorização escrita do autor.

O Homebrew Computer Club e a carta aberta aos entusiastas

O Homebrew Computer Club realizou a sua primeira reunião em março de 1975, numa garagem em Menlo Park, na Califórnia. Os membros levavam hardware e fita de papel, e a cópia fazia parte da reunião. O Altair BASIC, escrito por Bill Gates e Paul Allen, circulava pela sala em fita copiada. Em fevereiro de 1976, Gates respondeu no boletim do clube com "Uma carta aberta aos entusiastas".

Como a maioria dos entusiastas deve saber, a maioria de vocês rouba o seu software.

Ele escreveu que menos de um em cada dez proprietários de um Altair tinha pago pelo BASIC e que o tempo de computador usado para o escrever valia mais de 40,000 dólares. Todo o debate moderno já está presente nessa carta. Copiar software não custa nada e ajuda todas as pessoas que o copiam. Escrevê-lo ainda custou a alguém um ano da sua vida. Cada licença descrita abaixo é uma tentativa de responder simultaneamente a esses dois factos.

GNU em 1983 e a GPL como invenção jurídica

Richard Stallman anunciou o GNU em setembro de 1983 na Usenet, a rede de grupos de discussão utilizada antes da Web. GNU significa "GNU's Not Unix". O plano era criar um sistema completo compatível com Unix que qualquer pessoa pudesse copiar e modificar.

Unix livre! A partir deste Thanksgiving vou escrever um sistema de software completo compatível com Unix chamado GNU (de Gnu's Not Unix) e distribuí-lo gratuitamente a todas as pessoas que o possam utilizar.

A Free Software Foundation (FSF) surgiu em 1985. A sua Free Software Definition enumera quatro liberdades, numeradas a partir de zero: executar o programa para qualquer finalidade, estudá-lo e modificá-lo, redistribuir cópias e distribuir as versões modificadas. A liberdade 1 exige o código-fonte, porque ninguém consegue estudar um binário de forma prática. Neste contexto, "livre" refere-se à liberdade, não ao preço. A expressão usada pela própria FSF é free as in free speech, not free beer.

O manifesto não foi a invenção. A licença foi. A GNU General Public License (GPL) utiliza os direitos de autor para exigir a partilha, em vez de a impedir. O utilizador recebe as quatro liberdades com uma condição: qualquer pessoa a quem passe o software também as recebe, juntamente com o código-fonte. Stallman chamou a isto copyleft. A licença foi distribuída pela primeira vez com o GNU Emacs em 1985, tornou-se a GPL versão 1 em 1989 e chegou à versão 2 em junho de 1991.

A GPL funciona porque se baseia na legislação de direitos de autor, e não porque a contraria. Sem uma licença, não tem qualquer direito de distribuir o código de outra pessoa. A GPL concede esse direito e associa-lhe condições. Por isso, um fornecedor que distribua código GPL modificado dentro de um router e se recuse a fornecer o código-fonte não está a quebrar uma promessa. Está a infringir direitos de autor, e o titular desses direitos pode levar o caso a tribunal. É por isso que a aplicação da licença é possível, desde os casos da gpl-violations.org de Harald Welte nos anos 2000 até à ação judicial da Software Freedom Conservancy contra a Vizio, apresentada em 2021, que defende que a pessoa que comprou o televisor também pode exigir o código-fonte.

Linux concluiu o sistema

Em 1991, o projeto GNU já tinha o compilador, a biblioteca C, a shell e a maioria das ferramentas. Não tinha um kernel funcional, porque o kernel desenvolvido pelo próprio GNU, o Hurd, demorou muito mais do que o previsto. Em agosto de 1991, um estudante de Helsínquia publicou no newsgroup comp.os.minix:

Estou a desenvolver um sistema operativo (gratuito) (apenas por hobby; não será grande nem profissional como o gnu) para clones AT 386(486).

O Linux 0.01 foi lançado em setembro de 1991 com uma licença escrita pelo próprio Linus Torvalds, que proibia a sua venda. No início de 1992, substituiu-a pela GPLv2 e afirmou desde então que essa foi uma das suas melhores decisões. A licença tornou segura a participação de empresas: uma empresa podia afetar engenheiros ao kernel sabendo que um concorrente não poderia tornar privadas essas melhorias.

Já existia um Unix livre em Berkeley. A razão pela qual o Linux, e não o BSD (Berkeley Software Distribution), se tornou o Unix livre padrão está parcialmente relacionada com um processo judicial. A Unix System Laboratories processou a Berkeley Software Design em 1992, e o processo decorreu até ao início de 1994. Durante esses dois anos, os sistemas BSD tinham risco jurídico e o Linux não tinha esse risco. Foi nesse período que chegaram os utilizadores. A FSF pede que as pessoas chamem ao sistema combinado GNU/Linux, porque o Linux é o kernel e a maioria das ferramentas envolventes pertence ao GNU. A maioria das pessoas diz Linux. Ambos os nomes referem-se à mesma coleção de software.

1998: a reformulação da marca open source e a divisão que nunca foi resolvida

Em janeiro de 1998, a Netscape anunciou que publicaria o código-fonte do seu navegador. Era a maior empresa até então a fazer algo desse tipo, e isso expôs um problema prático. Em inglês, a expressão "free software" é entendida como "software que não custa nada", e foi exatamente isso que os executivos ouviram. Um grupo reuniu-se em Palo Alto em fevereiro de 1998 para encontrar um termo melhor, e Christine Peterson propôs "open source". Em poucas semanas, Eric Raymond e Bruce Perens criaram a Open Source Initiative (OSI). A organização adotou a Open Source Definition, adaptada das Debian Free Software Guidelines que Perens tinha escrito em 1997.

A Open Source Definition tem dez critérios. Dois deles determinam a maioria dos debates atuais: o código-fonte deve estar disponível, e a licença não pode restringir quem pode usar o programa nem para que finalidade pode usá-lo. Uma licença que diga "não pode oferecer isto como um serviço comercial" não cumpre o teste, independentemente do que mais permita. Retenha esta frase. É esta a linha que as licenças atuais de código disponível cruzam.

A divisão que começou em 1998 diz respeito às razões, não às licenças aceitáveis. A posição da FSF é ética: um utilizador que não pode alterar o programa não controla o próprio computador. A posição da OSI, defendida junto das empresas pelo ensaio de Raymond "The Cathedral and the Bazaar", é prática: o desenvolvimento aberto produz software melhor, e uma empresa pode tirar partido disso. A resposta de Stallman, "Why Open Source Misses the Point of Free Software", continua publicada em gnu.org, e ele nunca aceitou o termo mais recente. Perens, que ajudou a criá-lo, demitiu-se do conselho da OSI em 1999, afirmando que o movimento se tinha afastado do software livre.

Vale a pena ser preciso quanto à dimensão reduzida da diferença prática. As listas da FSF de licenças livres e da OSI de licenças aprovadas concordam em quase tudo, incluindo a GPL, MIT, Apache 2.0 e BSD. Os autores que precisam dos dois significados ao mesmo tempo usam FOSS (free and open source software) ou FLOSS (free/libre and open source software).

Como as empresas aprenderam a distribuir código

A entrada da Red Hat na bolsa em 1999 mostrou que havia dinheiro no suporte e no empacotamento, e não na venda de cópias. A IBM comprometeu 1 bilhão de dólares com Linux em 2001. O diretor executivo da Microsoft chamou Linux de "um cancro" em 2001. A mesma empresa entrou para a Linux Foundation como membro platinum em 2016 e comprou o GitHub em 2018 por 7.5 bilhões de dólares em ações. A IBM comprou a Red Hat em 2019 por 34 bilhões de dólares. Nada disso representou uma mudança de posição em relação às licenças. A mudança ocorreu no local onde está o dinheiro. Quando um sistema operativo é um custo partilhado, manter o seu próprio sistema é caro, e todos os fornecedores preferem competir na camada acima dele.

A propriedade empresarial também pode produzir o efeito contrário. Quando a Oracle comprou a Sun em 2010, herdou o MySQL e o OpenOffice.org, e as duas comunidades saíram. O MariaDB surgiu do MySQL, e o LibreOffice foi criado a partir de um fork do OpenOffice.org em setembro de 2010. Um fork é a única forma real de votação que uma comunidade de utilizadores possui, e é a licença que torna essa votação possível.

Por que algumas aplicações que aloja agora têm forks

A partir de 2018, um grupo de empresas alterou os termos das licenças de software que já tinha lançado. A situação era semelhante em todos os casos. Uma empresa empregava quase todos os developers, um cloud provider muito maior vendia o mesmo software como serviço gerido e a empresa mais pequena decidiu que a licença era o motivo pelo qual não conseguia competir.

• O MongoDB adotou a Server Side Public License (SSPL) em outubro de 2018. A SSPL estabelece que, se oferecer o software a terceiros como serviço, terá de publicar o código-fonte de tudo o que utiliza para fornecer esse serviço. A OSI não a aceitou como licença open source e o MongoDB retirou-a do processo de avaliação em 2019.
• O Redis adicionou restrições de utilização a alguns módulos em 2018 e 2019 e, em seguida, passou o servidor principal para termos dual source-available com a versão 7.4, em março de 2024. Um fork da última versão licenciada sob BSD surgiu dias depois com o nome Valkey, sob a Linux Foundation e com o apoio, entre outros, da Amazon, da Google e da Oracle. Em maio de 2025, o Redis adicionou a Affero General Public License version 3 (AGPLv3), aprovada pela OSI, como terceira opção para o Redis 8.
• A Elastic retirou o Elasticsearch e o Kibana da Apache 2.0 em janeiro de 2021 e passou a disponibilizá-los sob termos duais SSPL e Elastic License. A Amazon criou o fork OpenSearch. A Elastic adicionou a AGPLv3 como terceira opção em agosto de 2024 e, em setembro de 2024, o OpenSearch foi transferido para a Linux Foundation como OpenSearch Software Foundation.
• A HashiCorp passou o Terraform e as outras ferramentas da empresa para a Business Source License (BUSL) em agosto de 2023. A BUSL não é uma licença open source enquanto está em vigor, porque proíbe a utilização concorrente em produção. Cada release passa para uma licença open após uma data fixa; no caso do Terraform, isso acontece quatro anos depois. O OpenTofu foi criado como fork em poucas semanas e também está agora sob a Linux Foundation.

Ambos os lados têm argumentos válidos e nenhum está a agir de má-fé. Uma empresa que paga cinquenta salários enquanto uma empresa muito maior revende o seu trabalho enfrenta um problema que a boa vontade não resolve. Um utilizador que criou uma aplicação com base nos termos da Apache 2.0 e acordou sob novos termos também enfrenta um problema, e ninguém lhe perguntou antes. Repare no que aconteceu a seguir em dois desses casos. Depois de os forks se consolidarem, a Elastic e o Redis adicionaram novamente copyleft forte. O copyleft respondeu à queixa original, porque a AGPLv3 exige que um service provider publique as alterações que executa. Em agosto de 2026, os dois projetos e os dois forks continuam ativos. Esse é o resultado que as licenças foram concebidas para permitir.

Quem pode alterar uma licença

Um projeto só pode mudar de licença se uma única parte controlar os direitos de autor de todo o projeto. As empresas obtêm esse controlo de uma de duas formas. A cessão de direitos de autor transfere para a empresa a propriedade de cada contribuição. Um acordo de licença de contribuinte (CLA) mantém a propriedade consigo, mas concede à empresa direitos suficientemente amplos para alterar a licença do seu trabalho. Normalmente, um destes acordos é assinado ao clicar numa ligação que um bot publica no seu primeiro pull request.

O Linux não tem um CLA. As contribuições são feitas ao abrigo da GPLv2, com um Developer Certificate of Origin, e os direitos de autor estão distribuídos por milhares de pessoas e empresas. Ninguém pode alterar a licença do Linux, porque seria impossível recolher todas essas assinaturas. A mesma proteção aplica-se a qualquer projeto com muitos titulares independentes de direitos de autor. É uma proteção mais forte do que uma promessa, porque resulta de um facto sobre quem é proprietário de cada parte.

Por isso, a pergunta a fazer sobre o software do qual pretende depender não é se ele é open source hoje. É quem poderia alterar essa situação e se poderia fazê-lo sozinho.

O que uma fundação oferece efetivamente

Uma fundação guarda os ativos e define as regras para a tomada de decisões. A Apache Software Foundation, a Linux Foundation, a Cloud Native Computing Foundation, que faz parte dela, e a Software Freedom Conservancy desempenham versões desse papel. Uma fundação não é neutra por magia. Os membros pagam pelas suas posições, e a maioria das pessoas que trabalham a tempo inteiro num projeto de uma fundação de grande dimensão é paga por empresas membros. O que se obtém é mais limitado, mas continua a ter muito valor: a marca e o processo de lançamento não pertencem a um único fornecedor, pelo que nenhuma empresa pode tornar o projeto privado.

A marca é a parte que muitas pessoas não percebem. O código é licenciado. Um nome é uma marca, e uma marca não é abrangida pela licença do código. É sempre possível criar um fork do código. Normalmente, não é possível manter o nome. É por isso que os forks desta história se chamam Valkey, OpenSearch, OpenTofu e Forgejo.

O problema da manutenção

A infraestrutura moderna depende de projetos com um ou dois responsáveis não remunerados, e as falhas são o que torna essa realidade visível. O bug Heartbleed no OpenSSL, em 2014, afetou uma biblioteca responsável por uma grande parte do tráfego web encriptado, mantida por poucas pessoas e com recursos financeiros quase inexistentes. O Log4Shell, em dezembro de 2021, fez com que a resposta a incidentes de todo o mundo passasse por uma pequena equipa voluntária do projeto Apache Log4j.

O backdoor encontrado no XZ Utils em março de 2024 é o exemplo mais claro, porque o ataque visou o responsável pela manutenção, e não o código. Uma conta passou cerca de dois anos a fazer contribuições genuinamente úteis para uma biblioteca de compressão usada em várias distribuições Linux. Outras contas pressionaram o único responsável, já exausto, a aceitar ajuda. O novo co-responsável introduziu então um backdoor nos arquivos de release, direcionado a sistemas em que o daemon SSH (secure shell) está ligado à liblzma. Um developer encontrou-o ao investigar por que motivo os logins demoravam cerca de meio segundo mais do que o esperado. Foi uma questão de sorte, como todas as pessoas envolvidas afirmaram publicamente.

O financiamento começou a chegar: GitHub Sponsors desde 2019, Open Collective, o Sovereign Tech Fund da Alemanha desde 2022 e o projeto Alpha-Omega da OpenSSF. Esse financiamento chega de forma desigual e tende a alcançar os projetos que já são conhecidos. A regulamentação também está a avançar. O Cyber Resilience Act da União Europeia entrou em vigor em dezembro de 2024, com a maioria das suas obrigações a aplicar-se a partir de dezembro de 2027. As primeiras versões colocariam a responsabilidade dos fabricantes sobre voluntários não remunerados. Por isso, o texto final criou uma categoria menos exigente, denominada "open source software steward", após um longo trabalho de lobbying por parte de fundações e distribuições.

O que a história do open source significa para o software no seu VPS

Todas as aplicações dos nossos guias de self-hosting dependem destas decisões. O Nextcloud existe devido a um fork: em 2016, o fundador do ownCloud e grande parte da equipa abandonaram o projeto e reiniciaram-no sob a AGPLv3. Desde então, os dois produtos têm evoluído em paralelo. Esse percurso é o contexto de as alternativas ao Nextcloud que vale a pena considerar e das alternativas self-hosted ao Dropbox que competem com ambos.

O mesmo padrão existe no alojamento de repositórios Git. O próprio Gitea começou em 2016 como um fork do Gogs. No final de 2022, a marca e os domínios do projeto passaram para uma empresa. Em dezembro desse ano, a Codeberg fez um fork para criar o Forgejo. Em 2024, o Forgejo passou da licença MIT para a GPLv3 com a versão 9. Ambos são abordados em as opções de servidores Git self-hosted, e a diferença de licenças explica em grande parte a divergência contínua entre os dois. Entretanto, a maior parte do software livre é desenvolvida no GitHub, uma plataforma fechada pertencente à Microsoft. Este é um argumento antigo, com bons pontos de ambos os lados: consulte o que é realmente o GitHub.

Antes de comprometer um servidor com um projeto, vale a pena dedicar dez minutos a quatro verificações.

• Leia o ficheiro LICENSE no repositório, e não a página de marketing. As páginas continuam a usar a expressão "open source" muito depois de o ficheiro deixar de a confirmar.
• Procure um CLA ou uma cessão de direitos de autor. Se existir, um único proprietário pode alterar os termos das versões futuras.
• Descubra quem detém os direitos de autor: uma empresa, vários contribuidores ou uma fundação.
• Conte os maintainers ativos. Um projeto com apenas um representa um risco tanto para essa pessoa como para si.

Nada disto significa que deva evitar software de um único fornecedor. Muito desse software é excelente, e o facto de ser pago é frequentemente a razão pela qual continua a ser mantido. Isto indica a que está exposto. Ao decidir o que vale a pena alojar por conta própria, coloque a licença na comparação, ao lado do requisito de memória.

Pode consultar parte deste historial na máquina à sua frente. Cada pacote num sistema Debian ou Ubuntu inclui os seus próprios termos:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

O primeiro número indica quantos pacotes instalados incluem um ficheiro de direitos de autor, normalmente algumas centenas num VPS pequeno. O segundo comando apresenta o início do ficheiro correspondente ao bash, que identifica a GNU General Public License versão 3. A ausência do ficheiro significa que o pacote não foi compilado de acordo com a política Debian. Isto é raro e merece uma segunda verificação antes de confiar no pacote.

FAQ

Qual é a diferença entre software livre e código aberto?

Abrangem quase o mesmo conjunto de licenças, mas discordam sobre a razão pela qual essas licenças são importantes. "Software livre" é o termo mais antigo, criado pela Free Software Foundation em 1985, e o seu argumento é ético: um utilizador que não pode alterar o programa não controla o computador. "Código aberto" foi criado em fevereiro de 1998 para facilitar a explicação dessas mesmas licenças às empresas, e o seu argumento é prático. As licenças GPL, MIT, BSD e Apache 2.0 estão presentes nas duas listas oficiais. Os autores que pretendem referir ambos usam FOSS ou FLOSS.

Software com código disponível é o mesmo que código aberto?

Não. Código disponível significa que pode ler o código. Código aberto, segundo a Open Source Definition, também significa que a licença não pode restringir quem usa o software nem a finalidade da utilização. As licenças SSPL e Business Source License restringem a utilização comercial por concorrentes. Por isso, nenhuma das duas é código aberto segundo essa definição, embora ambas publiquem o código-fonte. Se apenas alojar o software para utilização própria, a restrição pode nunca afetá-lo. Se quiser criar um produto com base nele, leia primeiro o texto da licença com atenção.

Uma empresa pode retirar uma licença de código aberto que já concedeu?

Não relativamente ao código que já lançou. Essa versão continua sujeita à licença com que foi lançada. É precisamente por isso que forks como Valkey e OpenTofu puderam começar a partir do último commit distribuído sob uma licença permissiva. O que uma empresa pode fazer é colocar versões futuras sob novos termos. Só pode fazê-lo se controlar os direitos de autor de todo o projeto através de uma cessão de direitos ou de um acordo de licença de contribuidor. Projetos com muitos titulares independentes de direitos de autor, incluindo Linux, não podem ser relicenciados por uma única entidade.

Que licença devo procurar em software self-hosted?

Para software que executa por sua conta e que não revende, qualquer licença aprovada pela OSI, como GPL, AGPL, MIT ou Apache 2.0, oferece tudo o que precisa. A verificação mais importante é saber quem detém os direitos de autor, porque isso determina se os termos podem ser alterados posteriormente sem a sua aprovação. Um projeto detido por uma fundação ou por muitos contribuidores independentes não pode ser relicenciado contra os seus utilizadores. Um projeto de um único fornecedor com um acordo de licença de contribuidor pode. Ambos podem ser software de qualidade. Apenas um deles pode alterar as regras por sua própria iniciativa.