Numa empresa de tecnologia, o que mais vale quase nunca é o que está registrado. Marca e patente protegem coisas bem delimitadas, o nome e a invenção, enquanto o valor real costuma estar em outro lugar: no jeito de integrar sistemas, na lógica das APIs, no conjunto de dados e nos processos que fazem o produto funcionar melhor que o do concorrente. Esse ativo não tem certificado nenhum a que recorrer, e é justamente ele que um parceiro, um fornecedor ou um ex-integrante consegue replicar sem nunca tocar no que está protegido. A proteção de know-how é o tema que fundador nenhum deveria deixar para depois da primeira cópia.
Por que registro não resolve
Cada instrumento de registro dá exclusividade sobre uma coisa bem delimitada, e é aí que mora o problema. A marca cobre o sinal que distingue o produto, nada além dele. O software é protegido pelo código, porque a Lei 9.609/1998 manda aplicar ao programa de computador o regime das obras literárias, e o art. 2º, § 3º, chega a dizer que essa proteção independe de registro, de modo que o depósito no INPI existe como faculdade do titular e não como condição. Já a patente exige novidade, atividade inventiva e revelação pública da invenção, requisitos que muitas soluções de integração não preenchem e, quando preenchem, cobram um preço que poucos querem pagar: contar ao mercado como a coisa funciona.
A vantagem competitiva de uma empresa de tecnologia raramente cabe nessas caixas. Uma API bem desenhada pode ser observada e reimplementada por quem nunca viu o código, e um fluxo de integração pode ser descrito, de memória, por quem trabalhou com ele durante seis meses. O conhecimento de como fazer escorre pelas bordas do que o registro alcança, de forma que contar apenas com marca e patente é proteger a fachada e deixar o cofre aberto.
Segredo de negócio: a proteção de know-how que a lei já dá
O direito brasileiro protege esse ativo, mas por uma via diferente da do registro. O art. 195, XI, da Lei da Propriedade Industrial tipifica como crime de concorrência desleal divulgar, explorar ou utilizar, sem autorização, conhecimentos, informações ou dados confidenciais utilizáveis na indústria, no comércio ou na prestação de serviços, a que se teve acesso mediante relação contratual ou empregatícia, e o texto é expresso ao dizer que o dever persiste mesmo após o término do contrato. Ficam de fora os conhecimentos de domínio público ou evidentes para um técnico no assunto. O inciso XII alcança quem obtém essas informações por meio ilícito ou fraude, e o § 1º estende a tipificação ao empregador, sócio ou administrador que incorrer nessas condutas.
A diferença prática é decisiva. O segredo de negócio não depende de depósito nem tem prazo de validade: ele vale enquanto a informação for, de fato, secreta e tiver valor por ser secreta. Em troca dessa vantagem, impõe um dever. A empresa precisa tratar a informação como confidencial de verdade. Segredo que circula sem controle, que qualquer fornecedor acessa sem restrição e que não está marcado como sigiloso deixa de merecer a proteção, porque deixou de ser segredo. Repare no recorte legal: a proteção nasce do acesso ter vindo por contrato ou emprego, e é por isso que o contrato é o centro de tudo.
APIs e integrações: proteger o que é copiável
APIs e integrações vivem numa zona cinzenta, porque o código que as implementa tem proteção autoral, mas a funcionalidade, a interface e a lógica de negócio que elas expõem não necessariamente têm. Quem observa a integração de fora pode reimplementá-la sem copiar uma linha sequer. Proteger uma API, por isso, é menos uma questão de registrar e mais de controlar quem acessa e sob que condições.
Na prática, isso significa desenhar a relação com quem toca a integração, o cliente que consome a API, o parceiro que integra, o fornecedor que desenvolve, de modo que o acesso venha acompanhado de limites claros: o que pode ser feito, o que não pode, e o que acontece se a fronteira for cruzada. A documentação técnica confidencial, as chaves de acesso e os termos de uso da API são camadas dessa proteção. Deixar a API aberta e sem termos é entregar o mapa da mina.
O contrato é onde a proteção de know-how se fecha
Se o registro não cobre e o segredo depende de disciplina, é no contrato que a proteção se sustenta.
Confidencialidade com dentes. Não basta o rótulo NDA. O acordo precisa definir o que é informação confidencial, por quanto tempo, e prever consequência real para o vazamento. Cláusula genérica, sem definição e sem sanção, é decorativa.
Titularidade de PI clara. Todo desenvolvimento feito por prestador, freelancer ou parceiro precisa ter a titularidade definida por escrito e cedida à empresa quando for o caso. Sem cláusula de cessão, quem escreveu o código pode ser o titular dos direitos sobre ele, e a empresa fica dependente de quem deveria ser fornecedor.
Não concorrência e não aliciamento, nos limites da lei. É legítimo impedir que um parceiro use o acesso que teve para montar um concorrente com a mesma solução, ou para aliciar time e clientes. Essas cláusulas exigem limite de tempo, de território e de objeto para serem exigíveis, porque restrição excessiva à liberdade de trabalho e de concorrência não se sustenta.
Regras de uso da integração. Quem consome a API aceita termos que dizem o que pode fazer com os dados e com a conexão, e que proíbem engenharia reversa e replicação. É o que transforma um acesso técnico numa relação com fronteira jurídica.
Um roteiro para o fundador
Antes de abrir a integração para o primeiro parceiro, vale organizar quatro frentes. Mapeie o que é realmente segredo e o que é só código, porque a proteção de cada um é diferente. Marque e trate como confidencial o que for segredo, com controle de acesso de verdade. Amarre por contrato a confidencialidade, a titularidade da PI e os limites de uso com todo mundo que toca o ativo, do desenvolvedor ao cliente da API. E registre o que faz sentido registrar, marca e, quando couber, software, sem confundir isso com a proteção de know-how, que corre por outra via. Como esse ativo é o que sustenta o valuation numa rodada, tratá-lo bem também é preparar a empresa para o investimento.
Perguntas frequentes
Dá para patentear uma API ou uma integração?
Em regra, não da forma que o fundador imagina. Software tem proteção autoral pelo código, e patente exige requisitos rígidos e revelação da invenção. A proteção mais eficaz para integrações e know-how costuma vir de segredo de negócio somado a contrato.
O segredo de negócio precisa ser registrado?
Não. Ele não depende de depósito e não tem prazo: vale enquanto a informação for secreta, tiver valor por ser secreta e for tratada com medidas reais de sigilo pela empresa.
Preciso registrar o software no INPI?
Não é obrigatório. A Lei 9.609/1998 diz que a proteção independe de registro, e o art. 3º coloca o registro como faculdade do titular. Ele ajuda como prova de anterioridade, não como condição da proteção.
Um NDA basta para proteger o know-how?
Ajuda, mas sozinho não basta. Confidencialidade precisa vir acompanhada de definição do que é sigiloso, de controle de acesso efetivo e de cláusulas de titularidade de PI e de limites de uso.
Posso proibir um parceiro de replicar minha solução?
Pode, dentro de limites. Cláusulas de não concorrência e de não aliciamento são válidas quando têm prazo, território e objeto delimitados. Restrição ampla e indefinida tende a não ser exigível.
E se o desenvolvimento foi feito por um terceiro?
Sem cláusula de cessão de direitos, a titularidade sobre o que ele criou pode ficar com ele. Por isso todo desenvolvimento externo precisa tratar, por escrito, a quem pertencem os direitos sobre o resultado.
Leia também: Mútuo conversível ou SAFE brasileiro | Dever fiduciário do conselho e governança de IA
Fontes
- Lei nº 9.279, de 14 de maio de 1996 (Planalto), Lei da Propriedade Industrial, art. 195, incisos XI e XII, e § 1º.
- Lei nº 9.609, de 19 de fevereiro de 1998 (Planalto), proteção da propriedade intelectual de programa de computador, arts. 2º e 3º.
Este conteúdo tem caráter informativo e não constitui opinião legal para caso concreto.
Comments are closed