Orientação sobre Proteção de Software e Conteúdo

Uma plataforma digital pode reunir vários ativos diferentes.

Por exemplo:

• código-fonte;
• marca;
• layout;
• banco de conteúdo;
• metodologia;
• base documental;
• domínio.

Cada elemento pode possuir proteção jurídica própria

A pergunta correta não é:

“como registrar a plataforma?”

Mas:

“quais ativos existem dentro da plataforma e qual proteção faz sentido para cada um deles?”

Essa diferença é fundamental

Software possui proteção específica

Programa de computador possui regime jurídico próprio no Brasil.

A proteção está ligada ao código e à expressão do programa.

Isso não significa que qualquer funcionalidade abstrata ou ideia de aplicativo esteja automaticamente protegida.

Ideia e implementação precisam ser diferenciadas.

Uma pessoa pode ter a ideia de:

“criar um aplicativo para organizar contratos”.

Isso, por si só, não significa exclusividade sobre todo aplicativo com essa finalidade.

O valor jurídico está naquilo que foi concretamente desenvolvido.

Por isso, precisa estar juridicamente organizado.

Quem desenvolveu?

Foi:

• sócio;
• empregado;
• freelancer;
• software house?

A resposta influencia a cadeia de titularidade.

O simples pagamento pelo desenvolvimento não deve ser tratado automaticamente como prova de transferência integral de todos os direitos.

O contrato precisa ser revisado.

Contratos com desenvolvedores são essenciais

Eles podem definir:

• titularidade;
• licença;
• acesso ao código.

Também podem tratar:

• manutenção;
• atualizações;
• confidencialidade.

Isso evita que a empresa fique dependente de fornecedor.

Imagine uma empresa que utiliza software essencial para sua operação.

Mas o código está apenas com o programador terceirizado.

Se a relação termina, o negócio pode ficar vulnerável.

Por isso, proteção jurídica também envolve controle operacional.

Repositórios precisam estar organizados

O código pode estar em:

• GitHub;
• GitLab;
• outro repositório.

A empresa precisa saber:

• quem controla;
• quem possui acesso.

Não é recomendável que ativo estratégico fique exclusivamente em conta pessoal de desenvolvedor.

Governança tecnológica é parte da proteção.

Backups também precisam existir

Histórico de versões também.

Isso ajuda tanto operacionalmente quanto na documentação da evolução do software.

Registro de Programa de Computador pode ser considerado

No Brasil, existe procedimento específico perante o INPI.

O registro não cria necessariamente o direito autoral sobre o software, mas pode auxiliar na documentação de:

• autoria;
• titularidade;
• versão.

Isso pode ser relevante em:

• investimento;
• Due Diligence;
• disputa.

O registro deve refletir a realidade contratual.

Não faz sentido registrar em nome de empresa que não possui cadeia jurídica consistente sobre o código.

Primeiro é necessário revisar contratos.

Depois, formalizar.

Por exemplo:

• bibliotecas;
• frameworks;
• APIs;
• plugins.

Isso precisa ser conhecido.

Utilizar código de terceiro não é necessariamente problema.

Mas a licença precisa ser respeitada.

Open Source merece atenção especial

O termo “Open Source” não significa:

“pode fazer qualquer coisa sem condição”.

Existem diferentes licenças.

Algumas permitem utilização ampla.

Outras impõem condições.

Dependendo da licença, podem existir obrigações relacionadas a:

• distribuição;
• atribuição;
• disponibilização de código.

Por isso, empresas de software precisam conhecer suas dependências.

Inventário de componentes pode ser útil.

Isso é especialmente importante antes de:

• investimento;
• venda da empresa.

Due Diligence tecnológica normalmente examina essas dependências.

APIs também merecem atenção

Uma plataforma pode depender de serviço de terceiro.

Por exemplo:

• pagamentos;
• inteligência artificial;
• mapas;
• armazenamento.

Essa dependência possui componente contratual.

O negócio pode não possuir a tecnologia.

Apenas licença de acesso.

Isso precisa ser conhecido.

Termos do fornecedor podem limitar:

• uso;
• armazenamento;
• sublicenciamento.

Dependência excessiva também pode ser risco.

Proteção de software não significa apenas proteger aquilo que a empresa criou.

Também significa conhecer aquilo de que depende.

