UNIVERSIDADE FEDERAL DE LAVRAS WEBINTEGRATOR: ESTUDO DE CASO DA ABERTURA DO CÓDIGO FONTE DE UM PRODUTO COMERCIAL LUIZ AUGUSTO EVANGELISTA RUIZ

Transcrição

1 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

2 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

3 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

4 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.

5 Sumário 1. INTRODUÇÃO HISTÓRIA DO WEBINTEGRATOR A necessidade A solução adotada: WebIntegrator versão A evolução do projeto: versão A evolução do projeto: versão O estado do projeto quando da abertura do código SOFTWARE LIVRE Definições Principais licenças SOFTWARE PÚBLICO ABERTURA DO CÓDIGO Motivação Desdobramentos CONSIDERAÇÕES FINAIS REFERÊNCIAS...24

6 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

7 WebIntegrator: Estudo de caso da abertura do código fonte de um produto comercial Luiz Augusto Evangelista Ruiz 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 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

8 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 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 Durante esse período de nove anos, o WebIntegrator teve três versões, que serão detalhadas a seguir 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

9 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

10 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 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: XML. Manipulação de objetos totalmente em memória, utilizando DOM e Referência à página por nome e não mais por número. Maior clareza na URL das aplicações seguindo o padrão projeto/página. 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 WI- Builder, 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

11 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

12 ComboRef, GridRef, DownloadRef e UploadRef: referências aos componentes definidos no projeto. Somente de pré-pagina; Componentes de enviar, receber, listar e excluir 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

13 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

14 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 e FTP. Também é 14

15 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

16 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

17 Figura 5: Componentes de pré-página Figura 6: Componentes de pós-página 17

18 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

19 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 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

20 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

21 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 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

22 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 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