Comunidades open source são fascinantes porque, embora projetos do tipo possam ser sustentados por interesses financeiros, essa não é a regra. Outras motivações incluem senso de comunidade, propósitos sociais, ganho de experiência e vontade de não depender de soluções proprietárias. Mas também há quem veja a natureza do código aberto como um “liberou geral”.

“Liberou geral” no sentido de que “posso fazer o que eu quiser com isso” ou “acho que não vou ter problemas se eu usar esse software assim”. Mas há regras a serem seguidas no universo do código aberto. Se elas puderem ser combinadas com uma dose de bom-senso, melhor. Do contrário, as consequências poderão ir além de um mero aborrecimento.

Talvez eu esteja dizendo o óbvio. Mas, às vezes, o óbvio precisa ser dito. Três acontecimentos relativamente recentes abordados aqui no Tecnoblog exemplificam quão problemática pode ser a inobservância das condições de projetos de código aberto ou de princípios relacionados. Daremos uma olhada em cada um deles no melhor estilo “o que podemos aprender com isso”.

Caso 1: o falso Notepad++ para macOS

O Notepad++ é um editor de texto e código lançado em 2003 pelo desenvolvedor Don Ho, que o mantém até hoje. Trata-se de uma ferramenta até que bem conhecida, afinal, é leve, permite edições em várias linguagens de programação, tem código-fonte aberto e não custa nada para o usuário.

Contudo, o Notepad++ só tem versões para Windows. É por isso que alguns usuários ficaram animados com o lançamento de uma versão da ferramenta para macOS, em abril deste ano.

O repositório do então novo projeto tinha “Notepad++” como nome oficial, carregava o logotipo do software e o nome de Don Ho aparecia entre os responsáveis. Mas logo ficou claro que, na verdade, Ho não havia lançado o Notepad++ para Mac, tampouco dado aval para outra pessoa realizar esse trabalho em seu nome.

Alertado pela comunidade, Don Ho adotou uma série de medidas para resolver o problema, como solicitar que Andrey Letov, o verdadeiro autor, mudasse o nome e o logotipo do projeto.

Letov resistiu. Inicialmente, ele argumentou que queria apenas oferecer uma versão do Notepad++ para usuários de Mac e que esperava que Ho desse um sinal verde para isso.

Mas, pressionado por Ho e pela própria comunidade, Letov acabou concordando em promover mudanças: o Notepad++ para Mac foi renomeado para Nextpad++, recebeu domínio e logotipo próprios, e menções que davam a entender que Don Ho participava do projeto foram eliminadas. Recentemente, o editor ganhou uma versão para Linux.

Mas, se o Notepad++ é aberto, a reação não foi exagerada?

Há quem tenha esse entendimento, mas não foi o caso. O Notepad++ está disponível sob uma licença GPL 3.0, que permite uso gratuito, acesso ao código-fonte e criação de projetos derivados (forks). Porém, essa licença não transfere ao usuário os direitos sobre marcas registradas utilizadas no projeto.

Aqui está o maior erro de Andrey Letov: ele não poderia presumir que a licença GPL também lhe dava autorização para utilizar o nome e o símbolo do Notepad++ como marca para seu projeto. Para completar, Letov associou o nome de Don Ho ao novo software sem contatar o desenvolvedor sobre isso.

Mas Ho não poderia ter aceitado o convite, ainda que tardio, para apoiar o projeto? Poderia. Mas ele deu razões convincentes para a recusa:

(…) Não posso me responsabilizar pela manutenção a longo prazo de uma versão adaptada ou de um fork que não controlo. Quaisquer problemas críticos, travamentos ou vulnerabilidades de segurança nesse projeto externo poderiam prejudicar a reputação do próprio Notepad++.

Don Ho

Caso 2: a suíte de escritório europeia

Eis um caso em que o lado “errado” não é o que a gente conclui na primeira olhada. O Euro-Office foi anunciado em março de 2026 e introduzido em junho como um pacote de escritório aberto e capaz de contribuir para a soberania digital da União Europeia.

O projeto foi baseado em uma solução aberta que já existe: o OnlyOffice, e isso nunca foi um segredo. Mesmo assim, os responsáveis pelo Euro-Office foram acusados de violar propriedade intelectual e termos de licenciamento.

A base da acusação reside no fato de o OnlyOffice ter cláusulas adicionais à licença do projeto (AGPL-3.0) que determinam a preservação de sua identidade visual e de atribuições de autoria em softwares derivados. O Euro-Office, porém, removeu logotipo e outras referências ao OnlyOffice de suas interfaces.

Ficou parecendo que os responsáveis pelo Euro-Office agiram de má-fé. Mas a contra-argumentação foi coerente: a Nextcloud, uma das organizações que conduzem o projeto, declarou que a Seção 7 da licença AGPL-3.0 prevê que restrições adicionais que causem empecilhos para o uso ou distribuição do código sejam removidas.

Neste caso, o conflito está na obrigação do Euro-Office de exibir uma marca cujos direitos pertencem a terceiros. No entendimento da Nextcloud, essa situação colocaria o Euro-Office em conflito com a AGPL-3.0, razão pela qual essa cláusula pode ser removida conforme o regimento da licença, como forma de a irregularidade ser mitigada.

