Como cláusulas para desenvolvedores no exterior protegem o código

O contrato de desenvolvimento no exterior mais seguro trata a propriedade como uma cadeia de provas, não como uma frase que afirma que o cliente é dono do código. Uma cessão escrita e exigível importa, mas cobre apenas os direitos que o signatário realmente detém. Se um subcontratado não declarado escreveu um módulo, uma biblioteca antiga do fundador entrou no produto ou somente o fornecedor controla o repositório, até a cláusula de propriedade mais ampla pode deixar você com uma reivindicação em vez de software utilizável.

Este artigo oferece uma estrutura de redação para equipes comerciais e técnicas levarem à assessoria jurídica. Não é aconselhamento jurídico, e nenhum modelo pode escolher a lei aplicável, a condição trabalhista, o tratamento fiscal ou as medidas cabíveis para um país específico. O trabalho útil antes da revisão jurídica é identificar o código, as pessoas, as contas, as dependências, as provas e os deveres de saída que o contrato precisa cobrir. A assessoria pode então adaptar esses fatos aos locais onde o cliente, o fornecedor e os desenvolvedores atuam.

Como a cessão deve abranger todas as entregas

Use uma cessão presente de direitos definidos, apoiada por um dever de assistência adicional, em vez de depender de «obra feita sob encomenda» ou de uma promessa de cessão futura. Nos Estados Unidos, o artigo 204 do Título 17 do Código dos Estados Unidos determina que uma transferência de direitos autorais em geral deve ser escrita e assinada pelo titular. A Circular 30 do Escritório de Direitos Autorais dos Estados Unidos também explica por que uma obra encomendada não se enquadra automaticamente nessa figura: o trabalho de um contratado independente precisa entrar em uma das categorias legais e as partes devem concordar expressamente por escrito. Software personalizado comum pode não entrar nessas categorias, por isso o contrato deve conter uma cessão mesmo quando também usa linguagem de obra sob encomenda.

Defina «Entregas» de modo amplo o bastante para cobrir mais que os arquivos-fonte de produção. A definição deve incluir código-fonte, código-objeto, scripts, definições de infraestrutura, esquemas e migrações de banco de dados, testes, prompts de modelos e conjuntos de avaliação criados para o projeto, designs, documentação técnica, arquivos de compilação, instruções de implantação e alterações em qualquer desses itens. Vincule a definição aos escopos de trabalho, tickets, commits e outros registros escritos de tarefas para que um anexo esquecido não crie uma lacuna.

A concessão deve cobrir direitos autorais e outros direitos de propriedade intelectual transferíveis no mundo todo e por toda a duração desses direitos, inclusive renovações e prorrogações. Ela deve dar ao cliente o direito de usar, reproduzir, modificar, distribuir, exibir, executar, criar obras derivadas, comercializar, sublicenciar e transferir as entregas. A assessoria deve decidir como patentes, direitos sobre bancos de dados, direitos sobre topografias de circuitos e direitos semelhantes se aplicam ao projeto e às jurisdições. Uma cláusula que diga apenas «o cliente é dono de todo o produto do trabalho» pode expressar intenção, mas não responde quais direitos foram transferidos, quando isso ocorreu ou quais materiais estão incluídos.

Um ponto de partida útil para análise jurídica é:

O Desenvolvedor cede neste ato, de forma irrevogável, ao Cliente, desde a criação, todos os direitos, títulos e interesses sobre cada Entrega, incluindo todos os direitos autorais e outros direitos de propriedade intelectual transferíveis, por toda a duração desses direitos em todo o mundo. Na medida em que algum direito não possa ser cedido desde a criação, o Desenvolvedor o cede assim que a cessão se tornar juridicamente possível e concede ao Cliente uma licença exclusiva, irrevogável, perpétua, mundial, transferível, sublicenciável e integralmente quitada para exercer esse direito até que a cessão produza efeitos. O Desenvolvedor assinará documentos adicionais e praticará atos razoáveis necessários para confirmar, registrar ou fazer valer os direitos do Cliente.

Essa licença de apoio importa onde a lei local limita cessões antecipadas ou considera certos direitos intransferíveis. A assessoria também deve tratar dos direitos morais e de direitos pessoais semelhantes. O contrato pode exigir renúncia onde a lei permitir e, onde não permitir, o consentimento irrevogável do criador para não invocar esses direitos contra o uso autorizado do cliente. Não escreva uma renúncia absoluta presumindo que todos os países a reconhecerão.

