MONOLITH LAW OFFICE+81-3-6262-3248Dias da semana 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Contrato que um Engenheiro Individual deve preparar antecipadamente para um projeto conjunto com uma empresa

IT

Contrato que um Engenheiro Individual deve preparar antecipadamente para um projeto conjunto com uma empresa

O nosso escritório, liderado por um ex-engenheiro de IT que agora é o advogado principal, não só recebe consultas legais de empresas, mas também de engenheiros. Um tipo comum de consulta é: “Como indivíduo, estava a avançar num novo negócio em conjunto com uma empresa, mas agora não consigo receber uma distribuição adequada da empresa”. Por exemplo, situações como as seguintes.

  1. Como engenheiro individual, estive envolvido desde o início no desenvolvimento interno de um novo sistema por uma empresa que não é necessariamente forte em IT
  2. O referido sistema está a ter um bom desempenho e as vendas estão a aumentar
  3. Pedi a distribuição de ações ou a distribuição de lucros com base nas vendas, mas a empresa não concordou com isso

Explicaremos o que um engenheiro individual deve considerar nestas circunstâncias, por que estas situações ocorrem e como podem ser prevenidas.

Os conflitos relacionados a negócios conjuntos podem ser prevenidos com um contrato

Primeiramente, para chegar a uma conclusão, prevenir tais situações é, na verdade, simples. A resposta é simples

Para se preparar para tais situações, basta celebrar antecipadamente um “Contrato de Negócio Conjunto” que inclua o seguinte conteúdo.

Isso é o que se conclui. No contrato de negócio conjunto, por exemplo, pode-se estabelecer as seguintes disposições:

  • O direito autoral do sistema em questão será compartilhado entre si e a empresa
  • Uma porcentagem das vendas será distribuída para si
  • Disposições sobre a transferência de ações

Se você projetar isso com o equilíbrio ideal e celebrar antecipadamente, isso será suficiente.

No entanto, na prática, a celebração de tais contratos tende a ser adiada, e é por isso que os problemas mencionados acima tendem a vir à tona facilmente.

  • Quando os problemas vêm à tona, qual é a situação com relação aos direitos?
  • Para criar um contrato de negócio conjunto antecipadamente, qual política deve ser seguida para o design?
  • No entanto, por que os problemas tendem a surgir quando o contrato ainda não foi celebrado?

Explicarei cada um desses pontos em ordem a seguir.

Atribuição do Código Fonte do Programa em Negócios Conjuntos

O direito autoral do código fonte do programa nem sempre é atribuído ao engenheiro individual.

Quando problemas como os acima mencionados vêm à tona, o maior “direito” que um engenheiro individual pode reivindicar contra a empresa é o direito autoral. O código fonte de um programa é uma “obra” sujeita a direitos autorais. E a atribuição dos direitos autorais do código fonte segue as seguintes regras:

  1. Em princípio, é atribuído à pessoa que escreveu o código
  2. Se a pessoa que escreveu o código está empregada numa empresa, sob certas condições, torna-se uma “obra de emprego” e é atribuída à empresa
  3. Se houver uma disposição sobre a atribuição de direitos autorais no contrato, segue-se essa disposição

Portanto,

  1. Em princípio, é atribuído ao engenheiro individual que escreveu o código
  2. O engenheiro individual não é um empregado da empresa, por isso não se estabelece uma obra de emprego
  3. Segue-se a disposição de atribuição no contrato, mas não existe um “contrato” escrito

Com base nisso, parece que os direitos autorais seriam atribuídos ao engenheiro individual. No entanto, se este conflito fosse levado a tribunal, o tribunal não necessariamente faria esse julgamento.

Além disso, se você está se perguntando se um contrato de desenvolvimento de sistema pode ser estabelecido sem um contrato escrito, explicamos isso em detalhes no artigo abaixo.

https://monolith.law/corporate/system-development-contract[ja]

Na ausência de um contrato, a decisão torna-se vaga

Embora não seja um caso de desenvolvimento de sistemas, houve um caso em que a propriedade dos direitos autorais foi disputada entre um designer individual que fez o design de um monumento a ser instalado numa estação e a empresa que encomendou o design. O Tribunal Superior de Tóquio, em 31 de maio de 2004 (Heisei 16),

  • Não havia um contrato escrito
  • O monumento em questão estava planeado para ser instalado na estação sob a direção da empresa desde o início, e nenhum outro uso foi considerado
  • A empresa pagou ao designer individual pelo seu trabalho

