FSL: Uma licença para o bazaar, não para a catedral
Uma nova “Functional Source License” (FSL) para software SaaS pretende bloquear concorrentes comerciais por dois anos, prometendo depois uma mudança automática para uma licença open source permissiva. Os defensores veem isso como uma forma pragmática de financiar o desenvolvimento e limitar o “free-riding” de grandes provedores de nuvem, ao mesmo tempo em que dão aos usuários acesso ao código e uma saída de longo prazo; os críticos argumentam que ela enfraquece princípios centrais do software livre, complica contribuições e forks e embaralha a linha entre open source e modelos source-available. A discussão também traz preocupações jurídicas e de confiança sobre mudanças de licença com prazo e evidencia a tensão mais ampla entre sustentar negócios SaaS comerciais e preservar a liberdade irrestrita do software.
Escopo e natureza da FSL
- A FSL é vista como uma licença “source-available, eventualmente open”: o código pode ser usado agora com uma restrição de não concorrência e torna-se automaticamente Apache 2.0 após dois anos.
- A restrição mira principalmente ofertas SaaS concorrentes; hospedagem própria não comercial e não concorrente é permitida.
- Alguns a descrevem como o “menos pior” para SaaS: melhor do que totalmente proprietária ou BUSL, mas claramente não é FOSS durante o período de exclusividade.
Forks, “bazaar vs cathedral” e dinâmica de contribuição
- Críticos argumentam que a FSL é estruturalmente parecida com uma catedral: uma parte especial controla o uso comercial; forks significativos precisam atrasar dois anos e acompanhar o ritmo da equipe original.
- Há a preocupação de que correções de segurança e funcionalidades no fork “comunitário” estejam sempre dois anos atrasadas, tornando difícil uma competição real ou a segurança.
- Outros rebatem que forks ainda são possíveis, especialmente se o projeto principal estagnar, e observam que muitos projetos abertos já exigem CLAs ou concessões especiais de contribuição.
Preocupações legais e práticas
- Um debate questiona se relicenciamento com atraso temporal e término automático são válidos sob algumas leis da UE; outros respondem que concessões em fases temporais são comuns e que os termos são conhecidos מראש.
- Foram levantados casos extremos: o que acontece se a referência da licença futura (por exemplo, Apache) “desaparecer”; as respostas sugerem que os tribunais provavelmente manteriam a intenção e que forks existentes preservam a licença que já possuem.
- A ambiguidade sobre o que conta como “uso concorrente” e “expor APIs” deixa alguns receosos de risco jurídico.
Modelo de negócio e debate sobre “free-rider”
- Defensores enquadram a FSL como proteção contra provedores de nuvem ou revendedores que reempacotam o produto como um serviço hospedado sem financiar seu desenvolvimento.
- Críticos dizem que software não “se desgasta” como bens comuns físicos; o “free-riding” prejudicial é, na verdade, um problema de modelo de negócios, não de licença.
- Alguns argumentam que o open source, por natureza, abre mão do monopólio sobre a exploração comercial; se isso é inaceitável, o projeto deveria ser claramente proprietário.
Relação com definições de FOSS e comunicação
- Muitos enfatizam que a FSL não é Free/Open Source segundo as definições da FSF/OSI devido a restrições de campo de uso (sem competição).
- Há forte reação contra o marketing que chama o produto de “open source” ou “single-source open source”; vários veem isso como uma confusão da terminologia estabelecida.
- Representantes da Sentry reconhecem que a FSL não é Open Source até o vencimento, descrevem-na como alinhada com “ideais do open source” e dizem que parte da redação pública será revisada.
Alternativas e impacto no ecossistema
- Alguns sugerem AGPL/GPL como soluções mais simples e já estabelecidas; os contrapontos ressaltam o estigma do GPL em ambientes comerciais, a incompatibilidade com app stores e o risco percebido de ser “viral”.
- Vários comentaristas dizem que não contribuiriam sob a FSL, vendo um atraso de dois anos na liberdade como inaceitável; outros se importam principalmente com ter o código para depurar e fazer self-hosting, não com o status formal de FOSS.