Historia de Unix.-UnixUnix (registrado oficialmente como UNIX®) es un sistema operativo portable, multitarea y multiusuario; desarrollado, en principio, en 1969 por un grupo de empleados de los laboratorios Bell de AT&T, entre los que figuran Ken Thompson, Dennis Ritchie y Douglas McIlroy.Hasta 2009, el propietario de la marca UNIX® fue The Open Group, un consorcio de normalización industrial. A partir de marzo de 2010 y tras una larga batalla legal, esta ha pasado nuevamente a ser propiedad de Novell, Inc. Sólo los sistemas totalmente compatibles y que se encuentran certificados por la especificación Single UNIX Specification pueden ser denominados "UNIX®" (otros reciben la denominación "similar a un sistema Unix" o "similar a Unix"). En ocasiones, suele usarse el término "Unix tradicional" para referirse a Unix o a un sistema operativo que cuenta con las características de UNIX Versión 7 o UNIX System V.Contenido1 Historia2 Familias3 Familias UNIX más significativasHistoriaA finales de 1960, el Instituto Tecnológico de Massachusetts, los Laboratorios Bell de AT&T y General Electric trabajaban en un sistema operativo experimental llamado Multics (Multiplexed Information and Computing System), desarrollado para ejecutarse en una computadora central (mainframe) modelo GE-645. El objetivo del proyecto era desarrollar un gran sistema operativo interactivo que contase con muchas innovaciones, entre ellas mejoras en las políticas de seguridad. El proyecto consiguió dar a luz versiones para producción, pero las primeras versiones contaban con un pobre rendimiento. Los laboratorios Bell de AT&T decidieron desvincularse y dedicar sus recursos a otros proyectos.Uno de los programadores de los laboratorios Bell, Ken Thompson, siguió trabajando para la computadora GE-635 y escribió un juego llamado Space Travel, (Viaje espacial). Sin embargo, descubrió que el juego era lento en la máquina de General Electric y resultaba realmente caro, algo así como 75 dólares de EE.UU. por cada partida.De este modo, Thompson escribió nuevamente el programa, con ayuda de Dennis Ritchie, en lenguaje ensamblador, para que se ejecutase en una computadora DEC PDP-7. Esta experiencia, junto al trabajo que desarrolló para el proyecto Multics, condujo a Thompson a iniciar la creación de un nuevo sistema operativo para la DEC PDP-7. Thompson y Ritchie lideraron un grupo de programadores, entre ellos a Rudd Canaday, en los laboratorios Bell, para desarrollar tanto el sistema de ficheros como el sistema operativo multitarea en sí. A lo anterior, agregaron un intérprete de órdenes (o intérprete de comandos) y un pequeño conjunto de programas. El proyecto fue bautizado UNICS, como acrónimo Uniplexed Information and Computing System, pues sólo prestaba servicios a dos usuarios (de acuerdo con Andrew Tanenbaum, era sólo a un usuario). La autoría de esta sigla se le atribuye a Brian Kernighan, ya que era un hack de Multics. Dada la popularidad que tuvo un juego de palabras que consideraba a UNICS un sistema MULTICS castrado (pues eunuchs, en inglés, es un homófono de UNICS), se cambió el nombre a UNIX, dando origen al legado que llega hasta nuestros días.Hasta ese instante, no había existido apoyo económico por parte de los laboratorios Bell, pero eso cambió cuando el Grupo de Investigación en Ciencias de la Computación decidió utilizar UNIX en una máquina superior a la PDP-7. Thompson y Ritchie lograron cumplir con la solicitud de agregar herramientas que permitieran el procesamiento de textos a UNIX en una máquina PDP-11/20, y como consecuencia de ello consiguieron el apoyo económico de los laboratorios Bell. Fue así como por vez primera, en 1970, se habla oficialmente del sistema operativo UNIX ejecutado en una PDP-11/20. Se incluía en él un programa para dar formato a textos (runoff) y un editor de texto. Tanto el sistema operativo como los programas fueron escritos en el lenguaje ensamblador de la PDP-11/20. Este "sistema de procesamiento de texto" inicial, compuesto tanto por el sistema operativo como de runoff y el editor de texto, fue utilizado en los laboratorios Bell para procesar las solicitudes de patentes que ellos recibían. Pronto, runoff evolucionó hasta convertirse en troff, el primer programa de edición electrónica que permitía realizar composición tipográfica. El 3 de noviembre de 1971 Thomson y Ritchie publicaron un manual de programación de UNIX (título original en inglés: "UNIX Programmer's Manual").En 1972 se tomó la decisión de escribir nuevamente UNIX, pero esta vez en el lenguaje de programación C. Este cambio significaba que UNIX podría ser fácilmente modificado para funcionar en otras computadoras (de esta manera, se volvía portable) y así otras variaciones podían ser desarrolladas por otros programadores. Ahora, el código era más conciso y compacto, lo que se tradujo en un aumento en la velocidad de desarrollo de UNIX. AT&T puso a UNIX a disposición de universidades y compañías, también al gobierno de los Estados Unidos, a través de licencias.13 Una de estas licencias fue otorgada al Departamento de Computación de la Universidad de California, con sede en Berkeley. En 1975 esta institución desarrolló y publicó su propio sucedáneo de UNIX, conocida como Berkeley Software Distribution (BSD), que se convirtió en una fuerte competencia para la familia UNIX de AT&T.

