Advogado para Contratos e Registro de Software

No SaaS (software como serviço), a solução roda no ambiente do fornecedor e o cliente acessa como serviço, normalmente por assinatura. Na licença, há autorização para usar o software dentro das condições contratadas, às vezes com instalação no ambiente do próprio cliente — sem transferência de titularidade. O rótulo não decide a classificação: o conteúdo do contrato e a realidade da operação é que definem o regime aplicável.

Não necessariamente. Pagar pelo desenvolvimento de software sob demanda não faz, sozinho, a transferência plena dos direitos sobre o programa criado. A titularidade do software precisa ser definida no contrato — especialmente quando há componentes preexistentes, bibliotecas de terceiros ou tecnologias open source no meio. Sem cláusula clara, a discussão sobre quem é o dono pode custar caro em uma disputa ou em uma due diligence.

Depende do que o contrato e a legislação estabelecem para aquela situação. Por padrão, o direito sobre o programa de computador tem regras de autoria e titularidade próprias, que combinam criador, empregador e contratante conforme o contexto. O que parece óbvio na prática muitas vezes não está documentado. Entregar o código-fonte não equivale à cessão integral dos direitos: a titularidade exige instrumento próprio.

A cessão de código-fonte transfere direitos patrimoniais sobre o programa dentro dos limites definidos no instrumento — e precisa delimitar com precisão o que está incluído: versões, documentação, repositórios, credenciais e até futuras versões. Também separa o que permanece com o autor: componentes preexistentes, bibliotecas próprias e know-how. Não transfere automaticamente marca, domínio ou banco de dados — ativos distintos exigem previsão própria.

Pode ou não — isso precisa estar escrito. Bibliotecas reutilizáveis e módulos genéricos desenvolvidos para múltiplos clientes podem seguir de uso compartilhado; a solução específica do cliente, em geral, recebe restrições pela confidencialidade e pela cessão. Contratos claros evitam a situação desconfortável de descobrir um concorrente usando a mesma base construída com o seu dinheiro.

Não. Pela legislação brasileira de programas de computador, a proteção do software não depende obrigatoriamente de registro — ela decorre da criação e dos contratos que organizam a titularidade. O registro é uma camada estratégica de evidência formal, não um requisito legal para existir proteção nem a única fonte de direitos sobre o programa.

O registro de programa de computador é feito perante o INPI, seguindo os procedimentos e a documentação técnica exigidos pelo órgão — com identificação do titular, do autor, do programa e dos documentos que representam o código. O processo costuma ser realizado em ambiente digital e os procedimentos atuais devem ser consultados no portal oficial. O registro não protege ideias abstratas nem funcionalidades no sentido da patente.

Não substitui. Registrar o software sem organizar a sua cadeia de titularidade pode deixar a questão central sem solução: quem tinha o direito antes do registro? A proteção jurídica bem construída combina contratos com desenvolvedores e colaboradores, cessões, confidencialidade, histórico de versões e repositórios — o registro coroa uma cadeia coerente, não a compensa.

Primeiro, preserve tudo: escopo, cronograma, entregas, comunicações, pagamentos e o que já foi construído — incluindo código, documentação e acessos disponíveis. Notifique formalmente o responsável. Dependendo do caso, avaliam-se alternativas viáveis: retomada por outro fornecedor, conclusão interna, renegociação ou, quando cabível, medidas judiciais. Contratos com regras de crédenciais, repositório e entregas parciais têm papel direto na hora do abandono.

Separando as categorias de serviço: correção de erros, manutenção preventiva, manutenção evolutiva, suporte ao usuário, atualizações e novas funcionalidades têm naturezas e precificações diferentes. Sem essa separação, nasce o conflito clássico: o cliente espera evolução, o fornecedor entrega apenas correção. O contrato de manutenção de software define o que está incluído, como é solicitado e com que prazos.

SLA — acordo de nível de serviço — é o conjunto de compromissos técnicos formalizados no contrato: disponibilidade estimada, canais e horários de atendimento, classificação de incidentes, tempos de resposta e de solução, janelas de manutenção, exceções e consequências para descumprimentos, como créditos de serviço. O SLA não elimina indisponibilidades — organiza expectativa, prioridade de atendimento e compensação quando a meta não é cumprida.

Sim — quando há tratamento de dados pessoais pela plataforma, que é a regra. O contrato deve delimitar os papéis das partes, as finalidades autorizadas, medidas de segurança, suboperadores, incidentes de segurança, retenção, e devolução e eliminação dos dados ao final. Uma cláusula genérica de LGPD sem acompanhar a operação real não representa adequação completa — e não é a resposta que resiste a uma auditoria.

Modelos podem inspirar a discussão — mas não podem ser a decisão final. Contratos operacionais de tecnologia precisam refletir a arquitetura do produto, o modelo de receita, os ativos envolvidos e os riscos setoriais. Copiar texto de origem desconhecida significa adotar, sem saber, escolhas feitas para outra empresa — descobertas normalmente apenas quando o conflito já está instalado.

Sim. O atendimento é remoto por padrão — reuniões por vídeo, documentos digitais e acompanhamento on-line — para empresas de todo o Brasil e para empresas estrangeiras ou brasileiros no exterior com operações ligadas ao país. A distância não interfere na profundidade da análise nem na negociação dos documentos.