Seu sócio pediu para sair: ele pode levar o código? Propriedade intelectual, código-fonte e a saída do cofundador desenvolvedor

Alessandro C. Lavorante, Prof. Me. USP · OAB/SP

---

Dois amigos fundam uma startup. Um cuida do negócio, o outro escreve o código. Colocam 50% para cada no contrato social, apertam as mãos e mergulham na operação. Dezoito meses depois, o sócio-técnico decide sair. Ele desliga o notebook, revoga o acesso ao repositório (o ambiente digital onde o código-fonte da empresa é armazenado e versionado) e diz, com naturalidade desconcertante: "o código é meu, eu escrevi". A cena se repete com variações previsíveis em escritórios de advocacia e câmaras de mediação do país inteiro. O produto existe, os clientes pagam, a rodada de investimento estava encaminhada. Mas o ativo mais valioso da empresa acaba de sair pela porta junto com quem o escreveu. E a pergunta que ninguém fez a tempo passa a consumir honorários, noites de sono e, muitas vezes, a própria viabilidade do negócio: de quem é, afinal, o código? A resposta depende de uma teia de fatores que o contrato social não alcança e que o acordo de sócios, quando existe, raramente enfrenta. Os dois artigos seguintes desta série examinarão, respectivamente, os riscos que o contrato social de uma legaltech não resolve e o que acontece quando a due diligence expõe todos esses problemas ao investidor.

1. Equity não é propriedade intelectual

O equívoco mais difundido no ecossistema de startups — e o mais perigoso — é presumir que ter participação societária (o que o mercado chama de equity) equivale a ser dono do que foi criado dentro da empresa. Não equivale. Em nenhuma jurisdição relevante, deter quotas ou ações transfere automaticamente direitos autorais, patentes ou qualquer outro tipo de propriedade intelectual [1][2]. A participação societária remunera risco e capital investido. Ela não substitui o instrumento jurídico específico de cessão de propriedade intelectual — o que no mercado internacional se chama de IP assignment (cessão formal de PI). Para quem acha que isso é formalismo, vale imaginar a seguinte cena: sua startup está prestes a fechar uma Série B (uma rodada avançada de investimento, geralmente na casa de milhões de reais, destinada a escalar o negócio). O fundo de venture capital coloca os advogados para vasculhar tudo na due diligence. E aí descobre que o código inteiro da plataforma está juridicamente no nome do CTO que saiu seis meses atrás. Na prática de tech M&A nos Estados Unidos, advogados já tratam esse cenário como "thorny IP issue that can derail deals" — um problema espinhoso de titularidade capaz de matar a operação inteira [3][4]. Não se trata de hipótese acadêmica. Em 2026, a High Court de Karnataka, na Índia, decidiu no caso Harlalka v. State of Karnataka (Plutus Research Pvt. Ltd.) que o cofundador e acionista de uma empresa de trading algorítmico não tinha nenhum direito proprietário sobre os ativos digitais da companhia pelo simples fato de ser sócio [5]. O código, os modelos e os repositórios pertenciam à pessoa jurídica. A tentativa de removê-los configurou, segundo a corte, conduta passível de enquadramento criminal [6].

2. Cofundador, prestador, sócio: a zona cinzenta que a lei não previu