Mientras tanto, AT&T creó una división comercial denominada Unix Systems Laboratories para la explotación comercial del sistema operativo. El desarrollo prosiguió, con la entrega de las versiones 4, 5 y 6 en el transcurso de 1975. Estas versiones incluían los pipes o tuberías, lo que permitió dar al desarrollo una orientación modular respecto a la base del código, consiguiendo aumentar aún más la velocidad de desarrollo. Ya en 1978, cerca de 600 o más máquinas estaban ejecutándose con alguna de las distintas encarnaciones de UNIX.La versión 7, la última versión del UNIX original con amplia distribución, entró en circulación en 1979. Las versiones 8, 9 y 10 se desarrollaron durante la década de 1980, pero su circulación se limitó a unas cuantas universidades, a pesar de que se publicaron los informes que describían el nuevo trabajo. Los resultados de esta investigación sirvieron de base para la creación de Plan 9 from Bell Labs, un nuevo sistema operativo portable y distribuido, diseñado para ser el sucesor de UNIX en investigación por los Laboratorios Bell.AT&T entonces inició el desarrollo de UNIX System III, basado en la versión 7, como una variante de tinte comercial y así vendía el producto de manera directa. La primera versión se lanzó en 1981. A pesar de lo anterior, la empresa subsidiaria Western Electric seguía vendiendo versiones antiguas de Unix basadas en las distintas versiones hasta la séptima. Para finalizar con la confusión con todas las versiones divergentes, AT&T decidió combinar varias versiones desarrolladas en distintas universidades y empresas, dando origen en 1983 al Unix System V Release 1. Esta versión presentó características tales como el editor Vi y la biblioteca curses, desarrolladas por Berkeley Software Distribution en la Universidad de California, Berkeley. También contaba con compatibilidad con las máquinas VAX de la compañía DEC.Hacia 1991, un estudiante de ciencias de la computación de la Universidad de Helsinki, llamado Linus Torvalds desarrolló un núcleo para computadoras con arquitectura x86 de Intel que emulaba muchas de las funcionalidades de UNIX y lo lanzó en forma de código abierto en 1991, bajo el nombre de Linux. En 1992, el Proyecto GNU comenzó a utilizar el núcleo Linux junto a sus programas.En 1993, la compañía Novell adquirió la división Unix Systems Laboratories de AT&T junto con su propiedad intelectual. Esto ocurrió en un momento delicado en el que Unix Systems Laboratories disputaba una demanda en los tribunales contra BSD por infracción de los derechos de copyright, revelación de secretos y violación de marca de mercado.Aunque BSD ganó el juicio, Novell descubrió que gran parte del código de BSD fue copiada ilegalmente en UNIX System V. En realidad, la propiedad intelectual de Novell se reducía a unos cuantos archivos fuente. La correspondiente contra-demanda acabó en un acuerdo extrajudicial cuyos términos permanecen bajo secreto a petición de Novell.En 1995, Novell vendió su división UNIX comercial (es decir, la antigua Unix Systems Laboratories) a Santa Cruz Operation (SCO) reservándose, aparentemente, algunos derechos de propiedad intelectual sobre el software. SCO continúa la comercialización de System V en su producto UnixWare, que durante cierto tiempo pasó a denominarse OpenUnix, aunque ha retomado de nuevo el nombre de UnixWare.FamiliasComo se puede deducir de esta breve reseña histórica, existen varias familias del sistema operativo UNIX, que han evolucionado de manera independiente a lo largo de los años. Cada familia se distingue no tanto por sus diferencias técnicas como por sus diferencias en propiedad intelectual. Se observa que todas las familias se han visto contaminadas, directa o indirectamente, por otras familias.

Familias UNIX más significativas AT&T: la familia que tuvo su origen en el UNIX de AT&T. Considerada la familia UNIX "pura" y original. Sus sistemas

operativos más significativos son UNIX System III y UNIX System V. BSD: familia originada por el licenciamiento de UNIX a Berkely. BSD se reescribió para no incorporar propiedad intelectual

originaria de AT&T en la versión 4. La primera implementación de los protocolos TCP/IP que dieron origen a Internet son la pila (stack) TCP/IP BSD.

AIX: Esta familia surge por el licenciamiento de UNIX System III a IBM. Xenix: familia derivada de la adquisición de los derechos originales de AT&T primero por parte de Microsoft y de esta los

vendió a SCO. GNU: En 1983, Richard Stallman anunció el Proyecto GNU, un ambicioso esfuerzo para crear un sistema similar a Unix, que

pudiese ser distribuido libremente. El software desarrollado por este proyecto -por ejemplo, GNU Emacs y GCC - también han sido parte fundamental de otros sistemas UNIX.