A empresa pode possuir:

• base de clientes;
• dados estruturados;
• conteúdo.

Isso envolve diferentes questões.

Dados pessoais, por exemplo, não devem ser tratados como “propriedade” no mesmo sentido de um código-fonte.

LGPD entra nessa discussão.

Já a estrutura de determinado banco ou conteúdo pode possuir outros elementos jurídicos.

É necessário separar.

Não se deve chamar tudo de Propriedade Intelectual sem analisar a natureza do ativo.

Interface também pode possuir proteção

Uma aplicação possui:

• layout;
• elementos gráficos;
• ícones.

Esses elementos podem envolver Direitos Autorais.

Também podem utilizar componentes licenciados.

Fontes tipográficas podem possuir licença.

Ícones também.

Fotografias também.

Portanto, a empresa precisa saber de onde vieram.

Template comprado não significa titularidade integral

Normalmente existe licença.

A empresa pode usar.

Mas talvez não possa:

• revender;
• redistribuir.

Isso precisa ser verificado.

Marca também faz parte da proteção do software

O nome do aplicativo ou plataforma pode ser estratégico.

Ele é diferente do código.

Por isso, pode ser necessário:

• busca de anterioridade;
• pedido de registro de marca.

Registrar software não protege automaticamente o nome comercial.

Do mesmo modo, registrar a marca não protege o código.

São camadas complementares.

Domínio também é outro ativo

A empresa pode possuir:

• domínio;
• perfis em redes sociais.

Isso não substitui registro marcário.

Mas precisa estar sob controle da empresa.

Um domínio em nome pessoal de ex-sócio pode gerar problema.

Especialmente em conflito societário.

Governança de ativos digitais precisa ser revisada.

Isso pode envolver:

• texto;
• vídeo;
• fotografia;
• ilustração;
• e-book;
• aula gravada.

Direitos Autorais normalmente estão no centro.

Mas novamente:

autoria e titularidade são diferentes.

Um professor pode criar aula.

A empresa pode receber direito de exploração.

Isso precisa estar documentado.

Não se deve presumir.

Cursos digitais exigem atenção especial

Podem reunir:

• vídeo;
• apostila;
• apresentação.

Além de:

• imagem;
• voz do professor.

O contrato precisa tratar o conjunto.

Se o professor sair:

• o curso pode continuar?
• por quanto tempo?

Isso precisa estar definido.

E-books também podem ter vários autores

Ou componentes.

Texto de uma pessoa.

Capa de outra.

Ilustrações de outra.

A empresa precisa organizar toda a cadeia.

Registrar o e-book não elimina direitos dos criadores.

Contratos continuam fundamentais.

Conteúdo produzido por agência também precisa ser analisado

Uma agência pode criar:

• campanha;
• vídeo;
• arte.

Mas pode ter utilizado:

• banco de imagem;
• música licenciada;
• freelancer.

A empresa contratante precisa saber quais direitos recebe.

Principalmente se quiser reutilizar o conteúdo por longo prazo.

Uma campanha temporária pode utilizar licença limitada.

Reutilizar anos depois pode não estar autorizado.

Isso precisa ser conhecido.

Conteúdo de terceiros é uma das principais fontes de risco

Empresas frequentemente utilizam:

• imagens encontradas online;
• vídeos;
• músicas.

Isso pode gerar notificações e cobranças.

“Estava no Google” não é autorização.

Conteúdo publicamente acessível não significa conteúdo livre para exploração comercial.

Isso precisa estar claro para equipes de marketing.

Política interna pode ajudar

A empresa pode estabelecer regras para:

• uso de imagens;
• músicas;
• conteúdos de terceiros.

Isso reduz risco.

Fontes precisam ser registradas.

Licenças também.

Comprovantes também.

Organização é fundamental.

Empresas utilizam IA para produzir:

• texto;
• imagens;
• código.

Isso exige cuidado.

Primeiramente, termos da ferramenta precisam ser conhecidos.

A empresa precisa saber quais direitos recebe.

Também precisa compreender se os dados inseridos podem:

• ser armazenados;
• utilizados pelo fornecedor.

Informação confidencial não deve ser inserida indiscriminadamente.

Isso pode incluir:

• código;
• estratégia;
• dados de clientes.

Governança de IA precisa fazer parte da política tecnológica.