No Brasil, a Lei nº 9.609/1998 (Lei de Software), combinada com a Lei nº 9.610/1998 (Lei de Direitos Autorais), estabelece uma regra que surpreende muita gente: o autor originário do programa de computador é a pessoa física que o criou [7]. A exceção — atribuição automática ao empregador — exige vínculo empregatício formal e desenvolvimento dentro do escopo contratual [8]. Acontece que cofundadores técnicos de startups quase nunca são empregados. Atuam como sócios, como prestadores de serviço via CNPJ pessoal (o famoso PJ), ou numa zona cinzenta que desafia qualquer enquadramento binário. Nessa fresta, o código fica sem dono — ou com dois. Nos Estados Unidos, a doutrina do work made for hire (obra feita sob encomenda) resolve com relativa simplicidade os casos de código escrito por empregados: o copyright pertence à empresa desde a criação [9]. Mas o cofundador que atua via LLC pessoal ou que simplesmente nunca assinou contrato de trabalho é tratado como contractor (prestador autônomo) — e prestadores autônomos retêm a titularidade de tudo o que produzem, salvo cessão escrita [10]. Foi exatamente o que aconteceu no caso JustMed, Inc. v. Michael Byce, decidido pela corte de apelações do 9th Circuit em 2010. Byce havia sido contratado para reescrever o software embarcado de um dispositivo médico, remunerado em grande parte com participação societária — não com salário. A startup sustentou que ele era empregado; Byce, que era prestador independente. A corte confirmou o vínculo empregatício com base em critérios factuais (controle sobre horários, ferramentas, integração ao time) e reconheceu a JustMed como titular do copyright [11]. Byce ainda foi responsabilizado por apropriação indevida de segredos de negócio e violação de dever fiduciário [12]. O precedente é instrutivo, mas carrega um alerta que não pode passar despercebido: a JustMed venceu porque conseguiu provar a relação de emprego. Se Byce tivesse sido genuinamente autônomo, o resultado seria o oposto. A startup teria perdido o acesso ao próprio produto. No Reino Unido, a lógica é análoga. O Copyright, Designs and Patents Act 1988 transfere ao empregador o copyright de obras criadas durante o emprego, mas cofundadores que atuam como diretores sem contrato de employment não se beneficiam dessa presunção [13][14]. Na França e na Alemanha, a proteção autoral é ainda mais centrada no criador: a cessão deve ser expressa, granular, com descrição detalhada das obras e das modalidades de exploração cedidas [15]. O Brasil, com a Lei nº 9.610/1998, se alinha a essa tradição continental: cessão escrita, com especificação de obra, território, prazo e modalidades [16]. Interpretação restritiva é a regra, não a exceção [17]. Na prática, isso significa o seguinte: o cofundador técnico de uma startup brasileira que programa o MVP (Minimum Viable Product, o protótipo funcional mínimo do produto) antes mesmo de abrir o CNPJ, continua desenvolvendo depois sem contrato formal, e nunca assina instrumento de cessão de propriedade intelectual — esse cofundador é, juridicamente, o dono do código. A sociedade, na melhor das hipóteses, detém uma licença implícita de uso, deduzida da boa-fé e da conduta das partes [18]. Mas licença implícita não é cessão. E licença implícita, por definição, não sobrevive sem contestação quando o licenciante sai pela porta batendo.

3. Zipcar e a governança que não existia

Antes que alguém objete que esse tipo de conflito é coisa de startup de garagem, vale olhar para o caso Zipcar — que virou estudo de caso no MIT Sloan [19]. Robin Chase e Antje Danielson fundaram a empresa em 2000 com participações iguais: 50/50. Em poucos meses, conflitos sobre execução racharam a relação. Chase, com apoio do conselho, demitiu Danielson, cuja participação diluiu de 50% para 1,3% ao longo das rodadas seguintes, sem mecanismo claro de proteção antidiluição [20]. O caso não envolvia código — mas a mecânica de destruição é a mesma: dois fundadores, sem estrutura de saída, cujo conflito dilui valor que deveria estar protegido. A saída do cofundador expõe o primeiro problema — quem é dono do código. Mas expõe também um segundo, que costuma ficar enterrado até o momento da diligência.

4. Contaminação por copyleft: a dependência que ninguém auditou

A saída do cofundador técnico descortina uma segunda camada de risco que costuma permanecer invisível até o momento do conflito. É o que o mercado chama de contaminação por copyleft. Para quem não vem da área de tecnologia, uma breve explicação: boa parte do software moderno é construída com peças de código já prontas, chamadas de bibliotecas. Muitas dessas bibliotecas são open source (código aberto) — ou seja, podem ser usadas livremente, mas sob condições. Algumas dessas condições são razoáveis (dar crédito ao autor original). Outras são explosivas. Licenças como GPLv3 e AGPL (Affero General Public License, variante que estende as obrigações do copyleft a software acessado em rede) detêm o que se convencionou chamar de efeito copyleft: quem usa código sob essas licenças é obrigado a distribuir o código derivado (isto é, o produto inteiro que incorporou aquela peça) sob os mesmos termos abertos [21]. No contexto de um SaaS, a AGPL vai além: essa obrigação se aplica mesmo quando o código não é distribuído fisicamente, bastando que o software seja disponibilizado como serviço em rede [22][23]. Se o desenvolvedor incorporou uma única biblioteca AGPL três níveis abaixo na árvore de dependências, mesmo sem perceber, toda a base proprietária pode estar comprometida [22][24]. Na literatura de M&A tecnológico, esse tipo de contaminação é classificado como obstáculo crítico capaz de inviabilizar a operação inteira [22]. Há relatos documentados de aquisições renegociadas, reestruturadas ou simplesmente abandonadas depois que a due diligence revelou componentes copyleft entranhados no código proprietário [25]. Quando esse risco se sobrepõe à saída do cofundador técnico, a equação fica mais pesada. Se foi ele quem introduziu o componente contaminado sem informar os demais sócios, a discussão transborda do campo da propriedade intelectual para o da responsabilidade societária: violação do dever de lealdade, falha no dever de informação e, sob a ótica brasileira, eventual configuração de dolo ou erro essencial que vicie o próprio ato constitutivo da sociedade [26]. A remediação — reescrever módulos, substituir bibliotecas, refatorar a arquitetura inteira — custa tempo e dinheiro que a startup em fase inicial raramente tem [24]. Mas a titularidade e a contaminação do código não se provam com testemunhos. Provam-se com registros — e esses registros, na maioria dos casos, já existem.

