Juan Reig Director de la Conferencia Conferencia Internacional de Software Libre BIENVENIDA DEL DIRECTOR DE LA CONFERENCIA

Transcripción

1

2 BIENVENIDA DEL DIRECTOR DE LA CONFERENCIA Bienvenidos a la Conferencia Internacional de Software Libre! Bienvenidos a Málaga! Bienvenidos a una de las regiones europeas que más apuestan por el software libre: Andalucía! Quiero comentarle en más detalle datos sobre el evento que se celebra en el Palacio de Ferias y Congresos de Málaga desde el 18 al 20 de febrero y explicar los pensamientos que nos han llevado a organizarla como lo hemos hecho. Esta Conferencia Internacional pretende trascender lo puramente técnico o instrumental y abordar el software libre como un elemento capacitante para la extensión de la Sociedad de la Información y el Conocimiento. No solo como el componente básico de acceso o movilización, sino como posibilitador de la utilización de los servicios y de aquellos factores que nos pueden generar beneficios a nivel personal y social. Desde ese punto de vista hemos querido abordar temas, formularnos peguntas y buscar respuestas para cuestiones tales como: El futuro del movimiento de software libre, El papel de las Administraciones públicas en su expansión y desarrollo, Son viables los modelos de negocio actuales para las empresas de software libre?, Desarrollo sostenible y software libre, Proyectos destacados a nivel global de uso de software libre, Globalización y Software libre, Los nuevos espacios sociales y su relación con el software libre, o la necesidad de analizar políticas públicas y el papel que juegan las instituciones en su difusión. También queremos analizar las consecuencias que las tecnologías y los servicios de la Sociedad de la Información van a tener en nuestro entorno y espacio social, amén de la filosofía subyacente detrás de esos movimientos y la necesidad de definir (o no) criterios éticos para ese nuevo marco. La estructura de la Conferencia está organizada en torno a la celebración de dos sesiones plenarias, al comenzar y al finalizar las jornadas y las sesiones paralelas de contenido temático. Las sesiones plenarias abordan específicamente los temas de gran interés mencionados y suponen una profundización en aquellos elementos relacionados con los tres ejes temáticos centrales del evento: los aspectos técnicos, el uso y las aplicaciones del software libre y los aspectos relacionados con negocios, estrategias y políticas. Estoy convencido que hemos conseguido reunir a muchos de los principales actores implicados a todos los niveles en el desarrollo e implantación de soluciones basadas en software libre, y que la celebración de la Conferencia Internacional va a constituir un antes y un después para muchos de los participantes. La audiencia está integrada por responsables de gobiernos y administraciones publicas, responsables de grandes y pequeñas empresas, representantes de la academia y por supuesto muchos participantes relacionados con aspectos técnicos provenientes de diversos países del mundo y todos los continentes. Todos con una vinculación común: el software libre y la fuente abierta. En la organización estamos muy ilusionados con poder reunir, en un foro de discusión constructivo y abierto, a tantos hombres y mujeres con ese objetivo solidario de impulsar el desarrollo del software libre en beneficio del conjunto social. Hemos trabajado para que la Conferencia Internacional sea un lugar de encuentro, de contacto e intercambio y por supuesto, un espacio donde compartir y enriquecer ideas para definir un futuro mejor. Juan Reig Director de la Conferencia Conferencia Internacional de Software Libre

3 WELCOME FROM THE CONFERENCE CHAIRMAN Welcome to the Open Source International Conference! Welcome to Malaga! Welcome to one of the European regions that most supports Free software: Andalusia! I would like to explain in more detail, information on this conference being held at the Trade fair and Congress Centre, Malaga, from the 18th until the 20th of February, the rationale behind it and the way in which it has been organized. It is the intended purpose of this International Conference to go beyond the purely technical or instrumental aspects and tackle free software as an element capable of extending the Information and Knowledge Society. Not only as the basic component of access and mobility, but also as an enabler in making a reality the use of services and other factors that could generate benefits at personal and social levels. From this point of view it has been our intention to approach themes, pose questions and find answers for issues related to: The future trends of free software, the role of Public Administrations and their expansion and development. Whether or not current business models are viable in a free software environment? The sustainable development and free software, Projects accomplished at a global level of use of free software, Globalisation and Free Software, New social spaces and their implication with free software, or the need to analyse public policies and the role that the institutions play in their diffusion. Moreover we wish to analyse the consequences that these technologies and services of the Information Society are going to have in our environment and social space, with relation to the underlining philosophy of these movements and the need to define (or not) ethic criteria for this new scenario. The structure of the Conference is organised around two plenary sessions, and the commencing and closing of days and the parallel sessions of thematic content. The plenary sessions are directed towards above all themes of general interest and review in depth those elements related to the three thematic axes of the event: Technical aspects, the use of free software applications and issues related to businesses, strategies and policies. I am convinced that we have managed to gather many of the main stakeholders at all levels of development and implementation of solutions based on free software. In my opinion the International Conference will constitute a new beginning for many participants and institutions. The attendees are: government representatives, as well as those from public administrations, directors of corporations and SME s, academia representatives and of course many participants related to technical aspects coming from different countries from all over the world and all continents. In the organization we are very pleased to be able to bring together, in a constructive and open discussion forum, so many men and women with the sole objective of promoting the development of free software in the benefit of our society. We have worked hard to make the International Conference a place for networking, and exchange and above all a space for sharing and enriching ideas in order to build a better future. Juan Reig Conference Chairman Open Source International Conference

4 CONFERENCIA INTERNACIONAL DE SOFTWARE LIBRE Málaga, 18 al 20 de Febrero de 2004 MIERCOLES 18 JUEVES 19 VIERNES REGISTRO Y ACREDITACION SESION PLENARIA INAUGURACION CONFERENCIA INAUGURAL ESTRATEGIA DE LAS GRANDES COMPAÑIAS SOBRE EL SESION PLENARIA - EL FUTURO DEL SOFTWARE LIBRE: SOFTWARE LIBRE LA VISION DE LOS "GURUS" PAUSA CAFE VISITA EXPOSICION - PAUSA CAFE VISITA EXPOSICION - PAUSA CAFE AUDITORIO SESIONES TEMATICAS SALA 1 SALA 2 AUDITORIO SESIONES TEMATICAS SALA 1 SALA 2 AUDITORIO SESIONES TEMATICAS SALA 1 SALA ADMINISTRACION PUBLICA Y SOFTWARE LIBRE SISTEMAS ABIERTOS: DESARROLLO Y HERRAMIENTAS EXPERIENCIAS, BENCHMARKING Y ESTUDIOS DE CASOS SOFTWARE LIBRE EN EL MUNDO TECNOLOGIA ABIERTA EDUCACION, UNIVERSIDAD Y E-LEARNING SEGURIDAD Y MODELOS DE INNOVACIÓN CASOS PRACTICOS EN LA ADMINISTRACI ON PUBLICA SOFTWARE LIBRE PARA EL DESARROLLO Y LA MEJORA DE LA ACCESIBILIDAD 13:30 (1) (1) (1) (3) (3) (3) (5) (5) (5) CLAUSURA Y CONCLUSIONES ( ) ALMUERZO ALMUERZO APERITIVO : AUDITORIO SESIONES TEMATICAS SALA 1 SALA 2 AUDITORIO SESIONES TEMATICAS SALA 1 SALA MODELOS DE NEGOCIOS, SERVICIOS, MARCO LEGAL 17:30 (2) (2) (2) (4) (4) (4) APLICACIONES Y SERVICIOS PARA LOS CIUDADANOS PAUSA CAFE SESION PLENARIA - POLITICA, GLOBALIZACION Y SOFTWARE LIBRE COCKTAIL - ZONA EXPOSICION APLICACIONES OFIMATICAS, INTEGRACION Y DESKTOP SOFTWARE LIBRE EN EUROPA APLICACIONES INDUSTRIALES Y SECTORIALES PAUSA CAFE SESION PLENARIA - NUEVOS ESPACIOS SOCIALES Y SOFTWARE LIBRE XAVI DE BLAS - LINUX SHOW GRANDES EMPRESAS, MOVILIDAD Y TELECOMUNICACIONE S

5 Día h Sesión Auditorio: Administración Pública y Software Libre Moderador José Carlos Alarcón Participantes Marta Roldán Luis Millán Vázquez de Millán Esteban González Pons Marcelo Sosa Simon Forge Secretario Gral para la Sociedad de la Información de la Junta de Andalucía. Consejería de Ciencia y Tecnología. Junta de Castilla La Mancha. Consejero de Educación, Ciencia y Tecnología. Junta de Extremadura. Conseller de Cultura, Educación y Deportes. Generalitat Valenciana. Administrador. Economic and Scientific Affairs Policy Unit Parlamento Europeo. SFC Associates Ltd.

6 OSS and the European economy Economics of Open Source Software, a European view SIMON FORGE, SCF Associates Ltd Open Source Software (OSS) may be defined as software whose source code is published and made available to the public. It is free in the sense of free speech, rather than a free lunch. Commercial software, in contrast, is most usually available as a binary code, whose internal workings are never revealed. The OSS rules of usage (the licence) enable anyone to copy, modify and redistribute the source code, usually without paying royalties or fees, and without those restrictions carried by proprietary software on seeing, using and modifying the source code. There may be rules on returning OSS code modifications to the software commons, the development community, or there may be no rules on this at all. Examples of OSS are the Linux operating system, Eclipse tools, Apache Web server, with a large number of OSS products being hosted on SourceForge. Some have four developers, a few have thousands. And most importantly, OSS breaks the hold on innovation of the major commercial software players it is able to introduce disruptive technological discontinuities such as the World Wide Web, due to its powers of creativity and mass reach, without the normal rationings of price. OSS is very much a process for development as much as a legal status. The software code evolves through a community co-operation, including users as well as IT developers. This contrasts with the dominant software model until recently, a commercial model of charging royalties for usage, distributing only a cryptic binary format, retaining the intellectual property rights, with internal development by a one-company team. OSS owes its existence to a system of ad hoc communities and their dedication to quality, higher quality than can often be achieved in commercial software. These communities are composed of individual programmers, users as well as some very large companies. A key economic factor is that OSS offers a commons in software, providing a good that individuals, and all sizes of enterprise, may draw upon it without permission, or grants of access from the authors, and usually not rationed by price. Effectively the OSS resource has intrinsic value due to its openess because it is a class of economic good whose value is enhanced by having many able to access it and the right to use it. This is a typical trait of the economics of software where universal usage enhances value. Also, innovations can be made based on the Simon Forge All Rights reserved 2004 SCF Associates Ltd The Rain Forest And The Rock Garden

7 OSS and the European economy OSS offerings, in accordance with the OSS licence, so openess can be translated into value by individuals and enterprises, either in simple usage, or in developing products. OSS licences vary in their conditions on what status of software OSS can be linked to, or combined with, and the control over derived works. The benefits of OSS will be a significant factor for assuring Europe s future in high technology, both in terms of development of all industries generally and in the reinforcement of the indigenous software industry. OSS will spur packaged applications development, currently dominated by overseas software vendors, and also the systems integration business, a European strength. It will create new opportunities for business development and employment in the knowledge industries as the region has intense and increasing software usage. Already dependence on software is absolute in most sectors, including agricultural products. However, Europe has little prominence in packaged software, with only one of the global top ten software package developers by sales being European. OSS offers the chance to move to a software industry model that favours Europe s strengths in system integration, support maintenance services and value added resale of software applications for standard platforms. OSS cannot be stopped, either legally or commercially, nor should it be, as it holds a key to economic progress for Europe. Moreover it is a sustainable and stable model of software development and distribution. OSS has been officially recognised and developed since 1984, but its basic development model is far older. Its success dates from the origins of the ARPANET which, despite, being funded by the US government, gave rise to the first ad hoc development community. This is strong evidence that OSS will continue indefinitely; certainly for another thirty years. Today OSS is changing the software industry and all associated sectors, such as hardware systems manufacture. In total it offers the software industry a chance to move away from an increasingly monopolistic model towards a more openly competitive one. The two largest systems vendors are dropping their own operating systems in favour of OSS based environments. OSS is starting to impact the manufacture and use of embedded software in consumer goods, mobile telecommunications and industrial control systems and is already a foundation of e-science. OSS is strong in servers, with sales of servers based on low-cost Intel processors for use with Linux, Simon Forge All Rights reserved 2004 SCF Associates Ltd The Rain Forest And The Rock Garden

8 OSS and the European economy an OSS operating system, growing at 50% per year in the USA in Q [REF IDC/Business Week 02 FEB 2004, p.50]. There are probably tens of millions of Linux users in the world the exact number is impossible to know as the software can be freely downloaded for no charge, as well be sold as a package with support. OSS is important also in development tools, web servers, databases and application servers. Slowly OSS is growing in desktop software, mainly in the government sector with an office application, OpenOffice, but is still probably less than 10% of that market. But in desktop operating systems, Linux has less than 3% of the market [REF Financial Times, 23 Jan 2004 Linux looks to become desktop standard, Richard Waters]. For user organisations, the key factor of IT deployment is total cost of ownership (TCO) over the lifetime of the software usage, of which licence costs have been estimated at under 10%. Clearly TCO concerns far more than licence costs it extends to software s robustness and reduced down-time costs; OSS has higher resistance to malicious attacks on software resulting in lower rates of disruptions; higher security all round as the source code is known, so its weaknesses can be repaired; there is compatibility across different systems, hence the user is not locked into using specific hardware or software. In the light of this, over 24 countries have put forward proposals to include OSS in government procurement. The OSS model counters the commercial model of software sales and in so doing lowers OSS TCO further, in the areas of deliberate obsolescence by commercial software companies. OSS also provides an alternative that avoids the impacts of new commercial software releases which are likely to have a high number of defects. These flaws cause disruption to business and require further funds to be spent in the form of support licences, support services or complete upgrades to a less defective version, as well as downtime. As things stand, the weaknesses in commercial operating systems, applications and utilities can be treated as forms of production/consumption externalities or pollutants for which their consumers must in some way pay, for the errors of the producers. For many users, OSS cuts their dependence on commercial systems which are intended to lock users in. A particularly important area is electronic document formats. OSS offers stable, efficient formats for a period of time chosen by the user, which is typically over 50 years, for public sector and some business agreements. Most commercial electronic document formats over ten years old cannot be read by today s commercial applications, except occasionally in a limited form, and certainly not across different operating system environments. Simon Forge All Rights reserved 2004 SCF Associates Ltd The Rain Forest And The Rock Garden

9 OSS and the European economy The user is coerced into aligning applications, operating systems and document formats with the commercial releases. OSS liberates the user from this by providing an alternative and, in so doing, competitive pressure for behaviour that is in the interests of the user from commercial vendors. Anti-trust and monopoly law has been applied less in software than in other domains on which we rely absolutely such as energy, transport, telecommunications, food processing and utilities. Yet our dependency on software as a knowledge-based society is absolute. OSS redresses the balance using a market mechanism approach. Effectively, OSS rebalances the power between users and commercial software suppliers; as a result of OSS presence in the market, their prices are already falling. Here we have an illustration of the phenomenon that Software publishing exploits two effects to create a dominant industry position which drive a natural tendency to monopoly situations. These now need to be balanced if effective competition is to survive at all. First is the network effect of the more users, the more intrinsic value the market network has. Coupled with this with the second effect - the law of increasing returns, that is, we can produce a thousand copies of a software program with the same materials and labour as we need to produce one item, and the cost of software per unit tends towards zero with volume. The two effects are illustrated below : Simon Forge All Rights reserved 2004 SCF Associates Ltd The Rain Forest And The Rock Garden

10 OSS and the European economy Network effects - the value and cost of the network diverge as volume of connected users grows and value outstrips costs Coupled with Software economics of increasing returns (profits) multiplied together produce increasing profits with pricing power given by the progress to market dominance with inceasing numbers of customers Relative cost Software cost/unit - Increasing returns - Software cost/unit falls rapidly as original cost to develop stays the same while the duplication of units cost nothing in content while the cost of its packaging falls with volume Network Value increases rapidly with volume Relative cost of Physical Network, to build and operate, increases slowly with more users Relative transaction cost to software publisher to build and operate an e-commerce network as a sales channel decreases with volume Simon Forge SCF Associates All rights reserved 2004 Volume of users The coupling of these two forces can squeeze out competition in a proprietary software market. Also, if electronic document formats are considered in law as protected IPR and interworking interfaces (known as application program interfaces or APIs) are also regarded as commercial secrets, so document exchange across different supplier s products and interworking are impossible. Consequently the two effects combined may lead to a restriction of competition. The situation is tipped even further in favour of monopolies where enormous marketing muscle is brought to bear, so that the marketing becomes more important than the features the software has, or its quality, and other voices, such as those of the sales channels, are not heard because they are tied to the monopolistic supplier, while customers can be ignored they are locked in. Moreover, problems that are increasing regarding software piracy and intellectual property rights (IPR) enforcement under the WTO will become less significant if a move is made to OSS because it will avoid the legal minefields and entrapment of Trade Related IPR agreements (TRIPs) and software patents that some major software suppliers are lobbying so hard for. A move to OSS will neatly resolve the problem, and also the software industry has grown well without all this red tape and protection. The need for software patents cannot be amply demonstrated while there is evidence that they are detrimental to progress and innovation. Simon Forge All Rights reserved 2004 SCF Associates Ltd The Rain Forest And The Rock Garden

11 OSS and the European economy Policy directions should have a better industrial model for software creation as a top level goal, because our dependency on software is so high and is growing. The correct policy allows OSS to build market efficiencies in software, promoting economic growth for all Policy - OSS - Software patents OSS New value-systems Enabling ICTs Networked Co-operation and innovation communities Market Efficiency European economic growth Simon Forge SCF Associates All rights reserved 2004 The conclusions for Europe are that the way forward is a strong policy on OSS :- This analysis forms part of work for the IPTS unit (Sevilla) of the JRC of the EC. Simon Forge SCF Associates UK simon.forge@whsmithnet.co.uk Simon Forge All Rights reserved 2004 SCF Associates Ltd The Rain Forest And The Rock Garden

12 Día h Sala 1: Sistemas Abiertos: Desarrollo y Herramientas Moderador Felipe Romera Director General del Parque Tecnológico de Andalucía Participantes David Santos Oncero David Pinelo /José Luis Oramas Daniel Díaz Pérez Álvaro Peña Juan Ramón Alegret Fermín Galán Álvaro López Ortega Director de Operaciones de Animatika Sadiel/Sadesi Telvent Esware Linux Sun Microsystems Agora Systems GNU

13 Ponencia David Pinelo/ José Luis Oranas Selección de herramientas de Gestión de Contenidos para el Portal andaluciajunta.es Antonio David Pinelo Moruno Sociedad Andaluza para el Desarrollo de la Sociedad de la Información, S.A.U., España José Luis Oramas Martín SADIEL S.A.U., España Introducción La selección de un gestor de contenidos no es una tarea sencilla de realizar, debido a los múltiples parámetros involucrados en su elección, funcionalidades requeridas para el proyecto concreto, características que aporta el gestor de contenidos, necesidades de integración con la infraestructura existente o el potencial de crecimiento a futuro. Dentro del proyecto de Ampliación del Portal andaluciajunta.es, surge la necesidad de seleccionar una solución de gestión de contenidos de las muchas existentes en el mercado. Actualmente la Junta de Andalucía está apostando decididamente por el uso de software de fuente abierta como solución a las diferentes necesidades o problemas que encuentra la Administración. La utilización de software libre conlleva una serie de ventajas conocidas como el uso de estándares abiertos, la posibilidad de adaptar el código a las necesidades específicas del proyecto o la experiencia compartida de muchos usuarios en el uso del software. Es lógico plantear el empleo de herramientas de gestión de contenidos de fuente abierta en este proyecto. El abanico de herramientas de gestión de contenidos en software libre es amplio y rico en funcionalidades y características. La gran vinculación del software de fuente abierta con Internet tiene reflejo, entre otras, en las múltiples posibilidades o funcionalidades que éste ha aportado al manejo de información en sitios web, situándolo por delante del software propietario en muchos aspectos. Por ello, para facilitar esta elección se decidió realizar una comparativa de las soluciones de gestión de contenidos más adecuadas, en principio, a los requisitos de este proyecto. Tendencias tecnológicas La elección de las soluciones a evaluar ha sido fruto de un análisis de las tendencias actuales, tanto del mercado como de la Junta de Andalucía, unido a las necesidades propias del proyecto. Se han

14 tenido en cuenta factores como la madurez de las herramientas, robustez, usabilidad, tecnologías involucradas y capacidad de crecimiento, entre otras. Por ello se ha optado por realizar un estudio sobre plataformas que estén fuertemente asentadas y con una comunidad de usuarios e implantaciones bastante elevada. Dentro de las tendencias de mercado, se encuentran soluciones basadas en Java, Python o PHP, que han demostrado estar en la vanguardia tecnológica, proporcionando sistemas de alta fiabilidad, y que son consideradas hoy día como arquitecturas modelo. Las tendencias tecnológicas de la Junta de Andalucía se orientan a la utilización de Java y XML como piedras angulares, todo ello unido a la utilización de soluciones basadas en software de fuentes abiertas. Java, como lenguaje y plataforma de ejecución de aplicaciones de servidor, ha supuesto una revolución sobre la forma de entender Internet y sus servicios, en gran medida por su contribución a la estandarización de las plataformas. XML, como estándar de representación de contenidos, contribuye al desarrollo de sistemas fuertemente desacoplados, en los que la separación de presentación y contenido es una realidad, mejorando el mantenimiento y posibilitando la sustitución de componentes de una forma transparente para el resto del sistema. Además, en un entorno como el de la Junta de Andalucía donde se dispone de un gran número de fuentes de información susceptibles de proporcionar contenidos, la utilización de XML como formato de intercambio ayuda a resolver el problema de la sindicación de los mismos (inclusión de información procedente de distintas fuentes en un sitio web). Soluciones de fuentes abiertas, como medio para generar desarrollo local, reducir los costes de licencias de los proyectos, compartir esfuerzos entre diferentes Administraciones, o contribuir a la comunidad desarrolladora del software y a todos sus usuarios mediante mejoras, detección de errores o compartiendo experiencias o impresiones para su mejora. Evaluación de alternativas En base a los criterios expuestos, se seleccionaron diversas herramientas, y de entre todas ellas se optó por evaluar las que, a priori, parecían más adecuadas para este proyecto:

15 Cocoon 1. Un sistema de publicación web fuertemente basado en Java, XML y sus tecnologías derivadas (XSL). Su arquitectura de funcionamiento proporciona un aislamiento total de los diferentes componentes que lo forman, así como la agregación y desarrollo de funcionalidades con facilidad. Su pilar básico de funcionamiento es la separación real de contenidos y lógica de aplicación. OpenCMS 2. Un sistema de gestión de contenidos basado en Java, con una interfaz muy amigable y con las funcionalidades típicas de las herramientas de estas características, como son la gestión de permisos, estados de los contenidos, versionado, formularios de agregación de contenidos o integración con fuentes externas por mencionar algunas. Zope 3. Como plataforma y como puerta para el desarrollo de portales y gestores de contenido, como es el caso de CMF y Plone, ideal para la implantación rápida de este tipo de sistemas, pero con una no tan clara separación de lógica y contenido. Su arquitectura modular ha hecho que la comunidad haya aportado un gran número de funcionalidades añadidas. Dentro de cada alternativa se evaluaron criterios de diversa índole: tecnológicos, arquitectura, existencia y utilización de entornos de desarrollo y producción, metodología de gestión de los contenidos, seguridad, soporte o comunidad existente entre otros. Selección final Ninguna de las herramientas cumplía completamente con las necesidades del proyecto. En unos casos por funcionalidades y en otros por factores tecnológicos. Zope es una alternativa madura, con un elevado número de funcionalidades y con una comunidad de desarrolladores muy extensa. No obstante cuenta con dos grandes impedimentos dentro de este proyecto, uno tecnológico, ya que el entorno tecnológico donde se ha de integrar es fundamentalmente Java, y otro funcional, ya que su tratamiento para los contenidos y presentación en formato XML no es el más apropiado. Por otra parte, OpenCMS, que sí cumple con el requisito tecnológico de estar desarrollado en Java, tiene algunas limitaciones: no aporta ninguna funcionalidad específica para utilizar XML en la presentación de los contenidos, y tiene ciertas limitaciones en cuanto a su capacidad de integración con software externo. 1http://cocoon.apache.org 2http:// 3http://

16 El punto fuerte de Cocoon, en cambio, son las limitaciones de los anteriores, es decir, su utilización de XML y hojas de transformación XSL de forma nativa tanto para la presentación como para los contenidos. Y los puntos fuertes de las soluciones anteriores son las limitaciones de Cocoon, la gestión de los contenidos en sí misma, al ser únicamente un sistema publicación web. Teniendo en cuenta todos los criterios expuestos, las especificaciones del proyecto, las preferencias de la Junta de Andalucía fruto de sus necesidades tecnológicas, y la evaluación de funcionalidades de cada una de las opciones tecnológicas, finalmente se optó por implantar un sistema híbrido basado en el tándem Cocoon-OpenCMS, que combinara las ventajas de ambas soluciones, facilitando el desacoplamiento entre el portal (la presentación de la información) y la gestión de contenidos. Cocoon, como sistema de publicación web, se utilizará para toda la lógica del ciudadano, navegación, formularios, su sistema de caché o sus múltiples interfaces para lectura de datos entre otros aspectos. Su origen nativo XML conseguirá un separación completa entre el contenido y la presentación. OpenCMS, como repositorio de los contenidos, facilitará a su vez la incorporación de los contenidos de otras fuentes, como son las Consejerías o las diversas bases de datos existentes en la Junta de Andalucía. Sirve como plataforma de gestión de dichos contenidos, mediante las oportunas herramientas y formularios que utilizarán todos los usuarios destinados a poblar de información el portal. Ambas soluciones se integrarán utilizando protocolos estándares e intercambio de mensajes en XML, lo que garantiza el desacoplamiento de las mismas, y facilita su evolución. El sistema resultante se completa además con su integración con el directorio LDAP corporativo para autentificar a los usuarios creadores de contenidos contra OpenCMS, y con la integración de un sistema de workflow de publicación que proporcione la capacidad necesaria para definir los diferentes flujos de publicación, tanto por contenidos como por entidades, que permita cubrir las necesidades de la Junta de Andalucía.

17 AUTOR DE CONTENIDOS GESTOR CONSEJERIA SERVIDOR DE APLICACIONES WEB CONSEJERIA AUTOR DE CONTENIDOS GESTOR DE CONTENIDOS OPENCMS API GESTION DE CONTENIDOS GESTOR DE PUBLICACIÓN COCOON WEB PORTAL LDAP CORPORATIVO WORKFLOW CORPORATIVO FUENTES EXTERNAS DE CONTENIDO Conclusiones No hay una única solución de gestión de contenidos universalmente válida para todos los casos. Cada proyecto tiene sus propias necesidades, tanto de funcionalidades como de tecnología. En este caso concreto se optó por una solución combinada, que resuelve muchos problemas aunque no está exento de otros, como la complejidad de los entornos de desarrollo y producción, y problemas de integración entre ambas soluciones y con el propio entorno de la Junta de Andalucía. Además se han tenido que utilizar diversas estrategias de integración para evitar limitaciones de arquitectura y conseguir un sistema que pueda evolucionar, crecer y cambiar fácilmente. Este desacoplamiento de los componentes permitirá, en un futuro, sustituir cualquiera de los elementos componentes por otros que se consideren más adecuados sin que ello impacte en el resto de sistemas. Por ejemplo, se podrá sustituir la herramienta de gestión de contenidos (OpenCMS) por otra, o bien el LDAP corporativo por otro, el sistema de workflow... Es importante aprovechar las posibilidades que ofrecen las soluciones basadas en software de fuente abierta pero teniendo siempre presente cuáles son las ventajas e inconvenientes que pueden acarrear, de la misma forma con la que se evaluarían soluciones de software propietario. Deben

18 buscarse soluciones de integración que no lleven al estancamiento tecnológico y que faciliten que el sistema pueda evolucionar de una forma no traumática. La elección de estas tecnologías en el ámbito de la Junta de Andalucía sienta las bases para la utilización de estándares que prometen aportar grandes beneficios y un salto cualitativo notable al desarrollo de aplicaciones web y, en consecuencia, a los servicios prestados al ciudadano a través de Internet. Asimismo este proceso puede servir de catalizador para extender los beneficios que puedan obtenerse a otros proyectos de naturaleza similar en el marco de la Administración Autonómica.

19 TI-FLOWS: PLATAFORMA DE GESTIÓN DE PROCESOS BASADA EN SOFTWARE LIBRE. D. Díaz Pérez Telvent, España El objeto de esta ponencia es el presentar, no el producto como podría sugerir el título, sino la posibilidad de que el software libre y propietario coexistan en el entorno empresarial actual. Antes de centrarnos en la idea principal, convendría introducir ciertos aspectos relevantes que nos ayudaran a entender las claves que inducen a elegir este modelo de construcción de software. Hay que empezar presentando el producto Ti-Flows como un Gestor de Procesos. Un Gestor de Procesos es un sistema que permite la completa definición, gestión y ejecución de procesos. El gestor controla el flujo de los procesos de acuerdo a las reglas que lo definen y distribuye las diferentes tareas que conforman el proceso entre los usuarios. Dentro de estos gestores, los procesos son automatizaciones en todo o en parte de un proceso de negocio, dentro del cual, documentos, información o tareas se transmiten de un usuario a otro de acuerdo a un conjunto de reglas procedurales. Comúnmente, los procesos se definen mediante herramientas gráficas, por lo que el diseño de estos y sus posteriores cambios son sencillos. Hay que reseñar que los procesos de negocio de una organización, no permanecen estáticos a lo largo del tiempo, más bien, estos evolucionan a la vez que la organización. Una representación estática de las reglas que definen los procesos incrustadas en el código de las aplicaciones, haría que nuestro sistema fuese demasiado vulnerable a los cambios y que su posterior adaptación, se convierta en una tarea costosa. En el otro lado, el uso de gestores de procesos, hacen de la evolución y los cambios de los procesos algo sencillo. Bastaría rediseñar la definición del proceso y darla de alta en nuestro sistema para conseguir esa adaptación. Dentro del mercado, hay varias organizaciones que trabajan en la definición de estándares que sean capaces de constituir la base para la creación de gestores de procesos. Una de ellas es el Workflow Management Coalition (WFMC). Esta es una organización sin animo de lucro formada por vendedores, usuarios, grupos de investigación, universidades etc. que tiene como objetivo, el promover el uso y desarrollo de gestores de procesos mediante el establecimiento de estándares de terminología software, interoperabilidad y conectividad entre diferentes productos. El objetivo que pretende alcanzar el WFMC a través de las definiciones de estándares es: - El incremento de la inversión por parte de los clientes en sistemas basados en plataformas de gestión de Procesos. - La disminución del riesgo que supone el uso de dichas plataformas. - La expansión del mercado de estos sistemas a través del aumento del conocimiento que se tiene de estas plataformas.

20 A grandes rasgos, el WFMC define la manera de representar los procesos que los gestores manejarán mediante el XPDL. XPDL es un subconjunto del XML para la definición de procesos y su objetivo es el de obtener una definición intermedia entre los editores de procesos y el motor de gestión de procesos. El objetivo es hacer independientes estas dos partes. Por otro lado, define 5 interfaces que constituye el motor de un sistema gestor de procesos que cumpla con su estándar. Según el WFMC, un sistema que cumpla con su estándar debe estar formado por las siguientes interfaces: - Interfaz 1: Definición de procesos. - Interfaz 2: Operatividad de las aplicaciones cliente. - Interfaz 3: Invocación de aplicaciones. - Interfaz 4: Servicio de ajuste e interoperabilidad entre gestores. - Interfaz 5: Herramientas de administración y monitorización. Figura 1. Modelo de Gestor de Proceso basado en el estándar del WFMC.

21 Para la creación del gestor de procesos Ti-Flows optamos por seguir el estándar del WFMC. La razón de esta elección, fue la madurez del estándar y nuestra aceptación de la filosofía que este sigue. En este punto, encontramos un proyecto de software libre que se ajustaba a nuestras necesidades: un motor de proyectos basado en el estándar del WFMC y que a demás es software libre desarrollado con el framework de trabajo J2EE. La elección de integrar software libre en un proyecto empresarial no es fácil. En primer lugar, hay que entender que los proyectos específicos diseñados por las empresas y los proyectos de software libre son opuestos en su filosofía. Mientras los primeros se rigen por la competitividad que el mercado impone, los segundos se rigen por el afán de conseguir la popularidad y el reconocimiento de la comunidad. Esto hace que los proyectos de software libre no avancen a un ritmo tan rápido como los proyectos empresariales y que la elección de incluir ese software libre, dependa en gran medida del estado del desarrollo del mismo. No es una buena opción por lo tanto, elegir un software libre cuyo desarrollo esté empezando, ya que presumiblemente el proyecto donde debe ser incluido terminará antes. Otro aspecto negativo a la hora de integrar el software libre, es el hecho de no tener garantías de que un cierto programa funcione. Esto último se mitiga en productos libres con un prestigio ganado. Por ejemplo: nadie duda que el servidor web apache funcione correctamente. La ausencia de documentación fiable, en ciertos casos, es otro aspecto negativo. Pero afortunadamente no siempre es así, sino que en algunos casos, la documentación y la formación son vendidas como un servicio y se convierten en el medio de financiación de los proyectos libres. Por último, está el hecho de encontrar el producto que se adapte a nuestras necesidades. Es casi imposible, que un cierto software libre se adapte 100% a los proyectos a medida que se desarrollan en las empresas. Por esto los diseñadores, sólo construyen algunas partes de los proyectos basados en software libre. Esta es la clave de la coexistencia de los dos modelos de software. El encontrar un software libre que se adapte a alguna parte del proyecto a medida significa que primero se invirtió tiempo en buscarlo y en el entorno empresarial el tiempo se mide en dinero. La decisión de invertir este tiempo de búsqueda depende del responsable del proyecto. Para entender porqué una empresa decide usar software libre, una vez visto los inconvenientes que introduce en el desarrollo de software a medida, hay que prestar atención a los beneficios que este aporta. Para empezar, hay que tener en cuenta que su coste es nulo o prácticamente despreciable. Aunque este no es ni mucho menos el principal factor para elegir este tipo de software. El principal factor, bajo mi punto de vista, es la tendencia de este tipo de software a conseguir una alta calidad. El software libre no compite comercialmente, sino por ser el más eficiente y conseguir así el reconocimiento de la comunidad y la popularidad. Esto en muchos casos es imprescindible si se quiere vender documentación, formación etc. No menos importante, está el hecho de que muchos proyectos consigan involucrar a muchas personas, lo que garantiza que los posibles errores e incompatibilidades se resuelvan y localicen rápido.

22 Es importante para decidir incorporar software libre, el conocer los proyectos que existen. Hoy en día y gracias a la posibilidad de comunicación que Internet nos ofrece, muchos grupos de desarrolladores de software libre encuentran un medio para publicitar y conseguir adeptos a sus desarrollos. En proyectos que se financien mediante la venta de productos derivados del software libre, como por ejemplo la formación, documentación, consultorías etc., encuentran en Internet un medio fácil para publicitarse. Por último, existe una importante ventaja política al uso de este tipo de software. Hoy día muchas instituciones y organismos públicos apuestan abiertamente por el software libre. Esto hace que el hecho de que una empresa distribuya y use software libre en sus proyectos abra la posibilidad realizar negocios con ellas. Una vez presentadas las razones por la que se elige este tipo de diseño, basado en la unión de los dos tipos de software, presentaremos el esquema de Ti-Flows en la base de los módulos que lo conforman. Ti-Flows está diseñado por los siguientes módulos: - Motor de gestión de procesos. - Administración y control de usuarios del gestor de procesos. - Editor gráfico de procesos. - Simulación de los procesos. - Herramienta Worklist o de tareas pendientes. Para en motor de procesos se optó por la solución libre. Pero este software es solo la implementación de un motor de procesos, de hecho el estándar del WFMC define esto, un motor de gestión de procesos. La idea del desarrollo de Ti-Flows es adaptar todos los módulos que necesitaba el motor para alcanzar la funcionalidad que un producto de esta índole necesita. La gestión de los usuarios y la administración de los procesos que se ejecutan dentro del gestor, era un módulo necesario. Las tareas que forman los procesos deben ser asignadas explícitamente a entes de nuestro sistema (roles, usuarios, sistemas etc.), ya que el gestor debe controlar la asignación de las tareas a los usuarios que tengan permiso para gestionarlas. Por otro lado, está la necesidad de reasignar las tareas entre diferentes usuarios, para evitar que el flujo de un proceso se pare por no estar presente el usuario que tiene que tramitarla. La obtención de estadísticas y datos relevantes en la ejecución actual e histórica de los procesos del motor es otra necesidad añadida. Esto se consigue mediante el módulo de administración y gestión de usuarios. Para alimentar el motor con procesos, bastará con proporcionarle las representaciones de estos mediante un fichero de texto que contenga la definición XPDL. El crear el XPDL que representa un proceso es una tarea tediosa y es fácil cometer errores sintácticos. Para facilitar esta tarea se construyó una herramienta de edición de procesos gráfica, que nos ofrece como resultado el XPDL que define el proceso. Las personas que desarrollan los procesos, deberían tener una manera de probar que estos son correctos y cumplen la funcionalidad esperada. Para facilitar esta tarea, es conveniente dotar al producto de un simulador de procesos. Esta herramienta facilita la creación y prueba de los procesos a los encargados de la construcción de los mismos.

23 Por último, se necesita ofrecer una interfaz para que los usuarios involucrados en los procesos puedan gestionar las tareas que tienen pendientes y que estos creen los nuevos tramites que el sistema gestionará. Esto es el worklist o lista de tareas pendientes. La unión del desarrollo de los módulos necesarios, que constituyen el código propietario, más el gestor de procesos de software libre, constituye la unión de este tipo de sistemas, donde dos diferentes filosofías de desarrollo de software se unen. Conclusiones. Si bien es cierto que el modelo de desarrollo de software a medida, que a menudo prima en las soluciones que las empresas ofrecen a sus clientes, no se adapta a la filosofía del desarrollo de software libre, también lo es el hecho de que estos dos modelos de desarrollo pueden unirse y beneficiarse el uno del otro. Para ilustrar este hecho, bastará con contestar tres preguntas que nos aportarán las conclusiones finales. Cómo seleccionar un software libre adecuado a nuestro proyecto? Para la correcta selección de un software libre, además de que este se ajunte a las necesidades de la parte del proyecto a la que esté destinado, hay que tener en cuenta la versión y el estado del software. No es aconsejable elegir un software que se encuentre en fases iniciales de desarrollo y esperar que este avance al mismo ritmo que nuestro producto. Esto nunca ocurrirá debido a los diferentes ritmos de desarrollo de los dos modelos de desarrollo de software. Mientras que en desarrollo de software privado, está condicionado al ritmo que el mercado impone para obtener los mayores beneficios posibles, el software libre busca como objetivo la fiabilidad. Debido a ello, los desarrollos de software libre avanzan más lentos, por lo que presumiblemente no podremos incluir en nuestro proyecto una versión estable del ese desarrollo que se está iniciando. Por último, es muy importante elegir software libre que ofrezca una fuente de conocimientos de funcionamiento y de uso del mismo, ya sea en forma de documentación o cursos. Qué aporta el uso de software libre a un desarrollo de software privado? En primer lugar, el software libre tiende a ser de calidad. La finalidad de este tipo de software es obtener fama y el reconocimiento de la comunidad y ningún desarrollo que no alcance un nivel satisfactorio de fiabilidad podrá conseguir este objetivo. El coste es o nulo o casi nulo (compra de documentación, formación...), lo que hace que la construcción final del producto sea más competitiva en el mercado. Ofrece una buena respuesta ante la localización y reparación de los posibles fallos. Los proyectos de software libre consiguen involucrar a una gran cantidad de usuarios dispuestos a probar y corregir, si fuese necesario los errores encontrados.

24 Esware AD Connector Solución Integral de Conexión con Microsoft Active Directory iseries

25 Esware AD Connector Información del Producto La solución de conexión Esware AD Connector permite la integración del sistema Microsoft Active Directory con soluciones de servicio de Esware Linux y servidores en general, como el caso de servidores de correo, servidores ThinClient, servidores de mensajería instantanea (jabber), etc. En el esquema observamos un caso práctico en el que Esware AD Connector sirve de enlace entre un servidor de correo y una aplicación BackOffice, instaladas bajo un sistema Linux, y una servidor Microsoft Active Directory. El sistema de integración se basa en la obtención de recursos desde el servidor Active Directory como la contraseña de un usuario determinado o las direcciones de correo disponibles por un usuario. En el caso del servidor de correo pop la contraseña y el nombre de usuario que el Usuario introduce en los parámetros de configuración de sus aplicación MTA de correo (Evolution, Outlook, etc), son enviados atraves de Esware AD Connector para comprobar su validez, devolviendo el valor obtenido. Además, el Usuario puede obtener mediante interface Web su correo, identificandose del mismo modo, gracias a Esware AD Connector. Esta implantación permite el crear un sistema de almacenamiento externo, mediante cualquier sistema de ficheros, local o remoto mediante NFS. Mezclando un sistema NFS con un servidor IMAP conseguimos que el correo de los usuarios sea accesible en cualquier momento desde cualquier lugar, sin tener que realiza copias del mismo de uno a otro cliente de correo.

26 Esware AD Connector Sistema de configuración Para operar con el sistema es necesario realizar unos sencillos pasos de configuración. Después de obtener el producto Esware AD Connector podemos configurar el acceso al servidor Microsoft Active Directory mediante dos vias, usando la aplicación Web de configuración o con Esware AD Connector Configurator (aplicación de escritorio). Esware AD Connector Configurator El proceso de configuración es muy sencillo como podemos ver en la imagen, pocos datos son necesarios para configurar Esware AD Connector. El nombre o nombres de los equipos que tengan instalado el servidor Microsoft Active Directory y un usuario válido en estos sistemas para poder realizar las consultas con dicho servidor. Este usuario no requiere de permisos especiales de administración, solo necesita tener acceso de lectura, si solamente se desea ese tipo de acceso, para realizar tareas de configuración ser requiere un usuario con dichos permisos. Además del servidor y usuario al que conectar se requiere una base de busqueda. Esta será la usada para lanzar las consultas necesarias dependiendo del proceso a realizar, en el caso de un servidor de correo la busqueda sería por todo el arbol de fichas de usuarios.

27 Esware AD Connector Esware AD Connector Web Configurator Además de configuración desde el mismo escritorio podemos user el sistema mediante interface web, que nos permite configurar el sistema desde cualquier parte de la red a través de cualquier navegador web y mediante unos sencillos pasos. Esta página puede ser accesible mediante un protocolo seguro HTTPS. Además incorpora un sistema de contraseña para el acceso a dicha configuración. Los datos de configuración son mínimos para la conexión básica, permitiendo en pocos minutos el tener configurado el sistema en pocos minutos.

28 Esware AD Connector Resumen del Producto Conexión con Microsoft Active Directory Multi-acceso a servidores de Microsoft Active Directory Conexión anónima o mediante usuario Fácil configuración e instalación Conectividad con servidor de correo, servidor de ficheros, servidor jabber, acceso a terminal Linux, etc Herramienta BackOffice API para creación de aplicaciones (Perl y C) Mantenimiento y administración remoto

29 Esware elearning Plataforma Educativa

30 Esware elearning Información del Producto La plataforma elearning se define como un centro de gestión de recursos para materiales didácticos ampliados con un sistema de aplicaciones que expande la capacidad del sistema. Mediante un interface web un alumno accederá a los contenidos de un curso y usará las aplicaciones que le irán guiando y ayudando en el transcurso del curso. El usuario podrá así apuntarse o ser apuntado automáticamente a cursos, accederá a sus diversos temas y podrá realizar ejercicios por cada tema o sección, formar grupos de trabajo con otros compañeros, descargar material multimedia, mantener una conversación en tiempo real con el profesor, tutor o entre mas compañeros y cantidad mas de acciones gracias al sistema de aplicaciones modular. Además se ofrece un API de desarrollo simplificado para la creación de módulos que amplíen la capacidad de la plataforma, permitiendo una adaptación a necesidades específicas con pocas horas de desarrollo. En el esquema observamos las interacciones entre las distintas partes del sistema. La interacción con la base de datos se realiza mediante un modulo por cada tipo de Base de Datos, se dispone por defecto del modulo de conexión con MySQL. El desarrollo de nuevos módulos es muy sencillo partiendo del módulo ya creado. La comunicación entre el servidor de aplicaciones y el motor se realiza mediante un interfaz XML-RPC, permitiendo la comunicación entre módulos desarrollados en distintos lenguajes implementando este tipo de servicio. Además de esta comunicación XML-RPC, si se prefiere, se pude trabajar en sistema local desarrollando en PHP.

31 Esware elearning El Alumno Desde el punto de vista del alumno el mayor problema a la hora de realizar formación a través de Internet es el orden y la disciplina de estudio. Es importante para el alumno el disponer de un contacto fluido con los tutores y profesores además de conocer el estado del curso o cursos a los que se encuentre inscrito, mediante calendarios, notas, etc. El sistema presenta un menú muy sencillo de asimilar con iconos descriptivos y navegación guiada en todo momento. El usuario tendrá a disposición las herramientas que el tutor/profesor/administrador deseen. Así podrá decidir entre las opciones y sentir libertad de elección. Por defecto se han desarrollado las aplicaciones mas comunes y necesitadas en un entorno educativo: Agenda, Documentos, Presentación de Trabajo, Anuncios, Foros, Ejercicios, Chat y otras muchas más. En el caso de la herramienta Agenda se hace uso del estándar icalendar para almacenar los datos, permitiendo su importación en aplicaciones que hacen uso de este sistema, como Ximian Evolution, Apple ical, Microsoft Outlook, entre otros. Además de recibir correos cada vez que se escriba un nuevo anuncio de presentación de un trabajo, una fecha señalada como por ejemplo un examen, etc. Todo alumno puede pertenecer a un grupo que designe el tutor y podrán charlar con ellos y con el tutor mediante el uso del Foro de Grupo o mediante la aplicación de Chat incluida, la cual hace uso de un servidor jabber si se desea, permitiendo la ampliación que este gran sistema de mensajería ofrece.

32 Esware elearning El Tutor Las herramientas de edición de contenidos ofrecen el control total al tutor/profesor para realizar las tareas de mantenimiento y ofrecer a los alumnos el material necesario así como mantenerlos informados en todo momento del estado del curso, introduciendo notas y programando el curso con la herramienta Agenda. Cada herramienta cuenta con dos modos, el modo usuario y el modo de administración, el usuario con privilegios de tutor podrá trabajar con las herramientas en modo administración, permitiendo la modificación de los contenidos. Como podemos observar el interfaz del tutor es muy similar al del usuario. Contamos con las Herramientas de usuario, además de la opción de desactivar, y vemos herramientas reservadas a los administradores y la herramientas desactivadas. En todo momento el tutor puede activar temporalmente una herramienta, por ejemplo la herramienta Chat, para impartir una charla a los alumnos en una hora fijada. Una de las mas importantes es la herramienta de Ejercicios, esta herramienta permite realizar exámenes, de tipo test o escritos, en el caso de tipo test el alumno podrá obtener el resultado del test al instante. La herramienta ha sido diseñada en conjunto con profesores experimentados que han ido guiando en el transcurso del desarrollo de la herramienta, permitiendo que quedaran cubiertas las mayores necesidades a la hora de realizar un examen vía Internet.

33 Esware elearning El Desarrollador Para el desarrollo de nuevos módulos se ofrece una completísima API y una documentación detallada acerca de cada dato a tratar por parte del desarrollador. Además se cuenta con el código fuente de todo el sistema el cual se encuentra bajo licencia GPL. Gráficos explicativos y documentos vía HTML y con libros para la aplicación DevHelp, permitiendo la integración con editores de código como Emacs. Se puede usar XML-RPC para la comunicación entre módulos permitiendo el uso de cualquier lenguaje de programación, esta comunicación se puede realizar a través de una red si se desea colocar el servidor de aplicaciones en otro equipo distinto al que contenga el motor del sistema Esware elearning. De todos modos se pueden desarrollar los módulos en PHP introduciendo su código dentro del directorio de bibliotecas del propio motor de Esware elearning.

34 Esware elearning Resumen del Producto interfaz Web para alumnos y tutores mediante nombre de usuario y contraseña. Conexión segura por SSL Herramientas incluidas: Agenda, Documentos, Anuncios, Foros, Grupos, Enlace externos, Trabajos, Usuarios, Ejercicios, Descripciones, Videos y Chat. Herramientas de administración: Estadísticas, Noticias principales, Creación de Cursos, Creación de Campus. Diversos Cursos por Campus. Gestión de distintos Campus. Estadísticas de conexión

35 VNUML: UNA HERRAMIENTA DE VIRTUALIZACIÓN DE REDES BASADA EN SOFTWARE LIBRE Fermín Galán 1, David Fernández 2 1 Agora Systems S. A.; 2 Departamento de Ingeniería Telemática, UPM fermin.galan@agora-2000.com Abstract Hoy en día, las técnicas de virtualización suponen una importante alternativa a la implementación de sistemas con equipos reales. El artículo analiza las motivaciones de la virtualización y presenta VNUML (Virtual Network User Mode Linux), una herramienta potente y flexible basada en software libre que simplifica el trabajo del usuario automatizando la construcción de escenarios virtuales. Palabras claves: virtualización, simulación, UML, XML.

36 1. Introducción En la actualidad, la potencia del hardware disponible (equipos cada vez más rápidos en términos de CPU, con mayor cantidad de memoria RAM y espacio de almacenamiento en disco duro) ha motivado el interés por las técnicas de virtualización y sus aplicaciones, con el objetivo principal de reducir costes de despliegue y gestión de lo que sería un sistema equivalente realizado de forma convencional con equipos reales. El presente artículo describe VNUML (Virtual Network User Mode Linux) 1, una herramienta basada en software libre cuyo objetivo es la construcción de entornos virtuales o simulaciones, desarrollada dentro del marco del proyecto Euro6IX [1] con la financiación parcial de la Comisión Europea. 2. Virtualización Desde un punto genérico, puede definirse la virtualización como una técnica que permite encapsular una unidad de proceso (programa, sistema operativo, incluso un equipo completo) para su ejecución dentro de un entorno en un equipo anfitrión que emula el entorno real transparentemente. Esto implica que, en disposición de una máquina lo suficientemente potente que actúe de equipo anfitrión, es posible ejecutar simultáneamente un sistema de máquinas virtuales que se comporten de forma equivalente al mismo sistema implementado con máquinas reales. Lo deseable es que el sistema emulado se comporte lo más transparentemente posible, idealmente exactamente igual que el sistema real. Las principales ventajas de la virtualización son el ahorro de costes de infraestructura (ya que se utiliza un único equipo real, existe un ahorro de costes tanto mayor cuando más complejo -más equipos tiene- es el sistema original) y la simplificación de la gestión (tan solo hay que gestionar un único punto el equipo anfitrión- en vez de tener que interactuar con un entorno de equipos interconectados): configuración, corrección de errores, actualización de software, realización de backups, etc. Sin embargo, la transparencia completa usando virtualización es difícilmente alcanzable. Esto es debido a que la virtualización introduce un nivel de proceso adicional (el que traduce las llamadas al 1 La herramienta puede descargarse libremente desde

37 sistema de la máquina virtual al sistema anfitrión) que supone un overhead debido al consumo de recursos. Para conseguir un rendimiento equivalente al del sistema real es necesario utilizar hardware de mayor potencia en la máquina anfitriona. En todo caso, esto es algo que depende de lo eficiente que sea la técnica de virtualización que se emplee. Si bien la teoría en la que se basan las técnicas de virtualización modernas es bastante antigua [2], el auge de este tipo de soluciones (muchas de ellas basadas en software libre) no se ha producido hasta hace relativamente poco tiempo, motivadas principalmente por la baja relación potencia del hardware/precio a la que hemos llegado en nuestros días: Plex86 [3], Bochs [4], UML [5], VMware [6], En particular, VNUML está baso en UML (User Mode Linux [5]). 3. Aplicaciones VNUML está orientado a la prueba de aplicaciones de redes y servicios sobre escenarios complejos compuestos de múltiples nodos (incluso decenas), evitando el coste de adquirir y gestionar equipos físicos reales. Se señalan a continuación varios casos típicos en los que la herramienta puede ser de utilidad. Prueba de aplicaciones de red. Con VNUML es sencillo establecer una maqueta o demostrador para pruebas de aplicaciones de red. En el proyecto Euro6IX [1], VNUML ha sido utilizado para evaluar y comparar distintas alternativas de software de routing BGP [7]. Despliegue de laboratorios. Es posible utilizar VNUML para ahorrar costes de despliegue y mantenimiento en laboratorios de universidades o centros de enseñanza. En un caso extremo, el laboratorio entero podría ser incluido en CD-ROM (junto con algún programa de aprendizaje guiado) y proporcionado al alumno para su utilización independiente. Redes señuelo. Una red señuelo (honeynet) es una red cuyo objetivo es el estudio de amenazas de seguridad dirigidas contra ella [8]. Utilizando VNUML se simplifica la implantación y gestión de este tipo de redes. Hosting. Para una empresa dedicada a la provisión de servicios de hospedaje (hosting) es posible utilizar un único equipo anfitrión sobre el que implementar un conjunto de servidores virtuales con VNUML, alquilándose su uso a los clientes (que tendrán la percepción de disponer de una máquina convencional, aunque realmente no sea así).

38 4. VNUML VNUML es una herramienta software libre formada por dos componentes: un lenguaje simple y descriptivo basado en XML (extended Markup Language [9]) que permite definir el sistema emulado en un fichero de texto; y un parser de ese lenguaje que se encarga de procesar el fichero, construyendo la simulación y gestionándola, ocultando los detalles complejos al usuario. Esta sección describe las características de VNUML, la sección 5 las ilustra con un ejemplo. Como sistema de virtualización, VNUML utiliza UML, una modificación de las fuentes del núcleo de Linux que permiten su ejecución como proceso de usuario encima del núcleo convencional de Linux. Cada uno de los procesos UML constituye una máquina virtual (con sus propios recursos) dentro de la cual otros procesos se ejecutan (Figura 1). La funcionalidad del núcleo UML es exactamente la misma que la de un núcleo convencional de Linux por lo que la transparencia es (salvo por la pérdida de rendimiento debido al overhead de virtualización) total. UML no solo proporciona la manera de crear máquinas virtuales, sino que existen mecanismos para la interconexión entre ellas mediante redes virtuales (a nivel 2 modo bridge- o a nivel 3). Es posible también conectar equipos externos a la simulación. VNUML también soporta el uso de VLANs (Virtual Local Area Network [12]). UML es una herramienta potente pero compleja si se pretende construir escenarios que incluyan muchas máquinas virtuales y topologías complicadas de red. Además, es necesario tener un buen Proceso Proceso Proceso Proceso Núcleo máquina virtual Redes virtuales Núcleo sistema anfitrión Núcleo máquina virtual Hardware Figura 1. Virtualización con VNUML

39 conocimiento de ciertos detalles del sistema Linux (disposit ivos tap, sockets UNIX, bridges virtuales, etc.) para construir escenarios a mano. La motivación con la que VNUML ha sido desarrollado es evitar esta complejidad, de forma que el usuario tenga que concentrarse solo en la definic ión del sistema emulado, como se verá en el ejemplo de la sección 5. El uso de VNUML/UML implica un consumo de recursos que ha de ser tenido en cuenta en el equipo anfitrión que albergará la simulación. En concreto, podemos identificar los siguientes factores de coste: uso de CPU (especialmente en el momento de arrancar las máquinas virtuales), memoria física (una asignación excesiva de memoria a las máquinas virtuales podría dar lugar a situaciones de thrasing en la memoria virtual del equipo anfitrión) y espacio de almacenamiento en disco (cada máquina virtual tiene asociado un sistema de ficheros que reside en un fichero de gran tamaño normalmente- en el sistema de ficheros del equipo anfitrión). VNUML se distribuye bajo los términos de la licencia GNU y ha seguido un modelo de desarrollo basado en software libre. La página web del proyecto [11] incluye el software para su descarga, así como documentación, tutoriales y soporte para los usuarios. Más aún, VNUML no habría podido ser desarrollado sin apoyarse en un conjunto de herramientas de software libre y estándares abiertos existentes: UML [5] (la base sobre la que se ha desarrollado UML, hasta el punto de que la herramienta puede verse como un front-end de UML), Perl [12] (el parser está escrito íntegramente en este lenguaje, por su orientación a expresiones de texto y la sencillez de mantenimiento de los lenguajes interpretados) y XML [9] (lenguaje sencillo basado en etiquetas en el que se escriben las simulaciones de VNUML). 5. Ejemplo de uso A continuación se incluye un ejemplo simplificado de aplicación de VNUML. Considérese que se quiere emular una topología como la que muestra la Figura 2. El fichero de configuración VNUML que define el anterior sistema es el que se muestra en la Tabla 1.

40 Tabla 1. Descripción VNUML de la simulación <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE vnuml SYSTEM "/var/vnuml/vnuml.dtd"> <vnuml> <net name="net0"/> <net name="net1"/> <net name="net2"/> <net name="net3"/> <vm name="uml1"> <filesystem>/var/vnuml/um11.fs</filesystem> <if id="1" net="net0"> <ipv4> </ipv4> </if> <route type="inet" gw=" ">default</route> </vm> <vm name="uml2"> <filesystem>/var/vnuml/uml2.fs</filesystem> <if id="1" net="net0"> <ipv4> </ipv4> </if> <route type="inet" gw=" ">default</route> <start>/usr/local/samba/smbd</start> <stop>killall smb</stop> </vm> <vm name="uml3"> <filesystem>/var/vnuml/uml3.fs</filesystem> <if id="1" net="net0"> <ipv4> </ipv4> </if> <if id="2" net="net1"> <ipv4> </ipv4> </if> <if id="3" net="net3"> <ipv4> </ipv4> </if> <route gw=" "> /24</route> <route gw=" ">default</route> <forwarding /> </vm> <vm name="uml4"> <filesystem>/var/vnuml/uml4.fs</filesystem> <if id="1" net="net1"> <ipv4> </ipv4> </if> <if id="2" net="net2"> <ipv4> </ipv4> </if> <route gw=" ">default</route> <forwarding /> </vm> <vm name="uml5"> <filesystem>/var/vnuml/uml5.fs</filesystem> <if id="1" net="net2"> <ipv4> </ipv4> </if> <route gw=" ">default</route> </vm> <host> <hostif net="net3"> <ipv4> </ipv4> </hostif> <route gw=" "> /16</route> <forwarding /> </host> </vnuml> Como puede observarse, el fichero de configuración es bastante sencillo: no es necesario que el usuario conozca detalles complejos de UML o Linux para utilizar la herramienta. Cada una de las máquinas virtuales está definida dentro de una etiqueta vm (existe una etiqueta especial, host, que define el entorno de la máquina anfitriona). Por brevedad, no se detalla el significado de las distintas UML1 UML2 UML Net0 Net1 Net UML3 UML Net Host Internet Figura 2. Ejemplo de escenario simulado.

41 etiquetas, remitiendo al lector a [11] para una referencia completa. 6. Conclusiones Las técnicas de virtualización, utilizadas de forma conveniente, pueden suponer un importante margen de ahorro de costes en la implementación de un sistema con respecto a su contrapartida utilizando equipos reales. VNUML es una herramienta de virtualización de propósito general flexible y que simplifica el trabajo del usuario ofreciéndole gran parte de la potencia de UML pero sin tener que enfrentarse a los detalles complejos de creación de máquinas y redes virtuales. De esta forma, el usuario puede concentrarse en la definición de la simulación, que es lo realmente importante desde su punto de vista. Una de las limitaciones de VNUML/UML es que solo permite la creación de máquinas virtuales Linux, aunque es posible conectar equipos externos (como por ejemplo un router Cisco). Una solución a más largo plazo sería cambiar el backend de virtualización, sustituyendo UML por otro sistema que sea más flexible con respecto al tipo de sistemas que puede emular (como por ejemplo, VMware [6], que, entre otros, permite la emulación de sistemas operativos Windows). Los únicos casos en los que VNUML es claramente no utilizable son aquellos en los que se realicen medidas de eficiencia de aplicaciones, ya que el overhead introducido por la virtualización falsearía estas medidas. Referencias [1] Euro6IX, tomado el 7 de Enero de [2] L. Seawright y R. MacKinnon, VM/370: A Study of Multiplicity and Usefulness, IBM Systems Journal, 18(1), [3] Plex/86, tomado el 7 de Enero de [4] Bochs IA-32 Emulator, tomado el 7 de Enero de [5] J. Dike, User Mode Linux, Proc. 5th Annual Linux Showcase & Conf., Oakland CA, [6] J. Nieh y O. C. Leonard, Examining VMware, Dr. Dobb s Journal, Agosto [7] D. Fernández, F. Galán y T. de Miguel. Study and Emulation of IPv6 Internet Exchange (IX) based Addressing Models. IEEE Communications Magazine, vol. 42, no. 1, pag , Enero 2004

42 Técnicas de escalabilidad para servidores Web: balanceo de carga y servidores de altas prestaciones Alvaro Lopez Ortega, <alvaro@gnu.org> 1 Abstract Este artículo estudia el problema de escalabilidad de los servidores web actuales. En primer lugar presenta las posibles técnicas para desarrollar un servidor web, y evalúa el rendimiento de cada una de ellas, exponiendo en último lugar la arquitectura de Cherokee, un nuevo servidor web que combina varias formas de trabajo para obtener un alto rendimiento. A continuación se presentan las posibles arquitecturas de clustering de servidores web con las que resolver el problema de escalabilidad si la mejora en el software no es suficiente y es necesario distribuir el trabajo entre varias máquinas. Por último, estudia y expone una solución basada por completo en Software Libre con la que construir servidores web distribuidos de una forma eficiente, y propone posibles mejoras en el software para conseguir un aumento del rendimiento del cluster. Index Terms web server, clusters, Cherokee, Free Software I. INTRODUCCIÓN DESDE hace años, la tecnología que rodea al Web tiene una importancia grandísima. Desde su creación, este servicio ha aumentado su implantación e importancia de forma exceptacular, teniendo como perspectiva de futuro la continuación de este incremento. Los servidores Web han evolucionado desde sus primeros tiempos pasando de servir unos miles de páginas diarias a procesar la petición de varios millones de ellas. Por otro lado, se ha aumentado considerablemente la complejidad de la generación del contenido servido. Tanto los servicios Web como la generación dinámica de contenidos, son piezas fundamentales de la Internet de hoy en día, pero hay que tener presente que aumentan de forma considerable el tiempo de proceso de cada petición recibida y por tanto el estrés de los sistemas que las atienden. El problema del aumento de la carga de los servidores Web se torna especialmente complicado cuando el número de accesos a uno de ellos aumenta de forma drástica en un corto periodo de tiempo. En este caso, si se trata de un sólo servidor, puede que se vea desbordada su capacidad y por tanto los clientes no reciban respuesta a las peticiones efectuadas. Si se trata de un servidor Web centralizado, la solución al problema es la implantación de alguna de las arquitecturas de clustering web que se estudian a continuación, de forma que si en algún momento el tráfico aumenta de forma repentina se pueda ampliar la capacidad de proceso del cluster para cubrir las necesidades de servicio de los clientes. Por otro lado, existen una serie de mejoras posibles para cada uno de los servidores web. Se ha demostrado que el tiempo de espera en el servidor es el factor fundamental en la velocidad de servicio de una petición HTTP [1], y por lo tanto un factor crítico en la percepción de la velocidad del servicio por parte del usuario. II. ESCALABILIDAD DE SERVIDORES WEB Al hablar de escalabilidad de un servidor Web, nos estamos refiriendo a la capacidad de este para aumentar la cantidad de trabajo que es capaz de realizar, de forma que aumenten de igual manera el número de peticiones respondidas en un periodo acotado de tiempo. Existen dos grandes posibilidades bien diferenciadas para realizar este aumento de rendimiento: la escalabilidad en un único servidor, y la escalabilidad en un conjunto o cluster de servidores. II-A. Escalabilidad en una única máquina La primera opción para aumentar la capacidad de un servidor Web mediante el enfoque de único servidor es la escalabilidad por hardware [2], es decir, la actualización del hardware del servidor a una máquina más potente y rápida. Esta, es una solución de escalabilidad a corto plazo ya que el hardware tiene un limite claro a partir de cual no es posible seguir aumentando la capacidad, de forma que esta opción se tornaría inviable. Dentro de la arquitectura de servidor único se encuentra otro posible punto de mejora sobre el que trabajar para aumentar el rendimiento de los servicios Web: el software. Existen estudios anteriores sobre el diseño de servidores web [3], [4] en los que se presentan posibles diseños o modificaciones del sistema operativo del servidor [5] que persiguen este objetivo. Por otra parte se han realizado mejoras sobre el protocolo HTTP [6] que persiguen de igual forma una menor carga del servidor Web a la hora de servir contenidos: conexiones keep-alive o manejo de caché en el cliente. II-B. Escalabilidad mediante clustering La segunda opción para la escalabilidad de un servidor web tiene como base, al contrario que en el caso anterior, el trabajo con un conjunto o cluster de máquinas conjuntamente. La considerable ventaja de este método radica en la posibilidad de inclusión de nuevas máquinas en el cluster si la carga de este lo requiere, de forma que no se llegue a producir una situación en la que no es posible que el servidor Web aumente el número de peticiones atendidas por unidad de tiempo. Los sistemas basados en más de un servidor web deben cumplir una serie de premisas básicas. El usuario que acceda a uno de estos nodos del sistema ha de tener la sensación de estar accediendo a un único servidor, de forma que no tenga

43 2 que conocer la arquitectura de este, pero pueda interaccionar con él. Los sistemas distribuidos se clasifican en dos grupos[7]. En primer lugar, los sistemas de escalado global. En este caso, cada uno de los servidores puede estar ubicado en un punto geográfico diferente del planeta. Esta forma de trabajo, Fig. 2. Sistema de escalado local Fig. 1. Sistema de escalado global normalmente se implementa utilizando balanceo por medio de un servidor de DNS [8], [9]. Se trata de la primera técnica de balanceo de carga en HTTP que vió la luz - en que consiste en variar la dirección IP destino cada vez que se resuelve el nombre de dominio que se alberga, de entre las de todos los servidores del sistema. La principal ventaja de este método radica en que es posible tener varias conexiones a la red, preferiblemente en diferentes backbones de forma que si alguna de las conexiones falla, únicamente sea necesario modificar el DNS para que el sitio Web siga funcionando sin problemas. Por otra parte, este método también adolece de algunos grandes problemas: cuando el servidor de DNS resuelve una petición, la respuesta incluirá un TTL con el que intentar controlar el sistema de caching en otros servidores DNS intermedios, de forma que si, por ejemplo, el cliente utiliza un servidor local de DNS, este no almacene por un largo periodo de tiempo una de las IPs de uno de los nodos del sistema. El problema de esta forma de trabajo estriba en que algunos servidores DNS cambian el TTL cuando el valor recibido es considerado demasiado bajo. [7] Por último, dentro de la clase de sistemas de escalado global, se pueden incluir los que basan su funcionamiento en la redirección de peticiones, normalmente mediante la utilización de la repuesta 301 (Moved Permanently) de HTTP. En este caso, el principal inconveniente es el aumento de latencia que va a percibir el usuario. Esta es una forma de trabajo que se puede clasificar más cercana al mirroring que al balanceo real de carga. El segundo grupo de clasificación de los servidores Web distribuidos engloba a aquellos que escalan localmente. En este caso, los nodos que componen el sistema, conocidos como Cluster Web o Web Farm [2], se encuentran conectados a una red local de alta velocidad en la que únicamente existe un punto de acceso desde el exterior y desde el cual se reciben las peticiones. En la Figura 2 se muestra un esquema a alto nivel de esta arquitectura. Aunque el cluster puede estar formado por decenas de servidores, únicamente existe una IP pública para todo el sistema que recibe el nombre de VIP (IP Virtual), que es la dirección IP que resuelven los servidores DNS cuando se realiza una consulta sobre el dominio alojado. Como suele ser habitual en los cluster, existe un nodo front-end; en este caso concreto, al tratarse de un Cluster Web, el front-end realizará la tarea de distribuir las peticiones entrantes entre cada uno de los diferentes nodos. Hoy en día, existen balanceadores de carga implementados en hardware, uno de los cuales podría sustituir al nodo front-end y realizar la misma tarea que este. El objeto de este artículo es el exponer una solución software con la que poder construir un cluster Web con total autonomía de dispositivos hardware, de modo que no se profundizará en el uso o desempeño de este clase de balancedores. III-A. III. CHEROKEE WEB SERVER Arquitecturas comunes de servidores Historicamente, se han ido sucediendo una serie de diseños de servidores Web. Como es lógico pensar, cada uno ha evolucionado en algunos aspectos concretos respecto a los servidores anteriores, siendo en todos los casos, el aumento en la velocidad de proceso uno de sus principales objetivos [10], [4], [3]. Algunos de los nuevos diseños de servidores Web se basaron en nuevas arquitecturas para la construcción de esta clase de programas. Desde los años 70 se ha producido un gran cambio en el diseño de servidor Web. En un principio estos programas se basaban en la utilización de un proceso por cada conexión que debían responder; para ello utilizaban la llamada al sistema fork() con el objetivo de clonar el proceso del servidor y de esta forma atender asíncronamente la petición del cliente. El principal problema de este método es la eficiencia, sobre todo cuando el ejecutable que contiene el servidor ha sido linkado dinámicamente, caso en el cual, el rendimiento baja aun más debido al que el espacio de direccionamiento de memoria es más completo, y el sistema operativo tiene más carga para realizar la duplicación [11]. Esta clase de servidores basado en procesos bajo una alta carga, provocan ineficiencias en el sistema operativo a causa del alto número de procesos, ya que el planificador dedica un tiempo excesivo a esta tarea. Esta situación se agraba cuando se trata de máquinas SMP - multiprocesador - en las que es posible que el sistema operativo tenga que mantener la coherencia de las listas del planificador mediante semáforos, aumentando aun más la sobrecarga y por tanto la latencia percibida por el cliente que realizó la petición al servidor.

44 3 Este es el modo en el que trabajaba el primer servidor web de NCSA [3]; algún tiempo después Apache realizó una mejora sobre este sistema, implementando una técnica de pre-forking, es decir, realizar copias del proceso del servidor mediante fork antes de comenzar a servir las peticiones, de forma que en el momento de atender la primera de ellas no tuviera que realizar esta tarea sino usar uno de los procesos que ya se habían creado [10]. Esta es objetivamente una mejora considerable sobre el método anterior, aunque como veremos aun mejorable por otras arquitecturas de servidor. En busca de la solución al problema de rendimiento de los servidores basados en procesos, la siguiente arquitectura utilizada basó su funcionamiento en el manejo de hilos. Como en el caso anterior, supuso una considerable mejora en el rendimiento de los servidores que utilizan este sistema. Hoy en día existen infinidad de servidores que basan su funcionamiento en esta forma de trabajo, aunque como en los casos anteriores hay una serie de circunstancias bajo las que este método provocará que el servidor de comporte de una forma más ineficiente que si hubiese sido implementado tomando como base la arquitectura de un proceso por conexión [12], en concreto, los servidores basados en threads se tornan ineficientes en comparación de los basados en fork() al superar la barrera de las 400 conexiones simultáneas. Existe una forma de atenuar este problema de los servidores basados en threads, que consiste, en la misma línea que el método de pre-forking, en crear un poll de threads en lugar de generar uno nuevo en cada petición recibida por el servidor Web. En contraposición a las arquitecturas expuestas anteriormente, en las que se busca el conseguir un contexto de ejecución asíncrono una vez recibida una petición, existe una arquitectura basada en un único proceso. Al trabajar con un único hilo lógico de ejecución varía considerablemente la forma de trabajo respecto a los casos expuestos anteriormente. Esta clase de servidores, inspeccionan los descriptores asociados a las conexiones en curso y al socket principal del servidor, y a continuación dedican pequeñas fracciones de tiempo a cada una de ellas. Este método de trabajo se basa sobre dos conceptos fundamentales: los sockets no bloqueantes y las funciones de inspección de descriptores. Al igual que las arquitecturas de servidores, esta clase de funciones han evolucionado. Cronológicamente, la primera de ellas es select(). Esta función tiene una serie de problemas bien conocidos: en algunos sistemas no devuelve la cantidad de tiempo que ha estado esperando hasta que uno de los descriptores ha cambiado de estado, realiza un gasto innecesario de memoria teniendo como parámetro un array en el que los números de descriptor realizan la función de índice. La función poll() realiza la misma tarea, pero con una implementación e interface mejoradas respecto a las de select(); en este caso el número de descriptor ya no funciona como índice del array de descriptores pero incurre en la ineficiencia de tener que copiar todo este array de memoria de usuario a espacio de kernel. Por último existe una nueva implementación de esta clase de función llamada epoll() [13] que a día de hoy únicamente está disponible en la rama 2.6 de GNU/Linux. La principal ventaja de esta función frente a sus predecesoras se centra en que se ha hecho una implementación de complejidad O(1) en lugar de O(n) de la misma funcionalidad. Como resultado directo de esta mejora a nivel de kernel, los servidores que utilizan este nuevo API aumentan considerablemente su rendimiento. Fig. 3. III-B. Pasos de una conexión HTTP/1.1 Arquitectura de Cherokee Web Server Uno de los objetivos de este artículo es la exposición y evaluación de la arquitectura y rendimiendo del servidor Web Cherokee[14]. Se trata se un servidor de alto rendimiento con una estructura que ha sido diseñada para obtener la máxima productividad, de forma que proporcione la base para la construcción de sistemas web escalables. En su diseño se ha utilizado un enfoque híbrido de varias arquitecturas de servidores expuestas anteriormente: como primera arquitectura, se utiliza el método de atención a varias conexiones en un único proceso ya que se trata del más eficiente con ficheros pequeños y sin grandes cargas en el servidor. Teniendo en cuenta los problemas de la arquitectura de único proceso, en el diseño del servidor se introdujo parcialmente el modelo de threads para reducir al mínimo el efecto que se produce en un servidor basado en select() o poll() cuando existe una gran carga[12]. En el arranque, Cherokee examina el número de procesadores existentes en la máquina - un factor importante en servidores SMP - para lanzar un número de threads acorde con él. Cada uno de estos threads, en lugar de prestar servicio a una única petición, como en el modelo de arquitectura clásico basado en threads, va a realizar el proceso de varias de ellas, siguiendo el modelo de select()/poll(). De esta forma, dentro del único proceso del servidor existen varios hilos, y a su vez, varios hilos lógicos dentro de cada uno de ellos. Fig. 4. Benchmark servidores Web. Cherokee utilizando un sólo hilo.

45 4 La metodología de funcionamiento consiste en separar dos roles dentro del servidor. En primer lugar, existe un rol de receptor de nuevas conexiones, que únicamente escucha el socket del servidor en busca de peticiones que provienen de algún cliente. En el momento que una conexión se establece, examina los threads en busca del más desocupado, asignando esta nueva conexión a este hilo. Como segundo rol dentro del servidor se encuentran los hilos que atienden las peticiones. Por lo general, no deberían superar los 10 en un servidor que atienda una media de 500 peticiones por segundo. Como se puede ver en la Figura 4, Cherokee obtiene un magnifico rendimiento con cargas moderadas, de forma que el objetivo a perseguir es la duplicación de ese mismo comportamiento, pero en esta ocasión de forma paralela. Hay que tener en cuenta que en la paralelización del código anterior se crean secciones críticas, que deben ser convenientemente aseguradas por medio de uso de métodos concurrentes - semáforos, monitores, etc -. En la implementación del servidor se han reducido estas secciones críticas a tan sólo dos en el servidor completo: la primera en el manejador que distribuye las conexiones entre los diferentes threads del servidor y la segunda en el sistema de logging. El uso de las guardas disminuye ligeramente el rendimiento que a priori parece que podría ofrecer el servidor con más de un hilo, aunque porcentualmente no representa en absoluto una carga extra importante. en Software Libre. Las dos piezas fundamentales de la arquitectura son, un distribuidor de peticiones HTTP y un servidor Web - Cherokee. El software para el balanceo de peticiones HTTP entre los distintos servidores web es Pure Load Balancer (PLB) [15]. En principio, PLB trabaja básicamente como un servidor proxy, aceptando las peticiones de los clientes y retransmitiéndolas a los servidores que forman parte del cluster, aunque no realiza tareas de caching de contenidos o re-escritura total o parcial de la cabecera enviada por el cliente. Fig. 6. Diagrama de funcionamiento de un distribuidor de carga PLB Fig. 5. Cherokee utilizando epoll() Actualmente existen dos formas de utilizar Cherokee, con poll() como función de inspección de descriptores, o con epoll(). En caso de tratarse de epoll() el rendimiento se mantiene según aumenta progresivamente el número de clientes del sistema. En este caso, sería posible decrementar el número de threads para contribuir a que se produzca el mínimo número de bloqueos en las guardas de las secciones críticas. Como se observa en la Figura 5, epoll() no sufre el decremento progresivo que se observa en la implementación con poll(), pudiendo reducir el número de hilos hasta el número de procesadores en el sistema. IV. PROPUESTA DE ARQUITECTURA WEB ESCALABLE Como último punto de este artículo se va exponer la propuesta de una arquitectura Web escalable basada por completo El la Figura 6 se puede observar la secuencia de paquetes que intercambia el cliente con el balanceador de carga y éste con uno de los servidores del cluster. Hay que tener en cuenta que en estas transacciones se utiliza HTTP tanto en la conexión entre cliente y distribuidor de carga, como en la este último con el servidor Web. El balanceador de carga atiende la recepción de peticiones como si se tratase de un servidor web tradicional, y a continuación, establece una conexión con uno de los nodos que forman el cluster. Esta forma de trabajar deja abierta la puerta a incorporar diferentes servidores Web al cluster, posiblemente cada uno de ellos con una tecnología y prestaciones diferentes. De esta forma, es posible ofertar un conjunto de servicios heterogéneos y al mismo tiempo especializados desde lo que a los ojos de los usuarios parece un único servidor web. IV-A. Propuesta de modificaciones del sistema propuesto Tanto Cherokee como PLB son herramientas que se han desarrollado con el objetivo de proporcionar el máximo rendimiento posible. La primera propuesta de mejora de este sistema consiste en aumentar la integración de los programas. Si Cherokee y PLB aumentan su integración, sin perder ninguna de las caracteristicas y funcionalidades de las que actualmente disponen, se podría aumentar el rendimiento del conjunto mientras que se sigue proporcionando el mismo grupo de servicios.

46 5 La propuesta de integración consiste en mantener una conexión permanende de PLB con cada uno de los servidores Web Cherokee, de forma que no sea necesario crear una nueva conexión cuando el balanceador de carga ha recibido una nueva petición o cuando se realiza la desconexión del servidor Web al balanceador. Si se añade esta nueva funcionalidad, se acortaría significativamente el camino crítico de las conexiones que se realizan actualmente[1], y sería posible que PLB trabajase con las conexiones HTTP/1.0, mientras que los servidores del cluster trabajarían con unas conexiones permanentes del tipo de HTTP/1.1 keep-alive. Trabajos recientes [16] indican que a día de hoy en Internet aún es más utilizada la versión 1.0 de HTTP, así que esta mejora en la arquitectura del cluster mejoraría significativamente el rendimiento final del conjunto. Al mantenerse una única conexión entre balanceado y servidor [17], y debido a que cada servidor debe poder recibir cientos de peticiones simultáneas por ella, es necesario introducir un sistema de multiplexación tanto para las cabeceras como para las respuestas del servidor. Un ejemplo de esta clase de implementaciones se puede encontrar en el protocolo FastCGI [18], mediante el cual uno o varios servidores Web se pueden comunicar con diferentes conexiones con un único proceso que ejecuta un programa FastCGI. En este caso, se realizaría una operación similar, encapsulando los datos intercambiados entre Web Server y balanceador en una estructura que especifique a qué flujo de información pertenece cada uno de los paquetes. Una vez hayan llegado al balanceador, se irá retransmitiendo cada uno de los flujos de datos al cliente que los solicitó a través de la conexión que estabeció con el balenceador. La segunda propuesta de mejora consiste en la implementación de un módulo de procesado de las peticiones entrantes para PLB. La función principal de este módulo consiste en analizar las cabeceras de las peticiones aceptadas con dos objetivos bien definidos. En primer lugar, el analizar la petición con el objetivo de aumentar la seguridad del cluster; si el balanceador detecta una petición errónea, mal formada o no permitida, la eliminará sin enviarla a ninguno de los nodos del cluster, de forma que estos no se puedan ver comprometidos por ella. La segunda funcionalidad adicional del módulo consiste en la especialización de servicios en diferentes servidores del cluster. En el cluster pueden existir grupos de nodos especializados en ciertas tareas - por ejemplo, servicios multimedia, ejecución de código en el servidor, servicio de contenidos estáticos, etc. Si el balanceador de carga analiza la petición, es capaz de propagarla a uno de los nodos que puedan atenderla, eliminando así la necesidad de una arquitectura de cluster en la que todos los nodos son iguales. De esta forma, se puede plantear el Cluster Web como una entidad heterogénea en la que conviven diferentes servidores web con diferentes tecnologías y servicios. Cherokee; basado en un concepto de servidor híbrido que consigue unas altas tasas de rendimiento muy superiores a las de otros servidores web existentes. Los resultados de las pruebas realizadas sobre la eficiencia de Cherokee muestran que supera entre un 60 % y un 90 % a Zeus Web Server. Se han estudiado los diferentes factores que intervinieron en el diseño de la arquitectura del servidor, así como los aspectos de su integración con un balanceador de carga y las posibles mejoras que se pueden realizar para que aumente el rendimiento de un cluster Web basado en esta arquitectura. Todo el software necesario[14], [15] para la construcción de un Cluster Web como los expuestos, es libre[19], así como los cambios realizados sobre ellos durante el estudio y redacción de este artículo. REFERENCES [1] Paul Barford and Mark Crovella, Critical path analysis of TCP transactions, in SIGCOMM, 2000, pp [2] B. Devlin, J. Gray, B. Laing,, and G. Spix, Scalability terminology: Farms, clones, partitions, and pack: Racs and raps, in Technical Report MS TR-99-85, Dec [3] Thomas T. Kwan, Robert McCrath, and Daniel A. Reed, NCSA s world wide web server: Design and performance, IEEE Computer, vol. 28, no. 11, pp , [4] Vivek S. Pai, Peter Druschel, and Willy Zwaenepoel, Flash: An efficient and portable Web server, in Proceedings of the USENIX 1999 Annual Technical Conference, [5] Gaurav Banga and Jeffrey C. Mogul, Scalable kernel performance for Internet servers under realistic loads, in Proceedings of the 1998 USENIX Annual Technical Conference, New Orleans, LA, [6] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, RFC 2068: Hypertext Transfer Protocol HTTP/1.1, Jan. 1997, Status: PROPOSED STANDARD. [7] Valeria Cardellini, Emiliano Casalicchio, Michele Colajanni, and Philip S. Yu, The state of the art in locally distributed web-server systems,. [8] T. Brisco, RFC 1794: DNS support for load balancing, Apr. 1995, Status: INFORMATIONAL. [9] Anees Shaikh, Renu Tewari, and Mukesh Agrawal, On the effectiveness of DNS-based server selection, in INFOCOM, 2001, pp [10] Richard Gregory and Ladan Tahvildari, Architectural evolution: A case study of apache,. [11] Adrian Cockcroft, Performance: Static or dynamic linking, in Sun Microsystems: IT World, [12] Felix von Leitner, Scalable network programming, in Linux Kongress, [13] Davide Libenzi, Epoll homepage, [14] Alvaro López Ortega, Cherokee web server, [15] Frank Denis, Pure Load Balancer homepage, [16] Balachander Krishnamurthy and Craig E. Wills, Analyzing factors that influence end-to-end Web performance, Computer Networks (Amsterdam, Netherlands: 1999), vol. 33, no. 1 6, pp , [17] J. C. Mogul, The Case for Persisten-Connection HTTP, in Digital WRL Research Report 95/9, [18] P. Simons and R. Babel, Fastcgi the forgotten treasure,. [19] GNU, GNU homepage, since V. CONCLUSIONES En este artículo se han presentado los conceptos principales tanto de diseño de servidores Web como de balanceo de carga en Clusters Web, y se han expuesto las situaciones bajo las que son preferibles unas u otras opciones. Por otro lado, se ha mostrado un nuevo servidor Web de altas prestaciones,

47 Día h Sala 2: Experiencias, Benchmarking y Estudios de Casos Moderador Adolfo Borrero Director General Telvent Participantes José E. Marchesi Maciej Hapke Luis Miguel Cabezas Ferran Cabrer i Vilagut Angel di Geronimo Thorsten Schreler Alejandro Carrasco Olivier Bunouf GNU Poznan University Junta de Extremadura Muficata, S.L. Fujitsu - Siemens Independiente Universidad de Sevilla Director de Desarrollo Software Libre. Director de Proyectos WebCité

48 OPHELIA Open Platform for Distributed Software Development Maciej Hapke, Andrzej Jaszkiewicz, Krzysztof Kowalczykiewicz, Dawid Weiss, Piotr Zielniewicz Poznan University of Technology Institute of Computing Science Poznan, Poland Abstract This paper is a summary of the open source OPHELIA project, a tool integration open platform for distributed software development. We present basic concepts of the project and some of the novel approaches that proved to be interesting from software engineering point of view. We describe project s outcomes and outline the key future perspectives. 1. Introduction Contemporary software development methodologies define numerous artifact types like error reports, source code, schedules, test cases or documentation. Development tools aid in creating and managing these software engineering artifacts. Unfortunately very often these tools are offered by different software vendors and they vary significantly with the scope and functionality. They are also specialized, offering aid in a specialized area of software engineering like requirements management, software model design, project management, documentation management or risk assessment and control. Finally, it is a rare case for a software vendor to offer a broad range of tools for all of these different domains that could cooperate and exchange information across between different project areas. Meanwhile one of the most frequent problems with software development is the lack of consistency between its artifacts. For example, keeping source code and UML model in sync is a nightmare of every programmer unless the case tool has reverse engineering capabilities and integration with an IDE environment. The same problem applies to updating documentation, test cases, schedules and other project elements. It is in general the problem of reacting to changes introduced to the project and propagating those changes on related elements. The additional effort this operation requires, unless supported by integrated tools, is usually higher than the payoff; that is the main reason most software projects abandon documentation and UML models at certain point of complexity or their lifecycle. Tight development tools integration can help in keeping the software project consistent and prevent proliferation of redundant (and obsolete) project artifacts by automating some of tedious tasks related to change propagation and notification. Unfortunately, what we have already OPHELIA has been jointly developed by a consortium of academic and industry partners and co-funded by the 5th FP of EU.

49 pointed out, most software vendors provide specialized, black-box products that lack wide integration facilities. All these problems need resolution to improve the way software projects are run. Two possible approaches could be distinguished. One of them is to develop a set of tools that build complete unified and distributed environment for managing all software artifacts. Some vendors already provide solutions of such flavor [WWW2003a,c,d]. Commercial software packages are usually of limited availability to small or mid-size companies because of their price (on the other hand, one could argue whether such small companies really need complex distributed development aid). Open source packages and solutions, such as [WWW2003c] require shifting the development process to specific tools, which is sometimes an obstacle. An alternative approach is to develop a framework that could bring together existing software development tools from different domains and create an abstraction layer consolidating them and adopting them for use in an enterprise environment. The abstraction layer here would not only create a bundle of different tools, but also provide a global view of project artifacts, regardless of the tool used to create them, and an additional functionality of relationship tracking and event notification. The OPHELIA project is an example of this second approach. The OPHELIA project has been created and developed by a number of partners from software and academic fields. Our work and contribution to the project has been focused on creating traceability subsystem and integrating it with change notifications. The challenging task was to define the level of inter-artifact links on the abstract level that OPHELIA provides, without the knowledge of what the underlying tools might be. In the following part of this paper we describe the basics of the OPHELIA project and our experiences with the abstract tools layer and tools integration. Chapter 2 compares several existing approaches to tools integration. Chapter 3 describes the OPHELIA project approach in more details, presenting basic architecture, components and integration strategies. The following chapter outlines possibilities the OPHELIA technology could enable a new class of tools making use of the abstract access layer to project artifacts. Chapter 5 presents an implementation of OPHELIA technology Orpheus solution that has been developed to prove the concept. Chapter 6 presents project curriculum and concepts evolution throughout the project period followed with the chapter on future plans and perspectives for continuing project effort. 2. Other development tools integration efforts There are already some solutions on the market that provide different software engineering tools integration in more-or-less limited form. Feature comparison matrix has been shown in the Table Rational Suite Rational Suite [WWW2003a] is a toolset including acclaimed modeling and requirements management applications. The suite includes most of the software engineering tools developed by Rational. As a toolset provided from a single vendor the integration between different applications is very tight. They share their data, allow relationship tracking and provide some traceability services. With software configuration management mechanisms provided the toolset supports distributed development. Rational Suite is one of the most mature solutions on the software engineering tools market. Years of development made this environment industry standard. Unfortunately price of this solution is quite high and may not be acceptable for many, especially mid- and small software companies.

50 2.2. Eclipse Eclipse [WWW2003b] is a development environment created initially in IBM laboratories and contributed as free, open-source product to the developers community. This tool represents new approach to the IDE (Integrated Development Environment) concept. Eclipse is rather a platform for embedding different tools, not only purely development-related, but also for modeling, configuration management, documentation generation etc. The Eclipse project has been widely acclaimed and has been in active development ever since its public release by IBM. Many new plug-ins appear, both free ones and commercial. It seems to be a very good platform for building toolsets and integration services. At the time of writing, distributed development is supported in this platform only using common versioning repository for development files Sourceforge Enterprise Sourceforge website [WWW2003c] became recently one of the centers of open-source development. Its services host over projects (May 2003). A version of Sourceforge called Sourceforge Enterprise [WWW2003d] is available for commercial institutions. It consists of a web-based collaboration environment extended with project management, requirements tracking and several other software engineering modules Feature comparison Feature Table 1. Comparison of tools integration solutions OPHELIA (Orpheus) Rational Suite Eclipse Sourceforge Enterprise Open integration platform Yes No Yes No Open source Yes (except of project management module) No Yes (with many commercial plug-ins) Yes/No Distributed development Yes Yes No Yes Requirements management Yes Yes No Yes * Project management Yes No Yes * Yes Bug/issue tracking Yes Yes Yes * Yes Repository access Yes Yes Yes Yes Relationship tracking Yes Yes * No Yes * Modelling support Yes Yes Yes * No Metrics support Yes Yes No Yes * Development environment Yes * Yes Yes No Testing support No Yes Yes * No Process definition Yes * Yes No Yes * - limited support

51 3. OPHELIA open environment of tools integration, unification and abstraction The aim of the project is to build a unified software engineering tools integration technology. The concept behind the project involves defining standardized set of interfaces abstracting functionalities of different kinds of software development tools. These unified interfaces are access points to the specific tools behind them. This abstraction layer would make OPHELIA environment adaptable to any set of tools. To maintain implementation language independence CORBA technology has been chosen for defining these interfaces. A number of most popular tools categories have been chosen and for each of them a CORBA interface has been defined representing its common internal object model. All these interfaces define the OPHELIA technology. They are described in a set of documents called Module Interface Specification. Base OPHELIA technology includes the following MIS documents: Kernel Services Module Interface Specification Requirements Module Interface Specification Modeling Module Interface Specification Project Management Module Interface Specification Metrics Module Interface Specification Bug Tracking Module Interface Specification Repository Module Interface Specification Knowledge Management Module Interface Specification Traceability Module Interface Specification Notifications Module Interface Specification Depending on the software configuration in a given environment, suitable OPHELIA instances could be created. As different tools may expose different set of functionalities the effort needed to OPHELIA-enable them may differ. The approach is to develop a plug-in that exposes application s functionalities through CORBA interfaces. Because each OPHELIA module becomes in the end a server of a certain artifact type, the underlying tools must have the ability to work in client-server mode. For desktop tools missing this functionality, an additional effort is required to develop the server part of such software. These approaches are summarized in the Table 2. Table 2. Integration of development tools with OPHELIA platform Type of tool Desktop tool Client-server tool Web tool Steps needed to integrate into OPHELIA Server component needs to be written (or reused) implementing appropriate MIS interface. Plug-in for the software needs to be written to communicate with the server. Plug-in for the server part of the software needs to be written implementing MIS interface. Adapter needs to be written to access the data in the tool s database through module s MIS interface. To enable multi-project and multi-user environment additional interfaces have been defined for managing projects and user accounts as well as security mechanisms. These compose OPHELIA kernel services interfaces. The architecture of an OPHELIA solution is presented in Figure 1.

52 OPHELIA Services Layer Notification Services Traceability Services Knowledge Management Integrator Metrics Requirements interface Modelling interface Bug tracking interface OPHELIA Module Interfaces Layer Abstract Tool Services Requirements tool Modelling tool Bug tracking tool OPHELIA Kernel Services Figure 1. Architecture of OPHELIA platform Summarizing OPHELIA itself as a technology is only composed of several CORBA interfaces that should be implemented to build OPHELIA instance. In other words, OPHELIA technology could be compared to a bus in computer architecture forming a base for co-operation of various modules. 4. OPHELIA services utilizing tools abstraction With different tools interfaces defined, new services can be built on top of the existing abstraction layer. These services do not need to rely on any particular tools that lay behind these interfaces. This abstraction creates uniform view on the software artifacts and possibilities emerge to create new kinds of services [KOW2002]. A few of such possible services are listed in this chapter Integrators An example of the new service type that can be built using OPHELIA technology is an integratortype application. Such application can extract data from one tool (using its OPHELIA interface), process it automatically or semi-automatically (with user assistance) and create new project artifacts utilized by different tool type. This type of operation facilitates transferring data from one type of tool to another while minimizing the human effort required for such task. An example of such integrator software could be a wizard that migrates the requirements defined in the project directly to use cases within the modeling tool. Depending on the software process reverse action could be taken as well. Another example of such integration process is an integrator for creating schedule tasks using information about classes and use cases. Relationships defined within modeling tool between these objects affect precedence constraints of the tasks created [HAP1999], [HAP2000]. Integrators that only migrate the data are of course of limited usefulness since they amplify data duplication and synchronization problems mentioned at the beginning. We think that once we have the abstraction layer, the integrators can be pushed further toward intelligent, automated synchronization agents. These, working behind-the-scenes, agents would be responsible for keeping artifacts in sync among all components of an OPHELIA instance.

53 4.2. Abstract Tool Services The MIS interfaces define a unified and public way of accessing project artifacts. With this transparent layer it is possible to provide services for tracing relationships and receiving events from any project element, regardless of the tool used to create or maintain it. Within OPHELIA this layer is called an ATS (Abstract Tool Services). Using the ATS services it is possible to retrieve basic artifact properties and subscribe to events fired from it. The ATS forms the base for other OPHELIA services Traceability Traceability is one of the key aspects of the OPHELIA project. Traceability involves defining and managing relationships between any kinds of objects in the OPHELIA environment. This constitutes a brand new value in a distributed multi-tool environment. Type of relationship Internal explicit External implicit Table 3. Types of relationships in OPHELIA Description Some tools may manage relationships between their objects internally. To maintain their usefulness they should be transferred into OPHELIA traceability services in order to make them propagable. This kind of relations is created automatically by integrator-type applications. Any integrator used to transfer data from one tool to another should create traceability links between the items transferred. External explicit Traceability services allow defining explicit relationships. It is possible to select any two objects and create a traceability relationship propagating or not propagating the events. With traceability relationships defined it is possible to determine the impact potential changes may have on the project by analysis of the graph of affected objects. Moreover it is possible to use traceability relationships to propagate events and supply consistency warnings to items (and users responsible for these items) that may be potentially involved in the change propagation chain. All the objects in the OPHELIA environment and the relationships defined within traceability service make a global traceability graph of the project. This graph includes several types of relationships, which may be created in different ways (see figure 3) Notifications Using the notification service one can subscribe and receive information about any changes made to a particular project artifact. Artifact owners and managers can track the changes on objects and the set of depending objects easier than it was the case when performed manually. An example of such process could be a requirement change that is propagated through previously defined traceability links to the related use cases and then to their implementation files. This way a developer in charge of a given implementation file gets a notification when requirement is changed. We have found out that the fact that no change to an artifact or its dependency graph gets unnoticed is both an advantage and a potential problem. When pushed to the extremes, the number of notification can exhaust any user s patience limits A careful study of usability of notifications

54 and traceability links is scheduled as part of the OPHELIA project, but the results are currently not yet available Knowledge management Knowledge management module allows the user to search project artifacts of different types according to various search criteria. It monitors also changes made in project s artifacts and update project s documentation after each change. If automatic documentation generating facilities are available, this results in always up-to-date documentation available to project stakeholders. What is particularly beneficial and distinguishes the OPHELIA project is that the documentation is generated using the ATS services, so the documentation-engine has no knowledge of what exact tool type it is accessing or how the artifact should be documented (the module that manages that artifact knows these facts) Metrics Unified events management in OPHELIA environment allows building software which can monitor these events and perform certain operations when predefined actions happen. An example of such a service can be an event-driven metrics services. Such services may monitor artifacts that are used for calculating project metrics. With any depending artifact changed or added, the metrics daemon receives an event notification and may recalculate metric value to its current state. It could be even possible to define alert thresholds that would notify project managers if the threshold is exceeded (for example, when module-cross-references exceed a given level). 5. Orpheus OPHELIA solution example One of the key tasks for the OPHELIA project was to create an instance of the OPHELIA technology. Example implementation was assumed to use free, open-source tools where possible. If such tools had not been available, they were to be developed. Commercial tools could be used as a last resort. To present the diversity of approaches for integrating different tools into OPHELIA solution the Orpheus system has been proposed. The components of this solution are presented in the Table 4. Tool type Kernel services Requirements management Modelling Project management Bug tracking Metrics Repository Knowledge management Traceability Notifications Table 4. Orpheus solution components Orpheus implementation custom implementation (free, open-source) DRES (custom implementation, free, open-source) ArgoUML (free, open-source) Microsoft Project (commercial) Bugzilla (free, open-source) The Metrix (custom implementation, free, open-source) CVS (free, open-source) (custom implementation, free, open-source) Traceplough (custom implementation, free, open-source) (custom implementation, free, open-source)

55 Integrators Portal Modeling Project Management Integrator (custom implementation, free, open-source) custom implementation based on Apache Jetspeed (free, open-source) Additionally, several utility software components have been developed to help future OPHELIA solution developers with their work. For instance, common storage repository has been developed to supply versioning XML storage facility for any tools not offering server counterpart. To provide unified front-end for the users utilizing Orpheus solution a web-based portal application has been proposed. It provides users with a common startup point for their daily operations with Orpheus. 6. Project curriculum summary The OPHELIA project is a joint research, development and evaluation effort. The intent was to provide OPHELIA technology specification, develop example solution that relies on this technology and then evaluate the product created in the software development companies there were part of the project consortium. The project started in September 2001 with a debate on the OPHELIA architecture. Few approaches have been identified and discussed upon. These finally transformed into two alternative architectures to choose from. The first one was based on a centralized repository of all software artifacts. This repository would take care of events management, change detection and would provide common storage facility for all the modules. The second approach was to create a more distributed infrastructure with the tools utilizing their own storage facilities where applicable. OPHELIA interfaces would be implemented not by the repository, but by the server counterparts of the tools. As can be concluded from the architecture description in the previous chapters, the second approach has been finally chosen in December Soon after the architecture debate new concepts arose to supply functionalities not described in the initial project description. It turned out that the modules abstraction OPHELIA will provide can be utilized to create new services for managing inter-object relationships and events management. This is how traceability and notification services concepts started in early Later, a portal application has been proposed to provide a front-end for the Orpheus user. In the spring of 2002 module interface specification documents were prepared including initial interface definitions Orpheus solution should implement. It soon turned out that one of the major issues with these specifications is a level of objects granularity they should provide. At this stage events management facilities have been decided to include in the interface specifications. Major development effort was conducted during summer 2002 resulting with early alpha version of the Orpheus solution in autumn Further development had led to the beta version released during spring of Future plans The consortium plans to continue efforts to popularize the OPHELIA technology. Consulting services for companies desiring to adopt the technology are planned as well as supporting broader range of tools. The software created with the project effort will be free and will be contributed to the open-source community.

56 Starting from the beginning of the OPHELIA project it was obvious that this technology opens new possibilities for managing software projects and for developing new services utilizing software artifacts abstraction. Soon the scope became too broad and some of the aspects have been excluded from the OPHELIA project. Members of the consortium have further research and development plans on extensions to OPHELIA platform. The potential research topics are: New tool types specifications (risk management, workflow, testing) Intelligent project monitoring software, detecting process disturbances, management reporting Workflow integration and process definition facilities Integrating with IDEs, e.g. Eclipse [WWW2003b] development platform Migrating to alternative distribution providers (web services) 8. Summary The assumptions and achievement of OPHELIA project have been presented. OPHELIA platform constitutes a new approach to software development tools integration in distributed environment. Its main advantages are openness, low cost, support for distributed work in decentralized environment and the additional functionality like event-driven metrics or traceability, provided on top of the existing software development tools. Within OPHELIA project a specific instance of OPHELIA technology, called Orpheus, has been built. It is expected, that, in the future, further solutions, both open-source and commercial, based on OPHELIA technology should be developed. To some extend OPHELIA platform is a competitor to other development tools integration systems (see chapter 2). At the same time, however, due to distinct and often complementary approaches used in OPHELIA platform and other systems, new promising paths for further integration appear. For example, OPHELIA based solutions may be integrated with open IDEs, e.g. Eclipse. Existing, closed collaborative development environments, e.g. Sourceforge, may re-use OPHELIA technology in order to assure openness of their systems and take advantage of some OPHELIA-specific tools like traceability. References [BOL2003] [DEW2003] [HAP1999] [HAP2000] Boldyreff C., Dewar R., et al., Environments to Support Collaborative Software Engineering. 2nd Workshop on Cooperative Supports for Distributed Software Engineering Processes, Benevento, Italy, March 25, Dewar R., Smith M., et al., The OPHELIA Traceability Layer. 2nd Workshop on Cooperative Supports for Distributed Software Engineering Processes, Benevento, Italy, March 25, Hapke M., Jaszkiewicz A., Kominek P., Integrated tools for project scheduling under uncertainty (in Polish). Proceedings of 1st National Conference on Software Engineering, Kazimierz Dolny , Informatyka Stosowana S4/99, Politechnika Lubelska, Hapke M., Kominek P., Jaszkiewicz A., Slowinski R., Integrated tools for software project scheduling under uncertainty. In: P. Brucker, S. Heitmann, J. Hurink, S. Knust (Eds.) Proc. 7th Int. Workhop on Project Management and Scheduling PMS'2000, Osnabrueck, Germany, April 17-19, 2000, pp

57 [HAP2001] Hapke M., Jaszkiewicz A., Perani S.: OPHELIA - Open platform and methodologies for development tools integration in a distributed environment. Proceedings of 3rd National Conference on Software Engineering, Otwock/Warsaw, p [KOW2002] Kowalczykiewicz K., Weiss D., Traceability: Taming uncontrolled change in software development. Proceedings of 4th National Conference on Software Engineering, Tarnowo Podgórne, Poland, [WWW2003a] [WWW2003b] [WWW2003c] [WWW2003d]

58 Open Source Software (OSS) within organization Critical factors for consulting Thorsten Scherler, Alcántara sistemas de información, S.L. 1 Introduction The consultation of enterprises and organizations regarding the correct implementation of modern information technology is an important segment on the modern consulting market. The main focus of this work is to conduct the consultation in consideration of the topic Introduction of Open Source e- Business Technologies. Michael Porter identified a set of interrelated generic activities common to a wide range of firms and organizations. The resulting model is known as the value chain 1. Due to limited budget funds more and more enterprises are designing their value chain more cost-effective by using web based systems. To conduct business on the Internet is called e-business (electronic business). It refers to not only buying and selling but also servicing customers and collaborating with business partners over a web based system. Mostly all parts of the value chain can be supported by e-business technologies. To further reduce the costs this e-business technologies should be Open Source. 2 Consulting The consultation contains the actors shown in drawing 1 and should be conduct with standardized methods to be objective. This model takes in Client Consultant Business system e-business consulting Solution provider Drawing 1 Business system "e-buisiness consulting" consideration that the consultant do not have to be a solution provider (companies specialized with implementation). This is even better for the objectivity of the deduced solution. Using e-business to consult e-business would mean to conduct parts of the consulting process (standardized methods) over a web based system which will reduce the costs for the consultation itself. 1Porter, M.: Wettbewerbsstrategien (competitive strategy) Methoden zur Analyse von Branchen und Konkurrenten, 7. überarbeitete und erweiterte Auflage, Campus Verlag, Frankfurt/Main, 1992

59 Different consulting companies use different procedure models for their consultation process. As well different authors propose different models. Strasser 2 divides the chronology of the consultation process into the following three phases which can be found in almost all procedure models: t- time Initiation Execution Final stage The client becomes beware that he The consultant collects information The client decides needs a consultation and contacts an about restrictions. He then optimize about the proposal consultant. The consultant analyze which the processes and is looking into and the consultation fields of the client should be remodeled different software solutions. ends. and supported by web based systems. Table 1 Phases of the consulting process 2.1 Initiation The relative position within its industry determines whether a company's profitability is above or below the industry average. The fundamental basis of above average profitability in the long run is sustainable competitive advantage 3. There are two basic types of competitive advantage an organization can possess: low cost or differentiation. To analyze the specific activities through which organizations can create a competitive advantage it is useful to model the organization as a chain of value-creating activities 1. The following procedure model presumes that an analysis of the value chain can deduce general functionality for a software solution. This functionality has to be included in the e- Business technologies that a solution provider offers. Support Activities Procurement Technology Development profit margin Human Resource management Inbound logistics Operations Firm Infrastructure Outbound logistics Marketing Sales Primary Value Chain Activities Service profit margin Drawing 2 Value Chain 2Strasser, H.: Unternehmensberatung aus Sicht des Kunden, Schulthess, Zürich, Porter, M.: Wettbewerbsvorteile (competitive advantage) Spitzenleistungen erreichen und behaupten, 5. überarbeitete und erweiterte Auflage, Campus Verlag, Frankfurt/Main, 1999

60 Activity Primary activities Support activities Goal Create value that exceeds the cost of providing Facilitate the primary activities the product or service, thus generating a profit margin. Activities Inbound logistics include the receiving, warehousing, and inventory control of input materials. Procurement - the function of purchasing the raw materials and other inputs used in the valuecreating activities. Operations are the value-creating activities that transform the inputs into the final product. Technology Development - includes research and Outbound logistics are the activities required to get the finished product to the customer, including warehousing, order fulfillment, etc. development, process automation, and other technology development used to support the value-chain activities. Marketing & Sales are those activities associated with getting buyers to purchase the Human Resource Management - product, including channel selection, the activities associated with advertising, pricing, etc. recruiting, development, and compensation of employees. Service activities are those that maintain and enhance the product's value including Firm Infrastructure - includes customer support, repair services, etc. activities such as finance, legal, quality management, etc. Table 2 Value chain description Michael Porter identified the value chain 1 which can be seen in drawing 2 as a standardized method. The elements of the value chain are explained in table 2. The consultant will conduct a scan of the internal and external environment of every element (primary and support) to know, which processes of the company should be remodeled and supported by e-business technology. Such an analysis of the strategic environment is referred to as a SWOT analysis. The SWOT analysis provides information that is necessary in matching the firm's resources and capabilities to change within the Environmental scan competitive environment in which it operates. The consultant has to identify Internal Analysis External Analysis the activities where the opportunities and Strengths Weaknesses Opportunities Threads Drawing 3 SWOT - Analysis the strengths exceed the weaknesses and the threads.

61 2.2 Execution The activities where the benefits exceeds the costs should be supported by e-business technology. This activities have restrictions on the resources and the capabilities of the internal processes. This restrictions can be mapped to the functionality a software have to provide. Knowing this functionality the consultant has to look for alternatives that exists in the market. He will have to contact solution provider to analyze which software offers the necessary functionality. The final step of the execution phase is to evaluate the cost and the benefits of the software alternatives. The main difference between open source and proprietary software for the consultation is that there are a lot of solution provider for proprietary software and only a few for OSS. This is changing today where for example the MySQL AB 4, who holds the source code for the MySQL database, offers certification, training and a list of solution provider which can help by implementations. The same services offers the JBoss Group 5 which announced a strategic alliance with MySQL 4. JBoss is a J2EE based application server certified by Sun 6. The last example is Orixo 7, a business alliance of European companies specialized in building and supporting enterprise XML solutions around Open Source technologies. All these companies that have been mentioned are part of an active healthy open source community. This is a very important aspect for the quality and long run of a software alternative. To show this importance a short historical overview over open source will be given at the end. The consultant should have a list of solution provider (experienced in the implementation of open source software) which he can contact to get information about software functionality and the community. The consultant should have as well experience with open source communities to evaluate the health of the proposed software in communities aspects. 2.3 Final stage The presentation of the deduced solution should include a cost effectiveness analysis for the software. In case of an open source software the proposal has also to include a SWOT analysis of the community behind the software. In combination of the evaluation of the cost and benefits of the alternatives the client can make his decision based on an objective proposal. 4http:// 5http:// 6http:// 7http://

62 Excursus - Open Source Although it is widely discussed, many people remain confused by just what open source software (OSS) is. The key feature which differentiates an open source product from a commercial software product is that the source code is made freely available and can be modified and altered at will by individual users 8. This has three important consequences. Firstly, there is no charge for the basic software, since anyone can access and compile the code. Secondly, bugs in the software can be identified by any of its users, and can be fixed instantly. Thirdly, users have total freedom in modifying the product to fit their individual needs better. That there is no charge for the basic software does not mean that there are not any costs. The learning curve, a graph showing some measure of the cost of performing some action against the number of times it has been performed 9, to adapt to an open source product or to get information of its functionality is normally signed by higher costs (time) in comparison to a proprietary product. This is due to the fact that there are less solution providers who could help by either an implementation or a consultation about the functionality of the software. A healthy community around the open source product is a very important aspect as well because the history of open source is closely connected to a working software, information and knowledge sharing community. Excursus - Unix The history of Open Source is closely tied to the history of UNIX and GNU / Linux. Open source has a long history that goes back to the creation of UNIX (1969) and further. Traditionally, hardware vendors like International Business Machines (IBM) delivered the source code for the operating systems of their early computers with the shipment of the machine. Furthermore, computer manufacturers actively encouraged users to share improvements to the software out of a belief that it would help save support costs. This belief changed only gradually with the advent of UNIX 10. In October 1973 UNIX became popular in the field of computer science, but it was created 1969 in AT&T Bell Laboratories like Ritchie 11 stated. AT&T had been convicted of antitrust violations in 1956, prohibiting it to start any other business than telephone or telegraph services http:// 10http://citeseer.nj.nec.com/cache/papers/cs/27173/ page 11 11http://cm.bell-labs.com/cm/cs/who/dmr/hist.html

63 After people outside the company had started to get interested in the operating system AT&T had to avoid any conflict with the decree. Their policy was to license the software (allowed by the decree) but not to pursue software as a business. UNIX was provided [a]s is, no support, payment in advance Without support and bug fixes the growing community of UNIX users was forced to help themselves. They started to share ideas, information, programs, bug fixes, and hardware fixes. User groups were created wherever UNIX was introduced. Excursus - GNU / Linux The following quotations are taken from DiBona 12. Starting his job at the MIT Artificial Intelligence Lab in 1971, Richard Stallman joined a software sharing community that had existed for many years. Anytime you stumbled over an interesting program you asked the creator for the source code and read it, changed it or used parts of it to write a new program. Unfortunately, the model was discontinued in the early 1980s, all the created programs were unusable as they were written in assembler language and computers of that era had their own proprietary operating systems. [Y]ou had do sign a nondisclosure agreement even to get an executable copy. He did not want to join the proprietary software world, signing nondisclosure agreements and promising not to help [his] fellow [programmer]. So he was looking for a possibility to be a programmer and work on the establishment of a new cooperative community. He decided that the crucial component was an operating system as you cannot use a computer without it. He chose to make his new system compatible with Unix. Therefore he called his new project "GNU" which stands for the recursive acronym "GNU is Not Unix" and coined the term "free software" in opposition to proprietary software. The "GNU General Public License" (GPL) is based on a method called "copyleft" and is used to keep software free. In order to speed up the project he decided to adapt existing components of free software wherever it was possible. People started using single finished components on the various compatible Unix systems. "By 1990, the GNU system was almost complete; the only major missing component was the kernel." Fortunately, Linus Torvalds started to develop his own Unix-compatible kernel "Linux" in An important aspect was that Torvalds provided Linux under copyleft and invited anyone to help him develop and improve the kernel. The developer community grew quickly with the help of this extraordinary development model and the used infrastructure, the Internet. 12DiBona,C. et al. (editors): Opensources - Voices from the Open Source Revolution, 1999, O'Reilly & Associates Inc., Sebastopol

64 Día h Sesión Auditorio: Modelos de Negocios, Servicios, Marco Legal Moderador Adolfo Hernández Director General Sun Microsystems Participantes Julio Yuste Enrique López Carlos Milchberg Sergio Montoro Rafael Fernández Calvo Javier Aragonés Alfredo Romeo Junta de Extremadura Gerente CASSFA Responsable I+D Open Source- Bull Knowgate Univ. Pont. Comillas, Director de la revista Novática Abogado Suárez de la Dehesa & Sainz Dochado Director General Open Service

65 hipergate: Software Libre en la Empresa Propuesta de Ponencia para la Conferencia Internacional de Software Libre 2004 Ponente: Sergio Montoro Ten KnowGate Consejero Delegado C/Oña, 107 1º Madrid Tel Fax Resumen Esta ponencia trata de los aspectos que propician y frenan la adopción del software libre en las empresas. Está dividida en 5 apartados: 1º) situación general del software libre vs. software propietario, 2º) factores a favor del software libre, 3º) factores en contra del software libre, 4º) presentación de la plataforma hipergate como ejemplo concreto de software libre adaptado al entorno empresarial, 5º) conclusiones. 1 Marco actual del software libre vs. propietario para uso empresarial Si se compara la distribución de mercado entre software libre y software propietario, se aprecian importantes diferencias. En software libre hay unos pocos programas dominantes muy extendidos: Linux, BSD, Apache, Mozilla, PHP, PostgreSQL, MySQL, phpmyadmin, AWStats, JBoss, Compiere, phpnuke, Zope y algunos más. Estos paquetes ejercen un dominio casi absoluto de la cuota de su mercado. A continuación existen una enorme cantidad de software sin terminar, mal documentado, poco estable o en fase de declaración de intenciones; de escaso o nulo valor para su explotación en real. En software propietario, Microsoft domina las aplicaciones de escritorio, pero en otros ámbitos el mercado está repartido habiendo varios contendientes con cuotas significativas de mercado en cada nicho: iplanet, WebLogic, WebSphere, Oracle, SQL Server, DB2, SAP, PeopleSoft, Vignette, BroadVision, etc. Y pequeños jugadores muy especializados: TIBCO, WebMethods, Tamino, etc.

66 La diferencia, desde el punto de vista del comprador, es que el software propietario ofrece muchas alternativas desde los paquetes grandes de amplia cobertura funcional hasta los super especializados. El software libre, por el contrario, sólo dispone de un número muy limitado de opciones razonables, individualmente muy buenas pero sin posibilidad de alternativa. Por otra parte, Linux ha calado tan profundo, que cuando se habla de software libre frecuentemente se asocia inmediata e irremediablemente con Linux. Con independencia de gran valor de Linux, esto es una idea que no contribuye a la difusión del concepto de software libre. En el futuro será posible obtener versiones open souce de Solaris y, casi con certeza, de todas las variantes de UNIX que no quieran desaparecer. 2 Factores a favor del software libre Cero coste en licencias Es un hecho prácticamente indudable que el software libre ha calado antes en la administración pública que en la empresa privada porque el número de licencias a comprar para un proyecto de ámbito nacional es mucho mayor que para un proyecto privado. Cuando se trata de comprar un millón de licencias incluso un coste mínimo de 10 por licencia supone un gran desembolso total recurrente año tras año Estabilidad y Fiabilidad Algunos de los programas decanos del software libre, son indiscutiblemente los más robustos y mejor testeados, empezando por la pila de TCP/IP base de todo Internet. Sin embargo, la calidad de la oferta es desigual y en pocas ocasiones se percibe el software libre como más fiable que el propietario. Rápida Solución de Incidencias Históricamente se ha demostrado que las comunidades de software libre reaccionan más rápidamente ante bugs serios (hasta 5 veces más rápido que las mejores empresas). En el peor caso siempre es factible tomar los fuentes y corregir el error uno mismo, algo imposible con software cerrado. Mano de obra más barata Cada vez es más sencillo conseguir mano de obra con formación en software libre. Esto reduce la necesidad de inversiones en formación en las empresas y reduce los precios de los servicios profesionales.

67 Tecnología punta Muchos de los desarrollos experimentales más avanzados son software libre. De hecho si uno examina la mayoría de los paquetes comerciales es fácil darse cuenta de que están construidos sobre una sorprendente cantidad de software libre reciclado. Usar software libre puede ser una fuente de ventaja competitiva para aquellos adoptadores que basen su oferta en la disponibilidad de tecnología puntera antes que su competencia. 3 Factores en contra del software libre Curva de aprendizaje Quizá el principal factor que sigue impulsando la adopción de paquetes propietarios en nuevos proyectos es que dichos productos son, en general, más fáciles de aprender y de utilizar. Por ejemplo, cuando llega la hora de una evaluación técnica es mucho más sencillo aprender a utilizar desde cero Weblogic Workshop que una combinación de Tomcat, Struts y JetSpeed, aunque el modelo conceptual de ambos sea el mismo. En último término esto motiva que los prescriptores sientan que les será más fácil desarrollar con software propietario que con herramientas libres. Inercia No hay que olvidar que el software libre es algo relativamente nuevo. Muchos programadores y administradores de sistemas veteranos se sienten más cómodos con sus sistemas propietarios de siempre. Carencia de un modelo de negocio para los intermediarios tecnológicos Los clientes necesitan servicios profesionales externos para el desarrollo e implantación de proyectos y las compañías que proveen estos servicios necesitan un modelo de negocio que les reporte buenos beneficios. Actualmente las grandes consultoras negocian macrocontratos de distribución con los principales fabricantes norteamericanos. Estos contratos proporcionan comisiones a las consultoras junto con elevados márgenes en servicios de personal especializado en cada producto muy difícil de conseguir en el mercado. En muchas ocasiones las consultoras perciben el software libre como una amenaza y disuaden al cliente de su uso porque democratiza el mercado (Bjarne Stroustrup dijo en una ocasión que inventó C++ porque los salarios de los programadores de C estaban empezando a caer). Como excepción a lo anterior, existe un mercado que si está creciendo sobre software libre que es el de la formación, especialmente sobre Java, XML y Linux.

68 Ausencia de un canal comercial Un producto requiere de canales comerciales para su difusión. Los productos americanos de mayor tamaño irrumpen en el mercado con campañas de marketing muy agresivas que captan la atención de los usuarios y desarrollan poderosas redes de partners. Comparativamente, el software libre basa su difusión en las comunidades de usuarios, pero las comunidades son intrínsicamente incompatibles con los departamentos de empresas rivales, que deben ocultar sus conocimientos y progresos a la competencia. Falta de soporte Es un efecto secundario de la carencia de un modelo de negocio claro para los intermediarios y de canales comerciales bien desarrollados. La mayoría de los responsables de toma de decisiones no pueden arriesgar su posición apostando por software con soporte inadecuado. Escasez de aplicaciones verticales La oferta de aplicaciones verticales en software libre es en general, inferior a las propietarias. Históricamente esto ha sido la causa de la muerte de arquitecturas enteras de empresas muy poderosas. Arquitectura inadecuada Muchas aplicaciones de software libre no se adaptan bien al sistema de información de las empresas. Se trata de software concebido para una misión específica, no para integrarse dentro de un ecosistema complejo de aplicaciones como suele ser habitual en una empresa mediana o grande. Falta de honestidad de algunos intermediarios tecnológicos Existe un número considerable de intermediarios tecnológicos que venden software propietario como si fuese software libre. En la mayoría de los casos, el negocio consiste en montar Linux y PostgreSQL o MySQL y luego una aplicación propietaria encima por la que se cobra una licencia. Esto confunde a los clientes, y, en muchos casos, sólo es una táctica para embolsarse el mismo coste de las licencias en forma de servicios profesionales adicionales.

69 4 hipergate hipergate es, probablemente, el mayor proyecto open source de software empresarial patrocinado en España por una entidad privada -KnowGate- hipergate es una suite de aplicaciones de Gestión de Ventas, Soporte Post-Venta, e- Marketing, Intranet/Groupware, Gestión de Contenidos y e-business. El proyecto se halla en fase plenamente operativa desde la introducción de la versión 1.0 en septiembre de 2003 con un rápido despliegue en instalaciones en real desde entonces. La misión de hipergate es cubrir un hueco en aplicaciones open source para la empresa. El software se distribuye bajo una variante de la licencia GPL compatible con las normas de OSI. Las características que convierten a hipergate en único dentro de la oferta open source son: Suite Integrada hipergate ofrece una suite integrada junto con un modelo base para agregar ampliaciones fácilmente, a diferencia de la mayoría de los productos open source que son paquetes funcionalmente limitados y difíciles de extender. Multiplataforma hipergate está desarrollado 100% en java y soporta un amplio espectro de bases de datos y servidores de aplicaciones: PostgreSQL, Oracle, Microsoft SQL Server, Tomcat, Weblogic, WebSphere, JRun, etc. Se trata de una arquitectura pensada para integrarse en un ecosistema de aplicaciones. En este punto difiere de la masa de aplicaciones desarrolaldas sobre PHP y MySQL pensadas para correr con muy poco hardware y alojadas en ISPs. Arquitectura usable y escalable Se ha hecho un gran esfuerzo en dotar al software de la máxima usabilidad y escalabilidad. Haciendolo adecuado en entornos desde 1 a miles de usuarios. Propuesta de Negocio para Implantadores y Universidades Dentro de la articulación del producto se ha tenido en cuenta la oferta para que las consultoras, universidades y centros de investigación puedan obtener sus propios beneficios del producto. A las consultoras se ofrece un plan concreto de propuesta de valor a los

70 clientes finales con el que puedan ganar dinero, a las universidades y centros de investigación la posibilidad de utilizar el software como fundamente para sus propios proyectos de investigación en aplicaciones avanzadas. Respaldo técnico, comercial y financiero La plataforma cuenta con un sólido respaldo técnico, comercial y financiero que permite a los clientes confiar en su continuidad. Ámbito mundial Existen versiones en inglés, español y francés y está prevista la publicación de versiones en otros idiomas. El software es adecuado para su uso en cualquier pais. Buena documentación La buena documentación se considera un factor crítico del éxito del proyecto. 5 Conclusiones Actualmente el software libre se halla en una posición muy favorable para empezar a penetrar definitivamente en las empresas, pero necesita del apoyo de los prescriptores tecnológicos para que la oferta se consolide. En los ISPs el tandem PHP+MySQL ya es una realidad pero las empresas requieren de una arquitectura diferente para poder adoptar software libre. Una arquitectura más orientada a la integración de complejos y heterogéneos subsistemas de aplicaciones. Para los fabricantes de software propietario, el software libre supone una grave amenaza, porque rompe las reglas del enfrentamiento comercial. Desde la batalla de Lee contra Grant, los americanos han sido expertos en la victoria por dominio y concentración de recursos. Esta ha sido la táctica de Microsoft para eliminar sistemáticamente a sus competidores concentrándose en ellos de uno en uno aplastándolos a golpe de talonario. Pero esta estrategia no funciona con un enemigo invisible, que prolifera de forma viral por todo el globo. La administración pública puede jugar un papel a favor de la adopción del software libre, pero, por si misma no desplazará a corto plazo la posición de los paquetes propietarios en el sector privado, debido a la fuerza de base instalada y a la diferencia de necesidades entre el sector público y el privado. En España, con hipergate, proponemos un ambicioso proyecto de gran valor social y económico para la mejora de la gestión de relaciones con clientes y la gestión del

71 conocimiento en las organizaciones. Un proyecto en el que reconocemos la necesidad de terminar con los oligopolios del software clásico para sustituirlos por propuestas asequibles a todas las empresas y usuarios y no sólo a los de mayor tamaño y con más recursos económicos. Proponemos una plataforma para que los expertos en tecnología puedan ayudar en el desarrollo de la sociedad de la información a las organizaciones que necesitan de una guía para modernizarse con costes asequibles. Sergio Montoro Ten Madrid 19 de diciembre de 2003

72 LA GNU GPL EN EL ORDENAMIENTO JURÍDICO ESPAÑOL Introducción Como su título indica se trata de analizar la licencia estándar de la Free Software Foundation, conocida como GPL (General Public License), a la luz del ordenamiento jurídico español. Dicha licencia es la defensa jurídica que tiene el software libre frente a las leyes de propiedad intelectual, y es la licencia usada en un 60-70% del software libre en el mundo. No es intención de esta ponencia analizar todas las repercusiones que la GPL puede tener en las diferentes ramas del derecho, sino sólo aquellas que más directamente le afectan. De esta manera, solamente se analizará dicha licencia desde la perspectiva del derecho civil, pues nos encontramos claramente ante un contrato, ya que la licencia es un acuerdo de voluntades entre dos partes sobre un objeto válido y con una causa cierta. Posteriormente, y dado que el objeto de la licencia son los derechos de autor, también se examinará detenidamente la misma desde el punto de vista de la propiedad intelectual, determinado claramente qué derechos se encuentran incluidos en la misma y los limites que la ley establece al respecto. Por último, pero no menos importante, es necesario mencionar las implicaciones de las cláusulas de exención de garantía y responsabilidad, para lo cual se hace necesario el estudio de la legislación sobre consumidores, pues los licenciatarios de los programas de ordenador son, en la mayoría de los casos, usuarios finales de los mismos, y por tanto, es de aplicación dicha normativa. ***

73 Validez de la GPL Antes de comenzar con un detenido estudio de la GPL en las tres ramas del derecho mencionadas, conviene establecer si, a grandes rasgos, más allá de detalles contenidos en una determinada cláusula, la licencia GPL por sí misma, puede o no ser contraria a los principios jurídicos que rigen estas vertientes del ordenamiento. Es decir, si tiene algún rasgo que haga presuponer su invalidez. Desde el derecho civil.- en principio, rige en nuestro ordenamiento una amplia libertad contractual, pues de acuerdo al artículo 1255 Código Civil (CC en adelante) los contratantes pueden establecer los pactos, cláusulas y condiciones que tengan por conveniente, siempre que no sean contrarios a las leyes, a la moral, ni al orden público. Así pues, partimos de la base de que la GPL es, en principio, valida siempre que no sea contraria a: - La moral.- término ambiguo, pero frente a la cual no se me ocurre ninguna contradicción, pues el software libre se muestra como un modelo a seguir al fomentar la libertad y la colaboración entre las personas; - El orden público.- segundo término ambiguo al cual, en principio, el desarrollo de software no se opone de por sí, ahora bien, esto podría ser matizable; - La ley.- en sentido general, el ordenamiento jurídico, con lo que aquí hay que ver que áreas del mismo pueden verse afectadas y si puede la GPL ser contraria a las mismas, que no son otras que el derecho de la propiedad intelectual y el derecho del consumo. Desde la propiedad intelectual.- Como veremos más adelante, la propiedad intelectual presenta muchas peculiaridades, entre ellas, existen ciertos derechos, los morales, que son inherentes al autor e intransmisibles, y otros, los de explotación que, con ciertos límites, sí pueden ser objeto de contratación. En principio, mientras no se afecte a ningún derecho considerado intransmisible por la Ley de Propiedad Intelectual (LPI en adelante), el autor puede disponer de los mismos según estime oportuno, teniendo presentes los límites establecidos en la ley. De los derechos que son objeto de la GPL, en principio, todos se encuentran dentro de los llamados derechos de explotación, y por tanto, a salvo de lo que se diga al tratar el tema con más desarrollo, todo hace suponer que la licencia no es contraria a la LPI. Desde el derecho del consumo.- Dos son los aspectos más relevantes a tener en cuenta. En primer lugar, la GPL constituye un contrato no negociable impuesto por una de las partes, con lo que se ha de reputar su contenido como cláusulas generales de la contratación, y en este sentido se han de respetar los límites que se imponen a las mismas. Así mismo, hay que tener en cuenta que en un gran porcentaje de ocasiones el licenciatario es consumidor a los ojos de la ley y por tanto la GPL ha de respetar los beneficios que la Ley de Defensa de los Consumidores y Usuarios (LDCU en adelante) otorga a los mismos.

74 (I) La GPL como contrato civil Tres son los requisitos que establece el CC en su artículo 1261 para que exista un contrato: consentimiento, objeto y causa. El consentimiento Se manifiesta por la concurrencia de una oferta y una aceptación sobre el objeto y la causa del contrato (artículo 1262 CC). Para que exista consentimiento la doctrina entiende que han de concurrir una pluralidad de partes con capacidad suficiente para contratar y que manifiesten o exterioricen su voluntad. Cuando un autor somete su obra a la licencia GPL y la pone voluntariamente a disposición de todo aquel que la quiera, se está produciendo la oferta, y cuando algún interesado en el programa accede a una copia del mismo y la usa en un sentido amplio (realizando aquello que se le permite), se presume que ha habido aceptación de los términos de la licencia, y, por tanto, que ya se ha realizado el contrato. El objeto Es aquello sobre lo que las partes se proponen contratar. En la GPL el objeto del contrato es el otorgamiento de licencias no exclusivas de determinados derechos de explotación sobre un programa de ordenador por parte de su titular. Sólo tres artículos del CC se refieren a él, pero en lo que a la GPL se refiere, su objeto, ciertos derechos de explotación, es perfectamente válido, pues está en el comercio de los hombres, no se trata de una cosa imposible y se encuentra determinado claramente. La causa De manera sencilla, pues es una cuestión profunda y con muchas interpretaciones, puede decirse que la causa es la razón o fin por el que se contrata, y como requisitos se le exige que exista, sea verdadera y sea lícita. Dichos requisitos se presumen en todo caso aunque no se expresen en el contrato, correspondiendo al deudor probar lo contrario (1277 CC). En la GPL, la causa por la que se mueve cada autor puede ser diferente a la de otro, pero si buscamos un motivo común podría encontrarse en que todos ellos actúan movidos por la generosidad, pues no reciben nada a cambio de los derechos que licencian y buscan la consecución de las libertades consagradas por Richard Stallman en el texto The GNU Project, sacado del sitio web Usted tiene libertad para ejecutar el programa, con cualquier propósito.

75 Usted tiene la libertad para modificar el programa para adaptarlo a sus necesidades. (Para que esta libertad sea efectiva en la práctica, usted debe tener acceso al código fuente, porque modificar un programa sin disponer del código fuente es extraordinariamente dificultoso.) Usted tiene la libertad para redistribuir copias, tanto gratis como por un canon. Usted tiene la libertad para distribuir versiones modificadas del programa, de tal manera que la comunidad pueda beneficiarse con sus mejoras. De ello podemos deducir que la causa en la GPL es la liberalidad, causa en la que concurren las características enunciadas, pues existe, es verdadera y es lícita, pues no se opone a las leyes o a la moral. El perfeccionamiento Una vez delimitados los requisitos de un contrato hay que ver si éste cumple con las exigencias necesarias para entenderse perfeccionado, y, por tanto, es capaz de crear obligaciones entre las partes del mismo. En este sentido, el artículo 1258 CC dice que los contratos se perfeccionan por el mero consentimiento, y desde entonces obligan, no sólo al cumplimiento de lo pactado, sino también a todas las consecuencias que, según su naturaleza, sean conformes a la buena fe, al uso y a la ley Ahora bien, surgen diversas dudas sobre el momento de perfeccionamiento de la GPL, (es decir, el momento en el consentimiento se entiende válidamente otorgado y las cláusulas da la licencia se convierten en vinculantes para las partes), pues no nos encontramos ante un contrato usual, ya que no se trata de un objeto físico que necesite cambiar de manos, puede que no estén presentes las partes (como suele ocurrir) y encima, el mismo no se rubrica por las partes con su firma en señal de aceptación, ya que lo más normal es descargarlo de Internet, copiarlo de un conocido o comprarlo en una tienda. Para que ese consentimiento se dé y el contrato se perfeccione, la oferta ha de realizarse con voluntad de obligarse, lo que sucede aquí, pues nadie obliga al autor a licenciar bajo los términos de la GPL; ha de ser concreta, de manera que se incluyan los elementos necesarios para la celebración del contrato, que también se cumple en la GPL, pues quedan claramente establecidos los derechos que se licencian y lo que el licenciatario puede y no puede hacer; y debe dirigirse a la persona con la cual se quiere contratar. Sobre este último punto, concreción del destinatario de la oferta, algún autor puede oponerse a su admisión en relación con la GPL, pues en ella el destinatario no se encuentra determinado, ya que cualquiera puede serlo, pero frente a esta postura se puede alegar que en el mismo CC ya hay otros contratos con destinatarios indeterminados (la promesa pública de recompensa, por ejemplo) y fundamentalmente, que la voluntad del licenciante es obligarse precisamente frente a todo aquel que acepte la licencia.

76 A ello se puede sumar el nombre mismo de la licencia, que no es otro que Licencia General Pública, lo que nos da una idea inconfundible de que se trata de una licencia abierta a todo aquel que la acepte y asuma lo que en ella se estipula. Sería lo mismo que comprar el periódico en el quiosco de la esquina, está ahí esperando que alguien lo coja (cualquiera que pase) y pague el precio que figura en su portada al quiosquero, oferente, para perfeccionar un contrato de compraventa. Hubo una oferta concreta sobre el objeto (periódico), la causa (el lucro del quiosquero y la necesidad de información del lector) y las condiciones (un euro, un periódico) dirigida a un pluralidad indeterminada de destinatarios, que se perfecciona por la aceptación de uno de ellos manifestada por el acto de coger el objeto y cumplir con la contraprestación establecida (entregar un euro al quiosquero). Junto a la oferta válida realizada por el autor del programa, tiene que concurrir la aceptación del destinatario, a la cual se le exige ser pura y simple, correspondiendo exactamente a lo ofrecido, y encontrarse dirigida al oferente con el propósito de celebrar el contrato. Se suscita ahora un tema muy discutido siempre que se habla de contratos celebrados entre ausentes (la mayoría en relación a la GPL) y es el de determinar el momento en el que ha de entenderse perfeccionado el contrato. Al respecto hay dos teorías principales, la de emisión y la de conocimiento. La primera entiende perfeccionado el contrato desde que el destinatario manifiesta su aceptación, mientras que la segunda entiende que la perfección se produce en el momento en el que el oferente tiene conocimiento de la aceptación por parte del destinatario. No es una cuestión banal, pues si se opta por la segunda, presente para algunos supuestos en el CC, en la mayoría de los casos no se podría entender perfeccionado el contrato alrededor de la GPL, y por tanto, no surtiría efectos entre las partes (autor del programa y licenciatario del mismo). Para otorgar validez a la GPL habremos de optar por la primera de ellas (la de la emisión). De esta manera, podríamos interpretar que el contrato se perfecciona desde que el interesado realiza cualquier acto que manifieste su aceptación de los términos de la misma (descarga e instalación del programa en cuestión, acceso a su código fuente, distribución del mismo, etc ). Esta teoría se ve corroborada por la misma letra de la GPL, que, recordemos, es la voluntad del autor, y en cuya Cláusula 5 se reconoce que no hay otra forma de confirmar la aceptación de la licencia que el ejercicio de las facultades que en la misma se autorizan, pues el aceptante no la firma. La GPL como contrato atípico Tras ver, según la teoría general de los contratos, que la GPL es un contrato válido y perfecto, toca examinar ante qué clase de contrato nos encontramos, si se corresponde con alguno de los regulados por la legislación, con lo que se trataría de un contrato típico, y a su regulación habríamos de remitirnos; o si, por el contrario, éste no se encuentra tipificado y por tanto es un contrato atípico para cuya aplicación habremos de referirnos a su clausulado.

77 Puesto que el autor oferente no recibe ninguna contraprestación y la causa del contrato es la liberalidad, como ya vimos, podemos afirmar que se trata de un contrato gratuito y por ello deberíamos examinar los contratos gratuitos regulados para ver si se ajusta a alguno de ellos. El primero que viene a la mente es la donación, pero el encaje de la GPL en dicha figura hay que descartarlo pues en la licencia falta uno de los requisitos establecidos para la existencia de la donación: la disminución del patrimonio del donante. No se produce dicha disminución por la particularidad del objeto de que se trata, pues el donante, como se explicará más adelante al hablar de los derecho de autor, solamente otorga una licencia no exclusiva sobre determinados derechos, lo que significa que no se ha producido una transferencia de un derecho de su patrimonio al del donatario, ya que al ser no exclusivo el autor conserva la idéntica facultad de realizar por sí mismo lo licenciado o incluso cederlo nuevamente a un tercero si le place. Lo único que puede suceder es un posible menor ingreso debido a la existencia de licenciatarios concurrentes, pero esta situación no se ha de entender como disminución de patrimonio. Otro contrato gratuito regulado en el CC es el comodato, nombre que se le da al préstamo de cosas no fungibles (sustituibles), pero tampoco es aplicable, pues se trata de un contrato real y unilateral, características que no reúne la GPL. Quedaría algún otro contrato gratuito típico, pero baste decir que no se ajustan a las características de la GPL por razones que aquí no interesan. Tras este análisis cabe concluir que estamos ante un contrato atípico (no regulado específicamente en nuestro ordenamiento) para cuya aplicación se ha de estar a lo que su contenido diga. Como ha establecido el Tribunal Supremo en sentencias de 18 de noviembre de 1980 y 7 de enero de 1981: cuando una relación obligatoria contractual contiene suficientemente los requisitos que el ordenamiento jurídico civil exige para su validez y producción de efectos (art del C. Civ.), no hay necesidad de esforzarse en seguir los viejos cauces del dogmatismo jurídico e intentar encajar, más o menos a fortiori, el pacto o convenio en cuestión en los tipos contractuales civiles perfilados en las leyes, ya que, sobre no aparecer en ningún lugar normativo esa exigencia asimiladora (salvo la aplicación analógica ex art. 4 del C. Civ., como función integradora del juez), bastará con que el intérprete y juzgador se atenga a lo estipulado si ello es lícito, conforme al artículo 1255 del C. Civ. y sancione ex oficio judex sus naturales consecuencias en orden a la eficacia y efectos (art C. Civ.) de lo acordado libremente por obra de la autonomía de la voluntad, ya que lo que importa no es el nomen iuris, sino la licitud, validez y eficacia del contrato en conjunción con los intereses en juego, sea más o menos típico, atípico, simple o complejo, y siempre, naturalmente, que sus cláusulas contengan las suficientes especificaciones para su normal cumplimiento.

78 Dicha jurisprudencia confirma lo dicho hasta ahora y sirve para encauzar con los efectos de la GPL en las partes contratantes. Efectos Ahora que ya se ha determinado que estamos ante un contrato atípico, válido y perfecto es el momento de hablar de sus efectos, o lo que es lo mismo, de las consecuencias que produce en la actuación de las partes. El primer efecto de todo contrato es su obligatoriedad para las partes, y ello a través de dos preceptos, por un lado el artículo 1091 CC, que establece que las obligaciones que nacen de los contratos tienen fuerza de ley entre las partes contratantes, y deben cumplirse al tenor de los mismos, y por otro, el artículo 1278 CC que enuncia que los contratos serán obligatorios, cualquiera que sea la forma en que se hayan celebrado, siempre que en ellos concurran las condiciones esenciales para su validez. A ese efecto general común a todos los contratos hay que sumar los efectos particulares de la GPL, que no son otros que los en ella contenidos y regulados en su clausulado, pues, sólo si son contrarios a la ley, a la moral o al orden público dejarán perderán la condición de ser obligatorios para las partes, como establece el Tribunal Supremo en las sentencias citadas. El clausulado de la GPL Se puede clasificar el clausulado de la GPL en dos grandes grupos, las referidas a los derechos de propiedad intelectual (Cláusulas 0, 1, 2, 3, 6, 8 y 10) y las de contenido civil y o de consumo (Cláusulas 4, 5, 7, 11 y 12). Restaría únicamente la cláusula 9 que se refiere a las versiones de la misma licencia. Puesto que las cláusulas de la GPL que se refieren a derechos de autor serán tratadas en el apartado siguiente, en este apartado analizaremos las obligaciones civiles que asumen las partes. Cláusula 4.- Contiene esta cláusula la principal causa de resolución del contrato mediante la imposición de unas condiciones u obligaciones que limitan la libertad de actuación del licenciatario, y cuyo incumplimiento provoca la revocación automática de la licencia. Esta cláusula encuentra una correlativa en la regulación de las donaciones, concretamente el artículo 647 CC, que establece que la donación será revocada a instancia del donante, cuando el donatario haya dejado de cumplir alguna de las condiciones que aquel le impuso. La doctrina ha señalado como fundamento de dicho precepto, sin dificultad ni controversia, el respeto a la voluntad liberal del donante. Puesto que la GPL también es un acto de liberalidad, como se ha dicho, la voluntad del autor del programa debe ser respetada en todos sus extremos y no parece abusivo imponer ciertas obligaciones a un

79 licenciatario que no ha tenido que realizar ninguna contraprestación para la obtención del los derechos que le otorga la licencia, lo que es perfectamente acorde y compatible con lo ya establecido de que rige para este contrato la voluntad de las partes como primera fuente de sus obligaciones. El imponer que los actos autorizados por la licencia se hayan de ceñir a lo estrictamente estipulado es muy importante, sobre todo en relación a las condiciones de mantener los posibles programas derivados (modificados) bajo el régimen de la GPL, pues es lo único que puede mantener el software libre como libre, sin posibilitar su salida a un ámbito más restrictivo en el que alguna de las cuatro libertades buscadas pueda verse limitada. Contiene esta cláusula una mención al mantenimiento de los derechos adquiridos por terceros de buena fe. Dicha estipulación es perfectamente válida y es un principio de nuestro ordenamiento presente en la mayoría de instituciones jurídicas, incluso en un derecho tan especial como el de la propiedad intelectual encontramos una cláusula semejante en la Disposición Transitoria 1ª de la ley que la regula. Cláusula 5.- Esta cláusula ya fue mencionada con anterioridad, baste recordar que contiene la norma sobre aceptación y perfeccionamiento de la licencia. Cláusula 7.- Hace mención esta cláusula a otra condición impuesta al licenciatario en cuanto limita su posibilidad de actuación. El propósito de esta cláusula, como en ella se estipula, es mantener la integridad del sistema de distribución del software libre, el mismo que la examinada cláusula 4, aunque en ella no se mencione, probablemente por evitar redundancias en texto de la GPL. De acuerdo a esta cláusula, cuando se imponga al licenciatario, por cualquier motivo o procedencia, una condición que le impida cumplir todos los términos de la licencia, deberá abstenerse de realizar la conducta condicionada por terceros, y ello no es por restringir los derechos del licenciante, si no por mantener el sistema del software libre. Desde el punto de vista de la propiedad intelectual, en el caso de obras derivadas, esta cláusula se justifica, como veremos más adelante, en el articulo 21.2 de la LPI, pues no puede explotarse la obra derivada en perjuicio del derecho del autor de la obra preexistente (el licenciatario de la GPL). Cláusula 11.- De suma importancia son tanto ésta, como la Cláusula 12, pues contienen las cláusulas de exención de garantía y responsabilidad, respectivamente. Es este apartado sólo hablaremos de estas cláusulas desde el punto de vista civil contractual, dejando la vertiente del consumo para ser tratado de manera independiente al final de la ponencia. En cuanto a la exención de garantía es conveniente matizar una cuestión. Lo que aquí se diga va referido solamente al bien inmaterial que es objeto de la licencia (el programa de ordenador), pues en los supuestos de distribución del mismo en objetos físicos (CD)

80 a cambio de precio, el distribuidor lógicamente responde de la idoneidad del bien para el fin por el que se pone en el comercio. Es decir, si compro un paquete de distribución de Linux y el CD no funciona, tienen obligación de entregarme uno que sí funcione. En cuanto al programa en sí, puesto que el licenciatario se supone que ha leído y aceptado la licencia, ya se encuentra avisado de la ausencia de garantía, pues esta cláusula y la siguiente son las únicas que vienen escritas en mayúsculas, evidentemente para resaltar su importancia y captar la atención del posible licenciatario hacia la posibilidad de que se trate de un producto no perfecto. Las razones y justificación de esta cláusula hay que buscarlas principalmente en la voluntad de las partes, pero también en los usos y en los fundamentos del software libre y puede ser interpretada según la naturaleza del licenciatario. La voluntad del autor se encuentra en su ánimo de liberalidad. Desinteresadamente realiza una aportación a la sociedad, y es ese espíritu de colaboración desinteresada llevada a cabo con buenas intenciones lo que permite excluir la garantía sobre el producto. En el mundo del software libre éste es el uso, la costumbre. La generalidad de usuarios son conscientes de que quien somete un programa a la GPL lo hace desinteresadamente, cobrando en todo caso por la distribución (sobre la que sí hay garantía) y que dicho programa es susceptible de tener errores. Y nadie piensa en reclamar a su autor, pues éste no tenía, ni tiene, ninguna obligación de suministrar el programa en perfecto estado, pues la inexistencia de programas perfectos es un hecho, incluso en el software propietario. Exigir una garantía a quien desinteresadamente hace una aportación a la sociedad para que otros puedan beneficiarse y, si son capaces, mejoren su trabajo eliminando los fallos, es contraproducente, pues desincentivaría a todo aquel que quisiera desarrollar un programa. También hay que tener presente que los desarrolladores desinteresados no actúan sometidos a la presión del mercado y a sus plazos de entrega y de marketing. Un desarrollador desinteresado programa por el placer de hacerlo, por aportar algo a la comunidad, y busca aportar una utilidad, no un beneficio, con lo que sólo pondrá el programa en circulación cuando crea que está suficientemente depurado, no como una empresa de software propietario que tiene que vender ya, como esté, y luego ya harán parches corrigiendo los errores (lo que pasa todos los días). Sería lo mismo que si yo regalo mi bicicleta vieja a un conocido, y éste, un día pedaleando montaña abajo, al ir a frenar, tiene un accidente porque el cable del freno se rompe debido a que estaba desgastado. Se me puede considerar responsable? En el CC diversos preceptos citan los usos y la costumbre como fuente del derecho y como criterio de interpretación, desde el artículo 1 (es fuente del ordenamiento) hasta el artículo hasta el 1282 ( para juzgar la intención de los contratantes, deberá atenderse a los actos de éstos, coetáneos y posteriores al contrato ) o el artículo 1287 ( el uso o la costumbre se tendrán en cuenta para interpretar las ambigüedades de los contratos ), que sirven para aplicar los usos mencionados a esta situación.

81 Así mismo, en otro contrato gratuito, como es la donación, el articulo 638 CC excluye al donante de responder por el saneamiento, lo que podría aplicarse de manera analógica en el supuesto de la GPL, pues como se dijo ya, ambas figuras presentan similitudes y en este supuesto la regulación de la donación puede servir de guía. Y, mencionado el saneamiento, en su regulación se hace mención a la exclusión de responsabilidad por los vicios ocultos si el comprador es un perito que, por razón de su oficio o profesión, debía fácilmente conocerlos. No es lo mismo que el licenciatario sea un informático que va a hacer uso de su derecho de modificación (que es plenamente consciente de que el programa no es perfecto y probablemente intentará mejorarlo en lo posible para el bien de la comunidad), que un mero usuario final sin conocimientos en programación que obtiene el programa sólo con intención de usarlo (que a lo mejor se siente defraudado en sus aspiraciones), así pues frente al segundo no se responde por lo ya dicho y frente al primero no se responde, además, por la propia regulación del saneamiento. Cláusula 12.- Prácticamente todo lo dicho para la cláusula precedente es de aplicación a ésta otra, con lo que a ella nos remitimos para evitar redundancias. En esta cláusula se establece la exención de responsabilidad del autor en el supuesto de que el programa licenciado cause daños y perjuicios al licenciatario, siempre con los límites establecidos por la legislación aplicable a la relación contractual vigente entre las partes. Para hablar de responsabilidad, lo primero que hay que distinguir claramente son los conceptos de dolo y culpa, determinantes del nivel de responsabilidad en que se puede incurrir. La responsabilidad en la que puede incurrir una de las partes de un contrato respecto de la otra, se llama responsabilidad contractual y está regulada en el artículo 1101 CC en los siguientes términos: Quedan sujetos a la indemnización de los daños y perjuicios causados, los que en el cumplimiento de sus obligaciones incurrieren en dolo, negligencia o morosidad, y los que de cualquier modo contravinieren el tenor de aquella. Hay dolo cuando el responsable tiene conocimiento de que su acto es antijurídico y aún así lo realiza. Se caracteriza por esa nota de voluntariedad, de realizar el acto aún sabiendo que contraviene las normas establecidas. Esta cláusula de exención de responsabilidad significa que, si un autor sabe que su programa puede producir daños y perjuicios a los posibles licenciatarios, y, aún así lo pone al alcance de todos con la apariencia de proporcionar un programa normal y eficaz, está actuando con dolo, y de acuerdo a la legislación vigente esa circunstancia no le exime de responsabilidad por los daños causados. En concreto, el artículo 1102 CC establece que la responsabilidad procedente del dolo es exigible en todas las obligaciones. La renuncia a la acción para hacerla efectiva es nula

82 En cuanto a la culpa, esta se produce cuando el responsable no pone la debida diligencia en el cumplimiento de sus obligaciones. El nivel de diligencia ha de ser el normal exigible en las relaciones sociales, aquel nivel de diligencia que, de haberlo empleado, podría haberse evitado el resultado negativo. Este tipo de responsabilidad es difícil que se dé en relación con el software libre, pues como se dijo antes, los autores desinteresados no tienen la presión del mercado y lo que buscan es aportar una utilidad a la sociedad, para lo cual ponen todos sus esfuerzos e intentan hacerlo lo mejor que pueden, pues el reconocimiento de la comunidad es muchas veces la única recompensa que se busca. Además, según la doctrina más autorizada, la responsabilidad por culpa puede modularse por contrato, e incluso, puede eliminarse, cuando dicha renuncia no esté prohibida, como sucede con el dolo ya mencionado 1. Así pues, sin perjuicio de lo que se diga más adelante en los supuestos en los que resulte aplicable la normativa de protección de los consumidores, dicha cláusula de exención de responsabilidad resulta válida de acuerdo a la legislación civil. 1 Casos en que cesa la obligación de resarcimiento.- Cesa la responsabilidad en los siguientes casos: a) Cuando no se da la antijuricidad de la conducta (causas de justificación como el estado de necesidad) b) Cuando no concurre imputabilidad (daños causados por incapaces), si bien la responsabilidad se traslada en estos casos a los guardianes. c) Cuando en virtud de pacto se elimina la responsabilidad (pactum ne culpa praestetur), siempre que la renuncia no esté prohibida (como lo está en el caso del artículo 1102 con respecto a la responsabilidad procedente del dolo). d) Cuando el propio perjudicado haya incurrido en culpa (caso de coexistencia de culpas, que puede traducirse no en una total exoneración, sino en una disminución de responsabilidad, quedando así repartidas las consecuencias del hecho dañoso entre el agente y el perjudicado) e) Cuando el hecho en sí haya sido imprevisible e inevitable (caso fortuito). José Castán, Derecho Civil Español, común y foral. Tomo 1 Vol. II, pg. 686, duodécima edición, ed. Reus, Madrid 1985.

83 (II) La GPL como licencia de derechos de autor Antes de entrar a analizar el clausulado de la GPL relacionado con los derechos de autor, habría que describir brevemente las principales características de la propiedad intelectual. Los derechos de autor Cuando una persona crea una obra literaria, musical, científica o artística, pasa a ser titular de esa obra y es libre de decidir acerca de su uso. Incumbe, pues, a dicha persona lo que desea hacer con su obra. La obra está amparada por el derecho de autor desde el momento de su creación y no es necesario proceder a trámite alguno, como el registro o depósito para obtener la protección que otorga el sistema. Lo que se protege no son las ideas sino la forma en que se expresan esas ideas. Por derecho de autor se entiende la protección jurídica que se otorga al titular de los derechos sobre una obra original de la que es autor, figura central del sistema al que se busca proteger, pues se le considera, y generalmente sucede así, la parte débil en la contratación. El derecho de autor comprende dos categorías principales de derechos: los derechos morales y los derechos patrimoniales. Por derechos morales se entiende el derecho del autor a oponerse a cualquier deformación, mutilación o modificación de su obra que pueda ir en detrimento de su honor o reputación. Estos derechos contenidos en el artículo 14 del Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el Texto Refundido de la Ley de Propiedad Intelectual (LPI) se consideran irrenunciables e intransmisibles (salvo mortis causa, y no todos), con lo que nunca salen de la esfera del autor. Los derechos patrimoniales pueden describirse como todas las posibilidades de explotación derivadas de la utilización de la obra, por eso también son llamados derechos de explotación. Se comprenden en tal concepto los derechos de reproducción, distribución, comunicación pública y transformación, de acuerdo al artículo 17 LPI. Estos derechos sí son transmisibles y se encuentran en el comercio y se hallan regulados independientemente, y con mayor detalle, en los artículos 18 (reproducción), 19 (distribución), 20 (comunicación pública) y 21 (transformación), todos de la LPI. Ambas categorías de derechos son prerrogativa del creador, que es quien tiene derecho a utilizar la obra, a autorizar a terceros el uso de la misma, o a prohibir su uso. Por principio general, las obras protegidas por derecho de autor no pueden utilizarse sin previa autorización del titular del derecho. No obstante, existen pequeñas excepciones a esta norma. El sistema de transmisión de los derechos de explotación también presenta particularidades, pues aunque el autor quiera, no puede ceder todos los derechos y desentenderse de su obra. Siempre permanecen en su esfera los derechos morales, las

84 modalidades de explotación que no se deduzcan del contrato y las inexistentes en el momento de la transmisión y ciertos derecho de remuneración. Es el artículo 43 LPI el que regula la transmisión de los derechos de explotación por actos inter vivos, respecto a la cual es necesario hacer un par de comentarios. La cesión de derechos queda limitada a los derechos cedidos, a las modalidades expresamente previstas y al tiempo y ámbito territorial que se determine. De no mencionarse estos extremos, la cesión se limita a las modalidades que se deduzcan del contrato, al ámbito territorial del país en el que se realice y a cinco años de duración. Trasladando esto a la GPL, en ella se mencionan expresamente los derecho cedidos, pero nada se dice del ámbito territorial o temporal. Como se dirá analizar el clausulado, podría entenderse que la cesión se realiza para el mundo entero, y en relación al tiempo, la ausencia de su mención no parece afectar mucho pues en cinco años, a la velocidad en que la informática evoluciona, ya casi no tiene interés el software para usos comerciales. Tras estas nociones básicas sobre los derechos de autor toca analizar el clausulado de la GPL más detenidamente para determinar con precisión los derechos concretos que se licencian. Cláusula 0.- Contiene principalmente las definiciones que se usarán a lo largo de la licencia y describe sucintamente lo que se encuentra cubierto por ella. Sobre el término programa ciertas precisiones merecen ser hechas. La primera, que de acuerdo al artículo 96 LPI, que contiene la definición de programa de ordenador, a efectos de la propiedad intelectual, dicho término incluirá también la documentación preparatoria mientras que la documentación técnica y los manuales recibirán la misma protección que la LPI otorga a los programas. A su vez, en la GPL se dice que el término programa se aplicará también a cualquier tipo de obra que se someta a dicha licencia, pero hay que advertir que no toda obra protegida por la propiedad intelectual es apta para ello, por ejemplo, una obra plástica suele ser un ejemplar único, y sería de dudoso encaje con respecto a una licencia no exclusiva. Cláusula 1.- Esta cláusula se refiere a dos derechos de explotación, el de reproducción del artículo 18 LPI y la distribución del artículo 19, hablándose en ambos casos de copias en sentido estricto, tal como fue recibido el original, y referidas únicamente al código fuente. Se permiten los actos de reproducción y distribución siempre que se respeten las condiciones impuestas, siendo las referidas a los avisos de titularidad exigibles no solo desde el punto de vista contractual sino también desde la propiedad intelectual, pues estamos hablando de un derecho moral, el de ser reconocido como autor de la obra.

85 De acuerdo a esta cláusula, se permite cobrar por el mero hecho de la transferencia física del soporte del programa, con lo que no ha de entenderse incluido en ningún caso que se permita cobrar por la licencia en sí, pues son dos conceptos bien diferenciados. Así mismo, esta cláusula permite que se ofrezca garantía a cambio de un precio. Cabe decir que dicha garantía la ofrece el licenciatario independientemente del autor, que en su licencia (si no especificó lo contrario) excluyó tal extremo. Nota.- Las referencias al derecho de distribución han de entenderse comprensivas de el derecho de puesta a disposición, tal como lo reconoce el artículo 3 de la Directiva 2001/29/CE pues en la legislación estadounidense tal derecho se incluye como modalidad de la distribución, mientras que en Europa se incluye como modalidad de comunicación pública. Así pues en la GPL se incluyen los derechos de reproducción, distribución, transformación y puesta a disposición (modalidad del más genérico de comunicación pública). Ello es así porque el método más usual de distribución de programas de ordenador es Internet, en la Cláusula 1 se dice por cualquier medio y en el último párrafo de la cláusula 3 se establece que ofrecer el acceso al código objeto en un determinado lugar es válido si en ese lugar se da acceso al código fuente. Puesto que la GPL se redactó en 1991, ahora en esas referencias ha de entenderse incluida Internet, pues se ha convertido en el medio usual de distribución, aunque se encuadre legalmente en la comunicación pública. Cláusula 2.- Esta cláusula trata del derecho de transformación recogido en el artículo 21 de la LPI, que muchos estiman que es una cuestión delicada pues puede afectar al derecho moral del autor de exigir el respeto a la integridad de la obra. Se permite la transformación de la obra o parte de la misma siempre que se cumplan las tres condiciones enunciadas. En la letra del apartado 2 del artículo 21 LPI se establece la facultad del autor licenciante de imponer condiciones al autor licenciatario para poder explotar la obra derivada resultante de su actividad de transformación, y así, dice que los derechos de propiedad intelectual de la obra resultado de la transformación corresponderán al autor de esta última, sin perjuicio del derecho del autor de la obra preexistente de autorizar, durante todo el plazo de protección de sus derechos sobre ésta, la explotación de esos resultados en cualquier forma y en especial mediante su reproducción, distribución, comunicación pública o nueva transformación. Y dicha autorización nada obsta a que pueda ser condicional, lo que encaja perfectamente en el conjunto de la GPL. De las tres condiciones, la primera sirve precisamente para certificar que la transformación autorizada no entra en colisión con el derecho moral del autor, pues impone al licenciatario transformante la obligación de señalar las modificaciones introducidas, salvaguardando el buen nombre del autor, tal como se menciona en la introducción de la GPL.

86 La segunda condición cumple la misma finalidad que las cláusulas 4 y 7 ya estudiadas, y es la de preservar el sistema que permite que el software libre permanezca libre. De lo cual se aprecia que el licenciatario viene obligado civilmente a ello, como ya se dijo, y además, también por mediación de la propiedad intelectual, pues si quiere obtener el preceptivo permiso del autor licenciante para poder explotar su obra derivada, ha de cumplir con dicha condición. La tercera condición simplemente obliga a facilitar una copia de la GPL junto con el programa derivado, que no sería otra cosa que la obligación del licenciatario autor derivada de tener que licenciar su programa derivado bajo la GPL y obligación que también se mencionará en la cláusula 3. El siguiente párrafo es una salvaguarda del derecho del licenciatario autor sobre su obra si ésta es susceptible de explotación independiente, lo cual no podría ser de otra manera bajo nuestra legislación, en la que el autor, salvo en la explotación de obras derivadas, es libre de explotar su obra como mejor estime oportuno. Cláusula 3.- En esta cláusula vuelven a licenciarse los derechos de reproducción y distribución ya mencionados, pero esta vez abarca el programa en su conjunto, tanto el código objeto como el código fuente. En principio, la licencia otorgada por esta cláusula se refiere sólo al código objeto, es decir, la versión ejecutable del programa, pero luego en las condiciones de la misma se obliga a facilitar el acceso al código fuente de una de las tres formas enunciadas. Esta diferenciación se debe a que no es necesario que ambos códigos, ejecutable y fuente, sean distribuidos conjuntamente, pues se dan dos opciones de facilitar simplemente el acceso al código fuente y puede deberse a los diversos usos que se pretenden abarcar con la GPL. En la Cláusula 1 se está pensando en la distribución entre desarrolladores, a quienes lo que más les interesa es el código fuente, y en la 3 se piensa más en la distribución con usuarios finales, quienes ante todo quieren obtener un copia del ejecutable, pero a quienes no se les puede negar la libertad de acceder al código fuente si desean hacerlo. Cláusula 6.- Esta es una de las cláusulas que presenta más cuestiones al encajarla a nuestro ordenamiento, pues el artículo 50 LPI establece que el derecho del cesionario no exclusivo (o licenciatario no exclusivo) es intransmisible, con lo cual excluiría que terceros licenciatarios obtuviesen los mismos derechos que tenía el licenciatario. Dicho artículo 50 ha sido interpretado por algunos autores de la siguiente manera: No dice el artículo 50 que el cesionario puede ceder su derecho con el consentimiento expreso de su cedente, pero parece que debe entenderse así, si el cedente ostentaba derechos exclusivos. La Ley, en cambio, dice que su derecho es intransmisible, salvo los supuestos de disolución o cambio de titularidad de la empresa cesionaria. Debe comprenderse que el sinsentido es evidente: si la sucesión de empresa admite la transmisión del derecho no exclusivo, resulta difícil encontrar un razón por la que el consentimiento expreso del cedente no baste para transmitir ese derecho, que es de

87 naturaleza patrimonial. (F. Bondía y J. M. Rodríguez Tapia. Comentarios a la Ley de Propiedad Intelectual, pg. 227, ed. Civitas, Madrid 1997.) De ahí se deduce que con el permiso expreso del cedente o licenciante, el licenciatario puede, a su vez, otorgar licencias no exclusivas idénticas a la que el ostenta. Pero en la GPL aparte de otorgar expresamente dicha facultad (es una de las libertades que se quieren proteger) establece en esta cláusula que la licencia que recibe el tercero no la recibe del licenciatario, sino del licenciante original. Esto se puede interpretar, respecto de la distribución del programa, en el sentido de que con la GPL se quieren cubrir una diversidad de usos diferentes, y en este supuesto (mera distribución del programa licenciado) el licenciatario actúa como persona intermedia, como un distribuidor en la cadena de distribución que va del autor al usuario final, pues sólo se está haciendo uso de los derechos necesarios para ello (reproducción y distribución). Un programa propietario sale del fabricante y pasa por numerosas manos hasta llegar a las del usuario final. Los distribuidores de la cadena, como mínimo deben tener cedido el derecho de distribución, y dentro de la caja viene la EULA (End User License Agreement), destinada exclusivamente, como su nombre indica, a ser la licencia para el usuario final. La GPL puede interpretarse en el sentido de cumplir las dos funciones a la vez, adaptándose a la función necesaria para cada receptor de la misma. Cláusula 8.- Establece esta cláusula una protección del programa licenciado mediante la exclusión de la misma de los territorios en los que su uso puede estar restringido. Lo importante de esta cláusula es que interpretada en sentido contrario, establece que el ámbito territorial de la licencia es todos los estados del planeta. Surge ahora la cuestión de si la referencia al territorio ha de ser explícita, o puede ser tácita y deducirse de los términos de la licencia. Dos cuestiones apuntan a que se incluyen todos los países. Por un lado esta cláusula interpretada en sentido contrario, y por otro, la inclusión del derecho de puesta a disposición entre los derechos licenciados, que no se comprende sino autorizada para el mundo entero pues en Internet se puede acceder a la obra desde cualquier ordenador con conexión, independientemente del país de conexión. Cláusula 10.- Coherente con la LPI y el resto de las cláusulas, en especial la 0 y la 4, si se quiere realizar un acto de distribución no contemplado en la licencia (como distribuir bajo otra licencia) se necesita forzosamente el consentimiento de autor. Tras haber examinado ya todo el clausulado de la GPL desde el punto de vista civil y desde el punto de vista de la propiedad intelectual, sólo nos resta ver si el derecho del consumo impone algún límite a la completa validez de la GNU GPL a la luz del ordenamiento jurídico español.

88 (III) La GPL como contrato con los consumidores En este apartado, como ya se apuntó en la introducción sólo se analizarán dos cuestiones: la compatibilidad con la legislación sobre condiciones generales de la contratación y la responsabilidad del autor frente a un licenciatario consumidor. La GPL como contrato de adhesión Es un contrato de adhesión aquel en el que uno de los contratantes solo puede adherirse al contrato, o lo toma o lo deja, pero no puede negociarlo. Puesto que la GPL es uno de ellos y contiene un clausulado no negociable, es de aplicación la Ley de Condiciones Generales de la Contratación (LCGC). Los requisitos que dicha Ley exige a las cláusulas de un contrato de adhesión son que estas se ajusten a los criterios de transparencia, claridad, concreción y sencillez (artículo 5.5 LCGC), que en la GPL se respetan, pues está redactada en términos suficientemente claros y sencillos como para ser comprendidos por la persona media sin conocimientos excesivos ni en informática ni en derecho. Lo que más importa en relación a la GPL es si alguna de sus cláusulas puede reputarse de abusiva, y por tanto, nula y no tenida por puesta. Para ello la LCGC remite al artículo 10 bis y disposición adicional primera de la Ley 26/1984, de 19 de julio, General para la Defensa de los Consumidores y Usuarios (LDCU). Se define en el mencionado articulo 10 bis a las cláusulas abusivas como todas aquellas estipulaciones no negociadas individualmente que en contra de las exigencias de la buena fe causen, en perjuicio del consumidor, un desequilibrio importante de los derechos y obligaciones de las partes que se deriven del contrato. En todo caso se considerarán cláusulas abusivas los supuestos de estipulaciones que se relacionan en la disposición adicional primera de la presente Ley. En principio, las cláusulas de la GPL suponen un equilibrio entre las prestaciones de ambas partes, y de producirse un desequilibrio entre los derechos y obligaciones, este sería favorable al licenciante, pues como ya se ha dicho, no recibe nada a cambio de la licencia. Está claro que el licenciatario es quien tiene unas obligaciones que se le imponen como condiciones en la licencia, pero esa es una carga aceptable al ser las únicas que se le imponen, pues no ha de realizar ninguna contraprestación a cambio de los derechos que se le licencian. Así pues, sólo resta examinar el listado de cláusulas abusivas de la Disposición Adicional Primera de la Ley y ver alguna es aplicable en relación al clausulado de la GPL. De las 29 cláusulas que se menciona sólo una, la novena, puede ser aplicable, y dice que La exclusión o limitación de forma inadecuada de los derechos legales del consumidor por incumplimiento total o parcial o cumplimiento defectuoso del profesional. En

89 particular las cláusulas que modifiquen, en perjuicio del consumidor, las normas legales sobre vicios ocultos, salvo que se limiten a reemplazar la obligación de saneamiento por la de reparación o sustitución de la cosa objeto del contrato, siempre que no conlleve dicha reparación o sustitución gasto alguno para el consumidor y no excluyan o limiten los derechos de éste a la indemnización de los daños y perjuicios ocasionados por los vicios y al saneamiento conforme a las normas legales en el caso de que la reparación o sustitución no fueran posibles o resultasen insatisfactorias. (negrita añadida). Como se explicó al tratar la responsabilidad, la GPL no reduce el derecho del licenciatario a ser indemnizado por los daños y perjuicios, simplemente se limita la misma a la existencia de dolo por parte del licenciante, posibilidad legal como ya se razonó con anterioridad. Así pues, pese a ser condiciones generales previstas para multitud de contratos, ha de concluirse que la GPL no es contraria a la LCGC, y por tanto su clausulado es perfectamente válido. La GPL como contrato con los consumidores Siempre que el licenciatario sea usuario final del programa de ordenador, será de aplicación la LDCU, en cuyo articulo segundo figura como derecho básico la indemnización o reparación de los daños y perjuicios sufridos. En el articulo vigésimo quinto de la LDCU se establece que el consumidor y el usuario tienen derecho a ser indemnizados por los daños y perjuicios demostrados que el consumo de bienes o la utilización de productos o servicios les irroguen salvo que aquellos daños y perjuicios estén causados por su culpa exclusiva o por la de las personas de las que deba responder civilmente, lo que parece dar la impresión de que el licenciante si responde por los daños y perjuicios que el programa cause al licenciatario consumidor. En el articulo siguiente se limita dicha responsabilidad diciendo que las acciones u omisiones de quienes producen, importan, suministran o facilitan productos o servicios a los consumidores o usuarios, determinantes de daños o perjuicios a los mismos, darán lugar a la responsabilidad de aquellos, a menos que conste o se acredite que se han cumplido debidamente las exigencias y requisitos reglamentariamente establecidos y los demás cuidados y diligencias que exige la naturaleza del producto, servicio o actividad, del que se deduce que si el licenciante ha actuado con la debida diligencia que exige su actividad (programar) su responsabilidad se verá limitada. En conjunción con lo dicho anteriormente cabe concluir que el licenciante de la GPL responde en todo caso por dolo, y sólo responde por culpa (ausencia de diligencia) cuando el licenciatario sea usuario final del programa licenciado. Pero como ya se dijo antes, es difícil probar que un programador de software libre no actúa con la diligencia debida, pues lo que busca, mediante la colaboración con otros, es aportar una utilidad a la sociedad sin obtener un beneficio directo de ello, a diferencia del software propietario, cuyos desarrolladores si actúan movidos por el lucro, y ello les

90 somete a las presiones del mercado, que puedan apresurar la salida al mercado de un producto mucho más imperfecto (como suele suceder por la continúa publicación de parches que se sucede). Otro punto a tener en cuenta y que también se mencionó ya, es la inexistencia de programas de ordenador perfectos. Dada la multitud de configuraciones de hardware existentes y su evolución, es fácil que un programa presente errores e incompatibilidades diversas a lo largo de su existencia, y dichos fallos se consideran normales y son los que van provocando la aparición de nuevas versiones del programa en cuestión. Una segunda interpretación Otra interpretación que puede sostenerse es la no aplicación de la legislación sobre consumidores a la GPL, pues lo que se pretende con dicha legislación es proteger a los consumidores de los abusos de que pueden ser objeto en relación con la actividad comercial. Y como se ha visto, la GPL no se suele constituir como un acto de comercio, sino como un acto de mera liberalidad. La Ley de responsabilidad civil por los daños causados por productos defectuosos Hay algún autor que estima que la mencionada ley es de aplicación a los programas de ordenador, pero tras examinar el articulado de la misma y de la Directiva 85/374/CEE, de la que es tributaria esa Ley puede concluirse que los programas de ordenador no se encuentran incluidos por la misma, y ello por los siguientes motivos: En el tercer considerando de la Directiva se dice que la responsabilidad objetiva resulta aplicable únicamente a los bienes muebles producidos industrialmente, y en el articulo 2 de la misma, así como en el mismo artículo de la Ley, copia del de la Directiva, rubricado como concepto legal de producto se establece que a los efectos de esta Ley, se entiende por producto todo bien mueble, aun cuando se encuentre unido o incorporado a otro bien mueble o inmueble. También se considerarán productos el gas y la electricidad. (Negrita añadida). Así mismo, el considerando 10 de la Directiva dice que los productos se desgastan con el tiempo, que cada vez se elaboran normas de seguridad más estrictas y se avanza más en los conocimientos científicos y técnicos; que, por tanto, no sería razonable hacer responsable al productor del estado defectuoso de su producto por tiempo ilimitado. Un programa de ordenador no es un bien mueble, es un bien inmaterial y no se desgasta con el paso del tiempo, con lo que si lo hubieran querido incluir bastaba con un añadido similar al realizado con el gas y la electricidad, pues de hecho, el gas se incluyó por el legislador nacional, ya que no figuraba en la directiva, con lo que nada le impedía hacerlo, en el supuesto de estimar que un bien de tanta relevancia como son los programas de ordenador debiera responder por responsabilidad objetiva.

91 Conclusión Tras todo lo visto se puede concluir que la GPL es un instrumento válido en nuestro ordenamiento para la explotación de los derechos de autor sobre un programa de ordenador, que sólo necesita ser completado en cuanto a la responsabilidad del licenciante, posibilidad contemplada en el mismo texto de la GPL al hacer referencia a la ley aplicable como moduladora de tal responsabilidad Javier Aragonés. Se autoriza la reproducción, distribución y traducción de este documento por cualquier medio en los términos de los artículos 18, 19, y 21 del Real Decreto 1/1996 por el que se aprueba el Texto Refundido de la Ley de Propiedad Intelectual, así como su comunicación pública en los términos establecidos en el artículo 3 de la Directiva 2001/29/CE, siempre que se conserve este aviso y dichos actos se realicen sin ánimo de lucro.

92 LICENCIA PÚBLICA GENERAL GNU * Traducción propia únicamente de los TÉRMINOS Y CONDICIONES PARA LA COPIA, DISTRIBUCIÓN Y MODIFICACIÓN 0. Esta Licencia se aplica a cualquier programa u otra obra que contenga un aviso colocado por el titular de los derechos de autor diciendo que puede ser distribuido bajo los términos de esta Licencia Pública General. En adelante, el "Programa" se refiere a cualquier programa u obra, y "una obra basada en el Programa" significa bien el Programa o bien cualquier obra derivada del mismo bajo la legislación de propiedad intelectual: es decir, una obra que contenga el Programa o una porción del mismo, ya sea de manera literal o con modificaciones y/o traducido a otro idioma. (De aquí en adelante, la traducción se incluye sin límites en el término "modificación".) Cada propietario de una licencia es tratado como "usted". Otros actos diferentes de la copia, distribución o modificación no están amparados por esta Licencia; quedan fuera de su alcance. El acto de ejecutar el programa no se encuentra restringido, y los resultados del programa están amparados sólo si sus contenidos constituyen una obra basada en el Programa (independiente de haber sido producidos por la ejecución del Programa). La exactitud de lo anterior depende de la funcionalidad del programa. 1. Usted puede copiar y distribuir copias literales del código fuente del Programa tal y como lo recibió, por cualquier medio, asumiendo que usted publica apropiada y visiblemente en cada copia un aviso de su titularidad y una exención de garantía; mantiene intactos los avisos que se refieren a esta Licencia y a la ausencia de cualquier garantía; y da a cualquier otro receptor del Programa una copia de esta Licencia junto con el Programa. Usted puede cobrar por el acto físico de la transferencia de una copia, y puede a su elección ofrecer protección mediante garantía a cambio de un precio. 2. Usted puede modificar su copia o copias del Programa o cualquier parte de él, creando así una obra derivada del Programa, y copiar y distribuir tales modificaciones u obra bajo los términos de la cláusula 1 precedente, siempre que usted cumpla todas las condiciones siguientes: a) Debe hacer que los archivos modificados incluyan avisos destacados manifestando que usted cambió los archivos y la fecha de cualquier cambio. b) Debe hacer que cualquier obra que distribuya o publique, que en todo o en parte contenga a o sea derivada del Programa, sea licenciada en su conjunto sin coste alguno para terceras partes bajo los términos de esta licencia. c) Si el programa modificado normalmente lee comandos interactivamente al ejecutarse, usted debe procurar que cuando empiece a ejecutarse para ese uso interactivo de la forma más usual muestre un anuncio que incluya un aviso apropiado de titularidad y un aviso de que no existe garantía (o bien, diciendo que usted proporciona garantía) y que los usuarios pueden redistribuir el programa bajo estas condiciones, y diciendo al usuario como ver una copia de esta Licencia. (Excepción: si el Programa es en sí mismo interactivo pero no muestra normalmente un aviso tal como el descrito, su obra derivada del programa no está obligada a mostrar ningún aviso). Estos requisitos se aplican a la obra modificada en su conjunto. Si algunas secciones claramente identificables de esa obra no se derivan del Programa, y pueden ser razonablemente consideradas como trabajos independientes y separados en sí mismos, entonces esta Licencia y sus términos no se aplican a esas secciones cuando usted las distribuya como obras separadas. Pero cuando usted distribuya las mismas secciones como parte de un conjunto que constituye una obra derivada del Programa, la distribución de ese todo debe cumplir los términos de esta Licencia, cuyos permisos para otros licenciatarios se extienden para el conjunto en su totalidad, y por tanto, a todas y cada una de las partes con independencia de quien las haya escrito. Por tanto, no es la intención de esta cláusula reclamar derechos o cuestionar sus derechos sobre una obra escrita completamente por usted; sino que la intención es ejercer el derecho de controlar la distribución de trabajos derivados o trabajos colectivos basados en el Programa. Además, la mera adición de otra obra no basada en el Programa junto al Programa (o a una obra basada en el Programa) en un medio de almacenamiento o distribución no incluye a esa otra obra bajo el alcance de esta Licencia. 3. Usted puede copiar y distribuir el Programa (o una obra derivada de él, de acuerdo con la Sección 2) en forma de código objeto o ejecutable bajo los términos de las Secciones 1 y 2 precedentes siempre y cuando cumpla una de las siguientes condiciones: a) Acompañarlo con el correspondiente código completo en formato legible por un ordenador. Este código debe ser distribuido bajo los términos de las cláusulas 1 y 2 en un medio comúnmente usado para el intercambio de software; o bien b) Acompañarlo con una oferta escrita, válida durante al menos tres años, de dar a cualquier tercero, por un precio no superior al coste que le ocasione el acto de distribuir físicamente las fuentes, una copia completa del correspondiente código fuente en formato legible por un ordenador, que será distribuida bajo los términos de las Secciones 1 y 2 en un medio comúnmente usado para el intercambio de software; o bien c) Acompañarlo con la información que usted recibió referida a la oferta de distribuir el correspondiente código fuente. (Esta alternativa se permite sólo para distribución no comercial y sólo si usted recibió el Programa en código objeto o formato ejecutable con una oferta de este tipo, de acuerdo con la Subsección b) precedente.) Código fuente de una obra significa el formato preferido para hacerle modificaciones. Para una obra ejecutable, el código fuente completo significa todo el código fuente para todos los módulos que contiene, además de cualquier fichero de definición de interfaz asociado, además de los guiones usados para controlar la compilación e instalación del ejecutable. Sin embargo, como una excepción especial, el código fuente distribuido no necesita incluir aquello que normalmente es distribuido (ya sea en formato fuente o binario) con los componentes principales (compilador, núcleo, y demás) del sistema operativo en el que se ejecuta el ejecutable, a no ser que ese componente le acompañe. Si la distribución del ejecutable o código objeto se realizada ofreciendo acceso para copiarlo desde un lugar designado, entonces la oferta de un acceso equivalente para copiar el código fuente desde el mismo lugar se considera como distribución del código fuente, incluso aunque terceras partes no estén obligadas a copiar el código fuente junto al código objeto,

93 LA ERA PROFESIONAL A. ROMEO MOLINA. Director General de Open:service El Software Libre ha dejado de ser una cuestión de colaboración entre unos miles de voluntarios técnicos repartidos a lo largo de todo el mundo creando programas informáticos. Las comunidades de software libre han crecido, abandonando los círculos endogámicos de personas técnicas, las cuales eran las únicas que podían contribuir. La propia evolución de las comunidades nos conduce hacia una nueva era caracterizada por tener sus propias particularidades. Nuevas tendencias están comenzando a transformar radicalmente el escenario en el cual el software libre se ha ido desarrollando durante los últimos años. Una nueva era se acerca en la cual el paradigma tecnológico es totalmente diferente, donde los componentes de las comunidades se encuentran formadas por todo tipo de agentes: organismos públicos, empresas, instuciones educativas, ciudadanos, etc. que conducen hacia nuevos desafíos que las comunidades del software libre deben resolver cuanto antes. Estos desafíos habrán de ser superados si se quiere que esta nueva fase en la que se encuentra el software libre, coseche los mismos éxitos de implantación y difusión que las primeras comunidades consiguieron. La relación entre la comunidad y las empresas multinacionales; el incremento de colaboración entre diferentes proyectos de software libre; la expansión del conocimiento del nuevo paradigma tecnológico, así como la colaboración entre organismos públicos, son algunos desafíos a los que las Comunidad del Software Libre se enfrenta. COMUNIDADES DEL SOFTWARE LIBRE, LIBERACIÓN DE APLICACIONES, COMUNIDADES, COLABORACIÓN

94 1. QUÉ ESTÁ OCURRIENDO? El nuevo paradigma tecnológico comienza a ser entendido por parte de diferentes empresas e instituciones. La industria informática ha cambiado radicalmente y ya no es la misma que hace cinco años. Gracias a la aparición de tecnologías libres cualquier organismo, empresa o ciudadano puede hacer uso de las mismas bajo un paradigma totalmente diferente al que se conocía. La libertad, unida a la estabilidad y seguridad que proporcionan las mismas, ha hecho que la industria haya cambiado para siempre. Gracias al empuje de la comunidad del software libre, el conocimiento se ha expandido entre todas las capas de la sociedad. La colaboración formará parte de los procesos de creaciones e innovaciones tecnológicas como nunca se ha hecho. Estas son algunas de las razones por las cuales se ha producido la liberación de muchas aplicaciones, antaño propietarias. Pero estas liberaciones no provienen sólo por empresas de software, sino que también provienen de todo tipo de organizaciones públicas y privadas. Por su parte, las empresas de software propietario, empujados por las iniciativas que la comunidad del software libre ha realizado durante los últimos años, se ha visto obligada por una parte a incrementar la seguridad de sus productos así como a la rebaja de sus costes de propiedad en muchas de sus líneas de negocio. EXPANSION DEL CONOCIMIENTO SOBRE EL SOFTWARE LIBRE El conocimiento del software libre y sus implicaciones tecnológicas se ha expandido en los últimos años. Tanto la Adminstración como las grandes empresas han comenzando a entender el cambio en el paradigma tecnológico que trae el software libre. Software

95 Libre es compartir y colaborar. Con una base tecnológica libre como la que se tiene actualmente, por que volver a reinventar la rueda? Razones de eficiencia y sociales se imponen. LIBERACIÓN DE APLICACIONES La liberación de aplicaciones i (ROMEO, GARCÍA, 2003) florece y diferentes áreas son objeto de atención por parte de empresas, que ven en la liberación de sus aplicaciones, un atajo hacia un modelo de negocio exitoso. Pero esto no está ocurriendo sólo entre las empresas que contaban con software propietario sino que está comenzando a verse entre la administración, como una excelente manera de proveer a los funcionarios públicos con herramientas flexibles y altamente productivas de una manera libre. Esta es quizás una de las grandes consecuencias que el software libre ha traído a la informática que conocemos. Diferentes aplicaciones están siendo liberadas cambiando radicalmente el panorama existente en la industria informática. Empresas de Software Propietario Las propias caracteristicas de la comunidad, no han hecho posible la creación de proyectos en determinados segmentos. Por su parte, la existencia de aplicaciones propietarias ha sido totalmente opuesta, habiendo grandes competencias en determinados mercados, donde la presencia de aplicaciones es significativa. Esta es la razón del porqué las empresas de software propietario, que tienen menos capacidad de penetración, se planteen la liberación de una aplicación. En La Pastilla Roja tuvimos la oportunidad de reflejar las razones por las cuales una empresa decidía liberar una aplicación.

96 Mercados altamente competitivos como el segmento de las aplicaciones horizontales, y en menor medida, el de determinadas aplicaciones verticales, verán la aparición de aplicaciones libres en los próximos años. La liberación del código de OpenOffice.org en el año 2000 por parte de Sun Microsystems y la publicación de la versión 1.0 en mayo de 2002 y de OpenOffice.org 1.1 (diciembre) ii, constituyen un auténtico punto de inflexión en la historia del software libre. Aunque fue Netscape la primera empresa de software propietario en apostar claramente por los modelos de desarrollo en bazar al liberar el código de su navegador Communicator y lanzar el proyecto Mozilla iii, podemos decir que el primer hito importante en la historia se produce mediante la liberación de la suite ofimática OpenOffice.org. Este es el caso también del servidor de groupware Skyrix, cuya empresas propietaria anunciaba el 10 de julio de 2003 la liberación de código fuente. El software OGo se basa en la contribución de código de SkyriX 4.1 Groupware Server, un producto con más de 7 años en el mercado iv. En España, encontramos un caso recientemente como es el de la empresa extremeña PuntoDev la cual mantenía un paquete de facturación y contabilidad propietario cuyo mercado era estrictamente local. Gracias a la consultoría de Vivernet, PuntoDev decidió liberar sus aplicaciones y en la actualidad, su mercado se ha visto multiplicado ṿ Iniciativas PYMEs ( de la Comunidad ) Otro tipo de liberaciones son las producidas por iniciativas de PYMEs que desarrollan aplicaciones desde cero para luego liberarlas posteriormente. Los últimos 12 meses y fruto del empuje del Software Libre en toda España, han surgido diferentes iniciativas

97 de desarrollos libres mayoritariamente en gestión comercial destinados a PYMEs así como en Gestión de Contenidos, llevados a cabo por pequeñas empresas y fruto de desarrollos proios. Entre ellas encontramos a Facturalux, BulmaGes, Fisterra, GestiONG, PuntoDev o Ferret, las cuales han sido promovidas por organizaciones altamente involucrados en la Comunidad como Vivernet, Bulma, Igalia, Santiago Torres u OpenSistemas Otras Organizaciones Liberando La existencia de enormes desarrollos en las Administraciones Públicas ha sido un punto donde los defensores del software libre han hecho hicanpié. Las posibilidades de reutilización del código para su uso por parte de organismos públicos es una de las mayores ventajas que el software libre tiene, ya que reduce enormemente el tiempo dedicado en desarrollo inútil para poder concentrar los recursos en la mejora y evolucion de los mismos. El acuerdo firmado por los presidentes de la Junta de Andalucía y la Junta de Extremadura en abril de 2003, muestra a las claras hacia donde se está evolucionando vi. Uno de los puntos del acuerdo reza de la siguiente manera: QUINTO.- Que ambas Administraciones coolaborarán en el desarrollo de nuevas aplicaciones, que mantendrán bajo licencia GPL (GNU Public License), y en las actividades de difusión y soporte de Software Libre a los ciudadanos de ambas Comunidades Autónomas. 2.CARACTERÍSTICAS DE LA ERA PROFESIONAL Estas actuaciones se circunscriben en la que denominamos era profesional la cual

98 peresenta particularidades diferentes y específicas que anteriormente no se encontraron en la génesis de las tecnologías libres. Desde el liderazgo profesional por parte de multinacionales del sector informático, organismos públicos, organizaciones semipúblicas, asi como fundaciones privadas, pasando por la construcción de nuevas relaciones económicas entre los diferentes agentes de la comunidad, la era profesional presenta una serie de características intrínsecas a este periodo. LIDERAZGO PROFESIONAL La nueva era trae que muchas de las iniciativas libres vengan respaldadas por empresas multinacionales de tecnología. Éstas ven en el software libre, una de las áreas de negocio con más futuro, debido a las propias dinámicas libres que las mismas presentan. Este es el ejemplo de la empresa estadounidense Novell. Novell ha comprado Ximian vii (AGOSTO 2003) y SuSE viii (NOVIEMBRE 2003), dos de las empresas de desarrollo de software libre más importantes y que más contribuyen a la comunidad con sus tecnologías libres. Por su parte, Sun continúa tomando posiciones en el software libre. Su plataforma Java Desktop System basada en GNU/Linux será implantada en millones de equipos en China ix, así como en el Reino Unido x. Por otra parte, no sólo las empresas mantendrán el liderazgo en aplicaciones exitosas, como las que comentábamos anteriormente. En la era profesional, diferentes organizaciones públicas y privadas llevan a cabo iniciativas relacionadas con el Software Libre. Vivernet, Open Source Application Foundations o Fundación Gnome, son algunos de los ejemplos. Vivernet (Viveros de Emprendedores en la Nueva Era) es

99 la medida de la Consejería de Educación, Ciencia y Tecnología de la Junta de Extremadura, destinada a facilitar el desarrollo de nuevos negocios en el ámbito de la Sociedad de la Información mediante la puesta a disposición, de los jóvenes emprendedores con capacidad creativa, los recursos que les permitan desarrollar sus actividades. Dentro de estas iniciativas, Vivernet está impulsando la utilización de las tecnologías libres entre todas las PYMEs. Para ello está preparando la primera metadistribución destinada íntegramente a las PYMEs, que incluirán un paquete ofimático, de gestión comercial, gestión administrativa, entre otras aplicaciones xi (ROMEO 2003).Por otra parte, organizaciones como la Open Source Application Foundations, sustentada por Mitch Kapor (creador de Lotus) incumba diferentes proyectos de software libre. Chandler, revolucionario proyecto de gestión de información personal, es su proyecto más importante xii (GILMOR). CONSOLIDACIÓN DE DETERMINADAS APLICACIONES La aparición de la era profesional, tiene como efecto la consolidación de las mejores aplicaciones libres que se tengan, sobre todo en el ambiente del escritorio. Cuando se ha de competir con las empresas de software propietario y con los recursos con los que cuentan, la comunidad del software libre, se ve obligado a promover determinadas alternativas frente a las propietarias. Ésto implica que aquellas iniciativas que no estén en la vanguardia de la tecnología, no lograrán atraer suficientes miembros a la comunidad de desarrollo tan necesaria para su implantacion. En la iniciativa UserLinux propuesta por Bruce Perens xiii (PERENS, 2003), podemos

100 observar cómo la elección de Gnome y OpenOffice.org sobre KDE o Abi, han resultado en un profundo debate en la comunidad del software libre. En caso de resultar exitosa la iniciativa UserLinux, hará que aquellas tecnologías no elegidas, verán mermadas sus posibilidades de crecimiento en gran medida. NUEVAS RELACIONES ECONÓMICAS Nuevas formas de relaciones económicas se imponen entre los diferentes miembros de la Comunidad. Cuando el software libre continúa con su penetración entre las diferentes partes de la sociedad, relaciones económicas comienzan a emerger. Este es el caso de las relaciones entre las empresas de software libre que trabajan en la comunidad y el de las empresas de IT que ven en el software libre, una interesante nueva línea de negocio que se abre. Otro de los ejemplos de las nuevas relacionaes económicas que se crean en la comunidad, son los Gnome Bouties (Recompensas Gnome) establecidos por parte de la Fundación Gnome xiv (2003). En aras de conseguir una mayor integración entre los diferentes componentes que componen este escritorio gráfico y las aplicaciones que corren sobre él, la Fudación Gnome publicaba el mes de noviembre de 2003 recompensas para todos aquellos desarrolladores que completaran determinadas tareas que se tenían pendientes desde hacía tiempo. De esta manera, se han introducido por primera vez, incentivos económicos de los que se tengan constancia, para el desarrollo de tareas específicas en la comunidad del software libre. Siguiendo los pasos dados por la Fundación Gnome, la Fundación Shuttelworth ha ofrecido $ xv (NOVIEMBRE

101 2003) para la realización de diferentes tareas en Python, entre otras tecnologías libres 3.DESAFÍOS A SUPERAR EN LA ERA PROFESIONAL Sin embargo, la era profesional debe superar diferentes desafíos que se les presentan que no son baladíes. Desde la relación entre las grandes empresas y la comunidad, pasando por la necesidad de una estandarización de procesos informáticos,o bien la expansión del conocimiento sobre el cambio en el paradigma tecnológico, la comunidad del software libre tiene ante sí unos retos importantes para los próximos cinco años. RELACIÓN ENTRE LAS GRANDES EMPRESAS Y LA COMUNIDAD. Uno de los principales desafíos a los que se tendrá que enfrentar la comunidades de tecnologías libres, será las relaciones entre las grandes empresas y los diferentes agentes que componen la comunidad: organismos públicos, empresas, instituciones educativas, ciudadanos, etc. Las grandes empresas tendrán que invertir en la construcción de comunidades y para conseguir las dinámicas del software libre, necesitan de un tippin' point (punto de inflexión) que les permitan aprovechar el trabajo colaborativo. Sin embargo la existencia de una multinacional no siempre es positiva desde el punto de vista de algunos miembros de la comunidad. Una de las razones para este hecho son las suspicacias que la misma levanta. No es fácil conjugar los intereses de todas las partes envueltas y no siempre las relaciones son

102 fáciles. Proyectos como OpenOffice.org (respaldado por Sun) o Helix (respaldado por Real Networks) no tienen las mismas facilidades costando tiempo y esfuerzo la construcción de una comunidad. Éste hecho se ve refrendado con el anuncio por parte de America Online de desentenderse de proyectos como Netscape, de los cuales nacieron comunidades como Mozilla. COLABORACIÓN ENTRE INICIATIVAS Otro de los grandes desafíos a los que se enfrenta el software libre, es el de la interoperabilidad y estandarización de procesos. Empresas como Microsoft llevan buscando durante años la máxima estandarización e interoperabilidad de sus aplicaciones entre sí. Por otro lado, gran parte del desarrollo por parte de la Comunidad del Software Libre se ha centrado en el desarrollo de aplicaciones no existentes en plataformas libres, como GNU/Linux, por lo que no ha dedicado tantos recursos como los necesarios a temas de interoperabilidad y estandarización de procesos. Era más necesario ofrecer aplicaciones libres y altenativas, que invertir tiempo en la interoperabilidad entre ellas. Sin embargo, el software libre no tiene mucho tiempo. Las iniciativas de Microsoft marchan rápidas y contundentes en todos los campos en los que trabajan. La estandarización de formatos, protocolos y procesos en los que están sumergidos pueden suponer la total dominanción de la infraestructura más básica informática de las organizaciones, y eso, puede significar perder la guerra. Project Green es el nombre de uno de los últimos proyectos de Microsoft tendentes a la interoperabilidad de muchas de

103 sus aplicaciones existentes en el ámbito del software de gestión xvi (GILBERT, 2003). Este hecho confirma mucho de lo apuntado por Andrew Grygus en su famoso Beyond 2003 xvii (GRYGUS 2003) al cual ya nos hemos referido en diferentes ocasiones xviii. Los planes de Microsoft de estandarización de facto del máximo de sus formatos en las áreas donde compiten. Gracias a esta estandarización, los costes de migración hacia plataformas libres serán mucho más costosas, ya que la tecnología propietaria estará mucho más "apegada". El Gestión Libre de Hispalinux es un ejemplo de este hecho. La lista de correo que prometía ser el inicio de una futura aplicación comercial libre, con el paso del tiempo ha ido decayendo. En España hemos visto durante los últimos 12 meses, la aparición de determinados proyectos como Facturalux, GestiONG, Fisterra, BulmaGes, y la más reciente de PuntoDev, que han mostrado cómo el hacer y no hablar se impone en el software libre..."release early, release often"... EXPANSIÓN DEL CONOCIMIENTO EN EL PARADIGMA TECNOLÓGICO Hemos hablado sobre cómo la expansión del conocimiento sobre el software libre ha sido decisivo en los últimos años para la penetración del tecnologías como Linux, OpenOffice.org, etc. Sin embargo esta expansión ha de continuar. El concepto del software libre, se estanca en muchas ocasiones en la gratuidad del mismo y en los quebraderos de cabeza de los interlocutores en entender cómo se gana dinero en el software libre. No se hace hincapié en el cambio en el paradigma tecnológico, que constituyen las nuevas formas de colabroación que una sociedad en red ofrece. Crear conciencia que un grupo de miles de desarrolladores ofrece soporte sobre una tecnología

104 como Linux se hace imperativo en la era en la que nos encontramos, si se pretende que el software libre continúe con su expansión en nuevas áreas. COLABORACIÓN ENTRE ORGANISMOS PÚBLICOS La implantación de software libre en los organismos públicos no sólo trae como consecuencia el cumplimiento de la ley, ni los grandes ahorros de costes por la libertad y gratuidad del mismo. La mayor consecuencia es la racionalización de los costes de desarrollo dependientes de las administraciones públicas así como el poder distribuir esas herramientas entre el resto de la sociedad. El desafío se presenta ante las actuales 4. Y PARA TERMINAR...UNA PROPUESTA Las iniciativas a las que nos referíamos anteriormente son sólo el primer paso para lograr que el software lirbe se expanda en ámbitos como el de la gestión comercial; todas ellas son bastante interesantes de por sí, pero se quedarán en eso, en iniciativas locales y sin mucho mayor poder de penetración, si entre las mismas no se colabora. Las dinámicas y bondades del Software Libre emergen cuando se colabora entre las organizaciones y los diferentes proyectos. Francisco de Urquijo, consultor de software libre, lo tiene bastante claro: estandarización de procesos antes de que las empresas de software propietario consigan imponer sus estándares de facto. Juantomas García, presidente de Hispalinux, ha propuesto la unificación en torno a un mismo proyecto de todos los responsables de proyectos de gestión en el ámbito

105 hispanoamericano. Desarrollando la propuesta de Juantomas, la creación de un comité de estandarización de procesos se antoja prioritaria. Este comité podría estar formado por parte de los responsables de Comunidad de cada una de las aplicaciones liberadas comerciales que quisieran participar en un comité tendente a la estandarización de los procesos. Este comité estaría formado por parte de un Consejo de Asesores entre los que se podría encontrar líderes de la Comunidad, Administración Pública, Responsables de Tecnologia de Asociaciones Empresariales, etc. que permitiera unificar criterios a nivel nacional sobre los procesos de administración. A este comité se irían incorporando poco a poco las empresas que fueran liberando para poder participar de las mismas, así como cualquier otra organización interesada en participar en la misma. Empresas de software propietario estarían especialmente invitadas a unirse al proyecto de estandarización, ya que las mismas se verían también favorecidas de un mercado donde se compitiera en servicios. En un futuro, podrían articularse comités por cada uno de las grandes áreas que necesitan de una estandarización. La comunidad del software libre ha entrado en la era profesional donde nuevas características trazan el futuro sobre el cual las tecnologías libres continuarán avanzando. Diferentes desafíos tendrán que ser superados por parte de los diferentes agentes de la Comunidad del Software Libre si se quiere que la penetración de las tecnologías libres, continúe con la penetración exponencial que ha venido manteniendo en los ultimos años. En las manos de la comunidad se encuentra su futuro.

106 i ROMEO, ALFREDO; GARCÍA, JUANTOMAS. La Pastilla Roja. Software Libre y Revolución Digital. Madrid ii OpenOffice.org Press Rease 1.1. NOTA DE PRENSA. 1 de octubre de Disponible en Internet: iii Netscape Plans to Make Next Generation Communicator Source Code Available Free on the Internet. Nota de Prensa. 21 de enero de Disponible en Internet. iv Liberación de Groupware completo por SkyriX. NOTA DE PRENSA. 10 de julio de Disponible en Internet: v Vivernet presenta ContaLinex y FacturLinex, en el marco del VII Encuentro de Emprendedores y Empresarios. Vivernet. 23 de octubre de Disponible en Internet: vi Protocolo general entre las comunidades autónomas de Extremadura y Andalucía sobre colaboración en materia de uso y difusión de software libre y de Linex en particular.11 de abril de Mérida. Disponible en Internet: vii Novell Acquires Ximian to Expand Linux Solutions and Open Source Commitment. NOTA DE PRENSA. 4 de agosto de Disponible en Internet: viiinovell announces agreement to acquire Leading Enterprise Linux Technology Company. SUSE Linux. NOTA DE PRENSA. 4 de noviembre de Disponible en Internet: ix Chinese deal could be biggest Linux rollout yet. MCMILLAN, ROBERT. Internet Week. 18 de noviembre de Disponible en Internet: x Sun Lights Up U.K. Servers, Desktops. SINGER, MICHAEL. Internet News. 8 de diciembre de Disponible en Internet. xi Software Libre e Innovación. ROMEO, ALFREDO. Baquia. 30 de octubre de Disponible en Internet: xii Reinventing Your Inbox. Mitch Kapor brings open source to the masses.gilmor, DAN. Wired Magazine. Noviembre Disponible en Internet: xiiion the GUI Selection in UserLInux. PERENS, BRUCE. 15 Diciembre Disponible en Internet: xivdesktop Integration Bounty Hunt. Gnome Foundation. Disponible en Internet: xv Claim your Bounty. Shuttelworth Foundation. Disponible en Internet: xvimicrosoft lays out 'Project Green' revamp. GILBERT, ALOIRE. 7 de octubre de Disponible en Internet: xvii2003 and Beyond. GRYGUS, ANDREW. Aaxnet. 23 de febrero Disponible en internet: xviiicolaborar o Morir. ROMEO, ALFREDO. Diariored.com. 21 de diciembre de Disponible en Internet:

107 EHAS: programas libres para apoyar el sistema de salud en zonas aisladas de América Latina. Joaquín Seoane Pascual Arnau Sánchez Sala Andrés Martínez Fernández 4 de febrero de 2004 Valentín Villaroel Ortega Alberto Sáez Torres Resumen El Programa Enlace Hispano Americano de Salud (EHAS 1 ) pretende contribuir a la mejora del sistema público de asistencia sanitaria en zonas rurales aisladas de países de América Latina, por medio de las telecomunicaciones y la informática. Para ello propone a puestos y centros de salud soluciones de conectividad de bajo coste aptas para zonas donde no haya teléfono ni eléctricidad, así como servicios adaptados a ellas, que faciliten la capacitación a distancia, las consultas remotas, el pedido de medicamentos, la vigilancia epidemiológica, etc. Estas soluciones utilizan y desarrollan software libre allá donde las condiciones lo permiten y que cada vez son más favorables. 1. Introducción Aunque hay razones poderosas para utilizar y desarrollar software libre en países en desarrollo y, en particular, en proyectos de desarrollo, la realidad indica que su aplicación es aún limitada. Como en todas partes, su introducción empieza allá donde su uso es, sin posibilidad de discusión, la mejor solución técnica y económica. Este es el caso de las soluciones que desarrolla el programa Enlace Hispano Americano de Salud (EHAS), que partiendo del estudio de necesidades del personal sanitario en regiones aisladas de Perú, Nicaragua, y posteriormente de Colombia, Cuba y México, llegó a la conclusión de que con telecomunicaciones de bajo costo se podrían paliar algunos de sus problemas, como su aislamiento personal y profesional, pudiendo facilitar las consultas profesionales, la formación, el intercambio de informes, la coordinación de emergencias, el pedido de medicamentos. Para demostrarlo, entre los años 2000 a 2002 se puso en marcha un proyecto piloto en la provincia de Alto Amazonas del departamento de Loreto en Perú, con objeto de demostrar una solución de bajo coste y evaluar su impacto. Dicho proyecto involucra al Hospital Provincial de la capital, Yurimaguas, y a 40 establecimientos de salud de dos categorías: centros de salud y puestos de salud. Los centros de salud están dotados de varias personas, al menos una de ellas médico, y suelen tener teléfono y grupo electrógeno funcionando algunas horas al día. Los puestos de salud dependen de los anteriores y sólo cuentan con una persona de formación limitada y carecen de teléfono y cualquier fuente de energía, lo que hace necesaria alimentación solar. Los desplazamientos se hacen por río y, en algunos casos peden necesitarse varios días para moverse de un puesto de salud a su centro de referencia

108 La evaluación de este proyecto sugiere que además de mejorar la calidad de la asistencia sanitaria, los costes de infraestructura se amortizan en poco tiempo [4, 3]. La experiencia obtenida y la evolución de la tecnología han dado pie para definir otros nuevos en distintos escenarios, unos realizados y otros en fase de diseño e implantación. Por ejemplo, en la provincia del Cauca, en Colombia, se enlaza la capital de la provincia, Popayan, con dos hospitales rurales en zona indígena guambiana de Silvia[1], y éstos con sus puestos de salud. En fase de diseño e implantación hay extensiones de los proyectos de Loreto y Guambia y acciones nuevas en el Cuzco peruano, la costa pacífica del Cauca y la provincia de Guantánamo en Cuba. El programa EHAS está liderado por el Grupo de Bioingeniería y Telemedicina de la Universidad Politécnica de Madrid, en su vertiente de investigación y desarrollo, y por la Asociación Madrileña de Ingeniería Sin Fronteras, en su vertiente de realización de proyectos de cooperación. Esta colaboración entre Universidad y ONG ha dado lugar a la Fundación EHAS, que será la que desarrolle el programa a partir de ahora. Cuenta con la participación de universidades e instituciones públicas en Perú, Colombia y Cuba, y es apoyado financieramente por los programas de investigación de los países participantes (Plan Nacional de I+D+I del MCyT español, Colciencias, el Concytec peruano) y programas de cooperación ordinaria (AECI, ayuntamientos, autonomías) o con una inclinación más científica o tecnológica (CYTED, Banco Mundial, Colegios profesionales, Comité de Cooperación y Solidaridad de la Universidad Politécnica de Madrid, programa ALIS de la Comunidad Europea). A continuación se describiremos brevemente las tecnologías utilizadas y en fase de desarrollo, haciendo hincapié en el software libre empleado, modificado o construido. 2. Redes de voz y datos Como las evaluaciones han demostrado, el principal servicio necesario y que claramente salva vidas es la simple comunicación de voz en el ámbito más local, siendo la comunicación de datos un complemento valioso, pero siempre secundario. Es por ello que la mayoría de las soluciones propuestas resuelven el problema de voz, sobre el que superponen un sistema de datos con bajo coste adicional Microrredes VHF En zonas como los llanos selváticos de Alto Amazonas o los valles de Guambia, con establecimientos separados decenas de kilómetros, sin teléfono, la infraestructura más sencilla y usada para comunicar los puestos de salud con su centro de salud es la radio VHF, ya que su alcance puede ser del orden de 40 Km, limitado por la curvatura de la tierra y los obstáculos importantes (entre los que se encuentran los árboles). Se eligen pues en estos casos radios VHF convencionales que se utilizan normalmente para voz, pero que, intermitentemente, pasan a intercambiar datos entre un ordenador cliente en el puesto de salud y un servidor situado en su centro de salud de referencia. El servidor a su vez se comunica intermitentemente con internet a través del teléfono o, en algunos casos, a través de un terminal VSAT Redes HF En zonas muy aisladas, VHF no se puede utilizar. En estos casos puede utilizarse HF (onda corta) por reflexión ionosférica, salvándose distancias de centenares o miles de kilómetros. Lamentablemente HF es de muy escasa calidad y sólo puede usarse a ciertas horas, dependiendo del canal, y con protocolos y modulaciones especiales. No obstante el funcionamiento de estas redes es muy similar 2

109 a las de VHF, aunque con un radio mucho mayor, y con un servidor permanentemente alimentado y conectado a internet Redes VSAT Otra solución explorada para zonas muy aisladas ha sido la utilización de satélites de baja órbita (LEO). Estos satélites no son geoestacionarios, pero pueden utilizarse cuando pasan por encima de un punto para intercambiar ficheros con muy baja energía. Pero no pueden utilizarse para voz, dependen de microsatélites compartidos de vida incierta y de equipos terrestres de cierta complejidad, por lo que se ha abandonado en favor de las redes HF. Ciertamente podría usarse la moderna telefonía satelital en la mayoría de los lugares, pero los costes actuales siguen excesivos, por lo que los enlaces satelitales geoestacionarios sólo se usan para concentrar comunicaciones que se distribuyen luego por enlaces terrestres Redes apoyadas en móvilidad física La idea de utilización de satélites LEO es extensible a cualquier tipo de móviles, ya sean satélites, autobuses, barcos, caballerías o personas[5, 7]. La opción más simple pero de más capacidad es el transporte físico de unidades de almacenamiento masivo, como CD o DVD, y esta posibilidad se ha adoptado en EHAS como complemento para el transporte de gran cantidad de información cuando los enlaces físicos no lo soportan, si bien en un sólo sentido Redes WiFi La extensión de las redes locales inalámbricas en microondas (actualmente IEEE b) a distancias relativamente grandes ha supuesto una revolución que por supuesto no desaprovechamos. A pesar de no haber sido expresamente diseñadas para ello, su regulación liberal y su conscuente bajo coste hacen de ellas una solución que ya ha sido aprovechada (enlaces entre Popayán y dos hospitales rurales a más de 40 Km). El ancho de banda mucho mayor que las soluciones anteriores abre el camino a aplicaciones muy diferentes. Sin embargo también plantea problemas, siendo el más importante el que ahora la voz depende de una red de datos sin soporte para calidad de servicio, por lo que ni siquiera está garantizado poder mantener una conversación. Otro inconveniente es la necesidad de que no haya obstáculo alguno entre los puntos a comunicar, algo muy caro de conseguir en selva, por ejemplo. Por ello se está explorando la posibilidad de construir redes ad-hoc con cierto soporte de calidad de servicio, construidas con encaminadores autónomos basados en Linux y alimentados con energía solar. Estas redes permitirían construir corredores inalámbricos en valles y cuencas fluviales. 3. Aplicaciones basadas en correo electrónico Excepto en el caso de las redes inalámbricas en microondas, vemos que las soluciones propuestas se basan en conexiones intermitentes de bajo ancho de banda y utilizando medios diversos. Por ello todas las aplicaciones contempladas, que dan valor añadido a la red de comunicaciones, se construyen para poder funcionar través de correo electrónico, ya sea interpersonal, ya entre programas. Así los mensajes pueden atravesar distintos medios (radio VHF o HF, conexiones telefónicas a veces de mala calidad, o almacén intermedio en satélites LEO o un CD) sin problemas. Sin embargo, si se dispone de una conexión de velocidad aceptable para el funcionamiento interactivo, se utilizará. 3

110 Esta diversidad de soportes y transportes requiere gran independencia entre la información que se maneja y la forma en que se trata, por lo que es preciso definirla de forma suficientemente abstracta. Es por ello que se utiliza extensivamente la tecnología XML, ya sea para definir el contenido de un informe epidemiológico como para describir el contenido de un curso de formación a distancia. En particular, para formación a distancia se está trabajando en un conjunto de herramientas para definir, editar y manipular material educativo utilizable por estudiantes conectados sólo por correo electrónico 2, así como en una plataforma visual de teleeducación activada por eventos de correo. 4. AX.25 y redes de banda estrecha Para comunicar vía radio clientes y servidores, tanto en VHF como en HF, se utiliza el protocolo AX.25[2], una adaptación de X.25 realizada por radioaficionados, implementada parcialmente en Linux y, de forma cerrada, en Windows. En Alto Amazonas y el Cauca se implementó una red mixta (estaciones Windows y servidores Linux) TCP sobre AX.25 Como las aplicaciones de correo para Windows utilizan protocolos POP y SMTP directamente, fué preciso implementar estos servicios de alguna manera sobre AX.25. En general, sea cual sea la plataforma, parece ser buena idea implementar protocolos de aplicación estándar de Internet, ya que de ese modo todos los programas diseñados para internet funcionarán directamente. Sin embargo, esto ocasiona dificultades e ineficiencias, debido al desconocimiento por parte de TCP de un medio semiduplex de elevadas tasa de error, latencia y probabilidad de colisión, lo que ocasiona repeticiones innecesarias de paquetes y detecciones falsas de congestión. Está claro que hay que impedir que TCP intervenga como protocolo de transporte y delegar la responsabilidad de gestión del enlace en AX.25, mucho mejor adaptado para ello Tunelado de protocolos de internet sobre AX.25 Una posibilidad de empleada con éxito en Alto Amazonas es engañar a las aplicaciones, haciéndolas hablar con sendos proxis locales de SMTP, POP o lo que sea necesario. Las conversaciones con esos proxis se trasladan al servidor por medio de AX.25, donde escuchan sus proxis complementarios, que trasladan la conversación a los servidores. Para multiplexar las distintas conversaciones de aplicación se utiliza SSH, lo que resuelve de una vez tres problemas: la multiplexación, el uso eficiente del escaso ancho de banda disponible, y la protección de información que puede ser confidencial Uucp sobre AX.25 No obstante, y a pesar de la eficiencia lograda con un túnel SSH, los protocolos de aplicación de internet no son del todo apropiados para una red poco fiable y de escaso ancho de banda. Tradicionalmente se ha usado uucp para intercambiar correo en enlaces de mala calidad, y como nuestras aplicaciones están basadas en correo, parece una opción natural optimizar éste. La venerable versión de Ian L. Taylor soporta diversos protocolos para distintos tipos de conexiones, incluidas semiduplex, permite reanudar transferencias abortadas, y es bastante eficiente. Ya se utilizó en Alto Amazonas Sobre TCP. 4

111 para intercambiar correo entre los centros de salud y el conmutador central, y ahora se utiliza sobre AX.25 para transferir lotes comprimidos con bsmtp. Este cambio de timón ha supesto también el abandono de implementaciones AX.25 sobre Windows. La flexibilidad de tener fuentes abiertos para resolver este y otros problemas compensa el intentar vencer las resistencias de los usuarios a usar una plataforma libre. Y si no se puede, lo que sí se puede es trasladar toda la lógica de comunicaciones a un procesador de comunicaciones de bajo costo basado en Linux y conectado a otro ordenador por medio de una conexión ethernet Modulación software Con radios comerciales de voz VHF, canalizadas a 25 KHz, se consiguen fácilmente 9600 bps, pudiéndose doblar la velocidad o reducir a la mitad la canalización si las radios y los modems son de buena calidad. Aunque se han utilizado modems externos, por razones de coste, flexibilidad y fiabilidad se ha optado por utilizar tarjetas de sonido, usando el procesador central como procesador de señal. Eso nos permite además optimizar las modulaciones. Para ello se ha utilizado directamente el paquete soundmodem de Thomas Sailer[6]. Con radios comerciales de voz HF, canalizadas a 3 KHz, y sometidas a fuertes interferencias y desvanecimientos, pueden utilizarse modems de HF muy caros o muy lentos (100 a 300 bps). Esto hizo necesario trabajar más en profundidad la modulación. Por ello se modificó profundamente un modem (newqpsk) añadido por Tomi Manninen a soundmodem. Dicho modem, usa 15 portadoras moduladas en DQPSK, entrelazado de bits para luchar contra los errores de ráfagas, y códigos autocorrectores. En él se sustituyó el código autocorrector por turbocódigos convolucionales, consiguéndose alcanzar velocidades entre 1000 y 2000 bps, según la calidad del canal. Además los espacios entre portadoras nos permiten intercalar canales de chat, muy convenientes cuando la calidad de la voz es muy mala Modificaciones de AX.25 Los clientes y el servidor de una red VHF o HF compiten por la única frecuencia disponible, que usan tanto en transmisión como recepción. Para controlar el acceso al medio, en el entorno de radioaficionado se utiliza normalmente CSMA-CA: un cliente escucha si alguien está hablando y, si es así, se espera un tiempo seudoaleatorio para intentarlo de nuevo, tanto más largo cuantas más veces se haya detectado portadora. La probabilidad de colisión y destrucción de paquetes puede ser muy grande debido a que el tiempo de conmutación entre transmisión y recepción es considerable. Y en radio no es posible detectar la colisión pronto y anular la transmisión, como se hace en ethernet. Este es el único modo implementado en Linux, ya que suele ser el único interesante para los radioaficionados, que quieren hablar todos con todos. Además exige que todas las estaciones se escuchen entre sí, lo que implica mástiles más altos para que las antenas, generalmente omnidireccionales, se vean todas entre sí. Esto es costoso y exige potencia suficiente en las radios para llegar a todos los puntos. Sin embargo en nuestra aplicación sólo hay comunicación cliente servidor. Una solución es la implementación, al mismo nivel de AX.25, de un protocolo de control de acceso múltiple asignado bajo demanda. Dicho protocolo permite al servidor la asignación de turnos a los clientes que simulatáneamente han establecido una conexión. El protocolo se ha implementado en el núcleo de Linux de forma que funcione correctamente con interlocutores que desconozcan que se está utilizando este método de control de acceso, haciéndoles creer que el servidor está ocupado durante la rodaja de tiempo que no les corresponde. Ello fué necesario porque, de nuevo, el carácter cerrado de la implementación de AX.25 en Windows impedía cualquier modificación. 5

112 Otra modificación importante fué la retransmisión selectiva en AX.25. La modificación introducida no es compatible con el estándar, ya que permite enumerar exactamente qué paquetes se han recibido mal para sólo retransmitir esos, algo muy necesario en un entorno tan sensible a errores. 5. Estación EHAS Para facilitar el despliegue de las tecnologías desarrolladas, se están preparando unas metadistribuciones basadas en el proyecto Gnome2-live, basado a su vez en Debian, que permita instalar y configurar fácilmente estaciones clientes y servidoras comunicables por medio de las tecnologías esbozadas más arriba. 6. Conclusiones El software libre nos ha permitido desarrollar rápidamente con pocos recursos un conjunto de soluciones de bajo coste para mejorar las condiciones de vida en zonas aisladas y desfavorecidas. También ha ayudado el carácter relativamente abierto de la comunidad de radioaficionados. En los casos en que se ha tenido que usar software comercial, las dificultades han sido mayores, ya que se han tenido que soslayar los problemas que su carácter cerrado impedía resolver más directamente. Por ello los nuevos desarrollos se están basando exclusivamente en software libre, si bien se ofrece la oportunidad de usarlos a través de un entorno propietario, a mayor coste. Referencias [1] Rendón A. EHAS-Silvia: Servicios de información sanitaria para las zonas rurales del cauca. In Primer Encuentro de Investigación, Innovación e Ingeniería en Telecomunicaciones y Áreas Afines, [2] William Beech, Douglas Nielsen, and Jack Taylor. AX.25 link access protocol for amateur packet radio v2.2. Technical report, Tucson Amateur Radio Corporation, [3] Andrés Martínez. Evaluación de impacto del uso de tecnologías apropiadas de comunicación para el personal sanitario rural de países en desarrollo. PhD thesis, Universidad Politécnica de Madrid, Escuela Técnica Superior de Ingenieros de Telecomunicación de la Universidad Politécnica de Madrid, [4] Andrés Martínez, Valentín Villarroel, Joaquín Seoane, and Francisco del Pozo. EHAS program: Rural telemedicine systems for primary healthcare in developing countries. In Proceedings of the International Symposium on Technology and Society, [5] Alex Sandy Pentland, Richard Fletcher, and Amir Hasson. Daknet: Rethinking connectivity in developing nations. IEEE Computer, 37(1), enero [6] Thomas Sailer. Soundmodem on modern operating systems. In ARRL and TAPR Digital Communications Conference, [7] Jaap van Til. Netweaving rural villages: introducing the weave. In ITS 12th European Regional Conference. International Telecommunications Society, Sept

113 OPEN SOURCE INICIATIVES IN BIOINFORMATICS A.Labarga 1, I. Kovarskaia 2 1 Universidad Pública de Navarra, Spain; 2 IMAGINA BIOTEK, SLL, Spain alberto.labarga@unavarra.es Bioinformatics is an exciting and rapidly developing field. There has been growing interest in the area in recent years as the rates of biological data generation increased. Several technological advances significantly accelerated the rate at which biological data is generated, mainly faster nucleic acid sequencing methods and highly parallel, microchip analysis technologies for both nucleic acids and proteins. The greatest single effort is the recent draft sequence assembly of the Human Genome. All indications point to the continued expansion of bioinformatics both as a scientific discipline and as a commercial endeavor to meet the challenges of managing and analyzing huge amounts of data. Scientific and methodological advances in both medicine and pharmaceutical discovery derive from these data, so the correct use of computing technologies leads to better science and better products. There is a wide variety of individual projects and groups working on software and tools for bioinformatics (Dugan, 2001). This presentation aims to provide a reference to those projects that seem to be the most important and most active at this time. There are two main groups within the bioinformatics open source software community. The first is the Open Bioinformatics Foundation and their associated projects like BioPerl and BioPython. This group creates development libraries and tools for programmers in a variety of languages for bioinformatics generally, but mainly to facilitate sequence management and analysis. The second group is the Bioinformatics.org and the Open Lab. This group provides support for a large set of unconnected projects all relating to bioinformatics. The projects within the Open Lab are primarily end-user software tools for scientists looking to solve particular biological and bioinformatics problems, and not for software developers. There are also larger, industry-focused organizations related to standards for middleware software, such as CORBA and XML, and the associated standards forming initiatives such as BioXML or BioCorba. We will try to provide a quick overview of these initiatives and we will show some of the work that Public University of Navarra and IMAGINA BIOTEK are developing related to two of these projects: Bioconductor and the Gene Ontology Consortium. References: Dugan, J. Open Source Initiatives In Bioinformatics. A report submitted to the Health Science Intiative Applications Working Group Internet Keywords: Bioinformatics, Biostatistics, Microarrays, Data mining

114 BENEFICIOS DEL CÓDIGO LIBRE EN LAS AREAS DE INVESTIGACIÓN Y DESARROLLO D. Reche Martinez 1, A. García Linares 2, I. Rodríguez Aragón 3 1,2,3 Departamento de Investigación, Desarrollo e Innovación, Novasoft Sanidad, España dreche@novasoft.es Palabras Clave: Investigación, Multiplataforma, Estándar, Seguridad, Sanidad 1. Introducción En los últimos años se escucha continuamente hablar del software libre, en multitud de foros seguidores y detractores debaten acerca de sus beneficios, sin embargo no existe un patrón común de utilización y explotación por parte de las empresas, los modelos de negocio son muy variados. En este articulo pretendemos dar una visión sobre como se utiliza el software libre en las áreas de investigación y desarrollo de organizaciones empresariales y mostrar los beneficios asociados a su utilización. El grupo de investigación, desarrollo e innovación de Novasoft Sanidad hace un uso extensivo del software libre. Uno de los parámetros que consideramos como mas importante en su uso es la confianza. Aunque a priori parezca sorprendente, el software libre nos da seguridad. Pero, Cómo es posible que un software desarrollado por voluntarios de distintas partes del mundo, con distintos niveles de programación, sin ningún interés especial en el correcto funcionamiento de sus desarrollos y en la mayoría de los casos sin ninguna remuneración, sea confiable?. Es fácil de explicar, aquí no hay trampa, todo se puede ver y tocar. El código fuente esta puesto a disposición de los usuarios. Cualquier persona tiene la libertad de adaptar a sus necesidades y modificarlos según su criterio. Los diseños y arquitectura son discutidos y revisados concienzudamente y cuando se detectan errores el propio programador da la señal de alarma, no se oculta información. 2. El modelo OpenSource El modelo de código abierto no es una religión, Es una manera muy pragmática de evolución del software en un ambiente en constante cambio. Aprovecha la sabiduría, la experiencia, la experticidad y el conocimiento de los requerimientos de los usuarios para asegurar que sus necesidades sean cubiertas rápidamente. En general, para el modelo de código libre podemos enumerar las siguientes características y beneficios: Gestión de la configuración (plataformas, compiladores, etc.) Muchos proyectos de código libre permiten la utilización del compilador que mejor se ajuste a las necesidades del usuario, esto permite personalizar el entorno de desarrollo y mejora la portabilidad del código. Si el sistema no tiene posibilidad de ejecución en su plataforma, entonces tome la iniciativa y cree un grupo de usuarios con su misma afinidad, colabore para obtener un beneficio común. Igualmente si usted vende una plataforma que esta pobremente soportada, manténgala usted, colabore con sus usuarios para afinar el software y sacarle el máximo rendimiento a su plataforma. En general el código libre facilita la facultad de elección. Mientras que los sistemas propietarios limitan esta facultad al restringir, normalmente, el uso de una plataforma y compilador especifico.

115 Gestión de revisiones y evolución del producto En este modelo ya no hay necesidad de esperar las promesas de resolución de problemas en la siguiente versión. Usted posee el código fuente y puede participar activamente en la las actividades de desarrollo, realizar un seguimiento de las mismas, participar en las pruebas verificando las nuevas características y su estabilidad. Depuración Al disponer del código fuente y del compilador adecuado, es posible participar mas activamente en el seguimiento de errores directamente realizando depuración sobre el código, esto acelera notablemente la velocidad de detección y corrección de errores ya que su descripción del error esta mas cercano al programador. Documentación La documentación del sistema normalmente es un proyecto satélite al proyecto de desarrollo. Puede y debe participar activamente en el desarrollo de la misma, realizando traducciones a su idioma, colaborando en las correcciones de las mismas y en su evolución según las revisiones. Esta interacción conlleva una documentación mas fiable y más actualizada de la que cualquier producto propietario pueda proporcionar. Propiedad En este modelo los usuarios son participes del sistema. Tienen interés en su buen rumbo. Ya no son victimas de decisiones corporativas. Herramientas de terceros Debido a que se dispone del código fuente los usuarios tienen mayor facilidad para desarrollar herramientas y productos complementarios al sistema. No tienen que necesariamente acceder vía APIS. Benchmarking Al no estar sometido a intereses particulares el software libre no inhibe su evaluación, no esconde o maquilla los resultados de la misma. No tiene que responder acerca del volumen de venta, si no esta preparado o no es lo suficientemente estable no se pasa a producción. Los evaluadores tampoco están sujetos a interés ya que finalmente son los máximos interesados en que el sistema tenga un rendimiento optimo. Seguridad Código abierto significa que lo que ves es lo que hay. Puede inspeccionar el código línea a línea en busca de acciones maliciosas, caballos de Troya, etc. Licencia No existen cargos por licencia, ni de desarrollo ni de ejecución. Es posible instalar el software donde y como quiera. Pasar a una nueva versión ya no es una decisión económica sino técnica, ya que el upgrade no tiene coste alguno. Puede utilizar el software como elemento de su solución sin temor a elevar los costes de distribución. Para nosotros, una de las ventajas mas importante del Software libre además de ser gratuito es, en la mayoría de las ocasiones, ser multiplataforma, ya que este, es un

116 excelente complemento para nuestros productos desarrollados en Java. En este aspecto es importante señalar la utilización cada vez mayor de estándares para facilitar la cooperación entre sistemas de distintas organizaciones y sistemas heterogéneos, como el XML, SOAP, etc. En particular, en las áreas de investigación y desarrollo, encontramos las siguientes ventajas adicionales: Reducción de costes de investigación El mantenimiento de un departamento de investigación y desarrollo dentro de una empresa, esta siempre sujeto a presiones económicas y de resultados. Especialmente en los casos de pequeñas y medianas empresas. Esto ocasiona que si no se cumplen los plazos o las expectativas planteados inicialmente, se tienda a la supresión o reducción del departamento. Buscar medios que permitan reducir estos costes o mejorar los tiempos de presentación de resultados son siempre una garantía de permanencia. En este aspecto, el uso de software libre supone una clara ventaja ya que los costes se reducen accediendo al mismo tiempo a tecnologías punta que permiten disminuir los tiempo de respuesta e implementar nuevas ideas que de otra manera sería difícilmente acometibles. Interacción con otros grupos de trabajo Es casi imposible utilizar un software libre sin involucrarse en el proyecto. Esto provoca una interacción continua en foros, listas de correo, etc. Esta interacción con otros grupos de trabajo aporta nuevas ideas ya sea para ese u otro sistemas, descubrir posibles errores de diseño, da la posibilidad de compartir información y contrastar los resultados de la investigación aportando una provechosa interacción. Inmediatez A menudo es necesario desarrollar elementos específicos de un sistema o solucionar una necesidad con extrema urgencia. Los repositorios de proyectos de código libre existentes en Internet aportan soluciones eventuales listas para descargar en las que podemos encontrar proyectos de todo tipo que en ocasiones solucionan o al menos nos sirven de guía en la consecución de la necesidad. Metodología Dado que el departamento de I+D marca el ritmo de la innovación de la empresa en aspectos tales como forma de trabajo, adopción de nuevas herramientas, sistemas de calidad, etc. el hecho de que se encuentre involucrado en proyectos de código libre con grupos de ambientes diferentes incrementa de manera muy positiva la adopción de técnicas metodologías de desarrollo como UML, URP, WorkFlows, etc. 3. Detalle de los proyectos utilizados Participamos en varios proyectos GNU y utilizamos muchos de los sistemas abiertos que se pueden encontrar gratuitamente en Internet. Esto nos da la posibilidad de experimentar con diferentes entornos y sistemas y dotar una mayor y mejor funcionalidad a nuestros productos. Entre los distintos sistemas de software libre utilizados por nuestro departamento, podemos destacar los siguientes:

117 Sistemas Operativos Linux. Es el sistema operativo libre mas utilizado para PC. Posee numerosas variantes, entre ellas están las iniciativas Linex y Guadalinex. Este entorno nos da la posibilidad de realizar test de nuestros productos desarrollados en Java y verificar su portabilidad. Además de utilizarlo como estación de trabajo, también aprovechamos sus características como servidor destacando su gran fiabilidad y estabilidad. FreeBSD. Nuestro servidor de correo, webmail, ftp, listas de correo y distribución se ejecutan en este sistema. Destacamos su robustez, sus limitadas exigencias hardware y su seguridad. Bases de Datos MySQL. Probablemente es la base de datos libre mas conocida. Intentamos desarrollar nuestros productos de manera que sean independientes del sistema de gestión de base de datos utilizada. En este aspecto, utilizamos este motor de base de datos como elemento participe en nuestro sistema de pruebas. Destacamos su sencillez y robustez. PostgreSQL. Este motor de base de datos aporta una mayor velocidad de acceso y un modelo de trabajo mas seguro (utilización de SSL y kerberos) y a esto añadimos características como la integridad referencial o lenguajes procedurales. Servidores y plataformas Apache+Tomcat. Líder en número de servidores web instalados. Apache y Tomcat ofrecen una solución eficaz a nuestra necesidad de exportar el interfaz de elementos de nuestros productos utilizando tecnología Java/JSP. También utilizamos la combinación Apache+PHP para obtener acceso a datos desde nuestra Intranet. Como una de las ventajas mas importantes destacamos su flexibilidad y extensibilidad. Jonas. Un servidor de aplicaciones que cumple con la normativa J2EE en el que poder realizar un despliegue de nuestros componentes Java (EJB). Es bastante ligero y permite el acceso a EJB vía RMI/IIOP. JBoss. Uno de los servidores de aplicaciones J2EE de código abierto mas conocido y utilizado. Actualmente disponemos de instalaciones en una comunidad autónoma que lo utilizan como motor para nuestra aplicación e-siap y pensamos introducirlo como núcleo de nuestra principal sistema de información sanitaria. Es bastante escalable y el despliegue de componentes es practico, no tiene requisitos hardware demasiado elevados. Mono. Mono es una iniciativa para implementar el entorno.net en código abierto. Entendemos que es una iniciativa muy interesante debido a la importancia que últimamente ha adquirido el entorno.net de Microsoft entre los desarrolladores. Herramientas: Jedit. Es un excelente editor de texto basado cien por cien en Java. Su característica mas deseable es su extensibilidad. Posee extensiones muy interesantes para editar y verificar ficheros XML. Forte. Es quizás uno de los entornos de desarrollo en Java mas utilizados en el mundo. Lo utilizamos para desarrollar en todos nuestros productos basados en tecnología Java.

118 OpenOffice. Es un conocido y completo paquete ofimático que tiene la posibilidad de ejecución en la mayoría de plataformas actuales, acceso a toda la funcionalidad y datos a través de componentes abiertos basados en API's bien definidas compatibles con Java y formatos de fichero basados en XML. Es por ello que desarrollamos un software especifico de integración de OpenOffice con uno de nuestros productos, e-siap. 4. Conclusiones A lo largo de este articulo hemos señalado las ventajas y beneficios de la utilización del código libre. Según nuestra opinión, en el modelo de código libre se produce una redirección del gasto económico. Si en los sistemas propietarios el gasto se produce al obtener las licencias y el soporte adecuado. En el modelo de código libre ya no hay gasto en licencias, pero sin embargo este se invierte en el mantenimiento, ya que se debe aportar esfuerzo de desarrollo al proyecto con su propio personal y darle continuidad. A cambio se obtiene mayor control sobre el sistema. Usted decide que rumbo tomar, participa en las decisiones, en definitiva es libre de elegir. Y siempre debe tener en cuenta que una mayor implicación repercutirá en una mayor capacidad para decidir. Es fácil descargar un software libre ponerlo en un CD y venderlo, pero la dificultad esta en darle un valor añadido a ese software. En nuestro caso es mas bien al revés. Es el software libre el que cubre ciertos aspectos adicionales de nuestros productos. Pero garantizar el soporte del producto no es cosa fácil, ya que al ser un trabajo voluntario no podemos exigir un tiempo de respuesta limitado a la hora de corregir errores, liberar nuevas versiones, etc. Aún así, consideramos que la introducción del software libre en la empresa es beneficiosa y necesaria, en particular en las áreas de investigación y desarrollo, debido en gran parte a la posibilidad de intercambiar conocimiento que en nuestra opinión redunda finalmente en una mejor calidad del producto final.

119 Día h Sala 2: Aplicaciones Ofimáticas, Integración y Desktop Moderador Carlos Castro Castro Director General de Sociedad de la Información. Junta de Extremadura Participantes Ben Marx Juan Zamora Diego Gómez Deck Kurt Pfeifle Antonio Larrosa Abraham Otero Miguel Hormigo Ruiz Rafael Grimán Linux Business Development, IBM Spain and Portugal Silicon Graphics Junta de Extremadura Danka Deutschland Holding GmbH Proyecto KDE Universidad de Santiago de Compostela Director Soluciones Globales Internet Suse Linux AG

120 ARQUITECTURAS DE KDE Y DESARROLLO RÁPIDO DE INTERFACES DE USUARIO A. Larrosa KDE Developer larrosa@kde.org KDE es un proyecto de software libre con más de 1000 colaboradores activos en todo el mundo que realizan el escritorio lider actualmente en la comunidad Linux según los usuarios que le han otorgado diversos premios durante años consecutivos por todo el mundo. En este artículo se enumerarán algunas de las arquitecturas que se han desarrollado dentro de este proyecto, parándose especialmente en las más importantes. Así, se explicará el funcionamiento de DCOP (protocolo de comunicaciones del escritorio), así como de algunos usos que se le pueden dar. También se hará hincapié en el excelente trabajo de los desarrolladores de KIO que es la arquitectura que encapsula todos los accesos a documentos e información, permitiendo acceder transparentemente a un documento sin importar el medio que haya que usar. No se dejará atrás a KParts, que es la tecnología que permite reutilizar funcionalidad de una aplicación en cualquier otra (por ejemplo, para usar un navegador web muy facilmente en cualquier aplicación, usando la componente KHTML a través de Kparts). Y se hará una introducción a Kiosk, una arquitectura para los entornos de uso restringido de ordenadores especialmente pensada para kioskos, máquinas autónomas y otros entornos restrictivos. Además, se hará un repaso a los métodos de desarrollo rápido de aplicaciones con KDE evaluando varias alternativas como KDialog, Kommander y Qt/Designer junto con el multiples veces premiado KDevelop. Keywords: Escritorio, Desarrollo, KDE, Arquitecturas 1. Introducción A mediados de 1996, Linux y el software libre había entrado ya en la mayoría de las universidades y los expertos comprendían el potencial que tenían sistemas operativos como Linux o FreeBSD. Sin embargo, y a pesar del gran número de ventajas que ofrecía respecto a otros sistemas operativos, tenía un problema pues para un iniciado en informática, era demasiado complicado de usar y sólo las personas con más experiencia se atrevían a hacerlo. Es por ello que Matthias Ettrich tuvo la idea de realizar un entorno de escritorio completo que permitieran a todos los usuarios el poder acceder a sistemas operativos que hasta esa época estaban reservados para los expertos. Además, se haría usando licencias libres, y de forma altruista. Viendo la magnitud del proyecto, envió una carta pública a todo el que quisiera colaborar con él e inmediatamente se le unieron decenas de personas, e iniciaron KDE. Desde entonces hasta ahora, KDE ha pasado por 3 versiones principales (la versión actual al tiempo de publicar este artículo es la 3.2) y se han desarrollado multitud de aplicaciones de todo tipo (desde un navegador web innovador llamado Konqueror que actualmente está siendo utilizado por Apple como base para su propio navegador, hasta una suite de oficina completa, KOffice, con editor de texto, hoja de cálculo, programa de presentaciones, etc.). Todo este desarrollo de aplicaciones ha necesitado del desarrollo de multitud de tecnologías que solucionen los problemas y necesidades que se iban encontrando. Como consecuencia, se han creado multitud de soluciones muy útiles para los desarolladores de casi cualquier aplicación e incluso para los usuarios que quieran avanzar un poco más en el uso de un sistema Linux.

121 2. Arquitecturas de KDE 2.1. DCOP Cuando un usuario usa un entorno de escritorio en su ordenador, hay multitud de aplicaciones ejecutándose a la vez. Para proveer al usuario de un entorno integrado y consistente, es necesario que las aplicaciones se comuniquen entre ellas de forma que no actuen como un conjunto de aplicaciones independientes sino en conjunto como un solo entorno de escritorio. Así nació DCOP (Desktop COmmunication Protocol, o protocolo de comunicaciones para el escritorio) como un protocolo que permite a unas aplicaciones comunicar su estado al resto de las aplicaciones o hacer preguntas o peticiones entre ellas. Por ejemplo, el marcador telefónico kppp puede emitir una señal cuando el usuario se conecta a internet o cuando se desconecta, de forma que otras aplicaciones pueden cambiar su comportamiento de acuerdo a esto (por ejemplo, para usar una caché local cuando se está desconectado, pero acceder directamente a la información a través de internet cuando se está conectado). Usando DCOP, las aplicaciones también pueden preguntar el estado a otras aplicaciones, por ejemplo, el lector de correo se puede comunicar con el cliente de mensajería instantanea para conocer si un contacto está actualmente en linea para comunicarse con él más rápidamente que con un mensaje de correo. Por último, aunque no menos importante es el uso de DCOP para realizar acciones en otros programas, así se puede hacer una llamada mediante DCOP para que el lector de correo descargue el correo de los servidores configurados, para que el navegador web visite una página determinada, o para hacer que el programa que gestiona el fondo de pantalla cambie el fondo por otro. DCOP es un protocolo construido sobre el ICE (Inter Client Exchange) que forma parte del estandar X11R6 y posteriores, y que es el encargado de gestionar las autorizaciones y permisos mediante el mismo método que la autorizaciones de X11 para usar el DISPLAY. En este modelo, hay un servidor de DCOP (dcopserver) y cada uno de los programas que envían o reciben señales a través de DCOP en un cliente del servidor de forma que todos los clientes son tratados iguales y el servidor se encarga de dirigir y repartir las señales entre los clientes. Hay dos tipos de señales, las que son de "enviar y olvidar" y las que devuelven un valor. Las primeras se utilizan cuando no estamos interesados en ningún valor de retorno o cuando estamos enviando una señal a más de una aplicación a la vez, con lo que no podemos tener un valor de retorno, y las segundas se utilizan cuando necesitamos un valor de retorno, ya sea porque queremos saber si la petición ha sido procesada correctamente, o porque esperamos una referencia de DCOP para poder seguir trabajando mediante llamadas DCOP con un mismo recurso. Las referencias DCOP se utilizan para referenciar a un recurso (un objeto) que se encuentra en otra aplicación y permiten realizar con ese objeto las funciones que el propio objeto haya especificado en su interfaz. El desarrollo de interfaces DCOP se sale del ámbito de este artículo, con lo que sólo habría que decir que es muy sencillo e invitar a las personas interesadas a visitar las páginas para desarrolladores de KDE en Sólo decir que se puede usar DCOP desde muchos lenguajes de programación (desde C++ al shell, pasando por python, perl, javascript, etc). Además, la aplicación kdcop permite mostrar las interfaces de los programas conectados en un momento dado al servidor dcop e incluso hacer llamadas DCOP de forma muy sencilla y didáctica KIO KIO es la arquitectura que se utiliza para abstraer los programas de los protocolos que puedan utilizarse para transferir archivos ya sea a través de internet, a través de una red local o incluso en el propio ordenador. Mediante KIO, los programas de KDE pueden acceder

122 transparentemente a casi cualquier protocolo sin necesidad de que el programador de la aplicación tenga que soportarlos explícitamente, ni siquiera sepa que existe, o incluso usando protocolos propietarios. KIO está estructurado en módulos que se cargan y ejecutan dinámicamente conforme a las necesidades de las aplicaciones. La idea principal es que cualquier documento y cualquier cosa es referenciable mediante una URI (Uniform Resource Identifier) tal y como se describe en el RFC Una URI tiene un campo que indica el protocolo mediante el cual el recurso está accesible, un nombre de máquina que indica donde está disponible ese recurso, optativamente un nombre de usuario y contraseña que se utilizan para identificarse y autentificarse con el ordenador remoto, también opcionalmente un número de puerto en el que el protocolo especificado anteriormente está disponible, y la dirección dentro del ordenador remoto donde el recurso al que queremos acceder está disponible (optativamente, puede ir seguido de más parámetros como una marca interna del recurso para acceder directamente a una posición específica, o incluso una petición para que el servidor genere el documento según la petición del usuario. Así, cualquier aplicación puede usar KIO para acceder a cualquier documento o fichero simplemente especificando la URI del objeto. Así, todas las aplicaciones de KDE permiten no sólo abrir ficheros locales sino también abrir ficheros remotos a través de protocolos como ftp, http, ssh, samba (para acceder a directorios compartidos por sistemas windows), ldap, etc. Cada protocolo implementado es un módulo (una librería dinámica) que permite obtener y enviar ficheros. Así cualquier persona puede implementar un protocolo propio haciendo un nuevo módulo y automaticamente todas las aplicaciones de KDE pueden acceder a recursos a través de ese protocolo sin modificar nada y sin recompilar ningún programa. El uso de KIO está ampliamente extendido, siendo quizás el más útil el que se hace en el diálogo de abrir un documento, donde el usuario puede seleccionar ftp://ftp.miservidorftp.org/ y acceder mediante el propio diálogo de abrir fichero a un servidor ftp remoto. Así, si por ejemplo desde el editor de texto Kate se abre un fichero mediante el protocolo fish://miservidorssh.org, cuando se pulse en "Guardar Documento", el fichero se guardará en su dirección original del ordenador remoto, sin necesidad de bajárselo,, modificarlo, guardarlo y volver a enviarlo mediante un cliente ssh externo. Otro uso muy útil de la arquitectura KIO es el de simular estructuras de directorios virtuales, así, el protocolo audiocd:// muestra en forma de directorios una estructura inexistente pero muy práctica de los CDs de audio. En el directorio raíz hay varios ficheros que contienen la información digital de cada pista de audio, en otra carpeta, un fichero en formato mp3 por cada pista, en otra carpeta en formato ogg vorbis, etc. Además, accede a una base de datos CDDB para poder mostrar como nombre de cada fichero el nombre de la canción. Así, cuando el usuario decide copiar uno de los ficheros al disco duro, el "esclavo de KIO" (que así es como se llaman a los módulos, o "kioslaves") procesa el CD para generar al vuelo el fichero en el formato seleccionado KParts Hace unos años se vió la necesidad de poder utilizar funcionalidad de una aplicación dentro de otra sin los problemas que trae el copiar código fuente de un programa en otro. Dichos problemas son tan importantes como el hacer muy dificil la mantenibilidad del código "copiado" (ya que hay que mantenerlo siempre actualizado e igual que el original) y la dificultad de extensión ya que para seguir extendiendo un programa necesitaría volver a copiar cualquier otro código de otro, lo que además, aumenta el tamaño de la aplicación y los recursos que consumiría. Además, en aquella época se estaba viendo la importancia de tener una suite de

123 oficina bien integrada para poder tener un entorno de escritorio completo. Así que los desarrolladores de Konqueror (el navegador universal tanto para ficheros locales como navegador de internet) y KOffice (la suite de oficina de KDE) desarrollaron una primera versión de KParts, que evolucionó en una solución general a este problema. KParts soluciona así una de las necesidades básicas de KOffice, que es la de poder empotrar un documento dentro de otro. Dicho de forma un poco más realista, KParts permite empotrar una aplicación dentro de otra. Pero también permite implementar plugins para aplicaciones de forma que mediante su instalación, un plugin pueda proveer nueva funcionalidad a un programa. Esto es por ejemplo lo que utilizan aplicaciones como Kopete (el cliente de mensajería instantánea de KDE) para implementar las extensiones que hacen cosas como poner el estado del usuario a "Alejado" automaticamente cuando Kopete (o mejor dicho, el plugin de "auto-away") detecte analizando las imágenes de una webcam que el usuario ya no está delante del ordenador. KParts se utiliza extensivamente por todo KDE. Uno de los usuarios más remarcables es Konqueror, que utiliza Kparts para cada una de las vistas que muestra en su interfaz. Así, todo en Konqueror es una componente de KParts, que se podría utilizar también en otras aplicaciones que las necesitaran, mejorando así la reusabilidad del código fuente y ayudando en gran medida a la rentabilidad del esfuerzo ejercido para desarrollar un programa, ya que una vez desarrollado algo en forma de componente de KParts, se puede reutilizar sin problemas en múltiples sitios. Es reseñable notar que incluso si hay un gran número de aplicaciones que usan KParts para poder usar funcionalidad de otras aplicaciones, el número de aplicaciones que implementan su funcionalidad en forma de componente es aún más grande. Hay componentes para ver imágenes, ficheros pdf (con la componente kghostview), ficheros postscript, hay componentes que implementan un reproductor multimedia (como la componente que kmplayer ofrece que contiene una ventana del reproductor mplayer junto con los controles), componentes para empotrar un terminal de texto (konsole) en cualquier aplicación, para empotrar un reproductor de ficheros MIDI (Musical Instrument Digital Interface) usando Kmid, y en general, componentes para visualizar casi cualquier formato de fichero. Pero quizás las más importantes son KHTML y Kate. KHTML es la componente que Konqueror utiliza para navegar por internet, e implementa un renderizador de páginas web que sigue la mayor parte de los estándares actuales (HTML 4, CSS, Javascript, etc.). Otros programas también utilizan KHTML para mostrar al usuario interfaces más elegantes (implementadas internamente como páginas web) o para mostrar páginas web que contienen la ayuda del programa. Kate es un avanzado editor de texto plano con soporte para coloreado de sintaxis, autocompletado, etc. Se utiliza en Konqueror por ejemplo para ver rapidamente el contenido de un fichero de texto, o también se utiliza esta componente en el IDE de desarrollo KDevelop, donde se amplía su funcionalidad con la posibilidad de mostrar por ejemplo la linea de ejecución de un programa cuando se está depurando, todo usando la misma componente Kiosk Aunque uno de los objetivos de KDE es dar al usuario el control absoluto de su escritorio, en algunos casos es necesario reducir las posibilidades que KDE ofrece por ejemplo por que se quiera que el sistema sólo se use para uno o varios fines muy particulares. Kiosk es la arquitectura que permite desactivar funcionalidad de KDE para producir un entorno más controlado. Por ejemplo, para prohibir que un usuario pueda modificar el fondo del

124 escritorio en ordenadores que se usen para acceso público a internet. Esto se puede conseguir de varias maneras. Por una parte, la arquitectura permite al administrador de una máquina configurar qué opciones de qué programas el usuario va a poder o no modificar. Anteriormente ya se podía hacer algo parecido eliminando los permisos del usuario en el sistema de ficheros al fichero que contiene la configuración, pero esta solución no es buena ya que por una parte, actúa sobre ficheros completos (no sobre parámetros individuales de una aplicación) y por otra, no es muy segura ya que el usuario podría renombrar el fichero o cualquiera de los directorios ancestros y regenerar un nuevo fichero donde sí tendría permisos de escritura. Además, no tendría sentido el deshabilitar ciertas acciones si el usuario podría ejecutar un terminal y editar la configuración manualmente. Es por ello que también se puede deshabilitar la ejecución de konsole. Por si eso fuera poco, la plataforma Kiosk permite definir restricciones respecto a URLs de manera que el usuario no pueda ser redireccionado desde una URL a otra o de manera que al usuario se le deniegue el acceso a listar el contenido de un directorio determinado o incluso el permiso a abrir cualquier fichero que esté fuera de su directorio $HOME (ni siquiera para lectura). 3. Desarrollo rápido de aplicaciones 3.1. KDialog KDialog es un sencillo programa que se puede utilizar para dotar de interfaz gráfica a aplicaciones escritas en un lenguaje de shell como bash. Con KDialog se pueden generar diálogos mediante los parámetros que acepta y devuelve la entrada del usuario en la salida estandar del programa, con lo que hace muy sencillo mostrar diálogos para pedir o enseñar datos al usuario. Para mostrar un mensaje de error por ejemplo, basta con ejecutar (desde un terminal): kdialog --error "Se ha producido un error" Para preguntar al usuario si desea continuar, se puede usar: kdialog --yesno " Desea continuar?" y el código de retorno especificará si el usuario seleccionó el botón "sí" o el botón "no". También se puede mostrar una lista de opciones para que el usuario seleccione una, en este caso, conviene usar un combobox. Para ver la (larga) lista de opciones de kdialog, use kdialog --help (incluye la posibilidad de pedir una linea de texto al usuario, una contraseña, un fichero con el diálogo de abrir fichero standar de KDE, preguntas con 3 opciones, etc.) Kommander Kommander es un conjunto de herramientas que permiten crear diálogos gráficos con los que el usuario puede interactuar. El editor está basado en Designer, con lo que los interfaces se pueden editar de manera extremadamente fácil. Pero lo más importante es que tiene detrás un novedoso sistema de programación. La idea básica es que los widgets (los elementos visuales tales como un botón, una línea de edición, una barra de desplazamiento, etc.) que se usan generan, según su estado, un texto. Este texto puede ser una linea de comando, un trozo de código, un documento, etc. Así, el texto resultante puede usarse para ejecutar un programa (de ahí el nombre Kommander), escribirse en un archivo, como parámetro de otro script, o cualquier otra cosa en la que se pueda pensar. La ventaja principal es que no hay que escribir ninguna linea de código.

125 El texto asociado a un widget puede contener texto fijo o variables que se especifican por un así, si el texto asociado a una línea de edición entonces este texto se sustituye por el que el usuario haya escrito en la línea de edición. Por otra parte, también se puede especificar como nombre de variable el nombre de otro widget, en ese caso, la variable toma el valor del texto asociado al widget que se referencia. De esta forma, si una línea de edición llamaba lineadecomando como texto asociado y un botón especial de ejecución (que ejecuta el código asociado cuando el usuario lo pulsa) tiene como texto entonces cada vez que el usuario pulse ese botón, se ejecutará el comando que haya escrito en la línea de edición. El editor de Kommander (kmdr-editor) guarda todos los datos en un fichero XML que más tarde puede ser ejecutado por kmdr-executor Qt Designer y KDevelop Qt Designer es un editor de interfaces que permite diseñar ventanas, diálogos, asistentes, widgets compuestos, etc. de forma completamente visual. Mediante un mecanismo de arrastrar y soltar, se pueden añadir todo tipo de elementos (incluso se puede extender con widgets propios de una aplicación específica), especificar la disposición dentro de la ventana, y retocar todos y cada uno de los atributos. KDevelop es un entorno de desarrollo integrado, con el que se puede desarrollar en casi cualquier lenguaje (están soportados C++, C, Java, Bash, Python, etc. ) además, tiene soporte de coloreado de sintaxis, autocompletado, depurador integrado para C/C++ y Java, y multitud de plugins que permiten hacer casi de todo (desde analizar la aplicación para encontrar problemas de pérdida de memoria o problemas de rendimiento en determinadas funciones, hasta ver gráficamente las diferencias entre dos ficheros, encontrar problemas de sintaxis en el código mientras se escribe o un asistente para ayudar en la edición de ficheros automake). 4. Conclusión Actualmente se siguen desarrolando nuevas ideas, como una nueva tecnología de compresión que permite comprimir los datos transmitidos entre un cliente y un servidor X de forma que las aplicaciones de KDE tengan un rendimiento muy mejorado respecto de otras soluciones para construir un servidor de terminales. De la misma forma, se están desarrollando multiples nuevas tecnologías, pero por lo rápido de la evolución de los proyectos opensource, seguramente tendrán inmensas mejoras en el tiempo que pase desde que escriba este documento hasta que usted lo lea, con lo que le invito a visitar para estar al tanto de las novedades que se vayan produciendo. 5. Bibliografía El proyecto KDE Información para desarrolladores de KDE Anuncio original (1996) de Matthias Ettrich para comenzar el proyecto KDE Tutoriales Tutorial de desarrollo visual Konqueror - Quanta (editor de páginas web) y Kommander Qt Designer

126 Análisis de la libertad en la plataforma Java A. Otero 1 y A. Sánchez-Mariscal 2 1 elabra@usc.es, Departamento de Electrónica y Computación, Facultad de Física. Universidad de Santiago de Compostela. Tlf , Ext mariscal@javahispano.org, javahispano ( Abstract Este trabajo analiza si se puede o no considerar que la plataforma Java sea libre. Este análisis no requiere sólo estudiar la parte software de la plataforma, fuente tradicional de las críticas a Java por su condición de no libre, sino también la libertad de las especificaciones que definen la plataforma, y por lo tanto al software. Mostraremos de qué partes consta la plataforma Java, y explicaremos el proceso mediante el cual se definen y mantienen las especificaciones que la guían, resaltando las principales causas de la falta de libertad, y proponiendo soluciones a éstas. Esto no siempre es simple, ya que no es fácil compatibilizar algunas ideas en las que se basa Java con las ideas en las que se basa el software libre. En el trabajo se proponen posibles soluciones a este problema, y se analiza la posición de Sun respecto a liberar completamente la plataforma. 1 Introducción Determinar la libertad de la plataforma no es sólo cuestión de analizar las licencias bajo las que se distribuye el conjunto de herramientas de desarrollo (jdk), y las librerías básicas, de Sun Microsystems, principal fuente de críticas de la comunidad de Software Libre (SL) hacia Java. En la plataforma Java, además de software, hay algo más importante: las especificaciones que debe cumplir el software, recogidas en una serie documentos pdf que describen todas y cada una de las tecnologías que componen la plataforma. Un análisis acerca de la libertad de la plataforma no puede olvidar estas especificaciones. Sin embargo, organizaciones como Free Software Foundation (FSF) [1], y Open Source Iniciative (OSI) [2] no proporcionan criterios para determinar si una especificación es o no libre. En este documento hemos analizado, con la filosofía del SL, el proceso de creación y mantenimiento de las especificaciones, concluyendo que no se pueden considerar completamente libres, y proponiendo las modificaciones que consideramos necesarias para que se puedan considerar libres. En cuanto a la parte software de la plataforma, las ideas del movimiento del SL, acceder y modificar el código fuente del software sin restricciones, pueden entrar en conflicto con el principio básico de la plataforma Java: escríbelo una vez y ejecútalo en cualquier sitio (adaptación de Write Once Run Anywhere, WORA). En el trabajo se proponen posibles soluciones para compatibilizar, en la medida de lo posible, estos objetivos parcialmente enfrentados. Este trabajo se organiza del siguiente modo: en el primer apartado se exponen las partes de las que consta la plataforma Java, a continuación se explica cómo se define ésta; es decir, cómo se crean y mantienen las especificaciones que la guían. En el cuarto apartado analizamos la libertad de la plataforma, analizando por un lado la libertad de las especificaciones y por otro la libertad de las implementaciones de estas especificaciones. En el quinto apartado se analiza la posición de Sun Microsystems acerca de liberar o no Java. Finalmente se exponen las conclusiones a las que hemos llegado en este trabajo. 2 Qué es la plataforma Java? Hill Venners en su libro [3] afirma que Java está formado por cuatro piezas completamente distintas: una especificación de un lenguaje de programación, una especificación de un formato binario, los bytecodes, una especificación de una máquina virtual, encargada de interpretar los bytecodes, y un conjunto de librerías estándar. Estos cuatro elementos definen, sin duda, el lenguaje de programación Java. Sin embargo si Java ha alcanzado tanto éxito y difusión no es sólo gracias al lenguaje, sino también al resto de la plataforma, que integra múltiples tecnologías en su seno, tecnologías para el desarrollo de aplicaciones Web (Servlets y JSP ), de aplicaciones empresariales (EJB), de aplicaciones para telefonía móvil (MIDlets), tarjetas inteligentes (JavaCard) y un inmenso sinfín de tecnologías que hicieron a Java único hasta hace tan sólo un par de años, cuando apareció.net. El fin de este trabajo no es sólo analizar la libertad del lenguaje de programación, y/o del jdk distribuido por Sun, sino de toda la plataforma en su conjunto. Por ello, para nuestros objetivos, es más correcto considerar que la plataforma Java está compuesta por un conjunto de especificaciones, que definen todas y cada una de las partes de la plataforma, y una serie de implementaciones de estas especificaciones. Sin duda, por ser la base sobre la cual se edifica el resto de la plataforma, las especificaciones del lenguaje, bytecode, máquina virtual, y de las librerías estándar juegan un papel protagonista, pero no son las únicas. Por ello, un análisis que pretenda determinar si se puede o no considerar libre la plataforma Java, no sólo

127 debe analizar su parte software, sino también las especificaciones. 3 La definición de las especificaciones: el Java Community Process El JCP, Java Community Process [4] es el organismo que dirige, mediante la creación de nuevas especificaciones y el mantenimiento de las ya existentes, la evolución plataforma Java. El JCP define su propio funcionamiento y las normas por las que se rige, normas que han ido evolucionando desde su creación en Diciembre de La versión actual del JCP, y la que se describe en este documento, es la 2.6 [5]. El JCP es administrado por el Program Management Office (PMO), organismo formado por asalariados de Sun Microsystems. Dos Comités Ejecutivos (CE) se encargan de aprobar las modificaciones y extensiones de la plataforma; uno encargado de las especificaciones relacionadas con J2EE y J2SE (ediciones empresarial y estándar, respectivamente, de la plataforma), y el otro de las relacionadas con J2ME (edición para pequeños dispositivos: teléfonos móviles, tarjetas inteligentes ). Cada uno de estos comités está compuesto por 16 miembros con derecho a voto, 5 elegidos mediante votación entre los miembros del JCP, votación en la que participan todos los miembros del JCP. 10 son propuestos por el PMO, siguiendo los criterios de comunidad balanceada y representación regional [5]. Estos miembros han de ser ratificados mediante votación pública. El miembro restante es un representante de Sun. En cada comité hay un segundo representante de Sun, que ejerce la labor de presidente, pero que no posee derecho a voto. Convertirse en miembro del JCP es gratis para empresas licenciatarias de Sun (empresas que implementan especificaciones de la plataforma con ánimo de lucro y pagan por ello a Sun), y para personas que a título individual deseen formar parte del JCP. Las empresas no licenciatarias han Figura 1 Diversas etapas por las que pasa un Java Specification Request. de pagar 5000 $ por año. En el caso de organizaciones sin ánimo de lucro, e instituciones académicas, es un comité formado por un miembro de Sun, un miembro del mundo del SL, o del mundo educacional, y un miembro elegido democráticamente, quien decide si pueden formar parte del JCP gratis, o han de pagar 2000 $. Las incorporaciones de nuevas tecnologías a la plataforma Java se realizan a través del JCP, mediante un Java Specification Request [6] (JSR). Para crear un JSR se ha de explicar en un documento la necesidad de esa nueva tecnología, o de modificación de una tecnología ya existente, y cómo afectará este cambio al resto de la plataforma. Aunque no es necesario, también es recomendable proponer un grupo de expertos que se encargará de desarrollar el JSR, en caso de ser aceptado. Cualquiera, sea o no miembro del JCP, puede proponer nuevos JSR. Uno de los dos CE del JCP, según el nuevo JSR afecte a J2ME, o a J2SE/J2EE, analiza la propuesta y decide si acepta o no la creación del JSR. Esta decisión se realiza mediante una votación pública, donde el nuevo JSR debe obtener mayoría simple. A continuación el grupo de expertos, normalmente liderados por quien propuso el nuevo JSR, trabaja sobre la especificación. Deberán completar el documento que define la nueva tecnología o modificación de una ya existente, una implementación de esta tecnología, denominada Implementación de Referencia (IR), para probar que la tecnología es factible, y un Test de Compatibilidad (TC), una batería de pruebas que permitan comprobar si una implementación cumple o no la especificación. Tanto la IR como el TC son desarrollados bajo la licencia que el grupo de expertos decida, incluida cualquier licencia libre. En una primera fase el grupo de expertos se centra en la definir la tecnología. Los documentos sobre los que trabajan son accesibles a todo el mundo a través de Internet, y cualquiera puede opinar y enviar realimentación sobre ellos al grupo de expertos. Una vez que los expertos han llegado a un acuerdo en la especificación ésta ha de ser aprobada por el CE correspondiente, mediante votación pública en la que necesita una mayoría simple de los votos emitidos para aprobarse. Si es aprobada pasa a una tercera fase, donde es toda la comunidad la que revisa y comenta la especificación, mientras el grupo de expertos se centra en el desarrollo de la IR y el TC. Una vez que el grupo de expertos ha terminado su trabajo éste, nuevamente, ha de ser aprobado por el CE correspondiente mediante una votación pública. Finalmente se entra en una fase cíclica de mantenimiento de la tecnología, fase también abierta al público (ver Fig. 1). Hay una serie de JSR en los que Sun tiene privilegios especiales y que se rigen por unas normas ligeramente

128 diferentes: los Umbrella Java Specification Request (UJSR) [5]. Estos son los JSR que definen las tres ediciones de la plataforma: J2SE, J2EE, J2ME y los diversos perfiles de J2ME. Estos JSR paraguas protegen, entre otros, la especificación de la máquina virtual, el lenguaje, y el bytecode. Los cambios en estas especificaciones pueden afectar a la compatibilidad hacia atrás, o a la portabilidad, de las aplicaciones, por ello Sun justifica este trato especial. Cualquier nueva funcionalidad o tecnología que quiera incorporarse a cualquiera de las tres ediciones de la plataforma ha de hacerlo a través de un UJSR. Para que un UJSR sea aprobado debe obtener al menos 5 votos positivos del CE correspondiente, y de los votos emitidos al menos dos tercios han de ser de aprobación. Además el representante de Sun puede vetar la nueva especificación, lo que se traduce en que Sun tiene la última palabra en lo que se refiere a la aprobación de los UJSR, y por lo tanto a cambios sobre J2SE, J2EE y J2ME. No todos los JSR existentes actualmente se rigen por estas normas; como ya hemos comentado, el propio JCP es un JSR que evoluciona y por lo tanto sus normas cambian. En un principio no era tan abierto, no permitiendo, por ejemplo, la implementación de los TC e IR bajo licencias libres. Sun también tenía derechos de veto sobre más JSR, y las implementaciones de las especificaciones estaban obligadas a respetar las posibles patentes que hubiese en las especificaciones, obligación que ya no hay en la actualidad. Algunos JSR todavía se guían por versiones anteriores del JCP, siendo el líder del grupo de expertos el que puede decidir si actualizar o no la versión del JCP. Es de esperar que según estos JSR saquen nuevas versiones de mantenimiento se vayan pasando a la última versión del JCP, más abierta y más respetuosa con el mundo del SL. Finalmente, cualquiera puede implementar las especificaciones, y distribuir su implementación bajo la licencia que considere oportuno. No está obligado a pasar el TC, pero si desea hacerlo, y ha realizado la implementación con ánimo de lucro, ha de pagar a Sun por pasar el TC. Si la implementación ha sido realizada por una organización sin ánimo lucro, como suele ser el caso de los desarrollos libres, el mismo comité de tres personas que decide si las organizaciones sin ánimo de lucro pagan por pertenecer al JCP, decide si ha de pagar o no por pasar el TC. No pasar el TC no implica que una determinada implementación no cumpla especificación, sin embargo es una garantía para sus usuarios de que efectivamente la cumple. 4 Análisis de la libertad de la plataforma Java La plataforma java se construye sobre las especificaciones, recogidas en documentos públicos, y acompañados de una IR y un TC. Normalmente determinar si algo es o no software libre sólo requiere estudiar si se puede o no, y bajo qué condiciones, acceder, modificar y redistribuir su código fuente. En el caso de la plataforma Java hemos de analizar además las especificaciones. Éstas son una clave fundamental en el éxito de la plataforma, ya que permiten la existencia de múltiples implementaciones de cada tecnología, libres y no libres, todas cumpliendo una misma interfaz. Esto evita estar ligado a un determinado producto: si encontramos otro mejor, o que se adapte más a nuestras necesidades, podemos cambiar el actual por el nuevo sin modificar una sola línea de código en nuestro desarrollo, siempre que ambos implementen correctamente las especificaciones, y la garantía de esto es que ambos hayan superado el TC. Las especificaciones también son la base sobre la que se sustenta toda la filosofía de la plataforma, WORA. Sin la seguridad de que las máquinas virtuales de todas las plataformas implementan correctamente la misma especificación, y sin la seguridad de que el formato binario, el bytecode, generado por cualquier compilador, sigue unas mismas especificaciones, no tendríamos garantizado que un binario se podrá ejecutar en cualquier plataforma. Por ello estudiar la libertad de la plataforma no implica sólo estudiar la libertad del software, sino también la libertad de sus especificaciones. Ni FSF, ni OSI han definido criterios para analizar la libertad de una especificación. Si bien los criterios con los que se analiza si un código es SL no son directamente aplicables a las especificaciones, sí podemos analizar su proceso de creación y mantenimiento con la filosofía que hay detrás del SL. En cuanto a la parte software de la plataforma, entendemos que el análisis no debe incluir las implementaciones de terceros, las ajenas al JCP. Hacerlo sería como requerir que, para que un lenguaje de programación sea libre, todos los desarrollos que empleen ese lenguaje sean libres. No obstante nos alegramos de poder afirmar que en la plataforma Java hay implementaciones libres de prácticamente todas las especificaciones, así como multitud de herramientas libres para el desarrollo de software que se han convertido en estándares de facto en la comunidad (Ant, Struts, Hibernate, JUnit, Eclipse, NetBeans ). En este sentido los trabajos [7,8] son un buen repertorio de estas libres de la plataforma Java. 4.1 Libertad de las especificaciones Los documentos que recogen las especificaciones son públicos, estando disponible en Internet en formato PDF. Cualquiera puede descargárselas e implementarlas si así lo desea; esto incluye la especificación de la máquina virtual y bytecode [9], y del lenguaje [10]. Cualquiera puede implementar estas especificaciones, o bien implementar modificaciones de ellas. En Internet hay abundantes proyectos en los que se han implementado, con fines didácticos o científicos, modificaciones de las especificaciones del lenguaje, bytecode y/o máquina virtual Java [11]. Basándose en esto, en algunos trabajos [7] se afirma que las especificaciones de la plataforma java son completamente libres. Acceder a una especificación, y realizar sobre ella las modificaciones que uno quiera no es realmente importante para la plataforma Java, más allá de permitir realizar interesantes experimentos e investigación sobre ésta [11]. Lo realmente importante son las auténticas especificaciones, las que guían la plataforma Son ellas realmente libres?. Siguiendo las ideas del SL esta

129 libertad se traduciría en que cada uno pueda modificar e implementar esas especificaciones sin restricciones, cosa que es cierta y poco relevante para la libertad de la plataforma. Aplicando el sentido común, la libertad exige además que la comunidad Java pueda, en igualdad de condiciones, participar en los procesos de creación, definición, y mantenimiento de estas especificaciones. Como hemos explicado, cualquiera, incluso sin vinculación con una organización, puede tanto proponer una nueva especificación como participar en la creación de ésta. Además cualquier miembro de la comunidad puede descargar y analizar el trabajo que realiza el grupo de expertos de cualquier especificación, y enviar realimentación sobre ella. En este sentido parece que el JCP es bastante libre. Sin embargo el máximo órgano del JCP, el PMO, está compuesto por miembros de Sun. Cada uno de los dos CE del JCP tiene siempre a un representante de Sun, y 10 de sus miembros son propuestos por el PMO, si bien han de pasar una ratificación de la comunidad. Finalmente Sun puede vetar cualquier cambio sobre un UJSR. Sun justifica sus privilegios diciendo que éstos le permiten velar por la compatibilidad hacia atrás, y el carácter multiplataforma de Java. Para ser realmente libre No debería ser la propia comunidad la que decida si quiere o no seguir siendo compatible hacia atrás, o soportar todas las plataformas?. Con esto los autores no estamos diciendo que estemos en contra de estos dos principios, pilares básicos de la plataforma en los cuales, al igual que la inmensa mayoría de la comunidad, creemos y estamos dispuestos a luchar por ellos. Sin embargo no creemos que estos principios sirvan de excusa para permitir a Sun esos privilegios, por más que él haya sido el padre de Java y su protector. Sin igualdad no puede haber libertad plena, por ello el JCP, y por extensión las especificaciones Java, no podrán considerarse completamente libres mientras haya desigualdades en la capacidad de participación de los miembros de la comunidad para gestionar, y para participar en la definición de las especificaciones. Por otro lado, si bien es cierto que por ser un organismo grande y complejo es necesario que haya dentro del JCP una serie de comités ejecutivos que velen por el correcto funcionamiento, e incluso de un órgano semejante al PMO, estos no deberían estar nunca en manos de una empresa (recordemos que el PMO está formado exclusivamente por personal de Sun). Las empresas tienen sus propios intereses, y no siempre son los más adecuados para la comunidad. Por ello el proceso de creación de las especificaciones no debe estar liderado por una empresa, sino por una organización sin ánimo de lucro, lo que nos garantizaría que el JCP velará por los intereses de la comunidad, sin privilegiar intereses particulares. En cuanto a los miembros de los CE deberían ser elegidos democráticamente por los miembros del JCP, pudiendo cualquier miembro del JCP optar a este puesto en igualdad de condiciones, cosa que no sucede ahora, ya que el PMO elige a 10 de los miembros, y al representante de SUN. 4.2 Libertad de las IR y TC En la libertad de las IR se basan actualmente la mayor parte de las críticas realizadas por parte de la comunidad del SL en contra de la plataforma. Esto no deja de ser curioso para los autores, ya que desde nuestro punto de vista lo más importante de la plataforma son las especificaciones, y no sus implementaciones. Quizás el motivo de centrar esas críticas en las IR sea el desconocimiento, por parte de los críticos, acerca del funcionamiento de la plataforma, o quizás sea que los críticos no comparten la filosofía de la plataforma Java, WORA, por lo que no dan tanta importancia a las especificaciones y TC. Actualmente el líder del JSR decide qué licencia emplea para la IR y TC, pudiendo ser una licencia libre si así lo desea. No cabe duda de que la comunidad se beneficiaría si todas las IR fuesen libres, ya que podrían ser empleadas como base para otras implementaciones de las especificaciones, y permitiría una evolución más rápida y eficaz de la plataforma. La IR que más críticas por parte de la comunidad del SL ha generado es, sin duda, la IR de J2SE, el conjunto de herramientas de desarrollo de Sun, conocido como jdk. Este se distribuye bajo licencia Sun Community Source License (SCSL) [12]. Esta licencia no es libre; permite ver el código fuente del jdk, e incluso modificarlo, pero sólo bajo ciertas condiciones, las cuales, en esencia, fuerzan a que el producto modificado siga cumpliendo las especificaciones de la máquina virtual, bytecode y lenguaje Java. Su objetivo es evitar que la plataforma se fragmente por causa de implementaciones del compilador o máquina virtual no compatibles con las especificaciones. Sun afirma que esta licencia toma las ventajas de los modelos de código abierto y propietarios, y elimina sus inconvenientes [12], ya que permite acceder al código fuente libremente, con todos los beneficios que para la comunidad y para la propia plataforma conlleva, siempre que el acceso no atente contra el principio básico de WORA. Sin embargo, una vez que un individuo ha accedido al código licenciado SCSL su licencia le impide participar en proyectos de código abierto, ya que el código que ha visto es propiedad intelectual de Sun, y no puede emplear en proyectos libres lo que en él ha aprendido. Además, si desea cobrar a sus usuarios por el trabajo que ha realizado, está obligado a pagar unas cuotas a Sun. Evidentemente una licencia así dista mucho de poder considerarse libre. Es necesaria una licencia de este tipo para algunas IR, para proteger a la plataforma Java de la fragmentación?. Es una pregunta difícil de responder. Sun afirma que sí; sin ella algunas empresas podrían aprovecharse de su posición privilegiada en el mercado para imponer una versión de la máquina virtual devaluada, o no compatible con las demás. Microsoft en su día desarrolló una versión de la máquina virtual y herramientas de desarrollo que permitían acceder a ciertos servicios de Windows, lo que permitía desarrollar aplicaciones que sólo funcionasen en Windows [13]. Si la plataforma Java hubiese sido completamente abierta nada hubiese podido detener a Microsoft. Hoy en día la plataforma estaría fragmentada; más de la mitad de los desarrolladores Java lo hacen bajo Windows, y probablemente buena parte de ellos emplearían las

130 herramientas de Microsoft. Según Sun, SCSL vela para que esto no suceda. Sin embargo, Microsoft, u otra gran empresa, tienen recursos suficientes para implementar la máquina virtual desde cero, sin necesidad de basarse en ningún código, con lo que esta licencia pierde bastante sentido. Si estas empresas lo desean pueden partir de las especificaciones del lenguaje y máquina virtual [9, 10] e implementar su propia variante de Java sin basarse en ningún código. Danese Cooper, responsable de Open Source Programs Office de Sun, ha tenido múltiples entrevistas con los representantes del Software libre. A ambas partes les resulta evidente que la compatibilidad obligatoria (WORA), y SL no pueden coexistir. Compatibilidad opcional y SL sí podrían existir. Esto es obvio, si entendemos por SL lo que se recoge en [14]. La comunidad de SL acepta en su seno, e incluso promueve y aconseja [15], una serie de licencias que en cierto modo limitan la libertad del usuario del software, a costa de evitar que ese usuario pueda contravenir en algún modo las ideas de los promotores del SL. Son las licencias con copyleft, encabezadas por la GNU GPL, la licencia recomendada por Free Software Foundation para el SL. Esta licencia obliga a que todo proyecto que emplee código GPL se rija también por la licencia GPL. Los autores de este trabajo creemos que la auténtica libertad debe nacer de la libre elección, y no de la imposición, en ese sentido preferimos licencias tipo Apache, o BSD y no la licencia GPL, licencia que obliga a ser libre. Esto no quiere decir que no comprendamos el porqué de la licencia GPL, ni que no nos parezca una licencia adecuada; es un arma que el mundo del SL ha creado para defender sus principios. Aceptaría el mundo del Software libre que la comunidad Java defendiese sus principios del mismo modo?, es decir, se podría considerar libre una licencia que permitiese acceder al código fuente de una IR, sin ningún tipo de restricciones, y modificarlo, siempre que la modificación supere el TC correspondiente. Esta licencia permitiría acceder con total libertad al código fuente, mientras que ese acceso no amenace los principios de la plataforma Java, del mismo modo que una licencia GPL permite acceder con total libertad al código fuente que la posee, siempre que el acceso no amenace los principios del SL. Otra alternativa, que indudablemente el mundo del SL vería con buenos ojos, sería liberar todas las IR con licencias aceptadas como libres, y confiar en la propia comunidad Java para que ésta siga las especificaciones desarrolladas en el JCP, especificaciones creadas con el consenso de la mayoría de la comunidad. Danese Cooper cree que llegará el día en que la comunidad Java sea la que defienda la plataforma contra cualquier posible intento de fragmentación, y que entonces se podrán liberar todas las IR con licencias libres. Los autores de este documento tenemos otra opinión, compartida por James Gosling [16]: creemos que ese día ya ha llegado. Vemos muy improbable que la plataforma Java pueda sufrir una fragmentación, ya que la mayoría de la comunidad no apoyaría esa iniciativa. Buena prueba del nulo interés en fraccionar la plataforma por parte de la comunidad Java son las múltiples implementaciones libres que de J2SE, y otras muchas tecnologías de la plataforma, existentes en la comunidad [7], todas ellas adhiriéndose a las especificaciones. Sin embargo Sun no lo ve así, y consideramos improbable que actualmente esté dispuesto a liberar las IR que de él dependen (entre ellas el polémico jdk) bajo alguna licencia actualmente aceptada como libres por Open Source Iniciative y/o Free Software Foundation. En este sentido quizás la hipotética licencia que en este documento hemos definido fuese un buen punto de encuentro entre las posiciones de Sun y las del SL, o cuanto menos, un paso más de la plataforma Java hacia la libertad completa. En líneas generales los razonamientos aplicados a la IR son extensibles al TC, si bien disponer de su código fuente no tiene más interés que el puramente investigador o académico. La libertad respecto a los TC, además de involucrar su código fuente, debería tener en cuenta también las tasas que hay que pagar para pasarlos. Actualmente las empresas han de pagar, y bastante, para pasar estos test, mientras que las organizaciones sin ánimo de lucro no. Si bien lo ideal sería que los test fuesen gratis para todo el mundo, un organismo como el JCP, en manos de una hipotética organización sin ánimo de lucro, requiere fondos para su subsistencia. El cobro de tasas, a las empresas que vayan a obtener beneficios de sus implementaciones de las especificaciones, por pasar el TC nos parece una fuente de ingresos adecuada. 5 Opinión de Sun Microsystems La opinión de Sun Microsystems sobre la libertad de la plataforma, como organización, es que ciertas partes de la plataforma no deben de ser completamente libres para evitar la fragmentación, y la licencia SCSL y los UJSR son el arma ideal para evitarlo. No se prevé que a corto plazo Sun vaya a cambiar la licencia, por ejemplo, del jdk. Comentaremos, a modo de anécdota, que cuando escribimos este trabajo J2SE 1.5 se encuentra en desarrollo, el JSR que lo está definiendo es el 176, liderado por Sun. La versión del JCP que emplea es la 2.1, una versión de JCP que no permite implementar con licencia libre la IR y TC. Desconocemos si su líder tiene intenciones de actualizar la versión del JCP a la 2.6. Internamente la posición de Sun dista de ser unánime; James Gosling reconoce que el tema de si Java debiera o no ser libre es un debate continuo [16]. Hay quien opina como Danese Cooper, principal responsable de la relación de Sun con el mundo del SL, quien cree que llegará el día en el que Java pueda ser libre y la propia comunidad, y no Sun, vigile por su compatibilidad y portabilidad. James Gosling, el padre de Java, opina que hace más de un año que llegó el día del que habla Danese Cooper [16]. Sin embargo las declaraciones de Jonathan Schwartz, vicepresidente ejecutivo de Sun, dan a entender que Java nunca debería ser libre [17]. Como vemos ambas posturas cuentan con partidarios de peso dentro de Sun. Analizando los hechos, y no las palabras, Sun ha mostrado a lo largo de los años que el motivo de las restricciones que hay en la plataforma es hacer frente a la fragmentación, como sucedió en el caso de Microsoft, y no poner trabas al desarrollo de SL en la plataforma

131 Java. Durante mucho tiempo Apache violó las normas del JCP, pudiendo haber sido demandado por Sun. Lejos de ocurrir esto Apache mantenía una excelente relación con Sun, quien le apoyaba y financiaba en sus desarrollos libres, y todos los problemas se zanjaron modificando el JCP para legalizar las actividades (desarrollo de IR y TC bajo licencias libres) que Apache llevaba tiempo realizando, pero que en ningún modo suponían un riesgo para la fragmentación de la plataforma. Por otro lado, si bien Sun posee privilegios en el JCP, no hay ninguna evidencia de que los haya empleado con otro fin que no fuese proteger la compatibilidad y portabilidad de la plataforma. También es evidente que Sun empuja cada vez más la plataforma Java hacia la liberación: cada nueva versión del JCP libera un poco más la plataforma, siendo un paso más hacia la libertad plena. 6 Conclusiones Es evidente que actualmente no se puede decir que la plataforma Java sea libre. Aunque la mayor parte de las críticas realizadas desde fuera de la plataforma en este sentido se dirigen hacia las licencias de las IR, en especial a IR del JSR que define J2SE, nosotros identificamos como más grave la falta de libertad plena en la creación y mantenimiento de las especificaciones de la plataforma. La rescisión de los privilegios de Sun, así como la gestión del JCP por una organización sin ánimo de lucro, evitando así que posibles intereses particulares de una empresa puedan llevar el JCP por el camino que no conviene a la mayor parte de la comunidad, son condiciones necesarias para lograr la libertad de la plataforma. En cuanto a las IR y TC, la comunidad se beneficiaría si se pudiese acceder al código fuente de éstas, para basar en ese código sus propias implementaciones de la especificación, así como para poder participar activamente en el avance y corrección de bugs de las IR. Es poco probable que esto supusiese un riesgo de fragmentación en la plataforma: las implementaciones libres que la comunidad Java ha realizado hasta la fecha tratan de adherirse a las especificaciones, lo cual muestra un nulo interés de la comunidad del SL por fragmentar la plataforma. Por otro lado el protagonista del único intento de fragmentación en la historia de la plataforma, Microsoft, actualmente apuesta por una tecnología similar a Java, pero paralela,.net, y es poco probable que en estas condiciones retomase Java y volviese a intentar fragmentar la plataforma. Una forma de evitar el riesgo de fragmentación, sería proteger estas IR con una licencia que permitiese el libre acceso y la modificación del código fuente siempre que el nuevo software pasase el TC correspondiente. No tenemos claro si la comunidad del SL aceptaría esta licencia como libre, licencia que protege la filosofía de Java, WORA, del mismo modo que la licencia GPL protege la de esta comunidad. Esta licencia sería más fácilmente aceptada por Sun que cualquier licencia considerada como libre por la comunidad de SL, y aún cuando esta licencia no fuese aceptada como libre, siempre sería un paso más hacia la libertad plena. En cuanto a Sun, hemos de reconocer que a pesar de ser el principal responsable de que Java no sea libre, hasta la fecha ha mostrado un buen criterio en la aplicación de sus privilegios, lo que hace que asociaciones como Apache, Blackdown, Kaffe, o javahispano, asociaciones con una notable afinidad por el SL, defiendan y trabajen por la plataforma Java. Sin embargo esto no excluye que deseemos seguir caminando hacia la libertad total de la plataforma, y que esperemos que la opinión de gente como James Gosling se acabe imponiendo a la de Jonathan Schwartz, y Sun libere completamente la plataforma. Bibliografía: [1] Free Software Foundation. [2] Open Software Iniciative. org. [3] Bill Venners. Inside the Java Virtual Machine. McGraw-Hill Osborne Media, [4] Java Community process. [5] JCP v /communityprocess/first/jsr215/jcp2_6.pdf. [6] Java Specification Request. en/jsr/overview [7] A. Molpeceres y M. Pérez. Java y Software Libre, Realidad o Ficción?. javahispano. org/articles.article.action?id= [8] A. Molpeceres y M. Pérez. Arquitectura empresarial y SL, J2EE. javahispano.org/articles.article.action?id= [9] Tim Lindholm y Frank Yellin. The JavaM Virtual Machine Specification. Addison Wesley [10] J. Gosling, B. Joy, G. Steele, G. Bracha. The Java Language Specification. Addison Wesley. [11] Modificaciones de las especificaciones de la máquina virtual, lenguaje, y bytecode. [12] Sun Community Source License (SCSL). [13] Declaración de James Gosling en el juicio contra Microsoft por violar las especificaciones de la JVM. [14] Free Software Foundation. Free Software Definition. [15] R. Stallman. Why you shouldn't use the Library GPL for your next library. [16] Entrevista a James Gosling. development/java/story/0,10801,82109,00.html. [17] Entrevista a Jonathan Schwartz. /development/java/story/0,10801,82286,00.html

132 El Papel del Integrador en el Software Libre Miguel Hormigo Ruiz Director Delegación Regional Sur Soluciones Globales Internet, S.A. (Grupo GMV) Antes de entrar en detalles sobre el contenido de mi ponencia, me gustaría dar la definición que la Real Academia Española da a la palabra integrar : completar un todo con las partes que faltaban. Hacer que alguien o algo pase a formar parte de un todo. Teniendo en mente esta definición, el integrador se puede considerar de manera recursiva como un generador de valor que une las piezas que dan sentido a un todo y genera en una pieza más aprovechable por el bienhechor. El integrador es un ente que tiene la necesidad de comprender cada una de las piezas y desarrollar otra pieza cuyo valor es la suma del esfuerzo en agregar las piezas unitarias más la nueva pieza generada. Esta idea de construcción e ingeniería está íntimamente relacionada con el Software Libre desde su nacimiento en cuanto al concepto de modularidad, simplicidad, ahorro de costes y beneficio para el cliente final. La integración asociada al concepto de ingeniería nos muestra la necesidad de aportar metodologías y procesos que generen los productos y soluciones deseados, y es aquí donde las empresas de integración añaden adicionalmente las cualidades necesarias para ofrecer servicios especializados en cada sector de actividad conjuntamente con el Software Libre. En definitiva, el integrador es uno de los engranajes clave para que el mundo del Software Libre crezca y se desarrolle acorde a las necesidades de un mercado en amplia expansión pero muy exigente en dos parámetros básicos: el tiempo y la calidad. La

133 tecnología avanza muy deprisa y es necesario ser capaz de absorber lo mejor de ella generando soluciones con igual o mayor calidad que lo puedan hacer los productos comerciales. Aunque anteriormente se han esbozado puntos en común entre el integrador y el Software Libre, me gustaría incidir más en este punto. Se puede considerar que esta relación tiene que construirla el Mercado en el que van encajando las piezas para construir un modelo económico que aporte valor a cada una de las partes que lo forman. El buen integrador tiene el objetivo constante, independientemente de si el software es libre o no, de ocupar la posición deseada en el mercado y para ello, teniendo en cuenta el modelo de software libre tiene que utilizar el modelo de negocio, que Raymond en su Caldero Mágico denomina Regale la Receta y Abra un Restaurante junto con una serie de alianzas en procesos, metodologías de calidad y experiencia en las tecnologías aplicadas en su sector de actividad. En este caso, el buen integrador se puede asemejar conjuntamente a las tres figuras que se muestran a continuación: - Equipo de Fútbol: el equipo de integradores debe constituir un conjunto sincronizado al mínimo detalle, organizado para llevar a cabo el trabajo deseado y liderado con una figura de referencia como director de proyectos. - Grupo de Música: el integrador debe estar en el mercado, es decir, temporalmente generar soluciones de valor que se reconozcan por la comunidad y aumenten su valor. - Dirección de una Película de Cine: el integrador debe volcarse en cada proyecto que realiza como si fuese su obra cumbre y considerarla como tal. Estas tres aproximaciones anteriores no son suficientemente explotadas tanto por el mercado como por el integrador aunque se observa cada vez un acercamiento mayor a

134 esta postura, en el que, por ej. empresas pequeñas o medianas son capaces de competir en igualdad de condiciones con empresas multinacionales, teniendo como principal valor la experiencia de sus equipos de trabajo. En cuanto a la relación entre el Integrador y el Software Libre, ésta debe ser pragmática en el sentido de que el integrador es la entidad encargada de unir piezas más pequeñas para hacerlas funcionar conjuntamente. No se debe perder en la inmensidad de cada una de las piezas, sino que su función es, primero, adquirir las mejores piezas; segundo, unirlas con su experiencia y metodologías para crear la nueva pieza deseada. El Software Libre proporciona al integrador los elementos necesarios para sustentar su fin ya que le da la posibilidad de aportar su buen hacer para crear, innovar y aportar. En este sentido, el Integrador ha convivido desde siempre con el concepto de Software Libre ya que sus productos, o mejor dicho, sus soluciones han sido traspasadas al mercado con todas sus consecuencias, incluido el código. El integrador aporta la garantía de privacidad al mercado ya que las soluciones son totalmente transparentes. El integrador se identifica plenamente con el Software Libre teniendo en cuenta que este último clasifica al software como un servicio y no un bien adquirible. De esta manera se considera que el concepto de valor de venta del software no tiene sentido, en contraposición al valor de uso que es por el que se valora realmente la aportación del integrador. Este concepto radicaliza la forma de comercializar los servicios del Integrador, es necesario que el mercado valore el esfuerzo, los conocimientos adquiridos y la experiencia de un buen Integrador, algo que no sucede siempre. Por otro lado es necesario que el Software Libre no se fagocite a si mismo y no muera de éxito, hay que comprender los modelos de negocio con los que actuar para generar economías válidas y proporcionar un desarrollo sostenible. En muchos mercados, el concepto de Software Libre se identifica como gratis lo cual es un gran error, si esto

135 fuese así ya estaría completamente degradado y haría años que hubiese sucumbido. El Software libre se tiene que identificar con otros valores más sutiles como son: - La defensa del derecho a la información - La independencia ante poderes económicos e intereses comerciales - La búsqueda de metodologías alternativas a los desarrollos tradicionales De tal manera que se le reconocen beneficios tales como: - privacidad (es posible realizar auditorias de código para detectar código malicioso) - enriquecimiento tecnológico - escalabilidad - productividad - interoperatividad - calidad, etc... En consecuencia es preciso que el mercado asuma completamente que el valor del Software Libre está en el uso o la importancia como herramienta y no en la venta, ya que el concepto de producto desaparece. Para que el Software Libre llegue a su estado de madurez debe desaparecer el concepto de licencia ya que ésta se tiene que considerar un bien higiénico o valor de por sí. Por el mismo motivo el concepto de patente, tal como lo conocemos hoy en día, no tiene sentido de tal manera que se tiene que valorar el avance tecnológico como apuntalamiento. La principal ventaja o valor que aporta consiste en bajar los costes sino en disminuir riesgos. El Integrador se incorpora en este modelo proporcionando el desarrollo sostenible, ya que, tanto éste como, el mercado no tiene que olvidar que su objetivo es obtener beneficios desarrollando un modelo constructivo piramidal sin vértice. Debe generar valor sobre una base firme obteniendo

136 resultados que generan beneficios una sola vez, adquirir experiencia, mejorar la calidad de los resultados obtenidos e innovar tecnológicamente en el siguiente desarrollo. Ante esto se abren nuevas puertas en las que la globalización ha tenido mucho que ver. El acceso a una cantidad de información ilimitada no significa gran calidad en el conocimiento, es por ello, que no hay que confundir Sociedad de la Información con Sociedad del Conocimiento ya que ésta es un fin último (inalcanzable por así decirlo) de la primera y el Integrador debe comprender que su valor está en el grado de conocimiento con respecto a la información suministrada. En consecuencia el beneficio que debe obtener es directamente proporcional a la capacidad de adquirir conocimiento específico sobre una tecnología, y saber aplicarlo no necesariamente sobre la capacidad de venta de dicho conocimiento. Por último, es necesario recalcar desventajas, malas interpretaciones y degradaciones de conceptos relacionados con el Software Libre y sobre todo hacer hincapié en evitar la radicalización del Software Libre que como queda patente tiene un gran futuro que hay que cuidar. El Software Libre no debe confrontarse con Software Comercial, hay que ir más allá y observar que el resultado puede ser tan bueno en un caso como en otro, es preciso observarlos como modelos de negocio alternativos y que sea deseable que sigan conviviendo. El mercado es el que dicta el valor de un bien o servicio, ya sea comercial o de libre distribución y en ese sentido las empresas generadoras de software comercial tienen aún mucho que decir y a la vez que están haciendo un esfuerzo por adaptarse a las nuevas formas de trabajo, bien abriendo sus fuentes poco a poco, bien participando de alguna manera en los nuevos mercados. Actualmente es difícil creer que se vuelvan a generar los monopolios de los años ochenta y noventa sino más bien una interoperatividad y homogeneización en todos los sentidos en consecuencia se debe confluir hacía estándares de facto. Si hacemos un ejercicio de memoria, hay que tener

137 en cuenta que el Software Libre tal como lo conocemos actualmente, no ha inventado nada relevante, aunque está explicando al usuario que no tiene sentido el modelo económico impuesto. Al contrario, las empresas de software comercial han desarrollado la tecnología que conocemos actualmente aunque se han extralimitado tanto que han hecho necesario que nos planteemos otros modelos económicos alternativos. En un futuro se hará necesario una convergencia y un alineamiento, se debe calcular el verdadero valor de coste del software y la gran capacidad de avance tecnológico del Software Libre debe apostar por un mundo mejor en el que el usuario tenga más libertad, seguridad y calidad. Me gustaría finalizar con una frase de Arthur C. Clarke que Eric S. Raymond utiliza en su fenomenal artículo El Caldero Mágico que se adapta perfectamente a las cualidades necesarias del Integrador: Cualquier tecnología suficientemente avanzada es indistinguible de la magia. Miguel Hormigo Ruiz.-

138 SUSE LINUX ENTERPRISE SERVER: CARRIER GRADE linux Y DATA CENTER LINUX Rafael Grimán Canto Maxfeldstrasse 5 D Nürnberg Germany rgriman@suse.it 1. Qué es Linux Linux, como bien se sabe, es un sistema operativo que nació en el año 1991 de las manos de Linus Torvalds. Apoyado por la comunidad GNU y OpenSource ha avanzado muchísimo y ha conseguido entrar en las empresas a pesar de ser software desarrollado por una comunidad de programadores y no por una empresa. La licencia principal bajo la cual se distribuye Linux, la licencia GPL, nos permite utilizar libremente dicho sistema operativo. Qué significa libremente? Libremente significa que podemos: instalar linux en tantos equipos como querramos modificar su código fuente aprender de su código fuente redistribuir dicho código Muchas veces se piensa que esto repercute negativamente sobe el autor original. Esto no es correcto pues la licencia GPL nos obliga a respetar al autor original en todo momento. Como podemos observar, en las licencias tradicionales de software, se protege únicamente al autor quedando el usuario desprotegido y sometido al autor original. En este caso, se respeta tanto al autor original como al usuario final.

139 2. Historia de Linux en las empresas Linux fuen entrando poco a poco en las empresas gracias a su gran parecido a los sistemas operativos UNIX y a su licencia. Al principio entró en las Universidades y centros de investigación debido a que se podía estudiar su códgo y modificarlo. Gracias a esto se le fueron añadiendo carcterísitcas propias de otros sistemas operativos, características como: servidores de impresión servidores de correo, web y ftp servidores de ficheros Los primeros pasos que dio Linux en la empresa fue para implementar dichos servicios. Eran servidores no críticos. Poco a poco se ha ido dotando a este sistema operativo de más capacidades y más prestaciones como pueden ser: clústering sistemas de ficheros journaling soporte para diferente hardware Gracias a estas nuevas características Linux ha podido ir escalando dentro de la empresa y tomando papeles cada vez más críticos dentro de las empresas. 3. Futuro de Linux en las empresas Cada día vemos más empresas y más proyectos basados en Linux. Actualmente las empresas saben que Linux es un buen servidor de ficheros, un buen servidor web, un buen servidor de correo. También están viendo que se le está dotando de características propias de otros sistemas operativos utilizados en sistemas de misión crítica como pueden ser grandes bases de datos de bancos o compañías de telefonía. Debido a esta posibilidad de añadir fácilmente nuevas características, muchas empresas han optado por Linux en sus centros de proceso de datos, en sus aplicaciones de misión crítica,... Muchos grandes fabricantes han decidido apostar por Linux fundando un laboratorio que permita que Linux tenga esas características demandadas por sus clientes. Este laboratorio denominado OpenSource Development Labs (OSDL)

140 está patrocinado por empresas como: SUSE LINUX AG, IBM, HP, Alcatel, CISCO, Fujitsu, Nokia, Novell,... De OSDL han salido dos grandes proyectos: Data Center Linux: cuya meta es dotar a Linux de todas aquellas necesidades y capacidades que requieren las empresas en sus centros de proceso de datos. Carrier Grade Linux: debido a la gran demanda de conectividad que hay hoy en día, se está produciendo un gran cambio en dichos mercados, cambio que difícilmente pueda hacer frente una empresa de telecomunicaciones sola. De ahí que haya un esfuerzo común para dotar a Linux de dichas capacidades. 4. Data Center Linux Las grandes instalaciones de Tecnologías de la Información se están dando cuenta que necesitan cada vez más recursos para manejar la ingente cantidad de datos que tienen. Esto requiere cada vez más el desembolso de sumas desorbitadas de dinero. No sólo eso sino que el mantenimiento es cada vez más difícil y la posibilidad de decidir libremente cómo manejar la información es cada vez menor. Debido a esta situación, se piensa más en Linux. El objetivo es dotar a Linux de las caracterísitcas que no tiene para poder implementarse perfectamente en los grandes centros de datos de las empresas. Obviamente los requerimientos de los grandes centros de datos varían en función del segmento de mercado en el que se encuentran. Podemos definir los siguientes segmentos de mercado: finanza fábricas educación sanidad Debido a esto se ha decidido empezar por uno de los cuatro segmentos mencionados en función de la adopción de Linux en dicho mercado, uso de nuevas tecnologías,... Dicho segmento es el de las finanzas. Se ha definido una arquitectura dentro de este segmento que es la siguiente: Infraestructura de red: aquí encontramos servicios de DNS, cortafuegos,...

141 Capa de presentación y hosting web: encontramos servicios como servidores web, servidores de correo,... Servidores de aplicaciones: encontramos tecnología como Java, J2EE,... Bases de datos: aquí encontramos data warehousing, bases de datos transaccionales,... Almacenamiento: se estudian las necesidades de conexión entre servidores y sistemas de almacencamiento. Esta arquitectura necesita que Linux presente una serie de mejoras: Administración Fiabilidad, Servicio, Disponibilidad Rendimiento Estándares 5. Carrier Grade Linux Carrier Grade Linux es una nueva categoría de Linux, más robusta que ofrece una plataforma estándar a las empresas de telecomunicaciones. El mercado al que se quiere ofrecer CGL es: Telefonía móvil Internet y servidores de aplicaciones Telefonía fija Equipos de comuncación empresariales VPNs Hay tres tipos de aplicaciones que se van a soportar: Gateways: actúan como pasarela entre dos tecnologías, suelen gestionar un gran número de conexiones en tiempo real. Signaling Servers: gestiona todas las rutas y el estado de las conexiones, suelen requerir un tiempo de respuesta de unos 80 milisegundos. Management Servers: gestionan la red, los clientes y los servicios. Para diseñar una especificación efectiva para las tres aplicaciones menscionadas anteriormente, se deben definir una serie de categorías: Seguimiento de estándares: SNMP, LSB, POSIX,... Requerimiento de la plataforma: hot-swap, arranques remotos,...

142 Disponibilidad: dotar a Linux de capacidades de alto rendimiento, como journaling, RAID-1, Volúmenes Lógicos,... Servicios: monitorización de recursos, alarmas,... Herramientas: depuradorrs para el kernel, herramientas de análisis de volcados del kernel,... Rendimiento: caracterísitcas como respuestas en torno al milisegundo, RAID-0,... Seguridad: no se ha definido, pero se ha tenido en cuenta para un futuro cercano.

143 Día h Sesión Auditorio: Software Libre en el Mundo Moderador José Carlos Alarcón Participantes Elizabeth Gordon-Werner Hugo Lueders David Evans Danese Cooper Marta Pérez Cuso José Cruz Cedillo Secretario General para la Sociedad de la Información de la Junta de Andalucía. NSW Department of Commerce- Australia Representante de initiative for Software Choice NERA USA Open Source Initiative USA Unctad. United Nations CINVESTAV-IPN-México

144 PSTEPS TO ASSIST TRANSITION TO OPEN SOURCE SOFTWARE E. Gordon-Werner 1 1 of Information and Communications Technology, NSW Department of Commerce, Australia Elizabeth.Gordon-Werner@commerce.nsw.gov.au The New South Wales (NSW) Open Source Project was established in mid 2002 by the Office of Information and Communications Technology, a branch of the NSW Department of Commerce which has responsibilities including fostering the move to egovernment and promulgating open standards The project currently has over 70 members from 50 NSW Government agencies and is focusing on facilitating communication and developing a toolkit to assist in the assessment and implementation of open source software (OSS). The toolkit includes: Open Source Software Products and Services in NSW,a report which lists a) locally available OSS products and commercial software that operates on OSS platforms catagorised by application (collaborative/workgroup software, content management/ web development, communication, databases, graphics, internet infrastructure, virus scanning, spam filtering, network and server monitoring, messaging/mail/web browsing/office systems and other miscellaneous systems); b) open source platforms, management and migration tools and c) local companies offering open source services and expertise. Total Cost of Ownership Template and Report, to assist cost and compare software products. The template was designed to be used not only to cost full IT solutions (to support business cases) but to compare alternative software packages which differ only in some details. It includes line items such as re-usability of source code. A report on industry use of OSS and on OSS training opportunities in NSW. The compatibility of two desktop suites was tested and the report is being used to produce a plain-english guide for NSW agencies using both the MS Office and StarOffice desktop suites. Among initiatives currently underway are a website at to facilitate communication and information sharing. Four Case Studies are also being prepared to document the experiences of NSW Government agencies with OSS. These Case Studies will assist others moving to use OSS. The reports, templates and future plans for the project will be discussed.

145 The NSW project is keen to share its products and knowledge with others and would welcome contact with other government groups with software, reports or experience to share. Keywords: Open Source, TCO, NSW, Government

146 Día h Sala 1: Tecnología abierta Moderador Jerónimo Moreno. Participantes Antonio Pedro Serrano Álvarez Silvia Soriano Agustín Torres- Ternero Álvaro Haya Oscar Gómez Prieto Antonio Luque José Jesús Chaso Juan A. Prieto Director General Cofiman Junta de Andalucía Silicon Graphics SADESI, SAU. Cassfa Telvent Universidad de Sevilla DMR Consulting XimetriX

147 Directorio Corporativo de la Junta de Andalucía: una experiencia de implantación con OpenLDAP para grandes volúmenes A. Torres-Ternero Alvarez 1, J Salmeron 2, L. Romero 1 1 SADESI, España, 2 C. de la Presidencia, Junta de Andalucía, España. agustin.torres@juntadeandalucia.es Resumen Este documento describe la arquitectura implantada para el desarrollo del Servicio de Directorio Corporativo de la Junta de Andalucía. El diseño de esta arquitectura e implantación del servicio se ha enfrentado a problemas derivados de la gestión masiva de usuarios, así como a elevadas cargas de trabajo. Todo ello ha definido la actual arquitectura como una solución caracterizada por su alta fiabilidad, elevadas prestaciones y caracter distribuido. 1. Introducción Con la puesta en marcha en el año 1999 de la Red Corporativa de la Junta de Andalucía se puso en marcha un proceso de profunda reestructuración de los cimientos telemáticos y de comunicaciones de la administración andaluza, siendo una de las principales acciones la constitución de una red de datos dotada de grandes anchos de banda internos que abre la puerta a un amplio rango de servicios de valor añadido. Entre estos servicios destaca el servicio de Correo Corporativo. Como elemento esencial de este proyecto surge la necesidad de implantar un servicio de directorio que proveyera de soporte a toda la información necesaria para el sistema de correo. La asociación del Servicio de Directorio Corporativo con una herramienta tan esencial como es el uso del correo electrónico dentro del marco de una gran organización se ha plasmado en los siguientes requisitos funcionales del servicio: Disponibilidad. El sistema ha de contar con una alta tolerancia a fallos hardware y software, teniendo en cuenta la redundancia de elementos críticos y cuellos de botella (bottlenecks) Rendimiento. El servicio ha de ser capaz de dar soporte a una elevada demanda de peticiones, del orden de varios millones al día, manteniendo una calidad de servicio óptima.

148 Seguridad. El servicio ha de proteger la información sensible almacenada contra ataques o usos indebidos. Escalabilidad. La magnitud en el número de peticiones puede cambiar sustancialmente con la integración de nuevos servicios, por ello la arquitectura debe ser fácilmente ampliable. Caracter marcadamente distribuido. El amplio ámbito geográfico y la dispersión de los usuarios hacen necesario el potenciar la distribución del servicio. 2. Arquitectura física del servicio La arquitectura final implantada para el servicio se basa en la utilización de la tecnología desarrollada en el proyecto OpenLDAP [1]. Dentro del análisis de herramientas y posibles soluciones para la satisfacción de los requisitos funcionales del servicio, OpenLDAP destaca no sólo en los apartados de prestaciones y rendimiento, sino que además su caracter de proyecto de fuente abierta se encuentra acorde con las directrices recogidas en el decreto 72/2003 que la Junta de Andalucía ha articulado en su avance hacia la Sociedad del Conocimiento y la Información [2]. La Figura 1 muestra la arquitectura física final desarrollada e implantada para este servicio. Figura 1 Arquitectura del Servicio de Directorio Corporativo de la Junta de Andalucía La arquitectura está formada por un conjunto de nodos especializados, los cuales implementan ciertos requisistos funcionales del proyecto.

149 El núcleo del servicio lo constituye el nodo de escritura (E), único elemento no redundado del sistema. Este nodo recibe las peticiones de actualización de datos por parte de los clientes (C) a través de una capa software denominada Interfaz de Administración (IdA). Esta capa software, que toma la forma de una aplicación cliente, una aplicación web y un conjunto de bibliotecas en lenguaje Java, forma parte del efecto de caja negra que sobre el sistema se trata de imponer en relación a la utilización del mismo por parte de los usuarios finales. La existencia de la Interfaz de Administración distribuye el centro de gravedad de la seguridad del sistema, entre los mecanismos de seguridad propios del servidor y la propia capa de software. Esta última permite crear mecanismos de autorización personalizados, robustos y ajustados a las necesidades específicas del proyecto, que complementan los incluidos en el propio software del servidor, resolviendo la componente de seguridad buscada por el proyecto. Los cambios realizados sobre el nodo de escritura (E) son trasladados a los nodos de lectura (L) usando para ello los mecanismos de replicación implementados en el servidor (slurpd). Estos nodos se destinan a la resolución de las peticiones de lectura de datos realizadas por los clientes (C). Para ello los nodos se encuentran agrupados bajo un elemento hardware (D), encargado del balanceo de la carga mediante la implementación del algoritmo de distribución de peticiones óptimo a las necesidades del servicio. Los clientes acceden por tanto al servicio a partir de una única dirección publicada. De esta forma se garantiza su escalabilidad ante un aumento de las peticiones por parte de los clientes, por el simple método de agregar más nodos de lectura. La fiabilidad del sistema es controlada en sus dos vertientes: OpenLDAP potencia la creación de servicios altamente fiables gracias, entre otras características, a la calidad de su código. Por otra parte la redundancia de los elementos de la arquitectura permite una alta tolerancia a fallos. En este sentido hay que destacar que el caracter de especialización de los nodos se consigue con una combinación de configuración y gestión de las conexiones. Por ello la reconversión de un nodo desde un determinado rol a otro cualquiera se realiza en un tiempo límite, llegando a poderse automatizar para evitar retrasos innecesarios. Los cambios realizados sobre el conjunto de datos también son trasladados a un nodo especializado denominado 'servidor de réplicas' (SR) usando los mecanismos de replicación integrados en el software del servidor (slurpd). Este elemento se encarga de la retransmisión de los cambios a las diferentes réplicas externas (X) a la organización, de nuevo usando los mecanismos de replicación

150 comentados. Estos nodos de servicio son locales a cada uno de los departamentos u organismos de la organización. Cada uno de ellos almacena el conjunto de datos propietarios de cada organismo. De esta forma logramos un proceso diferido de consulta por parte de los clientes (C), o aplicaciones locales a cada organismo, integradas en el sistema. Una primera etapa del proceso consistirá en la petición de datos al nodo local de cada organismo, agilizando las peticiones y potenciando la seguridad en las comunicaciones al no viajar estas por la intranet de la organizacion. Únicamente cuando los datos requeridos no se encuentren en esta copia local de los datos, la petición se realizará al servicio centralizado. Esta parte del diseño del servicio potencia el caracter distribuido del mismo, elevando su rendimiento, gracias al caracter local de las peticiones, y potenciando la fiabilidad del sistema al contar cada organismo con una copia de los datos de los cuales son propietarios. 3. Arquitectura lógica del Servicio En la definición de la arquitectura lógica se definen las características poseídas por la información almacenada en el servicio. Aunque el estándar [3] diferencia en un servicio de directorio LDAP dos componentes principales: el modelo de protocolo y el modelo de datos, trabajos posteriores [4] han dividido el servicio en cuatro componentes diferentes: los modelos de datos, funcional, de seguridad y de nombrado. En el diseño de esta arquitectura se ha seguido esta última división. El modelo de datos trata sobre la estructura y tipos de datos necesarios para la construcción del árbol del servicio. En la definición del modelo de datos hay dos tareas principales: la definición de los datos que el servicio almacenará y la definición del esquema que estos datos implementarán. Para el caso del Servicio Corporativo de la Junta de Andalucía, su evolución inicial como proyecto asociado al Servicio de Correo Corporativo marcó el conjunto de datos a aquellos relacionados con la información personal de los usuario y el rutado del correo electrónico por los diferentes nodos de la pasarela y nodos de almacenamiento. Tambien se incluyó información referente a usuarios especializados (administradores), organismos dados de alta en el sistema y otros recursos como edificios, servicios, etc. En relación a los esquemas de datos implementados, en el proyecto siempre se ha intentado seguir los esquemas estándares implementando esquemas propietarios únicamente cuando no existían soluciones ya implementadas o las que existían no se adecuaban a las necesidades del proyecto.

151 El modelo funcional define todas aquellas operaciones que interactuan con los datos almacenados en el servicio. El modelo funcional implementado por el servicio coincide totalmente con el modelo funcional definido en el proyecto OpenLDAP, el cual divide las operaciones sobre los datos en tres grupos diferenciados: operaciones de consulta, que permiten realizar búsquedas en el servicio y recuperar los datos obtenidos, operaciones de actualización, las cuales implementan las operaciones de borrado, inserción y modificación de los datos almacenados, y operaciones de autenticación y control, las cuales llevan a cabo los procesos de autenticación por parte tanto de los clientes como del propio servicio, así como el control de ciertos aspectos de la sesión establecida entre ellos. El modelo de seguridad provee al servicio de mecanismos de protección en una doble vertiente: orientado a los clientes y orientado al servidor. Los primeros permiten a los usuarios la presentación de su identidad (autenticación). Los mecanismos orientados al servidor permiten controlar el acceso a los datos por parte de los usuarios previamente autenticados (autorización), distinguiendo a los usuarios normales de aquellos usuarios especializados en la gestión y administración del sistema. Finalmente el modelo de nombrado define como son almacenados los datos en la estructura árbol del servicio. La estructura desarrollada para el proyecto se ha basado en la estructura estándar de estos sevicios con algunas modificaciones. Se han definido ramas en la estructura para el almacenamiento de los datos referidos a los empleados de la organización, para los organismos y entidades dados de alta, para los usuarios especializados en la administración del servicio y para las aplicaciones integradas en el mismo. Finalmente se ha definido una meta rama para el almacenamiento de los meta datos referidos al servicio. La meta rama ofrece funcionalidades de diccionario de datos del servicio y constituye una de las fuentes de información sobre el servicio de caracter dinámico más importantes del mismo. 4. Conclusiones El desarrollo e implantación del Servicio de Directorio de la Junta de Andalucía surge como un proyecto complementario al Servicio de Correo Corporativo. A partir de aquí, las posibilidades del proyecto y la flexibilidad del diseño del mismo han potenciado la integración de sistemas y servicios que inicialmente no estaban previstos. En la actualidad los servicios integrados no sólo abarcan los relacionados con el Correo Corporativo (rutado de mensajes de correo electrónico, autenticación de clientes IMAP y POP, autenticación de

152 usuarios en su acceso al Servicio de Webmail Corporativo) sino que diferentes sistemas han sido conectados, entre otras cosas para centralizar la autenticación en el servicio, bien vía LDAP o bien mediante la utilización de plug-ins como PAM para la autenticación a través de diferentes servicios (IMAP, POP, etc.) La definición de un protocolo de intercambio de datos con las aplicaciones de gestión de recursos humanos de la organización ha automatizado la carga y borrado de los usuarios, potenciando el caracter de meta directorio del servicio, caracter ampliable en un futuro no muy lejano con la integración de otros servicios fuentes de datos, como los relacionados con el personal docente adscrito a la organización. En todas estas cuestiones OpenLDAP ha representado un papel preponderante. Una veces gracias a su flexibilidad, otras gracias a sus elevadas prestaciones o a los mecanismos de seguridad implementados en el mismo, OpenLDAP se ha convertido en uno de los referentes de esta tecnología dentro de la organización, siguiendo un desarrollo paralelo a su auge internacional como servicio de directorio por excelencia en sistemas abiertos. 4. Referencias [1] [2] Consejería de la Presidencia, Decreto 72/2003, de 18 de Marzo, de Medidas de Impulso de la Sociedad del Conocimiento en Andalucía. BOJA 55, Junta de Andalucía, Marzo [3] M. Wahl, T. Howes y S. Kille. Lightweight Directory Access Protocol(v3). RFC 2251, IETF, Diciembre [4] T. Howes, M. C. Smith y G. S. Good. Understanding and Deploying LDAP Directory Services. Prentice-Hall, 2003.

153 ABSTRACT PLATAFORMA DE GESTORES DE CONTENIDO EN SOFTWARE LIBRE Ponente: Día: Álvaro Haya (CASSFA) Jueves 19, Sala 1, Mañana 1. Introdución: qué es un gestor de contenidos? Requisitos que debe cumplir Gestión documental Versionado WorkFLow (procesos de publicación) Categorización de los contenidos Ciclo de vida de los contenidos Deshacer cambios Sistemas de Búsqueda Múltiple criterios de ordenación Soporte para Metadatos Seguridad Autenticación Granuralidad de privilegios Herramienta de administración Soporte transacional Soporte SSL 2. Ventajas de uso de una herramienta de SFA para la Gestión de los contenidos 3. Panorámica de gestores de contenido de SL. Visión tecnológica Plataforma Servidor de aplicaciones Sistema Operativo Servidor Web Base de Datos Lenguajes De desarrollo Leguaje de lógica de negocio Separación del contenidos de la lógica Procesos de composición de páginas XML Presentación según canal Importación / Exportación XML XSLT Modularidad Interfaces de comunicación Fuentes de datos externas Sites Virtuales Cache

154 Balanceo de carga Alta disponibilidad 4. Ámbito de aplicación de cada gestor de contenidos a. Tamaño de la Web b. Tecnología c. Web colaborativa d. Exportación / 5. Independización de los contenidos de la publicación. Publicación en Base a estándares a. Mecanismos de separación de la gestión de los contenidos de la Publicación b. Herramienta de publicación Cocoon c. Integración de Gestores de contenidos con herramientas de publicación Cocoon d. Un ejemplo de integración OpenCMS Cocoon. e. Servicios Web 6. Unos ejemplos prácticos a. Intranet del IAJ (PHPNuke) b. Web de la Consejería de Gobernación (OpenCMS) c. Andaluciajunta.es (OpenCMS Cocoon).

155 Ponencia Antonio Luque SISTEMA DE SIMULACIÓN PARA UN MICROCONTROLADOR ELECTRÓNICO BASADO EN LAS HERRAMIENTAS DE DESARROLLO GNU J. M. Benítez, A. Luque Departamento de Ingeniería Electrónica, Universidad de Sevilla, Spain En este artículo se presenta un entorno modular de simulación de sistemas electrónicos construidos alrededor de un microcontrolador. A partir de unas herramientas que propociona el depurador GDB, se han desarrollado simuladores de periféricos y de dispositivos electrónicos simples que pueden conectarse a un microcontrolador. Se describe la arquitectura general del sistema, que consta de: simuladores de periféricos, simuladores de módulos externos, interfaz de usuario, y sistema de comunicaciones entre las partes. Palabras clave: microcontrolador, simulación, GDB, periférico. 1. Introducción Los microcontroladores son las piezas fundamentales de los sistemas empotrados, que en los últimos tiempos se han convertido en casi ubicuos. Un microcontrolador es un dispositivo electrónico parecido a un microprocesador, pero más completo que éste en muchos aspectos. Al igual que un microprocesador, un microcontrolador (uc) posee una unidad aritméticológica (ALU), y una serie de registros internos. Estos elementos forman la unidad central de proceso (CPU). Un microprocesador no contiene nada más (salvo quizá memoria de almacenamiento), pero un microcontrolador integra en el mismo circuito integrado una serie de periféricos, que lo dotan de funcionalidad completa. Estos periféricos son, por ejemplo, contadores, puertos serie, temporizadores, memorias, puertos de E/S, etc. Un microcontrolador no necesita de más componentes electrónicos para funcionar, mientras que un microprocesador sí. Es por esto, que los microcontroladores son el componente más utilizado para construir sistemas empotrados, en los que el tamaño y el coste son factores determinantes (VanSickle2001). Normalmente, estos sistemas empotrados carecen de los interfaces que presentan los ordenadores de propósito general, como teclado o monitor, por lo que la programación de los microcontroladores que los integran no puede hacerse directamente. Lo usual es escribir y compilar el programa en un ordenador personal y luego descargar una imagen binaria del mismo a la memoria interna del microcontrolador. La depuración de los programas es extremadamente difícil en un sistema empotrado, al no poseer éste los mecanismos de interfaz con el exterior antes descritos, siendo muy habitual el proceso de prueba y error para depurar un programa. Conscientes de este problema, muchos fabricantes de microcontroladores han desarrollado emuladores, dispositivos que, situados en el sistema electrónico en el mismo lugar en que estaría el microcontrolador, y conectados a su vez a un PC, se comportan desde el punto de vista eléctrico de la misma forma que lo haría el microcontrolador que se pretende emular. Estos emuladores suelen tener un precio prohibitivo, que los hace inviables para muchas aplicaciones. El proceso de depuración usando el hardware real es caro y tedioso. Se comprende la necesidad de contar con un simulador que se ejecute enteramente en un PC y que sea capaz de leer e interpretar un programa compilado para el microcontrolador, y proporcionar las mismas

156 salidas que proporcionaría este. Usando simuladores, el ciclo de desarrollo se puede acortar sensiblemente y el coste fijo asociado al proyecto es bastante menor. En este artículo se describe un sistema de simulación desarrollado por los autores para los microcontroladores de la familia M.CORE de Motorola (MMC2000). El sistema está basado en las herramientas GNU, como GCC y GDB que han sido aportadas por el fabricante del microcontrolador, a las que los autores han añadido las rutinas suficientes para simular el microcontrolador completo. La familia M.CORE consta de varios microcontroladores diferentes construidos alrededor de una CPU RISC (Reduced Instruction Set Code). Su característica más destacada es el bajo consumo, lo que los hace ideales para aplicaciones móviles o que necesiten baterías. Cada miembro de la familia es ligeramente diferente en los periféricos que incorpora, pero en general se cuenta con puertos serie síncronos (SPI) y asíncronos (SCI), memoria Flash, memoria RAM estática (SRAM), temporizadores, convertidores analógico-digitales, y puertos digitales de entrada/salida, entre otros. 2. Diseño general del sistema La compañía Motorola, fabricante del microcontrolador, proporciona un simulador de la CPU del mismo para ser embebido en el depurador GDB. Por otra parte, algunos empleados de la misma han contribuido a la comunidad de software libre una versión del compilador GCC y del resto de herramientas de desarrollo GNU adaptadas para producir código M.CORE. El simulador aportado por Motorola se limita exclusivamente a la CPU del microcontrolador, por lo que es apropiado únicamente para calcular los tiempos de ejecución de un determinado programa. En este aspecto es muy preciso, como se puede comprobar en la Tabla 1, en la que se comparan los ciclos de reloj que toma la ejecución de varios programas en el simulador del que tratamos con los que toma según las pruebas internas de Motorola. La compañia afirma que la precisión del simulador para cualquier programa está en torno al 0.5%. ciclos reales ciclos sim Diferencia Programa % Programa % Programa % Tabla 1. Comparación de ciclos de reloj usados por varios programas, en la realidad y en el simulador de Motorola. Los programas son: algoritmos de ordenación, resolución de ecuaciones y compresión de datos. Fuente: Motorola, Inc. El concepto central del sistema descrito en este artículo es la construcción, en torno al simulador de Motorola, un sistema que sea capaz de simular los periféricos del microcontrolador, y al que se puedan conectar dispositivos externos, de la misma forma que se haría con un sistema electrónico real. El usuario del simulador es capaz de especificar qué dispositivos están conectados en qué pines del microcontrolador, y el simulador se encarga de que estos dispositivos reflejen el estado actual del sistema. En la sección 5 se incluye un ejemplo simple. Para lograr el objetivo descrito, son necesarias dos simulaciones adicionales a la de la CPU. Por una parte, hay que simular todos los periféricos internos al microcontrolador, como

157 contadores, puertos, etc. Y por otra, hay que añadir un conjunto de módulos que se puedan conectar externamente al simulador del microcontrolador completo. Estos módulos pueden ser LEDs, displays de 7 segmentos, terminales serie, motores paso a paso, o cualquier cosa que se pueda inventar. Estas dos nuevas simulaciones se describirán con detalle en las secciones 3 y 4. Con el objeto de no limitar arbitrariamente el sistema, la prioridad en el diseño del mismo ha sido la modularidad. Los autores han desarrollado únicamente algunos módulos que se pueden conectar al microcontrolador, pero han dotado al sistema de la capacidad de poder ser extendido simplemente escribiendo el código de nuevos módulos. Para esto se ha diseñado una interfaz de comunicación entre el simulador y los módulos externos, de forma que sea muy fácil añadir nuevos módulos en cualquier momento. En la Fig. 1 se muestra la arquitectura general del sistema. Las partes sombreadas han sido desarrolladas por los autores dentro de este proyecto, mientras que las que tienen fondo blanco se encuentran disponibles bajo licencia libre. Figura 1. Estructura general del proyecto 3. Simulación de periféricos La principal característica de la simulación de los periféricos, al igual que la del resto del sistema, es su modularidad. No todos los microcontroladores de esta familia presentan los mismos dispositivos periféricos, de manera que el diseño de estos dispositivos sigue un patrón modular. Los elementos periféricos se representan como módulos independientes al microcontrolador, para conseguir así una estructura flexible que puede simular cualquier elemento microcontrolador de la familia. De esta forma, además, se facilita la incorporación de nuevos periféricos al simulador. Para que la flexibilidad no derive en problemas de incompatibilidad entre los distintos elementos que forman el simulador se ha definido una interfaz de acceso a los dispositivos periféricos. La estandarización del acceso a estos periféricos permite que la adición de un nuevo elemento que se ajuste a esta interfaz definida no implique cambios adicionales en el resto de la estructura del simulador. La combinación del diseño modular en la simulación de los periféricos junto con la definición de un acceso estándar a ellos consigue que el microprocesador vea a los periféricos como cajas negras, sin que tenga que conocer nada acerca de cuál es su estructura interna o cómo se ha implementado su funcionalidad. Lo único que conoce el microprocesador es la manera de acceder a esas cajas negras.

158 La directriz que suele seguir Motorola en la arquitectura de sus microcontroladores es mapear todos los periféricos en memoria, de manera que no hay diferencia entre acceder a una posición de memoria y acceder a un dispositivo externo, del mismo modo que no hay diferencia entre acceder a un periférico y acceder a otro. Esta arquitectura viene a redundar en la idea de que el microprocesador considere a los periféricos como cajas negras que se distinguen entre sí tan sólo por la dirección mediante la cual son accedidas. Éste ha sido, pues, el diseño que se ha seguido en la definición de la interfaz de acceso a los periféricos, por ser la que habitualmente emplea Motorola, pero podría cambiarse fácilmente a otras arquitecturas usadas por otros fabricantes, como puede ser Intel, que diferencia entre accesos a memoria y accesos a periféricos. Cada uno de los periféricos desarrollados en el proyecto posee su propio código, que trata de imitar la lógica propia del componente hardware real. Así por ejemplo, un contador posee un código que decrementa continuamente a intervalos regulares un cierto registro y activa un bit en otro cuando la cuenta ha llegado a cero. El programa que se ejecuta en el simulador puede leer este bit para saber si la cuenta ha acabado, o acceder en cualquier momento de forma transparente al valor actual de la cuenta. 4. Interfaz de usuario El uso de interfaces de usuario se hace especialmente útil en el desarrollo de sistemas empotrados, pues éstos carecen de mecanismos de interfaz con el exterior como ocurre con los sistemas para computadores. De esta manera, el poder visualizar de algún modo cuáles son las salidas que proporcionan los programas que ejecuta el microcontrolador se convierte en una ayuda inestimable para el desarrollo de tales sistemas. La interfaz de usuario desarrollada refleja la doble vertiente de la naturaleza del desarrollo de sistemas empotrados. Por un lado, dispone de todos los elementos habituales de un sistema de depuración convencional para programas que se ejecuten en computadores, como puede ser la ejecución controlada o la posibilidad de comprobar el valor de las variables que conforman el programa. Por otro lado, la incorporación al simulador de los dispositivos periféricos que forman el microcontrolador hace necesario que la interfaz de usuario no sólo trabaje con el programa que ejecuta el microprocesador, sino que también muestre el estado de los distintos periféricos. De esta manera, podemos comprobar, por ejemplo, el estado del puerto serie o de los distintos registros de salida. Finalmente, y para conseguir que el simulador se ajuste lo más posible a la realidad, del mismo que podemos conectar físicamente distintos elementos a la salida del microcontrolador para comprobar su estado, la interfaz de usuario permite hacer lo mismo con el simulador, mediante una serie de módulos independientes que representan elementos externos al microcontrolador. Toda esta estructura se ha diseñado teniendo presente la necesidad de que el conjunto sea fácilmente extensible, de forma que se puedan incorporar nuevos módulos si el usuario de la interfaz lo cree necesario. La interfaz de usuario es la capa más externa en la estructura del sistema desarrollado por los autores. Se trata de una sencilla aplicación gráfica que pone a disposición del usuario toda la potencia y capacidad que ofrece la API de comunicación con GDB. Dicha aplicación está implementada con la completa librería de componentes Qt que ofrece Trolltech (Kalle2002).

159 Se ha elegido esta librería por la enorme flexibilidad y funcionalidad que provee el mecanismo de signals y slots para la comunicación entre objetos. Hay que hacer notar que la aplicación gráfica está perfectamente separada de la API, por lo que no es necesario utilizar aquélla si queremos usar esta última. La API está presentada mediante una serie de llamadas que obtienen toda la funcionalidad que ofrece GDB, por lo que es posible desarrollar cualquier otro tipo de aplicación gráfica que haga uso de dicha interfaz de programación. La aplicación desarrollada por los autores, aun siendo una interfaz de usuario completa y totalmente funcional, puede servir de muestra a otras futuras aplicaciones y a lo que éstas pueden conseguir si se utiliza la API. La aplicación gráfica tiene un diseño convencional compuesto por un menú, una barra de herramientas y una serie de vistas y panales. En la vista principal se puede ver el código del programa que se quiere simular. Mediante el menú o directamente en la barra de herramientas, el usuario de la aplicación gráfica puede controlar cómo se ejecuta el programa, mediante la inserción y eliminación de puntos de ruptura y mediante los comandos de control de flujo de ejecución. Se dispone también de una serie de ventanas adicionales en las que se puede ir siguiendo la evolución de varios componentes del programa. Así, se dispone de vistas para obtener el valor de variables, de la pila de llamadas, de los registros internos del microprocesador y de cualquier dirección de memoria del microcontrolador. Es esta serie de vistas la que da sentido y utilidad al uso del simulador, puesto que se puede comprobar que todos estos parámetros toman los valores que quiere el programador a medida que ejecuta su programa. Por último y para hacer más útil el uso de esta herramienta, se ha provisto a la interfaz un modo gráfico en el que el usuario puede añadir a la salida del microcontrolador elementos externos como los que puede conectar en la realidad. De esta forma, se pretende conseguir que el simulador refleje lo más fielmente posible el comportamiento real del microcontrolador, comprobando el funcionamiento de elementos externos en lugar de una serie de valores numéricos. Toda esta funcionalidad se obtiene a través de la API de comunicación con GDB. Esta interfaz de programación ofrece toda una serie de llamadas que ponen a disposición de los programadores todo lo que GDB ofrece mediante su interfaz de comandos. En el sistema desarollado por los autores se ha puesto especial hincapié en los aspectos más relevantes del diseño de sistemas empotrados y que podemos apreciar en la interfaz de usuario, como puede ser la obtención del estado de los registros internos del microprocesador o la obtención del valor almacenado en una posición cualquiera de memoria. Esta interfaz de programación no está ligada al microcontrolador M.CORE, es decir, es independiente del microprocesador que se utilice, pudiéndose utilizar con cualquier otro simulador que provea GDB. El funcionamiento de la librería se basa en la creación de dos procesos que se comunican mediante tuberías (pipes). Uno de estos procesos, el hijo, ejecuta el depurador GDB, mientras que el otro, el proceso padre, se encarga de realizar las peticiones y presentarlas de manera adecuada al exterior. También se utiliza otro mecanismo de comunicación entre procesos, como son las señales, que se emplean para informar a la API de que han sucedido eventos significativos, como puede ser el cambio de estado de los periféricos. Para comunicarse con GDB se utiliza la interfaz GDB/MI, que es una interfaz orientada al

160 uso de GDB como una parte de un conjunto mayor (Stallman1994). 5. Ejemplo de aplicación En esta sección se pretende ilustrar con un ejemplo las capacidades del sistema. Se va a conectar un módulo externo en algunos pines de salida del microcontrolador simulado y se va a proceder a simular un programa que acceda a dichas salidas. Uno de los módulos desarrollados en el proyecto es el conjunto de LEDs. Se trata de un número de diodos emisores de luz que se pueden conectar a cualquier pin de salida del microcontrolador. Cuando el programa que se está ejecutando establece un valor lógico alto en uno de esos pines, el LED correspondiente se ilumina en pantalla, y cuando el valor lógico es bajo, permanece apagado. En este ejemplo, el conjunto de LEDs se conecta al puerto A del microcontrolador (MMC2000). Una vez se ha hecho esto, se compila el siguiente programa, que hace parpadear uno de los LEDs del conjunto (se han omitido algunas inicializaciones de los registros del microcontrolador, que no aportan nada al ejemplo). int main(void) { set_led(off); for(i=0;i<=10;++i) { set_led(on); delay1(); set_led(off); delay1(); } } En el programa anterior, la función set_led() únicamente pone un valor lógico alto o bajo en un registro interno del microcontrolador, en función de su único parámetro, como se muestra en el código siguiente. void set_led(unsigned char v) { if(v) reg_porta.reg =0x01; else reg_porta.reg&=0xfe; } Este registro en un microcontrolador real se redirige inmediatamente a un conjunto de pines de salida (el puerto A). En este sistema, es el simulador del periférico correspondiente al puerto A el que informa al módulo de los LEDs de que el valor del registro ha cambiado. El módulo entonces actualiza la imagen en pantalla, dando al usuario la impresión de que un LED se enciende o apaga. Por supuesto, son posibles simulaciones más complejas. Por ejemplo, los autores han desarrollado también un módulo externo que simula un terminal serie, que se puede conectar al puerto serie asíncrono del microcontrolador simulado. De esta forma, es posible la visualización en pantalla de los caracteres transmitidos por el programa del microcontrolador.

161 6. Conclusiones Se ha presentado un sistema apropiado para la simulación de sistemas electrónicos sencillos basados en microcontroladores. El sistema descrito está orientado a la simulación de un microcontrolador concreto, pero es fácilmente portable a otros para los que existan simuladores de sus CPUs (GDB proporciona varios). La gran ventaja del sistema descrito es la modularidad, que permite escribir nuevos módulos que conectar al microcontrolador simulado con gran facilidad. Las líneas de desarrollo futuro del proyecto se centran en la creación de una mayor cantidad de módulos externos para ampliar el rango de sistemas electrónicos simulables. Otra característica que los autores están estudiando es la posibilidad de conectar dos o más microcontroladores simulados a través de sus puertos serie (síncronos o asíncronos) con el objeto de simular un sistema de comunicaciones completo. Referencias (Kalle2002) Matthias Kalle Dalheimer, Programming with Qt, 2 nd ed., O'Reilly, (MMC2000) MMC2107 Technical Data, Motorola Inc., (Stallman1994) Richard M. Stallman and Roland H. Pesch, Debugging with GDB, Free Software Foundation, (VanSickle2001) Ted Van Sickle, Programming microcontrollers in C, 2 nd ed., LLH Publishing, 2001.

162 SISTEMA DE SIMULACIÓN PARA UN MICROCONTROLADOR ELECTRÓNICO BASADO EN LAS HERRAMIENTAS DE DESARROLLO GNU Persona de contacto: Antonio Luque Departamento de Ingeniería Electrónica, E. S. Ingenieros Av. Descubrimientos, s/n Sevilla (España) Tlf: , Fax:

163 GESTIÓN SEMÁNTICA DE CONTENIDOS CON ximdex J. A. Prieto, J. Villar, D. Gómez, M. Estellés XimetriX network thoughts; Spain La gestión de información y documentos mediante Sistemas de Gestión de Contenidos (CMS, Content Management Systems) ha evolucionado hacia la plena separación entre los contenidos y los elementos encargados de su presentación. Sin embargo, esta separación no está siendo aprovechada para dotar de significado a los elementos de información que constituyen los contenidos, lo que, en el paradigma de la Web semántica, facilitaría, por ejemplo, la sindicación de información sin necesidad de establecer manualmente las fuentes origen de la información y, a un nivel más avanzado, permitiría aumentar el grado de interoperatividad entre sistemas de distintas corporaciones. En la actualidad, el uso de XML para la publicación en Web asocia, en la mayoría de los CMS existentes, una estructura y una sintaxis concreta, lo que dificulta considerablemente su posible uso para la realización automática de tareas de intercambio de información entre entidades en base a una sintaxis y/o semántica compartida. Por otro lado, los CMS tradicionales se constituyen además en los Servidores de Aplicaciones encargados de la explotación de los contenidos, lo que reduce considerablemente la interoperabilidad con otros sistemas, bloqueando además el acceso a los precursores de los contenidos. El entorno ximdex 1 de Gestión de Contenidos (CMS) desarrollado por XimetriX ( proporciona los pilares necesarios para dotar de significado a los elementos de información que constituyen los contenidos. Para ello, proporciona a los usuarios la capacidad de edición y definición de los formatos finales a utilizar en la gestión de los contenidos (aplicativo XML), proporcionando además un motor de transformación (módulo dext en ximdex) con licencia libre, encargado de la translación a los formatos finales de publicación (XHTML, HTML, PDF, ) utilizados en los servidores Web y de explotación, a partir de los aplicativos XML libremente definidos. Además, a diferencia de otras herramientas similares, el entorno ximdex proporciona un editor de XML tipo wysiwyg en web y simplifica o automatiza la mayoría de las tareas vinculadas al ciclo de vida documental, lo que garantiza un acceso sencillo a las tareas necesarias para la adecuada gestión de los contenidos y permite el uso del entorno por usuarios no avanzados. La reutilización de contenidos ya existentes o heredados se garantiza mediante filtros de transformación automatizados. Sin embargo, en un marco libre, es aún más importante garantizar la reutilización futura de los contenidos y fomentar la interoperabilidad entre corporaciones en un entorno colaborativo. En el entorno ximdex, esta reutilización futura de los contenidos surge como consecuencia directa de: i) permitir la libre definición de los aplicativos XML utilizados en la gestión de contenidos de una corporación y ii) estructurar y garantizar el pleno acceso a todos los contenidos y a los precursores de los mismos (código fuente para explotación dinámica, plantillas de transformación de formatos, ) mediante múltiples vías como, por ejemplo, Servicios Web. Keywords: Gestión y Publicación de Contenidos, CMS, Web Semántica, Interoperabilidad. 1

164 Contenidos y Web Semántica La gestión de contenidos centrada en la publicación en Internet ha evolucionado gradualmente hacia la plena separación entre los contenidos y los elementos encargados de su presentación, es decir, de los aspectos visuales. El máximo exponente de esta separación lo proporciona el asentamiento de XML como tecnología para la publicación de contenidos [Zapt03]. En el paradigma de la Web Semántica [Bern01] se asocia un significado a los elementos de información que forman los contenidos, proporcionándose simultáneamente mecanismos para estructurar y compartir ese significado en un dominio concreto de conocimiento. El dotar a los elementos de información que componen la Web actual de un significado bien definido permitiría, entre otros, mejorar las capacidades de búsqueda contextual, aumentar la interoperabilidad entre sistemas en entornos de colaboración y llegar, en combinación con Servicios Web, a componer aplicaciones en base a servicios publicados [Shet02, Tsai03]. Sin embargo, en el marco de los Sistemas de Gestión de Contenidos (CMS, Content Management Systems) actuales, esta separación entre contenidos y presentación no está siendo aprovechada para añadir significado a los elementos de información que constituyen los contenidos, principalmente por la asociación realizada por los CMS existentes a una estructura y sintaxis predefinida y por la falta de madurez de las tecnologías de gestión de ontologías, técnica habitualmente usada para la representación de conocimiento en base a la especificación formal y explicita de términos en un dominio y de las relaciones existentes entre ellos [Chan99]. El acercamiento de los sistemas de Gestión de Contenidos a los paradigmas de la Web Semántica permitiría automatizar la realización automática de tareas de intercambio de información entre entidades en base a una sintaxis y/o semántica compartida, lo que facilitaría la sindicación y agregación automática de información, evitando la necesidad de establecer manualmente las fuentes origen de la información. A nivel más avanzado, permitiría aumentar el grado de interoperabilidad entre sistemas de distintas corporaciones, evolucionando de los actuales Portales de Contenidos a Portales de Servicios [Prie03]. XimetriX network thoughts ( ha desarrollado ximdex, un entorno para la adquisición, gestión y transformación de contenidos que permite la inclusión de significado bien definido a los elementos de información que forman los contenidos. El presente artículo recoge las principales características del entorno, resaltando los aspectos clave que posibilitan el tratamiento de contenidos en el paradigma que ofrecerá la Web Semántica. Gestión de Contenidos con ximdex El entorno ximdex es un sistema automático de adquisición, transformación y publicación de contenidos en base a aplicativos XML sobre un entorno visual de etiquetado de los elementos de información. Así, en su configuración como CMS, el gestor ximdex permite la automatización de la publicación de contenidos en formatos típicos de Internet, tanto de tipo estático como de tipo dinámico, y de todos los componentes encargados de su explotación (java, php,.net, etc.), a lo largo de todo el ciclo de vida del documento. El carácter del entorno facilita el escalado y desarrollo de nuevas aplicaciones, proporcionando

165 simultáneamente mecanismos de reutilización de los contenidos y facilitando la asociación de significado a los elementos constitutivos de los contenidos. El pilar central de esta operativa lo constituyen las capacidades de transformación de los documentos estructurados (documentos XAP XML Active Publishers en ximdex), descritos en base a aplicativos XML libremente definidos por los usuarios, hacía los múltiples formatos finales de publicación e intercambio comúnmente aceptados en Internet. Operando como CMS, los documentos XAP almacenados en el entorno son convertidos automáticamente al formato final de publicación (XHTML, por ejemplo), mediante la aplicación recurrentemente de una serie de Plantillas de Transformación de Documentos (PTD) que contienen las propiedades de presentación necesarias para cada uno de los canales vinculados a la publicación (pda s, web, móviles), respetando las características multilingüe requeridas. Los documentos no estructurados (PDFs, vídeos) son gestionados en base a metainformación aplicada mediante técnicas de anotación, controlando el entorno todo su ciclo de vida y versionado y la publicación y despublicación automática en los servidores vinculados al entorno de producción. En el contexto de separación entre contenidos y presentación es necesario desvincularse de los entornos de producción existentes. Para ello, el entorno ximdex gestiona los elementos de código (clases java, php, ) encargados de los contenidos dinámicos, convirtiéndose en un precursor tanto de los contenidos a publicar como de los elementos de explotación necesarios. Esto permite al entorno ximdex operar de forma completamente separada respecto al entorno final de explotación, lo que disminuye considerablemente el nivel de intrusividad de la solución y aumenta el nivel de interoperabilidad. Documentos estructurados y anotaciones contextuales Los documentos en ximdex (documentos XAP) se estructuran mediante anotaciones XML elegidas libremente de un aplicativo XML predefinido por los usuarios del entorno, aplicativo con vinculación directa con las Plantillas PTD de transformación que encapsulan los aspectos necesarios para su traslación a otros sistemas de publicación, agregación y sindicación de información. Así, un formato XAP lo constituye el aplicativo XML, libremente definido por los usuarios del sistema, que proporciona las pautas para realizar la transformación adecuada mediante la invocación recurrente de las plantillas PTD. La Figura siguiente recoge un documento XAP sencillo que vincula significado a elementos concretos de información en un dominio concreto de aplicación, en este caso para representar una beca, donde, para simplificar, se han eliminado las descripciones multi-idioma y de identificación de las anotaciones: <beca id= 123 > <organismo>ministerio de Ciencia y Tecnología</organismo> <destino>instituto de Microelectrónica de Sevilla</destino> <duración unidad= meses >12</duracion> <título>ayudas y Becas de introducción a la investigación aplicada</título> <referencia boe= ><url> </beca> Figura 1: Documento estructurado en formato XAP

166 En la línea de simplificación requerida para el acercamiento del entorno a personal no especializado, el entorno ximdex proporciona un editor wysiwyg para XML, lo que permite la edición de los documentos estructurados sin conocer las etiquetas que lo componen, visualizando simultáneamente el estilo final del documento. La figura siguiente muestra el entorno ximdex durante la edición de un documento para el canal web: Figura 2: Edición wysiwyg de un documento XML en ximdex. Una vez incorporado (bien por agregación, bien por edición) el documento XAP XML Active Publishers al sistema, este es transformado de forma activa hasta llegar al formato final de publicación o intercambio requerido. Durante este proceso de transformación se expanden de forma recurrente las distintas anotaciones existentes en el documento en base a un contexto predeterminado y acotado de publicación a elegir de una taxonomía de perfiles. Esta transformación implica habitualmente la inclusión de texto estructurado o no, permitiéndose también el acceso a fuentes remotas de información para la inclusión de información generada dinámicamente (activa) o incluso la ejecución de código interpretable. Módulos básicos de ximdex A diferencia de la mayoría de los gestores de publicación existentes, donde se realiza una generación dinámica de los contenidos publicados en cada visita al servidor de explotación, el gestor ximdex desvincula la creación de los documentos de su explotación. Para ello, induce una separación entre la etapa encargada de la creación/importación, supervisión, transformación y publicación de los contenidos y la etapa posterior de explotación por servidores especializados (de vídeo, de aplicaciones, web, etc.). De este modo, el entorno ximdex puede describirse como un precursor de contenidos y de sus componentes dinámicos, dejando la explotación a servidores especializados (ej.: apache, resin) para cada tipo de contenido, lo que permite un mejor escalado de la infraestructura asociada y evita los cuello de botella, típicos de las arquitecturas multicapas con generación dinámica, inducidos por otros CMS. Además, y lo que es más importante, permite adecuar la tecnología empleada a la explotación a realizar (PHP versus JAVA por ejemplo), lo que reduce el nivel de intrusividad de ximdex en el ámbito de aplicación y aumenta las capacidades de interoperabilidad.

167 La Figura siguiente recoge el desglose de ximdex en los módulos principales que lo componen y su vinculación con los servidores remotos: dext FS BD dexc dexp D E ServidorWEB (Back Office) Servidores Remotos de Explotación web aplicaciones vídeo Figura 3: Módulos principales de ximdex y servidores de explotación El módulo dexc es el orquestador del sistema completo. Para ello, accede a los datos y documentos, estructurados XML o no HTML, PDF, etc., almacenados en la base de datos del sistema (BD), invoca al módulo de transformación dext, encargado de realizar la síntesis real de los contenidos estructurados en los diversos idiomas y formatos de explotación mediante la aplicación de las plantillas PTD, gestiona el ciclo de vida completo de cada documento y sus ventanas de publicación y despublicación en los formatos finales para sincronización a los servidores remotos, agrega información de fuentes externas, realiza importaciones masivas de contenidos desde el sistema de archivos, realiza un control de la integridad de los enlaces internos y externos, la gestión de las anotaciones contextuales, etc. El módulo dext constituye el corazón de ximdex. Se encarga de generar las diversas variantes de los elementos de un documento a partir del documento original descrito en formato XAP. Los documentos y elementos generados por el módulo dext de ximdex se encuentran ya en el formato final de presentación (HTML, código PHP o clases java, por ejemplo), para su sincronización final al servidor elegido mediante el módulo dexp. El dext se encarga además de controlar las diversas variantes de un documento, es decir, los diversos idiomas en que se publica, las versiones para impresión, y para los diversos canales de publicación (PDA, móvil, Web). El formato XAP (XML Active Publishers) es el aplicativo XML que proporciona las pautas para realizar la transformación adecuada mediante la invocación recurrente de las plantillas PTD definidas. Por último, el módulo dexp se encarga de enlazar el entorno ximdex con los servidores remotos de explotación que publican y sirven los documentos en los formatos finales (servidores de aplicación, vídeo, web, ). Este módulo presenta dos personalidades entrelazadas, una de tipo estático y otra de tipo dinámico, realizando la sincronización con el servidor de explotación adecuado en la fecha y hora indicada por el perfil de publicación, o bien, en caso de optarse por una explotación dinámica del contenido directamente por el entorno ximdex, realiza la petición al módulo de transformación (dext) para la interpretación del documento XAP a petición del servidor Web de explotación. La figura siguiente recoge una de las pantallas de gestión de flujos de trabajo que controlan el comportamiento del módulo dexc:

168 Figura 4: Control de Flujos de Trabajo en ximdex Formatos libres y reutilización de contenidos Un aspecto clave, habitualmente olvidado de forma intencionada por otros entornos y productos, es el libre acceso a los documentos y contenidos almacenados en el gestor y la publicación de los formatos de intercambio utilizados [Cosm97]. En un marco libre es aún más importante garantizar la reutilización futura de los contenidos y fomentar la interoperabilidad de corporaciones mediante el intercambio de información en formatos no propietarios. En el entorno ximdex, la garantía de reutilización futura de los contenidos surge como consecuencia directa de los aspectos siguientes relacionados con la información y los formatos: i) permitir la libre definición de los aplicativos XML (formato XAP) utilizados por la entidad o corporación en la gestión de sus contenidos, ii) proporcionar mecanismos potentes de estructuración y anotación de los mismos, y iii) garantizar el pleno acceso a todos los contenidos (XAP y generados) y a los precursores de los mismos (código fuente para explotación dinámica, plantillas de transformación PTD, ), a través de múltiples vías como, por ejemplo, Servicios Web. Otro aspecto fundamental es proporcionar con licencias libres todos los sistemas encargados de realizar la transformación de los contenidos desde el formato original (XAP) a los formatos finales utilizados para la publicación. En el entorno ximdex, esta transformación la realiza el módulo dext, publicado con licencia libre, capaz de transformar y estructurar portales complejos multilingüe de contenidos a múltiples formatos finales. Conclusiones La separación creciente entre contenidos y presentación abre un camino directo hacía la inclusión de técnicas provenientes de la Web Semántica, lo que permitirá asociar significado concreto y unívoco, en un dominio de conocimiento, a los elementos de información que forman los contenidos.

169 En este contexto, se han presentado las características fundamentales del gestor ximdex desarrollado por XimetriX ( entorno que facilita la asociación de semántica a los elementos de información durante la creación de documentos, resaltándose además los requisitos fundamentales para garantizar la reutilización futura de los contenidos y el intercambio automatizado de información entre entidades en un marco de colaboración, lo que facilitará las tareas de agregación y sindicación y permitirá la manipulación automática de información en el paradigma ofrecido por la Web Semántica. Referencias o [Athe02] R. Athey, Enterprise Content Management: taming content chaos, Search Results, Deloitte Consulting and Deloitte & Touche, ISBN , o [Bern01] T. Berners-Lee, J. Hendler et al, The Semantic Web: A New Form of Web Content That Is Meaningful to Computers Will Unleash a Revolution of New Possibilities, Scientific American, vol. 284, no. 5, pp , May o [Chan99] B. Chandrasekaran, V. R. Benjamins et al, What Are Ontologies, and Why Do We Need Them?, IEEE Intelligent Systems, pp , Jan./Feb o [Cosm97] P. Di Cosmo, Piège dans le Cyberespace / Trampa en el cyberespacio / CyberSnare, (español) o [Prie03] J. A. Prieto, Interoperability Dossier, Internal Report, Jul o [Shet02] A. Sheth, C. Bertram el al, Managing Semantic Content for the Web, IEEE Internet Computing, Volume: 6, Issue: 4, pp , Jul-Aug o [Tsai03] Tse-Ming Tsai, Han-Kuan Yu et al, Ontology-Mediated Integration of Intranet Web Services, Computer Magazine, Volume: 36, Issue: 10, pp , Oct o [Zapt03] Zapthink LLC, XML in the Content Lifecycle: Creating, Managing, Publishing, Distributing, Syndicating, and Protecting Content with XML, Jan

170 Día h Sala 2: Educación, Universidad y e-learning Moderadora Pilar Ballarín Directora General de Evaluación Educativa y Formación de Profesorado Junta de Andalucía Participantes Jesús María Rodríguez Barahona Francisco de Urquijo Niembro Giovanna Sissa Francisco Javier Sánchez Quirós David Puente Antonio José Sáenz Albanes Álbert Calvet Univ. Juan Carlos I CINVESTAV-IPN Observatorio Tecnológico/ Educación Ministry Esware Linux Sadiel Cassfa CV & Consulting

171 MicroEducation F. de Urquijo Niembro, J.U. Cruz Cedillo, R. Hansen, CINVESTAV-IPN, México It is during the first months of life that the most important part of our formation and education takes place. The great majority of the cerebral connections develop based on the needs and impulses experienced during the immediate months after birth. The acquisition of communication skills of all types like foreign languages, reading, mathematics, body language, music and sign language is enormously facilitated if it is practiced during very early childhood. These depend fundamentally on the exposure of children to their parents doings and awareness. The objective of the research is to develop a better structure to support parenthood by means of new technologies and by making parents conscious of this natural opportunities opened to the human being. The Digital Revolution and the use of Sign Language with Babies. This paper propose a new vision of the relevance of the signs language for human beings and proposes a way to enhance human communication in the planet by taking advantage of the digital revolution. Based on an in-depth reflection of the challenges and the practices of natives americans and the deaf community, it is time to turn our attention to what we could learn from them. Signs language is so natural to the human being that babies can learn its use months before being able to communicate in a spoken language. The Digital Revolution is reaching most of the world regions. Soon, it will be normal to interact directly through video conferences or other forms of virtual presence. The use of new technologies will foster the development of sign languages. If every children in the world learn to communicate by means of signs we would be initiating a new way to unite the world, learn new languages much easier and enlarge our natural potential. Sign language usage in native America. What can the modern world learn from native americans today? Universal use of sign language had almost disappearing even from the history books, but recently has come back as a powerful tool for human understanding and sharing between different cultures, like it used to be for centuries on this part of the world. The cultural collision between such difference worlds, in so different aspects, had been so tremendous, that five hundreds years latter had not been enough to settled the consequences of such impact. Somethings were adopted in both worlds very fast, like smoking, eating beef, pork, corn, tomatoes, potatoes, etc. The adoption of languages took more time, for example only 20% of the mexican population speak Castilian by Other cultural differences took even more time to reach the planet. One in particular, very close to our heart is the extremely advance, sophisticated, powerful and universal

172 use of sign language used by the american natives before The subject is enormous, in history, in sociology, in linguistic, and specially as a new and powerful very modern educational tool. Even more important, this subject has to offer lots in nature respect, in human understanding, and a future for the world. Natives americans living today, have still so much to share, above richness, food, lands and beauty, that had not yet been valued enough. Important lessons, the world can get from such living societies today. Only some native communities from Yucatan, Alaska or Arizona, still use sign language in general. We hope soon with the help of open systems and free software human been could hear on its natural mother tong the sound of many other languages of the world while understand through the use of signs. Often, free software is criticizes for only reverse engineering what proprietary software has done before. Microeducation is a new and fascinating new field where proprietary solutions had not been before.

173 EL SISTEMA OPERATIVO ORGANIZACIONAL ESTÁNDAR (SOOS) F. de Urquijo Niembro, J.U. Cruz Cedillo CINVESTAV-IPN, México El proyecto SOOS, busca apoyar a las pequeñas, medianas y grandes organizaciones de todo tipo y de cualquier parte del mundo, para ayudarlas a evolucionar hacia una economía digital. Actualmente, sólo unas cuantas empresas muy bien financiadas pueden pagarse toda la diversidad y complejidad de las innumerables tecnologías existentes, apoyándose en decenas de proveedores distintos, cada uno automatizando partes puntuales de las operaciones. Esto exige una enormidad de recursos que muy pocas empresas de México o del mundo se pueden permitir. En contraste, en este proyecto se busca simplificar al máximo la operación organizativa de todo lo estandarizable, favoreciendo así la interacción automática entre organizaciones, reduciendo los costos operativos de toda la economía sin mayores necesidades de capital o de endeudamiento. Lo que proponemos es crear un Sistema Operativo Organizacional Estándar (SOOS), como base para el mejoramiento del desarrollo, funcionamiento e interoperabilidad de las organizaciones de todo tipo. Esta propuesta busca la efectividad y eficiencia de los procesos de la organización mediante la integración de diversas tecnologías. El objetivo consiste en mejorar el funcionamiento de las organizaciones, a través de la estandarización de los procesos. Esto requiere de investigación y desarrollo tecnológico interdisciplinario, ya que implica integrar conocimiento de áreas muy diversas, como la administración, la electrónica, la informática, las telecomunicaciones, las ingenierías de diseño y de las manufacturas, el derecho y las ciencias sociales, entre otras. Resultados esperados 1.- Una comunidad especializada y altamente competente, que además y gracias a sus desarrollos concretos con el SOOS, sea capaz de ofrecer soluciones reales para las organizaciones en todos los países. 2.- Un conjunto de políticas relativas a procesos y tecnologías organizacionales, cuyo objetivo es establecer estándares y métodos que permitan la obtención de sinergias entre la academia, las empresas, los gobiernos y las comunidades. 3.- El SOOS será distribuido libremente en un DVD, CDs o Internet, y su contenido no tendrá costo alguno para el usuario, al igual que otros servicios públicos, similar a los libros de textos gratuitos que tienen muchos países del mundo. 4.- Su contenido será el compendio de software libre que una organización necesita para funcionar lo más eficientemente posible, pero basado en estándares internacionales abiertos y metodologías (diseño, implementación, codificación, comunicación y documentación, entre otras) que permitan una adaptación fácil a sus necesidades específicas. Contendrá lo necesario para facilitar la administración, la comunicación telefónica y de datos, el seguimiento de las actividades, de los recursos y de las personas. 5.- Una comunidad de organizaciones, alerta y activa que utilizará el SOOS, pero que también tendrá lo necesario para expandir la funcionalidad de tal manera que sea forjada

174 una comunidad participativa, de individuos, grupos y de instituciones con intereses comunes. El mínimo común denominador Desde el punto de vista técnico, el SOOS será un conjunto de componentes de software que incorpore de una manera estándar (pero en continua evolución) las siguientes funciones: 1.- Comunicar la organización con el exterior (al utilizar los servicios telefónicos, o una red de voz y datos). Facilitar la interoperatividad con otras organizaciones: clientes, usuarios, proveedores, bancos, organismos gubernamentales, etc. 2.- Interactuar con una base de datos relacional abierta, accesible a todas las aplicaciones (Postgress) 3.- Dar seguimiento a los procesos que realiza una organización (Workflow). 4.- Visualizar las actividades de la organización en términos de modelos estándares (MDA, UML, XML, ebxml,...) Racionalización de módulos que no están integrados ni estandarizados 1.- La funcionalidad de un ERP (Enterprise Resource Planning) flexible y adaptable a las necesidades de las organizaciones de cada país. Cada año se gastan localmente decenas de millones de dólares para adquirir soluciones propietarias tipo SAP, BAAN, People Soft, Solomon, u otras, que no están necesariamente al día ni se adecuan a las necesidades de las organizaciones. 2.- Un CRM (Customer/Citizen Relationship Management) suficientemente versátil para la administración de la relación con los clientes (ciudadanos, pacientes, escuelas, municipios,...) al alcance de todas las organizaciones (micros, pequeñas y medianas). 3.- Un GIS (Geographical Information System), Sistema de Información Geográfico, basado en estándares abiertos (OpenGis), coadyuvaría en muchas de las aplicaciones del SOOS, por ejemplo el catastro predial en los municipios, las obras hidráulicas en los ejidos, la localización de móviles vía GPS (vehículos, personas, fauna, flujos,...), la planificación, asignación y control de rutas de distribución en las empresas, entre muchas otras. 4.- Un HD (Help Desk), módulo interactivo que atienda automáticamente las peticiones de información relevante de parte de ciudadanos, clientes, usuarios, causantes, pacientes, alumnos o turistas, buscando mejorar la eficiencia de esas actividades recurrentes. 5.- Comercio Electrónico (B2B). En el contexto de la globalidad económica, toda organización que tenga que comprar o vender deberá operar digitalmente para mantenerse competitiva. Esto hará posible agregar la funcionalidad de oferta y demanda de productos directamente del productor al consumidor, eliminando intermediarios. 6.- Una integración total entre el teléfono y los datos. Actualmente las organizaciones instalan dos redes: una de datos y otra de voz. Esta duplicidad, además de ser incómoda, reduce dramáticamente la productividad y origina gastos adicionales. Los Beneficios 1.- Acercar las actividades académicas y las productivas: Todos los sectores académicos podrán concretar sus investigaciones en aplicaciones directas al convertir sus conocimientos en software que se pueda emplear fuera de la academia. Los universitarios necesitan saber lo que las organizaciones requieren; inversamente, las organizaciones necesitan abastecerse de material humano con conocimiento y experiencia práctica obtenidos durante su formación profesional.

175 2.- Saltar la brecha tecnológica informática: En el sector de alta tecnología, muchas organizaciones pueden salvar varias de las etapas intermedias de desarrollo de software que tecnológicamente ya han sido superadas. Por ejemplo, el mercado financiero más grande del mundo, el de Nueva York, usa el lenguaje de programación universal COBOL, a pesar de que ya se conocen mejores tecnologías. 3.- Establecer un mercado abierto internacional de nuevas tecnologías: Actualmente muchos países son un territorio colonizado por empresas de software propietario. El SOOS permitirá tener la masa crítica necesaria, la vinculación academiaeconomía, y una exposición a millones de posibles nuevos creadores y usuarios de soluciones abiertas. 4.- Eliminar la total dependencia de soluciones extranjeras: En países en desarrollo, hay empresas, universidades u organismos del sector público que quisieran contribuir a la expansión tecnológica de sus correspondientes economías, pero no lo pueden hacer porque tienen que cumplir con los requisitos de seguridad de la inversión que hipotéticamente si tienen las soluciones propietarias. Por ello se requiere de una masa crítica de éxitos documentados, y de un esfuerzo riguroso de parte de los investigadores y usuarios, para mejorar el nivel de credibilidad que tienen las soluciones abiertas. 5.- Mejorar directamente la productividad y la eficiencia de las organizaciones: Un SOOS ofrecerá una reducción radical de los costos de modernización sin tener que utilizar onerosos créditos. 6.- Reducir considerablemente el costo de operación de las organizaciones: El desarrollo de un SOOS brindará la posibilidad de que las mismas organizaciones desarrollen sus competencias administrativas a través de un aprendizaje continuo y acceso a la mejor tecnología disponible. Ellas mismas contribuirán al desarrollo y mejora continua del SOOS. Keywords: SOOS, estándares abiertos, sistemas organizacionales, economía digital.

176 TECHNOLOGY TRANSFER AND OPEN SOURCE SOFTWARE FOR SCHOOL Giovanna Sissa Osservatorio Tecnologico scuole MIUR Piazza della Nunziata 2, Genova, Italy Technology Transfer is a keyword in ICT field; usually the term is used to indicate a facilitation process from ICT to industry. The relevance and complexity of ICT trends leads to the need of this kind of support for schools and mainly for the introduction of Open Source Software in education. Osservatorio Tecnologico ( by the Italian MIUR (Ministero Istruzione Università e Ricerca), is an Italian web based national service for technology transfer from ICT to schools. Since the beginning, in 1999, the Open Source Software has been one of the main topics which Osservatorio Tecnologico was engaged with. Osservatorio Tecnologico mission is the technological transfer from ICT to school in order to establish a link between academic, research, net-economy communities and schools. Main tasks are: To identify and focus on ICT trends and Open source software paradigm; To support the introduction and management of Open Source software; To identify Best practice of Open source software in education; To disseminate Open source principles for student, teacher and generic users; To inform about open source and free software opportunities for e-government into public sector and more specifically into school system; To create Guideline for open source software choice into public sector and school. Open Source Software is an emerging trend in software development, both in private and public sector; in school it's relevant too. Core business of Osservatorio Tecnologico are trends and news about basic and general purpose application software, operating system and general application programs (not educational software). Osservatorio Tecnologico want to try and define Open Source Software phenomenon, development and business model and to help schools into the introduction of Open source software paradigm. For this purpose the Osservatorio Tecnologico web based service has created four different types of repository: An information repository, containing document, bibliography, papers and news; An experience repository, containing best practice about Open source software experience into school, mainly related to networking; A data repository, about 1600 Italian schools; A software repository, containing test and evaluation of: Linux distribution, both on server and on client, networking program, like http server, file server, mail server and application program, like office automation programs. Target people are teachers, school operators, public sector managers, but also citizens. The cultural impact of OSS in education

177 One of the most widely discussed arguments in the OSS debate concerns the impact it could have on the development of the country. There is an area of particular interest: education. The phenomenon of open source software (and the related areas of open formats and information access and sharing) is proving to be much larger than its origins as a specialist niche could have led us to suppose. Furthermore, it has a potential cultural impact that go beyond computer science field. Cultural aspects involved are the openness of knowledge, the freedom of disseminating scientific knowledge and the debate on issues relating to copyright protection. Modalities and rules to transfer and distribute Knowledge on Internet are critical issues for schools. Knowledge has to be as free and open as possible but authorship must be preserved and reliability of sources too. For this reason the web site of Osservatorio Tecnologico is released under Creative Commons licence. In general, the OSS paradigm has cultural implications that cannot be reduced to a mere technological fact. This cannot fail to have a significant impact on the relationship between OSS and education, at both school and university level. The availability of the source code, which is the essence of OSS, is also of great interest in the area of education. In particular, it is widely used in technical schools, where computer science is on the syllabus. From a methodological point of view, some advocates emphasise the educational value of OSS in a computer science course, while others highlight the specialist training aspect for technical school students. In addition, the teaching of the various disciplines can be carried out using open source teaching programs. The other use of OSS in schools concerns the operation of computer infrastructure, starting with the adoption of a Linux operating system on the server, including the management of networks and network services, and the use of an open source office automation suite on clients. OSS can offer various advantages; in order to exploit these benefits, adequate professional skills must be available, and this may be a critical issue for schools. There are four areas of OSS use in school. 1.Direct use of open source package Open source packages can certainly be used in place of, or alongside, proprietary software in support of teaching activities, network or network services management, or administrative activities. From the teaching point of view, the use of open source packages together with proprietary ones helps students to understand that there is often a wide choice and numerous alternatives available. Examples of tools that can be used in this field are Linux, Apache, OSS office automation suites, tools for managing network services, and training support programs. 2. Analysis and study of open source code The advantage of OSS is that its source code can be accessed. For this reason many people argue that OSS and other types of accessible software can be used not only as a direct working tool but also as a subject of study. The source code availability can be used to teach the principles and techniques of computer science. Examples of this use are: study and organisation of a compiler, the structure of a network server, and techniques for indexing databases. Computer science, in addition to a theoretical base, requires practical training. The direct development of code from the student is very useful. The study of existing programs can be used to demonstrate programming techniques and the best practices can significantly increase

178 the capabilities and skills of the students. However the source code under consideration must be of a high quality and adhere strictly to the software engineering principles. 3. Development and integration of an open source code The third field in which OSS can play an important role is in advanced laboratory work, especially in the final years of secondary school. Examples include extending the functionality of existing systems, integrating other open source and proprietary software programs or systems, and the addition of new data formats. 4. Modification of open source resources and their reuse in teaching and network services This area involves the work being done by some groups of teachers and programmers in developing teaching software, including: software for teaching various subjects that has been adapted by teachers/developers to meet their own needs; utilities for teaching and school organisation developed and modified by the teachers; and distribution of solutions or systems for specific use in schools, such as the distribution of the Linux operating system. Outlook for the use of OSS in schools Italian schools are becoming increasingly interested in OSS. Actual use is however limited to some exemplary cases concentrated mainly in technical or vocational institutes where computer science is taught. These experiences are the result of specific or local factors for excellence, such as the presence of a teacher who is particularly convinced of the validity of the OSS paradigm or where there is a centre of technological excellence in the area which gives support and provides solutions and training, mainly with the aim of testing out innovative approaches. These practices are difficult to scale up and apply to the basic educational curriculum. Keywords: Open Source Software in school, Technology transfer, Open Content, Osservatorio Tecnologico

179 E-LEARNING Y EDUCACIÓN SECUNDARIA Fco. Javier Sánchez Quirós 1, 1 I.E.S. Monterroso, Spain fco.javier.sanchez@hispalinux.es I. Introducción La importancia que en los últimos años están adquiriendo las plataformas o herramientas de aprendizaje electrónico (o e-learning) ha hecho que todos los niveles educativos, tanto dentro de la enseñanza reglada, como puede ser la Universidad, como en ámbitos económicos como puede ser la teleformación de los empleados en las empresas, comiencen a preocuparse por desarrollar contenidos e implantar plataformas de e-learning. Al mismo tiempo, los gobiernos están intentando impulsar este tipo de enseñanza a través de programas europeos (vid. Sin embargo, es muy poco lo que podemos encontrar de aprendizaje electrónico en el ámbito de la educación secundaria y fundamentalmente esto es así porque las plataformas de e-learning que se usan en universidades o empresas suelen pertenecer al software propietario, que es caro, cerrado y no muestra su fuente. Qué posibilidades hay entonces de desarrollar contenidos y de implantar un sistema de e-learning en la educación secundaria? Sin duda, la respuesta se halla en el software libre que nos permite acceder al código fuente para modificarlo, mejorarlo y adaptarlo a nuestras necesidades. Además, la instalación de servidores con este tipo de software es sencilla y muy configurable. Nuestra intención en esta comunicación es mostrar cuáles son los pasos que hemos dado hasta el momento para desarrollar nuestro proyecto en el ámbito de la educación y dividiremos nuestra exposición en los siguientes apartados: en primer lugar, trataremos la planificación estratégica del proyecto; a continuación, la planificación táctica, seguida de la gestión tecnológica del mismo. El siguiente apartado será la gestión y desarrollo de los contenidos, que deberemos comenzar a debatir en cuanto esté en marcha nuestro proyecto. Y por último, cuál creemos que deben ser las fases en las que se explicite este proyecto. Todo este desarrollo lo hemos plasmado en un documento que es fácilmente adaptable a la realidad concreta de cada centro. II. Una nueva forma de educación: el aprendizaje electrónico o e-learning

180 Pretendemos en este apartado definir una idea acerca de lo que es el e-learning, pero también mostrar cuáles son las características principales de esta nueva forma de aprendizaje así como sus implicaciones desde el punto de vista educativo. III. Proyecto tecnológico en el ámbito de la educación 1. Planificación estratégica del proyecto de implantación Está claro que sin una estrategia de implantación nuestro proyecto no podría ser llevado a cabo; pero, cuáles son las bases sobre las que tenemos que plantear nuestra estrategia? Son unas más importantes que otras, o, de otra forma, tenemos que establecer prioridades en nuestra estrategia? Por otra parte sabemos que la planificación de un proyecto de este tipo es algo fundamental para la viabilidad y buen funcionamiento del mismo y, por ello, no queremos dejar de hacer algunas consideraciones que, sin lugar a dudas, serán la base de todo nuestro proyecto: 1ª. Participación de los profesores en el proyecto 2ª. Estrategia y temporalización de la implantación del plan 3ª. Formación del profesorado 2. Planificación táctica del proyecto de implantación Sin duda alguna, nuestro proyecto necesita de una gestión estratégica que defina apartados tan importantes como la creación y gestión del plan, los contactos iniciales para acuerdos estratégicos, la definición de las necesidades para la ubicación y el desarrollo del proyecto, la organización del personal, la estructura organizativa general y los perfiles generales de acceso. Todos estos apartados configurarán la planificación táctica del proyecto de implantación. 3. Gestión tecnológica del proyecto de implantación Este apartado, necesario e imprescindible en nuestro proyecto, tiene su razón de ser en el hecho de que debemos seleccionar una plataforma o herramienta en la que centrar nuestro trabajo, explicar las características de la misma, establecer las herramientas de comunicación y definir la infraestructura tecnológica sobre la que va a desarrollarse. La selección de la plataforma está motivada por la infraestructura con la que contamos: de hecho, tenemos en el servidor de nuestro centro un sistema operativo Linux instalado y funcionando, por lo que quedan excluidas ya de principio todas las herramientas que necesitan un sistema operativo propietario tipo Windows. Además creemos firmemente

181 que el software libre nos conducirá inevitablemente a que también el conocimiento sea libre, como ya antes hemos apuntado. Entre las herramientas disponibles hemos elegido miguel (nombre de nuestra herramienta) porque consideramos que su nivel de desarrollo y perfeccionamiento es tal que no tendremos ningún problema en su instalación, configuración y funcionamiento. Además, tenemos la ventaja de que esta herramienta está desarrollada por un equipo español, con lo que el acceso a los desarrolladores será más fácil y rápido, tanto para la comunicación con los mismos como para la posibilidad de que sean ellos los que impartan los cursos que el Centro de profesores pueda asignar a nuestro centro. Las características de miguel que mejor se adaptan a nuestro proyecto se resumen en el siguiente cuadro: Fácil de usar: La aplicación está pensada para ser usable y no quedar en el olvido, tanto por parte de los profesores como de los alumnos. Esto se consigue gracias a la elaboración de ayudas e interfaces humanas sencillas, así como con mecanismos de publicación y compartición de contenidos que no necesitan de una elevada curva de aprendizaje. Accesible a personas con discapacidades. Mantenimiento simplificado: Facilita el trabajo del administrador. Segura y de alto rendimiento. Modular. Capaz de adaptarse a cualquier necesidad. Hay que señalar que miguel dispone de las herramientas básicas para el desarrollo de un curso. Como profesor, se tiene acceso a otras necesarias para que el curso pueda realizarse sin ningún tipo de incidencias, así como para evaluar la calidad del curso. Y además, para facilitar el trabajo al administrador del sistema, se dispone de una herramienta de administración muy sencilla de utilizar y en la que se automatizan las tareas más comunes. Como algo especial se incluye también una potente y sencilla herramienta de gestión de bases de datos en la que el administrador puede realizar cualquier tarea referente al acceso a los datos de la plataforma. Tareas como la realización de informes, resolver peticiones de modificación de datos concretos, tareas de mantenimiento..., se resuelven de la forma más simple en miguel. Por otra parte, las herramientas de comunicación que usaremos para hacer más viable nuestro proyecto serán el correo electrónico y las reuniones del Equipo Técnico de Coordinación Pedagógica y el Claustro, así como todas aquellas que el equipo directivo decida para presentar, difundir y promocionar nuestro plan de implantación.

182 Por último, señalar que nos hemos propuesto desarrollar e implantar una plataforma educativa de e-learning usando sofware libre en un instituto de educación secundaria. Pero nuestro proyecto educativo de innovación pretende además que este modelo sea extensible a todos los centros de enseñanza interesados dependientes de la Consejería de Educación y Ciencia de la Junta de Andalucía a través de un sistema de formación del profesorado que tenga como núcleo los Centros de profesores y la Dirección General de Evaluación Educativa y Formación del Profesorado como coordinadora y aglutinante de estos esfuerzos.

183 OPENSOURCE EN E-LEARNING D. Puente Bautista Sadiel S.A, España El elearning no es sencillo. No es tan simple como "que el profesor cuelgue contenidos en una web y el alumno se los descargue para imprimir y leer". Entran a jugar factores que tienen que ver con todo lo que comprende la educación y la tecnología. El mejor profesor que presencialmente imparte sus clases podría no ser el mejor profesor en un curso impartido a través de Internet. Igualmente, el mejor equipo de analistas podría no concretar una aplicación que consiga que profesores y alumnos enseñen y/o aprendan... y una de las muchísimas consecuencias de esto es que, un software, sea gratuito o sea comercial no garantizará nunca, por el hecho de costar mas o menos, el logro de la enseñanza y del aprendizaje. En esta ponencia no vamos a discutir qué software es mejor y no vamos a decir verdades absolutas. Se van a mencionar siempre hechos parciales. Nadie puede asegurar que hoy mismo no se haya lanzado una nueva aplicación, un nuevo LMS (Learning Management System) que cubra más o nuevos aspectos que los actualmente cubiertos. Igualmente no podemos asegurar que todas las instituciones empleen adecuadamente los medios que tiene a su alcance ni que sus demandas y necesidades sean siempre idénticas. El coste de un LMS OpenSource Una de los primeros motivos que un cliente puede argumentar en la adquisición de un software OpenSource suele ser el coste económico del producto. No queremos centrar en éste el motivo por el cual una institución prefiera un tipo de aplicación u otra ya que, aunque la licencia de un LMS sea de 0 no debemos pensar que el coste de su utilización sea de 0. El hosting del LMS: Propio o en ASP. El ancho de banda necesario para Internet (en función del uso que se le vaya a dar). La integración con otros sistemas de información. La personalización. La formación para la administración y gestión del LMS. Los contenidos y la integración de los mismos. La tutorización y el seguimiento de los cursos. Es muy frecuente encontrar que un LMS OpenSource tiene miles de descargas realizadas por toda la Comunidad de usuarios pero también es frecuente encontrar que gran parte de las mismas están instaladas en PCs personales como fruto de la curiosidad y a modo de testeo. Nada negativo pero ejemplificador de lo que hemos expuesto anteriormente: La explotación no suele ser de 0 y es aquí en donde muchas implantaciones quedan paralizadas. Evidentemente, todos estos conceptos pueden ser o no "gravosos" en función de los recursos que un organismo o empresa tenga. Ventajas Muy escuetamente, entendemos que un LMS OpenSource puede ser beneficioso para: Empresas que no exijan prestaciones distintas a las que la solución OpenSource da respuesta. Se puede entender que dichas instituciones no son complejas y el

184 nivel de crecimiento y demanda de servicios puede tener respuesta desde estas soluciones. Organismos o entidades que dispongan de recursos (económicos y humanos) suficientes como para dar solución a nuevas demandas o necesidades que la solución OpenSource genere. Peligros Pensar que siempre va a salir mas económico que con un software comercial: Sólo en algunos casos es así. Generalmente, si se opta por un LMS OpenSource por este motivo, deberá estudiarse el proyecto a medio largo plazo. Los inicios suelen ser ideales para ver las bondades de algunas aplicaciones, pero la evolución y el éxito del proyecto puede llevarnos a un desarrollo interminable de sus posibilidades (y desarrollo implica coste). El coste para desarrollar y evolucionar un LMS OpenSource con prestaciones semejantes a otros con licencias de pago puede llegar a ser superior que las mismas. A continuación se enumeran y describen brevemente las herramientas más conocidas en este ámbito y que se pueden considerar lo suficientemente maduras como para ser puestas en explotación. Algunas de ellas, aunque no se pueden considerar estrictamente LMSs, han sido incluidas por su excelencia en ciertos aspectos y pueden ser utilizadas en algunos casos específicos. Claroline [Miguel] ( y De la parte del usuario, sólo necesita de un navegador, de la parte del servidor, funciona casi en cualquier plataforma, siempre que soporte Apache, PHP y MySQL: Linux, Unix, Windows y MacOs X están comprobados. Recomendable correr en el mismo servidor un servidor de correo (Postfix o Sendmail). En 1998, Claroline comenzó su desarrollo en la University of Louvain en Bélgica, la cual decidió desarrollar una plataforma Open Source para poder basarla en la colaboración de muchos usuarios y que el desarrollo de la misma fuese más rápido. Lo que consiguieron es un paquete muy sencillo y minimalista, en el que el profesor puede añadir de modo muy simple las partes (los módulos) que necesite. Esto se ha conseguido reciclando piezas de código de la comunidad Open Source. Por ejemplo, el proceso de autentificación está inspirado en el utilizado por PhpNuke, y el layout de la página de inicio de los cursos está inspirado en Yahoo. El fenómeno Claroline se extendió rápidamente a otros países, agrupando una comunidad de usuarios, desarrolladores, traductores y profesores que han hecho posible la traducción en 15 idiomas y el desarrollo rápido de esta herramienta en un competidor para plataformas comerciales. Existen aplicaciones en desarrollo basadas en Claroline en Galicia (la experiencia del CESGA ( y Extremadura (Miguel, desarrollado por Hispalinux). Herramientas generales: Agenda, Enlaces, Documentos, Trabajos, Anuncios, Usuarios, Foros, Ejercicios, Grupos, Descripción del curso, Chat. Herramientas sólo para administradores: Estadísticas, Características del curso, Añadir un enlace a la página principal. Moodle ( De la parte del usuario, sólo necesita un navegador. Para el servidor, decir que Moodle se ha desarrollado en Linux con Apache, MySQL y PHP, pero también funciona con PostgreSQL y sobre sistemas operativos Windows XP, MacOs X y Netware 6. Cualquier servidor web que soporte PHP debe funcionar (por ejemplo, IIS sobre Windows). En cuanto a bases de datos, MySQL y PostgreSQL están recomendadas, el resto se soportarán a partir de Moodle 1.1.

185 Moodle comenzó su desarrollo a final de los 90 gracias a la idea de Martin Dougiamas, quien hoy en día aún esta a cargo del proyecto. En esos tiempos Martin era el administrador de WebCT en la Curtin University of Technology. La primera versión de Moodle vio la luz en Agosto 2002, tras varios prototipos descartados. A partir de ahí, Moodle ha ido creciendo en herramientas, escalabilidad y rendimiento. Algunas de sus características son: Accesibilidad para visitantes, editor HTML embebido, módulos de actividades, Plug-ins de idiomas, diversos métodos de autentificación, los cursos pueden ser públicos o cerrados, puede configurarse la eliminación automática de alumnos, dispone de una herramienta de cambios recientes. Las calificaciones de foros, exámenes, tareas y diarios de estudio pueden visualizarse en una página y descargarse a Excel, dispone de informes completos de actividad, integración con correo exterior, tareas, consultas, foros de discusión, diario de estudios, cuestionarios, recursos, encuestas. FLE ( Para el usuario, solo es necesario un navegador y para el servidor es necesario Zope (similar a Apache) ya que está escrito en Python. Se ha probado en la mayoría de sistemas operativos: GNU/Linux, MacOs X, *BSD y Microsoft Windows. Junio de 1997, MediaLab, University of Art and Design en Helsinki. FLE nace como un proyecto soportado por el ministerio de educación finlandés y varios sectores de la industria. El proyecto pretende crear un sistema que soporte métodos de educación innovadores utilizando new media. Debe ser un producto accesible a través de Internet y soportar, en especial, el aprendizaje basado en problemas (Problem Based Learning, PBL). Este primer prototipo de FLE se testeará con unos 2000 alumnos en su primer año de existencia, en entornos tan dispares como empresas e institutos de educación secundaria. A final del año 2000 se lanzará una segunda versión del proyecto debido al alto nivel de aceptación del primero. En este proyecto participarán además otras instituciones gubernamentales escandinavas y contará con el soporte de ITCOLE (Innovative Technologies for Collaborative Learning and Knowledge Building), proyecto de la UE incluido en el programa 'Schools for Tomorrow'. Hoy en día FLE es una opción para aquellos que necesitan de una herramienta que soporte el aprendizaje colaborativo. FLE3 se distribuye como software libre y de código abierto bajo licencia GPL, permitiendo a cualquiera modificarlo y redistribuirlo. Herramientas: En FLE no existen herramientas de por sí como a las que se ven en otros sistemas. La idea de FLE es otra, y quizá por eso sea una herramienta interesante para algunos. En esta sección se van a ver en profundidad los tres bloques que conforman FLE al ser estos lo más parecido a herramientas que podemos encontrar. CampusAbierto ( Para el usuario, solo es necesario un navegador y para el servidor es necesario Apache sobre Linux, Tomcat, y PostgreSQL. CampusAbierto es la plataforma de elearning con licencia GNU desarrollada por IngeniA (empresa ubicada en el Parque Tecnológico de Málaga), que ofrece además servicios de instalación, consultoría, mantenimiento, etc. para esta plataforma. Cada curso contiene varios grupos de herramientas, organizadas en 4 categorías: Información, Trabajo, Comunicación y Pública, que aparecen a la izquierda en un menú separado. CampusAbierto ofrece cuatro perfiles de usuario distintos: Administrador, tutor, alumno y público, este último diseñado para dar acceso a visitantes y que no pueden acceder a algunos recursos del curso.

186 Las diferencias entre los perfiles se encuentran en el numero de opciones disponibles para cada uno de ellos. Herramientas: Información del curso, Participantes, Agenda, Contenidos, Ejercicios, Prácticas, Evaluaciones, Correo, Foros, Tablón del curso, Charlas..LRN 2 ( es una reciente y prometedora iniciativa del MIT (Massachusetts Institute of Technology) para, sobre licencia GNU, dotar a esta y a todas las universidades interesadas, de un entorno (LMS) que soporte los contenidos y recursos que son necesarios para desarrollar acciones educativas a través de Internet..LRN actualmente está en uso en el MIT (U.S.), en la Universidad de Heidelberg, Cambridge, Bergen (Noruega), Sydney (Australia), Galileo (Guatemala), y Copenhagen (Dinamarca). Herramientas:.LRN dispone de recursos para hacer posible una comunidad de usuarios en un entorno de trabajo colaborativo.. Soporta la administración y registro de grupos, portal, carga de ficheros, calendario, foros, FAQ.s, noticias, páginas personales de los alumnos y encuestas..lrn 3 (a partir de mediados del 2004) incluirá, entre otras muchas funcionalidades, soporte a los estándares mas extendidos (IMS, SCORM, OKI...) y nuevas funcionalidades. Conclusiones La herramienta Open Source recomendada de las presentadas a día de hoy es sin duda Moodle, excepto en casos puntuales en los que puede recomendarse FLE3 o Mimerdesk debido a sus características especiales: FLE será la opción preferente para cursos o proyectos basados en resolución de problemas, y Mimerdesk lo será para proyectos colaborativos. En todos los demás casos, se optará siempre por Moodle debido a su superioridad en cuanto a número de herramientas, estabilidad y expansión. Aún así, WebCT sigue siendo superior en estos aspectos al compararla con Moodle. Keywords: elearning, OpenSource, LMS, educación a distancia.

187 APORTACIONES DE LA COMUNIDAD DE MADRID AL SOFTWARE LIBRE. UNA PERSPECTIVA EDUCATIVA I. Ali Gago, J.Q. Vargas Ibáñez Área de Tecnologías de la Información y la Comunicación. Consejería de Educación de la Comunidad de Madrid; España. ismail.ali@madrid.org Recientemente, diversas administraciones locales y regionales en España han desarrollado distribuciones de sistemas opertivos alernativos a los sistemas propietarios, fundamentalemente dirigidos al mundo educativo. Dichos sistemas trataban de reducir el excesivo coste en licencias pagado por las administraciones educativas y contribuir al desarrollo de entornos alternativos y abiertos que permitieran independizarse de corrientes mayoritarias. Consciente de todo ello, y siguiendo la línea abierta por otras Comunidades Autónomas en España, la Consejería de Educación de la Comunidad de Madrid ha desarrollado su propia distribución de un sistema operativo y aplicaciones de código abierto. Se ha puesto especial enfasis en incorporar todas aquellas aplicaciones necesarias para impartir los contenidos de Informática incorporados en los curricula de la enseñanza no universitaria y aquellas aplicaciones educativas y entornos de desarrollo que permitan, al profesorado no especialista, la utilización y la elaboración y disribución de contenidos educativos en formato digital. Se ha elegido como soporte para esta distribución aquel que ha permitido incorporar el sistema operativo y todas las aplicaciones reseñadas y se ha intentado que dicho soporte respete al maximo la configuración de los equipos informaticos de los posibles usuarios, así como su eventual convivencia con otros sistemas ya instalados. Keywords: Educación, Software, Administración, Licencias

188 LOS LMS OPEN SOURCE ELIMINAN UNA GRAN BARRERA AL E-LEARNING por Albert Calvet Ribé Socio Director CV&A Consulting SL Calvet 36, 4º 4ª E Barcelona Fax Tel Ponencia presentada al OPEN SOURCE WORLD CONFERENCE 2004, FEBRERO DE 2004 Cuando una empresa desea implementar un programa de elearning empieza por preparar un análisis de las necesidades a cubrir, las características de la audiencia a la que se dirigirá, el establecimiento de unos objetivos y, en definitiva, la planificación de las actividades y recursos a emplear con el fin de lograr el cumplimiento de dichos objetivos. Luego realiza el diseño instructivo de los cursos y prepara los correspondientes contenidos. Por entonces empieza también la selección de una plataforma de gestión de la formación o LMS, su adquisición, instalación y puesta en marcha. Después se preparan los tutores, se matricula o registra a los alumnos y finalmente se inicia la formación, cierto? Falso. Lo que ocurre la mayoría de los casos es que se empieza por buscar una plataforma, es decir, el LMS (Learning Management System). Se cae entonces en la peor trampa posible, una trampa que alarga, encarece y dificulta la implementación de la actividad de elearning. Por qué la selección del LMS se convierte en una barrera?. Por varias razones. 1. La mayoría de los LMS son aplicaciones complejas y con largas listas de funcionalidades que naturalmente difieren sensiblemente unos de otros. 2. Sin un plan de negocio sobre la actividad del elearning es imposible preparar una lista de requisitos que no resulte una carta a los reyes magos y se hace prácticamente imposible evaluar las diferentes alternativas que ofrece el mercado. 3. Los elevados precios de las plataformas hacen que el riesgo de la elección sea tan alto que se llega a demorar la decisión varios años. 4. En el caso de las empresas de menor dimensión, este coste tan elevado consume todo el presupuesto de elearning y más. El resultado final es que antes de empezar realmente a hablar de elearning hay que superar estos impedimentos. Pero cuando una situación se enquista tanto es extraordinariamente difícil resolverla, tanto al personal de la empresa como a los consultores externos. Afortunadamente, existe una solución. Los LMS Open Source con un coste de licencia nulo y unas prestaciones similares a las de los productos comerciales están permitiendo ver el problema de la selección del LMS de una forma nueva que cambia las reglas del juego. Se examinan las alternativas principales y prestaciones de los LMS de esa categoría, se muestra que han alcanzado un nivel de calidad más que adecuado y se detallan las exigencias operativas que requieren: hardware, instalación, soporte y mantenimiento.

189 Se resume cual es la difusión en España de los LMS Open Source y las posibilidades futuras, teniendo en cuenta que el tamaño de las empresas en nuestro país es más bien reducido, lo que hace aún más atractivas estas soluciones. La conclusión de todo esto es que el Open Software permite romper la barrera de elección del LMS y hace posible decirles a las empresas. Como el trabajo de seleccionar una plataforma no es en realidad una actividad de elearning, cuanto más sencillo sea y antes termine antes se podrá empezar a trabajar en el real y difícil planteo de las cuestiones del elearning.

190 Día h Sesión Auditorio: Software Libre en Europa Moderador: Representante Comisión Europea DG INFSO Unidad de Software Participantes Barbara Held Arnold Reinders Flavia Marzano Morgens Kuehn Pedersen Pjet Severljnen Tunde Kallai Greert Didden Fed. Ministry of the Interior Ministry of the Interior Italian Provinces Unión Copenhagen Business School 3 Roses/CEMR Hungarica Sprl EC proyects manager

191 Ponente Arnold Reinders In the Netherlands there is an increasing political pressure to implement Open Standards and Open Source Software in government. This would put the public sector in charge of its own software policy, increase the accessibility of government information and increase competitiveness within the software market. In response to that the Ministry of the Interior and the Ministry of Economic Affairs have developed a policy on how to handle Open Standards and Open Source Software. Key issue of this policy is that Open Source Software cannot exist without Open Standards. The policy that is now being implemented on open standards is: 1. organisations in the public sector should use open standards; 2. if they have implemented their own closed standards they should make them open; 3. discuss with the European Commission whether they can use their market power to open proprietary standards from software vendors or to implement open alternatives. The policy for open source software is: 1. open software may not be discriminated in favour of proprietary software; 2. develop open source software where it not exists; 3. to encourage public sector organisations to develop their own software as open source software. The goal is to have the Dutch government standardized on Open Standards by 2006 and a freedom of choice in operating systems and applications. This goal however, is hampered by uncertainty about reliability, support and liability of Open Source Software by government IT-managers. In order to reach that goal a competence centre has been instituted to support government organizations in implementing this policy. Some of the tasks of this competence centre will be: - communicate on Open Standards and Open Source Software - creating a catalogue with Open Standards; - creating a license model for releasing government software along the lines of GNU- GPL; - creating a software exchange site where government organizations can exchange their own software. We try to join or initiate European initiatives because many developments take place on an international level rather than at a national level. In the latter half of 2004 the

192 Netherlands chairs the EU and we intend to organize several events to promote open standards and open source software.

193 Tunde Kallai evillages - demonstrating exploitation of public sector information on an open source platform - RTD project proposal document ( ITEM 2003) - Hungary Rationale and Objectives Short summary of the project eeurope2005 from the European Commission sets several concrete goals and action lines to speed up the process creating a digital Europe. Several action lines concerning high performance in a constantly changing world with increasing convergence between data- and telecommunication, action lines concerning the needs of high security on the global net, Internet oriented general solution - co-operating with mainframe proprietary systems - reusing experience and well proved knowledge to shape the new digital administration. In that context we see it as a major challenge to speed up the process of an open digital administration at European level. It will only succeed - by cross-border co-operation and if every public entity in Europe organise their public information - general and specialist orientated information as well - and maybe especially - as specific information/data of persons or companies - in open data structures to be enhanced with high security by Internet. Content and data are still becoming ever more important. The main intention should be to develop solutions and content which as fast a possible can be implemented from governmental users and citizens. Therefore we see a strong connection from organised data and information to directly access by Internet as a base of new digital economy - and in private-public co-operation where both international orientated and at the same time private and public used solutions and content are preferred. 1.2 The priorities of the evillage -initiative: citizens and companies own (personal) secure portal - homepage for handling information and services by Internet (Informer SA Greece) interactive/dynamic forms on demand guiding the citizen (and the front service officer) through an optimal flow ( SUSE LINUX Hungary) structured access on demand to all legislation, rules and guidelines (in digital form) for citizens and companies by the interactive form ( Ministry of Interior Affairs) secure reuse of relevant information about the citizens, properties and companies (from the classic, central systems) all needed information on the right step in the flow (from the best practice in the administration, (Small regions from South-Hungary)

194 most (except local information) electronic information (regulations, legislation, procedures etc.) in standard built on net-world-wide best administrative practice, provided by central information provider (Ministry of Interior Affairs ) highest level of automatic integration between data from forms and the most used electronic case-handling systems (Informer SA, SUSE LINUX) ) and a broad extent of already used governmental data processing solutions, formerly only in use for experts, internal government users and not - net oriented data transport (Office of State Secretary for Rural Development) overall technical architecture building on integration's and OS-platform for structuring information to be directly accessed by Internet (SUSE-LINUX) one basic system which suits the needs of both citizens, companies, employees, employers, networkers, other authorities and organisations to create equality by providing knowledge on demand both for specialists, administrators, citizens and companies (HadroNet Ltd, Informer SA) 1.3. The evillage -project should give the experiences about the RTD goals : how our concept can be realised as a general cross-border-concept in Hungary and in the accession countries? are the contents of key-data-sets the same in Hungary? how to find new methods for mutual identification of key-data? how can we adopt best practice to use legislation, rules and public guidelines in the concept - in spite of the fact that familiar public services are carried out by different administration levels - in different organisations and surroundings - using the possibilities and rationales in digital services? how can our platform, data structure and used standard for data exchange secures a decentralised creation of knowledge and data for reuse for public entities in other EU member states? how can our planned structure for charged data and services be best-practice to create new markets in the egov area? 1.4. Advantages The benefits are among others: For citizens, companies and networkers: V Better, cheaper and higher quality information - both in general and considering personal files V Self Service - "One-Stop-Shopping" most services as seen from the users can be found in one place. Electronic mail and forms gives far quicker means of communication and the digital architecture makes it possible to simplify the forms making them easier and

195 quicker to fill out. The dynamic form guides the user through an optimal process (best practice). V New democratic means of expression. The direct access, through , to the political representatives is already in place. In the near future it will be possible to establish electronic debate forums where the citizens can get in a dialogue with each other and the politicians about specific subjects, for example local area planning. For administrations and citizens, companies and networkers: V Better real time overview for both citizens, public and private users at the same time: regulations, information about persons and projects etc. V Better case handling: deadlines, work flow. Exactly because it will be possible to send electronic documents from one case worker to another and to build in automatic alarms, which alerts the employee when a deadline is getting near, the work process becomes easier and faster. The simplified forms results in fewer errors and hereby quicker processing. V Closer contact with the citizen: electronic mail, forms and direct access to own cases V Better means of education/reduction /lifelong learning through flexible tele-education V Rationalisations V Better overview of bottlenecks and critical paths in the whole administration. In our project the goal is to link together different forms from several organisations. Today many applications to one organization demand support documents from one or more third party organization and therefore the total service time is not only measured through one application but a series of applications for one and the same "citizen-case". The relationship of those forms is deciding the total service time for a citizen s application for a service. This - we believe - will lead to a number of important changes in the relationship between citizen and civil servants Budget Duration (in months) 5 8 Total Eligible 6 EUR Costs Contribution requested from the Ministry of Information Technology 7 EUR

196 1.6. Deliverables DELIVERABLES LIST Reference No. Title of Deliverable Status Expected Delivery Date D.2.1 Technical Infrastructure handbook Confidential 2 D.1.1 Progress Report 1 Restricted 3 D.3.1 OS Forms ready and integrated in the OS based Confidential 3 solution D.4.1 OS Form is ready Confidential 3 D.5.1 Digital signature solution operating and Confidential 4 integrated with OS Form D.6.1 Distribution and maintenance of the digital Public 4 signatures used in the project operating D.6.2 User groups identified and have started using OS Public 4 Form D.7.1 Web enabled showcase illustrating the main Public 5 innovations of the intended services D.7.2 First dissemination and good practice workshop Public 5 and report D.1.2 Progress Report 2 Restricted 6 D.7.3 Second dissemination and good practice Public 6 workshop and report D.8.1 Plan for exploitation of the products developed Confidential 7 D.1.3 Progress Report 3 Restricted 7 D.7.4 Second dissemination and good practice Public 8 workshop D.7.5 Final report Public The Cost Models in EURO FC Informer EUR/month - SUSE LINUX 5000 EUR/month - HadroNet Ltd EUR/month AC - Ministry of Interior Affairs 3500 EUR/Month - The Office of the State secretary for the Rural development - Regional Development Agency of Small region (South-Hungary Region)

197 1.8. The budget Partner name Own contribution Requested Total budget fund Ministry of Interior Affairs The Office of the State secretary for the Rural development Regional Development Agency of Small region Informer 12, SUSE LINUX HadroNet Ltd 7, Total EUR EUR EUR

198 Is Linux ready for space applications? Sebastián S. Prieto, Ignacio G. Tejedor, Daniel Meziat L., Aitor V. Sánchez Computer Engineering Department (University of Alcalá) Ctra. Madrid-Barcelona, km 31,600, Alcalá de Henares (Madrid), Spain Tel.: , Fax: {ssp, ngt, meziat, Abstract The main goal of this paper is to determine the readyness for space-grade applications of the open source approach to software development in general and the Linux operating system in particular. We will begin explaining what does make space systems different from other embedded environments and the technical hurdles that it poses to application software and OS development. We will then explain the advantages that can be obtained from an open source software development model and the use of the Linux OS, as well as its theoretical disadvantages. Afterwards, some examples of actual use of Linux and free software in space will be provided, establishing the state of Linux in space nowadays. And finally, we will briefly expose the linux and open source efforts related to space applications that we re involved in. 1 Introduction Outer space is an attractive environment for almost anybody, not only for obvious scientific and economic reasons, but also for the mystery and awe it traditionally inspires. However, space missions have a lot of technical hurdles to overcome and its problems have traditionally been solved with highly specialized hardware and software, which leads to high reliability but also very high cost and long development times. The appearance and great success of open source development philosophies and the Linux operating system, specially in the scientific community, leads to the main question of this work: Is Linux in particular, and open source in general, applicable and ready for space in order to reduce cost and development times? We will try to address this question and show that the answer is a resounding yes. 2 Space missions primer Computing systems are used in several parts of a space mission, each with different technical issues to solve. They can be classified using different criteria, such as radiation exposure, possibility of manual maintainance, reliability levels required, power and space constraints, etc. Typically the five following items are included in such classification: 1. Systems onboard unmanned space vehicles such as satellites 2. Systems onboard manned vehicles such as space stations, capsules or other spaceships 3. Systems onboard planet exploration vehicles, such as exploration rovers 4. Ground station systems 5. Other computer systems, such as laptops aboard space stations to asist astronauts in scientific or maintainance tasks We will briefly explain such criteria and the technical challenges they involve in the following subsections. Then we will focus in systems types defined in items 2 and 3 of the previous list, which share a few characteristics that make them specially difficult and expensive to produce, and as such, most interesting to adapt Linux for. 2.1 Technical hurdles Several technical difficulties arise in space environments. Some of them are inherent to the place they perform their duties, such as outer space or a distant planet: Maintainance is difficult if not impossible, so highest reliability is a must. Other constraints are due to physical limitations (in terms of both size and weight) of the launch 1 This work has been supported by Comisión Interministerial de Ciencia y Tecnología (CICYT) of Spain, grant ESP C02-01

199 and/or transporting vehicle. Moreover, power consumption is usually limited too, since power sources are also weight and size limited, be it solar panels or any kind of battery. However, in space systems not protected by a planetary atmosphere or the stronger shields of a manned spacecraft, radiation is probably the biggest problem to solve. Radiation can penetrate the vehicle s shielding and alter the contents of memory cells, or even destroy electronic circuits causing latch-up effects of the total failure of an element. A lot of effort is put into avoiding this kind of effects, including: Using radiation-hardened versions of electronic components Adding hardware EDAC to buses, memory modules and internal CPU circuits Duplication of system buses Using redundant architectures for some or all system components Additionally, electronic components are more sensitive as the level of integration gets higher, so enhancements in speed, power and capacity derived from these technological enhancements can t always be used. 2.2 How is software affected? Ultimately, the technical issues described before end up affecting the way software is produced and used in several ways. First of all, the reliability concerns derived from radiation and the impossibility of maintanance causes very few processors and architectures to be oficially validated by Space Agencies. Sometimes, completely new architectures are designed for space applications (i.e. MAS281 processor), which usually means there s no OSes and very few tools readily available. Another option is to produce radiation-hardened versions of general purpose processors such as x86 and PowerPC. However, these architectures lack special advanced features of space architectures (such as EDAC and native redundancy support). And not every popular architecture has space versions, so choice of OSes and tools is reduced. Also, in many cases where the architecture offers space features, system software needs to be aware of them; for example, hardware EDAC and redundancy must be supported, and this is usually not taken into account in generic OSes. And other techniques such as failed memory bank switching, built-in-tests and such must be also taken into account. Finally, due to performance and capacity constraints, software footprint and speed optimizations are of great importance. Even power draw must be frequently taken into account. All the above causes the hardware and software to undergo extensive testing and validation processes, which ultimately means that very few (and expensive) OSes or runtime environments, such as ADA, that qualify for space use. 2.3 Embedded space systems As stated before, of all possible space systems unmanned space vehicles present the most daunting difficulties, and as such, they are the most interesting case of study for Linux suitability and the use of open source development philosophy. These difficulties are mainly: They are extreme embedded systems in terms of power, size and weight constraints They are usually subject to high radiation environments Manual maintainance is impossible or near to impossible, so reliability must be top-notch We will try to determine if the characteristics of Linux make it a pratical alternative to traditional, commercial and closed-source operating systems. 3 Open source in space Because of the peculiarities of space applications, space computers and software have been traditionally very special-purpose pieces of engineering. CPUs and hardware designed specially for space, and hand-coded software specially tailored for the application needs, often without any proper operating system. The use of an Ada environment as only runtime environment has been a common alternative. The need for faster development times and easier programming has made space systems evolve slowly to COTS (commercial of-the-shelf ) hardware and software. Using rad-hard versions of popular architectures such as PowerPC, and commercial, more generic and high quality operating systems such as VxWorks has allowed lower cost and faster development time, though losing a bit of the features of a fullly-customized system in terms of reliability, power, size, weight, etc. It is quite popular nowadays to use slightly modified commercial spacegrade SBCs (Single Board Computers), a commercial Real-time OS such as VxWorks and an appropriate BSP (Board Support Package) and build the needed applications on top of this platform. However cost is still very high. Operating systems and BSPs are mostly closed source, which often results in difficult debugging and programming. Moreover, development environments are usually proprietary and licenselimited, which further drags development. It is our belief

200 that many aspects of development could greatly benefit of an open source COTS operating system and platform such as Linux, in many ways. We will try to show these advantages in the following sections. 3.1 The Linux environment for space application programming From the point of view of the application programmer, open source in general and Linux in particular offers a wide range of advantages over a commercial COTS environment, not to mention over traditional programming. [7] In terms of cross-platform development, the possibility of using a development testbed with the same characteristics as the final target at the OS level, inherently speeds up testing, debugging and validation of a big amount of code that does not depend in specific target hardware details. Almost every OS functionality available in a conventional x86 PC will be available in the target system, including RT extensions; and writing software to emulate target hardware behaviour is always an option. All this accounts for lower costs and faster development. The wide range of tools, programming environments, documentation and libraries, coupled with the familiarity of a UNIX environment also makes development far more flexible. The programmer is not limited to the tools provided by a software vendor; he may practically build its own development environment. Moreover, the available open source tools such as the GNU tools are well known for its high quality and robustness. Many commercial software vendors use them themselves in their own products. Finally, there is a very important factor often overlooked; the great source of information and support that the open source community provides. Even though commercial software vendors usually provide good technical support, it can t compare with such a massive, dynamic and usually helping community. 3.2 The Linux kernel Space systems have evolved from using no operating system at all, to operating systems built from the ground up specifically for real-time embedded systems. In these systems, emphasis is put into several features: High performance High reliability Small footprint Low latency (to meet real-time constraints) Standard APIs (preferably POSIX) and wide array of IPC (Inter Process Communications) mechanisms The Linux kernel fulfills most of these requirements; it has evolved into a high performing, stable OS. The possibility of selecting which parts of the kernel to include at compile-time and the module loading capability helps minimizing system footprint. Finally, it offers a rich system call interface, and supports various POSIX APIs via the standard GNU libc. But the main weak point of Linux remains the lack of real-time features; the regular Linux kernel is non-preemptible, so return times are not guaranteed. The scheduler has very poor support for real-time tasks. and finally, the timer precision is lacking at best due to the non-preemptability of the kernel. This situation has got better in the recently released 2.6 series, but it is still not completely fine-tuned and still does not provide true real-time. However, not all hope is lost; we are talking of the vanilla Linux kernel here. There are several real-time kernel extensions and enhancements that successfully provide RT capabilities to Linux, even though they are not strictly kernel components and require special programming; this has allowed Linux to be succesfully used in hard real-time systems. Apart from providing all the functionality needed to qualify for use in an embedded environment, the Linux kernel offers advantages directly inherited from its open source nature. We will get into this in a subsequent section. 3.3 Real-time extensions As stated before, Linux doesn t do real time well at all. In order to provide RT features such as low response times, preemptability, etc., Real-time extensions available for the Linux kernel must be used. There are several alternatives the end-user can choose, depending on its needs, each with its own pros and cons. There are mainly two approaches to the real time problem in the Linux OS: The latency reduction and preemptability approach. It consists mainly in making the kernel more (or fully) preemptible, and reducing the amount of time the Linux kernel spends with interrupts disabled. This approach provides an easy programming model at the cost of making the kernel more difficult to follow, providing worse response time than other methods of providing RT and possibly decreasing throughput a bit. This is the approach used by MontaVista and the kernel preemption and low latency patches. The dual-kernel approach. It consists in placing a minimalistic real-time kernel between the hardware and the standard Linux kernel. This RT kernel intercepts interrupts and either passes them to the appropriate real-time task, or to the standard Linux kernel (which runs as a task itself). This approach ensures minimal delays and the best response times

201 possible. However it has several disadvantages: RT tasks must run in kernel space and cannot use any standard Linux services, since they run independently of it. Device drivers can t be used either. Moreover, real-time applications must be split in at least two parts: a RT task and a Linux userland task, which communicate using special RT-FIFO devices. This makes programming more difficult and takes the risk of running code in kernel space. However, this is the most popular choice and has shown very good results in real-worls applications. This is the approach taken by RT/Linux and RTAI. Even though not as polished or hassle-free as other OS kernels built with real-time in mind from the design table, Linux suceeds in providing real-time capabilities if needed, with really good performance. There are several choices (some of them commercial) for enabling realtime, and choosing the most adequate is up to the developer. 3.4 uclinux Sometimes, application constraints (physical or economical) force the developer to use hardware architectures with reduced features. In case the architecture doesn t sport a MMU (Memory Management Unit), it is not possible to use some operating systems that rely on it for a good deal of their functionality. Linux is one such operating system. However, Linux counts with a derivative specifically designed for MMU-less CPUs, called uclinux [1]. While this OS has reduced features when compared to the standard Linux kernel, it provides most of the functionality and mostly allows cross-platform development in standard Linux systems, which is still comparatively easier compared to other environments. Almost any application that works under Linux will run under uclinux, as long as a few limitations of uclinux are taken into account. 3.5 Open source philosophy implications In the previous sections we have showed that the Linux operating system is a competent alternative from the technical standpoint, both as a development environment and as a kernel executive. But we have only taken a peek at the most important feature of Linux for space applications: its Open Source nature. Using a fully open source environment (OS and development tools) automatically brings to the table the usual advantages of the open source philosophy: Enhanced robustness and security derived from the massively parallel auditing of code by thousands of users that contribute with their patches and corrections Massive amount of features and latest technology incorporated into the kernel due to code contribution; many device drivers, many supported filesystems, rich set of networking capabilities, etc Bugs are discovered faster, and patches are quickly issued compared to closed source alternatives Code sharing speeds up development of own applications and provide a great information resource Additionally, open source software provides a great advantage in this type of software developments: Everything (OS kernel or tools) can be freely and easily modified to suit the needs of the specific application or platform. If the kernel scheduler doesn t perform well, one can tune it or rewrite it. If a device driver needs tweaking, it can be modified. If we need new drivers, programming and debugging them is easier. Customization of kernel or other system software is taken one step beyond the possibilities offered by commercial closed-source OSes and development environments. Finally, as was our own situation, if a hardware architecture is not yet supported, it is possible to perform a port to such architecture. This is simply impossible with closed source operating systems. 4 State of Linux in space In the following section we will first expose processor architectures in which Linux is known to run. Afterwards we will mention some commercial distributions of development kits (SDKs) and customized Linux kernels suited specifically for embedded and space applications, in case the developer doesn t want to build everything by himself. Finally we will mention some real space missions in which Linux has been used (or is projected to be used) in one way or another. 4.1 Current space architectures in use and Linux support As stated before, nowadays it s very usual to use radiation hardened versions of regular CPUs to reduce cost and development time. These versions are virtually identical to their more mundane counterparts, so if Linux runs in a particular architecture, it will run in the rad-hard version with no more modifications than those required to adapt to the particular SBC. The following is a relation of current or near-future space CPU architectures and their their corresponding regular commercial versions (if any): PowerPC architecture: RHPPC (PPC603), RAD6000 (RS/6000), RAD750 (PPC750)

202 SPARC architecture: ERC32 (V7, no MMU), LEON2 (V8, not yet commercially available) MIPS family: Mongoose-V, RH32, Harris RH3000 (all based in the R3000 core, no TLB) Intel x86: Rad-hard versions of standard IA32 CPUs (80x86, Pentium) All these architectures have available Linux ports (or uclinux in case or MMU-less designs) for the commercial version of the related CPU architecture, so specific Linux ports already exist or are potentially feasible. One notable exception was the ESA-approved ERC32 architecture; even though SPARC ports of the Linux kernel do exist, they are targeted at V8 and V9 versions, and there is support for specific V7 machines with MMU (mainly Sun4/300). LEON2, an architecture not already available in commercial silicon, already has Linux ports. [15] 4.2 Commercial Linux development products Even though Linux and most development tools are completely free, some companies offer development kits and tools tailored to specific needs. These packages usually include BSPs for commercial COTS SBCs, Linux kernels modified with proprietary solutions and customizations (mainly RT extensions) and assorted development tools. Sometimes these products are worth the investment, and can be considered an intermediate alternative to closed source COTS software like for example Tornado/VxWorks. However, what s really important is that its existence shows the industry s interest in developing solutions based in free, open software; and specifically the Linux environment. Some of these products are: Timesys Linux RTOS SDK. Timesys offers a complete development package including a low-latency Linux kernel with several modifications to enhance RT capabilities. It also includes a BSP claiming full driver support for up to 70 different SBCs in 8 processor architectures. Enhanced versions of the kit include an IDE (Integrated Development Environment) and profiling tools [14] FSM Labs RTLinux Pro. Developers of the original RTLinux versions, apart from offering a free RTLinux distribution, FSM Labs offers an enhanced version of Linux with realtime extensions, tailored to a variety of architectures such as IA32, PowerPC, MIPS, ARM, etc. They offer enhanced performance and features compared to the standard RTLinux distribution, and some sidekick products focused on real-time network communications [11] Montavista Linux. Montavista offers a range of Linux kits focused in embedded systems in general, including their own low latency patches to the Linux kernel, drivers and tools, supporting several processor architectures [12] LynuxWorks BlueCat Linux. Apart from offering LynxOS development tools, LynuxWorks offers a linux kit consisting of the BlueCat RT kernel (a dual-kernel RTLinux realtime Linux kernel), BSP packages for several boards and architectures and a wide range of tools and IDEs [13] Therefore, using Linux in embedded space applications doesn t necessarily mean a completely Do-It-Yourself approach; it s possible to obtain professional tools, drivers, documentation an support and on the other hand, keep all advantages of working with Linux and an open source environment. This adds even more flexibility to the developer s options, and shows the strenght of Linux and Open Source in embedded and space applications. 4.3 Efforts and Success stories In this subsection, we will summarize a few space efforts and projects where Linux has been used in one way or another FlightLinux This NASA-funded project had the goal of providing an on-orbit flight demonstrarion of the Linux software. The goals was achieved, using the UoSAT-12 mission from Surrey Space Technology Ltd. (SSTL), and obtaining a NASA Technology Readyness Level (TRL) 7 (out of 9), which stands for System prototype demonstration in a space environment. Flight Linux is a specific Linux build, with reduced footprint, and spacecraft-specific device drives included. The CPU architecture used was an Intel 80386EX, radiation hardened, with 4Mb of RAM. Support for several onboard devices was developed (i.e. the Bulk Memory device), and where COTS drivers were available they were customized to the specific implementation in the system. Examples of this customization are the CAN bus and 10BaseT drivers. This effort managed to remotely load a Linux kernel and perform a ping command and ftp up and down transfers. [5, 4] CANDOS This project is part of tne OMNI (Operating Missions as Nodes on the Internet) Project, a series of Internet-inspace experiments and demonstrations. The objective of the CANDOS (Communication And Navigation Demonstration On Shuttle) Mission was the demonstration of a

203 Low Power Transceiver (LPT), which flew as payload in the STS-107 Columbia mission. Several mission operations scenarios were demonstrated using the CANDOS communications system, using standard IP communications protocols and technologies. The onboard computer of the experiment consisted on a standard x86 computer running of-the-shelf RedHat Linux 6.1, with complete sucess JAESAT JAESAT will be a 15 kg-class amateur radio micro satellite in development by the Australian Space Research Institute (ASRI). [6] According to the project s homepage, the twin flight computers will most likely be based in COTS SBC, probably StorngARM 1110-based running Linux. Dual-redundant components are used to account for the use of COTS electronics, which is likely to suffer from degradation due to space environment Linux for the ISS Although it cannot be strictly considered space applications, Linux has been chosen by the European Space Agency (ESA) for two software products which will control the rendezvous and docking operations for a servicing spacecraft called ATV. These pieces of software are GOAS and RACSI. [8] GOAS is the Ground Operator Assistant System for the rendezvous operations of ATV. It is used on ground, and is a tool to monitor the ATV mission and intervene in case of a problem, providing complex command and control to replan the entire mission if necessary. [9] RACSI (Remote ATV Control System at ISS) runs on a laptop operated by an astronaut onboard the station. It monitors and checks the ATV mission and offers the posibility to temporarily interrupt the mission and to initiate collision-avoidance maneuvers. [10] In both cases, Linux was chosen as the underlying OS for reliability, performance, portability and cost reasons Other works in progress In space timescale, where adoption of new tech is slow due to extensive validation and testing, Linux is a rather new technology. We will definetly see Linux-based missions flourishuing in the next few years, as Linux matures as a embedded real-time platform. One such example of could-be Linux based mission is the next generation of NASA s Mars Exploration Rover (MER), due to launch in Current MER missions, which will hopefully arrive to Mars in January 2004, are powered by Windriver s VxWorks RTOS. But a prototype vehicle of the next generation MER has already been demonstrated by NASA s Jet Propulsion Laboratory (JPL) and Sun Microsystems as a proof of concept, powered by TimeSys Linux RTOS and JTime real-time Java virtual Machine, running control software written in Java. This is a great proof of the validity of the Linux operating system for mission critical flight software. 5 Our contribution to push Linux into space: ERC32 uclinux port Our workgroup has participated in several space programmes, and has dealt with some different software projects for flight computers. In the process we have worked with several development environments, from fully hand-made programming to Ada environments and VxWorks in a variety of platforms (i.e. MAS281 and PowerPC). We have dealt with the problems of proprietary systems, and closed-source kernels, BSPs and drivers. A few years ago, ESA pushed an initiative to generate an open platform, hardware and software, to develop space applications in order to reduce development time and cost [2]. In the process, a 32-bit, high performance and open hardware architecture was validated: ERC32. It is a SPARC V7 CPU and combines specific for-space features such as multiple EDAC mechanisms, redundancy support and radiation hardness, with the advantages of being fully compatible with a commercial and open architecture such as SPARC. The software part coming out from the initiative was a RT kernel (RTEMS), an open Ada environment (Open Ravenscar), and adapted gcc tools. However, RTEMS lacks the popularity of the Linux operating system and environment, so we decided to start an effort to port Linux to the ERC32 architecture. [3] ERC32 is a MMU-less design, so porting the regular Linux kernel is not possible. Instead we have ported the uclinux variant to the Tharsys ERC32 SBC that we had available. 5.1 Status uclinux 2.0 has been sucessfully ported to the ERC32 platform with standard functionality; all system calls are supported (with the typical limitations of uclinux), it is ROMable (works both from ROM and RAM after ROMto-RAM copy). There is support for several board devices, and work is in progress to produce an ethernet driver for the included SONIC ethernet controller. Also, a reasonably usable development environment consisting of the usual GNU tools has been produced. However, the port is complete only in a basic form; some ERC-32 specific (i.e. non-sparc V7 standard) features are not yet supported, such as EDAC error handling, RAM bank switching handling, etc. and some board

204 devices such as the VME interface is not supported either. for these and other reasons, it is already a work-inprogress. 5.2 Future work These are our planned future developments for the ERC32 Linux port: Full SBC driver support Real-time extensions Upgrading to uclinux 2.6 and integration in the main Linux 2.6 kernel tree Enhancements to the development environment to ease application programming and testing 6 Conclusions We believe there are clear advantages in developing space software using open software in general, and Linux in particular. Having direct access to source code is a great avantage in a number of ways; Bug fixing by the end-user, higher degree of customization and easier debugging being some of the most relevant. On the other hand, with the addition of RT extensions and the support of POSIX APIs, Linux offers a complete set of features, placing it at the level of other COTS software solutions. Additionally, the Linux development environment offers great flexibility, and the possibility of cross-platform development and testing in standard PCs makes the technology more accessible and cost-effective. Finally, we should not overlook the cost reduction derived from the use of free software and royalty-free components. For all this, we must conclude that Linux will be used more and more often in the future in space applications, and establish itself as a strong alternative against other COTS alternatives. The recent involvement of traditional RTOS software companies as Windriver in Linux, and the appearance of companies devoted to offer real-time Linux based development kits should confirm this. References [1] Embedded Linux microcontroller project. ( [2] ESA Contractor Report, SAAB Ericcson Space, Sweden, 32-bit microprocessor and computer development programme - Final report. [3] Sebastián S. Prieto, Ignacio G. Tejedor, Aitor V. Sánchez, 2003, Porting Linux to ERC-32 Architecture, FIFTH REAL-TIME LINUX WORKSHOP, pp [4] Patrick H. Stakem, QSS Group, Inc., June 2002, FlightLinux Project Final Report. ( [5] Patrick H. Stakem, QSS Group, Inc., Oct 2000, FlightLinux Project Technical Report. ( [6] Australian Space Research Institute (ASRI) JAESAT project website ( [7] Laird, Cameron, August 2002, Open source satellite control. (Web article). [8] Ortega, Guillermo, March 1999, Linux for the International Space Station, LINUX JOURNAL, ISSUE 59 ( (Web article). [9] GOAS: The Ground Operator Assistent System for Rendezvous and Docking (Web report) ( [10] RACSI: The Remote Control of the ESA s Pre-Development Programme Automatic Transfer Vehicle (Web report) ( [11] FSMLabs RTLinux software (Commercial website) ( [12] MontaVista Linux software (Comercial website) ( [13] LynuxWorks Bluecat RT real-time embedded Linux software (Commercial website) ( [14] TimeSys Linux RTOS Software (Commercial website) ( [15] Gaisler Research, ERC32, LEON and LEON2 tools and information (website) (

205 COMO CREAR UN PROYECTO DE SOFTWARE LIBRE José Manuel Palomar Megía Caymasa El Sendero, SA, España Desde el punto de vista de la empresa privada el uso del software libre no es sólo una forma de ahorrar costes, también es un exitoso modelo de negocio para aquellos que se atrevan a abrazarlo. Sin embargo, a pesar de lo mucho que se habla de el software libre últimamente poco se habla acerca de cómo crear uno de estos proyectos y devolver a la comunidad de software libre algo a cambio de lo que ella nos ha dado. Primero es importante no dejarse engañar por mitos. Por ejemplo, la idea de que con liberar el código fuente de uno de nuestros proyectos software y publicarlo en Internet bajo alguna de las licencias de código abierto, miles de desarrolladores por Internet van a unirse al proyecto y continuar desarrollándola sin más ni más es un mito. Conseguir una comunidad de buenos desarrolladores que contribuyan y colaboren en un proyecto es muy complicado y conlleva mucho esfuerzo, un ejemplo claro de esto es Netscape. Otro mito es suponer que porque publiquemos nuestra aplicación como software libre, inmediatamente toda la comunidad vaya a utilizarlo y se haga muy popular. El software por ser libre no significa que sea bueno y los usuarios desean software de calidad y si es libre mejor. Como en cualquier proyecto software el primer paso es decidir que queremos hacer, si ya disponemos de algún proyecto software interesante podemos escogerlo para publicarlo como software libre. También podemos publicar desarrollos que hayamos tenido que abandonar sin terminar o empezar algún proyecto nuevo. Una vez sabemos que es lo que queremos hacer es hora de ponerse manos a la obra, porque el software libre no se programa sólo. Como ya dijimos antes, no esperemos a que una avalancha de programadores se peleen por colaborar en nuestro proyecto nada más publicarlo, lo normal es que durante un largo periodo, de años, la mayoría de los desarrolladores de nuestro proyecto debamos asignarlos de entre los que dispongamos en la empresa. Si somos una gran empresa esto, normalmente, no debería ser un gran problema pero si estamos en una empresa mediana o pequeña hay que saber asignar los recursos juiciosamente y es en buenos desarrolladores donde debemos concentrar nuestros recursos. Es importante que le proyecto siga vivo en todo momento y mientras la comunidad de desarrolladores de nuestro proyecto no madure debemos ser nosotros quienes la mantengamos. Contra menos invirtamos en su desarrollo menos posibilidades hay de que finalmente sea exitoso. También es importante que el código que se desarrolle esté bien documentado, la documentación hace la diferencia, sobre todo si nuestro proyecto consiste en algún tipo de librería o servicio que deba integrarse o utilizarse por otros desarrolladores. Además el software bien documentado hará más sencillo que programadores externos colaboren con el proyecto. El último paso antes de empezar a distribuir nuestro proyecto es decidir la licencia bajo la cual vamos a distribuirlo. Tenemos muchas opciones que van desde las más libres como la GPL, LGPL o Apache o algunas más restrictivas como la utilizada por Sun Microsystems o Netscape. Todo depende de que grado de libertad de uso queremos dar

206 a terceros y del nivel de compromiso que queremos ofrecer a la comunidad, personalmente prefiero GPL, la licencia de software libre por excelencia. Ya estamos listos para distribuir nuestro proyecto para lo cual la vía más adecuada es fundar un sitio en Internet. Dicho sitio debe albergar todos los servicios complementarios a nuestro proyecto, estos deben ser al menos una web, listas de correo y un repositorio de código. En el sitio web vamos a publicar los anuncios de los progresos del proyecto, su documentación y las distribuciones binarias y de código fuente del mismo. Las listas de correo nos servirán como vía de comunicación con los usuarios y entre los desarrolladores y a través de ellas ofreceremos soporte gratuito sobre el proyecto. Por último y no por ello menos importante el repositorio CVS donde ir almacenando el código de la aplicación a medida que se va desarrollando, este repositorio debe ser público si queremos que desarrolladores externos colaboren programando la aplicación. Además podemos disponer de otro tipo de servicios, como foros, que son una buena alternativa a las listas de correo o un Wiki. Si no disponemos de recursos propios para montar todos estos servicios de forma autónoma podemos usar uno de los muchos hospedajes gratuitos que están a disposición de los proyectos de software libre, de los cuales mi consejo es Publicitar el proyecto es la parte más sencilla, simplemente hay que anunciar el proyecto en los directorios de software libre que existen en Internet, como por ejemplo Ya sólo queda una cosa, trabajo, trabajo y trabajo. Hay que tener paciencia y ser muy constante, son muchos los proyectos que se empiezan pero pocos llegan a su madurez y la única forma de conseguir esto es con la constancia y el trabajo. Mucho se habla hoy en día sobre el software libre, sobre sus usos y sobre sus posibilidades comerciales. Es hora de dejar de hablar empezar a contribuir. Keywords: proyecto, software, libre, sendero

207 PROYECTO ANDALUSÍG, dentro del Sistema Integrado de Información Agraria de Andalucía (SIIA) Alvaro Zabala Ordóñez1, Marco Antonio Fuentelsaz Pérez1, Antonio Muñoz Rastrero1, Sergio Baños Calvo1, Borja Mañas Alvárez1 1: Empresa Pública Desarrollo Agrario y Pesquero. El Sistema Integrado de Información Agraria de Andalucía es un programa de actuaciones que surge a raíz del Plan de Modernización de la Agricultura Andaluza, cuyo objetivo es obtener una mejora de los sistemas de información desde y hacia el sector agroalimentario, como herramienta de apoyo al proceso de toma de decisiones. En un primer momento, la aplicación GIS del SIIA fue desarrollada como un Sistema Abierto e independiente de la plataforma, frente a las tendencias predominantes dentro del mercado GIS, que apuntaban claramente hacia el software propietario. En los últimos tiempos, la tendencia en el campo de desarrollo de software se está invirtiendo, y ha emergido con gran fuerza el movimiento del Software Libre. La Junta de Andalucía ha sido, junto con la Junta de Extremadura, una de las primeras administraciones públicas en apostar por esta filosofía, al ser consciente de las importantes ventajas que aporta tanto para la sociedad como para las empresas del sector, que se pueden aprovechar de las sinergias existentes. En ese sentido, la aplicación GIS del SIIA se ha encontrado en una posición inmejorable para aprovecharse de los beneficios del movimiento del Software Libre, al estar concebida como un sistema abierto y estar desarrollada con la plataforma Java, plataforma de desarrollo independiente tanto del entorno hardware como del sistema operativo que dan soporte a las aplicaciones. Esto hace posible, por ejemplo, que el SIIA pueda funcionar sin ningún esfuerzo adicional en sistemas operativos como GuadaLinex o Linex. En un primer momento, el SIIA ha hecho uso de numerosos proyectos de carácter libre, distribuidos bajo diferentes tipos de licencia (GPL, Apache) para incorporar funcionalidades y servicios soportados por estos. No obstante, para la consecución de la implantación de los procesos de negocio a los que el SIIA debe dar soporte, se han realizado una serie de desarrollos propios, partiendo de productos libres ya desarrollados. El siguiente paso dentro de esta decidida apuesta del SIIA por el Software Libre será la distribución de estos desarrollos bajo algún tipo de licencia libre (GPL, LGPL, Apache, etc.) Palabras Clave: SIIA, Software Libre, Java, GIS

208 PROYECTO ANDALUSÍG, dentro del Sistema Integrado de Información Agraria de Andalucía (SIIA) Alvaro Zabala Ordóñez1, Marco Antonio Fuentelsaz Pérez1, Antonio Muñoz Rastrero1, Sergio Baños Calvo1, Borja Mañas Alvárez1 1: Empresa Pública Desarrollo Agrario y Pesquero. PARTE I: INTRODUCCIÓN Y MOTIVACIONES. 1) El Software Libre como elemento clave para el impulso de la Sociedad de la Información en Andalucía. La Junta de Andalucía, consciente de la importancia que las Nuevas Tecnologías están cobrando en la sociedad actual, y con el objetivo de impedir la aparición de la denominada brecha digital, que incremente las desigualdades como consecuencia de la dificultad de acceso a las tecnologías de la información, está tomando una serie de medidas encaminadas al impulso de la Sociedad de la Información. Estas medidas, materializadas en una serie de planes como el III Plan Andaluz de Investigación, o el Plan Info-AlAndalus: actuaciones estratégicas para el desarrollo de la Sociedad de la Información en Andalucía, alcanzaron su punto culminante con la publicación del DECRETO 72/2003, de 18 de marzo, de Medidas de Impulso de la Sociedad del Conocimiento en Andalucía, en el BOJA de 21 de Marzo. El principal objetivo de este decreto es poner las Nuevas Tecnologías al servicio de los ciudadanos andaluces, para obtener una mejora en la calidad de vida, en el equilibrio social y por consiguiente en la productividad. Para ello, el decreto se traduce en varias medidas que buscan alcanzar una serie de objetivos específicos, necesarios para alcanzar el mencionado objetivo principal: - Facilitar el acceso a Internet a todos los ciudadanos, y la apertura de este canal telemático a los servicios que presta la Administración (e-administración). - Adaptar servicios básicos como Educación, Sanidad, Bibliotecas y Fondos Documentales, etc a las tecnologías de la información, con los beneficios potenciales que ello conlleva. - Garantizar el acceso de todos los andaluces y andaluzas a las tecnologías de la información y las comunicaciones. Dentro de las medidas propuestas en el Decreto para la consecución de este último objetivo, como implantación de puntos de acceso a Internet para ciudadanos, buzón de correo gratuito para mayores de 14 años, etc. destaca dentro del ámbito que nos ocupa la difusión de la utilización del Software Libre. De esta forma, el artículo 31 de este decreto establece los siguientes puntos: - En las adquisiciones de equipamiento informático destinado a los centros docentes públicos para su uso en actividades educativas, se exigirá que todo el hardware sea compatible con sistemas operativos basados en software libre. Los ordenadores tendrán preinstalado todo el software libre necesario para el uso específico al que estén destinados.

209 - El equipamiento informático que la Administración de la Junta de Andalucía ponga a disposición en los centros de acceso público a Internet utilizará para su funcionamiento productos de software libre. - La Administración de la Junta de Andalucía fomentará la difusión y utilización orientadas al uso personal, doméstico y educativo de software libre debidamente garantizado. A tal fin se establecerá un servicio de asesoramiento a través de Internet para la instalación y uso de este tipo de productos. La materialización de todas estas medidas ha sido el proyecto GUADALINFO. Este proyecto ha sido impulsado por la Junta de Andalucía, con la colaboración de varias consejerías y contando con participación privada, y su objetivo básico es la creación de centros de acceso público a Internet en banda ancha para municipios de menos de veinte mil habitantes. Uno de los pilares sobre los que se está desarrollando este proyecto es el sistema operativo de carácter libre GUADALINEX. GUADALINEX es una distribución del sistema operativo GNU/Linux, basada en una de las distribuciones libres más populares de éste: Debian. Al desarrollar una distribución propia como ésta, la Junta de Andalucía obtiene la capacidad de soporte necesaria para dar servicio al ciudadano, y es capaz de dotar a ésta de la facilidad de uso e instalación de las que suelen carecer las distribuciones no comerciales normales. GUADALINEX es la principal muestra de la voluntad de la Junta de Andalucía para promocionar la utilización de Software Libre, por las consabidas ventajas para la sociedad que éste proporciona. 2) SIIA: Sistema Integrado de Información Agraria de Andalucía. El Sistema Integrado de Información Agraria de Andalucía (SIIA) surgió para dar respuesta a varios de los objetivos planteados por el Plan de Modernización de la Agricultura Andaluza, elaborado por la Consejería de Agricultura y Pesca. En concreto el SIIA entronca directamente con las siguientes estrategias de modernización del plan: - Estrategia nº 8: Infraestructura de I+D+I al servicio de los sectores productivos. - Estrategia nº 9: Información como un factor clave para mejorar la competitividad. - Estrategia nº 10: Obtención de un sector agroalimentario organizado y vertebrado. - Estrategia nº 16: Una administración agraria ágil y eficaz, al servicio del sector agrario. Como podemos ver, en este plan se da una especial importancia a la información como un factor clave en la obtención de la competitividad (en el mismo sentido del decreto 72/2003 anteriormente mencionado). El SIIA permite gestionar toda la información de interés tanto para la Administración como para los distintos agentes económicos y sociales del complejo agroalimentario, manteniéndola perfectamente actualizada. Además, posibilita la realización de estudios prospectivos y el modelado de escenarios que sirvan de apoyo para la toma de decisiones en materia de política agraria. El SIIA por el tipo especial de información con la que trabaja (datos geográficos o susceptibles de ser referenciados espacialmente) cae dentro del ámbito de estudio de los Sistemas de Información Geográfica. El SIIA ha sido concebido como una herramienta para ser utilizada no solo por la administración, sino también por todos los agentes que estén relacionados con la realidad

210 agraria: agricultores, ganaderos, asociaciones profesionales, sindicatos, etc. De esta forma, el SIIA no es solo un sistema que permite mejorar la gestión interna de la administración, sus propios procesos, sino que también permite mejorar la relación de ésta con sus administrados, centralizando los flujos de información entre ambos. El sistema consigue dar servicio a esta pluralidad de usuarios con intereses tan distintos (regadíos, ganadería, forestación, acuicultura, etc.) de una forma totalmente integrada. Es decir, los datos que se ofrecen y las herramientas proporcionadas para su tratamiento dependerán tanto del ámbito abordado (los anteriormente mencionados y otros más, como concesiones de agua, catastro, etc.) como de los privilegios que tenga asignados el usuario para ese ámbito. Estos usuarios puede acceder al sistema bien a través de la Red Corporativa de la Junta de Andalucía (usuarios de la propia administración), bien a través del portal web de la Junta (usuarios externos). 3) SIIA y Software Libre. a) SIIA apuesta por la plataforma Java y los Sistemas Abiertos. Tal y como hemos comentado con anterioridad, el SIIA es un sistema de información que cae dentro del ámbito de los Sistemas de Información Geográfica (GIS), al manipular datos geográficos o que son susceptibles de ser referenciados espacialmente. Este sector tradicionalmente se ha visto dominado por el software propietario, e incluso la tendencia dominante apuesta por desarrollos basados en una única plataforma: Microsoft Windows, manteniendo un nicho de productos residuales para el resto de plataformas. Tal es el caso de ESRI, líder mundial del mercado GIS, cuyos productos en un principio estaban basados en componentes ActiveX, y actualmente en la plataforma.net. El SIIA desde su concepción se desvió rápidamente de esta tendencia, pues su objetivo principal era dar servicio a una gran pluralidad de usuarios funcionando bajo diversos entornos y plataformas. Con tal fin, el núcleo del SIIA fue desarrollado íntegramente con la plataforma Java. Gracias al empleo de la plataforma Java, un mismo núcleo dio soporte a servicios heterogéneos que debían funcionar bajo diferentes entornos. Teniendo en cuenta la supremacía de la familia de sistemas operativos Unix en el mundo de los servidores, caracterizada por la seguridad y estabilidad, el servicio web del SIIA comenzó a funcionar en un servidor web Apache bajo un sistema operativo Unix. La lógica de las aplicaciones desarrolladas en Java era ejecutada por el motor de servlets Tomcat, también de carácter gratuito y libre. Con posterioridad el motor de Servlets Tomcat fue sustituido por un servidor de aplicaciones, capaz de ejecutar componentes EJB (Enterprise Java Beans). De hecho, el servicio web del SIIA podría funcionar dentro del entorno de ejecución de cualquier servidor de aplicaciones compatible con la especificación J2EE. Para la manipulación, tratamiento y recuperación de imágenes digitales de gran volumen, el SIIA utilizó el formato de almacenamiento de imágenes ECW. Este formato presenta una serie de ventajas que lo hacen muy adecuado para el almacenamiento de imágenes de gran resolución: - Elevado grado de compresión, al utilizar algoritmos Wavelet. - Empleo de imágenes piramidales. - Bajo porcentaje de pérdida de información (compresión no degradativa). No obstante, se trata de un formato propietario y no existen bibliotecas de programas adecuadas para la carga de este tipo de imágenes en plataformas que no sean compatibles con

211 Microsoft Windows. Por esta razón, el servicio web del SIIA se complementa con una serie de servicios distribuidos, encargados de la manipulación de imágenes y datos cartográficos, funcionando bajo diferentes plataformas. Estos servicios comparten el mismo núcleo de sistema que el servicio web, al estar desarrollados con el lenguaje multiplataforma Java. En el momento de concepción del SIIA no existían productos de carácter libre desarrollados en Java que pudiesen servir como un adecuado punto de partida para su desarrollo. En adición, la gran mayoría de productos GIS existentes en el mercado estaban orientados a trabajar con ficheros de datos o con bases de datos personales (DBase, Access), lo que resultaba inapropiado para arquitecturas cliente / servidor a tres capas, soportando varios clientes concurrentes. Por esta razón, se optó por desarrollar íntegramente el corazón del SIIA, lo que en el sector se denomina Geodatabase, a partir de las especificaciones publicadas por el consorcio OpenGIS (OGC). De esta forma, se desarrolló un modelo de clases Java (basado en las especificaciones OGC) y se creó un modelo de datos en una base de datos relacional que diese soporte persistente a las clases Java mencionadas. Gracias al estándar de acceso a Bases de Datos JDBC, el SIIA es capaz de trabajar con cualquier base de datos relacional de la que se disponga de un driver JDBC. No obstante, por razones de celeridad en la prestación de servicio la función de renderizado de mapas fue delegada en última instancia en un producto comercial: ArcIMS de la casa comercial ESRI. ArcIMS es un servidor de mapas que trata de seguir en mayor o menor medida la especificación OGC WMS (Web Mapping Service). Este servidor recibe peticiones en formato XML (según la misma filosofía de la especificación SOAP del consorcio W3C) y como respuesta genera imágenes con los mapas solicitados, devolviendo a su vez un mensaje XML del que, entre otra información, se puede extraer la ubicación de la imagen guardada. En adición, permite gestionar aspectos adicionales como la simbología de los elementos cartográficos, etiquetado, formato de los textos en los mapas, etc. Aún así, ArcIMS es simplemente un servidor de mapas, del que no se puede esperar que soporte las funciones de análisis y geomodelaje que caracterizan a los Sistemas de Información Geográfica, funciones que sí son soportadas por el núcleo Java del SIIA. b) SIIA consumidor de Software Libre. Además, durante este tiempo en el que el SIIA ha estado dando servicio, han comenzado a surgir desarrollos de productos GIS de carácter libre publicados bajo la licencia del software libre por excelencia: la licencia GPL. La existencia de un software de carácter libre, con gran parte de funcionalidad implementada, posibilitaba la extensión del SIIA sin tener que partir desde cero. En concreto, el equipo del SIIA fijó su atención en las suites JTS y JUMP. JUMP (Java Unified Mapping Platform) es un cliente al estilo del GIS de escritorio ArcView. Tiene funciones de edición y análisis espacial avanzado, como cálculo de áreas de influencia, cruce entre capas de polígonos, etc. Presenta una arquitectura basada en plugins que le hace relativamente fácil de extender. JUMP es capaz de cargar orígenes de datos en fichero (ShapeFile, GML), también es capaz de conectarse a una base de datos Postgre SQL con la extensión espacial PostGIS, e incluso puede conectarse a servidores WMS y mostrar las imágenes generadas por este tipo de servidor. Gracias a su arquitectura extensible, JUMP es capaz de cargar cualquier origen de datos cartográfico para el que se desarrolle un plugin que realice esa tarea. JTS (Java Topology Suite) es una implementación de la especificación de geometrías del consorcio OpenGIS. JTS proporciona funciones de análisis avanzado como cálculo de áreas

212 de influencia, cruce de polígonos, evaluación de predicados binarios del tipo intersecta a, toca a, etc. Ambos proyectos han sido desarrollados por la empresa canadiense Vivid Solutions Inc., y han sido distribuidos con licencia GPL. Adicionalmente, el SIIA hace uso de otros productos de carácter libre, no directamente relacionados con la lógica GIS, pero sí necesarios como subsistemas de soporte para la realización de tareas básicas en todo sistema de información. De estos productos cabe destacar Hibernate, Velocity, JFreeChart, JFreeReport, o Log4J. Hibernate. Este producto libre, distribuido bajo licencia LGPL, es un potente motor de persistencia basado en la técnica del mapeo Objeto / Relacional. Un motor de persistencia es un subsistema que nos permite hacer persistentes las instancias de nuestras clases sobre múltiples almacenes: bases de datos, ficheros, sistemas heredados, etc. Además, nos permite recuperar instancias de estos objetos según diferentes criterios. Los motores de persistencia están diseñados para realizar esta labor de forma muy eficiente y optimizada, por lo que liberan a los desarrolladores, acostumbrados a trabajar con clases, de tener que trabajar con conceptos relacionales. De forma paulatina, el corazón del SIIA se está migrando para hacer uso de Hibernate, de forma que se gestionen de forma sencilla y transparente los accesos a la base de datos. Velocity. Es un motor de plantillas desarrollado íntegramente en Java por el proyecto Jakarta de Apache. Jakarta es un proyecto que se encarga de proporcionar herramientas de carácter libre y de código abierto a la comunidad de desarrolladores Java. En vez de utilizar alguna de las licencias GNU, Apache distribuye sus productos libres con una licencia propia: la licencia de software libre de Apache. Un motor de plantillas es un subsistema que se encarga de generar las vistas de una aplicación web (código Html) a partir del contenido de una plantilla, normalmente un fichero de texto con formato. Esta definición casa perfectamente con la tecnología de páginas JSP. De esta forma, una página JSP se podría ver como una plantilla. No obstante, Velocity (y sus páginas VTL) presenta una serie de ventajas sobre las páginas JSP que nos decidieron a optar por su utilización. Entre ellas cabe destacar: Las páginas JSP mezclan la lógica de presentación con la lógica de negocio (el acceso a objetos Java), lo que se traduce en un código en espagueti difícil de mantener. Por el contrario, las páginas VTL de Velocity mantienen una clara separación entre ambas. Las páginas JSP no permiten la reutilización de componentes visuales. Velocity permite definir bibliotecas de macros de las que se puede hacer uso desde las páginas VTL. Por esta razón, las macros Velocity pueden ser consideradas como componentes reutilizables. Las páginas JSP experimentan una fase inicial de compilación (en la primera petición que reciben), lo que eleva mucho el tiempo de respuesta de los primeros usuarios que solicitan estas páginas. Por el contrario, las páginas VTL presentan un buen rendimiento en todas las peticiones al no atravesar por el ciclo interpretado-traducción a código java-generación de código binario. Log4J. Es un sistema de traza de mensajes desarrollado también como parte del proyecto Jakarta, y distribuido bajo licencia de software libre de Apache. Un sistema de traza de mensajes (habitualmente conocido por su termino inglés Logging ) permite controlar la ejecución de los sistemas desarrollados, para revisar si su funcionamiento es el debido. Facilita controlar el nivel de prioridad de los mensajes generados por el programa como ayuda a la depuración, y volcarlos según diferentes salidas: pantalla, ficheros de log, tablas de

213 base de datos, etc. La última versión del JDK de Java (la 1.4) incluye un subsistema de este tipo. No obstante, en la mayor parte de entornos de producción los servidores de aplicaciones y motores de servlets no contemplan esta versión, sino que trabajan con la versión anterior. Esta política es muy prudente, pues el JDK 1.4 lleva relativamente poco tiempo a disposición de la comunidad, y no está todavía suficientemente maduro. Por esta razón, es muy útil el empleo de este subsistema de traza de mensajes de Jakarta. JFreeChart. Se trata de una biblioteca de clases Java, distribuida bajo licencia GPL, para la generación de gráficos y diagramas. El SIIA hace uso de esta útil herramienta para la generación de gráficos de todo tipo, tanto desde entorno Internet (gracias a su facilidad de exportación a formatos de imagen como PNG, JPEG, etc) como en los nuevos desarrollos de escritorio. JFreeReport. Consiste en un subsistema de generación de informes para su impresión y visualización por pantalla. A partir de documentos XML que especifican el formato que ha de tener el informe, se puede interactuar con el API Java que proporciona para dotar de contenido a dichos informes. Esta biblioteca de clases también permite generar salidas según diferentes formatos: Html, PDF, Excel, impresión, etc. Gracias a su uso, se han facilitado mucho las tareas relacionadas con el formateo de informes impresos, como selección del formato de papel, cambio de orientación, etc. JFreeReport y JFreeChart han sido desarrollados por la empresa Object Refinery y son distribuidos bajo licencia GPL. c) SIIA productor de Software Libre. Actualmente, el equipo SIIA está desarrollando una extensión del GIS de escritorio JUMP para que se conecte a su Geodatabase núcleo de la aplicación GIS del SIIA- y sea capaz de acceder a los orígenes de datos cartográficos contenidos en ella. Esta extensión se encuentra en estado muy avanzado, y de ella ya existe disponible una versión Beta. En algunas de las figuras que acompañan al presente documento se pueden ver capturas de pantalla con el funcionamiento de la aplicación. Se trata de una arquitectura cliente / servidor a dos capas, con el cliente JUMP accediendo directamente a la Geodatabase incluida dentro de una base de datos relacional. Además, se está desarrollando un servidor de datos espaciales, y una extensión de JUMP capaz de conectarse al mismo y de trabajar con los datos servidos por éste. De esta forma, estaríamos hablando de una arquitectura cliente / servidor en 3 niveles, con un middleware intermedio (nuestro servidor espacial) que minimiza el número de conexiones consumidas de la base de datos, optimiza el tráfico de red, y además aporta lógica no existente en la base de datos gracias al empleo de las clases topológicas de JTS. De este servidor ya existe una primera versión Beta, capaz de recuperar datos de la base de datos según diferentes criterios, incluso espaciales aunque la base de datos no estuviese preparada para trabajar con este tipo de datos. Estas extensiones contemplan también la posibilidad de trabajar con imágenes digitales y orígenes de datos Raster, característica de la que en un principio carecía JUMP. Actualmente se están desarrollando extensiones que permitan la edición concurrente de cartografía por parte de múltiples usuarios, el mantenimiento de diferentes versiones de un mismo elemento cartográfico (transacciones de larga duración), la implementación de reglas topológicas y asociaciones entre diferentes capas cartográficas, y funciones de análisis avanzado en general.

214 El desarrollo de estos productos se abordó tras un análisis de las herramientas de carácter libre existente, tras llegar a la conclusión de que ninguna ofrecía la funcionalidad requerida, y de que sí sería viable el desarrollo de un servidor propio, con un protocolo abierto y pública, al que se pudiese conectar cualquier tipo de cliente. El siguiente paso, una vez alcanzado un estado de madurez suficiente, será la publicación tanto del código fuente como de los scripts y utilidades necesarios para la instalación y puesta en funcionamiento del nuevo sistema, bajo una licencia de software libre. De esta forma, se pondrá a disposición de toda la comunidad de usuarios interesados un producto GIS que cubra sus necesidades, tanto de aplicaciones de escritorio (JUMP) como de servidores departamentales (Geodatabase del SIIA), y lo mas importante, independiente del sistema operativo utilizado, al estar desarrollado con la plataforma Java. 4) Descripción de la Interfaz Web del SIIA. Antes de pasar a describir cómo se ha desarrollado el núcleo del sistema, no podemos dejar de detallar algunos casos de uso de la interfaz web del mismo, de cara a ofrecer una mejor visión de la percepción que el usuario tiene de él. a) Visualización de Cartografía, y Navegación interactiva por ésta. El SIIA permite visualizar en forma de mapas los orígenes de datos cartográficos incorporados al sistema. Así mismo, el usuario es libre de modificar la escala, centro de visualización o número de capas que se le muestran. Con tal fin, todas las aplicaciones del SIIA (según el concepto de aplicación mencionado con anterioridad) ofrecen módulos para esto. FIGURA 1: CAMBIOS DE NIVEL DE ZOOM b) Consulta de Información Alfanumérica (Catastro, etc) El SIIA permite realizar consultas alfanuméricas sobre la información territorial almacenada. Para ello, proporciona módulos como los localizadores, que son asistentes que guían al usuario en su búsqueda ofreciéndole diferentes criterios de filtro para su encadenamiento. FIGURA 2: LOCALIZADORES. c) Incorporación al Sistema de datos almacenados de forma local. El Sistema también ofrece a los usuarios la posibilidad de incorporar nuevos datos para su visualización. Para ello, los usuarios autorizados podrán subir ficheros de cartografía en alguno de los formatos de intercambio soportados (ShapeFile de ESRI, GEN de Arc/Info, etc.). Estos datos solo permanecerán en el sistema mientras dure la sesión de trabajo del usuario que los incorporó, pudiendo éste realizar diversas operaciones con ellos. FIGURA 3: CARGADOR DE FICHEROS 5) Descripción de los nuevos productos en fase de desarrollo. El principal inconveniente de los clientes GIS basados en web es el hecho de que estos clientes solo reciben imágenes (PNG, JPEG, etc) de los mapas generados de lado del servidor. Como consecuencia de esto, la carga de trabajo se centra casi exclusivamente en el servidor, desaprovechándose notablemente las posibilidades de las estaciones de trabajo

215 actuales, cada vez más poderosas con la difusión del PC. Esto resulta claramente ineficiente para la realización de operaciones de análisis complejas, para las que tradicionalmente se ha recurrido a clientes propietarios, limitándose los clientes web para las tareas de visualización. Además, como los datos cartográficos reales nunca son enviados al cliente, este no puede editarlos ni modificarlos. El equipo de desarrollo del SIIA está trabajando en un servidor de datos cartográficos capaz de atender simultáneamente múltiples conexiones de diferentes clientes, gracias a un diseño multitarea concurrente. De forma complementaria, se ha desarrollado un plugin del cliente GIS de escritorio JUMP que permita acceder, mostrar, consultar y manipular los datos cartográficos proporcionados por este servidor. Adicionalmente, y aprovechando la funcionalidad de dicho servidor, se ha desarrollado otro plugin que permita a JUMP conectarse directamente a una base de datos que tenga el esquema de Geodatabase corazón del SIIA, y extraer de ésta directamente los datos. De esta forma, y aprovechándonos del mayor grado de reutilización ofrecido por los lenguajes orientados a objetos, podemos trabajar según una arquitectura cliente / servidor tradicional en dos niveles, o podemos trabajar con una arquitectura cliente / servidor en 3 capas, según se desee. En la figura FIGURA 4 podemos ver el primer paso para conectarnos a una Geodatabase con nuestra extensión de JUMP, a través del middleware propio desarrollado. La aplicación nos muestra un dialogo en el que aparecen diferentes orígenes de datos, para seleccionar alguno de ellos. Una vez seleccionado el origen, se crea una nueva capa dentro del panel de capas, y sus elementos cartográficos son dibujados en el panel de visualización de mapas, como podemos apreciar en la figura FIGURA 5. Nuestro servidor de datos cartográficos también es capaz de proporcionar datos en formato raster, según diferentes formatos. En la figura FIGURA 6 podemos ver como el cliente JUMP muestra datos de imágenes raster servidos por nuestro servidor dedicado. Para tal fin, hemos desarrollado una extensión de JUMP que sea capaz de mostrar imágenes, tanto proporcionadas por servidores dedicados como recuperadas directamente de ficheros. PARTE II: DESCRIPCIÓN TECNOLÓGICA. 1. Modelo de Clases para Datos Vectoriales: OpenGIS Simple Features Specification. El modelo de datos vectorial del SIIA ha sido desarrollado a partir de la especificación Abstract Specification: Features formulada por el OpenGIS Consortium. El elemento central de este modelo es el Feature, definido como una entidad real o abstracta cuyos atributos describen fenómenos cuantitativos o cualitativos relacionados con dicha entidad, y que es susceptible de ser referenciada espacialmente. Toda ocurrencia de esta entidad tendrá asociada dos estructuras: una geometría cuya definición es objeto de otra especificación OGC, el modelo geométrico OGC, como veremos posteriormente- y un esquema de Feature FeatureSchema según la especificación- del que el Feature es una instancia. Cada esquema de Feature tendrá asociados una serie de atributos identificados por un nombre, que tendrán asociados a su vez un tipo de dato y un valor. El siguiente diagrama de clases recoge el mencionado diseño:

216 FIGURA 4: MODELO DE CLASES BASADO EN LA ESPECIFICACIÓN DE FEATURES DE OGC. Como parece evidente, un Feature sería el equivalente a una ocurrencia de Entidad de una base de datos relacional, un FeatureSchema sería el equivalente al Esquema de esta Entidad, y un FeatureAttr sería el equivalente a un campo. A su vez, para acotar los tipos de datos que pueden tener los valores de los atributos de un Feature se introduce la clase AttributeType. El equivalente de la Entidad-Tipo o Entidad sería una FeatureCollection colección de Features- A diferencia de las bases de datos relacionales, este modelo incluye el tipo de dato Geometry, que representa las propiedades geométricas de un fenómeno geográfico, y que será utilizado, entre otros casos, para la representación gráfica de estos fenómenos en el seno de un mapa, o como base para la realización de consultas de base espacial. Qué ventajas ofrece este modelo basado en el uso intensivo de metadatos como FeatureSchema esquema del Feature- o AttributeType esquema de un atributo, formado por nombre y tipo de dato-? Un GIS, frente a otros sistemas de información, es un sistema abierto capaz de integrar nuevas fuentes de datos, procedentes de orígenes diversos y almacenadas según diferentes formatos. Gracias a este esquema de metadatos, podremos cargar nuevas fuentes de datos en el sistema, con el único requisito de que se disponga de la suficiente información sobre su esquema, incluyendo en éste la topología (punto, línea o superficie de forma simplificada) esencial para determinar la representación gráfica de los Features almacenados. De esta forma, entidades geográficas del mundo real tan poco relacionadas como Carreteras y Ríos podrán ser gestionadas por diferentes instancias de una misma clase, FeatureCollection, siendo sus ocurrencias instancias de la clase Feature. En adición, la propiedad Geometría de su esquema tomará valores de un mismo tipo de dato: el subtipo Línea, puesto que ambas son entidades de geometría uno-dimensional. 2. Modelo geométrico del OpenGIS Consortium. Como hemos visto con anterioridad, todos los esquemas de una entidad geográfica Featuretienen un atributo Geometría, cuyo tipo de dato es Geometry. Geometry es una clase abstracta raíz de la jerarquía de clases geométricas proporcionadas por la especificación OGC. El resto de clases aparecen en el siguiente diagrama de clases. FIGURA 5: MODELO DE GEOMETRÍAS DE LA ESPECIFICACIÓN OGC. La especificación OGC también establece el comportamiento que deben proporcionar aquellas clases geométricas que implementen la especificación. Destaca la inclusión de predicados binarios (operaciones de carácter booleano que relacionan dos geometrías, un ejemplo sería el predicado contenido en ) y de operaciones de análisis espacial (operaciones que se aplican sobre una geometría para obtener otra, un ejemplo sería la operación buffer, que devuelve el área de influencia de una geometría) 3. Esquema Relacional. Como ya mencionamos con anterioridad, una de las principales características de los Sistemas de Información Geográfica, y por extensión del SIIA, es la capacidad de integrar datos geográficos procedentes de fuentes heterogéneas.

217 La necesidad de que un GIS sea capaz de integrar fuentes de datos procedentes de numerosos orígenes, almacenadas según distintos formatos, es debida al tradicional problema de la falta de estándares en el ámbito de la información geográfica digital. Los Sistemas de Información tradicionales, basados en el empleo de bases de datos relacionales, no presentan este problema. Esto es así gracias a la utilización del modelo en 3 capas de ANSI y a la estandarización de los tipos de datos empleados. El modelo en 3 capas de ANSI separa el nivel lógico de la información esquema conceptual- del nivel físico esquema físico -. De esta forma, y puesto que las aplicaciones específicas entran directamente en contacto con el nivel lógico, podemos hacer cambios en el nivel físico como por ejemplo cambiar de gestor de bases de datos relacional- de forma casi transparente. Esto sucede así al menos en teoría, pues en la práctica los Gestores de Base de Datos se suelen desviar del estándar, introduciendo sus propios tipos propietarios. En el caso de las aplicaciones GIS esto no ha sucedido así. Debido a que la representación del atributo geométrico de un dato geográfico no fue estandarizada (el estandar SQL92 no contempla la inclusión de objetos), aparecieron numerosos formatos propietarios, incompatibles entre sí. Las primeras soluciones estuvieron basadas en un modelo híbridorelacional. La componente alfanumérica del dato geográfico era almacenada en bases de datos relacionales, como Dbase, (o el gestor relacional Info, utilizado por el célebre GIS Arc/Info) mientras que la componente geométrica y/o topológica era almacenada en formatos propietarios orientados a fichero. Tal es el caso del formato que durante mucho tiempo ha sido considerado estándar de facto en el almacenamiento de información cartográfica digital: el formato ShapeFile propiedad de la casa comercial ESRI. El problema surge en que, si nos movemos en otros ámbitos cambia el formato de almacenamiento considerado como estándar. En el campo del planeamiento urbanístico el formato más utilizado es el formato DXF (Drawing exchange Format) propiedad de la casa comercial Autodesk, líder mundial en el mercado CAD. También podemos encontrarnos con cartografía almacenada en formatos propietarios de equipos de medida GPS, formato propio de catastro, formatos propietarios de intercambio de particulares, formato MIGRA normalizado por el ministerio pero que nunca llegó a cuajar, etc. El SIIA es capaz de acceder a información almacenada bajo diferentes formatos gracias al empleo de una arquitectura basada en drivers, haciendo uso intensivo de los patrones de diseño Dynamic Linkage (ligadura dinámica) y DAO ( Data Access Object, objeto de acceso a datos). FIGURA 6: DIAGRAMA DE CLASES DE ACCESO A DATOS. En adición, el SIIA sigue la especificación OGC Simples Features Specification for SQL para la inclusión del tipo de dato geográfico en bases de datos relacionales que no incluyan esta característica. La especificación establece que las colecciones de datos espaciales (FeatureCollection en nuestro modelo de clases) serán almacenadas como tablas de la/s base/s de datos (siendo ésta otra característica del SIIA, la capacidad de trabajar simultáneamente con bases de datos distintas, según una arquitectura distribuida). Cada dato geográfico (Feature) será almacenado como una fila en la tabla alfanumérica, cuyos atributos serán columnas que tengan alguno de los tipos de datos definidos en el estandar ODBC/SQL 92.

218 El atributo espacial (tipo de geometría y coordenadas de los vértices que la componen) es almacenado de acuerdo con el formato WKB (Well Known Binary Format), en una tabla asociada a la anterior, la tabla de geometrías. Ambas tablas se relacionan a través de la columna geométrica, GID, siendo ésta clave primaria de la tabla de geometrías. FIGURA 7: DIAGRAMA ERD DEL ESQUEMA RELACIONAL DESCRITO. Los gestores de bases de datos más importantes (Oracle, SQL Server, Informix, Postgre-SQL, MySQL) están adoptando la especificación OGC, incluyendo tipos geométricos en el juego de tipos de datos disponible. Esta especificación es conocida como OGC SQL 92 With Geometry Types, y es un subtipo del estándar ANSI SQL Objeto-Relacional. 4. Consultas por Rectángulo: Indexación Espacial. Como consecuencia de trabajar con un modelo extendido del modelo lógico tradicional, que incorpora el componente espacial (el atributo Geometría de un esquema de Feature) surge la necesidad de realizar consultas sobre la base de datos con una nueva semántica: consultas de base espacial. Este tipo de consulta se puede expresar de la forma: Devuélveme todos los Feature (registros) de las FeatureCollection especificadas (tablas) que cumplan una determinada condición lógica (filtro alfanumérico) y además cumplan una determinada condición espacial. Las consultas de base espacial se pueden complicar tanto como exija la naturaleza del problema planteado. Así, por ejemplo, se podría plantear una consulta del tipo selecciona todas las ciudades de población superior a 5000 habitantes que caigan dentro del área de influencia de este hospital (representado como una Feature de geometría puntual), considerando un radio de 15 km. No obstante, la consulta de base espacial más simple y más intensamente utilizada en un Sistema de Información Geográfica es la consulta a partir de rectángulo: devuélveme los Features de las capas visibles que caigan dentro del rectángulo especificado. Esta consulta se realiza cada vez que el usuario modifica el nivel de zoom del área de visualización del mapa mostrado, para acercar, alejar, desplazar, etc. Puesto que parece evidente que no sería viable recorrer todos los Features (registros) de las FeatureCollection (tablas organizadas en capas) en busca de aquellos cuya geometría esté contenida en el rectángulo, se han desarrollado algoritmos de indexación espacial tanto para 2 como para 3 o más dimensiones. Estos algoritmos son análogos, para el caso n-dimensional, a los algoritmos de indexación alfanuméricos (b-tree, índices bitmap) para el caso unidimensional. Los principales algoritmos de indexación espacial existentes son el algoritmo R-Tree y el algoritmo QuadTree. Ambos algoritmos mantienen una estructura arbórea, basada en la subdivisión del espacio que abarcan todas las Feature de una FeatureCollection. Independientemente del índice espacial utilizado, el proceso de consulta espacial atraviesa por dos etapas: filtro primario y filtro secundario. El filtro primario permite una rápida selección de los registros candidatos (Features) a cumplir la condición impuesta (contenido en rectángulo). Para ello, realiza sus comparaciones a partir de aproximaciones de la geometría de los Feature puestos en juego, reduciendo de esta forma la complejidad de los cálculos.

219 El filtro secundario toma como entrada los Feature candidatos (elementos devueltos por nuestro algoritmo de indexación espacial) y realiza un cálculo topológico exacto del tipo contenido en que relacione candidatos con el rectángulo de consulta. Existen diferentes formas de implementar estos algoritmos de indexación espacial. El API JTS (Java Topology Suite), visto en anteriores apartados del presente documento, proporciona implementaciones en memoria de los algoritmos R-Tree y QuadTree. Esto implica que, una vez cargados en memoria todos los Feature de una FeatureCollection (independientemente de cual sea su mecanismo de almacenamiento persistente) podremos recuperar directamente aquellos que solapen con un rectángulo determinado. Esta forma de trabajar tiene el inconveniente de que, para poder realizar consultas de base espacial, debemos cargar en memoria todos los registros almacenados en nuestra base de datos (lo cual resulta claramente inadecuado para, por ejemplo, trabajar con FeatureCollection de parcelas catastrales, del orden de varios millones de registros). En este punto, nos encontramos con un problema derivado de que los gestores de bases de datos relacionales tradicionales (compatibles con la especificación ANSI SQL 92, como Oracle8i) no incluyen tipos de datos geométricos en su juego de tipo de datos. Como consecuencia, los algoritmos de indexación que incorporan (en el caso de Oracle índices btree e índices bitmap) no son apropiados para trabajar con la componente espacial del dato geográfico, y por consiguiente para la realización de consultas de base espacial. Como estructura de indexación espacial persistente, que permite indexar tanto registros de bases de datos como entradas en ficheros binarios de acceso aleatorio, estamos utilizando el subsistema Spatial Index Library, distribuido bajo licencia LGPL por la Universidad de California. ( Un ejemplo de base de datos relacional que considera tipos geométricos e índices espaciales es Oracle, a partir de su versión 9i. Para tal fin, incluye el tipo de dato MDSYS.SDO_GEOMETRY, que representa la clase abstracta Geometry definida en el modelo geométrico de OGC. Con esta nueva capacidad, podemos crear una tabla que soporte los registros de una FeatureCollection de términos municipales con geometrías de polígono mediante la siguiente sentencia SQL: CREATE TABLE parcelas ( parcela_id NUMBER PRIMARY KEY, nombre VARCHAR2(32), geometria MDSYS.SDO_GEOMETRY); Y podríamos añadir registros de la siguiente forma: INSERT INTO parcelas VALUES( 3, 'jaén', MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(3,3, 6,3, 6,5, 4,5, 3,3) ) ); Por último, Oracle9i permite indexar espacialmente los registros que contengan campos del tipo MDSYS.SDO_GEOMETRY mediante la siguiente sentencia:

220 CREATE INDEX parcelas_spatial_idx ON parcelas(geometria) INDEXTYPE IS MDSYS.SPATIAL_INDEX; Gracias al uso del patrón de diseño DAO (Data Access Object) está previsto la incorporación de orígenes de datos de este tipo, de forma totalmente transparente al sistema. Como ejemplos de bases de datos libres que están incorporando esta capacidad, podemos mencionar PostgreSQL (con su extensión espacial PostGIS), y MySQL, que a partir de su vesión 4.1 va a incorporar también funciones espaciales. No obstante, la forma de trabajar con estas bases de datos no diferiría mucho de la aquí mostrada para trabajar con Oracle (producto de carácter comercial). 5. Orígenes de Datos Raster. El SIIA también permite el acceso y manipulación de fuentes de datos raster. Estos datos se corresponden con imágenes digitales, procedentes de vuelos aéreos fotogramétricos o de imágenes de teledetección. Dichas imágenes se caracterizan por su gran tamaño, del orden de magnitud del Gb, ya que forman mosaicos que pueden llegar a cubrir naciones e incluso continentes. Con tal fin, se utiliza como formato preferido de almacenamiento el ECW (Enhanced Compressed Wavelet), propiedad de la casa comercial ER-Mapper ( Este formato ofrece ratios de compresión muy elevados, conservando una calidad visual más que aceptables, característica que le hace altamente recomendable frente a otros formatos como el JPEG, que es muy degradativo, o el TIFF, que no ofrece suficiente grado de compresión. En adición, los tiempos de recuperación de fragmentos de imágenes están muy optimizados, al utilizar pirámides de imágenes multiresolución. Para su uso desde todo tipo de aplicación GIS o de Teledetección, ER-Mapper ofrece para su descarga una API Java que permite extraer fragmentos de imagen en forma de instancias de la clase java.awt.bufferedimage a partir del rectángulo del puerto de visión solicitado. En el caso de datos en formato raster, que no son más que imágenes digitales de las que se conoce las coordenadas de sus esquinas, la indexación espacial es inmediata, y viene dada por la propia estructura matricial de las imágenes digitales. Conociendo las dimensiones en pixeles de la imagen, y las coordenadas reales de sus esquinas, es posible obtener las coordenadas pixel de cualquier coordenada del mundo real que se proporcione. Como extensión a la especificación de Features, OGC ha elaborado una especificación que incluye orígenes de datos no vectoriales: OGC Coverages Specification. Dentro de esta especificación se incluye el modelo de clases para orígenes de datos raster, no incluido en ninguno de las APIs utilizadas (JTS, JUMP).

221 6. Referencias SIIA-Web: Spatial Oracle.: Open GIS: ArcIMS: JTS (Java Topology Suite): JUMP (Java Unified Mapping Platform): JfreeChart y JFreeReport: Spatial Index Library: ER-Mapper:

222 LISTADO DE FIGURAS FIGURA 1: CAMBIOS DE NIVEL DE ZOOM E INCORPORACIÓN DE NUEVOS DATOS FIGURA 2: LOCALIZADORES.

223 FIGURA 3: CARGADOR DE FICHEROS FIGURA 4: SELECCIONANDO UNA CAPA DE LA GEODATABASE CON JUMP

224 FIGURA 5: CAPA DE LA GEODATABASE CARGADA EN JUMP FIGURA 6: EXTENSIÓN DE JUMP PARA ACCEDER A ORÍGENES RASTER.

225 FIGURA 4: MODELO DE CLASES BASADO EN LA ESPECIFICACIÓN DE FEATURES DE OGC. FIGURA 5: MODELO DE GEOMETRÍAS DE LA ESPECIFICACIÓN OGC.

226 IGURA 6: DIAGRAMA DE CLASES DE ACCESO A DATOS.

227 Fisterra 2: software libre para gestión empresarial Alejandro García Castro, José María Casanova Crespo, Juan José Sánchez Penas, José Dapena Paz Igalia: Ingeniería en Informática y Software Libre Gutenberg 34B 2 o, 15008, A Coruña, Galicia, España 10 de enero de 2004 Resumen c 2004, Igalia S.L. 1 Fisterra 2 constituye una evolución en las aplicaciones de gestión empresarial en el ámbito del software libre. Partiendo del trabajo realizado por Igalia en la primera versión, publicada en 2003, se ha rediseñado una nueva arquitectura multicapa, más genérica y ambiciosa, que verá la luz en su versión estable durante el año En el artículo se realiza una evaluación sobre los distintos proyectos libres orientados al mundo de la gestión y, partiendo de ésto, se justifica y explica la aportación de la nueva versión de Fisterra. 1. Introducción: necesidad de aplicaciones empresariales En los últimos años, las plataformas basadas en software libre y su nuevo modelo de desarrollo cooperativo, y en particular el sistema GNU/Linux y sus aplicaciones asociadas, se han convertido en una alternativa sólida a cualquier otra solución tradicional, basada en software propietario cerrado. El nacimiento de decenas de nuevos proyectos cada mes, la adopción cada vez mayor del software libre por parte de administraciones públicas de todo el mundo, e incluso el apoyo explícito de grandes corporaciones como IBM, Sun o HP, son pruebas contundentes de la evolución de este movimiento que tiene apenas dos décadas y cuya explosión se está viviendo en los últimos cinco años. El avance del software libre tiene relación con distintos aspectos, que se pueden ver en la mayoría de los 1 Copyright Igalia, S.L. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. casos como complementarios: en ocasiones es decisiva la libertad que otorga al usuario el hecho de disponer del código fuente y de la posibilidad de analizarlo, modificarlo y redistribuirlo; en otras, cobra especial interés la reducción del TCO (coste total de propiedad) o la muchas veces mayor calidad técnica de las soluciones libres. En cualquier caso, miles de usuarios (empresas, administraciones o usuarios finales) están optando a cada vez mayor velocidad por soluciones innovadoras basadas en una nueva forma de entender el desarrollo de software. Esta evolución del sistema va pareja a la aparición de soluciones (aplicaciones, distribuciones, servicios) para los distintos ámbitos y sectores de utilización de software libre. Cada vez son menos los huecos en los que hay que recurrir a sistemas cerrados porque el conjunto de sistemas operativos y aplicaciones libres no son capaces todavía de satisfacer las demandas de los usuarios. Si hace unos años las limitaciones de las soluciones de escritorio era una crítica habitual a los sistemas libres, en la actualidad esa carencia ya no existe, gracias a proyectos como KDE o Gnome, que han equiparado la calidad del escritorio GNU/Linux a la de cualquier sistema propietario. No obstante, todavía existen algunos ámbitos en los que faltarán unos años para que esta situación llegue; entre ellos están el del diseño gráfico, el de las herramientas de CAD, o, atendiendo a lo que más interesa para el presente artículo, el sector de las aplicaciones de gestión empresarial (ERP, CRM, contabilidad, etc.). Existe un hueco por llenar, que se corresponde con las tecnologías, herramientas y aplicaciones adecuadas para construir sistemas de gestión eficientes, eficaces, flexibles, modernos y de calidad. Fisterra es un proyecto nacido con la vocación de colaborar en este trabajo, intentando que los sistemas libres, además de todos los sectores ya conquistados, puedan acceder a nuevos ámbitos en los que su aplicación traería mayor libertad para todos los participantes. 1

228 2. Aplicaciones de gestión en GNU/Linux La necesidad de aplicaciones y tecnologías de desarrollo especializadas en la gestión empresarial es algo difícilmente cuestionable. GNU/Linux, por la herencia de UNIX, nace como un sistema con especial fuerza en la parte servidor, lo que conlleva que su mayor cuota de mercado durante muchos años haya sido los servidores de intranet y de Internet (el ejemplo más utilizado es el del servidor web Apache). Progresivamente, esta mayor capacidad para el lado servidor se ha ido desplazando al desktop (escritorio del usuario final), y esto abre nuevas posibilidades entre las que, en el ámbito empresarial y de gestión, es cada vez más evidente el de la aplicación de software libre para solucionar las necesidades que tradicionalmente cubrían (y todavía cubren en la mayoría de los casos) los ERP/CRM propietarios de las grandes empresas de desarrollo de software (SAP, Navision, Libra, etc.). En los últimos años, han nacido iniciativas derivadas de la coincidencia por parte de distintos grupos de desarrolladores o empresas en la necesidad de software libre de gestión. Algunas de estas iniciativas están en sus primeras fases todavía y cuentan con pocos apoyos (grupo de desarrolladores limitado y problemas de financiación), pero otras comienzan a vislumbrarse como proyectos de gran interés. Comentamos a continuación algunas de las iniciativas existentes: GNUe [1] (GNU Enterprise): metaproyecto que forma parte del proyecto GNU, y que tiene tres objetivos claros: un conjunto de herramientas, incluyendo interfaces de usuario, generadores de informes, módulos para la creación de aplicaciones cliente/servidor de gestión, etc.; un conjunto de paquetes que implementen, utilizando las herramientas anteriores, un ERP completo; y finalmente, la creación de una comunidad de usuarios alrededor de este proyecto. GNUe nace en marzo de 2000, aunque toma las riendas de varios proyectos anteriores que ya se habían iniciado en En estos momentos las herramientas (servidor de aplicaciones, generador de informes, generador de formularios, navegador, etc.) comienzan a ser utilizables, aunque sus versiones no son todavía muy estables. Los paquetes están todavía en las primeras fases de desarrollo, o incluso sin comenzar. No obstante, ya existen tres proyectos que utilizan las herramientas de GNUe para implementar directamente sus programas de gestión: Luca [10], GNUe Small Business [11] y Rent-Free [12]. El lenguaje escogido para el desarrollo es Python. GNUCash [2]: aunque con frecuencia no es citado como una herramienta de gestión empresarial, por estar claramente enfocado a la administración contable más doméstica, el proyecto tiene características interesantes que podrían ser utilizadas para una contabilidad más empresarial. Es un proyecto muy estable, con licencia GPL y desarrollado con tecnología GNOME. Compiere [3]: iniciado en 1999 por la empresa del mismo nombre, se trata de un ERP desarrollado en Java y con interfaz web. Es multiplataforma y está publicado con licencia Mozilla (MPL), en la actualidad está ya en una versión completamente estable. El servidor está basado en JBoss [13], con el desarrollo basado en servlets y EJBs. El proyecto tiene en la actualidad una gran actividad. G-CTB [5] (GNU ConTaBilidad): implementación de una aplicación de contabilidad clásica, con licencia GPL, que utiliza tecnología GNOME para la interfaz gráfica y el acceso a datos, está desarrollado en C, y se encuentra todavía en versiones iniciales, además de encontrarse el proyecto completamente parado en el último año. ASPL-Fact [4]: proyecto iniciado en el 2000 e impulsado por la empresa ASPL (Advanced Software Production Line) que pretende crear una arquitectura modular para el desarrollo de aplicaciones de gestión en GNU/Linux. Por el momento el proyecto se ha centrado en la definición de una arquitectura flexible basada en tecnología GNOME y en el protocolo BEEP para la comunicación cliente/servidor; una primera versión de esta arquitectura está prevista para agosto de Todo el desarrollo es bajo licencia GPL y con C como el lenguaje principal de programación. Bulmages [6]: aplicación de contabilidad para GNU/Linux, con licencia GPL, que utiliza tecnología KDE, desarrollado en C++, y se encuentra en la actualidad en una versión utilizable, con las funcionalidades básicas y implementadas. Su desarrollo está siendo coordinado por miembros del grupo de usuarios de GNU/Linux de Mallorca. El proyecto inició su actividad en noviembre de Facturalux [7]: aplicación de gestión tipo ERP para GNU/Linux, con licencia GPL y tecnología KDE (QT, C++, Kugar), utiliza una arquitectura denominada A3D (Arquitectura Abierta de Aplicaciones Dinámicas), que almacena código y datos en la BD utilizando el estándar XML y ECMAScript; BEEP [14] es el protocolo de comunicación escogido. El proyecto está impulsado por InfoSiAL, desde principios del 2001, y mantiene una actividad alta en la versión actual del código, que todavía es un prototipo. 2

229 GestiONG [8]: implementación de una aplicación de gestión de ONGs y sociedades sin ánimo de lucro, haciendo especial hincapié en la creación de un programa estándar de contabilidad. El proyecto dio comienzo mayo de 2003 y está disponible ya un prototipo con funcionalidad básica. El programa, con licencia GPL, utiliza también tecnología KDE para la implementación (QT, C++, Kugar) y presenta una actividad considerable actualmente. Seguros Distribución Empresa A... Sector x... Gestión Libre [9] en Hispalinux: proyecto que pretende coordinar acciones (documentación, desarrollo, especificaciones) relacionadas con la introducción de software libre de gestión en empresas y administraciones públicas. El proyecto existe desde el año En este contexto, en en el que se ve claramente que están surgiendo iniciativas en los últimos 3 años para la creación de software de gestión empresarial, y también se puede observar que la mayor parte de los proyectos están todavía lejos de proporcionar una solución sólida al usuario, en el año 2003, nace el proyecto Fisterra. El proyecto es impulsado y desarrollado por Igalia y basado en tecnologías GNOME. En los siguientes apartados se detallan los aspectos más importantes del proyecto, describiendo la arquitectura propuesta para la nueva versión, que constituye un paso mucho más ambicioso para colocar a Fisterra definitivamente entre las alternativas más interesantes para la construcción de soluciones ERP/CRM en GNU/Linux. 3. Fisterra Presente del proyecto: fisterrabase y fisterra sectorial Actualmente Fisterra es un proyecto activo, desde el momento de su publicación hasta la fecha de hoy se ha trabajado mucho en el diseño y arquitectura de la nueva versión. Se está invirtiendo un gran esfuerzo en definir las necesidades de las aplicaciones de gestión empresarial tanto desde el punto de vista tecnológico como conceptual. La versión original, más orientada a un sector, del proyecto, ha sido generalizada hacia la creación de un framework para el desarrollo de aplicaciones de gestión de diversos sectores empresariales. Además, se ha potenciado la creación de herramientas que faciliten el trabajo en comunidad, por lo que se espera que el año 2004 sea clave para el crecimiento en el número de usuarios y desarrolladores de Fisterra. Igalia está en conversaciones con empresas especializadas en la gestión de negocio para la colaboración en el enriquecimiento de la solución y para la distribución a mayor escala de sistemas basados en esta tecnología. Fisterra 2 GNOME 2 Figura 1: Estructura de Fisterra 2 Fisterra 2 consta hoy por hoy de un núcleo sobre el que se apoyan desarrollos de Igalia orientados a desarrollos verticales para sectores específicos. Durante el primer mes de 2004 se está dando un importante giro en cuanto a las herramientas para el trabajo en comunidad dentro del proyecto. Una nueva web, más útil y dinámica, será el eje central de coordinación del proyecto. El trabajo del equipo de desarrollo será realizado en un servidor de CVS público y accesible para cualquier persona interesada. Una larga lista de herramientas de ayuda como bonsai, tinderbox, bugzilla o natzilla estarán a la disposición de la comunidad para coordinar el desarrollo de Fisterra. Uno de los intereses principales es la creación de una comunidad de desarrolladores fuerte que trabaje en el desarrollo aplicaciones de gestión basadas en software libre; por ello estamos intentando la colaboración con otros proyectos, acordando arquitecturas comunes que nos puedan llevar en un futuro cercano a la creación de estándares de facto para la creación de este tipo de aplicaciones. Fisterra 2 se divide en un framework genérico de trabajo, que es conocido como fisterra-base, y el conjunto de aplicaciones sectoriales genéricas desarrolladas utilizando las bibliotecas y facilidades aportadas por dicho framework. Las aplicaciones sectoriales implementan un conjunto de procesos de negocio que son interesantes para la lógica de trabajo de ese sector. Intentando la generalización de los procesos de negocio de una empresa Fisterra se ha dividido en las siguientes partes principales, que están siendo implementadas de forma progresiva para Fisterra 2: gestión de contacto con clientes (CRM); gestión de ventas (del presupuesto-venta a la contabilidad); gestión de compras (del presupuesto-compra a la contabilidad); 3

230 Vista/datos Controladores/widgets Modelo/Datos Vista Ventana Controlador Ventana Fachada Delegate... CORBA Modelo Aplicación Servidor Figura 2: Captura de pantalla de Fisterra 2 Figura 3: Diseño del Cliente de Fisterra2 gestión de la logística (almacenes); gestión de fabricación (SCM); gestión de recursos humanos; gestión de tesorería; gestión de la contabilidad y finanzas; gestión de negocio, táctica y estrategia (datawarehouse, OLAP); gestión de la integración (legacy); gestión de la aplicación (administración); gestión de proyectos; y gestión de calidad Objetivos de Fisterra 2 Fisterra 2 nace como la evolución tecnológica en el desarrollo de aplicaciones de gestión empresarial de Igalia. Tras la experiencia alcanzada con el desarrollo de la primera versión, se ha realizado una refactorización completa de la arquitectura para permitir desarrollos más escalables de sistemas de información para empresas. Los objetivos de Fisterra 2 son construir una solución más general y flexible que sea adaptable de forma sencilla a nuevos negocios. Entre los objetivos a alcanzar con la nueva versión se encuentran: incorporación de la tecnología GNOME2; arquitectura multicapa; y proporcionar un framework genérico y un conjunto de ejemplos de aplicaciones para sectores de negocio para facilitar el desarrollo y adaptación de nuevos módulos sectoriales sin partir de cero Diseño del sistema Fisterra 2 establece una separación entre cliente y servidor. El cliente tiene como funciones la interacción con el usuario final mediante la interfaz gráfica. Es necesario poder ejecutar instancias del cliente en múltiples equipos. Su implementación es totalmente independiente de la del servidor siempre que cumpla las interfaces de comunicación. El servidor se encarga de gestionar el proceso de negocio de la aplicación. Realizar las operaciones que en- viadas por los clientes, a la vez que gestiona el acceso a la base de datos, el control de accesos y las autorizaciones Cliente Fisterra 2 El cliente en Fisterra es la parte visible al usuario, la cual está controlada por un autómata de estados que determina el flujo de la aplicación. La estructura interna del cliente está definida siguiendo el patrón de diseño MVC (Model-View-Controller). Cada ventana está formada por tres tipos de componentes: vista descrita mediante ficheros XML de glade; controlador, que rellena la ventana en base a su modelo, gestiona los eventos y callbacks; y widgets para la representación de los datos del dominio del negocio utilizaremos widgets creados según el patrón model-viewcontroller, de forma similar a la solución aplicada para los GtkTrees. De esta forma tendremos modelos que representarán estructuras de datos de dominio complejas orientadas a al trabajo visual y controladores/vista encargados del mostrado de estos objetos. Esta solución nos permitirá la creación múltiples vistas sin tener que cambiar la representación de datos del cliente. Para la gestión de ventanas y su creación usamos un sistema de controlador principal en el que se registran las ventanas para poder ser construidas en el sistema. Para la construcción de una ventana se hace una petición a este controlador que utilizará builders para la creación de las mismas. Por abajo de los controladores de ventana encontramos las fachadas encargadas de implementar las llamadas a los servicios utilizando los modelos que representan los datos de las ventanas. La abstracción de la tecnología de comunicaciones, en este caso CORBA, se consigue mediante una capa de delegación encargada de ocultar los procesos necesarios para realizar la comunicación. 4

231 CLIENTE CLIENTE COMUNICACIONES SERVICIOS OBJETOS DE NEGOCIO DAO INFORMES SESION WORKFLOW... Figura 4: Diseño servidor Fisterra Servidor Fisterra La novedad en Fisterra 2 se encuentra principalmente en que se separa del cliente todo el comportamiento de gestión de negocio, autenticación y acceso a datos en un servidor. Éste proporciona distintos servicios que son utilizados por el cliente para la ejecución de la aplicación. El sistema servidor permite disponer de un único punto de acceso a la base de datos, de forma que todas las operaciones contra ella se ejecutarán desde un único punto. Esto además elimina la dependencia de la base de datos para la gestión de la concurrencia. Para la creación y gestión de datos se ha creado una estructura basada en un sistema de generación de código, que permite construir la estructura de objetos de gestión de datos de negocio de forma eficiente. EL objeto principal es el barnacle del que heredan el resto de objetos y que les proporciona una serie de características estándares. El servidor permite gestionar la operativa de distintos clientes y disponer de una gestión global de autorizaciones y control de las operaciones. La capa de comunicaciones implementa las interfaces disponibles para su utilización en el cliente, se encarga de aceptar las peticiones en el cliente y redirigirlas al servicio correspondiente. La tecnología de comunicaciones se mantendrá abstracta al sistema, pero para las implementaciones iniciales se utilizará CORBA. En la capa de servicios se dividen en 2 tipos, servicios de utilidad y servicios de negocio. Ambos tipos se han implementando utilizando una estructura de objetos con un tipo padre encargado de implementar las características generales de los mismos, los EGBs (Enterprise Gnome Barnacles). Los EGBs nos permiten la separación del código de gestión de negocio. Los EGBs específicos de servicio se encargan de la implementación las funciones que exportan los módulos. Entre los servicios utilidad se encuentran el acceso a datos, gestión de workflow, gestión de sesión y elaboración de informes. Los servicios de negocio implementan comportamientos del negocio soportado por la aplicación y se apoya sobre los servicios utilidad, de esta forma las personalizaciones del modelo de negocio consistirían en modificar o parametrizar estos servicios. La nueva arquitectura está detallada en la figura Tecnologías utilizadas Fisterra utiliza como base el conjunto de tecnologías que conforman el Gnome SDK, para las interfaces de usuario y el servidor de aplicaciones. Sobre éstas, integra e introduce otras tecnologías, para dar soporte a persistencia, e implementar la comunicación, tal y como hemos podido ver en apartados anteriores. Sobre ellas, Fisterra constituye por si mismo un completo framework de desarrollo de aplicaciones. A continuación detallamos las principales tecnologías que se utilizan en Fisterra Tecnologías GNOME GTK+ Librería que proporciona los widgets y controles. En Fisterra se utilizan los estándares de desarrollo de interfaces del escritorio GNOME, y se observa el respeto por los estándares que define, en especial las HIG 2. LibGlade Librería para la descripción visual de interfaces de usuario, y el uso de estas descripciones en aplicaciones. La mayor parte de las interfaces de usuario de Fisterra se desarrollan con esta herramienta. GObject Sistema que permite realizar orientación a objetos en C, usado por el proyecto GNOME. Los objetos de negocio y la persistencia se implementan utilizando GObjects. LibXML, libxslt Librerías que implementan operaciones para manipulación de ficheros XML, y transformaciones XSL. Se utilizan en Fisterra como formato de intercambio. Orbit Implementación ligera de CORBA, protocolo de invocación remota de métodos, y comunicación de objetos interoperable. Se utiliza para la comunicación entre los distintos servicios del sistema, y entre cliente y servidor. libgda Librería de acceso a bases de datos del proyecto Gnome. Se utiliza para implementar el acceso genérico a bases de datos relacionales, y proporcionar así persistencia a la capa de negocio. 2 HIG (Human Interface Guidelines): Documento de normas y estándares sobre la implementación de interfaces de usuario en GNOME. 5

232 Otras tecnologías PostgreSQL Gestor de bases de datos relacional, que implementa un gran conjunto de funcionalidades de SQL, de forma eficiente. Es la base de datos elegida para el almacenamiento de información en Fisterra Publicación y colaboración En el momento de elaboración de este artículo se encuentra publicada (además de la versión 1.5 completa y funcional, pero menos genérica) en la web la versión de Fisterra 2, está formado por un subconjunto de las funcionalidades de Fisterra sobre las que se han realizado las pruebas tecnológicas sobre el entorno GNOME 2, consistentes en la migración de la interfaz de Glade1 a Glade2 y la actualización de la librería libgda a su versión 0.12 desde la 0.2. Esta versión es simplemente para realizar pruebas de desarrollo, pero en el CVS público está ya disponible la versión inicial de fisterra-base y el código inicial sobre el que se está construyendo un ejemplo de aplicación para el sector de la distribución. La primera versión estable de fisterra-base y el código para el sector de la distribución serán publicadas en el primer y segundo trimestre de 2004, respectivamente. Igalia está trabajando actualmente en buscar puntos de encuentro con otros proyectos para intercambiar experiencias y tratar de clarificar el futuro de las aplicaciones de gestión empresarial como Software Libre. 4. Conclusiones y trabajo futuro En este artículo hemos presentado el presente y planes futuros de un nuevo proyecto de software libre llamado Fisterra. El desarrollo del ERP Open Source se encuentra en estos momentos inmerso en la segunda etapa de generalización, con la definición de una arquitectura que marca el rumbo cara a un framework que permita definir con facilidad nuevas aplicaciones de gestión empresarial para sectores distintos de los ya implementados. Con la versión 1 ya estabilizada y en funcionamiento, el proyecto y sus desarrolladores están embarcados en una segunda fase intensa y compleja de la que debería salir, si todo sigue como está previsto, una versión avanzada de la segunda versión, siguiendo las decisiones de diseño arquitectónico que se explican en el artículo. Esta nueva versión será publicada en sus distintas versiones durante la primera mitad del año Con estas líneas trazadas, se deja claro cuál es el enfoque actual del proyecto, que camina hacia un ERP abierto en dos niveles diferentes: por un lado los componentes básicos que forman el framework de desarrollo de aplicaciones basadas en Fisterra (solución horizontal común), y por otro las implementaciones de los distintos sectores verticales especializadas y posiblemente adaptables para las necesidades de una empresa en concreto. Tres sectores están siendo desarrollados ya, y sus partes comunes están siendo abstraídas, y dichas implementaciones formarán parte de las próximas versiones de Fisterra 2, completamente integrada con las más recientes tecnologías del proyecto GNOME. A pesar de que los desarrolladores del proyecto se encuentran satisfechos con las decisiones tomadas, tanto tecnológicas como de diseño de arquitectura, es muy importante el intercambio y la colaboración con otros proyectos con objetivos similares, con lo que en estos momentos se están llevando a cabo iniciativas para contactar con los coordinadores de distintos proyectos de software de gestión empresarial libre. En el futuro, Fisterra buscará todavía más la sinergia con otras iniciativas, intentando ser una solución mejor y más completa para los usuarios de software libre. 5. Agradecimientos Los autores del artículo quieren agradecer a Javier Vázquez Lamas, Xavier Castaño García, Alberto García González, José Juan González Alonso, Javier Fernández García-Boente, Alejandro Piñeiro Iglesias, Xavier Rodríguez Calvar, Eloy Froufe y Sergio Villar Senín su colaboración en el desarrollo del proyecto Fisterra. Referencias [1] GNU Enterprise: [2] GNU Cash - Open Source accounting Software: [3] Compiere, Smart Open Source ERP Software with integrated CRM Solutions: [4] ASPL-Fact, facturación para Linux: [5] G-CTB: GNU ConTaBilidad: [6] Bulmages, contabilidad para Linux: [7] FacturaLUX - Software ERP de código libre: [8] GestiONG, Software solidario para organizaciones solidarias: [9] Gestión Libre: [10] LUCA, programa de gestión: [11] GNUe Small Business Edition: [12] Rent-Free: [13] JBoss, Professional Open Source: [14] RoadRunner, Industrial Strength BEEP Toolkit: [15] Open Source Initiative: [16] García Castro, Dapena Paz. GNOME for business appliances: case study and architecture proposal. GUADEC IV Dublin,

233 LA LIBRERÍA DE VISIÓN ARTIFICIAL OPENCV APLICACIÓN A LA DOCENCIA E INVESTIGACIÓN 1 V. M. Arévalo, J. González, G. Ambrosio Dpto. De Ingeniería de Sistemas y Automática, Universidad de Málaga. España varevalo@ctima.uma.es En este artículo describimos las características fundamentales de la librería de visión artificial y código abierto The Open Computer Vision Library (OpenCV a partir de ahora). La librería OpenCV proporciona un marco de trabajo de alto nivel para el desarrollo de aplicaciones de visión por computador en tiempo real: estructuras de datos, procesamiento y análisis de imágenes, análisis estructural, etc. Este marco de trabajo facilita en gran manera el aprendizaje e implementación de distintas técnicas de visión por computador, tanto a nivel docente como investigador, aislando al desarrollador de las peculiaridades de los distintos sistemas de visión. De igual forma, presentamos algunos ejemplos de la utilización de dicha librería en docencia e investigación por parte del Dpto. de Ingeniería de Sistemas y Automática de la Universidad de Málaga. Palabras clave: Software libre, visión por computador, procesamiento de imágenes, docencia, investigación, etc. 1. Introducción La necesidad de disponer de un paquete de visión por computador y procesamiento de imágenes lo suficientemente flexible como para proporcionar herramientas de alto nivel para el desarrollo de las prácticas docentes que imparte el Dpto. de Ingeniería de Sistemas y Automática de la Universidad de Málaga; y la potencia, escalabilidad y disponibilidad del código fuente para el desarrollo de los distintos proyectos fin de carrera y tesis doctorales que dirige dicho departamento, propició una búsqueda incesante de software que cumpliera dichas características y sobre todo que fuese gratuito, estuviese soportado/revisado por personal cualificado y además se le intuyese una larga vida. Son muchos los paquetes de procesamiento de imágenes comerciales y software libre disponibles actualmente, y muchas las ventajas e inconvenientes de cada uno de ellos. Entre los distintos paquetes comerciales disponibles actualmente destacan por su potencia The Matrox Image Library (MIL) [1], Khoros, evision, HIPS, Exbem, Aphelion, etc. sin embargo, el principal inconveniente es su elevado precio y su ciclo de actualización, muchas veces, relativamente largo. Algunos de ellos carecen de un entorno de desarrollo de alto nivel (i.e. HIPS), otros disponen de éste, pero están ligados a la plataforma de desarrollo (i.e. Khoros - Unix, Linux; Exbem - MacOS; evision, Aphelion - Windows) o al propio hardware de captura (i.e. MIL). Todos ellos proporcionan funciones de procesamiento y análisis de imágenes, reconocimiento de patrones, estadísticas, calibración de la cámara, etc. a través del propio entorno o a través de librerías de funciones, desarrollados en la mayoría de las ocasiones en C/C++. Sin embargo, tan sólo HIPS pone a disposición del cliente su código fuente, y en la mayoría de los casos hablamos de librerías monolíticas, muy pesadas y no demasiado rápidas. Por otro lado, son muchos los paquetes no comerciales (con y sin licencia Software Libre) disponibles en el mercado, entre ellos destacan OpenCV, Gandalf, TargetJr, VXL (basado en TargetJr), CVIPTools, ImageLib, ImLib3D (Linux), LookingGlass, NeatVision (Java), TINA y XMegaWave (Unix/Linux). Todos ellos disponen de herramientas para el procesamiento de imágenes, pero a excepción de OpenCV y Gandalf ninguno proporciona un marco de trabajo completo para el desarrollo de aplicaciones relacionadas con la visión por computador. Esta capacidad de desarrollo contempla, no sólo el procesamiento de imágenes, sino tareas mucho más complejas como el reconocimiento de gestos, estimación del movimiento y la posición de un objeto, morphing, estimadores (filtros de Kalman, etc.), etc. Sin embargo, sólo OpenCV proporciona bibliotecas de tipos de datos estáticos y dinámicos (matrices, grafos, árboles, etc.), herramientas con la posibilidad de trabajar con la mayoría de las capturadoras/cámaras del mercado, entornos de desarrollo fáciles e intuitivos y todo ello, corriendo en dos de los sistemas operativos más utilizados del mundo Microsoft Windows y Linux. 1 Este trabajo ha sido financiado por el proyecto CICYT DPI

234 El artículo está estructurado de la siguiente forma. En la sección 2 describimos las características de The Open Computer Vision Library. En la sección 3 detallamos algunas de las aplicaciones de dicha librería a la docencia e investigación. Finalmente, en la sección 4, presentamos las conclusiones de este trabajo. 2. The Open Computer Vision Library El 13 de Junio del 2000, Intel Corporation anunció que estaba trabajando con un grupo de reconocidos investigadores 2 en visión por computador para realizar una nueva librería de estructuras/funciones en lenguaje C. Esta librería proporcionaría un marco de trabajo de nivel medio-alto que ayudaría al personal docente e investigador a desarrollar nuevas formas de interactuar con los ordenadores. Este anuncio tuvo lugar en la apertura del IEEE Computer Society Conference on Computer Vision and Pattern Recognition (CVPR). Había nacido The Open Computer Vision Library [5] y lo hacía bajo licencia BSD (Software Libre). La librería OpenCV es una API de aproximadamente 300 funciones escritas en lenguaje C que se caracterizan por lo siguiente: Su uso es libre tanto para su uso comercial como no comercial (ver licencias en [2], [3] y [4] para más información). No utiliza librerías numéricas externas, aunque puede hacer uso de alguna de ellas, si están disponibles, en tiempo de ejecución. Es compatible con The Intel Processing Library (IPL) y utiliza The Intel Integrated Performance Primitives (IPP) para mejorar su rendimiento, si están disponibles en el sistema. Dispone de interfaces para algunos otros lenguajes y entornos: EiC - intérprete ANSI C escrito por Ed Breen. Hawk y CvEnv son entornos interactivos (escritos en MFC y TCL, respectivamente) que utilizan el intérprete EiC; Ch - intérprete ANSI C/C++ creado y soportado por la compañía SoftIntegration; Matlab - gran entorno para el cálculo numérico y simbólico creado por Mathworks; y muchos más Estructura y características de la librería OpenCV La librería OpenCV esta dirigida fundamentalmente a la visión por computador en tiempo real. Entre sus muchas áreas de aplicación destacarían: interacción hombre-máquina (HCI 4 ); segmentación y reconocimiento de objetos; reconocimiento de gestos; seguimiento del movimiento; estructura del movimiento (SFM 5 ); y robots móviles. Figura 1: Estructura de la librería OpenCV. 2 Intel facilitó el desarrollo y mantenimiento de la librería OpenCV aceptando y manteniendo las propuestas de código fuente revisadas por un grupo de expertos de la comunidad investigadora. Revisores que incluían representantes de los más importantes laboratorios de visión incluyendo: Jitendra Malik, University of California Berkeley; Takeo Kanade, Carnegie Mellon University; Pietro Perona, NSF Engineering Research Center, California Institute of Technology; Irfan Essa, Georgia Institute of Technology; Carlo Tomasi, Stanford University; Trevor Darrell, Massachusetts Institute of Technology; Stan Sclaroff, Boston University. 3 Son muchos los proyectos Software Libre en avanzado estado de gestación que hacen uso de la librería OpenCV como marco de trabajo, entre ellos podemos destacar: Foresight; OpenCV User Contribution Library y S2iLib (visitar para más información). 4 Del término inglés Human-Computer Interaction. 5 Del término inglés Structure From Motion. 2

235 Como podemos ver en la figura 1, la librería OpenCV proporciona numerosos elementos de alto nivel, como veremos en secciones posteriores, que facilitan sobre manera el trabajo al usuario (tanto al docente como al investigador). Por ejemplo, proporciona filtros Microsoft DirectShow para realizar tareas tales como: calibración de la cámara, seguidores de objetos (Kalman tracker y ConDensation tracker), etc. Todos ellos se pueden utilizar en Microsoft GraphEdit para ilustrar de forma bastante sencilla numerosas aplicaciones de visión. En la figura 2 y figura 3 podemos observar un ejemplo de ellos. Figura 2: Seguidor de caras realizado con un filtro de Kalman. Figura 3: Salida del seguidor de caras realizado con un filtro de Kalman. De igual forma, la librería OpenCV proporciona numerosas aplicaciones de ejemplo que ilustran como emplear las distintas funciones de la librería. En la figura 4 podemos ver una implementación de los HMM (Hidden Markov Models) para el reconocimiento de caras. Figura 4: Detector de caras realizado con HMM (Hidden Markov Models). También los entornos de scripting hacen uso de estas funciones para implementar su funcionalidad. La librería OpenCV proporciona una gran diversidad de entornos. En la sección 2.2 detallamos de forma pormenorizada algunos de los más utilizados. Todas estas herramientas de alto nivel hacen uso de un paquete de clases C++ y funciones C de alto nivel que utilizan a su vez funciones muy eficientes escritas en C. Concretamente, el conjunto de funciones suministradas por la librería OpenCV se agrupan en los siguientes bloques: Estructuras 6 y operaciones básicas: matrices, grafos, árboles, etc. Procesamiento y análisis de imágenes: filtros, momentos, histogramas, etc. Análisis estructural: geometría, procesamiento del contorno, etc. Análisis del movimiento y seguimiento de objetos: plantillas de movimiento, seguidores (i.e. Lucas-Kanade), flujo óptico, etc. Reconocimiento de objetos: objetos propios (eigen objects), modelos HMM, etc. Calibración de la cámara: morphing, geometría epipolar, estimación de la pose (i.e. POSIT), etc. Reconstrucción tridimensional (funcionalidad experimental): detección de objetos, seguimiento de objetos tridimensionales, etc. Interfaces gráficos de usuarios y adquisición de video. En la figura 1 también podemos observar como la librería OpenCV puede hacer uso de librerías propietarias como son en este caso The Intel Image Processing Library (IPL) y The Intel Integrated Performance Primitives (IPP) en caso de disponer de ellas. Estas aplicaciones tratan de mejorar el 6 Todas estas estructuras disponen de funciones para su gestión: creación, inicialización, destrucción, conversión, estadísticas, etc. Por ejemplo, la librería OpenCV dispone de todo un conjunto de funciones para realizar operaciones con matrices, álgebra lineal (SVD, Mahalanobis, etc.) y funciones matemáticas de propósito general. 3

236 rendimiento de la librería con primitivas optimizadas para procesadores Intel. Sin embargo, la licencia por las que se rigen estas aplicaciones no es software libre y por tanto carece de interés para los autores. 2.2 Interfaces gráficos y herramientas de la librería OpenCV La librería OpenCV proporciona varios paquetes de alto nivel para el desarrollo de aplicaciones de visión. Todos ellos se pueden agrupar en librerías de C/C++ dirigidas a usuarios avanzados y en herramientas de scripting dirigidas, en este caso, a usuarios de nivel medio (ideal para practicar con las distintas técnicas de procesamiento de imágenes y visión). Al primer grupo pertenecen HighGUI y CvCam, mientras que al segundo pertenecen Hawk y OpenCV Toolbox para Matlab. HighGUI permite la escritura/lectura de imágenes en numerosos formatos (BMP, JPEG, TIFF, PxM, Sun Raster, etc.) y la captura de stream de video de capturadoras Matrox y cámaras/capturadoras con drivers VFW/WDM (la mayoría del mercado); la creación de ventanas para visualizar imágenes en ellas, las ventanas HighGUI recuerdan su contenido (no es necesario implementar callbacks de repintado); y además, nos proporciona mecanismos muy fáciles de interaccionar con ellas: trackbars, capturando la entrada del teclado y el ratón. CvCam nos proporciona un único interfaz de captura y reproducción bajo Linux y Win32; callbacks para la gestión de stream de vídeo o ficheros AVI y un mecanismo fácil para implementar visión estéreo con dos cámaras USB o una estéreo-cámara. Hawk es un entorno visual con el intérprete ANSI C EiC como núcleo; soporta plugins; proporciona soporte para OpenCV, IPL y HighGUI vía plugin; y soporte de video. Figura 5: Hawk (EiC). Por último, la librería OpenCV proporciona un toolbox para Matlab que se caracteriza por lo siguiente: Utiliza tipos nativos de Matlab (matrices, estructuras). Compatibilidad con la Image Processing Toolbox. En la figura 6 podemos ver una implementación de un seguidor de caras denominado CamShift con el OpenCV Toolbox para Matlab. % Seguidor de caras Camshift, mejorado con filtro de ruido function new_window = track_obj( img, obj_hist, window, thresh ) probimg = cvcalcbackproject( img, obj_hist ); % Eliminamos pequeños huecos a través de la operación morfológica 'close' probimg = cvclose( probimg, 3, 2 ); probimg = cvthresh( probimg, thresh ); % Umbralizamos la imagen contours = cvfindcontours( probimg, 'external' ); % Localizamos los contornos mask_img = zeros(size(contours)); for i = 1:length(contours) % Eliminamos los contornos pequeños; if contous(i).rect(3)*contous(i).rect(4) < 30 contours(i).pt = []; end end mask_img = cvfillcontours( mask_img, contours, 'w' ); % Obtenemos la mascara new_window = cvcamshift( mask_img, window ); % Aplicamos el seguidor CamShift a la mascara return; Figura 6: Seguidor de caras CamShift implementado con Matlab. 4

237 3. Aplicación de la librería OpenCV en docencia e investigación Como hemos detallado en secciones previas, la librería OpenCV nos proporciona el marco de trabajo ideal, tanto por el desarrollo de pequeñas aplicaciones prácticas, ideales como apoyo a la docencia en asignaturas relacionadas con la visión por computador, como para el desarrollo de la labor investigadora de cualquier grupo de visión. En labores docentes es de gran interés disponer de herramientas que permitan al alumno experimentar las diferentes técnicas y procedimientos teóricos (metodológicos) explicados en clase. Una de las herramientas más utilizadas a nivel académico es el paquete matemático Matlab. Este paquete se utiliza en numerosas asignaturas como apoyo a la docencia y es ampliamente conocido por el mundo universitario. Matlab dispone de un toolbox denominado Image Processing Toolbox que permite cargar imágenes en distintos formatos, visualizarlas y manejarlas como matrices numéricas. Sin embargo, carece de muchas de las características a las que hacíamos referencia en la sección 1, y que debería cumplir cualquier paquete de visión por computador que se precie. La librería OpenCV proporciona un toolbox que aprovecha muchos de los tipos de datos, estructuras y en general, la potencia que este paquete ofrece, para facilitar al usuario de nivel medio-bajo el acercamiento a muchas de las tareas habituales de la visión por computador. En la figura 6 podemos ver un ejemplo de código Matlab de un seguidor de caras denominado CamShift, en la figura 7 podemos ver la salida de dicho algoritmo. Figura 7: Salida del seguidor de caras CamShift. Otro de los lenguajes más utilizados en el ámbito universitario es el lenguaje C. La librería OpenCV también proporciona, como ya hemos visto en secciones anteriores, numerosas librerías de apoyo que nos permiten implementar de forma sencilla y rápida aplicaciones de visión, obviando aspectos tales como las características de la cámara, el formato de las imágenes, etc. En la figura 8 podemos observar el código de un programa suministrado al alumno para que se familiarice con el entorno Hawk y con el operador de Canny de extracción de bordes 7. En la figura 9 podemos observar la imagen de entrada y dos imágenes de bordes obtenidas con distintos parámetros de procesamiento. void on_trackbar(int h) { cvcanny(gray, edge, 0.0f, (float)edge_thresh*5, 3); // Detectamos la imagen de bordes cvcopy( image, cedge, edge ); // Copiamos la imagen de bordes cvshowimage(wndname, cedge); } int main( int argc, char** argv ) { char wndname[] = "Edge", tbarname[] = "Threshold", filename[] = "fruits.jpg"; if( (image = cvloadimage( filename, 1)) == 0 ) return -1; // Creamos la imagen de salida cedge = cvcreateimage(cvsize(image->width,image->height), IPL_DEPTH_8U, 3); // Convertimos a escala de grises gray = cvcreateimage(cvsize(image->width,image->height), IPL_DEPTH_8U, 1); edge = cvcreateimage(cvsize(image->width,image->height), IPL_DEPTH_8U, 1); cvcvtcolor(image, gray, CV_BGR2GRAY); cvnamedwindow(wndname, 1); // Creamos una ventana y un trackbar cvcreatetrackbar(tbarname, wndname, &edge_thresh, 100, on_trackbar); on_trackbar(0); // Mostramos la imagen cvwaitkey(0); // Esperamos a que el usuario pulse una tecla cvreleaseimage(&image); cvreleaseimage(&gray); cvreleaseimage(&edge); cvdestroywindow(wndname); return 0; } Figura 8: Operador de extracción de bordes Canny escrito con C. 7 La extracción de bordes constituye una de las etapas del procesamiento de imágenes más habituales e importantes. La librería OpenCV nos proporciona una función de extracción de bordes que nos permite trabajar en tiempo real con un rendimiento aceptable. 5

238 Imagen fuente Canny (t=1) Canny (t=30) Figura 9: Salidas del operador de Canny. Todo lo expuesto anteriormente es perfectamente extrapolable a cualquier investigador que desarrolle su labor en algún área de la visión por computador. Además, la disponibilidad del código de la librería permite añadir nuevas funcionalidades o simplemente modificar las existentes (respetando siempre los requisitos exigidos por la licencia BSD-Software libre [2] por la que se rige la misma) lo que proporciona una ventaja añadida. Así mismo, es importante señalar que existe una lista de distribución (OpenCV@yahoogroups.com) con cientos de usuarios en la que se discuten aplicaciones, bugs, etc. y un grupo de cualificados revisores encargados de examinar exhaustivamente todas las contribuciones de código antes de incorporarlas a la siguiente versión estable de la librería. 4. Conclusiones Según lo expuesto a lo largo de este artículo, The Open Computer Vision Library constituye una de las apuestas más interesantes e importantes en visión por computador a lo largo de los últimos tiempos y además Software Libre. Su estabilidad, escalabilidad, su rápido crecimiento y desarrollo garantizan su continuidad y la hacen especialmente útil en el ámbito universitario, para la realización de tareas de docencia e investigación a corto, medio y largo plazo. Referencias [1] Matrox Electronic Systems Ltd. Matrox Imaging Library (MIL) [2] Open Source Initiative. The BSD License [3] Open Source Initiative. The MIT License [4] Open Source Initiative. The Open Source Definition [5] The Open Computer Vision Library