Conteúdo gerado com IA também precisa de revisão

Pode haver semelhança com obras anteriores.

Pode haver problemas de qualidade.

Em conteúdo técnico, pode haver erros.

A empresa não deveria publicar automaticamente.

Revisão humana é importante.

Direito autoral sobre conteúdo gerado com IA é tema que exige análise cuidadosa conforme o grau de intervenção humana e o contexto concreto.

Por isso, não se deve vender a ideia de que todo resultado de IA automaticamente pertence integralmente à empresa.

Cada caso precisa ser avaliado.

Nem tudo precisa ser registrado.

Uma empresa pode possuir:

• algoritmo;
• processo;
• metodologia;
• informação estratégica.

Dependendo da situação, manter confidencialidade pode ser mais adequado.

Isso exige medidas reais.

NDA é uma delas.

Mas NDA sozinho não basta.

Também podem existir:

• controle de acesso;
• classificação de informações.

Um segredo precisa ser tratado como segredo.

Se a informação está publicada, a lógica muda.

Por isso, governança é essencial.

Patente pode ou não ser relevante

Nem todo software pode ser patenteado.

Software isolado, como regra, possui regime autoral.

Mas determinada solução tecnológica pode envolver elementos técnicos que mereçam análise específica.

Isso exige avaliação de patenteabilidade.

Não se deve confundir:

• software;
• invenção implementada por computador.

A análise precisa ser técnica.

Em alguns casos, segredo pode ser melhor do que divulgação em patente.

Estratégia precisa ser definida antes da publicação.

Divulgação prematura pode afetar proteção.

Por isso, startups precisam pensar em propriedade intelectual antes de:

• pitch;
• evento;
• lançamento.

NDA pode ser útil em algumas negociações.

Mas não substitui decisão sobre patente ou registro.

Em software e conteúdo, grande parte da proteção está nos contratos.

Contratos com empregados.

Contratos com prestadores.

Contratos com parceiros.

Contratos com clientes.

Cada relação pode afetar titularidade ou exploração.

Contrato com desenvolvedor pode definir:

• código;
• melhorias;
• documentação.

Contrato com autor pode definir:

• cessão;
• licença.

Contrato com cliente pode definir:

• limites de acesso;
• proibição de redistribuição.

O conjunto precisa ser coerente.

Cessão e licença precisam ser diferenciadas

Cessão

Transfere direitos dentro do escopo aplicável.

Licença

Autoriza uso mantendo titularidade com outra pessoa.

Para software e conteúdo, essa distinção é central.

Uma empresa pode querer possuir integralmente determinado código estratégico.

Em outro caso, licença pode ser suficiente.

Não existe resposta universal.

O modelo de negócio define.

SaaS normalmente depende de licença de uso

O cliente paga para utilizar sistema.

Isso não significa que recebe código.

Nem propriedade.

O contrato precisa deixar claro.

Número de usuários pode ser limitado.

Uso pode ser:

• mensal;
• anual.

A licença precisa acompanhar a operação.

Não é recomendável utilizar contrato de venda de software quando o modelo real é serviço recorrente.

SaaS também precisa de Termos de Uso

Política de Privacidade também.

SLA também pode ser relevante.

Disponibilidade.

Suporte.

Segurança.

Tudo isso precisa conversar com Propriedade Intelectual.

Uma empresa desenvolve sistema e permite que outra utilize com sua própria marca.

Quem continua sendo titular do código?

O cliente pode alterar?

Pode sublicenciar?

Isso precisa estar no contrato.

Customizações também precisam ser tratadas.

O cliente pode pagar desenvolvimento específico.

Mas quem será titular da melhoria?

Essa pergunta deve ser respondida antes.

Background IP e Foreground IP são úteis

Background IP

Tecnologia que já existia antes do projeto.

Foreground IP

Aquilo que foi criado durante o projeto.

Isso evita discussão sobre customizações.

Uma empresa não deveria perder toda sua plataforma porque desenvolveu uma funcionalidade para um cliente.

Da mesma forma, cliente pode ter interesse legítimo sobre desenvolvimento específico.

O contrato precisa equilibrar.

Conteúdo White Label possui lógica semelhante

Material educacional pode ser produzido para terceiro.

Quem poderá reutilizar?

Haverá exclusividade?

O conteúdo será adaptado?

