O Estado investe recursos públicos no desenvolvimento de sistemas de informação, mas nem sempre transforma esse investimento em conhecimento reutilizável. A legislação brasileira já oferece instrumentos para evitar esse desperdício. Falta discutir o destino que devemos dar ao software produzido com dinheiro público.
Imagine que uma prefeitura contrate uma empresa para desenvolver um sistema de agendamento de consultas médicas. O projeto é concluído, o software entra em funcionamento e a empresa recebe pelo serviço. Algum tempo depois, outra prefeitura precisa de uma solução semelhante. Em vez de aproveitar o programa já desenvolvido, contrata um novo projeto, com custos que poderiam, ao menos em parte, ter sido evitados.
Esse exemplo hipotético revela uma questão pouco discutida quando se fala em transformação digital do Estado: o que acontece com o conhecimento tecnológico produzido com recursos públicos?
A administração pública costuma tratar a contratação de software como a aquisição de um produto ou serviço destinado a resolver determinada necessidade. O sistema funciona, o contrato é encerrado e a despesa está justificada. Mas um programa de computador tem uma característica que o distingue de muitos outros bens adquiridos pelo governo: depois de desenvolvido, seu código pode ser reproduzido e adaptado a um custo potencialmente muito inferior ao de sua criação original.
Se essa possibilidade não é aproveitada, o Estado pode acabar financiando repetidamente soluções para problemas semelhantes. O desperdício não está necessariamente na primeira contratação, que pode ter sido legítima e necessária, mas na incapacidade de aproveitar o que já foi produzido.
É razoável, portanto, discutir se o software desenvolvido especificamente para a administração pública, com recursos públicos, deveria ser disponibilizado sob licenças abertas como regra, reservando o fechamento do código para situações justificadas.
A questão envolve direitos autorais, contratos administrativos e transparência, mas também diz respeito à maneira como o Estado administra o conhecimento que financia.
O que o poder público efetivamente compra
A primeira distinção necessária é entre contratar o desenvolvimento de um software e adquirir o direito de utilizar um programa que já pertence a terceiros.
Quando um órgão público contrata uma licença do Microsoft Office, por exemplo, não está financiando a criação daquele produto nem adquirindo seus direitos autorais. Está pagando para utilizá-lo nas condições estabelecidas pelo titular. O software integra uma atividade econômica privada, desenvolvida para um mercado amplo, e o pagamento pela licença não altera essa circunstância.
A situação é diferente quando a administração contrata uma empresa para desenvolver, sob encomenda, um sistema destinado às suas necessidades específicas.
Nesse segundo caso, a legislação brasileira já reconhece que os direitos sobre o programa podem pertencer ao próprio poder público.
O artigo 4º da Lei nº 9.609/1998, conhecida como Lei do Software, estabelece que, salvo estipulação em contrário, os direitos relativos ao programa desenvolvido no âmbito das atividades previstas em contrato de trabalho, prestação de serviços ou vínculo estatutário pertencem ao empregador, contratante ou órgão público, observadas as condições previstas no dispositivo.
A Lei nº 14.133/2021, que disciplina as licitações e os contratos administrativos, vai além. Seu artigo 93 determina, nas contratações ali previstas, inclusive as que envolvem desenvolvimento de software, a cessão dos direitos patrimoniais à administração pública. A regra permite que o órgão utilize e altere posteriormente o trabalho sem precisar de nova autorização do autor. A própria lei admite uma exceção para determinadas atividades de pesquisa, desenvolvimento e inovação.
Existe, portanto, uma base jurídica relevante para assegurar que o software produzido por encomenda não permaneça necessariamente sob o controle exclusivo da empresa contratada.
Isso não significa que todo programa utilizado pelo Estado lhe pertença. Os contratos podem envolver componentes de terceiros, licenças preexistentes e diferentes regimes de titularidade. Cada situação exige atenção ao objeto efetivamente contratado e aos direitos que podem ser transferidos.
O ponto interessante, porém, aparece justamente quando esses direitos já pertencem ao poder público: por que o programa continuaria inacessível a outras instituições e à sociedade?
Ser proprietário não significa tornar público
O direito autoral protege o programa de computador como uma criação intelectual. Seu titular pode, dentro dos limites legais, autorizar ou restringir a reprodução, a modificação e a distribuição do software.
Quando o titular é uma empresa privada, essas prerrogativas cumprem uma função econômica compreensível. A exclusividade pode permitir a recuperação dos investimentos realizados no desenvolvimento e a exploração comercial do produto.
Quando o titular é um órgão público, a situação merece outro exame. A aquisição dos direitos patrimoniais não deve ser considerada um fim em si mesma. Ela permite que a administração decida como o programa será utilizado, compartilhado e desenvolvido posteriormente.
É preciso distinguir duas situações jurídicas que frequentemente se confundem: um software pertencer ao Estado e um software estar disponível para utilização pública.
A primeira diz respeito à titularidade dos direitos patrimoniais. A segunda depende de uma decisão sobre o regime de acesso e licenciamento.
Um programa pode pertencer integralmente à União e continuar indisponível a qualquer pessoa ou instituição externa ao órgão que o utiliza. Da mesma forma, pode permanecer protegido por direitos autorais e, ainda assim, ser distribuído sob uma licença livre, que permita sua utilização, estudo, modificação e redistribuição.
Disponibilizar um software sob licença aberta não significa necessariamente colocá-lo em domínio público. A titularidade autoral continua existindo, mas é exercida de maneira a permitir o aproveitamento da criação por terceiros.
Essa distinção ajuda a compreender que a abertura do código não exige a eliminação dos direitos autorais. Na verdade, é justamente o exercício desses direitos que permite estabelecer uma licença aberta.
O Brasil já reconheceu institucionalmente essa possibilidade com a criação, em 2007, do Portal do Software Público Brasileiro, destinado ao compartilhamento de soluções tecnológicas. A iniciativa demonstra que a disponibilização pública de programas de computador não é incompatível com o regime jurídico da propriedade intelectual.
Entretanto, a existência desse modelo não significa que toda contratação pública de desenvolvimento de software produza automaticamente um programa aberto.
A Lei do Software e a Lei de Licitações tratam da titularidade e da cessão dos direitos. Nenhuma delas estabelece uma obrigação geral de disponibilizar publicamente o código-fonte de todos os sistemas desenvolvidos com recursos públicos.
Há, assim, uma diferença entre o que a legislação já assegura ao Estado e o que ele decide fazer com os direitos que adquiriu.
O custo de desenvolver a mesma solução várias vezes
A discussão sobre software público costuma ser associada à transparência ou à defesa do software livre. Esses argumentos são relevantes, mas existe uma razão econômica que merece atenção especial: a possibilidade de reduzir gastos públicos por meio do compartilhamento de soluções.
O desenvolvimento de um programa envolve investimentos em análise de requisitos, arquitetura, programação, testes e documentação. Depois de concluído, o código pode ser reproduzido sem que esses mesmos custos precisem ser integralmente suportados outra vez.
Isso não significa que adaptar um software seja gratuito. Sistemas dependem de infraestrutura, equipes qualificadas, manutenção, atualizações de segurança e integração com outras aplicações. Em determinadas situações, desenvolver uma nova solução pode ser mais econômico do que adaptar uma existente.
Ainda assim, a possibilidade de reutilização altera o cálculo econômico.
Se um município financia um sistema para administrar bibliotecas públicas, outro município com necessidades semelhantes deveria ao menos poder avaliar a utilização daquele código antes de iniciar uma contratação inteiramente nova. O mesmo raciocínio vale para universidades, hospitais, tribunais e órgãos administrativos que executam atividades parecidas.
Um programa criado para determinada instituição pode não atender integralmente às necessidades de outra. Mas a existência de diferenças não elimina o valor do trabalho já realizado. Parte do código, da arquitetura ou dos componentes pode ser aproveitada.
Há também um efeito importante sobre a concorrência.
Quando apenas a empresa responsável pelo desenvolvimento original tem acesso ao código e condições de modificá-lo, o contratante pode se tornar dependente daquele fornecedor. A empresa passa a ocupar uma posição privilegiada nas futuras contratações de manutenção e evolução do sistema.
A titularidade pública dos direitos patrimoniais, acompanhada da efetiva disponibilidade do código e de sua documentação, reduz essa dependência. Outras empresas podem, em princípio, oferecer serviços sobre a mesma base tecnológica, disputando contratos de maneira mais competitiva.
A abertura pública amplia essa possibilidade ao permitir que diferentes instituições, profissionais e empresas conheçam a solução, identifiquem oportunidades de reutilização e contribuam para seu aperfeiçoamento.
Nada disso impede a atividade econômica privada. Empresas podem continuar sendo remuneradas pelo desenvolvimento, pela implantação, pela manutenção e por serviços especializados. O que muda é a possibilidade de transformar o conhecimento financiado pelo Estado em um ativo de utilização mais ampla.
O investimento público deixa de beneficiar exclusivamente o órgão que contratou a solução e passa a oferecer oportunidades de aproveitamento por outros interessados.
Transparência não significa publicar tudo
Defender a abertura do software produzido com recursos públicos não implica ignorar os limites jurídicos e técnicos dessa medida.
Alguns sistemas processam dados pessoais sensíveis, informações protegidas por sigilo ou atividades relacionadas à segurança institucional. Outros dependem de componentes proprietários que não podem ser livremente distribuídos. Há também situações em que a divulgação de determinados elementos técnicos pode produzir riscos concretos para a segurança de sistemas e serviços.
Essas circunstâncias precisam ser examinadas antes de qualquer publicação.
Convém, entretanto, não confundir o código-fonte de um programa com os dados que ele processa. Um sistema destinado à administração de prontuários médicos pode ter seu código disponibilizado sem que sejam divulgadas as informações dos pacientes. Também é possível retirar credenciais, configurações internas e outros elementos sensíveis antes da publicação.
A abertura do código tampouco assegura, por si só, que um programa seja seguro. Ela permite que terceiros examinem sua implementação, mas a segurança continua dependendo de boas práticas de desenvolvimento, auditorias, atualização de componentes e correção de vulnerabilidades.
Em certas situações, uma restrição de acesso pode ser necessária. Mas a justificativa deve decorrer de um risco identificado, e não da ideia genérica de que todo sistema público precisa permanecer fechado para ser seguro.
Esse entendimento encontra apoio na lógica da Lei de Acesso à Informação, que estabelece a publicidade como regra e o sigilo como exceção, preservadas as hipóteses legais de proteção de informações. Isso não equivale a afirmar que a LAI determine a publicação integral do código-fonte de qualquer sistema governamental. A questão exige análise dos direitos envolvidos, das restrições legais e da natureza da informação.
A Lei nº 14.129/2021, por sua vez, incorpora ao Governo Digital diretrizes de eficiência, interoperabilidade, transparência e atuação integrada da administração pública. São princípios compatíveis com políticas de compartilhamento de software, embora não constituam, isoladamente, uma obrigação geral de abertura do código.
A proposta, portanto, não deve ser a publicação indiscriminada de todo programa desenvolvido pelo Estado. Deve ser a exigência de uma justificativa consistente para mantê-lo fechado quando sua disponibilização for juridicamente possível e tecnicamente adequada.
Uma regra de abertura, com exceções justificadas
Se a administração pública financia o desenvolvimento de um software e adquire os direitos patrimoniais correspondentes, parece razoável adotar uma presunção favorável à disponibilização do código sob licença aberta.
Essa presunção não precisa ser absoluta.
O órgão responsável poderia avaliar as condições jurídicas e técnicas de publicação, verificar a existência de componentes de terceiros, retirar informações que não devam ser expostas e escolher uma licença compatível com o projeto.
Nos casos em que a abertura integral não fosse recomendável, seria possível considerar a disponibilização de componentes específicos ou o compartilhamento restrito entre instituições públicas, quando juridicamente admissível.
Também seria necessário organizar a documentação, manter um repositório acessível e estabelecer responsabilidades de manutenção. Publicar milhares de linhas de código sem instruções de instalação, identificação das dependências ou informações mínimas sobre seu funcionamento pode cumprir uma formalidade, mas dificilmente favorecerá sua reutilização.
Essa política deveria começar antes mesmo do desenvolvimento. Contratos de software poderiam prever, quando compatível com seu objeto, requisitos de documentação, entrega de código-fonte, identificação de componentes de terceiros e condições para posterior distribuição.
O objetivo seria assegurar que o resultado de uma contratação pública possa continuar gerando benefícios depois de encerrado o contrato original.
É possível argumentar que a abertura exigiria trabalho adicional e poderia ampliar os custos de determinados projetos. A objeção merece consideração, sobretudo em sistemas muito específicos ou sujeitos a restrições relevantes. Mas a análise econômica não deveria considerar apenas o custo imediato de publicar o código. Também precisa levar em conta as despesas futuras com manutenção, a dependência de fornecedores e a oportunidade de reutilização por outras instituições.
Um software não se torna necessariamente mais valioso para o Estado porque seu acesso é restrito. Em muitos casos, ocorre o contrário: seu valor público aumenta quando outras pessoas podem examiná-lo, adaptá-lo e aperfeiçoá-lo.
A propriedade intelectual oferece ao titular a faculdade de decidir como uma criação será explorada. Quando esse titular é o poder público, a decisão precisa ser orientada pelo interesse coletivo e pela boa administração dos recursos disponíveis.
O Estado pode ter razões legítimas para manter determinados programas fechados. Mas, quando o software foi desenvolvido com dinheiro público, pertence à administração e pode ser compartilhado sem prejuízo relevante, a restrição merece ser explicada.
Afinal, se os contribuintes já financiaram a criação de uma solução tecnológica, é difícil justificar que outras instituições públicas precisem pagar novamente para desenvolver algo semelhante apenas porque não podem aproveitar o que já existe.