Declare se a propriedade passa na criação, no pagamento ou na aceitação. Os clientes normalmente querem a transferência na criação, com disputas de pagamento tratadas como reivindicações contratuais. Os fornecedores podem pedir que a transferência dependa do pagamento integral. As duas posições podem ser negociadas, mas o silêncio é pior: uma equipe não deve descobrir durante uma rodada de investimento ou aquisição que uma solicitação de mudança não paga supostamente bloqueia a titularidade de todo o repositório.

A propriedade intelectual anterior exige lista e licença duradoura

Separe as novas entregas da propriedade intelectual anterior, pois a linguagem de cessão não pode absorver com segurança ferramentas que o fornecedor já possuía ou não tinha direito de transferir. A propriedade intelectual anterior inclui frameworks preexistentes, bibliotecas internas, modelos, geradores, utilitários, conhecimento técnico e material de terceiros que o fornecedor pretende incorporar às entregas ou usar para operá-las. O contrato deve exigir uma lista escrita antes do uso, não uma reserva vaga para «todos os materiais preexistentes».

A lista deve identificar cada item, seu titular, versão ou commit, termos de licença, finalidade, localização e se o sistema final pode ser mantido sem ele. Se o fornecedor disser que usa uma estrutura proprietária de implantação, pergunte se o cliente receberá o código-fonte da estrutura, apenas uma cópia executável ou acesso remoto controlado pelo fornecedor. Esses são riscos de dependência diferentes. Um sistema que só compila por meio da cadeia de ferramentas privada do fornecedor não é independente apenas porque o repositório da aplicação pertence ao cliente.

Para propriedade intelectual anterior aprovada, incorporada a uma entrega ou necessária ao seu uso, exija uma licença ampla o suficiente para o ciclo de vida esperado pelo cliente. Elementos comuns incluem licença perpétua, mundial, irrevogável, integralmente quitada, transferível e sublicenciável para usar, copiar, modificar, manter, distribuir e criar obras derivadas, com direitos para afiliadas, provedores de hospedagem, adquirentes, clientes e desenvolvedores substitutos conforme a necessidade do negócio. A assessoria deve comparar o alcance solicitado com a lei local e a autoridade real do fornecedor.

Defina uma consequência expressa para itens omitidos:

O Desenvolvedor não incorporará Materiais Anteriores sem que o Cliente os aprove por escrito e as partes os incluam no Anexo B antes da incorporação. Para qualquer Material Anterior incorporado sem essa aprovação, o Desenvolvedor concede ao Cliente a licença mais ampla prevista neste Contrato e substituirá, às suas custas, qualquer material que não tenha autoridade para licenciar, sem reduzir de forma relevante a funcionalidade, a segurança ou a facilidade de manutenção.

Esse texto incentiva a divulgação, mas não cria direitos que o fornecedor nunca teve. O dever de substituição e uma indenização adequada dão ao cliente uma medida contratual. A revisão técnica ainda precisa comparar a lista com o repositório e com a lista de materiais de software. Se o anexo do contrato disser «nenhum» enquanto a verificação de dependências encontra um namespace privado de pacotes, interrompa a aceitação e resolva a divergência.

Mantenha também os materiais do cliente em uma categoria própria. Especificações, dados, marcas, código existente, credenciais e regras de negócio fornecidos pelo cliente continuam sendo propriedade dele. Dê ao fornecedor uma licença limitada para usá-los somente na execução do projeto, proíba a reutilização para outros clientes e exija devolução ou exclusão na saída, sujeita a exceções restritas de retenção legal analisadas pela assessoria.

O controle do repositório deve existir desde o primeiro commit

Coloque o repositório oficial em uma organização controlada pelo cliente desde o início, com administradores do cliente, autenticação multifator obrigatória, branches protegidas e registro de cada colaborador. O direito contratual de receber o código no fim é mais fraco que a custódia contínua. Arquivos compactados entregues no final do projeto costumam omitir branches, tags, histórico de tickets, objetos de arquivos grandes, submódulos, configuração de implantação ou as versões exatas das dependências necessárias para recompilar.

