Licenças de Software e impacto numa stack de tecnologia

"folhas com descrição de uma lei"

As decisões sobre quais tecnologias, frameworks e/ou plataformas que serão base do desenvolvimento de produtos e serviços muitas vezes não são racionais. Elas são fortemente influenciadas por gosto pessoal, buzzwords, etc.

Isso é evidente quando as pessoas nas funções de liderança decidem por tecnologia A ou B, muitas vezes a decisão é fortemente influenciada pelo sucesso de projetos anteriores, recomendação de outras pessoas ou parceiros comerciais. Não há nenhum problema em tomadas de decisão assim, desde que tenha claro as limitações de cada tecnologia versus as condições da equipe de adotar a tecnologia definida na decisão.

Um exemplo é quando eu estava na posição de gestor (CTO) de uma startup na área de educação. Uma das minhas responsabilidades era criar uma equipe de tecnologia para desenvolvimento de uma plataforma para a rede de escolas desta startup.

A stack para desenvolvimento seria Python, especificamente Django como backend, PostgreSQL como banco de dados e como FrontEnd um dos três mais conhecidos (ao menos por mim), Angular, React ou Vue. Como meu conhecimento desses frontends eram muito básico, eu não era capaz de decidir por qual deles usar, a decisão seria das pessoas de front contratadas.

A escolha por Python, Django (REST Framework) foi porque Python é uma linguagem de programação com uma curva de aprendizado mais baixa (não quer dizer mais fácil) comparada à outros frameworks, a popularidade da linguagem e consequentemente maior possibilidade de contratar pessoas com algum conhecimento.

Outra parte importante seria o uso de containers desde o início do projeto. As primeiras versões rodam em containers (Docker) nas VMs do IaaS contratado, isso posteriormente foi migrado para Kubernetes, a razão principal disso é gerar cada artefato contido num container, padronizando a construção do artefato e rollout dele nos ambientes de homologação e produção.

O PostgreSQL é um banco versátil para diferentes usos, os principais provedores de Cloud tem oferta de serviço gerenciado dele e os ORMs (SQLAlchemy e Django ORM) funcionam bem também. Na startup anterior, ele foi utilizado com armazenamento de uma das plataformas desenvolvidas utilizando Event Sourcing (valeu Mário Idival por implementar!).

Analisando o exemplo que citei, as decisões sobre quais tecnologias seriam utilizadas tinha até bons argumentos, não é possível afirmar que não havia algum viés. Containers como base dos artefatos gerados, PostgreSQL como banco de dados foram decisões tecnológicas baseadas em implantações de sucesso em experiências anteriores.

Reforçando, não há problema em tomar decisões assim, cabe ponderar junto com as pessoas que irão desenvolver porque utilizar aquelas tecnologias e identificar potenciais limitações de cada tecnologia não só do ponto de vista técnico, mas também na capacidade da equipe aprender lidar com elas e olhar para outras tecnologias sem estigma da obrigação de aprender “tudo de novo”.

Há outro aspecto que é pouco abordado nas decisões de quais tecnologias serão adotadas, mas com a mudança das licenças do MongoDB e ElasticSearch despertou um interesse maior sobre as licenças de software.

Observação - A análise aqui é uma opinião, não sou advogado. Não use o conteúdo abaixo como referência, consulte uma empresa especializada no assunto.

Na startup escolhemos a maior parte da nossa stack base estava com licença do tipo permissiva (BSD): PostgreSQL, Django e Django REST. Python (PSF License Agreement) e Psycopg2 (LGPL-3) são “derivadas” da GPL-2 e GPL-3. React e Next.js usam MIT como licença e a maioria das bibliotecas de dependência dos projetos desenvolvidos usavam BSD, MIT ou Apache2.

ElasticSearch foram considerado algumas vezes como parte da stack, mas se fosse iniciar no dia de hoje enquanto escrevo pensaria duas vezes em considerar:

1. O ElasticSearch não está sob uma licença Open Source

Sempre que possível é preferível (para mim) adotar tecnologias com licença considerada Open Source e com uma governança transparente. Isso possibilita um ambiente de colaboração tecnológica e econômica incrível, um bom exemplo são os projetos mapeados pela CNCF no seu Landscape tem um valor de mercado estimado em 10,65 trilhões de dólares.

A licença SSPL não é considerada Open Source pela OSI (Open Source Initiative).

2. Quebra do ecossistema e usuários são clientes a partir da 7.11

Um ecossistema robusto como criado em torno do ElasticSearch permitiu que empresas crescessem em torno como Logz, CrateDB e Aiven está sendo quebrado por conta da mudança da licença.

Um ecossistema em torno de um projeto opensource contém usuários, clientes, parceiros comerciais, coopetidores (colaboradores + competidores), voluntários, etc. Ao adotar uma licença como SSPL está eliminando do ecossistema os coopetidores e muitos usuários.

Não é só Elastic que mudou para SSPL, MongoDB foi o pioneiro nesse movimento e no ano passado foi o Graylog que também mudou.

Claro, é compressível as razões da mudança na licença, mas não é uma questão do tipo: somos bons e eles são maus.

Qual licença é a melhor então?

Sabe aquela resposta padrão de consultor? “Depende”…

Enquanto consumidor de tecnologia

Acompanhe o que os desenvolvedores (pessoas e/ou empresas) estão pensando sobre o futuro do projeto que é base da stack de onde trabalha. Mudanças assim não chegam de uma hora para outra.

Enquanto consumidor mas também desenvolvedor de tecnologia

Vale o mesmo do cenário acima mas com um ponto importante a acrescentar. Se você ou sua organização quer colaborar com algum projeto, veja como é o processo de governança deles. Os projetos incubados em fundações como CNCF ou Apache Foundation tem um modelo claro de governança.

Enquanto desenvolvedor de tecnologia

A licença do projeto deve estar relacionada ao modelo de negócio que a empresa pretende ter. Para todo tipo de licença Open Source há casos de sucesso, segue alguns exemplos:

Se quer usar na sua stack alguma projeto que está sob a licença SSPL é claro que deve usar mas considere que não é de fato, Open Source. 😉

Referências

comments powered by Disqus