Linux: En 1991, cuando Linus Torvalds empezó a proponer el núcleo Linux y a reunir colaboradores, las herramientas GNU eran la elección perfecta. Al combinarse ambos elementos, conformaron la base del sistema operativo (basado en POSIX) que hoy se conoce como GNU/Linux. Las distribuciones basadas en el núcleo, el software GNU y otros agregados entre las que se pueden mencionar a Slackware Linux, Red Hat Linux y Debian GNU/Linux se han hecho populares tanto entre los aficionados a la computación como en el mundo empresarial. Obsérvese que Linux tiene un origen independiente, por lo que se considera un 'clónico' de UNIX y no un UNIX en el sentido histórico.Las interrelaciones entre estas familias son las siguientes, aproximadamente en orden cronológico:

La familia BSD surge del licenciamiento del UNIX original de AT&T. Xenix también surge por licenciamiento del UNIX original de AT&T, aunque aún no era propiedad de SCO. AIX surge por licenciamiento de UNIX System III, pero también incorpora propiedad intelectual de BSD. La familia original AT&T incorpora ilegalmente propiedad intelectual de BSD en UNIX System III r3. La familia AIX vuelve a incorporar propiedad intelectual de la familia AT&T, esta vez procedente de UNIX System V.

Linux incorpora propiedad intelectual de BSD, gracias a que éste también se libera con una licencia de código abierto denominada Open-source BSD.

Según SCO Group, Linux incorpora propiedad intelectual procedente de AIX, gracias a la colaboración de IBM en la versión 2.4, mas aún no está demostrado, hay un proceso judicial al respecto: Disputas de SCO sobre Linux.Historia de LinuxEl núcleo Linux, ha sido marcado por un crecimiento constante en cada momento de su historia. Desde la primera publicación de su código fuente en 1991, nacido desde un pequeño número de archivos en lenguaje C bajo una licencia que prohíbe la distribución comercial a su estado actual de cerca de 296 MiBs de fuente bajo la Licencia pública general de GNU.El nombre Linux ha generado gran controversia y nuevas alternativas no han tardado en aparecer para hacerle competencia.Contenido1 Antecedentes2 Aparición de Linux 2.1 Desarrollo del núcleo Linux2.2 El nombre2.3 Linux bajo la GNU GPL2.4 GNU/LinuxAntecedentesEn 1983 Richard Stallman inició el Proyecto GNU, con el propósito de crear un sistema operativo similar y compatible con UNIX y los estándares POSIX. Dos años más tarde, 1985, creó la Fundación del Software Libre (FSF) y desarrolló la Licencia pública general de GNU (GNU GPL), para tener un marco legal que permitiera difundir libremente el software. De este modo el software de GNU fue desarrollado muy rápidamente, y por muchas personas. A corto plazo, se desarrolló una multiplicidad de programas, de modo que a principios de los años 1990 había casi bastante software disponible como para crear un sistema operativo completo. Sin embargo, todavía le faltaba un núcleo.Esto debía ser desarrollado en el proyecto GNU Hurd, pero Hurd demostró desarrollarse muy inactivamente, porque encontrar y reparar errores (eliminación de fallos, debugging en inglés) era muy difícil, debido a las características técnicas del diseño del micronúcleo.Otro proyecto de sistema operativo software libre, en los años 1980 fue BSD. Este fue desarrollado en la Universidad de Berkeley desde la 6ª edición de Unix de AT&T. Puesto que el código de AT&T Unix estaba contenido en BSD, AT&T presentó una demanda a principios de los años 1990 contra la Universidad de Berkeley, la cual limitó el desarrollo de BSD y redujo el desarrollo. Así a principios de los años 1990 no produjo ningún sistema completo libre.El futuro de BSD era incierto debido al pleito y detuvo el desarrollo. Además, el Proyecto GNU gradualmente se desarrollaba pero, este carecía de un bien formado núcleo UNIX. Esto dejó un nicho crítico abierto, que Linux llenaría muy prontoAparición de LinuxDesarrollo del núcleo LinuxEn 1991 , en Helsinki, Linus Torvalds comenzó un proyecto que más tarde llegó a ser el núcleo Linux. Esto fue al principio un emulador terminal, al cual Torvalds solía tener acceso en los grandes servidores UNIX de la universidad. Él escribió el programa expresamente para el hardware que usaba, e independiente de un sistema operativo, porque quiso usar las funciones de su nueva computadora personal con un procesador 80386. Este es aún el estándar de hoy. El sistema operativo que él usó durante el desarrollo fue Minix, y el compilador inicial fue el GNU C compiler, que aún es la opción principal para compilar Linux hoy (aunque Linux puede ser compilado bajo otros compiladores, tal como el Intel C Compiler escribió en su libro "Solamente por diversión", él tarde o temprano comprendió que había escrito un núcleo de sistema operativo. El 25 de agosto de 1991, 20:57:08 GMT, anunció este sistema en un envío a la red Usenet, en el newsgroup (grupo de noticias): comp.os.minix.:Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things). I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-) Linus Benedict Torvalds (torvalds@kruuna.helsinki.fi) 

