Ninguém paga por FOSS, podemos forçá-los a isso

Artigo original ↗ Discussão no Hacker News ↗

Uma proposta para fazer empresas pagarem por software livre e de código aberto (FOSS), cobrando acesso a registros de pacotes, reacendeu tensões de longa data sobre como — ou se — o open source deve ser monetizado. Comentadores debatem estratégias de licenciamento, mudanças de licença do tipo “isca e troca”, vendas de dual-licensing e lojas, e se registros ou governos poderiam realisticamente canalizar dinheiro de volta aos mantenedores. Muitos argumentam que introduzir pagamentos obrigatórios distorceria incentivos, fragmentaria ecossistemas e minaria o ethos de “livre como liberdade”, enquanto outros veem algum modelo pago como necessário para sustentar infraestrutura crítica.

Percepções sobre FOSS e Dinheiro

  • Muitos argumentam: se você libera código como FOSS, você aceita implicitamente que a maioria dos usuários, especialmente empresas, não vai pagar; você não pode depois reclamar exatamente do que a licença permitia.
  • Outros rebatem: o sistema é estruturalmente injusto; infraestrutura crítica é mantida gratuitamente enquanto outros monetizam isso, então mudar os incentivos é legítimo.
  • Alguns enfatizam que escrevem FOSS para beneficiar outras pessoas, não para ganhar dinheiro, e veem a pressão posterior por monetização como uma corrupção desse espírito.

Modelos de Licenciamento e “Isca e Troca”

  • Vários comentaristas criticam projetos que começam permissivos, ganham popularidade e contribuições, e então apertam as licenças como uma forma de “enshittification” ou golpe de saída.
  • Outros respondem que não é isca e troca: versões antigas continuam sob a licença antiga; ninguém tem direito de que versões futuras continuem permissivas.
  • Debate sobre “source-available”, OpenRAIL, AGPL e licenças com restrições comerciais:
    • Pró: poderia ter evitado os problemas atuais se os projetos tivessem começado com termos do tipo “pague se a receita > US$ 5M”.
    • Contra: é difícil de auditar, convida disputas legais e não ganha tração de adoção inicial.

Registros Cobrando Empresas para Financiar Mantenedores

  • Proposta central: registros de pacotes cobram organizações e distribuem fundos para mantenedores.
  • Defensores veem isso como uma forma pragmática de monetizar a “oferta” (registros convenientes e padrão) mantendo o software em si livre.
  • Críticos levantam problemas:
    • Os próprios registros são empresas que podem reter valor.
    • Complexidade legal/fiscal enorme para encaminhar dinheiro de forma justa entre jurisdições e projetos.
    • Risco de gamificação: spam de dependências, forks triviais e incentivos perversos para PRs e forks.
    • Pode fragmentar a confiança ou afastar pessoas de contribuir.

Financiamento Alternativo e Modelos de Negócio

  • Modelos mencionados: binários pagos em lojas de aplicativos; dupla licenciamento (AGPL + comercial); contratos de suporte; “suporte estendido” para versões EOL; crowdfunding e promessas por meta; SaaS construído sobre FOSS.
  • Alguns afirmam que a maioria das tentativas de “vender o FOSS em si” fracassa; caminhos sustentáveis são suporte, serviços ou receber pagamento como funcionário/contratado.
  • Outros propõem correções mais sistêmicas: financiamento público (“Public Money, Public Code”), RBU, ou tratar pilhas de software como infraestrutura financiada por impostos.

Filosofia: “Livre” e Capitalismo

  • Esclarecimentos recorrentes: FOSS é “free as in speech”, não necessariamente “free as in beer”, embora na prática geralmente seja ambos.
  • Divergência sobre o papel do capitalismo: alguns veem a pressão por monetização como tóxica; outros insistem que aluguel e comida exigem dinheiro, então mecanismos de financiamento são necessários.
  • Preocupação de que adicionar dinheiro muda a dinâmica da comunidade e as motivações de maneiras imprevisíveis.

Debate sobre o Estilo do Artigo / Uso de LLM

  • Vários comentaristas suspeitam que o artigo foi escrito ou influenciado por LLM, citando certas formulações; outros discordam fortemente e o consideram coerente.
  • Alguns apreciam alertas iniciais sobre “AI slop”; outros acham esse tipo de reclamação mais irritante do que quaisquer questões de estilo.