Contabilidade e assessoria empresarial
Contratos de Licenciamento, Cessão e Desenvolvimento de Software sob Encomenda
Sua empresa contratou ou desenvolveu um software. Mas está claro quem é dono do código, quem pode utilizá-lo e quais direitos existem sobre as customizações e melhorias futuras?
- 01Software-base?
- 02Framework da software house?
- 03Customizações?
- 04Código-fonte?
- 05Repositório?
- 06Dados inseridos?
- 07Documentação?
- 08Conta cloud e domínio?
- 09Componentes Open Source?
Pagar pelo desenvolvimento não significa automaticamente adquirir todo o software.
Software é um ativo estratégico para muitas empresas.
Pode estar no centro de:
- Operações
- Vendas
- Atendimento
- Logística
- Gestão
- Análise de dados
- Produtos digitais
- Plataformas SaaS
Mas contratar desenvolvimento ou pagar por uma licença não responde automaticamente:
- ?Quem é titular do software?
- ?Quem pode modificá-lo?
- ?Quem pode reutilizar o código?
- ?Quem fica com as customizações?
- ?O cliente pode sublicenciar?
- ?O fornecedor pode utilizar a mesma solução em outros projetos?
Essas questões precisam ser definidas contratualmente.
Licenciamento, cessão e desenvolvimento são operações diferentes
Esse é o primeiro ponto.
Licenciamento
O titular mantém os direitos sobre o software e autoriza o uso dentro de determinadas condições.
o titular continua dono
Cessão
Existe transferência de direitos patrimoniais conforme o escopo definido no contrato.
direitos mudam de mãos
Desenvolvimento sob Encomenda
Uma parte contrata outra para criar software ou funcionalidades específicas.
alguém cria para alguém
O erro começa quando essas três situações são tratadas como se fossem iguais
Não são.
- Um cliente pode pagar pelo desenvolvimento e ainda assim receber apenas uma licença.
- Pode também receber direitos sobre parte do projeto.
- Ou pode haver cessão mais ampla.
Tudo depende do contrato.
Pagar pelo desenvolvimento não significa automaticamente adquirir todo o software
Esse é um dos conflitos mais comuns.
“eu paguei, então o código é meu”.
“eu desenvolvi, então posso reutilizar”.
Se o contrato não resolve essa questão, surge disputa. Por isso, titularidade precisa ser definida antes do início do projeto.
O que exatamente está sendo contratado?
Pode ser:
Desenvolvimento de software completo possui risco diferente de pequena customização O contrato precisa refletir a dimensão real do projeto.
O que é um Contrato de Licenciamento de Software?
É o instrumento pelo qual o titular autoriza terceiro a utilizar determinado software dentro de limites definidos. Monte a licença e veja a cláusula se formar.
Usuários
Afiliadas, controladas e coligadas
Prazo
Exclusividade
O cliente poderá sublicenciar para
A titularidade permanece com o licenciante O cliente recebe direito de uso. Não propriedade automática.
SaaSEsse é o modelo comum em SaaS
O cliente acessa a plataforma.
Paga:
- mensalidade;
- assinatura;
- licença.
Mas normalmente não recebe:
- código-fonte;
- repositório;
- titularidade.
O contrato precisa deixar isso claro.
UsuáriosLicença pode ser limitada por usuários
Por exemplo:
- cinco usuários;
- cinquenta usuários;
- usuários ilimitados.
Essa regra precisa acompanhar o modelo comercial.
Uso além do contratado pode gerar:
- cobrança adicional;
- descumprimento.
Mas a métrica precisa ser objetiva.
Não deve ser ambígua.
Empresa e grupoLicença também pode ser limitada por empresa
Uma sociedade contrata.
Mas o grupo inteiro pode querer usar.
Isso precisa estar definido.
Afiliadas estão incluídas?
Controladas?
Coligadas?
Não se deve presumir.
TerritórioTerritorialidade também pode ser relevante
Dependendo do software.
Especialmente em:
- licenças internacionais;
- distribuição.
Algumas soluções podem ter restrições por país.
O contrato precisa refletir isso.
PrazoPrazo também é fundamental
A licença pode ser:
- mensal;
- anual;
- determinada;
- por prazo indeterminado.
Isso precisa conversar com:
- renovação;
- cancelamento.
Em SaaS, renovação automática pode existir.
Mas precisa estar clara.
Especialmente em contratos B2B de longo prazo.
ExclusividadeLicença exclusiva é diferente de não exclusiva
Na maioria dos softwares comerciais:
a licença é não exclusiva.
O fornecedor pode atender vários clientes.
Mas em projetos específicos pode existir exclusividade.
Isso precisa ser delimitado.
Exclusividade ampla pode impedir o fornecedor de trabalhar em determinado mercado.
Por isso, deve ser negociada com cuidado.
Exclusividade pode ser limitada a:
- setor;
- território;
- funcionalidade.
Isso pode ser mais equilibrado.
SublicenciamentoSublicenciamento também precisa ser tratado
O cliente poderá permitir que terceiros utilizem?
Por exemplo:
- franqueados;
- distribuidores;
- prestadores.
Isso deve estar no contrato.
Caso contrário, pode surgir uso além do escopo.
On-PremiseSoftware On-Premise possui outra lógica
Nesse modelo, o software pode ser instalado na infraestrutura do cliente.
Isso pode aumentar acesso técnico.
Mas não necessariamente transfere titularidade.
A licença continua podendo ser restrita.
Pode existir:
- número de instalações;
- servidores autorizados.
Também:
- limitações de cópia.
O contrato precisa refletir a arquitetura.
Código-fonteCódigo-fonte normalmente exige tratamento específico
Receber acesso ao software não significa receber:
- código-fonte.
Se houver entrega do código, isso precisa estar expresso.
Pode ocorrer em:
- cessão;
- licença específica.
Ou em escrow.
Cada situação produz efeito diferente.
EscrowCódigo-fonte em Escrow pode ser útil em contratos críticos
Quando o cliente depende fortemente do sistema.
Pode temer:
- encerramento do fornecedor;
- descontinuidade.
Nesse caso, o código pode ser depositado com terceiro.
Só é liberado em eventos específicos.
Isso protege:
- continuidade do cliente;
- segredo do fornecedor.
Não é necessário em todo projeto.
Mas pode ser relevante em software crítico.
O que é uma Cessão de Software?
É a transferência de direitos patrimoniais dentro do escopo definido contratualmente.
Nesse caso, a lógica muda. O cliente pode passar a controlar economicamente o ativo. Mas a cessão precisa ser precisa.
É necessário identificar:
- qual software;
- qual versão.
Também:
- documentação;
- código;
- módulos.
O contrato precisa responder:
o que exatamente está sendo transferido?
Background IP precisa ser separado
Esse é um dos pontos mais importantes.
Uma software house pode já possuir:
- frameworks;
- bibliotecas;
- componentes próprios.
Esses elementos podem existir antes do projeto.
Se o cliente contrata uma customização, isso não significa necessariamente que recebe todos esses componentes anteriores.
Por isso, é útil separar:
Tecnologia pré-existente.
Aquilo que foi criado especificamente durante o projeto.
Sem essa separação, a cessão pode ficar excessivamente ampla
Ou excessivamente restrita.
O fornecedor pode querer preservar:
- framework;
- ferramentas internas.
O cliente pode querer controlar:
- funcionalidades exclusivas;
- customizações específicas.
O contrato precisa equilibrar.
Desenvolvimento sob Encomenda exige essa definição desde o início
O projeto como um quadro: o que precisa estar definido em cada coluna antes de virar conflito.
Antes do desenvolvimento, o contrato precisa definir:
A empresa contrata:
- freelancer;
- software house;
- desenvolvedor.
O objetivo é criar solução específica.
- escopo;
- entregáveis;
- titularidade.
Também:
- prazo;
- remuneração;
- homologação.
Sem isso, o projeto pode virar uma sucessão de expectativas diferentes.
Escopo precisa ser objetivo
“Desenvolver um sistema completo”
é muito genérico.
É melhor detalhar:
- funcionalidades;
- módulos;
- integrações;
- plataformas.
Isso pode estar em:
- anexo técnico;
- backlog aprovado.
O contrato comercial pode remeter a documentação técnica.
Isso melhora clareza.
Mudanças de escopo precisam ter procedimento
Software muda durante o projeto.
Cliente pede:
“aproveita e coloca essa funcionalidade”.
Depois:
“já estava incluída”.
Isso gera conflito.
Change Request pode ajudar.
Pode definir:
- nova funcionalidade;
- impacto de prazo;
- custo.
Isso melhora governança.
Não significa burocratizar cada pequeno ajuste.
Mas evitar escopo infinito.
Método Ágil não elimina necessidade de contrato
Projetos podem utilizar:
- Scrum;
- Kanban.
Nesse caso, escopo pode evoluir.
Mas ainda precisa existir regra sobre:
- orçamento;
- prioridades;
- aprovação.
“Projeto ágil” não significa:
“tudo está incluído”.
Contrato e metodologia precisam conversar.
Critérios de aceite também são importantes
Quando uma funcionalidade é considerada entregue?
Pode existir:
- ambiente de homologação;
- prazo para testes.
O cliente pode apontar erros.
Mas precisa diferenciar:
Bug
Funcionalidade não atende especificação.
Nova Funcionalidade
Mudança do escopo.
Essa distinção evita conflito.
Garantia de correção também pode ser prevista
Por determinado período.
Mas não deve ser confundida com manutenção eterna.
Depois da garantia, suporte pode ser:
- contratado;
- cobrado separadamente.
Isso precisa estar claro.
Manutenção corretiva e evolutiva são diferentes
Corretiva
Corrige falhas.
Evolutiva
Adiciona ou altera funcionalidades.
Um contrato pode incluir uma e não outra.
Não se deve presumir que mensalidade de suporte inclui desenvolvimento ilimitado.
SLA também pode ser necessário
Principalmente em software crítico.
Pode definir:
- horário de suporte;
- tempo de resposta.
Também:
- níveis de criticidade.
SLA não significa garantia absoluta de disponibilidade.
Deve refletir capacidade real do fornecedor.
Prometer 100% de disponibilidade é tecnicamente arriscado.
Melhor definir níveis realistas.
Hospedagem também precisa ser definida
Quem hospeda?
- fornecedor;
- cliente;
- terceiro.
Isso impacta:
- custo;
- segurança.
Também:
- disponibilidade;
- backup.
Contrato precisa saber quem é responsável por quê.
Backup não deveria ser presumido
Pode existir:
- frequência;
- retenção.
Isso precisa ser compatível com criticidade.
Continuidade também pode ser tratada
Especialmente em sistemas essenciais.
Plano de contingência pode existir.
Mas não precisa fazer parte de qualquer projeto simples.
Proporcionalidade é importante.
Bug ou nova funcionalidade?
Classifique os chamados. Essa distinção decide garantia, pagamento e prazo.
Titularidade das customizações é uma das cláusulas mais importantes
Decida antes: quem fica com o que é criado, o que vem de terceiros e o que é Open Source.
Quem fica com a customização?
Cliente pede:
- novo módulo;
- relatório específico.
Quem fica com isso?
Existem várias possibilidades.
Pode ser:
- cliente;
- fornecedor.
Ou titularidade dividida conforme componentes.
Não existe resposta universal.
O importante é decidir antes.
Customização exclusiva pode justificar preço diferente
Se o fornecedor não puder reutilizar.
Isso tem valor econômico.
Por isso, exclusividade precisa ter contrapartida.
Uma empresa não deveria transferir indiscriminadamente toda capacidade técnica sem precificar.
Do outro lado, cliente pode legitimamente exigir exclusividade sobre desenvolvimento estratégico.
Negociação precisa refletir isso.
Inventário de dependências
O que o seu software usa de terceiros?
0%
Melhorias futuras também precisam ser tratadas
O fornecedor atualiza o software-base.
O cliente recebe a melhoria?
Depende da licença.
Pode estar incluída em:
- assinatura;
- manutenção.
Ou ser cobrada separadamente.
Isso precisa estar claro.
O cliente também pode desenvolver melhoria interna
Se possui acesso ao código.
Quem será titular?
Novamente, depende do contrato.
Não se deve deixar para discutir depois.
Integrações com terceiros exigem atenção
Software pode integrar:
- APIs;
- gateways;
- ERPs.
O fornecedor não controla todos esses serviços.
Se a API de terceiro muda, o sistema pode ser afetado.
O contrato precisa distribuir responsabilidade de forma realista.
Não faz sentido responsabilizar integralmente o desenvolvedor por indisponibilidade de terceiro fora de seu controle.
Mas também pode existir obrigação de adaptação contratada.
Isso precisa ser definido.
Software de terceiros precisa ser identificado
Pode existir:
- biblioteca;
- SDK;
- banco de dados.
Esses componentes possuem suas próprias licenças.
O cliente precisa saber quando existe dependência relevante.
Especialmente antes de comprar ou receber cessão do sistema.
Open Source também precisa ser tratado
Não significa:
“é grátis e sem regra”.
Existem diversas licenças.
Algumas possuem obrigações específicas.
Por isso, a software house precisa saber quais componentes utiliza.
Cliente também pode exigir inventário em projetos críticos.
Isso aparece em Due Diligence.
Software proprietário não significa software escrito 100% do zero
Pode utilizar componentes de terceiros legitimamente.
O importante é:
- licenças serem compatíveis;
- dependências serem conhecidas.
Código sem contexto pode ser pouco útil
Monte o pacote que precisa chegar às mãos da empresa.
Modelo do contrato
Documentação técnica também precisa ser tratada
Pode incluir:
- arquitetura;
- manual de implantação;
- documentação de API.
A cessão do software inclui documentação?
A licença inclui acesso?
Isso precisa ser definido.
Código sem documentação pode ser difícil de manter.
Em cessão completa, essa questão é especialmente relevante.
Repositório precisa ser entregue quando aplicável
Se existe cessão com entrega técnica.
Pode envolver:
- GitHub;
- GitLab;
- outro sistema.
O contrato pode prever:
- transferência;
- exportação.
Também:
- histórico de versões.
Isso melhora continuidade.
Mas se a operação é apenas licença SaaS, isso pode não fazer sentido.
O contrato precisa refletir o modelo real.
Credenciais e ambientes precisam ser organizados
Pode existir:
- produção;
- homologação.
Quem controla?
O cliente precisa ter acesso administrativo?
Depende da arquitetura.
Isso precisa ser definido.
Não se deve descobrir no encerramento que todas as contas estão em nome pessoal do desenvolvedor.
Governança começa desde o início.
Propriedade dos dados não é propriedade do software
De quem é?
Dados, software e resultados são ativos diferentes.
camada 1 · ConfidencialidadeConfidencialidade também é central
O fornecedor pode receber:
- dados;
- processos.
O cliente pode receber:
- código;
- know-how.
Portanto, a obrigação pode ser bilateral.
NDA pode estar dentro do contrato principal.
O documento precisa definir:
- informação confidencial;
- finalidade.
Não basta uma frase genérica.
Código-fonte costuma exigir proteção especial
Especialmente quando permanece propriedade do fornecedor.
O cliente pode utilizá-lo apenas dentro de limites.
Se houver acesso.
Isso precisa estar claro.
Segredo empresarial também pode coexistir com licença
Software pode ser licenciado.
Know-how interno continua confidencial.
São camadas diferentes.
camada 2 · Dados pessoaisDados pessoais também precisam ser tratados
Se o software processa:
- dados de clientes;
- empregados.
Pode existir relação com LGPD.
O contrato precisa definir responsabilidades conforme o fluxo.
Por exemplo:
- quem determina finalidade;
- quem opera dados.
Não se deve colocar tudo em cláusula genérica de confidencialidade.
Proteção de dados merece tratamento próprio.
camada 3 · Segurança e incidentesSegurança da informação também pode exigir regras específicas
Pode envolver:
- controle de acesso;
- incidentes.
Também:
- autenticação;
- criptografia.
O nível precisa ser proporcional ao risco.
Não é adequado copiar padrões de banco para software simples sem necessidade.
Mas software crítico precisa de requisitos claros.
Incidente de segurança precisa ter fluxo
Quem comunica?
Em quanto tempo internamente?
Quem investiga?
Isso pode ser relevante.
Especialmente em SaaS B2B.
camada 4 · Dados × softwarePropriedade dos dados precisa ser diferenciada de propriedade do software
Outro erro comum.
O cliente pode ser titular de:
- dados inseridos.
O fornecedor continua titular do software.
São ativos diferentes.
Contrato precisa separar.
O fornecedor não deveria apropriar-se de dados empresariais do cliente sem fundamento.
Do outro lado, cliente não recebe o software porque inseriu dados nele.
Essa distinção precisa estar clara.
Dados agregados ou anonimizados podem exigir regra própria
Fornecedor pode querer utilizar:
- métricas;
- dados estatísticos.
Isso precisa ser analisado.
Especialmente quando existe:
- confidencialidade;
- LGPD.
Não se deve presumir autorização irrestrita.
camada 5 · Inteligência ArtificialInteligência Artificial também aparece em contratos de software
Fornecedor pode utilizar IA para:
- desenvolvimento;
- suporte.
Cliente pode inserir dados na plataforma.
O contrato pode precisar esclarecer:
- uso de informações;
- treinamento.
Dependendo do produto, isso é crítico.
Não deve ficar implícito.
Software que utiliza IA de terceiros também possui dependências
Pode existir:
- API de modelo externo.
O cliente precisa saber quando isso afeta:
- dados;
- disponibilidade.
Especialmente em operações reguladas.
Transparência contratual ajuda.
Propriedade Intelectual de resultados gerados por IA pode exigir análise específica
Não deve ser resolvida com uma frase genérica.
Isso depende:
- do produto;
- da intervenção humana.
Contrato precisa delimitar o que é resultado do serviço.
Não prometer titularidade impossível.
Não concorrência, não aliciamento e subcontratação
Cada restrição precisa ter finalidade.
Não concorrência com a software house precisa ser analisada com cuidado
Cliente pode querer impedir fornecedor de atender concorrentes.
Isso pode ser legítimo em determinados projetos estratégicos.
Mas restrição ampla pode ser excessiva.
Pode ser mais adequado proteger:
- informação confidencial;
- funcionalidade exclusiva.
Não necessariamente bloquear todo o mercado.
Exclusividade precisa ser proporcional.
E economicamente negociada.
Não aliciamento também pode aparecer
Cliente pode querer evitar contratação dos desenvolvedores.
Fornecedor pode querer proteção recíproca.
Isso deve ser analisado.
Não deve entrar automaticamente.
Cada restrição precisa ter finalidade.
Subcontratação precisa ser tratada
Software house pode utilizar:
- freelancers;
- parceiros.
Cliente precisa saber se isso é permitido.
Principalmente quando envolve acesso a:
- dados;
- código.
O contrato pode exigir:
- responsabilidade do fornecedor;
- obrigações equivalentes de confidencialidade.
Não necessariamente aprovação individual para qualquer colaborador.
Mas controle mínimo precisa existir.
Uso de profissionais no exterior também pode impactar dados
Especialmente em transferências internacionais.
Isso precisa ser avaliado conforme o caso.
Prazo de desenvolvimento precisa ser realista
Pagamento por marcos, obrigações dos dois lados e um plano para o fim.
- Entradainício do projeto
- Protótipovalidação da proposta
- Homologaçãoaceite objetivo
- Entrega finalconclusão
Projetos tecnológicos podem atrasar.
Por isso, cronograma precisa distinguir:
- dependências do fornecedor;
- dependências do cliente.
Se cliente demora para aprovar:
o prazo pode precisar ser ajustado.
Essa regra evita discussão.
Obrigações do cliente também precisam existir
Como:
- fornecer informações;
- homologar.
Contrato não pode concentrar todas as obrigações em uma parte.
Projetos dependem de cooperação.
Marcos de pagamento podem acompanhar entregas
Por exemplo:
- entrada;
- protótipo.
Também:
- homologação;
- entrega final.
Isso pode equilibrar risco.
Mas pagamento não deve ser vinculado a critérios vagos.
O aceite precisa ser objetivo.
Retenção integral de pagamento por pequenos bugs também pode gerar desequilíbrio.
O contrato deve diferenciar defeitos relevantes de ajustes menores.
E se a relação terminar?
Escolha o cenário.
Rescisão antes da conclusão precisa ser tratada
Se o projeto termina no meio:
- quem fica com o código produzido?
- o que foi pago?
Também:
- documentação parcial;
- acessos.
Essas questões precisam estar previstas.
Pode existir pagamento proporcional.
Pode haver licença sobre partes concluídas.
Depende da negociação.
Não se deve descobrir no litígio.
Rescisão por inadimplemento também precisa ter consequência
Por exemplo:
- cliente deixa de pagar.
O fornecedor pode suspender acesso?
Em SaaS, isso pode ser possível conforme contrato.
Mas precisa considerar:
- dados do cliente;
- transição.
Suspender software crítico de forma abrupta pode gerar impacto grande.
Procedimento deve ser proporcional.
Período de cura pode ser previsto.
Para descumprimentos sanáveis.
Alguns eventos graves podem permitir reação imediata.
Isso precisa ser definido.
Encerramento de SaaS precisa prever exportação de dados
Quando aplicável.
Cliente pode precisar retirar:
- cadastros;
- documentos.
Formato de exportação pode ser importante.
Isso reduz lock-in indevido.
Mas fornecedor não precisa entregar seu código.
Dados e software continuam sendo coisas diferentes.
Transição pode ser contratada
Em sistemas importantes.
Pode envolver:
- apoio à migração;
- entrega de dados.
Isso pode ter custo.
O contrato precisa prever.
Não assumir suporte ilimitado gratuito após rescisão.
A cessão também precisa prever transição
Se o cliente compra software.
Pode precisar de:
- treinamento;
- documentação.
Isso ajuda a tornar a transferência efetiva.
Um código sem contexto pode ser pouco útil.
Por isso, cessão comercial pode incluir suporte de transição.
Quem responde pelo quê
Declarações, limites e indenização precisam acompanhar a origem do problema.
Passivos anteriores também podem ser analisados
Comprador de software pode querer saber:
- terceiros alegam direitos?
- há licenças incompatíveis?
Isso se aproxima de Due Diligence.
Cessão relevante deve ser precedida de análise.
Não apenas assinatura.
Declarações e garantias podem ser úteis
Fornecedor ou cedente pode declarar:
- possuir direitos necessários;
- conhecer as dependências.
Também:
- não ter concedido exclusividade incompatível.
Essas declarações ajudam a alocar risco.
Mas precisam ser verdadeiras.
Não copiar modelo americano sem análise.
Limitação de responsabilidade também merece atenção
Contratos de software costumam conter.
Pode existir:
- teto.
Mas determinados eventos podem receber tratamento diferente.
Por exemplo:
- violação de confidencialidade;
- propriedade intelectual.
Isso precisa ser negociado.
Limitação não deveria tornar o contrato irrelevante.
Nem criar responsabilidade ilimitada para qualquer falha menor.
Equilíbrio é importante.
Indenização por infração de terceiros também pode ser tratada
Se fornecedor utiliza código sem autorização.
Cliente pode ser afetado.
O contrato pode prever:
- defesa;
- substituição.
Mas precisa considerar:
- componentes aprovados pelo cliente;
- modificações feitas pelo próprio cliente.
Responsabilidade precisa acompanhar a origem do problema.
Não ser automática.
O código é só uma parte do ativo
White label, lojas de aplicativo, domínio e nuvem também precisam de titular.
Em nome de quem está?
Software White Label exige regras específicas
O cliente utiliza:
- plataforma do fornecedor;
- sua própria marca.
Isso não significa que o código foi cedido.
O contrato precisa definir:
- titularidade da plataforma;
- customizações.
Também:
- uso após rescisão.
O fornecedor pode atender concorrentes?
Depende da exclusividade.
Isso precisa estar expresso.
Desenvolvimento de aplicativo também pode envolver lojas
Como:
- App Store;
- Google Play.
Conta de publicação deve ser definida.
Ficará em nome de:
- cliente;
- fornecedor?
Isso pode ser crítico.
A empresa pode descobrir no fim que o aplicativo está na conta pessoal do desenvolvedor.
Governança de ativos digitais evita esse problema.
Domínio também precisa ser controlado
Se o projeto envolve:
- site;
- plataforma.
O domínio deve estar adequadamente vinculado à empresa.
Não ao fornecedor por comodidade.
O mesmo vale para:
- certificados;
- contas de nuvem.
Contrato pode definir titularidade desses ativos operacionais.
Não apenas do código.
Contas em Cloud também são importantes
AWS.Azure.Google Cloud.
Quem é titular da conta?
Quem paga?
Isso afeta transição.
Em sistema estratégico, a empresa precisa saber.
M&A expõe contratos mal estruturados
O comprador vai perguntar. Responda antes dele.
M&AM&A expõe contratos mal estruturados
Comprador pode perguntar:
- quem é dono do software?
- existem contratos de cessão?
Também:
- quais licenças existem;
- o código foi terceirizado?
Um negócio que depende de software sem cadeia documental clara pode enfrentar Red Flag.
Por isso, contratos precisam ser organizados desde o desenvolvimento.
Não apenas quando a empresa for vendida.
investidoresInvestidores também analisam
Especialmente startups.
Perguntas comuns:
- software pertence à empresa?
- freelancers cederam direitos?
Também:
- fundador saiu levando repositório?
Esse tipo de problema pode ser corrigido.
Mas é melhor prevenir.
Regularização posterior pode exigir:
- aditivos;
- cessões.
Nem sempre antigo prestador estará disponível.
Por isso, contrato inicial importa.
reorganizaçõesReorganizações societárias também podem afetar software
Ativo pode ser transferido para:
- holding;
- outra empresa do grupo.
Isso pode exigir cessão.
Ou licença intragrupo.
A operação precisa estar documentada.
Contabilidade também pode precisar refletir.
Tributação pode ser relevante.
Principalmente em:
- royalties;
- operações internacionais.
Contrato tecnológico não deveria ser isolado dessas áreas quando material.
registroRegistro de Software pode ser complementar
Dependendo da estratégia.
Pode ajudar na documentação de:
- titularidade;
- versão.
Mas não substitui o contrato.
O registro não explica:
- licença;
- exclusividade.
Portanto, registro e contrato se complementam.
segredo industrialSegredo Industrial também continua relevante
Parte do software pode ser registrada.
Mas:
- arquitetura;
- know-how
podem permanecer confidenciais.
O contrato precisa proteger o que não será divulgado.
Especialmente em projetos com terceiros.
Não existe um único mecanismo de proteção.
Como funciona a assessoria em Contratos de Software?
O trabalho pode envolver:
- 1. Identificação do Modelo
Definição se existe:
- Licenciamento
- Cessão
- Desenvolvimento sob encomenda
- Combinação
- 2. Mapeamento dos Ativos
Identificação de:
- Software-base
- Customizações
- Componentes de terceiros
- 3. Definição da Titularidade
Organização de quem será titular de:
- Código
- Documentação
- Melhorias
- 4. Delimitação da Licença
Definição de:
- Usuários
- Prazo
- Território
- Sublicenciamento
- 5. Estruturação do Desenvolvimento
Definição de:
- Escopo
- Cronograma
- Aceite
- Mudança de escopo
- 6. Tratamento das Dependências
Análise de:
- Open Source
- APIs
- Serviços de terceiros
- 7. Confidencialidade e Segurança
Definição de regras sobre:
- Código
- Dados
- Acessos
- 8. Suporte e Manutenção
Organização de:
- SLA
- Correções
- Evoluções
- Custos
- 9. Rescisão e Transição
Definição de:
- Dados
- Código
- Acessos
- Suporte de saída
- 10. Integração com Propriedade Intelectual e Negócio
Compatibilização com:
- Investimentos
- Due Diligence
- M&A
- Reorganizações
Como a FIX Compliance atua
A FIX Compliance pode auxiliar empresas, startups, software houses e grupos empresariais na elaboração e revisão de contratos relacionados a software.
O trabalho pode envolver, conforme a necessidade:
O escopo depende do modelo comercial, da complexidade técnica, da quantidade de terceiros envolvidos e da relevância do software para a operação.
Para quem esse serviço é indicado?
Os Contratos de Licenciamento, Cessão e Desenvolvimento de Software sob Encomenda podem ser especialmente relevantes para:
Sua empresa está pagando pelo desenvolvimento de um software. Mas sabe exatamente o que receberá ao final: uma licença de uso, o código, a titularidade das customizações ou todos esses elementos dentro de limites definidos?
Essa é a pergunta central. Um contrato de software bem estruturado precisa ajudar as partes a responder: Toque nos pontos que o seu contrato já define.
e
Contratos de software não devem apenas dizer quanto custa e quando será entregue.
Eles precisam definir a arquitetura jurídica do ativo: quem cria, quem possui, quem pode utilizar, quais elementos podem ser reutilizados e como tecnologia, dados e acessos serão tratados durante e depois da relação.
Dúvidas sobre contratos de software
Para quem contrata, desenvolve, licencia, compra ou vende software.
01Qual a diferença entre licença e cessão de software?
02Se eu paguei pelo desenvolvimento, o código é meu?
03A cessão precisa ser por escrito?
04O que é Background IP e Foreground IP?
05No SaaS, o cliente tem direito ao código-fonte?
06O que é escrow de código-fonte?
07Como evitar briga sobre mudança de escopo?
08Qual a diferença entre bug e nova funcionalidade?
09Quem deve ser dono das contas de cloud, domínio e lojas de aplicativo?
10Registrar o software no INPI substitui o contrato?
Base legal e fontes oficiais
Conteúdo informativo. Mapas, prévias de cláusula e diagnósticos desta página são ilustrativos: não constituem parecer e não substituem a análise do contrato, do código e do modelo de negócio.
Nesta área e páginas relacionadas
Fale com a FIX Compliance
Se sua empresa pretende licenciar, contratar, desenvolver, adquirir ou ceder software e precisa definir com clareza titularidade, uso, código, customizações, manutenção e responsabilidades, fale com a FIX Compliance.
Nossa equipe pode analisar o modelo tecnológico e comercial da operação, estruturar o contrato adequado e integrar propriedade intelectual, confidencialidade, proteção de dados e governança dos ativos digitais à realidade do negócio.
WhatsApp e telefone: (11) 95276-4331
E-mail: contato@fixcompliance.com.br
Atendimento de segunda a sexta, das 9h às 18h.
Conte sobre o software
Licença, cessão ou desenvolvimento, quem desenvolve, se há SaaS, customizações, terceiros ou uma operação de investimento em vista.