5. Commits, logs e CODEOWNERS: a perícia forense que já existe no repositório

Todo desenvolvedor profissional usa um sistema de controle de versão chamado Git. Cada alteração no código é registrada num commit — uma espécie de carimbo digital que grava quem alterou o quê, quando e por quê. Além disso, plataformas como GitHub permitem que equipes definam, via arquivos chamados CODEOWNERS, quem é responsável por cada parte do código. Essa combinação de registros começa a ser usada em litígios e arbitragens como prova de autoria, contribuição e até conhecimento de falhas [27][28]. Para o cofundador que sai, o histórico de commits funciona como arma de mão dupla. De um lado, ele pode demonstrar que escreveu parcela substancial do produto. De outro, a startup pode usar o mesmo histórico para provar que módulos inteiros foram reescritos por outros desenvolvedores ao longo do tempo — diluindo a pretensão de autoria exclusiva [28]. Em operações de fusão e aquisição transfronteiriças, advogados especializados já examinam rotineiramente logs de acesso, revisões de código e aprovações de alterações como parte da perícia forense de PI [29]. Uma solução que começa a aparecer em acordos de sócios mais sofisticados é a inclusão de uma presunção contratual simples: "salvo prova em contrário, o titular da conta que realizou o commit será considerado autor do trecho correspondente" [28]. Parece processual, mas resolve disputas que de outro modo exigiriam perícia técnica custosa — e se alinha com a doutrina brasileira de obras coletivas, que permite tratar o produto de software como obra cuja titularidade pertence ao organizador, mesmo que módulos individuais tenham autoria identificável [16][17]. Se titularidade e contaminação dependem de registros técnicos, há um terceiro problema que torna esses registros ainda mais opacos: o código que nenhum humano escreveu sozinho.

6. Copilot, ChatGPT e a autoria que ninguém sabe atribuir

Parte crescente do código-fonte de produtos modernos é gerada ou substancialmente assistida por ferramentas de inteligência artificial, como GitHub Copilot ou ChatGPT. Em 2024, a pesquisa anual Developer Survey da Stack Overflow registrou que 76% dos desenvolvedores profissionais já usavam ou planejavam usar assistentes de IA para codificação [31] — o dado transformou o que era tendência em infraestrutura de trabalho. E a rotina traz ao menos dois problemas sobrepostos. O primeiro é a autoria. O debate internacional converge para a posição de que o direito autoral protege criações do espírito humano, não saídas puramente automatizadas [31]. O caso DABUS, decidido pelo Federal Circuit norte-americano em 2022, consolidou para patentes o entendimento de que uma IA não pode ser inventora [32]; o raciocínio, por analogia, transborda para software. No Brasil, pareceres acadêmicos e o Projeto de Lei nº 303/2024 caminham na mesma direção [33]. Para o cofundador que usou Copilot extensivamente, a tese sustentável é que a autoria do código final cabe ao humano que selecionou, adaptou e integrou o resultado da ferramenta [31]. Mas aí entra o segundo problema: o risco de que trechos gerados pela IA reproduzam código de terceiros licenciado sob GPL/AGPL, sem que o desenvolvedor sequer perceba [30][22]. Investidores já incluem em seus roteiros de due diligence perguntas específicas sobre uso de IA para codificação e existência de políticas internas de mitigação [29][30]. A saída do cofundador que era o principal operador dessas ferramentas agrava a exposição: com ele vai também o conhecimento sobre quais trechos foram humanos, quais foram assistidos e quais foram essencialmente delegados à máquina.