PS. Yes – it's free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.Linus TorvaldsTraducción:Hola a todos aquellos que usan Minix - Estoy haciendo un sistema operativo (gratuito) (solamente una afición, no será grande ni profesional como el GNU) para clones 386(486) AT. Este ha estado gestándose desde abril, y está comenzando a estar listo. Me gustaría recibir cualquier comentario sobre las cosas que gustan/disgustan en minix, ya que mi SO (Sistema Operativo) se le parece un poco (la misma disposición física del sistema de archivos, debido a motivos prácticos, entre otras cosas). Actualmente he portado bash(1.08) y gcc(1.40), y las cosas parecen funcionar. Esto implica que conseguiré algo práctico dentro de unos meses, y me gustaría saber qué características quiere la mayoría de la gente. Cualquier sugerencia es bienvenida, pero no prometeré que las pondré en práctica :-) Linus Benedict Torvalds (torvalds@kruuna.helsinki.fi) PD. Sí – es libre de cualquier código de minix, y tiene un sistema de archivos multi-hilo. NO es portable (usa 386 una conmutación de tarea etc.), y probablemente nunca será soportada por nada más que los discos duros AT, porque es todo lo que tengo :-(.Linus TorvaldsEl nombreLinus Torvalds había querido llamar su invención Freax, un portmanteau de freak (anormal o raro), free (libre), y "X", una alusión a Unix. Durante el inicio de su trabajo sobre el sistema, él almacenó los archivos bajo el nombre "Freax" por aproximadamente medio año. Torvalds ya había considerado el nombre "Linux", pero al principio lo había descartado por ser demasiado egocéntrico o egoísta.Para dar a otra gente la capacidad de cooperar en el sistema o sugerir mejoras, los archivos fueron colocados en el servidor ftp (ftp.funet.fi) de la Universidad de Tecnología de Helsinki (Helsinki University of Technology) (HUT), en septiembre de 1991. Ari Lemmke, colega de Torvalds en la HUT, que en ese entonces era responsable de los servidores, no estuvo de acuerdo con el nombre Freax, prefiriendo el nombre Linux. Él simplemente llamó a los archivos colocados sobre el servidor "Linux" sin consultar a Torvalds. Más tarde, sin embargo, Torvalds accedió a usar el nombre "Linux":" Después de muchas discusiones, él finalmente admitió que Linux era simplemente el mejor nombre. En el código original de la versión 0.01 de Linux, el nombre Freax fue, sin embargo, usado en el makefile. Sólo después fue usado el nombre Linux. Así el nombre, en realidad, no planificado en absoluto se hizo generalmente aceptado por todo el mundo. "Linux bajo la GNU GPLTorvalds primero publicó el núcleo Linux bajo su propia licencia, la cual fue casi una licencia de código fuente compartida (en inglés, share source) y que tenía una restricción contra la actividad comercial. En 1992, él sugirió cambiar a la GNU GPL. Primero anunció este cambio en las notas de lanzamiento de la versión 0.12. A mediados de diciembre de 1992 él publicó la versión 0.99 usando la GNU GPL.Más tarde, Torvalds dijo en una entrevista, "registrar a Linux bajo la GPL fue definitivamente la mejor cosa que alguna vez hice".9

GNU/LinuxLa designación "Linux" al principio fue usada por Torvalds sólo para el núcleo. El núcleo fue, sin embargo, con frecuencia usado junto con otro software, especialmente con el del proyecto de GNU. Esta variante de GNU rápidamente se hizo la más popular, ya que no había ningún otro núcleo libre que funcionara en ese tiempo. Cuando la gente comenzó a referirse hacia esta recopilación como "Linux", Richard Stallman, el fundador del proyecto de GNU, solicitó que se usara el nombre GNU/Linux, para reconocer el rol del software de GNU. En junio de 1994, en el boletín de GNU, Linux fue mencionado como un "clon libre de UNIX", y el Proyecto Debian comenzó a llamar a su producto GNU/Linux. En mayo de 1996, Richard Stallman publicó al editor Emacs 19.31, en el cual el tipo de sistema fue renombrado de Linux a Lignux. Esta "escritura" fue pretendida para referirse expresamente a la combinación de GNU y Linux, pero esto pronto fue abandonado en favor de "GNU/Linux".El producto terminado es más a menudo denominado simplemente como "Linux", como el más simple, el nombre original. Stallman anunció su demanda por un cambio de nombre sólo después de que el sistema ya se había hecho popular.Software Libre y Open Source.-

Software Libre y Open Source

Bajo la idea de los movimientos (o filosofías) de Software Libre y Open Source [OSIc] [OSIb] (también llamado de código abierto o software abierto), se encuentran varias formas de software, no todas del mismo tipo, pero sí compartiendo muchas ideas comunes.

La denominación de un producto de software como de código abierto conlleva como idea más importante la posibilidad de acceder a su código fuente, y la posibilidad de modificarlo y redistribuirlo de la manera que se considere conveniente, estando sujeto a una determinada licencia de código abierto, que nos da el marco legal.