Com base nesses pontos, o tribunal reconheceu a transferência dos direitos autorais do designer individual para a empresa.

Assim, na ausência de um contrato escrito, a questão de se os direitos autorais foram transferidos para o contratante é determinada com base em várias circunstâncias, procurando a intenção razoável do contratante e do contratado. Em outras palavras, torna-se uma decisão muito “vaga”, sem regras claras. Por exemplo, a questão de “como é pago o preço pelo código fonte escrito” é geralmente tratada da seguinte maneira no contexto desta “vaga” decisão.

  • Se o pagamento é feito na forma de uma taxa mensal → é considerado o preço de um serviço total, incluindo manutenção, e especialmente quando o contratado é um indivíduo, é facilmente avaliado como um pagamento semelhante a um salário, tendendo a afirmar a transferência dos direitos autorais para o contratante
  • Se uma estimativa é obtida cada vez que uma atualização de versão é feita → é facilmente avaliado como o preço de fazer essa versão, tendendo a negar a transferência dos direitos autorais para o contratante

Quando um engenheiro individual é contratado por uma empresa numa forma de “empreendimento conjunto”, a remuneração é muitas vezes paga na forma de uma taxa mensal, e como resultado, há uma tendência para a transferência dos direitos autorais para a empresa ser facilmente afirmada. Além disso, pelo menos do ponto de vista do engenheiro individual, na ausência de um documento escrito, torna-se difícil dizer que “os direitos autorais estão claramente comigo”.

Estes pontos sobre a propriedade dos direitos autorais do código fonte são explicados em detalhe no seguinte artigo.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

Questões a serem estabelecidas num contrato de negócio conjunto

A razão fundamental para tais situações é a falta de um contrato prévio. Mesmo que se diga isso, pode parecer intuitivamente que “não é realista fazer um contrato com antecedência”, mas falaremos sobre isso mais tarde. Primeiro, vamos explicar sobre o contrato que deve existir.

Estipulações sobre direitos autorais

No contrato, como é evidente a partir da discussão acima, deve haver uma disposição sobre direitos autorais. Do ponto de vista do engenheiro individual, o maior risco de “desenvolver um sistema em forma de negócio conjunto com a empresa como indivíduo” é ser “cortado” após o projeto se tornar lucrativo.

Em outras palavras, mesmo que você tenha feito um contrato que diz “20% das vendas serão pagas ao engenheiro individual”, se o contrato em si for encerrado, você acabará não podendo obter lucro. Para evitar o término do contrato, é importante ter “direitos” do seu lado, e o mais importante desses “direitos” é o direito autoral. Sobre os direitos autorais,

  • Os direitos autorais pertencem ao engenheiro individual
  • Os direitos autorais são compartilhados entre a empresa e o engenheiro individual
  • Os direitos autorais pertencem à empresa, mas a empresa não pode exercer ou transferir esses direitos sem a permissão do engenheiro individual

Se você estabelecer tais disposições, do ponto de vista da empresa, se “cortar o engenheiro individual, não será possível continuar o negócio”, então você pode evitar ser “cortado” dessa maneira.

Além disso, para uma visão geral dos direitos autorais e do sistema de TI, consulte o artigo abaixo para uma explicação detalhada.

https://monolith.law/corporate/internet-technology-system-copyright-problem[ja]

Estipulações sobre remuneração

Além disso, é claro que também é necessário estabelecer a remuneração. Não se limitando a tais casos, quando se faz negócios em conjunto, é mais vantajoso para o lado que não tem vendas receber uma distribuição baseada nas vendas, não nos lucros. Em outras palavras, por exemplo,

  • A empresa pagará ao engenheiro individual ●% do lucro do negócio relacionado ao sistema em questão
  • A empresa pagará ao engenheiro individual ●% das vendas do negócio relacionado ao sistema em questão

Deve-se preferir o último. O engenheiro individual não pode entender com precisão as vendas geradas pela empresa, o valor de cada despesa, ou se essa despesa é realmente “para o negócio”. Quem recebe o dinheiro das vendas, paga as despesas, e gerencia e supervisiona o que é obtido com essas despesas, como pessoal, é a empresa. E nesse contexto, pode-se dizer que as vendas são as mais fáceis de entender. É vantajoso ter uma forma de pagamento que possa ser calculada simplesmente a partir do que é fácil de entender.

Estipulações sobre a transferência de ações