7. O que o acordo de sócios precisa conter (e quase nunca contém)

O diagnóstico é desconfortável, mas não é irremediável. Contrato social não resolve propriedade intelectual. O acordo de sócios (instrumento parassocial, celebrado entre os sócios à margem do contrato social, com regras sobre governança, saída e direitos que o registro público não comporta) genérico — aquele que trata apenas de vesting, drag-along e tag-along e não competição — resolve metade. A outra metade exige instrumentos específicos que a prática internacional já consolidou e que a legislação brasileira permite adotar, desde que respeitados os requisitos formais das Leis nº 9.609/1998 e nº 9.610/1998 [17][34].

7.1. Cessão antecipada e automática de PI

O mecanismo mais elementar, e paradoxalmente o mais negligenciado, é uma cláusula de cessão ampla de propriedade intelectual, cobrindo tanto o código produzido antes da constituição da empresa (o MVP, o protótipo, os primeiros scripts) quanto todo o desenvolvimento posterior. Nos Estados Unidos, essa cláusula costuma vir nos moldes do hereby assigns ("o fundador, por este instrumento, cede e transfere..."), e precisa ser adaptada às exigências brasileiras de especificação de obra e escopo [10][17]. A Lei Complementar nº 182/2021 (Marco Legal das Startups), embora não discipline diretamente a matéria, tipificou e disciplinou modelos contratuais sofisticados no ambiente de startups e fornece moldura para que acordos parassociais incorporem cláusulas de cessão intelectual [34][35]. Na prática, quase ninguém faz. O custo parece desproporcionado quando os sócios ainda se gostam — até o dia em que o custo de não ter feito se torna irrecuperável.

7.2. Cessão escalonada de PI: o mecanismo que vincula entrega técnica à consolidação de direitos

Uma sofisticação que ganha tração no mercado internacional é o dual vesting: de um lado, a aquisição progressiva de participação societária tradicional, baseada em tempo; de outro, um vesting de propriedade intelectual atrelado a entregas técnicas verificáveis — conclusão do MVP, migração para microsserviços, certificação de segurança [2][36]. A cada entrega concluída, consolida-se a cessão de um módulo de PI à sociedade e reduz-se o percentual de recompra de participação em caso de saída. O mecanismo transforma a cessão de PI em processo escalonado, com condições bem descritas; atende, assim, à exigência da Lei nº 9.610/1998 de que a cessão seja específica quanto ao objeto [16].

7.3. Escrow de código-fonte

Na prática internacional de licenciamento corporativo, o source code escrow (depósito de código-fonte junto a terceiro de confiança) já é mecanismo consolidado: empresas como Escode (do grupo NCC) e Codekeeper operam globalmente [37]. A adaptação para cofundadores é direta. O código fica depositado junto a terceiro independente, com gatilhos de liberação vinculados a morte ou incapacidade do cofundador, recusa de suporte ou evento de liquidez [37][38]. A startup garante continuidade operacional; o cofundador, por sua vez, protege-se contra uso abusivo — inclusive com cláusulas de reversão caso a sociedade deixe de explorar o software [38]. Na prática, quase ninguém faz isso também. O argumento é sempre o mesmo: "somos três, nos conhecemos desde a faculdade." Até que não são mais três.

7.4. Governança de repositórios e further assurances

Quem controla a organização no GitHub? Quem detém as credenciais de infraestrutura? Essas questões, que pareceriam prosaicas para advogados societários de gerações anteriores, têm hoje consequência prática maior do que a titularidade registral de marca [28]. O acordo de sócios deve tratar expressamente: quem pode criar repositórios, quem aprova alterações críticas, quem detém chaves de acesso. E deve conter cláusulas de further assurances (compromisso de cooperação futura): a obrigação do cofundador de assinar, a qualquer tempo e mesmo após a saída, todos os instrumentos de cessão exigidos por investidores ou adquirentes para regularizar a cadeia de titularidade [4][10].

8. O espaço contratual brasileiro: cessão, limites e o que se pode importar

