DevSecOps

9 mai, 2011

Patrão ou desenvolvedor: quem é o autor? – Parte 02

Publicidade

Na primeira parte deste artigo, vimos três casos comuns de insatisfação dos desenvolvedores em conflitos de direito autoral com seus contratantes, e o detalhamento básico da questão essencial: aos olhos da lei, quem é o detentor do direito de autor de um software criado por um profissional contratado?

Hoje daremos continuidade, tratando de uma exceção interessante (e delicada), e detalhando os três casos de insatisfação citados, além dos fundamentos que os explicam.

Não contamine seu projeto

No caso de um desenvolvedor contratado ou empregado, a Lei esclarece um caso especial: se o programa for desenvolvido  fora da relação contratual (por exemplo, nos finais de semana, se o contrato não previr nada a respeito), os direitos de autor serão exclusivamente do desenvolvedor empregado ou contratado.

Parece óbvio, mas há uma pegadinha: o mesmo parágrafo da Lei estabelece um conjunto de outras condições para esta situação. Além de ter sido feito fora do contrato, o desenvolvimento em questão  tem que ter ocorrido “sem a utilização de recursos, informações tecnológicas, segredos industriais e de negócios, materiais, instalações ou equipamentos” do empregador ou contratante.

Ou seja: se você imprimir um módulo do seu programa na impressora “da firma”, enviar o código para algum lugar usando o e-mail corporativo, gravar um executável numa mídia de backup da empresa, usar uma ferramenta de desenvolvimento adquirida pela empresa, etc., lá se foi a garantia jurídica de que o projeto pertence mesmo a você, e não ao empregador – e não seria inédito ver um empregador usar evidências deste tipo de ato para tentar evitar ou dificultar que funcionários ou ex-funcionários distribuam (mesmo que não comercialmente) softwares desenvolvidos assim.

O patrão quer mudar a licença do “meu” projeto!

Chegamos aos três casos comuns que são frequentemente trazidos a mim, e que abordarei apenas em tese – se algum deles estiver acontecendo com você, leve-o a um especialista habilitado a analisar o caso concreto!

Caso 1: era pra uso interno

O desenvolvedor se sente prejudicado porque criou um software para uso interno em benefício de seus colegas da empresa e subitamente o patrão começa a lucrar vendendo este software como um produto para outras empresas, e não oferece uma compensação adicional a quem teve a iniciativa de desenvolvê-lo.

A situação quanto aos direitos aqui é simples: geralmente, se não houver um contrato de trabalho estipulando claramente algum direito adicional do empregado, o direito autoral do que o empregado ou o contratado desenvolver no horário do expediente ou no âmbito do contrato pertence ao empregador, que só tem que oferecer como compensação o salário. Se ele resolver vender, doar, proibir o uso, etc., estará em seu direito.

Caso 2: era para ser livre

É o caso típico do desenvolvedor que passa meses ou anos desenvolvendo na empresa um software sob uma licença de código aberto. Num certo momento, os gestores resolvem que vão passar a distribuir este mesmo software apenas de forma proprietária, e mandam apagar todos os comentários e termos indicando licenciamentos livres, além de deixar de disponibilizar o código-fonte para pessoas de fora da empresa.

Aqui a situação do empregador é mais complicada por duas razões principais. A primeira é que se a licença original era mesmo de código aberto, a mudança de licença só valerá para versões futuras e por princípio será irrevogável para as cópias que já tiverem sido distribuídas anteriormente.

Algum desenvolvedor externo poderá até mesmo criar um fork do projeto a partir do código anteriormente disponibilizado – algo até comum: o projeto OpenSSH nasceu de um fork similar.

A segunda razão complicadora para o empregador nestas condições é a da autoria do código. Se 100% do código tiver sido desenvolvido internamente, ele pode relicenciar como quiser, mas se parte dele for de autores externos e estiver sob licenças livres recíprocas, o relicenciamento só poderá ocorrer se estas partes forem removidas ou substituídas.

Mas, superados os dois fatores complicadores, o patrão terá pleno direito de relicenciar, sem que com isto esteja prejudicando algum direito do empregado sobre o código que foi contratado para criar.

Caso 3: cliente que não compartilha 

Neste cenário comum, um desenvolvedor é contratado para criar um programa sob uma licença livre, entrega o projeto ao cliente e percebe que o tempo passa, o cliente até mesmo faz alterações no software, mas nunca disponibiliza o código-fonte para ninguém – apesar de ter sido desenvolvido como um software livre.

Aqui há duas situações prováveis: o cliente pode simplesmente ter decidido mudar a licença do código (como já foi visto no segundo caso), transformando-o em proprietário – afinal, legalmente o direito de autor é dele, e não seu.

Ou ele pode simplesmente estar usando uma prerrogativa que até mesmo as licenças livres menos permissivas oferecem: se ele não distribuir o executável, também não precisa disponibilizar o código-fonte, e a licença estará sendo cumprida.

Este caso é especialmente comum quando a contratação ocorre para realizar modificações sobre um projeto de software livre pré-existente.

Conclusão

Como se vê, a ausência de conhecimento sobre as definições legais que regulamentam as questões do direito de autor na relação entre cliente e prestador de serviço, ou entre patrão e empregado, causam dissabores que podem ser prevenidos quando a parte interessada tem conhecimento deles e os estipula explicitamente no contrato.

Renovo a recomendação de que consultas sobre casos concretos sejam levados a especialistas do Direito, que poderão analisar a situação em profundidade.

Afinal, embora nossa revisão tenha sido extensa, cabe o destaque de que ela se concentrou apenas em um artigo de uma Lei. Se o seu caso algum dia for chegar ao Judiciário, certamente será analisado à luz de mais normas aplicáveis, da doutrina jurídica e da jurisprudência.

Vamos torcer para que nenhum leitor deste artigo precise chegar a isto, pois as providências preventivas são sempre melhores!

***

artigo publicado originalmente no Blog do developerWorks Brasil