Frente a un código de tipo propietario, en el cual un fabricante (empresa de software) encierra su código, ocultándolo y restringiéndose los derechos a sí misma, sin dar posibilidad de realizar ninguna adaptación ni cambios que no haya realizado previamente la empresa fabricante, el código abierto ofrece, entre otras consideraciones:

a) Acceso al código fuente, ya sea para estudiarlo (ideal para educación) o modificarlo, sea para corregir errores, adaptarlo o añadir más prestaciones.

b) Gratuidad: normalmente, el software, ya sea en forma binaria o en la forma de código fuente, puede obtenerse libremente o por una módica cantidad en concepto de gastos de empaquetamiento, distribución y valores añadidos.

c) Evitar monopolios de software propietario: no depender de una única opción o único fabricante de nuestro software. Esto es más importante cuando se trata de una gran organización, ya sea una empresa o estado, los cuales no pueden (o no deberían) ponerse en manos de una determinada única solución y pasar a depender exclusivamente de ella.

d) Un modelo de avance, no basado en la ocultación de información, sino en la compartición del conocimiento (semejante al de la comunidad científica), para lograr progresos de forma más rápida, con mejor calidad, ya que las elecciones tomadas están basadas en el consenso de la comunidad, y no en los caprichos de empresas desarrolladoras de software propietario.

Crear programas y distribuirlos junto al código fuente no es nuevo. Ya desde los inicios de la informática y en los inicios de la red Internet se había hecho así. Sin embargo, el concepto de código abierto como tal, la definición y la redacción de las condiciones que tenía que cumplir datan de mediados de 1997.

Eric Raymond y Bruce Perens fueron los que divulgaron la idea. Raymond [Ray98] era autor del ensayo titulado La catedral y el Bazar, que hablaba sobre las técnicas de desarrollo de software utilizadas por la comunidad Linux, encabezada por Linus Torvalds, y la comunidad GNU de la Free Software Foundation (FSF), encabezada por Richard Stallman. Por su parte, Bruce Perens era en aquel momento el jefe del proyecto Debian, que trabajaba en la creación de una distribución de GNU/Linux integrada únicamente con software libre. Nota

Dos de las comunidades más importantes son la FSF, con su proyecto de software GNU, y la comunidad Open Source, cuyo máximo exponente de proyecto es Linux. GNU/Linux es el resultado de la unión de sus trabajos.

Una distinción importante entre estas comunidades son las definiciones de código abierto y software libre. [Deba] [PS02]

El Software Libre (Free Software) [FSF] es un movimiento que parte de las ideas de Richard Stallman, que considera que hay que garantizar que los programas estuviesen al alcance de todo el mundo de forma gratuita, se tuviese acceso libre a éstos y pudieran utilizarse al antojo de cada uno. Una distinción importante, que causó ciertas reticencias a las empresas, es el término free. En inglés, este término tiene el doble significado de gratuito y libre. La gente de la FSF buscaba las dos cosas, pero era difícil vender ambas cosas a las empresas; la pregunta típica era: ¿cómo se podía ganar dinero con esto? La respuesta vino de la comunidad Linux (con Linus Torvalds en cabeza), cuando consiguieron tener una cosa que todavía no había logrado la comunidad GNU y la FSF: tener un sistema operativo libre con código fuente disponible. En este momento es cuando a la comunidad se le ocurrió juntar las diversas actividades que había en la filosofía del Software Libre bajo la nueva

denominación de código abierto (open source).

Open Source se registró como una marca de certificación, a la que podían adherirse los productos software que respetasen sus especificaciones. Esto no gustó a todo el mundo y suele haber cierta separación y controversias entre los dos grupos del Open Source y la FSF (con GNU), pero son más las cosas que los unen que las que los separan.

En cierta manera, para los partidarios del software libre (como la FSF), el código abierto (u open source) representa un paso en falso, ya que representa una cierta �venta � al mercado de sus ideales, y deja la puerta abierta a que se vaya haciendo propietario el software que era libre. Los partidarios de open source ven la oportunidad de promocionar el software que de otra manera estaría en una utilización minoritaria, mientras que con la divulgación y la puesta en común para todo el mundo, incluidas empresas que quieran participar en código abierto, entramos con suficiente fuerza para plantar cara al software propietario. Sin embargo, la idea que persiguen ambas filosofías es la de aumentar la utilidad del software libre, ofreciendo así una alternativa a las soluciones únicas que las grandes empresas quieren imponer. Las diferencias son más que prácticas.

Una vez establecidas las ideas básicas de la comunidad del código abierto, llegamos al punto en que había que concretar de manera clara qué criterios tenía que cumplir un producto de software para considerarse de código abierto. Había que contar con una definición de código abierto [OSIb], que inicialmente escribió Bruce Perens en junio de 1997 como resultado de comentarios de los desarrolladores de la distribución Debian Linux, y que posteriormente fue reeditada (con modificaciones menores) por la organización OSI (Open Source Initiative). Esta organización está encargada de regular la definición y controlar las licencias de código abierto.