A análise comparada revela uma convergência funcional entre países que, por caminhos legislativos distintos, chegam ao mesmo resultado prático: sem cessão expressa, o código pertence ao desenvolvedor. O Brasil não tem um Founder IP Assignment Act e a Lei nº 9.609/1998 não foi redigida com startups em mente. Mas o espaço contratual criado pela LC nº 182/2021, aliado à autonomia dos acordos parassociais, permite importar quase integralmente as práticas de Delaware, do Reino Unido e da Alemanha [34][35]. A condição é respeitar a forma: cessão escrita, objeto especificado, atenção aos limites dos direitos morais de autor, que no Brasil são irrenunciáveis [16]. A nosso ver — e a doutrina recente caminha nessa direção — diante do silêncio contratual, a boa-fé objetiva e a função social da empresa permitem, em certos casos, reconhecer à sociedade ao menos um direito de exploração do software, na forma de licença irrevogável [18]. Essa construção, contudo, não resolve a titularidade formal. A startup poderia usar o código, mas não cedê-lo a terceiros, relicenciá-lo ou defendê-lo em juízo contra imitadores sem a cooperação do autor original. É, no melhor dos cenários, uma solução parcial e litigiosa. Ninguém constrói uma empresa sobre uma licença implícita.

Conclusão

O fio condutor deste artigo pode ser condensado numa constatação incômoda: sociedade em startup de tecnologia sem cessão formal de propriedade intelectual funciona enquanto ninguém sai, ninguém discorda e o investidor não pergunta. A experiência doméstica e internacional demonstra que essas três premissas falham com regularidade desconcertante [1][4][19]. O caso JustMed nos Estados Unidos [11], o caso Plutus Research na Índia [5], o caso Zipcar como narrativa fundacional [19][20], e a jurisprudência brasileira sobre titularidade de software [7][8] convergem para um único princípio: equity. A hora de resolver essa equação é quando todos ainda se gostam, quando a empresa é projeto e não litígio, quando o acordo de sócios pode ser redigido com precisão cirúrgica em vez de reconstruído por perícia judicial. O cofundador técnico que sai pode, sim, levar consigo seu talento, sua experiência e sua capacidade de construir. O que ele não pode levar — desde que a empresa tenha feito o dever de casa — é o código que pertence à sociedade por cessão, por contrato, por governança. Nós entendemos a tentação de deixar para depois. Já vimos esse filme repetido o suficiente para saber como termina.

Referências

