Rug pull, forks e o feudalismo do open source

• Um panorama de como as dinâmicas de poder no ecossistema open source funcionam entre empresas, desenvolvedores e usuários, e do impacto das táticas de rug pull (relicenciamento) e forks que chacoalham esse equilíbrio
• Enquanto grandes provedores de nuvem exercem enorme influência, projetos centrados em uma única empresa podem relicenciar para redistribuir poder, e forks surgem como resposta
• Na análise de casos, Elasticsearch→OpenSearch, Terraform→OpenTofu, Redis→Valkey e Puppet→OpenVox mostram diferentes padrões de reorganização da comunidade e migração de contribuidores
• Adoção de CLA, domínio por uma única empresa e momento da transferência para uma fundação são apresentados como sinais de risco de rug pull, enquanto governança neutra e ampliação da camada de contribuições multi-institucionais são recomendadas como estratégia de resposta
• Em conclusão, o relicenciamento pode servir como instrumento para conter o poder da nuvem, mas também enfraquece os direitos dos contribuidores, enquanto a possibilidade de fork atua como freio nas decisões empresariais

---

Estrutura de poder no open source, rug pulls e forks

• No ecossistema de software open source, grandes empresas, PMEs, contribuidores e usuários exercem poder para influenciar tanto a direção do software quanto a estrutura de receitas
• Em especial, os grandes provedores de nuvem passaram a deter um poder considerável, tendendo a ficar em vantagem sobre empresas menores e comunidades
• Nesse contexto, a empresa desenvolvedora ou dona do projeto pode mudar a licença do software (rug pull) ou, em resposta, a comunidade ou outra empresa pode realizar um fork, causando deslocamentos de poder

Visão geral das dinâmicas de poder e das táticas

• No mundo open source, os grandes provedores de nuvem exercem o poder mais forte de canal e distribuição, criando uma estrutura que explora pequenas empresas, contribuidores e usuários
  • Como no feudalismo, em que o controle da terra definia o poder, provedores de nuvem transformam software open source em serviço enquanto evitam contribuir
  • Pequenas empresas fazem a maior parte do trabalho de desenvolvimento, mas ficam em posição desfavorável diante do uso gratuito pelos provedores de nuvem
• Pela tática de rug pull, pequenas empresas relicenciam o software para enfrentar os provedores de nuvem, mas isso tende a causar ainda mais danos a contribuidores e usuários
  • Quando provedores de nuvem transformam um projeto em serviço sem contribuir, o poder das pequenas empresas enfraquece
  • O relicenciamento prejudica usuários, mas é possível reequilibrar o poder por meio de forks
• Em projetos conduzidos por uma única empresa, o risco de rug pull é alto, o que exige avaliar a reputação da empresa, embora isso possa se tornar inútil em casos de aquisição ou falência
  • Pressão de investidores pode levar ao relicenciamento para aumentar receita, especialmente ao competir com provedores de nuvem
  • Ao adotar uma licença mais restritiva, tenta-se dificultar a monetização por terceiros e deslocar o equilíbrio de poder
• A criação de forks após um rug pull funciona como uma forma insurgente de ação coletiva para recuperar poder, mas há alto risco de fracasso por falta de pessoas e recursos
  • Grandes empresas ou provedores de nuvem podem apoiar forks com seus recursos, mas forks populares nem sempre têm sucesso
  • Há casos em que não houve fork, como MongoDB e Sentry; já após a aquisição da Puppet pela Perforce, o fechamento do desenvolvimento levou ao fork OpenVox

Comparação dos principais casos

Dawn Foster analisa, com dados, vários casos de rug pull, fork e seus impactos posteriores. (Parte dos resultados foi divulgada em um dataset de notebook Jupyter)

• Elasticsearch → OpenSearch
  • Em 2021, após o relicenciamento para SSPL pela Elastic, a AWS organizou o fork OpenSearch
  • Na Elastic, a proporção de contribuidores internos pouco mudou antes e depois do fork; no OpenSearch, o padrão continua sendo de contribuições lideradas pela Amazon
  • A análise aponta que, mesmo após a transferência para a Linux Foundation em 2024, não se observou explosão de contribuições externas
