 |
| Bellacosa Mainframe e a propriedade autoral em software |
☕ Um Café no Bellacosa Mainframe
O Software Vale Milhões. O Programador Recebe Apenas Uma Vez?
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Direitos Autorais, Contratos, Propriedade Intelectual e o Futuro da Engenharia de Software
"Quando um software gera bilhões para uma empresa durante décadas, quem realmente criou esse valor? Apenas quem investiu dinheiro ou também quem investiu conhecimento?"
Essa não é uma pergunta jurídica.
Também não é uma pergunta econômica.
É uma pergunta que, cedo ou tarde, todo profissional de tecnologia faz.
Principalmente quem trabalha em grandes empresas, bancos, seguradoras, indústrias e governos.
Imagine a seguinte situação.
Em 1998, uma equipe de desenvolvedores COBOL construiu um sistema de crédito.
Eles analisaram requisitos, desenharam arquitetura, modelaram bancos de dados, criaram algoritmos, implementaram regras de negócio, escreveram milhares de linhas de código e passaram meses testando a solução.
Hoje, quase trinta anos depois, esse mesmo sistema continua processando milhões de transações diariamente.
Movimenta bilhões de reais.
Sustenta parte do negócio.
Mas aqueles profissionais provavelmente não receberam um centavo além do salário ou do valor do contrato.
A pergunta inevitável surge.
Isso é justo?
Não existe resposta simples.
E justamente por isso vale a pena refletir.
Antes de tudo: software possui direito autoral?
Sim.
Existe um mito muito difundido de que software "não possui direito autoral".
Isso não é verdade.
No Brasil, programas de computador possuem proteção jurídica específica, inspirada no direito autoral.
Ou seja, quando um desenvolvedor escreve um algoritmo, cria uma arquitetura ou implementa uma solução original, existe autoria.
O código não surge espontaneamente.
Ele é fruto de conhecimento técnico, criatividade, experiência e capacidade intelectual.
Da mesma forma que um escritor escreve um livro ou um engenheiro projeta uma ponte, um desenvolvedor cria uma obra intelectual.
A diferença está em quem pode explorar economicamente essa obra.
Autor não é necessariamente proprietário
Esse é um dos pontos que mais confundem profissionais iniciantes.
Ser autor não significa possuir os direitos econômicos.
Na maioria dos contratos corporativos acontece exatamente isso.
O profissional continua sendo o criador intelectual.
Entretanto, os direitos de exploração comercial pertencem ao contratante.
Na prática, a empresa pode:
comercializar;
modificar;
distribuir;
licenciar;
integrar o software a outros produtos;
obter lucro durante décadas.
Tudo isso porque houve uma cessão contratual dos direitos patrimoniais.
Não significa que o desenvolvedor deixou de ser o criador.
Significa apenas que vendeu os direitos econômicos daquela criação.
O salário remunera apenas o tempo?
Aqui começa uma discussão extremamente interessante.
Muitos dizem:
"Você foi contratado para desenvolver software. O salário já paga isso."
Parece lógico.
Mas será que paga mesmo?
Vamos imaginar dois profissionais.
Ambos recebem exatamente o mesmo documento de requisitos.
O primeiro entrega um sistema funcional.
O segundo entrega um sistema:
mais rápido;
mais seguro;
mais escalável;
mais simples de manter;
preparado para integração futura;
com excelente tratamento de erros.
Os requisitos eram idênticos.
O salário também.
O resultado, porém, possui valores completamente diferentes.
O que fez a diferença?
Conhecimento.
Experiência.
Criatividade.
Arquitetura.
Engenharia.
Ou seja, aquilo que nenhum requisito consegue especificar completamente.
O software não é apenas código
Existe uma visão equivocada de que programar significa apenas transformar requisitos em linhas de código.
Na realidade, software envolve decisões intelectuais constantes.
Escolher uma estrutura de dados.
Criar um algoritmo eficiente.
Definir arquitetura.
Evitar débito técnico.
Projetar APIs.
Garantir segurança.
Melhorar desempenho.
Antecipar problemas futuros.
Nenhuma dessas atividades é totalmente mecânica.
São decisões humanas.
E essas decisões criam valor econômico.
Muito valor.
O paradoxo da engenharia de software
Curiosamente, quanto melhor um software é construído, menos as pessoas percebem sua importância.
Sistemas estáveis passam anos sem chamar atenção.
Ninguém elogia.
Ninguém comenta.
Mas basta ocorrer uma falha para todos lembrarem que aquele sistema existe.
Esse é o paradoxo da engenharia.
O sucesso costuma ser invisível.
O caso dos sistemas IBM Mainframe
Quem trabalha com IBM Z conhece esse fenômeno perfeitamente.
Existem sistemas COBOL escritos há décadas.
Foram mantidos por gerações de profissionais.
Receberam novas funcionalidades.
Migraram versões.
Ganharam APIs.
Integraram microsserviços.
Continuam processando bilhões de transações.
Quanto vale esse conhecimento acumulado?
Difícil responder.
Porque boa parte desse valor não está apenas no código.
Está nas decisões tomadas ao longo do tempo.
E os freelancers?
Talvez seja aqui que a discussão fique ainda mais delicada.
Imagine um desenvolvedor independente.
Ele dedica seis meses ao desenvolvimento de uma solução.
Recebe pelo projeto.
Entrega.
Assina a cessão dos direitos.
Cinco anos depois, aquele software tornou-se o principal produto da empresa.
Fatura milhões.
O desenvolvedor não participa desse crescimento.
Isso significa que houve injustiça?
Não necessariamente.
Mas certamente existe um debate legítimo.
O profissional vendeu apenas seu tempo?
Ou vendeu também um patrimônio intelectual que continuará produzindo riqueza durante muitos anos?
O argumento das empresas
Também é importante compreender o outro lado.
Empresas assumem riscos enormes.
Investem em:
infraestrutura;
marketing;
vendas;
suporte;
certificações;
advogados;
impostos;
treinamento;
aquisição de clientes.
Nem todo software gera lucro.
Muitos projetos fracassam.
Alguns sequer entram em produção.
Nesses casos, normalmente o desenvolvedor recebeu integralmente pelo trabalho.
Quem absorveu o prejuízo foi o contratante.
Esse é um argumento forte.
Quem assume o risco tende a receber o retorno.
Mas será que existem apenas duas opções?
Não.
Talvez o maior erro seja imaginar que existem somente dois modelos.
Modelo 1.
Pagamento único.
Modelo 2.
Royalties eternos.
Na realidade existe um enorme espaço intermediário.
Modelos que começam a surgir
Algumas empresas já experimentam soluções diferentes.
Por exemplo:
• participação nos lucros;
• bônus vinculados a metas;
• stock options;
• participação societária;
• contratos de manutenção recorrente;
• licenciamento em vez de cessão definitiva;
• remuneração variável baseada em indicadores de sucesso.
Nenhum modelo é perfeito.
Mas todos procuram aproximar quem cria valor de quem captura valor.
A Inteligência Artificial mudará essa discussão?
Provavelmente.
Hoje um desenvolvedor não entrega apenas código.
Entrega:
prompts especializados;
arquiteturas RAG;
agentes inteligentes;
pipelines de dados;
automações complexas;
bases de conhecimento;
estratégias de integração.
Grande parte desse conhecimento continua gerando valor muito depois da entrega do projeto.
Isso faz surgir uma nova pergunta.
Estamos vendendo software?
Ou estamos vendendo conhecimento especializado?
Talvez a resposta seja as duas coisas.
O conhecimento é um ativo
Durante décadas ouvimos que "dados são o novo petróleo".
Talvez exista uma afirmação ainda mais correta.
Conhecimento é o ativo mais valioso da economia digital.
É justamente esse conhecimento que transforma um requisito comum em uma solução extraordinária.
Nenhuma inteligência artificial consegue substituir décadas de experiência em negócios bancários, seguros, logística ou telecomunicações sem que alguém ensine esses conceitos.
E quem ensina?
Os profissionais.
Uma reflexão para quem contrata
Empresas precisam proteger seus investimentos.
Isso faz sentido.
Mas também precisam reter talentos.
Talvez um contrato que reconheça, ainda que parcialmente, o sucesso gerado pelo software seja mais eficiente do que simplesmente aumentar salários.
Profissionais valorizados permanecem.
Conhecimento permanece.
Qualidade permanece.
Uma reflexão para quem desenvolve
Também existe uma lição importante.
Nem todo projeto precisa significar cessão total dos direitos.
Em muitos casos é possível negociar.
Por exemplo:
manter propriedade sobre bibliotecas próprias;
reutilizar frameworks desenvolvidos anteriormente;
estabelecer contratos de manutenção;
prever bônus por desempenho;
licenciar componentes reutilizáveis.
Nem sempre o cliente aceitará.
Mas conversar sobre isso já representa uma evolução profissional.
O verdadeiro patrimônio do programador
Existe algo que nenhum contrato consegue retirar.
Sua experiência.
Cada projeto aumenta seu repertório.
Cada problema resolvido amplia sua capacidade de criar soluções futuras.
Esse patrimônio permanece com você.
E vale muito mais do que qualquer linguagem de programação.
COBOL.
Java.
Python.
Go.
Rust.
Todas mudarão.
Mas a capacidade de resolver problemas continuará sendo o maior diferencial de um engenheiro de software.
Uma pergunta que merece ser feita
Talvez o objetivo deste artigo não seja responder.
Talvez seja provocar reflexão.
Quando um sistema desenvolvido hoje continuar funcionando em 2055...
Quando ele ainda movimentar bilhões...
Quando dezenas de empresas dependerem dele...
Quando milhares de pessoas utilizarem seus serviços diariamente...
Quem criou esse valor?
A empresa?
O investidor?
O cliente?
O arquiteto?
O analista?
O programador?
O testador?
A resposta talvez seja simples.
Todos.
E justamente por isso talvez o futuro da engenharia de software caminhe para modelos de remuneração mais colaborativos, equilibrando investimento, risco e reconhecimento intelectual.
Não para transformar cada desenvolvedor em sócio de todos os projetos, mas para reconhecer que software não nasce apenas de computadores. Nasce de pessoas.
No fim, talvez a maior riqueza produzida por um programador nunca tenha sido o código-fonte. Sempre foi sua capacidade de transformar conhecimento em valor. O código apenas registra essa transformação.
Enquanto discutimos inteligência artificial, automação e produtividade, vale lembrar que toda tecnologia começa com uma ideia humana. É essa ideia que merece ser protegida, valorizada e, sempre que possível, reconhecida de forma justa.
Porque um software pode durar décadas.
Mas é o conhecimento de quem o construiu que faz toda a diferença desde o primeiro dia.
