Banco usa Software Livre?
Prof. Pedro Antonio Dourado de Rezende
Departamento de Ciência da Computação
Universidade de Brasília
19 de Novembro de 2010
Grandes empresas que dependem de TI, tais como os bancos, usam software livre nas suas aplicações? A pergunta surgiu numa discussão em lista jurídica, e chegou à minha atenção pelas repercussões que o contexto lhe emprestava. A rigor, hoje é praticamente impossível a um sistema informático conectado à Internet funcionar sem fazer uso de algum Software Livre. Porém, quando se trata de uso deliberado, consciente ou criterioso de Software Livre no desenvolvimento de sistemas, a pergunta costuma atrair um contexto de conotações confusas, marcado por retórica desconfiada e cética.
Essas confusões não me parecem acidentais. Muito do que vai nas decisões sobre TI se baseiam em percepções de confiança, e grandes atores nos respectivos mercados sabem bem disso. Vamos, então, separar as laranjas das bananas para entender a pergunta, e as armadilhas embutidas nas conotações que atrai, rumo a uma resposta satisfatória.
A demanda para desenvolvimento de aplicações visando a atender à missão ou o modelo de negócio de uma organização específica não produz, via de regra, software distribuível (no sentido de genericamente licenciável), pois, via de regra, seu desevolvimento é bancado, e sua utilidade é usufruida, por uma única entidade, a saber, a organização que gera sua demanda específica.
Um software de uso específico terá, no Brasil, sua titularidade (direitos autorais incidentes) regida pelo art. 4 da Lei 9609;97 (Lei de Software), quando este for desenvolvido por empregados da própria organização, ou regida por contrato específico (conforme o mesmo dispositivo), quando o software demandado for desenvolvido por empresa terceirizada. O processo de elaboração desses softwares de uso específico é, por isso, normalmente chamado de "desenvolvimento in-house".
No primeiro caso, a titularidade do software demandado será do seu (único) usuário, e no segundo caso (desenvolvimento terceirizado), a titularidade pode ser (dependendo dos termos do contrato) da empresa contratada pelo usuário que demandou dito software. Em qualquer dos dois casos, para o titular desse software, só faz sentido licenciar seu uso para outros usuários, qualquer que seja o regime de licença (proprietário ou livre) ou de contrapartida (com ou sem custos para o licenciado), se houver demanda.
Se existir, esta demanda estaria restrita, por óbvio, a organizações com missão ou modelo de negócio semelhantes (bancos, por exemplo), que contemplem demanda pela mesma funcionalidade, implementada in-house no sofware em questão. E ainda, em havendo tal demanda, o licenciamento do mesmo software a outro(s) usuário(s) só faria sentido se gerar ganhos, para o licenciador, que superem as consequências desse "licenciamento marginal". Ganhos -- no caso da organização que demandou originalmente o software ser titular do mesmo --, por exemplo, advindos de uma melhor comunicação com clientes ou parceiros, ou que superem a perda de competitividade advinda da mesma funcionalidade estar também em uso por concorrente(s),
Esta lógica tende a colocar, para outros usuários que são concorrentes em potencial, o custo do licenciamento marginal de softwares de uso específico em patamares inviáveis quando a titularidade do mesmo é retida pelo demandante original deste software. Isto ocorre quando a organização que demandou originalmente o software o desenvolveu ela mesma, ou quando reteve a titularidade no contrato de terceirização do desenvolvimento in-house (o que os bancos costumam fazer, mas organizações estatais nem sempre).
Por isso é comum pensar em software in-house como "de uso próprio" ou "não-licenciável", a exceção ficando por conta de órgãos estatais que, geralmente sob gestão inepta ou corrupta, terceirizam desenvolvimento in-house sem exigir a titularidade do "produto" contratado.
Mas nem todo software é de uso específico. Pela lógica econômica, os softwares de uso geral -- sistemas operacionais, compiladores, IDEs, suítes de escritório, etc. -- tendem a ser, ao contrário dos softwares desenvolvidos in-house, desenvolvidos para distribuição, ou seja, com vistas ao licenciamento genérico, para uma vasta gama de usuários em potencial. Devido a sua natureza, software de uso geral tende a estar na base das infra-estruturas de TI.
Ainda, pelas mesmas razões, software genericamente licenciável tende a estar também na base de qualquer infraestrutura de desenvolvimento in-house. Pela combinação desses fatores, é possível estimar que a maior parcela do trabalho de programadores hoje ocorra em regime de desenvolvimento in-house, embora a maior parcela do uso de softwares hoje ocorra em regime de licenciamento (proprietário ou livre). Tudo isso dá às diferenças entre os regimes de licenciamento importância estratégica para a questão aqui ventilada. Principalmente em casos que tratam de funcionalidade visando a atender algum interesse público.
Por que? De início, pelo fato do avanço dos regimes de desenvolvimento colaborativo e de licenciamento permissivo (do Software Livre), sobre os regimes exclusivistas baseados em escassez artificial (do Software Proprietário), ser um fenômeno de natureza "gravitacional", isto é, um fenômeno de massa crítica, num mercado sob forte efeitos de rede, numa economia de bens simbólicos (em essência, bens não-rivais): pode ser visto, como lembra Cesar Taurion, como um processo inevitável de comoditização do software, frente ao decréscimo natural na escassez de cógigo-fonte como obra autoral. O que tende a favorecer, a longo prazo, a relação custo-benefício do primeiro regime frente ao segundo, numa gama cada vez mais abrangente de usos gerais.
Diante deste quadro, é fácil perceber que qualquer política de TI de uma organização relativamente complexa, propensa a demandar desenvolvimento in-house, precisa considerar também os regimes de licenciamento genéricos, seus prós e contras, esteja ou não este desenvolvimento contemplando licenciamento marginal para clientes ou parceiros. Principalmente se a visão estratégica da organização contempla como desejável a autonomia ou independencia (a verdadeira neutralidade!) tecnológica a seu alcance. Visão que penso estar presumida, no princípio da soberania do Estado, no caso de organizações estatais por exemplo.
O regime de licenciamento permissivo do software livre é indicado, mesmo que apenas para a base de desenvolvimento in-house, para um demandante de soluções de TI que busca autonomia ou independência tecnológica. Por que? Porque, dentre outros motivos, o acesso irrestrito ao código fonte, e a natureza necessariamente aberta dos protocolos de comunicação entre componentes, deixa o demandante de software com funcionalidades específicas, e seus clientes ou parceiros se for o caso, menos vulneráveis ao poder de barganha dos fornecedores, relativa à integração do software de funcionalidade específica à(s) plataforma(s) onde irá operar. O exemplo mais loquaz deste nexo é a própria Internet, que só surgiu (como a conhecemos hoje) depois que uma base foi antes formada por uma infraestrutura licenciada em regime livre.
Esse nexo é também crucial quando a organização demandante contempla o desenvolvimento in-house terceirizado, e/ou na medida em que suas necessidades de TI e as de seus clientes e parceiros evoluem: A opção pelo regime de licenciamento livre, seja para a sua base de desenvolvimento in-house, seja para a distribuição do "produto" desenvolvido in-house, deixa-os menos vulneráveis às várias formas, presentes e futuras, de vendor lock-in.
Doutro lado, para um fornecedor de software sob demanda, a retenção da titularidade do "produto" contratado é condição legal para que ele possa obter ganhos adicionais com licenciamentos marginais desse "produto". Tal fornecedor pode, assim, oferecer no mercado variantes desse produto, as quais ele pode obter com pequenas adaptações no codigo-fonte do "produto" fornecido à primeira organização-cliente, com custo significativamente menor que o de desenvolvimento independente, e em detrimento das potenciais vantagens competitivas da primeira organização-cliente relacionadas à iniciativa de ter ela pago para ser a primeira, no seu mercado, a ter suas e-demandas específicas atendidas. Inclusive, se for o caso, a dela poder controlar a evolução da comunicação digital com seus próprios clientes.
Já quando a organização cliente em potencial é órgão do Estado, essa demanda pode ser artificalmente induzida por engenharia social, que engendra a percepção coletiva de uma "urgência" ou "obrigação" do Estado em suprir "necessidades" dos governados, como por exemplo as de "inclusão digital" e de "governança eletrônica". Essa forma de engenharia social manipula a imaginação coletiva no que concerne a qual seria o "mercado" e os "clientes" do Estado.
Temos, aqui, boas razões para que os fornecedores de softwares com funcionalidade específica se apresentem como algo mais, como fornecedores de "soluções" e não apenas de software, e para que, ao se apresentarem com suas propostas de solução, confundam seus clientes induzindo-os a acreditar que o regime de desenvolvimento in-house terceirizado e o regime de licenciamento proprietário são a mesma coisa. Não são. Mesmo que os fornecedores habituais insistam que tem que ser, há alternativa; é só insistir na prospeção contratual, e procurar melhor por fornecedores. Mesmo que a alternativa livre ofereça menos oportunidades para se camuflar corrupção em cláusulas contratuais "legítimas".
O regime de desenvolvimento colaborativo e licenciamento permissivo do Software Livre, quando clareado da fumaça que o FUD proprietário sopra sobre a cultura corporativa imersa numa sociedade que venera o consumismo, o individualismo e a competição, deixa essa organização-cliente antever a importância estratégica da autonomia e da independência tecnológica, até onde e o quanto estas são possíveis para ela, no mundo de hoje rumo ao de amanhã.
Autor
Direitos de autor:
Pedro Antônio Dourado de Rezende é matemático, professor de Ciência da Computação na Universidade de Brasília, Coordenador do Programa de Extensão em Criptografia e Segurança Computacional da UnB, Conselheiro do Instituto Brasileiro de Direito e Política de Informática, ex-conselheiro da Free Software Foundation América Latina, ex-representante da sociedade civil no Comitê Gestor da Infra-estrutura de Chaves Públicas brasileira (www.pedro.jmrezende.com.br/sd.php)
Artigo sob licença Creative Commons (CC) NC-ND 2.5.
Termos da licença em: creativecommons.org/licenses/by-nc/2.5/deed.pt
Comentário: A escolha desta licença tem, entre suas motivações, o deliberado intuito de contribuir para fragilizar o atual regime de direito autoral Brasileiro, no sentido de que isto seria socialmente sadio e legítimo, haja vista que sua jurisprudência vem hipertrofiando proteções apenas a interesses de intermediadores excessivamente gananciosos, retrógrados e parasitas.