Publicidade
Início Blogueria A importância dos contratos de Escrow de código fonte de software

A importância dos contratos de Escrow de código fonte de software

3
Publicidade

Na busca por melhor desempenho e controle de suas operações, as empresas têm investido cada vez mais em TI, especialmente em softwares feitos sob medida. Não é incomum que estes softwares se tornem essenciais para as corporações, pois algumas das operações mais importantes estão a eles vinculadas.

Imaginemos, como exemplo, que determinada empresa do segmento de logística, controle suas operações, tais como horários, itinerários, mercadorias a serem transportadas, clientes, etc., por meio de determinado software. O mau funcionamento do mesmo poderá interromper completamente a atividade da empresa. Porém, há uma hipótese ainda pior: e se a empresa responsável pelo software não puder repará-lo, porque fechou as portas?

Certamente que adquirir um software feito sob medida é uma atividade de grande risco. Não apenas porque o programa deverá se encaixar o mais perfeitamente possível às necessidades do adquirente, e essa compatibilidade nem sempre é facilmente alcançada, mas porque a aquisição, invariavelmente, vinculará o cliente ao desenvolvedor, não apenas quando se fala em reparos, mas também de atualização conforme as novas tecnologias e necessidades. Se o desenvolvedor desaparecer, falir ou encerrar completamente suas atividades, ou mesmo em determinados casos de desacordo comercial, o cliente poderá ser grandemente afetado.

Observando este anseio por maior segurança quanto à continuidade do negócio é que invariavelmente sugerimos um contrato de Escrow de Código Fonte. O Escrow consiste no depósito de um bem ao cuidado de uma terceira pessoa, a quem incumbe a guarda do mesmo até que seja reivindicada por quem tenha direito.

No caso dos softwares, ao se contratar uma empresa desenvolvedora, o adquirente poderá exigir que o código-fonte seja entregue aos cuidados de um terceiro de confiança das partes (depositário). As partes, então, deverão prever em contrato quais serão as hipóteses que ensejarão o direito do adquirente reivindicar o código-fonte do software, não podendo o depositário se opor a esta reivindicação. Dessa forma, o adquirente que não contar mais com a assistência do desenvolvedor poderá utilizar sua equipe de TI própria ou até mesmo contratar outra empresa de desenvolvimento para dar manutenção ao programa. Isso diminui consideravelmente o risco de prejuízos oriundos da interrupção do funcionamento do software.

Todavia, o contrato de Escrow, que pode ser a tábua de salvação em momentos delicados, não deixa de requerer alguns cuidados. Vamos tratar dos principais:

1. O terceiro depositário precisa ser de confiança de ambas as partes, idôneo e com experiência no ramo. Isso porque o código-fonte é a alma do software, objeto de proteção da lei de direitos autorais. Se uma pessoa de má-fé se apropriar dele, poderá reproduzir o programa livremente, o que gerará grandes prejuízos à empresa desenvolvedora. É conveniente também verificar o nível de segurança da informação oferecido pelo depositário, já que a ação de hackers poderia fazer vazar as informações estratégicas.

2. É necessário que a empresa desenvolvedora mantenha o código-fonte atualizado, fazendo com que o software permaneça sempre igual nas duas pontas, a do adquirente e a do depositário. É possível, inclusive, prever a liberação do código caso o mesmo não seja atualizado junto ao depositário. Não lhe será útil reivindicar a liberação do código-fonte de um software se o depositário estiver com uma versão muito desatualizada sob seu poder.

3. Quanto mais claras forem as regras para liberação do código, maior será a segurança jurídica das partes. De preferência com critérios objetivos e de forma a contemplar todas as hipóteses.

4. Se o software não for essencial às suas atividades, sendo facilmente substituídos por outros que existam no mercado, provavelmente exigir o Escrow não será o mais adequado. Isso por dois motivos: primeiro, as empresas desenvolvedoras que ainda não estão familiarizadas com o Escrow poderão resistir à ideia, gerando desgaste desnecessário na relação contratual; segundo, o depositário será remunerado por seus serviços e isso aumentará o custo da contratação.

Por fim, é possível afirmar que o Escrow não beneficia apenas o adquirente. Uma empresa de desenvolvimento que não cumpre com suas obrigações contratuais poderá ter que responder por perdas e danos, sendo que, dependendo do caso, os sócios poderão ser acionados. Se o Escrow tem o condão de diminuir o prejuízo do adquirente, certamente diminuirá proporcionalmente a indenização eventualmente devida pelo desenvolvedor por quebra de contrato.

Márcio Cots é sócio do Cots Advogados. Professor universitário de Direito Aplicado às Novas Tecnologias em MBA’s da FIAP e da APET ( Associação Paulista de Estudos Tributários), mestre em Direito pela FADISP (Faculdade Especializada em Direito) e pós-graduado em Direito Empresarial pela Universidade Mackenzie, fez Extensão Universitária em Direito da Tecnologia da Informação pela FGV-EPGE e participou do iLaw Program 2005 na Harvard Law School, na Harvard University (EUA).