• Terraform → OpenTofu
  • Em 2023, logo após a mudança para BSL pela HashiCorp, o OpenTofu foi lançado sob a Linux Foundation
  • O Terraform manteve contribuições centradas na empresa, mas o OpenTofu recebeu rapidamente novos contribuidores de várias empresas
  • Este caso sugere que fork liderado por usuários + fundação neutra desde o início favoreceu a formação de uma comunidade ativa
• Redis → Valkey
  • Em 2024, logo após a mudança para SSPL do Redis, muitos dos contribuidores externos existentes migraram para o Valkey
  • O Redis era um caso excepcional por ter alta proporção de contribuições externas antes do fork; depois, caiu bruscamente para zero contribuições externas, enquanto o Valkey nasceu como uma comunidade formada por várias empresas
• Puppet → OpenVox
  • Após a aquisição pela Perforce (2022), houve fechamento do desenvolvimento e dos releases e redução na frequência de lançamentos; em resposta, a comunidade impulsionou o fork OpenVox

Observações de dados e métricas

• Depois de um rug pull, é comum observar forte alta no número de forks no GitHub, interpretada como um sinal proxy de movimentação para avaliar um hard fork
  • No longo prazo, a tendência é que original e fork avancem em paralelo, mas a análise aponta que o original relicenciado tende a perder uso
• Lançar um projeto já sob o guarda-chuva de uma fundação favorece a atração de contribuições no início, mas uma transferência posterior pode ter efeito limitado
  • O caso do OpenSearch sugere que apenas a transferência não garante um salto nas contribuições externas

Sinais de risco e diretrizes

• O uso de CLA (Contributor License Agreement) é um sinal de concentração de poder de relicenciamento nas empresas, ampliando o desequilíbrio de poder
  • Projetos baseados em DCO (Developers Certificate of Origin) tendem a ter menor risco de rug pull
• É necessário avaliar a governança; domínio por uma única empresa e concentração de liderança são fatores de risco
  • Projetos com fundação neutra, liderança multi-institucional e base de contribuições externas têm vantagem em termos de sustentabilidade
• A amplitude e a profundidade da base de contribuidores também são critérios centrais de avaliação
  • Empresas precisam fortalecer ao mesmo tempo influência e sustentabilidade dos projetos dos quais dependem, destacando contribuidores diretamente para eles
  • As métricas e guias práticos do CHAOSS podem ser usados para diagnosticar e melhorar a saúde dos projetos

Recomendações para comunidade e governança

• Incentivar a adoção de uma estrutura de governança neutra e ampliar os contribuidores externos são meios concretos de conter rug pulls
  • A própria possibilidade de fork eleva o custo de decisão de um relicenciamento e funciona como mecanismo de dissuasão
• Em resposta à pergunta de Hazel Weakly sobre salvaguardas, a palestrante citou os casos de sucesso de Valkey e OpenTofu como exemplos reais que levaram empresas a reconsiderar relicenciamentos
  • Dirk Hohndel enfatizou que atrair mais contribuidores externos aumenta o risco de rug pull e, portanto, também o risco gerencial dessa decisão

Conclusão

• À medida que cresce a influência das grandes empresas de nuvem, o ecossistema open source vem assumindo uma estrutura cada vez mais feudal
• A mudança de licença limita o poder das empresas de nuvem, mas no processo gera o efeito colateral de reduzir os direitos dos contribuidores da comunidade
• Ainda assim, contribuidores e usuários contam com o fork como meio de reação, o que diferencia o open source do feudalismo histórico
• A possibilidade real de fork influencia decisões futuras das empresas e, de fato, casos de sucesso como Valkey e OpenTofu já levaram algumas empresas a abandonar planos de rug pull
• Em última instância, a neutralidade da governança do projeto e a ativação de contribuidores externos são a chave para prevenir rug pulls e manter um ecossistema saudável

Referência

• Slides da apresentação: Power Dynamics, Rug Pulls & Other Impact on Sustainability

[ndrgrd]