O contrato deve nomear o sistema oficial e proibir trabalho relevante em repositórios não declarados. Exija que os desenvolvedores enviem o trabalho concluído na frequência acordada, preservem autoria e data dos commits, usem contas aprovadas pelo cliente e apresentem mudanças pelo processo de revisão acordado. Dê ao cliente acesso contínuo de leitura e exportação, além de acesso administrativo adequado ao seu modelo de segurança. O fornecedor pode manter as permissões necessárias para trabalhar sem ser a única parte capaz de recuperar o acesso.

Acesso ao repositório não é o mesmo que propriedade. Possuir uma cópia não prova que todos os colaboradores cederam direitos. Propriedade também não é o mesmo que controle operacional: uma cessão assinada não entrega ao cliente uma chave de assinatura ausente, uma conta de nuvem, um registro de pacotes ou um domínio. O contrato e a configuração técnica devem cobrir as duas distinções.

Peça à assessoria que torne concretas as falhas de acesso. O contrato pode tratar o bloqueio do acesso do cliente, a transferência do trabalho para um repositório não aprovado, a exclusão do histórico ou a retenção de credenciais após aviso como violações materiais. Ele deve permitir que o cliente faça backups e exportações durante todo o projeto. Evite texto que permita ao fornecedor desativar repositórios ou sistemas de produção sempre que alegar uma disputa de pagamento; a assessoria pode redigir um processo de disputa e preservar direitos sem permitir que a operação vire refém.

O responsável pelo projeto deve conseguir executar esta verificação de custódia em qualquer marco:

Clonar o repositório com uma conta do cliente em um ambiente limpo.
Buscar todas as branches, tags, submódulos e objetos de arquivos grandes e comparar o resultado com o sistema oficial.
Compilar e testar a partir das instruções registradas usando credenciais fornecidas pelo cofre de segredos aprovado.
Relacionar cada colaborador ativo a um contrato assinado e cada dependência fora do padrão à lista de materiais aprovada.
Exportar tickets, registros de versões, definições de build, metadados de pacotes e configurações necessárias sem acesso exclusivo do fornecedor.

Uma compilação com falha nem sempre significa código ruim. Muitas vezes ela revela um token de registro não documentado, um pacote publicado na conta pessoal de um contratado ou uma etapa manual em produção. Essas falhas mostram por que os testes de custódia pertencem ao período de execução, não ao último dia do fornecedor.

A aprovação de código aberto deve seguir a licença real

Não proíba todo código aberto por impulso. Exija divulgação, regras de aprovação baseadas na licença e no uso, uma lista de materiais de software, avisos preservados e o dever de cumprir as licenças realmente aplicáveis. Uma proibição total parece protetora, mas aplicações atuais dependem de pacotes e cadeias de ferramentas de código aberto. Ela costuma produzir declarações falsas ou esconder dependências.

O contrato deve distinguir ferramentas de desenvolvimento de componentes enviados, distribuídos, modificados, vinculados, incorporados a um dispositivo ou usados para prestar um serviço pela rede. Esses fatos podem mudar as obrigações. A Open Source Initiative explica que os requisitos de copyleft variam e que a simples distribuição de uma obra ao lado de outra não coloca automaticamente a segunda sob a licença copyleft. Ela também observa que a GNU Affero General Public License pode exigir oferta do código-fonte quando usuários interagem com software modificado pela rede. A assessoria precisa analisar o texto de cada licença relevante e o uso do produto, em vez de rotular todo componente aberto como «permissivo» ou «viral».

Exija que o fornecedor mantenha um inventário legível por máquina com pelo menos nome do componente, versão, origem, aviso de direitos autorais, identificador da licença, estado de modificação e localização no produto. Identificadores SPDX ajudam na consistência, mas um identificador não é análise jurídica. O inventário também deve registrar se o pacote aparece somente no desenvolvimento, entra em um artefato distribuído ou é usado em um serviço hospedado.

Defina uma política de aprovação que a equipe técnica consiga seguir. Por exemplo, o contrato pode permitir licenças listadas baseadas em avisos se o fornecedor preservar os avisos exigidos, exigir aprovação escrita para termos recíprocos ou de código disponível e proibir código sem licença identificada. Deixe a assessoria escolher categorias e exceções. «Disponível publicamente» não significa licenciado, e um repositório sem licença normalmente não dá a terceiros permissão geral para copiar.

