Estou desenvolvendo uma peça de software em Python que será distribuída para os clientes do meu empregador's. O meu empregador quer limitar o uso do software com um arquivo de licença com tempo restrito.
Se distribuirmos os arquivos .py ou mesmo .pyc, será fácil (descompilar e) remover o código que verifica o arquivo de licença.
Outro aspecto é que meu empregador não quer que o código seja lido por nossos clientes, temendo que o código possa ser roubado ou pelo menos o "idéias novas".
Existe uma boa maneira de lidar com este problema? De preferência com uma solução de prateleira.
O software será executado em sistemas Linux (então eu não't acho que o py2exe vai fazer o truque).
Python, sendo uma linguagem interpretada por bytes-codificação, é muito difícil de trancar. Mesmo que você use um ex-packager como py2exe, o layout do executável é bem conhecido, e os bytes-códigos Python são bem compreendidos.
Normalmente, em casos como este, você tem que fazer uma troca. Quão importante é realmente proteger o código? Existem lá segredos reais (como uma chave para criptografia simétrica de transferências bancárias), ou você está apenas sendo paranóico? Escolha a linguagem que lhe permita desenvolver o melhor produto mais rapidamente, e seja realista sobre o valor das suas ideias inovadoras.
Se você decidir que realmente precisa aplicar a verificação de licença com segurança, escreva-a como uma pequena extensão C para que o código de verificação de licença possa ser extra duro (mas não impossível!) para fazer engenharia reversa, e deixe a maior parte do seu código em Python.
O seu empregador sabe que pode "roubar" apoiar alguma ideia que outras pessoas obtêm do seu código? Quero dizer, se eles podem ler o seu trabalho, você também pode ler o deles. Talvez ver como você pode se beneficiar da situação possa render um melhor retorno do seu investimento do que temer o quanto você pode perder.
Resposta ao comentário de Nick's:
Nada ganhou e nada perdeu. O cliente tem o que quer (e pagou por isso desde que ele mesmo fez a mudança). Como ele não'não libera a mudança, é's como se não't acontecesse para todos os outros.
Agora, se o cliente vender o software, tem de alterar o aviso de direitos de autor (o que é ilegal, para que possa processar e ganhe -> caso simples).
Se eles não't mudarem o aviso de direitos autorais, os clientes de segundo nível notarão que o software vem de você original e se perguntam o que está acontecendo. As chances são de que eles entrem em contato com você e assim você aprenderá sobre a revenda do seu trabalho.
Mais uma vez, temos dois casos: O cliente original vendeu apenas algumas cópias. Isso significa que eles não'não ganharam muito dinheiro de qualquer maneira, então por que se preocupar. Ou eles venderam em volume. Isso significa melhores chances para você aprender sobre o que eles fazem e fazer algo a respeito.
Mas no final, a maioria das empresas tenta cumprir a lei (uma vez que sua reputação é arruinada, é muito mais difícil fazer negócios). Assim, não roubam o seu trabalho, mas trabalham com você para melhorá-lo. Portanto, se você incluir a fonte (com uma licença que o protege de uma simples revenda), as chances são de que eles simplesmente empurrem para trás as mudanças que fizeram, já que isso vai garantir que a mudança está na próxima versão e eles não'não têm que mantê-la. That's win-win: Você recebe as mudanças e eles podem fazer a mudança eles mesmos se eles realmente, desesperadamente precisam dela mesmo se você'não estiver disposto a incluí-la no lançamento oficial.
Você deve dar uma olhada em como os caras do getdropbox.com fazem isso para o software de seus clientes, incluindo o Linux. It'é bastante complicado de quebrar e requer alguma desmontagem bastante criativa para ultrapassar os mecanismos de protecção.