Tudo precisa ser definido.

Proteção contra pirataria também deve ser considerada

Cursos.

E-books.

Software.

Todos podem ser copiados.

Não existe mecanismo capaz de impedir toda cópia.

Mas podem existir estratégias de:

• controle de acesso;
• monitoramento;
• enforcement.

Watermark pode ajudar em determinados conteúdos.

Gestão de usuários também.

Mas tecnologia e jurídico precisam trabalhar juntos.

Termos de Uso podem proibir:

• compartilhamento;
• redistribuição.

Isso cria base contratual.

Mas cláusula não substitui fiscalização.

Quando ocorrer violação, pode ser necessário:

• preservar prova;
• notificar.

Plataformas também podem receber pedidos de remoção.

Casos relevantes podem exigir medida judicial.

Essa estratégia precisa ser proporcional.

Não é eficiente tentar processar qualquer compartilhamento pequeno.

Priorização é importante.

Em startups, perguntas frequentes incluem:

• quem é dono do código?
• marca está registrada?
• contratos com desenvolvedores existem?

Se as respostas forem frágeis, isso aparece em Due Diligence.

O problema pode virar condição precedente.

Por isso, regularizar antes da rodada é melhor.

Isso não garante investimento.

Mas reduz inconsistência documental.

M&A também exige organização

Comprador precisa saber se recebe:

• software;
• conteúdo.

Uma empresa pode ter produto excelente.

Mas depender de licença pessoal do fundador.

Isso reduz segurança da transação.

Cadeia de titularidade precisa estar clara.

Software também pode estar em empresa diferente do grupo.

Nesse caso, licença intragrupo pode existir.

Isso precisa ser documentado.

Reorganização societária pode exigir transferência.

Mas efeitos tributários devem ser analisados.

Ativos intangíveis também podem aparecer na contabilidade

Mas tratamento contábil não define sozinho a titularidade jurídica.

Um ativo registrado no balanço pode possuir contrato inadequado.

E ativo juridicamente valioso pode nem estar reconhecido da mesma maneira contábil.

Contabilidade e jurídico precisam conversar.

Valor econômico é outra questão

Registrar software ou conteúdo não cria automaticamente valuation.

Valor depende de:

• receita;
• mercado.

A documentação ajuda a sustentar que o ativo realmente pertence ao negócio.

Mas não define seu preço.

Isso precisa ficar claro.

Inventário de Propriedade Intelectual pode ser útil

A empresa pode listar:

• ativo;
• titular;
• registro;
• contrato.

Para software, pode incluir:

• versão;
• repositório.

Para conteúdo:

• autor;
• contrato.

Essa organização facilita:

• auditorias;
• investimentos.

Também ajuda no dia a dia.

Renovação de marcas.

Atualização de registros.

Tudo fica rastreável.

Offboarding de colaboradores também faz parte da proteção

Quando desenvolvedor ou produtor de conteúdo sai:

• acessos precisam ser revogados;
• arquivos devolvidos.

Confidencialidade continua quando contratualmente e juridicamente aplicável.

Repositórios precisam permanecer com a empresa.

Senhas também.

Não se deve deixar patrimônio digital sair junto com a pessoa.

Isso precisa ser planejado no onboarding.

Não apenas na demissão.

Políticas internas ajudam

Podem tratar:

• desenvolvimento;
• criação de conteúdo.

Também:

• uso de IA;
• software de terceiros.

Elas não substituem contratos.

Mas ajudam a criar governança.

Empresas pequenas também podem se beneficiar

Não é necessário ser multinacional.

Uma startup de três pessoas pode depender totalmente do próprio software.

Nesse caso, titularidade é extremamente importante.

Uma escola pequena pode depender de seu acervo de cursos.

O tamanho da empresa não define relevância.

O que importa é quanto o negócio depende do ativo.

A proteção precisa ser proporcional

Nem todo conteúdo precisa de:

• registro;
• contrato individual complexo.

É necessário priorizar ativos estratégicos.

Um post isolado pode exigir organização diferente de um curso principal.

O objetivo não é criar burocracia.

É proteger valor.

Por isso, o trabalho deve começar pelo risco.

Qual ativo sustentaria maior prejuízo se fosse perdido?

Qual ativo representa maior receita?

Essas perguntas ajudam a priorizar.