A especificação ISO/IEC 5230 da OpenChain descreve requisitos para um programa de conformidade com licenças de código aberto. Ela sustenta o ponto de processo relevante para o contrato: alguém precisa responder pela política, analisar as licenças identificadas, manter registros e corrigir descumprimentos. Uma garantia do fornecedor dizendo «cumprimos as regras de código aberto» oferece pouca prova operacional se a entrega não contém inventário, avisos, materiais de oferta de fonte quando exigidos e um dever de correção.

Exija aviso rápido se o fornecedor encontrar um conflito. A medida deve permitir ao cliente escolher, quando comercialmente razoável, entre obter direitos suficientes, substituir o componente, alterar a entrega para remover o conflito ou receber reembolso pelo trabalho afetado. Qualquer substituição deve preservar a funcionalidade, a segurança e a facilidade de manutenção acordadas. A assessoria pode coordenar essa medida com garantias de propriedade intelectual, indenizações, limites de responsabilidade e exclusões.

Todo subcontratado precisa da mesma cadeia de titularidade

Responsabilize o fornecedor contratado por todas as pessoas e entidades que tocam o trabalho, incluindo afiliadas, empresas de alocação, freelancers e subcontratados de níveis inferiores. A aprovação deve ocorrer antes do acesso ou da contribuição, com nome legal da pessoa, empregador, país de trabalho, função e escopo de acesso informados ao cliente. Esses dados afetam propriedade intelectual, confidencialidade, privacidade, controles de exportação, sanções e revisão de segurança.

O fornecedor deve obter de cada colaborador termos escritos pelo menos tão protetores quanto o contrato principal em matéria de cessão, confidencialidade, materiais anteriores, código aberto, segurança, uso de dados e entrega. «O fornecedor continua responsável» é necessário, mas não transfere sozinho os direitos autorais de um freelancer ao cliente. Exija que o fornecedor mantenha contratos assinados pelos colaboradores e forneça cópias ou outras provas das concessões relevantes mediante solicitação, com ocultação lícita de dados pessoais sem relação com o projeto.

A cadeia limpa costuma seguir um de dois caminhos documentados: cada pessoa cede ao fornecedor e o fornecedor cede ao cliente, ou cada pessoa cede diretamente ao cliente enquanto o fornecedor administra a documentação. A assessoria deve escolher um caminho que funcione sob as leis aplicáveis. Misturar caminhos sem um registro dificulta a diligência porque ninguém sabe qual documento cobre qual commit.

Não aceite um plano de correção retroativa como processo normal. Ex-colaboradores podem se recusar a assinar, desaparecer ou pedir novo pagamento quando um prazo de investimento cria pressão. Vincule as credenciais do repositório à conclusão dos documentos de integração e desative o acesso quando alguém sair. O registro de colaboradores deve corresponder ao histórico do repositório, às revisões de código e à equipe faturada.

As obrigações repassadas também precisam de um mecanismo de execução. O fornecedor deve garantir que obteve os direitos exigidos, continuar responsável pelos atos dos subcontratados e corrigir lacunas às suas custas. A assessoria pode decidir se o cliente precisa de direitos diretos de execução, formulários de cessão anexos, direitos de auditoria e indenização por reivindicações de propriedade intelectual de terceiros.

A aceitação testa a qualidade sem mudar a propriedade em silêncio

Defina aceitação como teste das entregas acordadas, não como o evento que decide por acidente o que o cliente possui. Um escopo de trabalho deve listar critérios objetivos de aceitação, prazo de análise, processo de notificação de rejeição, prazos de correção, novos testes e tratamento de defeitos menores. Também deve dizer o que acontece se o cliente usar uma entrega em produção ou não responder no prazo.

Evite «a critério do Cliente» como único padrão. Isso convida à disputa, não dá à equipe de entrega um objetivo reproduzível e pode ser difícil de administrar entre fusos horários. Evite também aceitação automática depois de um silêncio muito curto. A análise não começa até o fornecedor entregar código, documentação, provas de teste, instruções de compilação, credenciais, inventários e outros materiais exigidos.