Como fazer um fork ainda não é algo fácil no momento, seria bom se houvesse entre as organizações relacionadas a open source algum lugar que ajudasse com isso.

[GN⁺]

Comentários do Hacker News

• Vejo que projetos que usam CLA (Contributor License Agreement) sofrem mais frequentemente com rug pull (quando o esforço dos contribuidores é apropriado privadamente por poucos), enquanto projetos que usam DCO (Developers Certificate of Origin) tendem a ter menos desse desequilíbrio. Ao assinar um CLA, você concede ao projeto o direito de relicenciar o código da sua contribuição. Ou seja, mesmo que você contribua com código GPL para um projeto GPL, a licença pode ser alterada. Se a licença já for permissiva, o CLA não tem grande impacto, mas em caso de copyleft (ex.: GPL), isso se torna injusto porque só quem recolheu as assinaturas do CLA pode ter posse exclusiva. Para evitar rug pull, o ideal é usar licença copyleft e evitar assinar CLA. Em licenças permissivas, é preciso entender que o rug pull faz "parte do jogo"
  • Projetos GNU também exigem CLA, mas imagino que não o façam com a intenção de dar um rug pull
  • Quero deixar claro que assinar um CLA não significa necessariamente conceder todos os direitos de relicenciamento; isso varia de CLA para CLA. Por exemplo, segundo a cláusula do CLA da Canonical(link), minha contribuição continua sendo oferecida também sob a licença existente. É importante ler e entender o CLA. A maioria dos CLAs mantém o copyright com o contribuidor, então você continua com o direito de fazer o que quiser com a sua contribuição. O problema fundamental é que a confiança no dono do projeto pode ser quebrada. O CLA dá controle ao proprietário e aumenta o risco de rug pull. Para reagir a um rug pull, na prática é preciso fazer um fork e colaborar diretamente nele para obter benefícios. Quando uma licença copyleft vem acompanhada de CLA (ex.: AGPL + CLA), isso pode ser ainda mais nocivo do que licença permissiva + CLA. A AGPL obriga a divulgar o código-fonte até em distribuição como serviço, mas com CLA o dono pode operar um serviço fechado sem publicar as melhorias. Casos reais como Incus e LXD mostram que a combinação de licença e CLA pode causar divisão na comunidade e restringir o compartilhamento de código(relato detalhado)
  • Considero que esse fenômeno de rug pull não existe em open source. Uma cópia GPL existe para sempre
  • Licenças permissivas de fato aumentam a chance de rug pull, mas vale apontar que um CLA nem sempre concede todos os direitos
  • Acho pouco saudável tratar o "rug pull" em open source com um purismo excessivamente ideológico. Projetos precisam ser sustentáveis. Num cenário em que grandes provedores de nuvem monopolizam a infraestrutura, parece melhor que pequenos desenvolvedores gastem energia mitigando o monopólio das big techs do que entrando em disputas em projetos open source ou baseados em CLA
• Contribuidores e mantenedores muitas vezes têm ainda menos poder do que pequenas empresas. Mesmo assim, com uma licença liberal, se você estiver insatisfeito, pode fazer um fork e seguir outro caminho. O caso do Valkey mostra como a dinâmica de licenciamento com o Redis tem sido interessante. Sinto que, no geral, a comunidade de desenvolvedores hoje está acomodada demais aos serviços em nuvem e tem menos disposição do que antes para fazer fork ou reimplementar coisas como sistemas operacionais, compiladores e bancos de dados. Também se ignora com frequência que empresas de nuvem como a AWS aumentaram a visibilidade de vários projetos ao oferecê-los como serviço (ex.: a popularidade do ElasticSearch depois da oferta da AWS). A nuvem também contribui para kernel, gcc, jdk etc., o que beneficia indiretamente empresas menores. Em vez de culpar automaticamente as grandes clouds, talvez valha repensar o próprio modelo de negócios. Se tudo tivesse começado como fechado, ninguém teria se importado
• Se você não receber o software como binário e fizer o build diretamente do código-fonte, sua capacidade de reação a eventos como rug pull aumenta. Quem instala por binários/imagens do fornecedor tem mais dificuldade para migrar para um fork, mas redirecionar a infraestrutura de build para uma nova fonte é relativamente simples. Como você também pode aplicar suas próprias correções e recursos, a dependência de manutenção diminui
  • É exatamente por isso que gosto do Guix. O build a partir do código-fonte é o padrão, e pacotes binários também são oferecidos via cache. Se o binário não existir, ele compila o código-fonte localmente de forma reproduzível. Até versões com patch podem ser instaladas facilmente com o mesmo gerenciador de pacotes, sem precisar de uma infraestrutura de build separada. Em ambientes de implantação em larga escala, faz sentido ter um servidor de build
  • Não sei por que há votos negativos, mas concordo. Fazer build do código-fonte geralmente não é tão difícil (sqlite é um bom exemplo)
  • Na prática, isso também depende das restrições de cada licença de software. Há softwares comerciais que fornecem o código-fonte, mas cuja licença não permite modificá-lo livremente. Por exemplo, produtos comerciais baseados em linguagens de script, ou casos de consultoria empresarial em que o código-fonte é entregue ao cliente, mas o direito de compilar exige pagamento adicional