Nota El código abierto está regulado por una definición pública que se utiliza como base de la redacción de sus licencias de software.

Un pequeño resumen (interpretación) de la definición: Un open source software [OSIb], o software de código fuente abierto, debe cumplir los requisitos si guientes:

1. Se puede copiar, regalar o vender a terceros el software, sin tener que pagar a nadie por ello. Se permite copiar el programa.

2. El programa debe incluir el código fuente y tiene que permitir la distribución tanto en forma compilada, como en fuente. O, en todo caso, hay que facilitar algún modo de obtener los códigos fuente (por ejemplo, descarga desde Internet). No está permitido ocultar el código o darlo en representaciones intermedias. Garantiza que se pueden hacer modificaciones.

3. La licencia del software tiene que permitir que se puedan realizar modificaciones y trabajos que se deriven, y que entonces se puedan distribuir bajo la misma licencia que la original. Permite reutilizar el código original.

4. Puede requerirse la integridad del código del autor, o sea, las modificaciones se pueden presentar en forma de parches al código original, o se puede pedir que tengan nombres o números distintos a los originales. Esto protege al autor de qué modificaciones puedan considerarse como suyas. Este punto depende de lo que diga la licencia del software.

5. La licencia no debe discriminar a ninguna persona o grupo. No se debe restringir el acceso al software. Un caso aparte son las restricciones por ley, como las de las exportaciones tecnológicas fuera de USA a terceros países. Si existen restricciones de este tipo, hay que mencionarlas.

6. No discriminar campos laborales. El software puede utilizarse en cualquier ambiente de trabajo, aunque no se haya pensado para él. Otra lectura es permitir fines comerciales, nadie puede impedir que el software se utilice con fines comerciales.

7. La licencia es aplicable a todo el mundo que reciba el programa.

8. Si el software forma parte de producto mayor, debe permanecer con la misma licencia. Esto controla que no se separen partes para formar software propietario (de forma no controlada). En el caso de software propietario, hay que informar que hay partes (y cuáles) de software de código abierto.

9. La licencia no debe restringir ningún software incorporado o distribuido conjuntamente, o sea, incorporarlo no debe suponer ninguna barrera para otro producto de software distribuido conjuntamente. Éste es un punto polémico, ya que parece contradecirse con el anterior, básicamente dice que cualquiera puede coger software de código abierto y añadirlo al suyo sin que afecte a las condiciones de su licencia (por ejemplo propietaria), aunque sí que, según el punto anterior, tendría que informar de que existen partes de código abierto.

10. La licencia tiene que ser tecnológicamente neutra. No deben mencionarse medios de distribución únicos, o excluirse posibilidades. Por ejemplo, no puede limitarse (por licencia) que se haga la distribución en forma de CD, ftp o mediante web.

Esta definición de código abierto no es por sí misma una licencia de software, sino más bien una especificación de qué requisitos debería cumplir una licencia de software de código abierto.

La licencia que traiga el programa tiene que cumplir las especificaciones anteriores para que el programa se considere de código abierto. La organización OSI se encarga de comprobar que las licencias cumplen las especificaciones. En la página web de Open Source Licenses se puede encontrar la lista de las licencias [OSIa], siendo una de las más famosas y utilizadas, la GPL (GNU

Public License). (Open Source Licences: http://www.opensource.org/ licenses/index.html).Bajo GPL, el software puede ser copiado y modificado, pero las modificaciones deben hacerse públicas bajo la misma licencia, y se impide que el código se mezcle con código propietario, para evitar así que el código propietario se haga con partes abiertas. Hay una licencia LGPL que es prácticamente igual, pero permite que software con esta licencia sea integrado en software propietario. Un ejemplo clásico es la biblioteca (library) C de Linux (con licencia LGPL); si ésta fuera GPL, sólo podría desarrollarse software libre, con la LGPL se permite usar para desarrollar software propietario.

Muchos proyectos de software libre, o con parte de código abierto y parte propietario, tienen su propia licencia: Apache (basada en BSD), Mozilla (MPL y NPL de Netscape), etc. Básicamente, a la hora de poner el software como open source podemos poner nuestra propia licencia que cumpla la definición anterior (de código abierto), o podemos escoger licenciar bajo una licencia ya establecida, o como en el caso de la GPL, nos obliga a que nuestra licencia también sea GPL.

Una vez vistos los conceptos de código abierto y sus licencias, nos queda por tratar hasta qué punto es rentable para una empresa trabajar o producir código abierto. Si no fuera atrayente para las empresas, perderíamos a la vez tanto un potencial cliente como uno de los principales productores de software.

El código abierto es también atrayente para las empresas, con un modelo de negocio donde se prima el valor añadido al producto. En el código abierto existen diferentes rentabilidades atrayentes de cara a las empresas:

a) Para las empresas desarrolladoras de software, se crea un problema, ¿cómo es posible ganar dinero sin vender un producto? Hay mucho dinero gastado en desarrollar un programa y después es necesario obtener beneficios. Bien, la respuesta no es simple, no se puede conseguir con cualquier software, la rentabilidad se encuentra en el tipo de software que puede generar beneficios más allá de la simple venta. Normalmente, hay que hacer un estudio de si la aplicación se tornará rentable al desarrollarla como software abierto (la mayoría sí que lo hará), basándose en las premisas de que tendremos un descenso de gasto en desarrollo (la comunidad nos ayudará), reducción de mantenimiento o corrección de errores (la comunidad puede ofrecer esto muy rápido), y tener en cuenta el aumento de número de usuarios que nos proporcionará el código abierto, así como las necesidades que tendrán de nuestros servicios de apoyo o documentación. Si la balanza es positiva, entonces será viable prescindir de los ingresos generados por las ventas.