Uma matriz de aceitação pode ligar palavras jurídicas a provas observáveis:

A integridade do fonte passa quando um clone limpo compila a versão marcada; a falha gera rejeição e correção.
A cadeia de direitos passa quando o registro de colaboradores corresponde ao histórico de commits; lacunas exigem documentos ou código substituto.
A conformidade das dependências passa quando a lista de materiais e os avisos correspondem à versão; a falha exige correção, substituição ou exceção aprovada.
Segurança e qualidade passam quando os testes acordados produzem resultados de sucesso registrados; a falha gera correção e novo teste.
A operação passa quando o cliente implanta no ambiente acordado seguindo instruções escritas; a falha gera rejeição e entrega assistida.

Mantenha marcos de pagamento, aceitação, garantia e titularidade em cláusulas separadas com referências cruzadas deliberadas. Uma estrutura comum paga uma parte na entrega do marco e outra na aceitação, enquanto a titularidade passa na criação ou no pagamento conforme a regra negociada. O período de garantia então cobre defeitos descobertos depois da aceitação. Se as partes querem outro arranjo, escrevam isso em vez de deixar uma fatura sugeri-lo.

O controle de mudanças pertence a esta parte porque ambiguidade de escopo vira ambiguidade de propriedade. Cada ordem de mudança deve identificar entregas novas ou alteradas, critérios de aceitação, preço, prazo e materiais anteriores ou de terceiros acrescentados. Aprovação por e-mail pode bastar para a operação se o contrato principal a reconhecer, mas concessões de direitos e regras locais de assinatura merecem análise jurídica.

Nunca deixe a aceitação renunciar a defeitos ocultos de titularidade, código malicioso, dependências não declaradas, violações de confidencialidade ou fraude. Aceitação técnica significa que a versão entregue passou nos testes declarados. Ela não deve certificar fatos que a equipe de testes do cliente não poderia descobrir razoavelmente.

Os deveres de entrega devem ser testáveis antes do término

Escreva a entrega como obrigação recorrente com um pacote final de saída, não como promessa de «cooperar» depois do término. O cliente deve receber código atualizado, documentação, controle de contas, materiais de compilação e implantação, exportações de dados, registros de dependências e ajuda razoável de transição em marcos definidos. A entrega regular reduz o que alguém pode reter quando a relação termina mal.

Liste os ativos operacionais que as cláusulas de código-fonte costumam esquecer: contas de nuvem e hospedagem, definições de integração contínua, registros de artefatos e pacotes, certificados de assinatura, controle de domínio e DNS, contas de distribuição de aplicativos, regras de monitoramento, procedimentos de backup, estado da infraestrutura, inventários de segredos, manuais operacionais, decisões de arquitetura, regras de dados de teste, configuração de modelos e contatos de suporte do fornecedor. O cliente pode não ser dono de toda conta de terceiro, mas o contrato deve identificar quais contas serão transferidas, quais precisam ser substituídas e quem paga.

Credenciais exigem cuidado. Não exija senhas em documento ou repositório. Exija que segredos fiquem em um gerenciador aprovado pelo cliente, garanta que o cliente tenha recuperação administrativa e determine a rotação na entrega. Contas pessoais não devem possuir recursos de produção. Quando uma plataforma não permite transferir uma conta, o fornecedor deve ajudar a migrar o recurso para uma conta controlada pelo cliente e verificar o resultado.

Defina prazo, formato e assistência. Uma cláusula aplicável informa quando o fornecedor deve entregar o pacote atualizado depois de uma notificação, quantas horas de suporte de transição estão incluídas, a tarifa da ajuda extra, quem pode ser o fornecedor substituto e por quanto tempo os registros devem ser preservados. Ela deve proibir exclusão ou interferência de acesso durante disputa ativa, preservando direitos legais de suspensão que a assessoria redija de modo restrito.

A assistência de término deve funcionar para expiração, conveniência, violação, insolvência e falha de equipe do fornecedor. O depósito de código-fonte pode ajudar quando o cliente não consegue manter uma cópia ativa, principalmente em produtos licenciados, mas substitui mal o acesso contínuo ao repositório em desenvolvimento personalizado. Depósitos ficam desatualizados, condições de liberação geram disputa e um arquivo pode não conter o conhecimento operacional necessário para implantar.