• Depois do rug pull do Elasticsearch, o fato de a Amazon ter passado a contribuir diretamente para o fork open source (OpenSearch) pode ser visto como um resultado parcialmente positivo, mesmo que não fosse a intenção original. Ainda assim, é importante discutir como o desequilíbrio entre contribuidores e beneficiários em grandes empresas também gera instabilidade nos projetos
  • Não há problema em usar software em conformidade com a licença; na verdade, é contraditório quando desenvolvedores ou startups usam licenças permissivas mirando apenas difusão e crescimento, e só passam a ver problema quando as grandes clouds entram no jogo. Não dá para ter os dois benefícios ao mesmo tempo
  • O que a Elastic queria era aumentar a receita com licenciamento, mas muitos usuários migraram para o fork, o que acabou corroendo a confiança na Elastic. A concorrência entre OpenSearch e ElasticSearch pode até ser positiva para o ecossistema, mas os dois já perderam compatibilidade e a posição da Elastic enfraqueceu
  • Licenças copyleft como AGPL/GPL exigem contribuição de código à força, então conseguem criar um ciclo de retorno mesmo sem licença proprietária
• Em projetos open source, um rug pull não se torna fácil apenas por trocar a licença. O problema mais profundo é a realidade de que não vivemos num ambiente utópico em que qualquer pessoa possa trabalhar de graça e ainda assim manter boa qualidade de vida. Sem mantenedores, a meia-vida de um projeto tende a ser curta e, sem patrocínio, a migração para licenças mais fechadas vai se acelerar
  • Isso me lembra o caso da comunidade Bukkit com Mojang/Microsoft. Durante o processo de contratação de desenvolvedores, o projeto foi comprado discretamente e voluntários trabalharam por anos sem remuneração; no fim, um deles usou a DMCA para derrubar o projeto. Mais detalhes: blog
  • No fim, é uma questão de incentivos. Mesmo que você crie software open source por conta própria, provedores de nuvem podem pegá-lo facilmente e monetizá-lo. Eu entendo que esse é justamente o significado da estrutura de licenças FOSS (Fully Open Source Software), mas sinto que a sociedade se acostumou demais ao trabalho gratuito. Por isso, acho que novos modelos como SSPL (Source-available licensing) vão parecer cada vez mais atraentes. A diferença de uma cláusula faz AGPL ser FOSS e SSPL não ser, o que me parece uma confusão terminológica
• Entendo a frustração de usuários diante de um rug pull, mas empresas que de fato lideram o desenvolvimento e a manutenção de um projeto também têm limites financeiros e acabam com poucas opções. Sem um modelo de receita, a mudança de licença pode se tornar inevitável. Como alternativas, venho pensando em crowdfunding, reduzir a carga de trabalho, vender merchandising, ou anunciar que o projeto se tornará aberto se não houver financiamento adicional. Texto relacionado
  • A essência da insatisfação é que o software foi publicado como OSS, conquistou usuários, e depois a licença foi repentinamente fechada. Se nunca tivesse sido OSS desde o começo, não haveria esse sentimento de traição; o problema é começar como OSS para atrair usuários e depois mudar
  • Mongo, Elastic, Redis e Hashicorp não estavam exatamente em grave dificuldade financeira no momento do rug pull. No caso da Hashicorp, isso pode até ter sido uma estratégia para aumentar valor numa aquisição
