UNIDAD I. Introduccin al Software Libre 1.1 1.2 1.

TEMAS Definicin Historia.

SUBTEMAS

Aspectos legales. 1.3.1 La licencia GPL 1.3.2 La licencia BSD 1.3.3 Otras licencias. Desarrollo bajo modelos libres 1.4.1.- Motivacin 1.4.2.- Economa

1.4

II.

Ingeniera de software libre

2.1 2.2

La catedral y el bazar Procesos en el software libre Definicin Historia La Open Source Initiative Linux Free BSD gcc make bison Apache GNOME KDE Mozilla Mono Sistemas APM (Apache-Php y MySQL

III.

El movimiento open source

3.1 3.2 3.3

IV.

Estudio de casos

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11

Unidad I.- Introduccin al software libre

1.1.- Definicin
La definicin de software libre no contempla el asunto del precio; un eslogan frecuentemente usado es "libre como en libertad, no como en cerveza gratis" o en ingls "Free as in freedom, not as in free beer" (aludiendo a la ambigedad del trmino ingls "free"), y es habitual ver a la venta CD de software libre como distribuciones Linux. Sin embargo, en esta situacin, el comprador del CD tiene el derecho de copiarlo y redistribuirlo. El software gratis puede incluir restricciones que no se adaptan a la definicin de software libre por ejemplo, puede no incluir el cdigo fuente, puede prohibir explcitamente a los distribuidores recibir una compensacin a cambio, etc.. Para evitar la confusin, algunas personas utilizan los trminos "libre" (software libre) y "gratis" (software gratis) para evitar la ambigedad de la palabra inglesa "free". Sin embargo, estos trminos alternativos son usados nicamente dentro del movimiento del software libre, aunque estn extendindose lentamente hacia el resto del mundo. Otros defienden el uso del trmino open source software (software de cdigo abierto). La principal diferencia entre los trminos "open source" y "free software" es que ste ltimo tiene en cuenta los aspectos ticos y filosficos de la libertad, mientras que el "open source" se basa nicamente en los aspectos tcnicos. En un intento por unir los mencionados trminos que se refieren a conceptos semejantes, se est extendiendo el uso de la palabra "FLOSS" con el significado de free/libre and open source software e, indirectamente, tambin a la comunidad que lo produce y apoya. De acuerdo con tal definicin, el software es "libre" garantiza las siguientes libertades:2
Libertad Descripcin

La libertad de usar el programa, con cualquier propsito.

La libertad de estudiar cmo funciona el programa y modificarlo, adaptndolo a tus necesidades.

La libertad de distribuir copias del programa, con lo cual puedes ayudar a tu prjimo.

La libertad de mejorar el programa y hacer pblicas esas mejoras a los dems, de modo que toda la comunidad se beneficie.

1.2.- Historia
Richard Stallman, creador del concepto de software libre y fundador de la Free Software Foundation. Entre los aos 1960 y 1970, el software no era considerado un producto sino un aadido que los vendedores de las grandes computadoras de la poca (las mainframes) aportaban a sus clientes para que stos pudieran usarlos. En dicha cultura, era comn que los programadores y desarrolladores de software compartieran libremente sus programas unos con otros. Este comportamiento era particularmente habitual en algunos de los mayores grupos de usuarios de la poca, como DECUS (grupo de usuarios de computadoras DEC). A finales de la dcada de 1970, las compaas iniciaron el hbito de imponer restricciones a los usuarios, con el uso de acuerdos de licencia. En 1971, cuando la informtica todava no haba sufrido su gran boom, las personas que hacan uso de ella, en mbitos universitarios y empresariales, creaban y compartan el software sin ningn tipo de restricciones. Con la llegada de los aos 1980 la situacin empez a cambiar. Las computadoras ms modernas comenzaban a utilizar sistemas operativos privativos, forzando a los usuarios a aceptar condiciones restrictivas que impedan realizar modificaciones a dicho software. En caso de que algn usuario o programador encontrase algn error en la aplicacin, lo nico que poda hacer era darlo a conocer a la empresa desarrolladora para que sta lo solucionara. Aunque el programador estuviese capacitado para solucionar el problema y lo desease hacer sin pedir nada a cambio, el contrato le impeda que modificase el software. El mismo Richard Stallman cuenta que por aquellos aos, en el laboratorio donde trabajaba, haban recibido una impresora donada por una empresa externa. El dispositivo, que era utilizado en red por todos los trabajadores, pareca no funcionar a la perfeccin, dado que cada cierto tiempo el papel se atascaba. Como agravante, no se generaba ningn aviso que se enviase por red e informase a los usuarios de la situacin. La prdida de tiempo era constante, ya que en ocasiones, los trabajadores enviaban por red sus trabajos a imprimir y al ir a buscarlos se encontraban la impresora atascada y una cola enorme de trabajos pendientes. Richard Stallman decidi arreglar el problema, e implementar el envo de un aviso por red cuando la impresora se bloqueara. Para ello necesitaba tener acceso al cdigo fuente de los controladores de la impresora. Pidi a la empresa propietaria de la impresora lo que necesitaba, comentando, sin pedir nada a cambio, qu era lo que pretenda realizar. La empresa se neg a entregarle el cdigo fuente. En ese preciso instante, Stallman se vio en una encrucijada: deba elegir entre aceptar el nuevo software propietario firmando acuerdos de no revelacin y acabar desarrollando ms software propietario con licencias restrictivas, que a su vez deberan ser ms adelante aceptadas por sus propios colegas. Con este antecedente, en 1984, Richard Stallman comenz a trabajar en el proyecto GNU, y un ao ms tarde fund la Free Software Foundation (FSF). Stallman introdujo la definicin de software libre y el concepto de "copyleft", que desarroll para otorgar libertad a los usuarios y para restringir las posibilidades de apropiacin del software.1

1.3.- Aspectos legales

Una licencia es aquella autorizacin formal con carcter contractual que un autor de un software da a un interesado para ejercer "actos de explotacin legales". Pueden existir tantas licencias como acuerdos concretos se den entre el autor y el licenciatario. Desde el punto de vista del software libre, existen distintas variantes del concepto o grupos de licencias:

1.3.1 La licencia GPL

Una de las ms utilizadas es la Licencia Pblica General de GNU (GNU GPL). El autor conserva los derechos de autor (copyright), y permite la redistribucin y modificacin bajo trminos diseados para asegurarse de que todas las versiones modificadas del software permanecen bajo los trminos ms restrictivos de la propia GNU GPL. Esto hace que sea imposible crear un producto con partes no licenciadas GPL: el conjunto tiene que ser GPL. Es decir, la licencia GNU GPL posibilita la modificacin y redistribucin del software, pero nicamente bajo esa misma licencia. Y aade que si se reutiliza en un mismo programa cdigo "A" licenciado bajo licencia GNU GPL y cdigo "B" licenciado bajo otro tipo de licencia libre, el cdigo final "C", independientemente de la cantidad y calidad de cada uno de los cdigos "A" y "B", debe estar bajo la licencia GNU GPL. En la prctica esto hace que las licencias de software libre se dividan en dos grandes grupos, aquellas que pueden ser mezcladas con cdigo licenciado bajo GNU GPL (y que inevitablemente desaparecern en el proceso, al ser el cdigo resultante licenciado bajo GNU GPL) y las que no lo permiten al incluir mayores u otros requisitos que no contemplan ni admiten la GNU GPL y que por lo tanto no pueden ser enlazadas ni mezcladas con cdigo gobernado por la licencia GNU GPL. En el sitio web oficial de GNU hay una lista de licencias que cumplen las condiciones impuestas por la GNU GPL y otras que no. 4Aproximadamente el 60% del software licenciado como software libre emplea una licencia GPL.

1.3.2 La licencia BSD

Llamadas as porque se utilizan en gran cantidad de software distribuido junto a los sistemas operativos BSD. El autor, bajo tales licencias, mantiene la proteccin de copyright nicamente para la renuncia de garanta y para requerir la adecuada atribucin de la autora en trabajos derivados, pero permite la libre redistribucin y modificacin, incluso si dichos trabajos tienen propietario. Son muy permisivas, tanto que son fcilmente absorbidas al ser mezcladas con la licencia GNU GPL con quienes son compatibles. Puede argumentarse que esta licencia asegura verdadero software libre, en el sentido que el usuario tiene libertad ilimitada con respecto al software, y que puede decidir incluso redistribuirlo como no libre. Otras opiniones estn orientadas a destacar que este tipo de licencia no contribuye al desarrollo de ms software libre (normalmente utilizando la siguiente analoga: "una licencia BSD es ms libre que una GPL si y slo si se opina tambin que un pas que permita la esclavitud es ms libre que otro que no la permite").

1.3.3 Otras licencias

Licencias estilo MPL y derivadas Esta licencia es de Software Libre y tiene un gran valor porque fue el instrumento que emple Netscape Communications Corp. para liberar su Netscape Communicator 4.0 y empezar ese proyecto tan importante para el mundo del Software Libre: Mozilla. Se utilizan en gran cantidad de productos de software libre de uso cotidiano en todo tipo de sistemas operativos. La MPL es Software Libre y promueve eficazmente la colaboracin evitando el efecto "viral" de la GPL (si usas cdigo licenciado GPL, tu desarrollo final tiene que estar licenciado GPL). Desde un punto de vista del desarrollador la GPL presenta un inconveniente en este punto, y lamentablemente mucha gente se cierra en banda ante el uso de dicho cdigo. No obstante la MPL no es tan excesivamente permisiva como las licencias tipo BSD. Estas licencias son denominadas de copyleft dbil. La NPL (luego la MPL) fue la primera licencia nueva despus de muchos aos, que se encargaba de algunos puntos que no fueron tenidos en cuenta por las licencias BSD y GNU. En el espectro de las licencias de software libre se la puede considerar adyacente a la licencia estilo BSD, pero perfeccionada.

Copyleft
Hay que hacer constar que el titular de los derechos de autor (copyright) de un software bajo licencia copyleft puede tambin realizar una versin modificada bajo su copyright original, y venderla bajo cualquier licencia que desee, adems de distribuir la versin original como software libre. Esta tcnica ha sido usada como un modelo de negocio por una serie de empresas que realizan software libre (por ejemplo MySQL); esta prctica no restringe ninguno de los derechos otorgados a los usuarios de la versin copyleft. Tambin podra retirar todas las licencias de software libre anteriormente otorgadas, pero esto obligara a una indemnizacin a los titulares de las licencias en uso. En Espaa, toda obra derivada est tan protegida como una original, siempre que la obra derivada parta de una autorizacin contractual con el autor. En el caso genrico de que el autor retire las licencias "copyleft", no afectara de ningn modo a los productos derivados anteriores a esa retirada, ya que no tiene efecto retroactivo. En trminos legales, el autor no tiene derecho a retirar el permiso de una licencia en vigencia. Si as sucediera, el conflicto entre las partes se resolvera en un pleito convencional.

1.4.- Desarrollo bajo modelos libres

1.4.1.- Motivacin

La motivacin tica, abanderada por la Free Software Foundation, heredera de la cultura hacker, y partidaria del apelativo libre, que argumenta que el software es conocimiento y debe poderse difundir sin trabas. Su ocultacin es una actitud antisocial y la posibilidad de modificar programas es una forma de libertad de expresin. La motivacin pragmtica, abanderada por la Open Source Initiative y partidaria del apelativo abierto, que argumenta ventajas tcnicas y econmicas, con respecto a evitar una tragedia de los anticomunes mejorando los incentivos.

Aparte de estas dos grandes motivaciones, la gente que trabaja en software libre suele hacerlo por muchas otras razones, que van desde la diversin a la mera retribucin econmica, que es posible debido a modelos de negocio sustentables. Ventajas del Software libre:

Bajo costo de adquisicin: Se trata de un software econmico ya que permite un ahorro de grandes cantidades en la adquisicin de las licencias. Innovacin tecnolgica: Esto se debe a que cada usuario puede aportar sus conocimientos y su experiencia y as decidir de manera conjunta hacia donde se debe dirigir la evolucin y el desarrollo del software. Este es un gran avance en la tecnologa mundial. Independencia del proveedor: Al disponer del cdigo fuente, se garantiza una independencia del proveedor que hace que cada empresa o particular pueda seguir contribuyendo al desarrollo y los servicios del software. Escrutinio pblico: Esto hace que la correccin de errores y la mejora del producto se lleven a cabo de manera rpida y eficaz por cada uno de los usuarios que lleguen a utilizar el producto. Adaptacin del software: Esta cualidad resulta de gran utilidad para empresas e industrias especficas que necesitan un software personalizado para realizar un trabajo especfico y con el software libre se puede realizar y con costes mucho ms razonables. Lenguas: Aunque el software se cree y salga al mercado en una sola lengua, el hecho de ser software libre facilita en gran medida su traduccin y localizacin para que usuarios de diferentes partes del mundo puedan aprovechar estos beneficios.

22

1.4.2.- Economa
El negocio detrs del software libre se caracteriza por la oferta de servicios adicionales al software como: la personalizacin y/o instalacin del mismo, soporte tcnico, donaciones, patrocinios; en contraposicin al modelo de negocio basado en licencias predominante en el software de cdigo cerrado.7 Una vez que un producto de software libre ha empezado a circular, rpidamente est disponible a un costo muy bajo. Al mismo tiempo, su utilidad no decrece. El software, en general, podra ser considerado un bien de uso inagotable, tomando en cuenta que su costo marginal es pequesimo y que no es un bien sujeto a rivalidad (la posesin del bien por un agente econmico no impide que otro lo posea). Puesto que el software libre permite el libre uso, modificacin y redistribucin, a menudo encuentra un hogar entre usuarios para los cuales el coste del software no libre es a veces prohibitivo, o como alternativa a la piratera. Tambin es sencillo modificarlo localmente, lo que permite que sean posibles los esfuerzos de traduccin a idiomas que no son necesariamente rentables comercialmente. La mayora del software libre se produce por equipos internacionales que cooperan a travs de la libre asociacin. Los equipos estn tpicamente compuestos por individuos con una amplia variedad de motivaciones, y pueden provenir tanto del sector privado, del sector voluntario o del sector pblico. Existen muchas posturas acerca de la relacin entre el software libre y el actual sistema poltico-econmico:

Algunos consideran el software libre como un competidor contra el centralismo en empresas y gobiernos, una forma de orden espontneo o de anarquismo prctico.6 Algunos consideran el software libre como una forma de trabajo colaborativo en un modelo de mercado, tal como se haba planteado el cooperativismo. Algunos comparan el software libre a una economa del regalo, donde el valor de una persona est basado en lo que sta da a los dems, sin que incurra valor monetario formal de por medio. Grupos como Oekonux e Hipatia consideran que todo debera producirse de esta forma y que este modelo de produccin no se limita a reemplazar el modelo no libre de desarrollo del software. La cooperacin basada en la libre asociacin puede usarse y se usa para otros propsitos (tales como escribir enciclopedias, por ejemplo). Hay proyectos de desarrollo con impulso gubernamental que utilizan software libre, as como en proyectos de voluntariado en pases del tercer mundo.

Las implicaciones polticas y econmicas del software libre, o su afinidad con el antiautoritarismo, son discutidas. Mientras para unos estas implicaciones son notorias y representan un factor importante a tomarse en cuenta, para otros si bien podra existir una leve relacin, no tiene suficiente relevancia.

Unidad II.- Ingeniera del software libre

2.1 La catedral y el bazar
Raymond establece una analoga entre la forma de construir las catedrales medievales y la manera clsica de producir software. Argumenta que en ambos casos existe una clara distribucin de tareas y roles, destacando la existencia de un diseador que est por encima de todo y que ha de controlar en todo momento el desarrollo de la actividad. Asimismo, la planificacin est estrictamente controlada, dando lugar a unos procesos claramente detallados en los que idealmente cada participante en la actividad tiene un rol especfico muy delimitado. Dentro de lo que Raymond toma como el modelo de creacin de catedrales no slo tienen cabida los procesos pesados que podemos encontrar en la industria del software (el modelo en cascada clsico, las diferentes vertientes del Rational Unified Process, etc.), sino que tambin entran en l proyectos de software libre, como es el caso de GNU y NetBSD. Para Raymond, estos proyectos se encuentran fuertemente centralizados, ya que unas pocas personas son las que realizan el diseo e implementacin del software. Las tareas que desempean estas personas, as como sus roles estn perfectamente definidos y alguien que quisiera entrar a formar parte del equipo de desarrollo necesitara que se le asignara una tarea y un rol segn las necesidades del proyecto. Por otra parte, las entregas de este tipo de programas se encuentran espaciadas en el tiempo siguiendo una planificacin bastante estricta. Esto supone tener pocas entregas del software y ciclos entre las entregas largos y que constan de varias etapas. El modelo antagnico al de la catedral es el bazar. Segn Raymond, algunos de los programas de software libre, en especial el ncleo Linux, se han desarrollado siguiendo un esquema similar al de un bazar oriental. En un bazar no existe una mxima autoridad que controle los procesos que se estn desarrollando ni que planifique estrictamente lo que ha de suceder. Por otro lado, los roles de los participantes pueden cambiar de manera continua (los vendedores pueden pasar a ser clientes) y sin indicacin externa. Pero lo ms novedoso de La Catedral y el Bazar es la descripcin del proceso que ha hecho de Linux un xito dentro del mundo del software libre; es una sucesin de buenas maneras para aprovechar al mximo las posibilidades que ofrece la disponibilidad de cdigo fuente y la interactividad mediante el uso de sistemas y herramientas telemticas. Un proyecto de software libre suele surgir a raz de una accin puramente personal; la causa se ha de buscar en un desarrollador que vea limitada su capacidad de resolver un problema. El desarrollador ha de tener los conocimientos necesarios para, por lo menos, empezar a resolverlo. Una vez que haya conseguido tener algo usable, con algo de funcionalidad, sencillo y, a ser posible, bien diseado o escrito, lo mejor que puede hacer es compartir esa solucin con la comunidad del software libre. Es lo que se denomina la publicacin pronta (release early en ingls) y que permite llamar la atencin de otras personas (generalmente desarrolladores) que tengan el mismo problema y que puedan estar interesados en la solucin.

Uno de los principios bsicos de este modelo de desarrollo es considerar a los usuarios como codesarrolladores. Ha de tratrseles con mimo, no slo porque pueden proporcionar publicidad mediante el boca a boca, sino tambin por el hecho de que realizarn una de las tareas ms costosas que existe en la generacin de software: las pruebas. Al contrario que el codesarrollo, que es difcilmente escalable, la depuracin y las pruebas tienen la propiedad de ser altamente paralelizables. El usuario ser el que tome el software y lo pruebe en su mquina bajo unas condiciones especficas (una arquitectura, unas herramientas, etc.), una tarea que multiplicada por un gran nmero de arquitecturas y entornos supondra un gran esfuerzo para el equipo de desarrollo. Si se trata a los usuarios como desarrolladores puede darse el caso de que alguno de ellos encuentre un error y lo solucione, enviando un parche al desarrollador del proyecto para que el problema est solucionado en la siguiente versin. Tambin puede suceder, por ejemplo, que una persona diferente al que descubra un error sea la que finalmente lo entienda y corrija. En cualquier caso, todas estas circunstancias son muy provechosas para el desarrollo del software, por lo que es muy beneficioso entrar en una dinmica de esta ndole. Esta situacin se torna ms efectiva con entregas frecuentes, ya que la motivacin para encontrar, notificar y corregir errores es alta debido a que se supone que va ser atendido inmediatamente. Adems, se consiguen ventajas secundarias, como el hecho de que al integrar frecuentemente -idealmente una o ms veces al da- no haga falta una ltima fase de integracin de los mdulos que componen el programa. Esto se ha denominado publicacin frecuente (en la terminologa anglosajona se conoce como release often) y posibilita una gran modularidad narduzzo: modularity: 03 a la vez que maximiza el efecto propagandstico que tiene publicar una nueva versin del software. Nota: La gestin de nuevas versiones depende lgicamente del tamao del proyecto, ya que la problemtica a la que hay que enfrentarse no es igual cuando el equipo de desarrollo tiene dos componentes a cuando son cientos. Mientras en los proyectos pequeos en general este proceso es ms bien informal, la gestin de entregas en los proyectos grandes suele seguir un proceso definido no exento de cierta complejidad. Existe un artculo titulado Release Management Within Open Source Projects ehrenkrantz03: release que describe detalladamente la secuencia que se sigue en el servidor web Apache, el ncleo del sistema operativo Linux y el sistema de versiones Subversion. Para evitar que la publicacin frecuente asuste a usuarios que prioricen la estabilidad sobre la rapidez con la que el software evoluciona, algunos proyectos de software libre cuentan con varias ramas de desarrollo en paralelo. El caso ms conocido es el del ncleo Linux, que tiene una rama estable -dirigida a aquellas personas que estiman su fiabilidad- y otra inestable -pensada para desarrolladores- con las ltimas innovaciones y novedades.

2.2 Procesos en el software libre

Aunque el software libre no est necesariamente asociado con un proceso de desarrollo software especfico, existe una amplio consenso sobre los procesos ms comunes que se utilizan. Esto no quiere decir que no existan proyectos de software libre que hayan sido creados utilizando procesos clsicos como el modelo en cascada. Generalmente el modelo de desarrollo en proyectos de software libre suele ser ms informal, debido a que gran parte del equipo de desarrollo realiza esas tareas de manera voluntaria y sin recompensa econmica, al menos directa, a cambio. La forma en la que se capturan requisitos en el mundo del software libre depende tanto de la edad como del tamao del proyecto. En las primeras etapas, fundador de proyecto y usuario suelen coincidir en una misma persona. Ms adelante, y si el proyecto crece, la captura de requisitos suele tener lugar a travs de las listas de correo electrnico y se suele llegar a una clara distincin entre el equipo de desarrollo - o al menos los desarrolladores ms activos - y los usuarios. Para proyectos grandes, con muchos usuarios y muchos desarrolladores, la captura de requisitos se hace mediante la misma herramienta que se utiliza para gestionar los errores del proyecto. En este caso, en vez de hablar de errores, se refieren a actividades, aunque el mecanismo utilizado para su gestin es idntico al de la correccin de errores (se la clasificar segn importancia, dependencia, etc. y se podr monitorizar si ha sido resuelta o no). El uso de esta herramienta para la planificacin es ms bien reciente, por lo que se puede observar cmo en el mundo del software libre existe una cierta evolucin desde la carencia absoluta a un sistema centralizado de gestin ingenieril de actividades, aunque indudablemente ste sea bastante limitado. En cualquier caso, no suele ser comn un documento que recoja los requisitos tal y como es normal en el modelo en cascada. En cuanto al diseo global del sistema, slo los grandes proyectos suelen tenerlo documentado de manera exhaustiva. En el resto de proyectos, lo ms probable es que el o los desarrolladores principales sean los nicos que lo posean -a veces slo en su mente-, o que vaya fragundose en versiones posteriores del software. La carencia de un diseo detallado no slo implica limitaciones en cuanto a la posible reutilizacin de mdulos, sino que tambin es un gran hndicap a la hora de permitir el acceso a nuevos desarrolladores, ya que stos se tendrn que enfrentar a un proceso de aprendizaje lento y costoso. El diseo detallado, por su parte, tampoco est muy generalizado. Su ausencia implica que se pierdan muchas posibilidades de reutilizacin de cdigo. La implementacin es la fase en la que se concentra el mayor esfuerzo por parte de los desarrolladores de software libre, entre otras razones por que a ojos de los desarrolladores es manifiestamente la ms divertida. Para ello se suele seguir el paradigma de programacin clsico de prueba y error hasta que se consiguen los resultados apetecidos desde el punto de vista subjetivo del programador. Histricamente, raro es el caso en el que se han incluidas pruebas unitarias conjuntamente con el cdigo, an cuando facilitaran la modificacin o inclusin de cdigo posterior por parte de otros desarrolladores. En el caso de algunos proyectos grandes, como por ejemplo Mozilla, existen mquinas dedicadas exclusivamente a descargarse los repositorios que contienen el cdigo ms reciente para

compilarlo para diferentes arquitecturas reis:mozilla:02. Los errores detectados se notifican a una lista de correo de desarrolladores. Sin embargo, las pruebas automticas no estn muy arraigadas. Por lo general sern los propios usuarios, dentro de la gran variedad de usos, arquitecturas y combinaciones, los que las realizarn. Esto tiene la ventaja de que se paralelizan a un coste mnimo para el equipo de desarrollo. El problema que plantea este modelo es cmo organizarse para que la realimentacin por parte de los usuarios exista y sea lo ms eficiente posible. En cuanto al mantenimiento del software en el mundo del software libre -refirindonos con ello al mantenimiento de versiones antiguas-, es una tarea cuya existencia depende del proyecto. En proyectos donde se requiere una gran estabilidad, como ncleos del sistema operativo, etc., se mantienen versiones antiguas del proyecto, ya que un cambio a una nueva versin puede resultar traumtico. Pero, por lo general, en la mayora de los proyectos de software libre, si se tiene una versin antigua y se encuentra un error, los desarrolladores no suelen ponerse a corregirlo y aconsejan utilizar la versin ms moderna con la esperanza de que haya desaparecido por el hecho de que el software ha evolucionado.

Cdigo abierto es el trmino con el que se conoce al software distribuido y desarrollado libremente. El cdigo abierto tiene un punto de vista ms orientado a los beneficios prcticos de compartir el cdigo que a las cuestiones ticas y morales las cuales destacan en el llamado software libre.

Historia
Artculo principal: Historia del cdigo abierto.

Su uso naci por primera vez en 1998 de la mano de algunos usuarios de la comunidad del software libre, tratando de usarlo como reemplazo al ambiguo nombre original en ingls del software libre (free software). Free en ingls significa dos cosas distintas dependiendo del contexto: gratuidad y libertad. Lo cual implica, para el caso que nos ocupa, "software que podemos leer, modificar y redistribuir gratuitamente" (software gratuito) y, adems, software libre, segn la acepcin espaola de libertad. El trmino para algunos no result apropiado como reemplazo para el ya tradicional free software, pues eliminaba la idea de libertad, confundida usualmente con la simple gratuidad. No obstante, el trmino cdigo abierto contina siendo ambivalente, puesto que se usa en la actualidad por parte de programadores que no ofrecen software libre pero, en cambio, s ofrecen el cdigo fuente de los programas para su revisin o modificacin previamente autorizada por parte de sus pares acadmicos. Dada la ausencia de tal ambigedad en la lengua espaola, el trmino software libre es adecuado para referirse a programas que se ofrecen con total libertad de modificacin, uso y distribucin bajo la regla implcita de no modificar dichas libertades hacia el futuro. De hecho en ingls tambin se usa el trmino "libre software" para evitar ambigedades semnticas. Desde el punto de vista de una "traduccin estrictamente literal", el significado textual de "cdigo abierto" es que "se puede examinar el cdigo fuente", por lo que puede ser interpretado como un trmino ms dbil y flexible que el del software libre. Sin embargo, ambos movimientos reconocen el mismo conjunto de licencias y mantienen principios equivalentes. Sin embargo, hay que diferenciar los programas de cdigo abierto, que dan a los usuarios la libertad de mejorarlos, de los programas que simplemente tienen el cdigo fuente disponible, previa restricciones sobre su uso o modificacin. En la actualidad el cdigo abierto se utiliza para definir un movimiento nuevo de software (la Iniciativa Open Source), diferente al movimiento del software libre, incompatible con este ltimo desde el punto de vista filosfico, y completamente equivalente desde el punto

de vista prctico, de hecho, ambos movimientos trabajan juntos en el desarrollo prctico de proyectos. La idea bajo el concepto de cdigo abierto es sencilla: cuando los programadores (en Internet) pueden leer, modificar y redistribuir el cdigo fuente de un programa, ste evoluciona, se desarrolla y mejora. Los usuarios lo adaptan a sus necesidades, corrigen sus errores a una velocidad impresionante, mayor a la aplicada en el desarrollo de software convencional o cerrado, dando como resultado la produccin de un mejor software.

Cronologa de una idea

27 de septiembre de 1983: Richard Stallman inicia el proyecto GNU. 25 de agosto de 1991: Linus Torvalds publica un mensaje en el grupo de noticias USENET comp.os.minix acerca del nuevo kernel de tipo Unix (Linux) que ha estado desarrollando. 22 de enero de 1998: Netscape anuncia que liberar el cdigo fuente de Navigator. 3 de febrero de 1998: en la reunin de Palo Alto se acua el trmino "open source" y durante la semana siguiente Bruce Perens y Eric S. Raymond lanzan opensource.org. 31 de marzo de 1998: el cdigo de Navigator ya est disponible: en unas horas, mejoras del programa invaden la red. 7 de mayo de 1998: Corel Corporation anuncia Netwinder, un ordenador econmico que corre bajo GNU/Linux. 11 de mayo de 1998: Corel anuncia sus planes de adaptar WordPerfect y el resto de sus programas de ofimtica a GNU/Linux. 28 de mayo de 1998: Sun Microsystems y Adaptec se unen a Linux International, las primeras grandes empresas vendedoras de equipos y sistemas operativos en hacerlo. 13-17 de julio de 1998: Oracle e Informix anuncian que conectarn sus bases de datos a GNU/Linux. 10 de agosto de 1998: Sun Microsystems ofrece Solaris a usuarios individuales e instituciones educativas o sin nimo de lucro. 1 de noviembre de 1998: se publican los Halloween Documents: planes de Microsoft contra GNU/Linux y otros proyectos open source. 16 de diciembre de 1998: IDG anuncia que la cuota de mercado del GNU/Linux se increment un 212% en 1998. 1-5 de marzo de 1999: LinuxWorld Conference and Expo: primera exposicin sobre GNU/Linux. HP, IBM, SAP inician el comienzo del apoyo de las firmas comerciales. 15 de marzo de 1999: Apple lanza Darwin bajo licencia open source. 4 de junio de 1999: Microsoft afirma que Linux vende ms que Windows 98 en las grandes superficies.1

Entre 1998 y 2000 se observ un gran crecimiento en la popularidad de GNU/Linux y de la formacin de muchas empresas "pro software de cdigo abierto". El movimiento tambin captur la atencin de la principal industria del software, llevando al software de cdigo

abierto las ofertas de compaas de software consolidadas como Sun Microsystems con StarOffice e IBM con OpenAFS.

Movimiento del "cdigo abierto"

Mapa conceptual del software libre y de cdigo abierto. La idea del cdigo abierto se centra en la premisa de que al compartir el cdigo o, el programa resultante tiende a ser de calidad superior al software propietario, es una visin tcnica. Por otro lado, el software libre tiene tendencias filosficas e incluso morales: el software propietario, al no poder compartirse, es "antitico" dado que prohibir compartir entre seres humanos va en contra del sentido comn. Al igual que el software libre, el cdigo abierto u open source tiene una serie de requisitos2 necesarios para que un programa pueda considerarse dentro de este movimiento, stos son:

Libre redistribucin: el software debe poder ser regalado o vendido libremente. Cdigo fuente: el cdigo fuente debe estar incluido u obtenerse libremente. Trabajos derivados: la redistribucin de modificaciones debe estar permitida. Integridad del cdigo fuente del autor: las licencias pueden requerir que las modificaciones sean redistribuidas slo como parches. Sin discriminacin de personas o grupos: nadie puede dejarse fuera. Sin discriminacin de reas de iniciativa: los usuarios comerciales no pueden ser excluidos. Distribucin de la licencia: deben aplicarse los mismos derechos a todo el que reciba el programa La licencia no debe ser especfica de un producto: el programa no puede licenciarse solo como parte de una distribucin mayor.

La licencia no debe restringir otro software: la licencia no puede obligar a que algn otro software que sea distribuido con el software abierto deba tambin ser de cdigo abierto. La licencia debe ser tecnolgicamente neutral: no debe requerirse la aceptacin de la licencia por medio de un acceso por clic de ratn o de otra forma especfica del medio de soporte del software.

Este declogo es compatible con las cuatro libertades del software libre.