[1] CROWLEY LAW LLC. Startup IP Assignment Agreements: Protect Chain of Title. Disponível em: https://www.crowleylawllc.com. Acesso em: 1º abr. 2026. [2] JONATHAN LEA NETWORK. When Co-Founders Resign: Who Owns the Code and Intellectual Property? Disponível em: https://www.jonathanlea.net. Acesso em: 28 mar. 2026. [3] GIBSON DUNN. IP Due Diligence in Technology M&A Transactions. Disponível em: https://www.gibsondunn.com. Acesso em: 1º abr. 2026. [4] ACC — Association of Corporate Counsel. Thorny IP Issues That Can Derail M&A Deals. Disponível em: https://www.acc.com. Acesso em: 30 mar. 2026. [5] LIVELAW. Shareholder Has No Proprietary Rights Over Company's Digital Assets — Karnataka HC. Disponível em: https://www.livelaw.in. Acesso em: 1º abr. 2026. [6] CASEMINE. MR. Aashay Harlalka v. State of Karnataka, Karnataka High Court, 2026. Disponível em: https://www.casemine.com. Acesso em: 1º abr. 2026. [7] BRASIL. Lei nº 9.609, de 19 de fevereiro de 1998. Dispõe sobre a proteção da propriedade intelectual de programa de computador. [8] BRASIL. Lei nº 9.609, de 19 de fevereiro de 1998, art. 4º. [9] EUA. Copyright Act of 1976, 17 U.S.C. § 101 (definição de work made for hire). [10] PROMISE LEGAL. Founder Agreement Template: Equity Splits, Vesting, and IP Assignment Explained. Disponível em: https://blog.promise.legal. Acesso em: 29 mar. 2026. [11] JustMed, Inc. v. Byce, 600 F.3d 1118 (9th Cir. 2010). [12] JustMed, Inc. v. Byce, 600 F.3d 1118 (9th Cir. 2010) — responsabilização por apropriação indevida de segredos de negócio e violação de dever fiduciário. [13] REINO UNIDO. Copyright, Designs and Patents Act 1988, s. 11(2). [14] ORRICK. IP Ownership in Technology Transactions: Founders, Employees and Contractors. Disponível em: https://www.orrick.com. Acesso em: 30 mar. 2026. [15] JDSUPRA. IP Ownership in Cross-Border Startup Structures. Disponível em: https://www.jdsupra.com. Acesso em: 28 mar. 2026. [16] BRASIL. Lei nº 9.610, de 19 de fevereiro de 1998. Altera, atualiza e consolida a legislação sobre direitos autorais. [17] MCK ADVOGADOS. Propriedade Intelectual de Software e Cessão de Direitos no Brasil. Disponível em: https://mckadvogados.com.br. Acesso em: 1º abr. 2026. [18] PERDIZ, Daniel. As Startups no Direito Societário Brasileiro. São Paulo: Quartier Latin, 2023. [19] MIT SLOAN MANAGEMENT REVIEW. Robin Chase, Zipcar, and an Inconvenient Discovery. Case Study. Disponível em: https://mitsloan.mit.edu. Acesso em: 29 mar. 2026. [20] THE VERGE. Driven: How Zipcar's Founders Built and Lost a Car-Sharing Empire. Disponível em: https://www.theverge.com. Acesso em: 29 mar. 2026. [21] HELLODATA.AI. What is a Copyleft License and Why is it Risky for Startups? Disponível em: https://www.hellodata.ai. Acesso em: 31 mar. 2026. [22] MINDCTO. The Copyleft Threat: How AGPL License Risk Can Destroy Your Startup's Valuation. Disponível em: https://mindcto.com. Acesso em: 31 mar. 2026. [23] FOSSITY. Open Source License Compliance and Due Diligence for M&A. Disponível em: https://fossity.com. Acesso em: 31 mar. 2026. [24] LEGAL500. IP Due Diligence and Founder Agreements in Tech M&A. Disponível em: https://www.legal500.com. Acesso em: 30 mar. 2026. [25] FOSSITY. Open Source License Compliance and Due Diligence for M&A. Disponível em: https://fossity.com. Acesso em: 31 mar. 2026 — relatos de aquisições renegociadas por contaminação copyleft. [26] LEGALE. Aspectos Societários e Contratuais de Startups Brasileiras. Disponível em: https://legale.com.br. Acesso em: 1º abr. 2026. [27] GRAPHITE. Understanding GitHub CODEOWNERS. Disponível em: https://graphite.dev. Acesso em: 28 mar. 2026. [28] MINDCTO. The Copyleft Threat — seção sobre governança de repositórios e uso de commits como evidência em due diligence. Disponível em: https://mindcto.com. Acesso em: 31 mar. 2026. [29] GIBSON DUNN. IP Due Diligence in Technology M&A Transactions — seção sobre perícia forense de repositórios. Disponível em: https://www.gibsondunn.com. Acesso em: 1º abr. 2026. [30] MIGALHAS. Código gerado por IA: autoria, licenciamento e riscos para startups. Disponível em: https://www.migalhas.com.br. Acesso em: 1º abr. 2026. [31] IDS — Instituto de Direito e Sociedade. Direitos autorais e inteligência artificial: criações do espírito humano. Disponível em: https://ids.org.br. Acesso em: 29 mar. 2026. [32] Thaler v. Vidal, 43 F.4th 1207 (Fed. Cir. 2022) — caso DABUS. [33] BRASIL. Projeto de Lei nº 303/2024. Dispõe sobre a regulamentação da inteligência artificial. [34] BRASIL. Lei Complementar nº 182, de 1º de junho de 2021 (Marco Legal das Startups). [35] PERIÓDICOS UNISANTACRUZ. Aspectos do Marco Legal das Startups e a governança de PI. Disponível em: https://periodicos.unisantacruz.edu.br. Acesso em: 30 mar. 2026. [36] SOLV LEGAL. We Built the Product But Don't Own It: How Founders Lose IP. Disponível em: https://solvlegal.com. Acesso em: 28 mar. 2026. [37] ESCODE (NCC Group). Industry-Leading Software Escrow Solutions. Disponível em: https://www.escode.com. Acesso em: 29 mar. 2026. [38] ESCROWSURE. Source Code Escrow in M&A Transactions. Disponível em: https://www.escrowsure.com. Acesso em: 30 mar. 2026.