O licenciamento de software é o mecanismo contratual pelo qual o detentor dos direitos autorais de um programa permite que outra pessoa o utilize. De acordo com a legislação holandesa, um programa de computador é uma obra protegida por si só, conforme o artigo 10, primeiro parágrafo, ponto 12 da Auteurswet (Lei de Direitos Autorais), portanto, qualquer ato de carregar, copiar ou adaptar o programa requer permissão ou uma exceção legal. Uma licença é essa permissão, e seu escopo, duração e condições são definidos pelo contrato, sujeitos a um pequeno conjunto de direitos aos quais o licenciado não pode renunciar.
Essa estrutura explica quase todos os erros que as organizações cometem em relação ao licenciamento de software: elas tratam a licença como um recibo em vez de um contrato, presumem direitos que a licença nunca concedeu e descobrem a lacuna durante uma auditoria do fornecedor ou uma migração. Este artigo explica o que a legislação holandesa e europeia realmente garante, o que a licença adiciona ou retira e quais cláusulas determinam sua exposição a riscos.
O que você adquire ao licenciar um software
Você não compra um software. Você adquire o direito de usar uma cópia, nos termos da licença, enquanto os direitos autorais permanecem com o detentor dos direitos. Essa distinção tem consequências práticas: você não pode presumir que poderá instalar o programa em um segundo servidor, executá-lo para uma empresa do grupo, permitir que um contratado use sua conta ou continuar usando-o após o término do contrato, a menos que a licença permita.
A legislação holandesa não considera toda aquisição de software como uma simples licença. No acórdão De Beeldbrigade de 27 de abril de 2012 (ECLI:NL:HR:2012:BV1301), o Hoge Raad (Tribunal Superior) decidiu que as regras de compra e venda do Livro 7 do Código Civil se aplicam à aquisição de software padrão fornecido por prazo indeterminado mediante pagamento único, mesmo que o software não seja um objeto tangível. O efeito prático é que se aplica o requisito de conformidade da lei de compra e venda: o software deve possuir as qualidades que o comprador tinha o direito de esperar. Essa é uma posição significativamente mais robusta do que uma mera garantia contratual, e é um dos motivos pelos quais os fornecedores preferem modelos de assinatura e nuvem, que são serviços e não vendas.
Quando o cliente é um consumidor, aplica-se uma camada adicional. O Livro 7 do Código Civil contém um conjunto específico de regras sobre contratos de fornecimento de conteúdo e serviços digitais desde 1 de janeiro de 2022, implementando a diretiva europeia sobre o assunto. Essas regras impõem requisitos de conformidade, uma obrigação de atualização enquanto o consumidor puder razoavelmente esperar atualizações e medidas corretivas que não podem ser excluídas em prejuízo do consumidor. As licenças entre empresas são, em grande parte, regidas pela liberdade contratual, razão pela qual a negociação é ainda mais importante nesse contexto.
A quem pertence o software desenvolvido para você é uma questão à parte que pega muitas organizações de surpresa. Os direitos autorais de um programa escrito por um funcionário no exercício de suas funções pertencem ao empregador, conforme o artigo 7º da Lei de Direitos Autorais (Auteurswet). Os direitos autorais de um programa escrito por um freelancer ou uma agência de desenvolvimento permanecem com essa parte, a menos que sejam transferidos por um contrato escrito. Um cliente que encomenda um software sem um contrato escrito acaba com uma licença implícita de escopo incerto, que só é descoberta no momento em que precisa vender a empresa ou trocar de fornecedor. Nosso artigo sobre licenciamento de software proprietário analisa essa relação com mais detalhes.
Os direitos que a lei lhe confere, independentemente do que diz a licença.
A legislação europeia sobre software reserva um pequeno número de direitos ao adquirente legítimo, e uma cláusula que pretenda excluí-los é nula. O conhecimento desses direitos altera o equilíbrio em caso de litígio.
O artigo 45j da Lei de Direitos Autorais (Auteurswet) permite ao adquirente legítimo de uma cópia fazer as reproduções necessárias para o uso pretendido do programa. As partes podem alterar isso no contrato, com uma exceção que não pode ser alterada: a reprodução que ocorre durante o carregamento, a exibição ou a correção de erros do programa não pode ser proibida por acordo. Uma licença que o impeça de corrigir uma falha que impeça o software de funcionar conforme o esperado é, nessa medida, inexequível.
O artigo 45k da Lei de Direitos Autorais (Auteurswet) permite ao usuário legítimo fazer uma cópia de segurança sempre que isso for necessário para o uso pretendido, e esse direito também não pode ser renunciado por contrato. O artigo 45m permite a descompilação, mas apenas sob condições rigorosas: ela deve ser indispensável para obter as informações necessárias para alcançar a interoperabilidade com um programa criado independentemente, deve ser realizada por um adquirente legítimo, as informações não devem estar prontamente disponíveis e devem se limitar às partes do programa necessárias para esse fim. A descompilação para construir um produto concorrente não se enquadra nessa exceção. O Tribunal de Justiça confirmou no caso Top System (C-13/20, 6 de outubro de 2021) que um adquirente legítimo também pode descompilar para corrigir erros que afetem o funcionamento do programa.
Um princípio adicional limita o que uma licença pode monopolizar. No caso SAS Institute (C-406/10, 2 de maio de 2012), o Tribunal de Justiça decidiu que nem a funcionalidade de um programa de computador, nem a linguagem de programação, nem o formato dos arquivos de dados utilizados por ele são protegidos por direitos autorais. O que é protegido é a expressão: o código-fonte e o código objeto. Nosso guia sobre a lei de propriedade intelectual na Holanda coloca os direitos autorais de software ao lado dos outros direitos dos quais uma empresa de tecnologia depende. Um concorrente que estuda o funcionamento do seu software e desenvolve sua própria implementação não está infringindo seus direitos autorais, por mais indesejável que isso seja.
Licenças proprietárias, de código aberto e copyleft
As licenças se dividem em três categorias, e a diferença entre elas não é ideológica, mas operacional: determina o que você deve divulgar e o que pode cobrar.
Licenças proprietárias
Uma licença proprietária mantém o código-fonte fechado e concede um direito de uso definido, geralmente não exclusivo e intransferível. As restrições constituem a essência do acordo: um número máximo de usuários ou dispositivos nomeados, um ambiente permitido, a proibição de sublicenciamento e a proibição de engenharia reversa, que só é eficaz na medida em que não conflite com os direitos legais descritos acima. O fornecedor controla as atualizações, o suporte e os preços, e o cliente arca com o custo da migração caso o produto seja descontinuado ou os termos sejam alterados. Essa dependência representa um risco contratual e é gerenciada por meio da negociação de prazos de aviso prévio, limites máximos para aumentos de preço, acordos de continuidade e, para sistemas críticos para os negócios, um depósito em garantia do código-fonte.
Licenças permissivas de código aberto
As licenças de código aberto são licenças de direitos autorais, não uma renúncia a esses direitos, e são aplicáveis da mesma forma que qualquer outra licença: viole as condições e você perderá a permissão, configurando uma infração.
Licenças permissivas como MIT, BSD e Apache 2.0 impõem poucas obrigações. Você pode incorporar o código em um produto comercial, inclusive em um produto distribuído apenas em formato binário, desde que reproduza o aviso de direitos autorais, o texto da licença e as isenções de responsabilidade. A Apache 2.0 adiciona uma licença de patente expressa e a exigência de declarar que você modificou os arquivos. Essas obrigações são fáceis de cumprir e fáceis de ignorar, sendo a omissão do arquivo de aviso a falha de conformidade com o código aberto mais comum na prática.
Licenças Copyleft
As licenças copyleft, das quais a GNU General Public License é a mais conhecida, impõem uma condição à distribuição: quem recebe o binário também deve poder obter o código-fonte correspondente, sob a mesma licença. Se você modificar o código GPL e distribuir o resultado , a obrigação copyleft se estende à obra como um todo, o que pode significar divulgar código que você pretendia manter em sigilo. Usar software GPL internamente, sem distribuí-lo, não aciona a obrigação, mas a variante Affero da GPL considera a disponibilização do software em uma rede como equivalente à distribuição, que é precisamente a situação de um provedor de SaaS.
A LGPL ocupa uma posição intermediária: você pode vincular código proprietário a uma biblioteca LGPL sem expor seu próprio código, desde que o usuário possa substituir a biblioteca por uma versão modificada. Se a vinculação estática satisfaz essa condição é uma questão que merece esclarecimentos antes, e não depois, do lançamento.
Para uma empresa que distribui software, a resposta prática é uma política de código aberto por escrito, um inventário de cada componente e sua licença, e uma verificação automatizada no processo de compilação. O inventário também é o que um comprador solicitará durante a due diligence, e sua ausência invariavelmente reduz o preço de compra.
Modelos de licenciamento e seu significado jurídico
O tipo de licença define o que você pode fazer com o código. O modelo de licenciamento define como você paga e como o uso é medido, além de determinar onde reside o risco de não conformidade.
Uma licença por usuário nomeado ou por licença física está vinculada a um indivíduo identificado. Compartilhar uma conta nomeada entre dois funcionários é uma violação, mesmo que os dois nunca trabalhem ao mesmo tempo, e é a violação que os fornecedores detectam com mais facilidade. Uma licença simultânea ou flutuante limita o número de usuários simultâneos e é controlada por um servidor de licenças; aqui, o risco não é o compartilhamento, mas sim exceder o limite máximo. Uma licença por dispositivo ou por núcleo é calculada com base no hardware, e a virtualização é onde as coisas dão errado: executar uma instância licenciada em um cluster pode, segundo as métricas de alguns fornecedores, ser interpretado como licenciar cada núcleo físico desse cluster. Leia a definição da métrica, não a lista de preços.
A escolha entre uma licença perpétua e uma assinatura envolve aspectos legais e financeiros. Uma licença perpétua concede o direito indefinido de usar uma versão específica; o suporte e as novas versões são garantidos por um contrato de manutenção separado , e o término desse contrato não remove o direito de continuar usando o que você já possui. Uma assinatura concede o direito de uso apenas enquanto você paga, portanto, o fim do contrato significa o fim do seu acesso; as questões a serem resolvidas antecipadamente são o que acontece com seus dados, em que formato eles são devolvidos e por quanto tempo o fornecedor prestará assistência no processo de cancelamento.
A implantação em nuvem e em infraestrutura local levanta questões diferentes. Com o software executado na infraestrutura do fornecedor, você está adquirindo um serviço, e o contrato deve abordar disponibilidade, tempos de resposta do suporte, subcontratados, localização dos dados e as consequências da rescisão. Quando dados pessoais são processados, você também precisa de um contrato de processamento de dados que atenda aos requisitos do artigo 28 do GDPR; um contrato de licença não cumpre essa função. Nosso artigo sobre o contrato de nuvem na Holanda descreve o que esse contrato deve abranger.
É possível revender ou transferir uma licença de software?
Por vezes, e a resposta segue uma linha europeia clara. No caso UsedSoft (C-128/11, 3 de julho de 2012), o Tribunal de Justiça decidiu que, quando um detentor de direitos disponibiliza uma cópia de um programa para download e concede, mediante o pagamento de uma taxa, o direito de usar essa cópia por um período ilimitado, considera-se que vendeu essa cópia. O direito de distribuição dessa cópia fica então esgotado, e o detentor dos direitos não pode opor-se à sua revenda, mesmo que a cópia nunca tenha sido gravada em disco. O primeiro adquirente deve tornar a sua própria cópia inutilizável no momento da revenda, e uma licença para um número definido de utilizadores não pode ser dividida e vendida em partes.
Os limites são tão importantes quanto a regra. O princípio da exaustão aplica-se a uma licença perpétua vendida por um preço fixo, não a uma assinatura ou serviço. O Tribunal confirmou no caso Tom Kabinet (C-263/18, 19 de dezembro de 2019) que o fornecimento de um livro eletrónico por download para uso permanente constitui uma comunicação ao público e não uma distribuição, pelo que não se verifica o princípio da exaustão; a decisão relativa ao software baseia-se nas disposições específicas da Diretiva de Software e não se estende a outras obras digitais. Os contratos de manutenção e suporte não são transferidos com a licença, a menos que o fornecedor concorde.
Na prática, uma licença vendida nessas condições é transferível, mesmo que haja uma proibição contratual, mas todos os demais termos são negociáveis. Antes de comprar licenças de segunda mão, solicite o histórico de propriedade, a nota fiscal original e uma confirmação por escrito do vendedor de que suas cópias foram descartadas.
Auditorias de fornecedores e o que uma empresa holandesa tem de aceitar.
A maioria dos contratos empresariais contém uma cláusula de auditoria, e os fornecedores as utilizam. Essa cláusula é o que confere ao fornecedor seus direitos, sendo, portanto, o primeiro documento a ser lido quando uma notificação é recebida.
Uma auditoria típica começa com uma carta anunciando a auditoria e solicitando dados de implantação, registros de compras e relatórios do sistema dentro de um prazo determinado. Você está vinculado ao que a cláusula prevê e nada mais. Uma cláusula bem redigida limita as auditorias a uma vez por ano, exige aviso prévio razoável, restringe o exercício ao horário comercial normal, obriga o auditor a assinar um termo de confidencialidade, prevê que o fornecedor arque com os custos, a menos que seja constatada uma deficiência material, e limita o escopo aos produtos efetivamente licenciados. Quando a cláusula for omissa, os requisitos de razoabilidade e equidade previstos no artigo 6:248 do Código Civil preenchem a lacuna, e não conferem ao fornecedor acesso irrestrito aos seus sistemas.
Aplicam-se três regras práticas. Não entregue dados brutos antes de ter realizado a medição você mesmo; a discussão quase sempre gira em torno de como o uso é contabilizado, e não sobre o que está instalado. Direcione toda a comunicação para uma única pessoa e confirme todos os acordos por escrito. E mantenha o processo dentro dos limites do contrato: um auditor que solicita acesso a sistemas fora dos produtos licenciados, ou dados pessoais de funcionários, está pedindo algo que a cláusula não prevê, e o RGPD se aplica a essa solicitação tanto quanto a qualquer outra.
Quando a falta for genuína, a reivindicação do vendedor é contratual, referente às licenças que deveriam ter sido adquiridas, e geralmente há espaço para negociação: uma compra futura em vez de taxas retroativas, isenção de penalidades em troca de um prazo mais longo ou a migração para uma métrica diferente. Quando o vendedor ameaça com um processo por violação de direitos autorais, ele deve comprovar a infração de direitos específicos, e as medidas cabíveis são as previstas na Lei de Direitos Autorais (Auteurswet), incluindo a possibilidade de recuperar a totalidade dos custos legais do processo. Nosso artigo sobre a aplicação de direitos de propriedade intelectual na Holanda descreve esse caminho, e uma disputa desse tipo geralmente começa com uma notificação extrajudicial.
As violações que aparecem nos relatórios de auditoria são consistentes: instalações que cresceram após a implantação original sem as devidas aquisições, contas de ex-funcionários que permaneceram ativas, licenças de usuário nominal compartilhadas entre pessoas, atualizações instaladas sem os direitos de atualização, uso em produção de uma licença de desenvolvimento ou teste e ambientes virtuais contabilizados de forma diferente da que o cliente havia previsto. Cada uma delas pode ser evitada com um registro preciso de direitos e implantações, conciliado pelo menos anualmente. Manter esse registro também faz parte da conformidade legal geral da organização.
As cláusulas que definem o seu risco
A maioria das licenças de software são apresentadas como não negociáveis. Para uma ferramenta comercial pronta para uso, isso geralmente é verdade e aceitável. Para qualquer coisa da qual o negócio dependa, cinco cláusulas merecem atenção especial.
O escopo da concessão vem em primeiro lugar. Deve especificar quem pode usar o software, incluindo empresas do grupo, contratados e fornecedores terceirizados; em quais ambientes, incluindo instâncias de teste, recuperação de desastres e backup; e em quais territórios. Uma concessão mais restrita do que a sua forma real de operar representa uma deficiência que pode ser facilmente descoberta.
A segunda questão é a limitação de responsabilidade. De acordo com a lei holandesa, tal cláusula é válida em uma relação comercial, mas pode ser anulada caso sua aplicação seja inaceitável segundo os padrões de razoabilidade e equidade, e não protegerá a parte cuja intenção ou imprudência deliberada tenha causado o dano. O que importa é a adequação: um limite fixado na taxa anual é defensável para uma ferramenta de baixo valor, mas indefensável para um sistema cuja falha interrompa a produção. Analise separadamente se as perdas indiretas e consequenciais estão excluídas, pois essa exclusão muitas vezes elimina a perda que de fato causaria prejuízo.
A terceira é a indenização por propriedade intelectual. Se um terceiro alegar que o software infringe seus direitos, o cliente é quem será processado por usá-lo. Uma indenização adequada obriga o fornecedor a se defender da alegação e a pagar os danos e custos resultantes, além de lhe dar a opção de obter uma licença, modificar o software ou reembolsar uma parte proporcional do valor pago. Fique atento a indenizações que tenham um limite máximo tão baixo quanto o da cláusula de responsabilidade civil geral, o que as torna praticamente inúteis.
O quarto ponto é a continuidade. O que acontece se o fornecedor deixar de dar suporte ao produto, for adquirido por outra empresa ou se tornar insolvente? Um depósito de código-fonte com um gatilho de liberação claro é a resposta usual para softwares instalados localmente, e para serviços em nuvem, os equivalentes são um plano de saída, formatos de dados acordados e um período de transição definido. A insolvência merece atenção porque a posição de um licenciado em um processo de falência na Holanda não é simples: o administrador judicial não é obrigado a continuar prestando o serviço, e quanto mais o serviço depender da atuação do fornecedor em vez de simplesmente tolerar o seu uso, mais vulnerável você estará.
A quinta cláusula é a de alteração. Os fornecedores costumam reservar-se o direito de alterar unilateralmente os termos, as métricas ou a documentação do produto. Aceitar isso sem restrições significa aceitar um preço e um escopo que você ainda não viu. Uma solução viável vincula as alterações a um prazo de aviso prévio e concede ao cliente o direito de rescindir o contrato sem penalidades caso a alteração seja substancialmente prejudicial. Orientações gerais sobre a negociação desses documentos podem ser encontradas em nosso artigo sobre contratos e acordos.
O que fazer antes de assinar e o que fazer todos os anos.
Antes de assinar, compare o uso real do software com o que foi descrito no contrato e esclareça as diferenças formalmente, em vez de resolver tudo por e-mail com um representante de vendas. Defina por escrito qual métrica se aplica e como ela será medida, com um exemplo prático para o seu ambiente. Confirme se o contrato é de licença perpétua ou assinatura e o que você manterá ao final do contrato. Verifique a cláusula de auditoria, o limite de responsabilidade, a indenização e a cláusula de alteração em relação ao valor do sistema para a empresa.
Após a assinatura, o trabalho é administrativo e é isso que evita disputas. Mantenha um registro único de direitos: contratos, formulários de pedido, faturas, chaves de licença, métricas e datas de renovação. Concilie-o com as implantações reais pelo menos uma vez por ano e sempre após uma reorganização, aquisição ou migração para infraestrutura virtual ou em nuvem, pois são esses eventos que criam déficits. Remova as contas de pessoas que saíram da empresa. Mantenha o inventário de código aberto atualizado. Nada disso é difícil e tudo é muito mais barato do que a alternativa.
Law & More Assessoramos empresas na Holanda em licenciamento de software, desenvolvimento e contratos SaaS, conformidade com código aberto e disputas com fornecedores de software, incluindo auditorias e reivindicações de violação de direitos autorais. Analisamos e negociamos termos de licença, avaliamos sua posição quando um fornecedor faz uma reivindicação e atuamos em processos judiciais quando um acordo não é possível. Se você deseja que seus contratos de software sejam analisados, entre em contato com nossos advogados.
