Felipe Brunati (*)
É comum a ideia de que os softwares Open Source, por serem “livres”, não possuem limitações e restrições, quando usados em processos de desenvolvimento de novos sistemas e aplicativos. No entanto, essa é definitivamente uma falsa premissa, já que cada OSS (Open Source Software) possui uma licença que determina termos e condições, que devem ser seguidos para que seja permitido o seu uso no negócio.
Ao não seguir esses termos e condições, a empresa responsável pelo uso do software em questão corre sérios riscos legais, operacionais e até comerciais. Alguns OSS possuem políticas que não permitem qualquer distribuição comercial de software, que usa as suas licenças. Ou seja, quando estiver usando um OSS desse tipo, não é possível vender ou alugar quaisquer entregáveis, que se enquadrem nessas licenças.
Outra consequência indesejada de não se atentar aos termos e condições do OSS é ser obrigado a ter que compartilhar alterações de seu produto publicamente. Ao utilizar um OSS, que usa um tipo de licença copyleft como GPL, LGPL, AGPL, EPL ou MPL em seu código, o desenvolvimento do software pode ser regido pela respectiva licença do OSS e, portanto, a propriedade de seu software não será exclusiva sua.
O software deve estar em conformidade com os mesmos requisitos aplicáveis ao OSS utilizados, por exemplo, uma licença GPL. No caso de ser liberada de alguma forma uma versão modificada para o público, isso requer que seja disponibilizado o código-fonte modificado publicamente para qualquer pessoa, já que parte de suas condições é divulgar o código-fonte e garantir que as modificações sejam lançadas sob a mesma licença.
Em outros casos, uma não conformidade pode levar a empresa a ser alvo de ação judicial, estando sujeita a penalidades e restrições na venda do produto de software da organização até que a conformidade seja atendida. Legalmente, as empresas que usam OSS em seus aplicativos devem cumprir as licenças de cada componente para manter os direitos de modificar e distribuir a sua tecnologia.
E, normalmente, as multas e gastos com esse tipo de situação acabam saindo mais caras do que o custo que seria gasto para evitar este tipo de problema. Existe também a possibilidade de ter uma licença rescindida automaticamente, devido ao status de não conformidade da empresa. Uma liminar pode impedir a distribuição de um produto até que o código-fonte seja liberado. Quanto mais tarde uma dependência problemática for descoberta, mais caro será para resolvê-la no processo de desenvolvimento do software.
Além de todos os riscos e possíveis prejuízos já listados acima, existem também consequências indiretas, negativas, que podem surgir a partir de uma situação de não conformidade, como um impacto negativo no mercado, perda de reputação e credibilidade junto ao público, desperdício de tempo e recursos humanos que poderiam ser evitados.
Nesse sentido, para as empresas que estão em processo de abertura de capital, há um risco ainda maior. A falta de auditoria e de um plano para resolver as questões da licença de código aberto não apenas retardará um potencial processo de preparação de IPO, mas também poderá diminuir o valor da IPO, tanto no curto prazo quanto em qualquer momento do ciclo de vida de uma empresa pública.
A Checkmarx realizou pesquisas sobre os fatores de risco legais em pacotes de código aberto. O objetivo foi verificar um grande número de dependências de código aberto, determinar quantas delas continham um risco legal e qual a sua gravidade para priorizá-lo e remediá-lo.
Para tornar esta pesquisa autêntica, a Checkmarx fez uso de pacotes bem conservados, bem como pacotes mal conservados (50:50), que faziam parte de projetos do GitHub OS, os quais foram filtrados usando o projeto de scorecard de ferramenta de código aberto (por OSSF). Buscou-se por métricas interessantes, usando uma ferramenta SCA automatizada. Os resultados foram os seguintes:
• 5,3% dos pacotes de código aberto possuem uma licença que contém “risco legal”. De acordo com o relatório GitHub State of the Octoverse, “projetos de código aberto têm uma média de 203 dependências de pacotes” – o que significa que, em média, cada projeto que um desenvolvedor usa contém 10 pacotes, que usam licenças com risco legal.
• A grande maioria desses riscos legais é considerada de alto risco/risco médio, o que significa que eles precisam ser abordados para tornar o seu produto seguro e compatível.
. Como gerenciar os riscos de licenças de código aberto – Toda organização precisa ter certeza de que está gerenciando adequadamente os seus riscos de licenças de código aberto. Mas sabemos que gerenciar as suas dependências de código aberto (e suas dependências transitivas), e seus riscos pode ser um desafio difícil e tedioso.
A grande quantidade de dependências de código aberto que uma organização usa, a dificuldade em coletar cada licença que está em uso e em categorizar essas licenças de acordo com os riscos, além da necessidade de priorizar esses riscos e abordar os problemas de conformidade com precisão e agilidade, muitas vezes podem se transformar em um desafio de proporções indesejadas à companhia.
Hoje há soluções que ajudam a gerenciar o risco de licença de código aberto, permitindo que a organização resolva os problemas de licença anteriormente no SDLC, reduzindo os processos manuais e digitalizando o seu código, e identificando o tipo de licença e os riscos que ela contém, para uma construção segura de software compatível com mais rapidez e em escala.
(*) – É Country Manager no Brasil da Checkmarx (https://checkmarx.com/).