b) Aumentar la cuota de usuarios. c) Obtener mayor flexibilidad de desarrollo, cuantas más personas intervienen, más gente habrá para detectar errores.

d) Los ingresos en su mayor parte vendrán por el lado del apoyo, formación de usuarios y mantenimiento.

e) En empresas que utilizan software, hay que considerar muchos parámetros a la hora de escoger el software para el desarrollo de las tareas, hay que tener en cuenta cosas como: rendimiento, fiabilidad, seguridad, escalabilidad y coste monetario. Y aunque parece que el código abierto ya supone de por sí una elección por el coste económico, hay que decir que existe software abierto que puede competir con el propietario (o incluso superarlo) en cualquiera de los otros parámetros. Además, hay que vigilar mucho con las opciones o sistemas propietarios de un único fabricante, no podemos depender únicamente de ellos (podemos recordar casos, en otros ámbitos, como los vídeos beta de Sony frente a VHS, o en los PC la arquitectura MicroChannel de IBM). Tenemos que evitar el uso de monopolios con lo que éstos suponen: falta de competencia en los precios, servicios caros, mantenimiento caro, poca (o nula) variedad de opciones, etc.

f) Para los usuarios particulares ofrece gran variedad de software adaptado a tareas comunes, ya que mucho del software ha sido pensado e implementado por personas que querían hacer esas mismas tareas pero no encontraban el software adecuado. Normalmente, en el caso del usuario particular un parámetro muy importante es el coste del software, pero la paradoja es que en el usuario doméstico es donde se hace más uso de software propietario. Normalmente, los usuarios domésticos hacen uso de productos de software con copias ilegales, algunas estadísticas recientes indican índices del 60-70% de copias ilegales domésticas. El usuario siente que sólo por tener el ordenador doméstico PC ya tiene derecho a disponer de software para usarlo. En estos casos estamos bajo situaciones ilegales que, aunque no han sido perseguidas, pueden serlo en su día, o bien se intentan controlar por sistemas de licencias (o activaciones de productos). Además, esto tiene unos efectos perjudiciales indirectos sobre el software libre, debido a que si los usuarios hacen un uso amplio de software propietario, esto obliga a quien se quiera comunicar con ellos, ya sean bancos, empresas o administraciones públicas, a hacer uso del mismo software propietario, y ellos sí que abonan las licencias a los productos. Una de las batallas más importantes para el software libre es la posibilidad de captar a los usuarios domésticos.

g) Por último, los estados, como caso particular, pueden obtener beneficios importantes del software de código abierto, ya que pueden disponer de software de calidad a precios ridículos comparados con el enorme gasto de licencias de software propietario (miles o decenas de miles). Además de que el software de código abierto permite integrar fácilmente a las aplicaciones cuestiones culturales (de cada país) como, por ejemplo, su lengua. Este último caso es bastante problemático, ya que en determinadas regiones, estados pequeños con lengua propia, los fabricantes de software propietario se niegan a adaptar sus aplicaciones, o instan a que se les pague por hacerlo. Contrato social de DebianContrato social de DebianLa versión 1.1 ratificada el 26 de abril de 2004 deroga la versión 1.0 ratificada el 5 de julio de 1997.El proyecto Debian, creador del sistema Debian, ha creado el contrato social de Debian. Este documento es una declaración de intenciones por nuestra parte y un conjunto de principios que acatamos. La parte del contrato llamada directrices de software libre de Debian (Debian Free Software Guidelines, DFSG)— diseñada inicialmente como un conjunto de criterios para definir lo que es software libre—, ha sido adoptada posteriormente por la comunidad de software libre como base para la definición de Open Source.

Contrato social con la comunidad de software libre1. Debian permanecerá 100% libre

Las directrices de software libre de Debian (DFSG) son el criterio que nosotros utilizamos para determinar si el software es libre o no. Prometemos mantener el sistema así como todos sus componentes completamente libres de acuerdo con este criterio. No obstante, daremos soporte también a aquellos usuarios que desarrollen y ejecuten software no libre en Debian pero nunca haremos que el sistema tenga que utilizar obligatoriamente un componente que no sea libre.

