Se métodos implementados em um hardware são objeto de patentes então
vetar a patenteabilidade aos seus equivalentes lógicos em software, não seria lógico, pois ambos, como métodos industriais se
prestam a solução do mesmo problema técnico sendo sua implementação em software ou hardware uma questão de projeto. A analogia entre hardware e software está presente nos trabalhos de pioneiros da ciência da
computação como Dijkstra que em “Structured
Programming” de 1972, escreve: “como
programador por profissão, programas são aquilo do que eu trato nesta seção
cujo verdadeiro tema é a confiabilidade dos programas. Que, apesar disso eu
tenha mencionado a expressão “mecanismos” no título é porque eu considero
programas como exemplos específicos de mecanismos, e desejo expressar, ao menos
por uma vez, meu forte desejo de que muitas de minhas considerações relativas a
software são mutatis mutandis, da mesma forma relevantes para o projeto de
hardware”[1]. Greg Ahronian ao
comentar um artigo de Larry Graham que trata do mito das patentes de software argumenta: “Concordo com ele que isto constitui um mito
e que o software de fato deva ser patenteado ... a luz das teorias de Turing,
Church e Post, das ferramentas de projeto de software e hardware e da doutrina
de equivalentes, se o hardware é patenteado, então o software também deve ser”.[2] Vannevar Bush pioneiro na construção de
um computador no MIT projeto o “Analisador diferencial” era composto de rodas
dentadas e discos de modo a estabelecer uma analogia física das equações
diferenciais. Segundo Andrew Tanembaum: “Nos
primeiros computadores, a fronteira entre o hardware e o software era muito
clara. Com o passar do tempo, porém, os limites entre o hardware e o software
foram ficando cada vez mais difíceis de serem definidos por conta do acréscimo,
da remoção e da combinação de níveis (cada linguagem usa sua antecessora como
base, de modo que um computador que use essa técnica pode ser visto como um
conjunto de camadas, desde o nível da lógica digital, sistema operacional até
as linguagens de alto nível), na medida em que os computadores evoluíram. Atualmente
é muito difícil separar o hardware do software. De fato, um dos temas centrais
deste livro é que hardware e software são equivalentes logicamente. Qualquer
operação realizada por software pode também ser realizada diretamente por
hardware, de preferência depois de ser bem entendida e bem depurada. Como muito
bem colocou Karen Panetta Lentz: o hardware é simplesmente o software petrificado.
Naturalmente a recíproca também é verdadeira: qualquer instrução executada por
hardware pode também ser simulada em software. A decisão de colocar em hardware
certas funções deixando outras implementadas em software baseia-se em fatores
como custo, velocidade, confiabilidade e frequência esperada de mudanças”. [3]
Andrew Tanembaum
Um outro exemplo mostra a
analogia software / hardware como questão de projeto. Na
década de 1990 a principal preocupação dos arquitetos de computadores era a
redução dos custos de software. Essa
preocupação foi atenuada principalmente pela substituição de software por hardware simplificando desta forma a tarefa dos projetistas de software ao se criar arquiteturas de hardware mais eficientes e sofisticadas.
Exemplos desta época são as arquiteturas VAX com vários modos de endereçamento,
suporte a vários tipos de dados e uma arquitetura altamente ortogonal. Na década
de 1980 houve um retorno a arquiteturas de hardware
mais simples, com o uso de uma tecnologia de compiladores (software) mais sofisticada e o desenvolvimento de processadores com
conjuntos de instruções reduzidas RISC Reduced
instruction set computers. Os primeiros processadores RISC foram
desenvolvidos pela Universidade de Berkeley (RISC-I) e Stanford (MIPS). [4] Roger Cullis aponta
que a tecnologia RISc atendi a dois objetivos: em primeiro lugar contornava as
patentes da Intel de microprocessadores e em segundo lugar transeria os custos
de desenvolvimento dos pordutos para os desenvolvedores de software ao invés do
projeto de arquitetura de hardware sofisticadas.[5]
[1]
“Being a programmer by trade, programs
are what I am talking about and the true subject of this section really is the
reliability of programs. That, nevertheless, I have mentioned
"mechanisms" in its title is because I regard programs as specific
instances of mechanisms, and that I wanted to express, at least once, my strong
feeling that many of my considerations concerning software are, mutatis
mutandis, just as relevant for hardware design”
[2]
GRAHAM, Larry. Debunking software patent
myths, IEEE Software, julho/agosto de 2000. A resposta de Greg Ahronian foi
publicada em sua lista PATNEWS de 15 de setembro de 2000
[4]
HENESSY, John; PATTERSON, David. Arquitetura
de computadores: uma abordagem quantitativa, Rio de Janeiro:Campus, 2003,
p. 109, 112.
[5]
CULLIS, Roger. Patents, inventions and the dynamics of innovation: a
multidisciplinary study, Edgard Elgar, 2007, p.98
Nenhum comentário:
Postar um comentário