3 COMENTÁRIOS

  1. Não seria mais viável para o adquirente ao inves de contratar contratar o mais barato contratar o melgor? Hoje é muito dificil customizar um sistema porque as empresas não querem mais o melhor e sim o mais barato. Por isso a promiscuidade dentro das empresas contratam programadores que só entendem da programação( enganam) porém nada da legislação. Não se desenvolve um sistema bom hoje em nosso pais sem que o programador e o analista tenham muito conhecimento da legislação brasileira.Para o usuário final e muito simples programamar ele só aperta botões e tem o resultada. Ninguem quer pensar mais só apertar botões.Para se fazer um programa com regras de negócios inteligentes precisa-se no minimo de três cabeças que entendam da legislação: O analista, o programador e o que faz os testes finais. Quando voce passa uma proposta para uma empresa que está fazendo cotação ela nunca pergunta nada sobre idoneidade, anos de mercado, conhecimentos dos profissionais entre tantos outros quesitos para se fabricar um sistema ela só quer saber de preço e não tem nada que a convença que não está sendo lesado. Hoje para desenvolver um sistema que atenda a empresa em 100% gasta-se uma media de R$5.000,00 por dia com esses três funcionarios qualificados.Se pegarmos esse valor e mutiplicar vezes o numero de horas de trabalho e passar para o cliente ele vai direto no concorrente que pega recem formados da faculdade paga pouco eles não a inteligenia do negocio mas o vendedor encanto o cliente com sua labia mas o preço que ela acha bom e o problema está criado. Empresas como a minha que tem mais de 30 anos de mercado e tem a equipe com a experiencia que o negocio precisa perde todos os dias futuros clientes para essas novas empresas.Conheço empresas que estão a ponto de fechar por esse motivo tem funcionarios competentes portanto caros e não conseguem fechar os negocios por causa dessa concorrencia desleal que só existe porcausa do proprio cliente se ele fosse mais seletivo não teria sua fabricante de softwres fechada.A concorrencia desleal não está só no desenvolvimento está tambem nos sistemas já implantados. O cliente não entende e troca de sistemas por menos R$50,00 na manutenção chega ser uma irresponsabilidade fazer uma coisa dessas se migres não existem na informática porque será que uma empresa precisa cobrar R$500,00 e a outra cobra R$280,00 de todos os sistemas administrativos? Ou copiaram de alguem, ou o suporte é pessimo ou não recolhem os impostos ou recebem doações ou receberam mesmo um milagre. Os clientes não medem as consequencias futuras apenas acha que está economizando e fica momentaneamente feliz e achando que fez um grande negocio.
    E por falar em clientes voces já perceberam que o cliente brasileiro não gosta de ser bem atendido.Tenho a impressaõ que eles acham monótono toda vez que ligar ser bem atendido,ter a solução do problema,as dúvidas resolvidas, ter a visita quando solicitada tudo muito certinho cansa. O bom e ligar ficar esperando uns 40 min. ouvindo uma musiquinha depois falar com uma maquina que passa para um atendente que na hora que pega cai a linha e depois de tenta inumeras vezes ser atendido por um funcionario que olhou em um manual para ver a resposta ou perguntou para o colega ou bufa ao falar com voce que responde somente o perguntado sem enriquecer a resposta para seu maior conhecimento. Acho que brasileiro gosta de se fazer de vítima ou tem tantos problemas que quando são bem atendidos se sentem frustrados:Como assim? Não precisei brigar? não fiquei estressado? que chato? que monótono.

  2. Prezado Dr. Márcio,

    Muito pertinente seu artigo.
    Trabalho no segmento de softwarehouse há 26 anos, tanto em empresas de sistemas prontos (ERP, CRM, BI, etc), quanto de fábricas profissionais de software.

    Este conceito de escrow já está previsto na maioria dos contratos das empresas de melhor qualidade, mas ainda é bem desconhecida das pequenas.

    Eu gosto de trabalhar com a antecipação de fatos, fazendo uma excelente seleção de fornecedor.

    Na prática, se uma empresa quebrar, será quase impossível que outra empresa assuma o projeto, a não ser que consiga contratar o time de analistas e desenvolvedores. O software em si é apenas uma parte do negócio.

    Selecionar com profissionalismo e métodos consagrados garante que o investimento da empresa seja protegido.

    Luis F G Deak

  3. Olá, estou passando por algo parecido mas desconhecia o contrato de Escrow. Criei um software em Delphi e pedi para que uma empresa traduzisse meu software para linguagem WEB. Forneci meu código fonte como base, contudo eles deixam muito a desejar quanto ao suporte. Quero mudar de empresa e eles não me fornecem o código “adaptado” por eles e com isso me faria gastar muito dinheiro para que a outra empresa recriasse o software.

DEIXE UMA RESPOSTA

Por favor digite seu comentário!
Por favor, digite seu nome aqui

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Sair da versão mobile