Por que tentar obstruir a leitura do seu código é uma má idéia

Nelson Ferraz
Publicado em 05/01/2007

r4 - 05 Jan 2007 - NelsonFerraz

Por que tentar obstruir a leitura do seu código é uma má idéia

Frequentemente alguém pergunta como ofuscar o código de um sistema, como criptografá-lo ou qualquer coisa parecida na intenção de, supostamente, proteger-se de alguém "roubar" o seu código. Vou tentar colocar aqui algumas boas razões para mostrar por que isso é uma má idéia.

Motivações para tentar esconder o código

Esconder o código não é uma atividade simples e tem custos associados, podendo gerar novos bugs, dificultar o debug de um código de produção etc. No entanto, se alguém ainda assim tenta esconder o código é por que existe uma boa motivação. Vamos tentar entendê-las.

* Quero evitar alguém de sair vendendo o meu software
* Tenho um diferencial que ninguém pode conhecer

Vamos então agora entender os problemas dessas motivações

Se alguém quiser roubar, provavelmente vai conseguir

É preciso deixar bem claro que o máximo que você vai conseguir fazer é dificultar a leitura do código, quando se trata de uma linguagem interpretada, o conjunto de comandos que o interpretador vai receber é de um nível consideravelmente mais alto que o conjunto de instruções em uma linguagem compilada para código nativo. Linguagens de alto nível possuem mecanismos de introspecção, e implementam um nível de abstração que facilmente pode ser manipulado para obter mais informações sobre a execução do processo.

Além do mais, na maior parte dos casos o acesso ao código fonte não é um pré-requisito para que alguém que esteja interessado em tirar vantagem do seu software sem a sua autorização, aliás, a maioria dos administradores de sistema jamais chegam a manipular o código fonte dos sistemas que administram. Dessa forma, não é o fato do código-fonte estar criptografado que vai impedir que ele pegue esse sistema e utilize em outro lugar. Lembre-se, se você não tem o controle completo sobre a máquina que roda o aplicativo, você não tem controle nenhum sobre o sofware.

Imaginando que você implemente um mecanismo de autenticação baseado em chaves públicas e chaves privadas para garantir que todos as versões do software vão estar sob o seu controle, ainda assim, só é necessário alterar o local onde está guardada a informação de qual é a chave do servidor e a informação de onde consultar a autenticação. Acredite, se é possível fazer isso em uma aplicação compilada para código nativo, é ainda mais simples fazer isso em uma aplicação que roda em um interpretador de alto nível. E isso não se aplica apenas a Perl, mas também a Python, Java, C# etc.

Obstruir o código só adiciona novas camadas de problemas

A melhor forma de te proteger é um bom contrato

Considerando o que disse acima, é preciso antes de cima, ter clareza que uma relação comercial tem que ser, em primeiro lugar, uma relação de confiança, se não entre as partes pelo menos entre cada uma das partes e o contrato que ambas assinaram. Da mesma forma que o seu cliente vai querer uma cláusula de confidencialidade sobre as informações que você vai ter acesso sobre a empresa dele durante o período de prestação de serviço, você pode querer que exista uma cláusula de proteção em relação ao software. Lembre-se até mesmo a GPL é, antes de qualquer coisa, um contrato.

Não sou um advogado, mas o que eu posso recomendar é que você consulte um bom advogado para formatar um modelo de contrato que você vai usar para os serviços que você vai prestar. Preveja nesse contrato multa para o caso de o software ser transferido para além do que está acertado. Multas previstas em contrato são sempre mais fáceis de aplicar do que tentar reaver o software que foi distribuído.

Se você pensa que reaver o prejuízo na justiça pode ser muito lento e prefere não arriscar, bem, então é melhor não sair no mercado. Quem está na chuva é para se molhar e qualquer operação comercial envolve risco. Um risco muito mais provável do que alguém "roubar" o software é simplesmente você levar um calote. É muito mais provável acontecer uma instabilidade qualquer na empresa de um cliente e você pode não conseguir receber o dinheiro que você provavelmente contava naquele mês. Se um de seus clientes tiver motivação para roubar, ele vai fazê-lo. Nesses casos, é mais barato remediar do que prevenir.

Ninguem é tão genial a ponto de escrever algo único.

Você teve aquela sacada, e agora quer esconder dos outros programadores porque acredita que esta é sua vantagem competetiva. O que as pessoas não levam em conta é que em geral, o nivel dos programadores profissionais é proximo, nos dias de hoje não há um programador no mundo que faça algo que não pode ser feito por outros; ainda mais se os outros se reunirem em uma comunidade, ao redor de um projeto de código aberto. Uma longa lista de programas open source que tem funções parecidas ou equivalentes a de programas fechados são uma boa prova. Ao inves disso, se você compartilhar essa sacada com o resto do mundo, só vai fazer a sua reputação, status e credibilidade subir. E existe vantagem competitiva maior que essa?

O que é mais comum: pirataria de software fechado ou de software aberto?

Por que deixar o código aberto é uma idéia melhor?

Regra de ouro número 1: Você é só um, a sua empresa é só uma, o mundo tem muitas pessoas inteligentes dispostas a contribuir

Regra de ouro número 2: Cobre pelo serviço que você prestar.

E mais importante que tudo: Entenda bem o seu modelo de negócio e o mercado onde você vai atuar

AUTHOR

Nelson Ferraz

blog comments powered by Disqus