Teste a saída enquanto a relação estiver normal. Peça a um engenheiro do cliente ou a uma equipe substituta independente para compilar, implantar, reverter, restaurar um backup, trocar uma credencial e publicar uma pequena mudança sem acesso privado do fornecedor. Registre lacunas como defeitos da entrega. A cláusula ganha sentido quando a prova mostra que outra equipe competente consegue operar o sistema.

Garantias e medidas devem cobrir falhas de procedência

Exija garantias específicas de que o fornecedor tem autoridade para celebrar o contrato, possui ou controla os direitos concedidos, obteve cessões dos colaboradores, divulgou materiais anteriores e de terceiros e não inseriu conscientemente código que viole outra obrigação. Evite uma promessa impossível de que o software jamais infringirá qualquer direito em nenhum lugar. Garantias precisas produzem diligência melhor e dão à assessoria fatos mais claros para distribuir o risco.

Uma indenização de propriedade intelectual deve indicar quais reivindicações de terceiros cobre, quem controla a defesa, como funciona o consentimento para acordos, que cooperação é exigida e quais exclusões se aplicam. Exclusões comuns podem tratar de materiais fornecidos pelo cliente, alterações não autorizadas do cliente ou combinações que o fornecedor não forneceu nem orientou. A assessoria deve garantir que as exclusões não eliminem a cobertura das integrações previstas do sistema.

As medidas devem reparar a posição do cliente, não apenas produzir uma discussão sobre perdas e danos. Em uma alegação de violação ou lacuna de titularidade, o fornecedor pode ter de garantir direitos contínuos, substituir ou alterar o material afetado, ajudar na migração e devolver valores se não existir correção razoável. Para uma cessão ausente de colaborador, a correção pode ser obter a assinatura ou substituir o código por outro criado de forma independente e com procedência documentada.

Coordene essas cláusulas com os limites de responsabilidade. Se o limite geral equivale a uma pequena parte do custo do projeto e se aplica a toda violação de propriedade intelectual, confidencialidade, dados e acesso, as proteções detalhadas podem ter pouca força econômica. Isso não significa que cada obrigação precise de responsabilidade ilimitada. A assessoria deve negociar limites, limites maiores ou exclusões com base na exposição real e no seguro disponível.

Direitos de auditoria devem ser direcionados. O cliente geralmente precisa de registros que provem cessões dos colaboradores, conformidade de dependências, custódia do repositório e exclusão ou devolução de materiais do cliente. Raramente precisa de acesso irrestrito a sistemas sem relação com o projeto ou a informações de outros clientes. Defina aviso, frequência, confidencialidade, escopo e quem paga quando uma auditoria encontra violação material.

A lei aplicável não substitui a análise jurídica local

Escolha de forma deliberada a lei aplicável, o foro, o processo de disputa e o idioma, mas espere que regras locais obrigatórias sobrevivam a essa escolha. Uma cláusula de lei da Califórnia não decide automaticamente se um desenvolvedor em outro país é empregado, pode ceder direitos futuros, pode renunciar a direitos morais ou precisa receber remuneração específica. A assessoria das jurisdições relevantes deve analisar o modelo real de colaboradores, não só o contrato principal entre cliente e fornecedor.

Mapeie todos os países relevantes: onde as entidades do cliente e do fornecedor foram constituídas, onde cada colaborador trabalha, onde dados regulados são acessados e onde a execução pode ser necessária. Depois faça perguntas direcionadas à assessoria local. Direitos autorais futuros podem ser cedidos? A cessão exige redação específica, pagamento separado, reconhecimento ou registro? Quais direitos pessoais não podem ser renunciados? O tribunal escolhido pode impor medida efetiva ao fornecedor ou aos colaboradores? Regras trabalhistas mudam a propriedade apesar dos rótulos contratuais?

Use um idioma contratual prevalecente e defina a função das traduções. Uma tradução de cortesia ajuda os colaboradores a entender deveres, mas o contrato deve dizer qual versão prevalece onde isso for permitido. Torne visível a autoridade de assinatura das duas entidades. Assinaturas eletrônicas podem funcionar, mas a assessoria deve confirmar as formalidades para a transferência e a jurisdição relevantes.