Além disso, você também pode solicitar a transferência de ações. No entanto, embora não detalhemos neste artigo, é difícil na prática para um “engenheiro individual subcontratado para trabalhar em um negócio conjunto” solicitar uma grande quantidade de ações, como dezenas de por cento. Se um estranho nessa posição tiver uma quantidade considerável de ações, será muito difícil na prática obter investimentos de VC ou IPO. Você deve negociar dentro de um alcance realista, como 5%.

Por que os contratos não são elaborados antecipadamente?

Num contrato relativo a um negócio conjunto, é importante esclarecer a relação contratual entre o engenheiro individual e a empresa.

Assim, a ausência de um contrato que inclua futuros pagamentos e outros aspectos de um “negócio conjunto” entre um engenheiro individual e uma empresa é uma situação muito “desvantajosa” para o engenheiro. É importante elaborar um contrato com antecedência, mas muitas pessoas parecem achar difícil fazer e concluir um contrato com antecedência.

Isso pode ser devido à diferença na percepção do que é um “negócio” entre a empresa e o indivíduo. Em primeiro lugar, a maioria dos conflitos relacionados a esses negócios conjuntos ocorre na seguinte ordem cronológica:

  1. A empresa e o engenheiro individual concordam em pagar uma remuneração, como “30.000 euros por mês”, para a vida do engenheiro individual, quando a empresa contrata o engenheiro para desenvolver um sistema para um novo negócio.
  2. A remuneração acima mencionada é ligeiramente aumentada à medida que o negócio começa a gerar lucro.
  3. O negócio continua a crescer, gerando milhões ou até bilhões de euros em receita para a empresa.
  4. Neste ponto, a quantia que o engenheiro individual recebe, como “50.000 euros por mês”, torna-se insignificante em comparação com o lucro que a empresa está ganhando, e também é barata em comparação com o valor que outra empresa receberia para assumir o sistema.
  5. A relação entre o engenheiro individual e a empresa se deteriora.

Do ponto de vista do engenheiro individual, é verdade que se ele não receber uma taxa mensal no estágio 1, isso causará problemas em sua vida. E no estágio 4, é verdade que a quantia de “50.000 euros por mês”, por exemplo, é insignificante em comparação com:

  1. O lucro que a empresa está ganhando
  2. O valor que outra empresa receberia se tivesse criado o sistema

Entretanto, fazer essa comparação simplesmente não é economicamente justo. Isso porque:

  1. No estágio 1, a empresa está fazendo um investimento antecipado, pagando salários para o engenheiro individual e o vendedor, para um negócio cuja receita é incerta.
  2. Se outra empresa tivesse criado o sistema, haveria provavelmente uma cláusula de transferência de direitos autorais, e não haveria discussão sobre a “distribuição de lucros com base na receita”.

Para ser franco, “se você recebeu uma compensação sem risco no estágio em que não se sabe se será lucrativo, não tem direito de pedir uma distribuição de lucros quando acaba sendo lucrativo”. Acredita-se que muitas das decisões do tribunal acabam concordando com essa avaliação e conclusão.

Resumo

Numa fase em que não se sabe se o negócio terá sucesso, gastar tempo a criar um contrato de joint venture ou a contratar um advogado para assumir os custos pode ser, de facto, um “risco”. Se o negócio falhar, esse tempo e custo tornam-se um “colapso de custos”.

No entanto, a estrutura básica de um negócio é que “aqueles que assumem o risco, se as coisas correrem bem, obterão lucros excedentes”. Do ponto de vista do engenheiro individual, mesmo numa fase em que “ainda não se sabe se será lucrativo”, se assumir o “risco” de incorrer em custos como tempo e dinheiro, poderá obter melhores resultados se o negócio for bem-sucedido do que se não tivesse assumido esse “risco”.

O contrato relativo a uma joint venture é inevitavelmente especializado. Para prevenir futuros conflitos e garantir os lucros que devem ser obtidos, é importante criar e celebrar um contrato que clarifique as relações contratuais, como por exemplo, solicitar a um advogado numa fase inicial.

Informações sobre a criação e revisão de contratos pela nossa firma

Na Monolis Law Firm, como uma firma de advocacia especializada em IT, Internet e negócios, oferecemos uma variedade de serviços, incluindo a criação e revisão de contratos, para as nossas empresas clientes e consultoras.

Para mais detalhes, por favor consulte a página abaixo.

https://monolith.law/contractcreation[ja]

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Retornar ao topo