UNIVERSIDADE FEDERAL DE
LAVRAS
WEBINTEGRATOR: ESTUDO DE
CASO DA ABERTURA DO CÓDIGO
FONTE DE UM PRODUTO
COMERCIAL
LUIZ AUGUSTO EVANGELISTA RUIZ
LAVRAS
MINAS GERAIS – BRASIL
2008
LUIZ AUGUSTO EVANGELISTA RUIZ
WEBINTEGRATOR: ESTUDO DE
CASO DA ABERTURA DO CÓDIGO
FONTE DE UM PRODUTO
COMERCIAL
Monografia apresentada a Universidade Federal de Lavras,
como parte das exigências do curso de Pós-Graduação Lato
Sensu “Produção de Software com Ênfase em Software Livre”,
para a obtenção do título de Especialização.
Orientador
Prof. Cristiano Lehrer
LAVRAS
MINAS GERAIS – BRASIL
2008
LUIZ AUGUSTO EVANGELISTA RUIZ
WEBINTEGRATOR: ESTUDO DE
CASO DA ABERTURA DO CÓDIGO
FONTE DE UM PRODUTO
COMERCIAL
Monografia apresentada a Universidade Federal de Lavras,
como parte das exigências do curso de Pós-Graduação Lato
Sensu “Produção de Software com Ênfase em Software Livre”,
para a obtenção do título de Especialização.
Aprovada em ____ de ________________ de _______.
Prof. ________________________________________
Prof. ________________________________________
_____________________________________
Orientador: Prof. Cristiano Lehrer
LAVRAS
MINAS GERAIS - BRASIL
AGRADECIMENTOS
Ao Deus dos nossos corações, que nos inspira constantemente na busca
do conhecimento.
Aos meus pais, José Ruiz e Elza Evangelista, que com o exemplo me
ensinaram a ser o que sou.
À ITX Tecnologia da Informação Ltda., especificamente aos diretores Jorge
Santana de Oliveira e Ricardo Masstalerz, pelo apoio sempre constante às
minhas iniciativas.
Sumário
1. INTRODUÇÃO......................................................................................................7
2. HISTÓRIA DO WEBINTEGRATOR......................................................................8
2.1. A necessidade.....................................................................................8
2.2. A solução adotada: WebIntegrator versão 1 ......................................9
2.3. A evolução do projeto: versão 2........................................................10
2.4. A evolução do projeto: versão 3........................................................13
2.5. O estado do projeto quando da abertura do código..........................14
3. SOFTWARE LIVRE............................................................................................19
3.1. Definições..........................................................................................19
3.2. Principais licenças.............................................................................20
4. SOFTWARE PÚBLICO.......................................................................................20
5. ABERTURA DO CÓDIGO...................................................................................22
5.1. Motivação...........................................................................................22
5.2. Desdobramentos...............................................................................23
6. CONSIDERAÇÕES FINAIS................................................................................23
7. REFERÊNCIAS...................................................................................................24
Lista de figuras
Figura 1: Tela principal do WI: Definição do projeto...............................................14
Figura 2: Tela de definição de grids........................................................................15
Figura 3: Explorar Banco de Dados.......................................................................16
Figura 4: Tela de definição de uma página............................................................16
Figura 5: Componentes de pré-página...................................................................17
Figura 6: Componentes de pós-página...................................................................17
Figura 7: Wizard de página.....................................................................................18
Figura 8: WIReport - gerador de relatórios.............................................................18
WebIntegrator: Estudo de caso da abertura do código
fonte de um produto comercial
Luiz Augusto Evangelista Ruiz
[email protected]
Resumo: Este trabalho é um resgate da história do software
WebIntegrator, produto comercial da empresa ITX Tecnologia da Informação
Ltda., que teve o seu código fonte aberto, tornando-se software livre sob a
licença GPL e hospedado no Portal do Software Público Brasileiro. O trabalho
irá contribuir para o esclarecimento dos termos comumente associados ao
software livre, apresentando também o conceito do Software Público Brasileiro.
1. Introdução
A Internet tem se destacado como o meio de comunicação que mais
rapidamente atingiu escala global de abrangência. Em poucos anos
revolucionou a forma como as pessoas se comunicam, compram, trabalham e
se divertem. O que no início era apenas um reduto de acadêmicos, a Internet
hoje é aberta a todas as idades e classes sociais, passando de um instrumento
apenas para troca de mensagens e arquivos, para uma plataforma onde se
geram negócios, de um mero repositório de textos, para um complexo
ambiente multimídia.
Essa evolução gerou uma necessidade de se construir aplicações que
utilizassem a Internet como plataforma, ganhando com isso, por um lado a
centralização das informações nos servidores, e por outro lado a
disponibilidade quase onipresente. Para atender a essa necessidade,
empresas desenvolvem frameworks que tornem o desenvolvimento das
aplicações mais rápido, mais padronizados e orientado a componentes,
possibilitando assim prazos e custos aceitáveis para o mercado.
O WebIntegrator (WI) é um exemplo dessa tendência, mas o que faz
dele um caso diferenciado é que o seu código foi aberto pela empresa que o
desenvolveu, a ITX Tecnologia da Informação Ltda., no mês de setembro de
2008.
No decorrer desse texto, procuraremos tornar conhecida a história desse
ambiente de desenvolvimento e a sua linha evolutiva. Antes de tratarmos da
abertura do código do WebIntegrator, serão abordados alguns tópicos que
ajudarão a entender melhor o cenário dos fatos. Uma definição de Software
7
Livre e os tipos de licença para Software Livre mais adotadas serão abordadas
em um capítulo específico. Será apresentado o portal de Software Público do
Governo Federal, onde o WebIntegrator está disponibilizado. A seguir será
tratado o tema da abertura do código do framework, mostrando sua motivação
e os desdobramentos dessa abertura, seguindo-se as considerações finais.
2. História do WebIntegrator
O WebIntegrator teve sua concepção em 1999. Procuraremos nesse capítulo
mostrar a história desse ambiente de desenvolvimento, desde a necessidade
que deu origem ao seu desenvolvimento, até a abertura do código fonte em
2008. Durante esse período de nove anos, o WebIntegrator teve três versões,
que serão detalhadas a seguir.
2.1. A necessidade
A empresa que deu origem ao desenvolvimento do WebIntegrator foi a Infox
Tecnologia da Informação Ltda.(INFOX), fundada em 1986 na cidade de
Aracaju, Sergipe. O diretor da empresa é Jorge Santana de Oliveira,
engenheiro civil, que trabalhou na Cobra Computadores como analista de
suporte.
No final da década de 1990 a Infox tinha como negócio programas
desenvolvidos na linguagem MUMPS, utilizando o banco de dados Caché, do
qual a Infox era representante na região. Foi quando surgiram as primeiras
demandas por aplicações Web. Jorge Santana contratou um funcionário do
Tribunal de Justiça do Estado de Sergipe, Geraldo Moraes, que iniciou a
elaboração de sites dinâmicos utilizando a linguagem Java e Caché como
banco de dados.
Após alguns sites desenvolvidos, Geraldo percebeu a necessidade de
criar facilitadores, para tornar a construção dos sites menos trabalhosa e mais
eficiente. Passou então a escrever classes genéricas que pudessem ser
utilizadas como framework das aplicações.
A Infox procurou parceria com outras empresas para fazer desse
embrião um produto que viesse a ser utilizado não apenas pelos parceiros,
mas que fosse também comercializado. Para conseguir essa parceria, procurou
apoio no Consórcio Brasileiro de Tecnologia da Informação (CBTI), do qual
faziam parte a Infox e algumas outras empresas de diversas regiões do Brasil.
Em uma reunião no Rio de Janeiro, em janeiro de 1999, Geraldo apresentou o
embrião do framework para as demais empresas, que fizeram diversas
sugestões e críticas, mas não se comprometeram diretamente com o projeto.
Como havia interesse por parte da Infox em manter o projeto para uso próprio,
Geraldo continuou o desenvolvimento, implementando as sugestões dadas
pelas empresas do CBTI.
8
2.2. A solução adotada: WebIntegrator versão 1
O projeto evoluiu ao longo de meses, chegando a um conjunto de classes que
executavam as funções mais comuns em uma aplicação Web, como por
exemplo acessar o banco de dados, montar uma tabelas, uma caixa de
seleção, fazer upload e download de arquivos. A esse conjunto de classes foi
dado nome de WebIntegrator, com a intenção de torná-lo um produto. Foi
criada a empresa NetAdvance que tinha a finalidade de manter e comercializar
o WebIntegrator.
A tecnologia utilizada pelo WebIntegrator (WI) era Java Servlet. O
ambiente típico onde o WI era instalado consistia de:
•Servidor Web (geralmente o Apache);
•Java Development Kit (JDK);
•Servlet Container (na época era comum o JServ do grupo Apache ou
JRun da Micromedia)
O WebIntegrator era composto de um servlet Java que recebia as
requisições e fazia o processamento das páginas. Cada página era composta
de um arquivo HTML que servia de modelo para a montagem feita pelo servlet.
Esse modelo (template) possuía partes delimitadas entre barras verticais ( | )
que indicavam ao servlet onde o conteúdo dinâmico seria inserido. A seqüência
do processamento era definida em arquivos texto com delimitadores, que
continham as informações. A construção de uma aplicação era feita editandose esses arquivos de configuração.
Para que o produto realmente se tornasse atraente foi criada uma
interface Web, chamada WI-Builder, que seria responsável pela manutenção
dos arquivos de configuração, facilitando ainda mais o desenvolvimento das
aplicações. O WI-Builder possuía a mesma arquitetura das aplicações por ele
geradas. Dessa forma o desenvolvimento das aplicações se tornou declarativo,
onde o desenvolvedor informava os parâmetros a serem utilizados, sem se
preocupar com a programação em si.
A utilização do WI foi imediata pela Infox, passando a ser a ferramenta
padrão para o desenvolvimento de aplicações Web, e continua sendo até a
presente data. Houve também um grande interesse por parte do Tribunal de
Justiça de Sergipe, que também adotou o WI como ferramenta preferencial de
desenvolvimento Web, especialmente pelo fato de que o WI contém um módulo
de integração com o banco de dados Caché, possibilitando o acesso a rotinas
MUMPS a partir da aplicação Java, o que aproveitou um grande legado que
aquela instituição tinha nessa linguagem. Uma outra empresa que demonstrou
interesse pelo produto foi a Tecnisys, de Brasília, que também adotou o WI
como ferramenta de desenvolvimento, devido às suas características de
facilidade de uso e baixa curva de aprendizado.
A adoção por parte da Tecnisys ocorreu de forma tão intensa, que um
dos sócios, Ricardo Masstalerz, manifestou interesse de investir no produto. No
9
final do ano 2000 foi então criada uma nova empresa, a ITX Tecnologia da
Informação Ltda, cujo único negócio seria o WI. A partir do começo do ano
seguinte (2001), foi iniciado o desenvolvimento de uma nova versão do
produto. Deste então o autor participa ativamente do desenvolvimento desse
produto.
2.3. A evolução do projeto: versão 2
Evoluir um produto de tecnologia é quase uma obrigação, devido ao
surgimento contínuo de melhores padrões e práticas. A primeira versão do WI
armazenava as informações em arquivos com texto delimitado, um padrão que
passou a ser substituído por arquivos XML, que oferecem uma estrutura mais
robusta e melhor organizada. As principais características que nortearam o
desenvolvimento da versão 2 foram as seguintes:
•Manipulação de objetos totalmente em memória, utilizando DOM e
XML.
•Referência à página por nome e não mais por número.
•Maior clareza
projeto/página.
na
URL
das
aplicações
seguindo
o
padrão
•Utilizar a terminação WSP como padrão para as páginas da aplicação.
•Conexão com banco de dados por componente, possibilitando acesso a
diferentes bases dentro de uma mesma página.
•Suporte a internacionalização.
Uma característica marcante da nova versão foi a nova interface do WIBuilder, utilizando ícones em barra de ferramentas, melhorando
consideravelmente a usabilidade do produto.
Novos assistentes foram desenvolvidos para auxiliar tarefas rotineiras do
desenvolvimento de uma aplicação. Foi criado um assistente para SQL, que
orientava a criação da expressão de consulta, listando as tabelas existentes na
base de dados. Uma vez selecionada a tabela eram mostrados os campos, que
podiam também ser selecionados em uma ordem da preferência do
desenvolvedor. Os campos poderiam ter função de agregação (soma, média,
etc.), expressões para filtro de registros e opção de ordenação (ascendente ou
descendente).
Um outro assistente foi o gerador de página, partindo de uma expressão
SQL. O gerador analisava a consulta, verificando na base de dados os
metadados dos campos (tipo, tamanho) e gerava uma página com um campo
de formulário para cada coluna da expressão SQL fornecida. Também havia a
opção de se gerar os componentes necessários para fazer a persistência das
alterações efetuadas através do formulário da página.
10
O principal assistente, que mais contribuiu para o sucesso do WI, foi o
assistente de páginas (WIzard), que consistia em uma interface onde o
desenvolvedor tinha uma pré-visualização da página que estava sendo editada,
podendo selecionar cada um dos campos e alterar as suas propriedades. Mas
apenas essa característica não trazia os benefícios esperados, por isso foram
criados componentes de página, que passaram a ser o padrão de
desenvolvimento do WI.
Um componente de página é um trecho de código HTML préprogramado, contendo propriedades que podem ser parametrizadas. Cada
projeto podia ter o seu conjunto de componentes específicos ou utilizar um
conjunto comum a todos os projetos feitos com o WI. Esse conceito de
reutilização de componentes foi o fator inovador e que trouxe um expressivo
ganho de produtividade e redução da curva de aprendizado, uma vez que os
componentes eram desenvolvidos por especialistas que garantiam o seu
funcionamento. As páginas eram feitas como uma linha de montagem,
escolhendo-se os componentes correspondentes a cada um dos campos de
formulário ou qualquer outro trecho da página.
O WI passou a ser um conjunto de componentes de lógica e
componentes de interface. Os componentes de lógica poderiam ser utilizados
para montar uma página, isso é, eram processados entre a requisição e a sua
resposta. Esses componentes recebiam o nome de componentes de prépágina. Os componentes que eram definidos para serem chamados depois que
o usuário submetia os dados eram chamados de componentes de pós-página.
Ambos os tipos de componentes eram classes Java que executavam
operações específicas e que tinham uma interface no WI-Builder, onde o
desenvolvedor informava os parâmetros necessários para a execução da lógica
pré-programada no componente. Um outro tipo de componente, o componente
de projeto, definia artefatos comuns a todo o projeto, que eram referenciados
em diferentes páginas.
Os componentes de projeto eram:
•Upload: definiam os dados para envio de arquivos do cliente para o
servidor;
•Download: definiam os dados para envio de arquivos do servidor para o
cliente;
•Combo: definição de conteúdo a ser utilizado em caixas de seleção nas
páginas (select);
•Grid: definição de conteúdo a ser utilizado em tabelas nas páginas
(table);
•Event: definição de expressões SQL que seriam executadas com
submissão parcial de dados. Tratava-se de uma inovadora implementação do
que hoje se tornou popular como AJAX.
Os principais componentes de pré-página e de pós-pagina eram:
11
•ComboRef, GridRef, DownloadRef e UploadRef: referências aos
componentes definidos no projeto. Somente de pré-pagina;
•Componentes de email: enviar, receber, listar e excluir email de um
dado servidor;
•Object: componente que buscava as informações na base de dados e
trazia para o contexto de variáveis do WI;
•List: componente que criava uma lista de dados buscados na base de
dados informada. Somente de pré-página;
•Update: componente que cuidava da persistência dos dados na base de
dados, utilizando uma expressão SQL para a atualização;
•WIConnector: componente que fazia uma chamada a uma classe
desenvolvida especificamente para um dado fim. Era um importante ponto de
extensão do WI, suportando lógicas específicas escritas em Java pelo usuário
do WI.
O WI também tinha um módulo gerador de relatórios, baseado na API
JasperReports(JASPERREPORTS). Esse gerador consistia de uma interface
Web para a definição dos relatórios, um assistente para a geração e um
módulo de integração com o WI-Engine, permitindo que os relatórios fossem
chamados a partir das páginas do WI.
Havia também um módulo de indexação e busca textual, o WISearch,
baseado na API Apache Lucene (LUCENE), que permitia a indexação de
documentos e a pesquisa por partes do texto, com diversas funcionalidades
como proximidade de palavras, operadores lógicos, etc.
A funcionalidade de geração de gráficos, chamada de WIGraph, era
baseada na API JFreeChart (JFREECHART), possibilitando a criação de
gráficos em fatias, em barras, de linhas e de áreas.
O crescimento do produto foi muito expressivo com essa nova versão,
especialmente em Brasília, Aracaju e Salvador. Os principais clientes eram:
Tribunal de Justiça de Sergipe, Tribunal de Justiça da Bahia (IPRAJ), Tribunal
de Justiça do Distrito Federal, Prefeitura Municipal de Aracaju, SESI (DF),
FAPESB (Fundação de Amparo à Pesquisa da Bahia), PRODAM
(Processamento de Dados do Amazonas), etc.
Diversos projetos começaram a ser desenvolvidos tanto pela Infox como
pela Tecnisys, que estruturaram-se como fábrica de software, utilizando o WI
como ferramenta exclusiva de desenvolvimento.
Com o crescimento dos projetos desenvolvidos, surgiu a necessidade de
uma nova atualização no WI, tornando-o mais aderente a padrões e utilizandose mais as funcionalidades do container Web do que as implementações
proprietárias. Foi feito um estudo das alterações e iniciado o desenvolvimento
da versão 3 do produto. Isso foi no início do ano de 2004.
12
2.4. A evolução do projeto: versão 3
A aderência a padrões é um fator muito importante para aumentar a vida útil de
um produto de software. Com o WI não foi diferente. Com o estabelecimento do
Tomcat, do grupo Apache, como padrão da implementação da tecnologia J2EE
para Web, houve a necessidade de se adaptar o WI para esse container. Além
disso surgiu a necessidade de se deixar o projeto gerado pelo WI independente
do próprio WI, possibilitando o uso de qualquer outra ferramenta para editar as
páginas. Isso era exigência de alguns clientes.
Para atender a essas necessidades foi concebida uma nova forma de
gerar as páginas a partir dos modelos. Como dito anteriormente, na versão 2
haviam modelos HTML com partes variáveis delimitadas com barras verticais
(pipes '|'), que eram processados pelo WI-Engine quando a página era
requisitada. Na versão 3 as páginas passaram a ser geradas como JSP, isto é,
em vez de serem processadas na requisição, eram pré-processadas no
desenvolvimento e geradas como JSP, para serem chamadas normalmente
pelo container Web (Tomcat). Isso possibilitou o uso de mais funcionalidades
do Tomcat, como por exemplo clusterização, dentre outras.
As mudanças no WI-Builder foram mais de layout, para marcar uma
nova identidade visual da versão e melhorar a usabilidade, através da mudança
de algumas barras de ferramentas. Essas mudanças não foram tão profundas
como as feitas no WI-Engine, que passou por uma reestruturação para poder
suportar as chamadas a partir das páginas JSP.
Com essas mudanças e como resultado do sucesso alcançado pelos
projetos anteriores, a ferramenta se consolidou ainda mais, possibilitando o
desenvolvimento de projetos arrojados, como por exemplo o sistema do
Tribunal Regional Federal da quinta região (Nordeste), com sede em Recife.
Uma parte desse projeto é o Juizado Virtual, cujos processos tramitam
somente por via digital, dispensando o uso de papel. O sistema está em uso
em todos os estados da quinta região, com base de dados que chegam a meio
terabyte.
Com o passar do tempo, algumas melhorias foram acrescentadas ao
produto, sempre visando melhorar a performance ou facilitar tarefas repetitivas.
Foi feito um levantamento entre os clientes das principais demandas. Esse
levantamento resultou em reuniões chamadas de WIMeeting, que aconteceram
em Jaraguá do Sul, Santa Catarina, em Curitiba e em Aracaju. Nessas
reuniões eram definidos os rumos a serem tomados pelo produto e quais as
novas funcionalidades que seriam implementadas. Também era um momento
de troca de experiências entre os usuários do WI, onde cada um mostrava um
projeto que considerasse interessante, demonstrando detalhadamente sua
implementação.
13
2.5. O estado do projeto quando da abertura do código
A abertura do código será assunto de um capítulo posterior, mas apenas para
fechar o ciclo do desenvolvimento do WI pela ITX, será descrito o estado do
projeto que estava, na época da abertura do código (setembro de 2008), na
versão 3.3.
Com o aumento da base instalada de clientes e as especificações
definidas nos encontros WIMeeting, as novas implementações foram
agregadas. Dentre elas podemos destacar:
•Funcionalidade de registro de acesso ao banco de dados (logs) de fácil
definição, possibilitando uma auditoria de todas as expressões de consulta
submetidas a qualquer uma das bases de dados definidas no projeto.
•Single Sign On: identificação única do usuário que utiliza diferentes
aplicações geradas pelo WI.
•Melhorias na implementação de webservices, tanto cliente como
servidor.
•Mecanismo de renderização parcial de página (AJAX), não apenas para
consultas como fazia o WIEvent, mas para qualquer região da página.
•Controle de transações ao longo de uma requisição. O desenvolvedor
indica onde começa e termina uma transação.
As cópias de tela a seguir ilustram a interface do WIBuilder, nas suas
principais definições.
Figura 1: Tela principal do WI: Definição do projeto
A figura 1 mostra a tela de definições do projeto. É a primeira tela que é
aberta quando se cria um projeto no WI. Nela estão os links para definição do
acesso às bases de dados e dos servidores de email e FTP. Também é
14
possível ver os links para definição dos componentes de projeto: combos,
downloads, events, grids, uploads e webservices.
A figura 2 mostra a tela de definição de um grid, onde temos o campo da
expressão de consulta (SQL), o identificador do grid, a quantidade de registros
a ser mostrada por página, e outros campos mais. Todos os componentes que
acessam uma base de dados tem alguns campos em comum: a expressão de
consulta SQL, o seletor da base de dados a ser utilizada e o campo filtrar, que
permite a retirada de caracteres do conteúdo das variáveis, por questão de
segurança, como é o caso do símbolo '%' que é um coringa em uma expressão
SQL e pode gerar consultas mais demoradas que o esperado.
Para facilitar o teste das expressões de consulta existe uma tela
chamada Explorar BD, mostrada na figura 3, que permite que o desenvolvedor
escreva a expressão SQL e veja os registros retornados por ela.
Figura 2: Tela de definição de grids
15
Figura 3: Explorar Banco de Dados
Para as páginas do projeto temos 3 telas: a figura 4 mostra a tela de
definição da página, a figura 5 mostra a tela dos componentes de pré-página e
a figura 6 mostra a tela dos componentes de pós-página.
Figura 4: Tela de definição de uma página
16
Figura 5: Componentes de pré-página
Figura 6: Componentes de pós-página
17
Para a definição dos componentes de interface, temos a tela do Wizard,
mostrada na figura 7.
Figura 7: Wizard de página
Figura 8: WIReport - gerador de relatórios
A figura 8 mostra a tela do WIReport, o gerador de relatórios baseado na
API JasperReports, que possibilita a geração de relatórios em diversos
formatos: HTML, PDF, XLS, etc.
18
3. Software Livre
Antes de tratarmos o assunto da abertura do código do WI, é conveniente
esclarecer o que é Software Livre e o que é Software Público. Esse capítulo
tratará do Software Livre e o próximo do Software Público.
O termo Software Livre é frequentemente alvo de mal-entendidos,
devido ao uso indiscriminado da expressão. Procuraremos definir bem esse
conceito, de forma a contribuir para o esclarecimento dos diferentes tipos de
licenciamento de software.
É comum se confundir Software Livre com software gratuito, ou
freeware. Como exemplo da diferença podemos citar o Internet Explorer da
Microsoft, que é um software gratuito, mas não é um software livre, pois o seu
código fonte é propriedade da Microsoft. Para ficarmos no domínio dos
navegadores, podemos citar o Firefox como um Software Livre, pois além de
gratuito, o código fonte é aberto.
3.1. Definições
A seguir serão listadas algumas expressões relacionadas ao licenciamento de
software e suas principais características.
•Software Livre: todo software que possui as quatro liberdades definidas
por Richard Stallman, o criador da Free Software Foundation (FSF). São elas:
usar, copiar, modificar e distribuir livremente o software. Geralmente um
software livre é gratuito, mas nem sempre é assim, como é o caso do Red Hat
Enterprise Linux, que é uma distribuição GNU/Linux, vendido pela Red Hat.
•Software Gratuito (Freeware): software que é distribuído gratuitamente,
mas não tem o código fonte aberto. Como citamos anteriormente, o Internet
Explorer da Microsoft é um software gratuito que não é software livre.
•Software Proprietário: aquele que é distribuído com uma licença para
uso e cujo código fonte é propriedade da empresa que o desenvolveu.
Normalmente há um contrato de uso, apresentado durante a instalação do
software, com o qual o usuário deve estar de acordo para poder utilizá-lo.
•Software em Domínio Público: aquele em que o autor abre mão dos
direitos autorais, tornando o código público. Não deve ser confundido com
Software Público, que será tema do próximo capítulo.
•Software Open Source: é o software que tem o código aberto mas não
tem o caráter ideológico do Software Livre, atendo-se mais ao aspecto técnico.
A organização mais expressiva nesse tipo de software é a OSI (Open Source
Initiative), fundada por Eric Raymond entre outros.
19
3.2. Principais licenças
A licença de Software Livre mais comum é a GNU-GPL (General Public
License) da Free Software Foundation (FSF). Essa é a licença utilizada no
sistema operacional GNU/Linux e em diversos outros programas de Software
Livre. É considerada a menos restritiva de todas as licenças, pois garante que
um software com ela licenciado sempre será livre, obrigando todo trabalho
derivado a ter o mesmo tipo de licença. Um usuário pode realizar alterações
em um software sob essa licenças e não distribuí-lo, mas se vier a distribuir,
necessariamente ele será GPL também.
A licença GNU-LGPL (Lesser General Public License) é bastante
semelhante à GPL, mas permite que o software por ela licenciado possa gerar
outros derivados que não necessariamente tenham que ter a mesma licença.
Por esse motivo, essa licença também é chamada de Library General Public
License, ou seja, licença GPL para bibliotecas. Um grande número de
bibliotecas de software usam essa licença. O WI utiliza diversas bibliotecas
com essa licença, como por exemplo JasperReports, JFreeChart.
Uma licença que também é muito popular é a licença da Apache
Software Foundation (ASF), devido ao grande número de projetos mantidos
pelo grupo. Entre os mais conhecidos temos o Apache Server, Ant, Lucene,
MyFaces, Tomcat, Struts, Maven, entre outros.
4. Software Público
O conceito de Software Público é muito novo e consolida diversas iniciativas de
facilitar a disponibilização de software, tanto entre organismos do governo
como entre este e a sociedade.
Desde o ano de 1995, empresas estaduais de informática, reunidas na
Associação das Entidades Estaduais de Tecnologia da Informação e
Comunicação (ABEP), vem discutindo a questão do software público brasileiro.
As discussões eram inicialmente no sentido de compartilhar soluções entre
entidades públicas, evitando que o governo pagasse duas vezes por uma
mesma coisa (MEFFE, Um primeiro modelo para o software público).
Graças ao avanço tecnológico do software livre e à consolidação da
licença GPL como sendo totalmente compatível com a legislação brasileira, os
administradores públicos começaram a ganhar maior segurança para o
compartilhamento de soluções. A primeira solução liberada com a licença GPL
foi o sistema de inventário CACIC, da Dataprev, Empresa de Tecnologia e
Informações da Previdência Social. Esse fato, entre outros, foi responsável
pela retomada do debate sobre software público, resultando no
amadurecimento do conceito.
20
Segundo Corinto Meffe, atual gerente de projetos do Departamento de
Integração de Sistemas, Secretaria de Logística e Tecnologia da Informação,
do Ministério do Planejamento Orçamento e Gestão:
[…] poderia definir que o software público é aquele que trata o
software como um bem público e imputa responsabilidades
para os entes governamentais no processo de tornar disponível
uma solução […] (MEFFE, Entrevista concedida a Rafael
Evangelista)
A criação do Portal do Software Público Brasileiro foi o resultado
concreto do amadurecimento do conceito, estabelecendo um modelo com as
seguintes características:
•O produto: tratar o software como um produto acabado, pronto para
funcionar.
•Os serviços associados: conjunto de serviços como página na Internet,
fórum e lista de discussão para desenvolvimento, suporte e projetos,
ferramenta de controle de versão e documentação do sistema.
•A prestação de serviços: criar facilidade na relação do governo com o
cidadão que acessa o serviço, mantendo uma equipe de atendimento para a
comunidade.
•A gestão da colaboração: abrange incentivar a colaboração entre
desenvolvedores e usuários, estruturar instrumentos de gestão e controles e a
definir parâmetros de controle de qualidade.
O Portal teve o seu lançamento no 8º Fórum Internacional de Software
Livre, em Porto Alegre, no dia 12 de abril de 2007. Conta atualmente com 17
comunidades que disponibilizam soluções nas áreas de educação,
geoprocessamento, informática, administração e saúde.
Ainda segundo Meffe (MEFFE, A consolidação do Software Público em
2008) a consolidação do conceito do software público está mais próxima depois
de uma menção explícita do Portal na Instrução Normativa para Contratação de
Serviços de Tecnologia da Informação do Governo Federal (IN04). Esta
Instrução Normativa estabelece que antes de se contratar um serviço de
software, deve-se considerar as soluções que compõe o acervo do Portal.Outro
fator que pode consolidar o conceito é a adesão do meio acadêmico
(SOFTWARE PÚBLICO, Academia vai colaborar com o Portal do Software
Público) e municipal (SOFTWARE PÚBLICO, Prefeituras brasileiras vão
disponibilizar soluções no Portal do Software Público).
No meio acadêmico destaca-se a colaboração de cinco instituições:
Centro Federal de Educação Tecnológica de Campos (RJ), Universidade
Federal de Lavras (MG), Universidade Federal de Santa Catarina, Universidade
de Brasília (DF) e Faculdade Jesus Maria José (DF). Essas instituições vão
cooperar com as soluções do Portal, que terá uma área específica para o
cadastro das instituições de ensino, dos projetos e dos alunos.
21
No meio municipal, as prefeituras de Itajaí (SC) e de Bagé (RS) vão
disponibilizar no Portal soluções desenvolvidas para municípios, com a
intenção de oferecer sistemas que atendam às necessidades das prefeituras.
Isso será feito em conjunto com o Projeto Via Digital (VIA DIGITAL). O Portal
também irá ter uma área destinada a aumentar a interação entre os municípios
e estimular o uso das aplicações disponíveis.
5. Abertura do código
A ITX Tecnologia da Informação, empresa que desenvolveu o WI sempre foi
adepta do software livre, fazendo uso de bibliotecas com licença LGPL e
recomendando o uso de servidores com sistema operacional GNU/Linux. O
módulo WIEngine, que acompanha cada projeto gerado pelo WI, a partir da
versão 3 passou a ser de código aberto e livre para ser distribuído junto com os
projetos.
Sempre houve uma tendência à abertura do código do produto como um
todo. Em vários momentos foram feitos estudos sobre a viabilidade da abertura
do código e como isso poderia beneficiar também a empresa, não apenas à
comunidade, uma vez que o único negócio da empresa é o WI.
5.1. Motivação
A principal motivação para a abertura de código do WI foi o amadurecimento do
conceito de software público. Ricardo Masstalerz, sócio da ITX, sempre
acompanhou de perto a evolução do portal e das políticas governamentais de
incentivo ao software livre, por entender que o processo colaborativo gera
vantagens não apenas para a empresa, como também para toda a comunidade
(SOFTWARE PÚBLICO, A empresa privada ITX Tecnologia disponibiliza
solução no Portal do Software Público).
Apesar da tendência para a abertura do código, sempre houve por parte
da ITX a preocupação com demandas por suporte e o apoio a ser dado à
comunidade de usuários. Quando o Portal do Software Público se consolidou
como um ecossistema completo para o apoio a essa iniciativa, a tendência
passou a se tornar uma realidade.
No dia 24 de setembro de 2008, no evento Linux Park na cidade de
Brasília, foi assinada a carta de lançamento do WebIntegrator no Portal do
Software Público. Assinaram a carta Rodrigo Assumpção, Secretário-Adjunto
de Logística e Tecnologia da Informação e Ricardo Masstalerz Sócio Diretor da
ITX Tecnologia da Informação (SOFTWARE PÚBLICO, WebIntegrator
disponível no Portal do Software Público).
22
5.2. Desdobramentos
A aceitação da abertura do código por parte da comunidade foi surpreendente,
como ficou demonstrado pela rápida adesão dos usuários na comunidade do
WI. Em poucos dias chegou ao número de 500 usuários. Em um mês chegou a
1083 usuários, um crescimento muito expressivo.
A comunidade do WI recebeu diversas contribuições por parte de
desenvolvedores mais avançados que prepararam vídeo-aulas, apresentações
e tutoriais, disponibilizando esse material na área de arquivos da comunidade.
A expectativa agora é que a comunidade possa contribuir com
sugestões de melhorias, notificação de erros e correções, uma vez que o Portal
disponibiliza uma ferramenta de gerenciamento de versões e tickets chamada
Trac (TRAC) que permite aos usuário cadastrados na comunidade acessar o
código fonte através do Subversion, possuindo um wiki integrado para facilitar a
documentação.
6. Considerações finais
A abertura do código fonte de um produto comercial estável é sempre uma
decisão difícil de ser tomada, uma vez que a venda do produto pode ser
reduzida praticamente a zero. Essa decisão deve ser baseada em um novo
modelo de negócio, que leve em conta prestação de serviços como
treinamento, consultoria, mentoring, customização, etc.
A ITX Tecnologia da Informação não foi a única empresa que abriu o
código fonte de um produto através do Portal do Software Público Brasileiro. A
empresa Light Infocon Tecnologia S/A disponibilizou duas soluções, a solução
LightBase, que é um banco de dados textual multimídia e a solução
GoldenDoc, um conjunto de frameworks Web para a implantação de soluções
voltadas para o gerenciamento de informações e arquivos eletrônicos.
O que se espera dessas iniciativas é que haja um melhor
aproveitamento por parte de todos os envolvidos: empresas, governo e
cidadãos, onde todos possam ser beneficiados com produtos de melhor
qualidade, abertos e gratuitos, características apenas possíveis graças ao
Software Livre.
23
7. Referências
ABEP. Associação Brasileira de Entidades Estaduais de Tecnologia da
Informação e Comunicação. Disponível em: http://www.abep.sp.gov.br/. Acesso
em: 21 out. 2008.
FSF. Free Software Foundation. Disponível em: http://www.fsf.org. Acesso em:
18 out. 2008.
INFOX. Infox Tecnologia da Informação
http://www.infox.com.br. Acesso em: 22 out. 2008.
Ltda.
Disponível
em:
IN04.
Instrução
Normativa
Número
4.
Disponível
em:
http://www.governoeletronico.gov.br/anexos/instrucao-normativa-in-nb0-4.
Acesso em: 23 out. 2008.
JASPERREPORTS. JasperReports. Disponível em: http://www.jaspersoft.com/
JasperSoft_JasperReports.html. Acesso em: 24 out. 2008.
JFREECHART. JFree Chart. Disponível em: http://www.jfree.org/jfreechart/.
Acesso em: 22 out. 2008.
LUCENE. Apache Lucene. Disponível em: http://lucene.apache.org/. Acesso
em: 22 out. 2008.
MEFFE, Corinto. Um primeiro modelo para o software público. Disponível em:
http://computerworld.uol.com.br/governo/corinto_meffe/idgcoluna.2007-0323.2475687668. Acesso em: 19 out. 2008.
_____. Corinto Meffe define software público. Entrevista concedida a Rafael
Evangelista. Disponível em: http://cienciaecultura.bvs.br/scielo.php?pid=S000967252006000300004&script=sci_arttext. Acesso em 19 out. 2008.
_____. A consolidação do Software Público em 2008. Disponível em:
http://computerworld.uol.com.br/governo/corinto_meffe/idgcoluna.2008-0925.5912621469. Acesso em: 19 out. 2008.
OSI. Open Source Initiative. Disponível em: http://www.opensource.org/.
Acesso em 23 out. 2008.
SOFTWARE PÚBLICO. Portal do Software Público Brasileiro. Academia vai
colaborar com o Portal do Software Público. Disponível em:
24
http://www.softwarepublico.gov.br/web/one-entry?entry%5fid=5668487. Acesso
em: 21 out. 2008.
_____. Portal do Software Público Brasileiro. Prefeituras brasileiras vão
disponibilizar soluções no Portal do Software Público. Disponível em:
http://www.softwarepublico.gov.br/web/one-entry?entry%5fid=5229291. Acesso
em: 21 out. 2008.
_____. Portal do Software Público Brasileiro. A empresa privada ITX
Tecnologia disponibiliza solução no Portal do Software Público. Disponível em:
http://www.softwarepublico.gov.br/web/one-entry?entry_id=5999414.
Acesso
em: 21 out. 2008.
_____. Portal do Software Público Brasileiro. WebIntegrator disponível no
Portal
do
Software
Público.
Disponível
em:
http://www.softwarepublico.gov.br/web/one-entry?entry_id=6441983.
Acesso
em: 21 out. 2008.
TRAC. Trac Project. Disponível em: http://trac.edgewall.org. Acesso em: 20 out.
2008.
VIA DIGITAL. Portal Via Digital. Disponível em: http://www.viadigital.org.br.
Acesso em: 17 out. 2008.
25