O desenvolvimento internacional também envolve confidencialidade, proteção de dados, segurança, controles de exportação, sanções e regras setoriais. Esses assuntos merecem anexos e orientação próprios. Não os coloque todos na cláusula de propriedade intelectual supondo que o projeto ficou coberto. Sistemas de saúde, por exemplo, acrescentam questões de dados e regulação que a linguagem de propriedade não responde.

A SaaS Production coordena engenheiros experientes na Califórnia, no Cazaquistão e na Europa Oriental, por isso tratamos o registro de colaboradores, o repositório controlado pelo cliente e a entrega testada como trabalho do projeto, não como papelada guardada para o encerramento. Esse hábito operacional não substitui a assessoria local. Ele dá fatos precisos à assessoria e provas ao cliente enquanto as pessoas que criaram o sistema ainda estão disponíveis.

Antes da assinatura, a assessoria deve conseguir seguir uma cadeia simples: cada colaborador está identificado, os direitos de cada um chegam à parte contratante, a cessão escrita chega ao cliente, todo componente retido aparece em uma lista com direitos de licença suficientes e cada repositório e ativo operacional tem um responsável. Antes do pagamento final, o cliente deve repetir o percurso contra a versão real. Se os documentos e a compilação divergirem, corrija a compilação ou os documentos antes que a equipe se disperse.

Perguntas Frequentes

Obra sob encomenda basta para desenvolvedores no exterior?

Em geral, não. Nos Estados Unidos, o trabalho encomendado a contratados entra apenas em categorias legais restritas e exige acordo escrito expresso. Use uma cessão presente assinada como mecanismo principal e peça à assessoria local para adaptá-la a cada país.

Quando a propriedade do código-fonte deve passar ao cliente?

O contrato deve dizer se os direitos passam na criação, no pagamento ou na aceitação. Clientes costumam preferir a criação e fornecedores podem vincular ao pagamento, mas é mais importante declarar a regra com clareza e coordená-la com disputas de faturas.

O que é propriedade intelectual anterior em um contrato de software?

É o material que o fornecedor ou outra parte possuía antes do projeto, como bibliotecas internas, modelos e ferramentas de implantação. Liste cada item e dê ao cliente direitos suficientes para operar, alterar, transferir e manter o sistema.

O cliente deve controlar o repositório de código-fonte?

O cliente deve controlar o repositório oficial e a recuperação administrativa desde o primeiro commit. A custódia não prova direitos autorais, mas impede que somente o fornecedor consiga acessar ou reconstruir o sistema atual.

Um contrato pode proibir código aberto?

Pode, mas uma proibição total costuma piorar a divulgação em vez de limpar o software. Uma cláusula melhor exige inventário, aprovação por licença, avisos, provas de conformidade e substituição ou correção de componentes incompatíveis.

Como subcontratados afetam a propriedade do código?

Cada subcontratado acrescenta um elo à cadeia de titularidade. Exija aprovação prévia, registro de colaboradores, obrigações escritas equivalentes e prova de que os direitos de cada pessoa chegam ao fornecedor ou ao cliente antes do acesso.

Aceitar o software prova que ele pertence ao cliente?

Não. A aceitação mostra que a entrega passou nos testes; a propriedade depende da lei aplicável e dos documentos assinados. Separe aceitação, pagamento, garantias e titularidade para que um prazo perdido não resolva os quatro assuntos.

O que uma cláusula de entrega de software deve incluir?

Ela deve cobrir repositórios, instruções de compilação e implantação, documentação, registros de pacotes, contas, exportações, rotação de segredos, certificados, manuais e ajuda de transição. Teste uma compilação e publicação sem acesso exclusivo do fornecedor antes do último marco.

Escolher a lei dos EUA resolve questões de propriedade no exterior?

Não por si só. Regras obrigatórias do país de trabalho podem afetar cessões futuras, direitos morais, situação trabalhista, pagamento, assinaturas e medidas. Faça perguntas específicas à assessoria local sobre a estrutura real.

Que provas a assessoria deve analisar antes do pagamento final?

Ela deve comparar documentos assinados e listas de materiais anteriores com o histórico do repositório e o inventário da versão. A equipe técnica também deve provar que um ambiente controlado pelo cliente consegue compilar, implantar e operar a versão aceita.