Quem está com a razão? Bom, não há, aqui, uma decisão judicial ou algo do tipo que encerre definitivamente a discussão.

Mas Bradley M. Kühn, um dos responsáveis pela AGPL, classificou a postura da Ascensio (organização que controla o OnlyOffice) como “a restrição adicional mais ardilosa que já vi”. Isso porque, se uma cláusula extra do projeto prevê que o logotipo original seja mantido, uma segunda cláusula impede o uso dessa marca por terceiros, uma verdadeira contradição.

Até a Free Software Foundation (FSF) se manifestou a favor do Euro-Office:

Esta obrigação de ‘manter o logotipo original do produto’ não está incluída na Sec. 7(b) da (A)GPLv3 (…), sendo, portanto, considerada uma restrição adicional. A (A)GPLv3 deixa claro que permite a todos os licenciados remover quaisquer termos adicionais que sejam “restrições adicionais” nos termos da (A)GPLv3.

Krzysztof Siewicz, gerente de licenciamento e conformidade da FSF

O Euro-Office está envolto em outras polêmicas (como ter sido apontado como um “aliado” da Microsoft pelo time do LibreOffice), mas pelo menos este caso parece caminhar para uma solução: a Ascensio propôs exigir que o OnlyOffice seja citado apenas em áreas apropriadas do código-fonte e em telas de créditos, que é a abordagem padrão de projetos open source.

Caso 3: o conflito que ameaçou uma distribuição Linux

Até projetos pequenos precisam ter salvaguardas. O caso do OpenMandriva é um bom exemplo disso. Criado em 2012 após o fim do Mandriva Linux, a distribuição quase teve a sua continuidade comprometida devido a um conflito entre colaboradores.

Davide Beatrici, que é conhecido por manter o aplicativo de mensagens por voz Mumble, ofereceu uma instância privada na OneDev para hospedar repositórios da distribuição Linux quando se juntou à equipe do OpenMandriva.

Se de um lado essa solução eliminaria eventuais custos com hospedagens no GitHub ou oferecia redundância, por outro, deixaria uma infraestrutura importante nas mãos de uma única pessoa. Apesar de alguns membros terem manifestado essa preocupação, a proposta foi aceita.

Tudo ia bem, até que outro colaborador que ingressou no projeto junto com Beatrici passou a apresentar comportamento agressivo com outros integrantes, segundo o mantenedor “AngryPenguin”. Como consequência, essa pessoa foi banida de um dos chats principais do projeto pelo próprio AngryPenguin (mas permaneceu fazendo parte do OpenMandriva).

Contrariado com essa decisão, Beatrici teria decidido deixar a iniciativa. Diante disso, os mantenedores da distribuição resolveram, então, desvincular os repositórios espelhados na instância da OneDev.

Beatrici ficou ainda mais contrariado e, por isso, teria usado seus privilégios de acesso à instância para apagar determinados repositórios e publicar um pacote vazio “que tornou obsoletos todos os pacotes do Gnome e do Cosmic”, relatou AngryPenguin.

Ao The Register, Davide Beatrici admitiu que apagou repositórios e tornou pacotes obsoletos deliberadamente, mas negou ter tentado sabotar o projeto. Seu objetivo foi o de protestar após os mantenedores terem removido arquivos de configuração do OneDev de vários repositórios sem consultá-lo, declarou.

Dias depois do primeiro comunicado sobre o assunto, a OpenMandriva informou que os repositórios apagados haviam sido restaurados e que o pacote problemático foi apagado. Com isso, o projeto voltou a ter repositórios no GitHub, sem depender de contas particulares.

Backups mantidos por outros colaboradores foram essenciais para o retorno à normalidade. Sem eles, o transtorno teria sido muito maior.

Os “recados” que esses episódios nos deixam

Eu não sou o tipo de pessoa que acredita que devemos extrair aprendizados de tudo o que nos acontece. Mas é inegável que os casos abordados aqui deixam algumas lições valiosas, que reforçam que código aberto é assunto sério. Em resumo:

• caso 1 (Notepad++ x Nextpad++): permissões sobre código não devem ser confundidas com permissões sobre marcas; usualmente, licenças abertas permitem consulta, modificação ou reuso do código, mas não dão direito automático ao uso de nomes e identidades visuais, muito menos permitem associações de autoria sem autorização prévia;





• caso 2 (Euro-Office x OnlyOffice): é necessário ter cuidado para evitar que licenças abertas como a AGPL-3.0 sejam usadas para impor restrições comerciais que se passam por exigências legais; se isso ocorrer, a própria licença pode ser acionada para derrubar amarras que se mostrarem abusivas ou incoerentes;





• caso 3 (OpenMandriva): esforços altruístas não substituem a necessidade de um projeto seguir boas práticas de gerenciamento e segurança, mesmo que isso contrarie colaboradores; convém estabelecer políticas rígidas de privilégios, priorizar infraestruturas técnicas neutras e deixar claro que anseios pessoais não devem sobrepor os valores comunitários do projeto.

O recado final é este: o open source abre portas para que softwares sejam estudados, compartilhados e derivados a partir de projetos originais, desde que as condições de cada licença sejam observadas. Do contrário, correremos o risco de cair no velho e perigoso chavão de confundir liberdade com libertinagem.

Os limites do open source: por que código aberto não é terra sem lei