• Recentemente, vêm aumentando os casos em que se criam conselhos de governança e modelos operacionais mais regulados para levar técnicos a sair por vontade própria, ao mesmo tempo em que opiniões divergentes são reprimidas e permissões no projeto são revogadas. Na prática, um clima orwelliano em nome da "segurança" vem sendo introduzido nas comunidades
• Quase todo usuário de open source é um free rider. Usamos livremente projetos sem contribuir em nada. Open source pode ser visto como um presente sem contrapartida, ou como uma cultura de consultar o dever de casa dos outros. Se você quer contribuir para o mundo, faça isso de bom grado, mas sem esperar qualquer recompensa. Chamar mudança de licença de rug pull também é uma visão enviesada. De qualquer forma, nós já recebemos o código; é triste quando a direção muda, mas nada no mundo dura para sempre
  • A afirmação "a maioria de nós só usa sem devolver nada" não é totalmente verdadeira. Muitos projetos receberam contribuições amplas em código, testes, documentação, marketing e evangelização. Esses projetos não surgiram como artefatos silenciosos colocados por acaso no GitHub; empresas investiram muito dinheiro e contrataram ativamente evangelistas de desenvolvedores para divulgar as vantagens técnicas e de licenciamento e ampliar a base de usuários. Nesse contexto, receber código e contribuições em grande escala e depois mudar repentinamente a licença, especialmente quando outros projetos FOSS dependem disso, é justamente o que leva à crítica de rug pull. Se fosse um projeto colocado no GitHub sem marketing e adotado organicamente, provavelmente não seria alvo dessa controvérsia. Mas quase nunca vejo casos assim
  • Não precisa ser necessariamente assim. Empresas ou organizações com recursos podem aumentar a sustentabilidade dos projetos open source dos quais dependem com contribuições financeiras e técnicas. Dá para criar um Open Source Program Office, analisar todo o software usado e suas dependências, dedicar tempo de contribuidores e apoio financeiro, e incentivar essa cultura também no setor
• Na empresa em que trabalho hoje, a questão do rug pull também tem deixado a liderança confusa. Sempre insistimos em contratos de suporte para os sistemas, mas situações parecidas continuam se repetindo com Chef, CentOS, VMWare, Broadcom etc. Mesmo quando a intenção era pagar, os serviços básicos de manutenção chegam a milhares ou dezenas de milhares de dólares por ano, e ainda assim a confiança não existe. Nesse cenário, parece melhor apoiar uma fundação ou contratar diretamente mantenedores de OSS de forma recorrente. Antes eu era cético com esse tipo de proposta, mas a adesão vem crescendo. Pessoalmente, eu preferiria contratar desenvolvedores de Proxmox ou qemu a pagar a VMWare
  • Acho que é a ideia certa. É importante revisar todo o software utilizado e suas dependências, garantir sustentabilidade com contribuição de tempo de desenvolvimento e recursos financeiros, e espalhar essa postura pelo setor
  • Curiosamente, as empresas citadas chegaram a criar Open Source Program Offices para atuar de forma mais voltada à comunidade, mas quando a organização cresce demais, parece inevitável surgir uma duplicidade entre comunidade e interesse corporativo
• Fazer um fork não é simples; para dar certo, é preciso gente e recursos. Open source, no fim, só funciona quando há muitos contribuidores. Se um fork morre, isso significa que havia free riders demais naquele projeto. O maior problema do rug pull, na verdade, me parece ser propaganda enganosa. Você atrai clientes com o discurso de open source e, quando isso deixa de te favorecer, quebra essa promessa, o que é moralmente problemático. Já o fim das contribuições em si não me preocupa. Ninguém é obrigado a permanecer num projeto para sempre, então é natural que indivíduos ou empresas também interrompam sua participação