Aseprite e a Mudança de Licença: Lições de 2016 Sobre Software Livre e Sustentabilidade

Em setembro de 2016, o Aseprite, um dos editores de pixel art mais populares, anunciou uma mudança importante. A partir da versão 1.1.8, o projeto deixou de ser distribuído sob a GPLv2 e passou a adotar uma licença EULA própria. O código continuou disponível para consulta e modificação, mas a redistribuição deixou de ser permitida.

Essa decisão gerou controvérsia na comunidade, especialmente entre usuários de Linux. Em termos da filosofia do sistema, o Aseprite passou a ser considerado "non-free". Isso significava que distribuições Linux não poderiam mais empacotar o software livremente. A mudança, no entanto, não foi arbitrária. Ela refletia anos de experiência do desenvolvedor com os desafios de viver de software livre.

O Aseprite começou em 2001 como um projeto pessoal distribuído gratuitamente. Apenas em 2014, com a versão 1.0.0, tornou-se um produto comercial ainda sob a GPLv2. A ideia parecia viável: continuar livre e, ao mesmo tempo, gerar receita.

Na prática, a situação mostrou-se bem mais complexa. Ao decidir viver do próprio software, que não era um serviço, mas um produto, surgia uma dificuldade clara. Todo o código estava disponível gratuitamente e isso criava uma insegurança constante sobre a sustentabilidade do projeto.

O autor destacou que o código em si não era o mais importante. O essencial estava na visão do produto, nas decisões de design e na experiência de uso. Muitos projetos de código aberto, segundo ele, careciam justamente de visão e de atenção à experiência do usuário.

O desenvolvedor também comentou sobre contribuições externas. Apesar de parecer algo positivo, integrar patches gera custos elevados. É necessário revisar o código, testar em diferentes plataformas, ajustar a experiência de uso, propor mudanças e integrar o resultado. Esse processo consome muito tempo e pode comprometer o andamento do planejamento.

Ainda assim, o código do Aseprite permaneceu disponível para estudo e contribuições, mas sem a possibilidade de redistribuição.

Outro ponto relevante foi a questão da pirataria. Na visão do autor, quem não está disposto a pagar não é cliente. Essas pessoas acabam encontrando outras formas de usar o software. Tornar o código público seria, na prática, aceitar que qualquer um poderia compilar e usar até decidir se valeria a pena pagar.

Essa abordagem mostrou uma postura pragmática. Não há como impedir totalmente o uso não autorizado, mas é possível focar em quem realmente valoriza o produto.

A relação com as distribuições Linux foi um dos fatores decisivos. O Aseprite era empacotado e disponibilizado em repositórios, o que passava a impressão de que o software era gratuito por padrão, apagando a figura do desenvolvedor.

Entre os problemas relatados estavam a falta de clareza sobre quem era o verdadeiro autor, a ausência de links de compra ou doação, a confusão entre o papel do maintainer e o do criador, e a inexistência de mecanismos de feedback direto com o desenvolvedor.

Esse cenário levantou uma questão essencial: se as distribuições não ajudam a sustentar o trabalho do autor, qual seria o incentivo para continuar oferecendo o software nessas plataformas?

Para o criador do Aseprite, o problema não estava apenas na GPL em si, mas na mentalidade que ela incentivava. A ideia de oferecer tudo ao usuário sem esperar nada em troca poderia levar ao desgaste do desenvolvedor e até à estagnação do projeto.

Na sua visão, o software deveria ser tratado como uma ferramenta que precisa de manutenção constante. Os usuários também têm responsabilidades, seja apoiando financeiramente, seja relatando bugs ou contribuindo de alguma forma.

Mesmo após a mudança de licença, o Aseprite manteve parte do código sob licenças permissivas, como a MIT. O objetivo era continuar contribuindo com a comunidade por meio de bibliotecas e ferramentas auxiliares.

A principal lição desse episódio é que a sustentabilidade precisa vir antes da ideologia. A liberdade oferecida pela GPL pode ser atraente, mas se o modelo não garante condições de vida para o autor, ele inevitavelmente buscará alternativas.

Licenças permissivas e modelos proprietários podem representar um equilíbrio melhor entre colaboração comunitária e viabilidade financeira para quem deseja viver do próprio software.

A mudança de licença do Aseprite em 2016 trouxe críticas e resistência, mas também evidenciou uma realidade incontornável: sobreviver apenas de software livre, especialmente sob a GPL, é extremamente difícil.

O caso serviu como ponto de reflexão para desenvolvedores independentes. Sem sustentabilidade financeira, não há como manter qualidade, evolução e dedicação integral a um projeto. O Aseprite mostrou que é possível continuar contribuindo com a comunidade, mas sem abrir mão da sobrevivência do próprio criador.

Referência
ASEPRITE. New source code license. 2016.
Disponível em: https://dev.aseprite.org/2016/09/01/new-source-code-license/.
Acesso em: 26 set. 2025.