2. Contribuiremos a la comunidad de software libre Cuando escribamos nuevos componentes del sistema Debian, los licenciaremos de forma consistente con nuestra definición de software libre. Haremos el mejor sistema que podamos, de forma que el software libre tenga amplia difusión y uso. Enviaremos parches, mejoras, peticiones de los usuarios, etc. a los autores originales (esto se conoce en inglés como upstream, N. del T.) del software incluido en nuestro sistema.

3. No ocultaremos los problemas Mantendremos nuestra base de datos de informes de error accesible al público en todo momento. Los informes de error que los usuarios envíen serán visibles por el resto de usuarios de forma inmediata.

4. Nuestra prioridad son nuestros usuarios y el software libre

Nos guiaremos por las necesidades de nuestros usuarios y de la comunidad del software libre. Sus intereses serán una prioridad para nosotros. Daremos soporte a las necesidades de nuestros usuarios para que puedan trabajar en muchos tipos distintos de entornos de trabajo. No pondremos objeciones al software no libre que vaya a ejecutarse sobre Debian ni cobraremos a las personas que quieran desarrollar o usar ese tipo de software (no libre). Permitiremos a otros crear distribuciones de valor añadido basadas en Debian sin cobrarles nada por ello. Es más, entregaremos un sistema integrado de alta calidad sin restricciones legales que pudieran prevenir este tipo de uso.

5. Trabajos que no siguen nuestros estándares de software libre Reconocemos que algunos de nuestros usuarios necesitan usar trabajos que no sigan las directrices de software libre de Debian (DFSG). Por ello, hemos creado las secciones contrib y «non-free» en nuestro archivo para estos trabajos. Los paquetes en estas secciones no son parte del sistema Debian, aunque han sido configurados para usarse con Debian. Animamos a los distribuidores de CDs a que lean las licencias de los paquetes en estas secciones para poder determinar si pueden distribuir este software en sus CDs. Así pues, aunque los trabajos que no sean libres no son parte de Debian, damos soporte para su uso, y proporcionamos infraestructura (como nuestro sistema de informe de errores y listas de distribución) para paquetes no libres.

Las directrices de software libre de Debian (DFSG)1. Libre redistribución

La licencia de un componente de Debian no puede restringir a un tercero el vender o entregar el programa como parte de una distribución mayor que contiene programas de diferentes fuentes. La licencia no debe solicitar «royalties» u otras comisiones para su venta.

2. Código fuente El programa debe incluir el código fuente completo, y debe permitir la distribución en forma de código fuente y en forma compilada (binario).

3. Trabajos derivados La licencia debe permitir modificaciones y trabajos derivados y debe permitir que estos se distribuyan bajo los mismos términos que la licencia del programa original.

4. Integridad del código fuente del autor La licencia puede restringir la distribución del código fuente en forma modificada sólo si la licencia permite la distribución de parches (patch files) para poder modificar el código fuente original del programa en el momento de compilarlo. La licencia debe permitir explícitamente la distribución de software a partir de código fuente modificado. La licencia puede obligar a los trabajos derivados a llevar un nombre o número de versión diferentes del programa original Esto es un compromiso. El grupo de Debian anima a todos los autores a no restringir ningún fichero, fuente o compilado, de ser modificado.

5. No discriminación contra personas o grupos La licencia no debe discriminar a ninguna persona o grupo de personas.

6. No discriminación en función de la finalidad perseguida La licencia no puede restringir el uso del programa para una finalidad determinada. Por ejemplo, no puede restringir el uso del programa a empresas con fines comerciales, o en investigación genética.

7. Distribución de la licencia Los derechos y libertades de uso asociados al programa deben aplicarse en la misma forma a todos aquellos a los que se redistribuya el programa, sin necesidad de pedir una licencia adicional para estas terceras partes.

8. La licencia no ha de ser específica para Debian Los derechos asociados al programa no deben depender de que el programa sea parte o no del sistema Debian. Si el programa es extraído de Debian y usado o distribuido sin Debian, pero manteniendo el resto de las condiciones de la licencia, todos aquellos a los que el programa se redistribuya deben tener los mismos derechos que los dados cuando forma parte de Debian.

9. La licencia no debe contaminar a otros programas La licencia no debe poner restricciones sobre otros programas que se distribuyan junto con el programa licenciado. Por ejemplo, la licencia no puede insistir que todos los demás programas distribuidos sobre el mismo medio deben ser software libre.

10. Ejemplos de licencias Las licencias GPL, BSD, y Artística son ejemplos de licencias que nosotros consideramos libres.La expresión contrato social con la comunidad de software libre fue sugerida por Ean Schuessler. El primer borrador de este documento fue escrito por Bruce Perens, fue modificado por los demás desarrolladores de Debian durante una conferencia por correo electrónico que duró un mes (junio de 1997) y finalmente aceptado como la normativa pública del proyecto Debian.Posteriormente, Bruce Perens eliminó las referencias específicas a Debian en las directrices de Debian para el Software Libre (DFSG), creando la definición de Open Source.

Cualquier otra organización puede llevar a cabo trabajos derivados a partir de este documento. Por favor, haga referencia al proyecto Debian en tal caso. Fuente: http://www.debian.org/social_contract.es.html