Historia y evolución del software de codigo abierto

Qué es el software de código abierto y cuál es su origen

La historia del software de código abierto es, en su mayor parte, la historia de sus licencias, ya que una licencia es lo único que determina qué puede hacer usted con el código que escribió otra persona. El código se compartía abiertamente mucho antes de que alguien pusiera esas licencias por escrito. Dejó de compartirse una vez que se convirtió en un producto, y las licencias se redactaron para que el intercambio tuviera validez ante un tribunal.

Esa es la versión corta. La versión larga es importante porque el software que usted ejecuta hoy en un servidor todavía lleva las marcas de aquellas decisiones. Algunas de esas decisiones se tomaron en 1983. Otras se tomaron el año pasado, y son la razón por la que algunas de las aplicaciones en nuestras guías de autoalojamiento ahora vienen en dos versiones con nombres diferentes.

El software se compartía antes de venderse

En las décadas de 1950 y 1960, el software se entregaba junto con la máquina. IBM distribuía el código fuente con sus sistemas y los grupos de usuarios, como SHARE, fundado en 1955, intercambiaban programas mediante cintas. Dos factores pusieron fin a esto. En 1969, IBM anunció que empezaría a cobrar el software por separado del hardware, lo que creó un mercado independiente para el software. Posteriormente, la legislación se adaptó. La Computer Software Copyright Act de 1980 confirmó que los programas son obras protegidas por derechos de autor en Estados Unidos. Después de 1980, el código que uno no escribía pasó a ser cerrado por defecto, por lo que compartirlo requería el permiso por escrito del autor.

El Homebrew Computer Club y la Carta abierta a los aficionados

El Homebrew Computer Club celebró su primera reunión en marzo de 1975, en un garaje de Menlo Park, California. Los miembros llevaban hardware y cinta perforada, y copiar era parte de la reunión. Altair BASIC, escrito por Bill Gates y Paul Allen, circuló por la sala en cintas copiadas. En febrero de 1976, Gates respondió en el boletín del club con una "Carta abierta a los aficionados".

Como la mayoría de los aficionados debe saber, la mayoría de ustedes roba su software.

Escribió que menos de uno de cada diez propietarios de Altair había pagado por BASIC, y que el tiempo de computadora utilizado para escribirlo valía más de 40,000 dólares. Todo el argumento moderno ya está en esa carta. Copiar software no cuesta nada y ayuda a todos los que lo copian. Escribirlo, sin embargo, le costó a alguien un año de su vida. Cada licencia descrita a continuación es un intento de responder a ambos hechos simultáneamente.

GNU en 1983 y la GPL como invención legal

Richard Stallman anunció GNU en septiembre de 1983 en Usenet, la red de grupos de noticias que la gente utilizaba antes de la web. GNU significa "GNU's Not Unix". El plan consistía en un sistema completo compatible con Unix que cualquiera pudiera copiar y modificar.

¡Unix libre! A partir de este Día de Acción de Gracias voy a escribir un sistema de software completo compatible con Unix llamado GNU (por Gnu's Not Unix), y lo entregaré gratis a todo aquel que pueda utilizarlo.

La Free Software Foundation (FSF) surgió en 1985. Su Definición de Software Libre enumera cuatro libertades, numeradas desde cero: ejecutar el programa para cualquier propósito, estudiar y modificarlo, redistribuir copias y distribuir sus versiones modificadas. La libertad 1 requiere el código fuente, porque nadie puede estudiar un binario de forma práctica. "Libre" aquí significa libertad y no precio. La frase propia de la FSF es "libre como en libertad de expresión, no como en cerveza gratis".

El manifiesto no fue la invención. La licencia sí lo fue. La GNU General Public License (GPL) utiliza los derechos de autor para exigir el intercambio en lugar de impedirlo. Usted recibe las cuatro libertades con una condición: cualquiera a quien usted pase el software también las recibe, junto con el código fuente. Stallman llamó a esto copyleft. Se lanzó por primera vez con GNU Emacs en 1985, se convirtió en la GPL versión 1 en 1989 y en la versión 2 en junio de 1991.

La GPL funciona porque se apoya en la ley de derechos de autor, no en contra de ella. Sin una licencia, usted no tiene derecho alguno a distribuir el código de otra persona. La GPL otorga ese derecho y le añade condiciones. Por lo tanto, un proveedor que distribuye código GPL modificado dentro de un router y se niega a entregar el código fuente no está rompiendo una promesa. Está infringiendo los derechos de autor, lo cual un titular de derechos puede llevar a los tribunales. Es por eso que la aplicación de la ley es posible, desde los casos de gpl-violations.org de Harald Welte en la década de 2000 hasta la demanda de la Software Freedom Conservancy contra Vizio, presentada en 2021, la cual argumenta que una persona que compró el televisor también puede exigir el código fuente.

Linux completa el sistema

Para 1991, el proyecto GNU ya contaba con el compilador, la biblioteca de C, el shell y la mayoría de las herramientas. No tenía un kernel funcional, ya que el kernel propio de GNU, Hurd, tardó mucho más de lo previsto. En agosto de 1991, un estudiante en Helsinki publicó en el grupo de noticias comp.os.minix:

Estoy haciendo un sistema operativo (gratuito) (solo un hobby, no será grande ni profesional como gnu) para clones AT 386(486).

Linux 0.01 llegó en septiembre de 1991 bajo una licencia que el propio Linus Torvalds escribió, la cual prohibía su venta. A principios de 1992, la reemplazó por la GPLv2 y, desde entonces, ha afirmado que fue una de sus mejores decisiones. La licencia es lo que hizo segura la contribución corporativa: una empresa podía asignar ingenieros al kernel sabiendo que un competidor no podría privatizar esas mejoras.

Ya existía un Unix libre en Berkeley. La razón por la que Linux, y no BSD (Berkeley Software Distribution), se convirtió en el Unix libre predeterminado se debe en parte a una demanda. Unix System Laboratories demandó a Berkeley Software Design en 1992, y el caso se prolongó hasta principios de 1994. Durante esos dos años, los sistemas BSD conllevaron un riesgo legal mientras que Linux no, y fue entonces cuando llegaron los usuarios. La FSF pide a las personas que llamen al sistema combinado GNU/Linux, ya que Linux es el kernel y la mayoría de las herramientas que lo rodean son GNU. La mayoría de la gente dice Linux. Ambos nombres señalan la misma colección de software.

1998: el cambio de marca del código abierto y la división que nunca sanó

En enero de 1998, Netscape anunció que publicaría el código fuente de su navegador. Fue la empresa más grande hasta la fecha en realizar tal acción, lo cual expuso un problema práctico. La frase "free software" se interpreta en inglés como "software que no cuesta nada", y los ejecutivos entendieron exactamente eso. Un grupo se reunió en Palo Alto en febrero de 1998 para encontrar un término mejor, y Christine Peterson propuso "open source". En pocas semanas, Eric Raymond y Bruce Perens fundaron la Open Source Initiative (OSI). Esta adoptó la Open Source Definition, adaptada de las Debian Free Software Guidelines que Perens había escrito en 1997.

La Open Source Definition tiene diez criterios. Dos de ellos resuelven la mayoría de las discusiones modernas: el código fuente debe estar disponible y la licencia no debe restringir quién puede usar el programa ni para qué puede utilizarlo. Una licencia que indique "no puede ofrecer esto como un servicio comercial" no supera la prueba, independientemente de lo que permita en otros aspectos. Tenga presente esta frase. Es la línea que cruzan las licencias de código disponible (source-available) actuales.

La división que surgió en 1998 trata sobre los motivos, no sobre qué licencias son aceptables. El argumento de la FSF es ético: un usuario que no puede modificar el programa no controla su propio equipo. El argumento de la OSI, expuesto a las empresas mediante el ensayo de Raymond "The Cathedral and the Bazaar", es práctico: el desarrollo abierto produce mejor software y una empresa puede beneficiarse de ello. La respuesta de Stallman, "Why Open Source Misses the Point of Free Software", sigue publicada en gnu.org, y él nunca ha aceptado el término más reciente. Perens, quien ayudó a crearlo, renunció a la junta de la OSI en 1999 argumentando que el movimiento se había alejado del software libre.

Vale la pena ser preciso sobre lo pequeña que es la brecha práctica. La lista de licencias libres de la FSF y la lista de licencias aprobadas por la OSI coinciden en casi todo, incluyendo GPL, MIT, Apache 2.0 y BSD. Los autores que necesitan ambos significados a la vez utilizan FOSS (free and open source software) o FLOSS (free/libre and open source software).

Cómo aprendieron las empresas a distribuir código

La salida a bolsa de Red Hat en 1999 demostró que el dinero estaba en el soporte y el empaquetado, no en la venta de copias. IBM comprometió mil millones de dólares para Linux en 2001. El director ejecutivo de Microsoft calificó a Linux de "cáncer" en 2001, y la misma empresa se unió a la Linux Foundation como miembro platino en 2016, para luego comprar GitHub en 2018 por 7.5 mil millones de dólares en acciones. IBM compró Red Hat en 2019 por 34 mil millones de dólares. Nada de esto supuso un cambio de opinión sobre las licencias. Fue un cambio en dónde reside el dinero. Cuando un sistema operativo es un coste compartido, pagar por mantener el propio resulta caro, y cualquier proveedor prefiere competir en la capa superior.

La propiedad corporativa también tiene su contrapartida. Cuando Oracle compró Sun en 2010, heredó MySQL y OpenOffice.org, y ambas comunidades se marcharon. MariaDB surgió de MySQL, y LibreOffice fue bifurcado (forked) de OpenOffice.org en septiembre de 2010. Una bifurcación es el único voto que una comunidad de usuarios posee realmente, y la licencia es lo que hace posible ese voto.

Por qué algunas de las aplicaciones que aloja usted mismo tienen forks

A partir de 2018, un grupo de empresas cambió los términos del software que ya habían publicado. La situación fue la misma en cada caso. Una empresa empleaba a casi todos los desarrolladores, un proveedor de nube mucho más grande vendía el mismo software como un servicio gestionado y la empresa más pequeña decidió que la licencia era la razón por la que no podía competir.

• MongoDB adoptó la Server Side Public License (SSPL) en octubre de 2018. La SSPL establece que si usted ofrece el software a otros como un servicio, debe publicar el código fuente de todo lo que utilice para proporcionar dicho servicio. La OSI no la aceptó como código abierto y MongoDB retiró la solicitud de revisión en 2019.
• Redis añadió restricciones de uso a algunos módulos en 2018 y 2019, y luego trasladó el servidor principal a términos duales de fuente disponible con la versión 7.4 en marzo de 2024. Días después apareció un fork de la última versión bajo licencia BSD llamado Valkey, bajo el amparo de la Linux Foundation y respaldado por Amazon, Google y Oracle, entre otros. En mayo de 2025, Redis añadió la Affero General Public License version 3 (AGPLv3), la cual está aprobada por la OSI, como una tercera opción para Redis 8.
• Elastic cambió Elasticsearch y Kibana de la licencia Apache 2.0 en enero de 2021 a términos duales de SSPL y Elastic License. Amazon creó el fork OpenSearch. Elastic añadió la AGPLv3 como tercera opción en agosto de 2024, y OpenSearch fue transferido a la Linux Foundation en septiembre de 2024 como la OpenSearch Software Foundation.
• HashiCorp trasladó Terraform y sus otras herramientas a la Business Source License (BUSL) en agosto de 2023. La BUSL no es una licencia de código abierto mientras está en vigor, ya que prohíbe el uso comercial competitivo. Cada versión se convierte a una licencia abierta en una fecha fija, cuatro años después en el caso de Terraform. OpenTofu fue creado como fork pocas semanas después y ahora también se encuentra bajo la Linux Foundation.

Ambas partes tienen argumentos válidos y ninguna actúa de mala fe. Una empresa que paga cincuenta salarios mientras una firma mucho más grande revende su trabajo tiene un problema que la buena voluntad no resuelve. Un usuario que construyó sobre los términos de Apache 2.0 y despertó bajo nuevos términos también tiene un problema, y nadie le consultó primero. Observe lo que ocurrió después en dos de esos casos. Tras consolidarse los forks, tanto Elastic como Redis volvieron a añadir copyleft fuerte. El copyleft respondió a la queja original, ya que la AGPLv3 exige que el proveedor de servicios publique los cambios que ejecuta. A fecha de agosto de 2026, ambos proyectos y ambos forks siguen activos, que es el resultado que las licencias fueron diseñadas para permitir.

Quién tiene permiso para cambiar una licencia

Un proyecto solo puede cambiar de licencia si una parte controla los derechos de autor de la totalidad del mismo. Las empresas obtienen ese control de dos formas. La cesión de derechos de autor transfiere la propiedad de cada contribución a la empresa. Un acuerdo de licencia de colaborador (CLA, por sus siglas en inglés) le mantiene a usted como propietario, pero otorga a la empresa derechos lo suficientemente amplios como para cambiar la licencia de su trabajo. Cualquiera de los dos se suele firmar haciendo clic en un enlace que un bot publica en su primera solicitud de extracción (pull request).

Linux no tiene CLA. Las contribuciones llegan bajo la licencia GPLv2 con un Certificado de Origen del Desarrollador, y los derechos de autor están repartidos entre miles de personas y empresas. Nadie puede cambiar la licencia de Linux, porque nadie podría reunir todas esas firmas. La misma protección se aplica a cualquier proyecto con muchos titulares de derechos de autor independientes, y es una protección más sólida que una promesa, ya que es un hecho sobre quién posee qué.

Por lo tanto, la pregunta que debe hacerse sobre el software del que planea depender no es si es de código abierto hoy. Es quién podría cambiar eso y si podría hacerlo por sí solo.

Lo que una fundación le aporta realmente

Una fundación mantiene los activos y establece las reglas para la toma de decisiones. La Apache Software Foundation, la Linux Foundation, la Cloud Native Computing Foundation que alberga y la Software Freedom Conservancy realizan cada una una versión de esa labor. Una fundación no es neutral por arte de magia. Los miembros pagan por sus puestos y la mayoría de las personas que trabajan a tiempo completo en un proyecto grande de una fundación reciben su salario de empresas miembro. Lo que usted obtiene es más limitado, pero sigue teniendo mucho valor: la marca comercial y el proceso de lanzamiento no pertenecen a un solo proveedor, por lo que ninguna empresa puede privatizar el proyecto.

La marca comercial es el aspecto que la gente pasa por alto. El código tiene una licencia. Un nombre es una marca comercial y una marca comercial no está cubierta por la licencia del código. Siempre puede realizar un fork del código. Por lo general, no puede conservar el nombre. Es por eso que los forks en esta historia se llaman Valkey, OpenSearch, OpenTofu y Forgejo.

El problema del mantenedor

La infraestructura moderna depende de proyectos con uno o dos mantenedores no remunerados, y los fallos son lo que hace visible esta situación. El error Heartbleed en OpenSSL en 2014 afectó a una biblioteca que transportaba una gran parte del tráfico cifrado de la web, mantenida por un puñado de personas con casi nulos recursos económicos. Log4Shell en diciembre de 2021 canalizó la respuesta ante incidentes de todo el mundo a través de un pequeño equipo de voluntarios en el proyecto Apache Log4j.

La puerta trasera en XZ Utils descubierta en marzo de 2024 es el ejemplo más claro, porque el ataque se dirigió al mantenedor en lugar de al código. Una cuenta pasó aproximadamente dos años realizando contribuciones genuinamente útiles a una biblioteca de compresión utilizada en todas las distribuciones de Linux. Otras cuentas presionaron al agotado mantenedor único para que aceptara ayuda. El nuevo co-mantenedor introdujo entonces una puerta trasera en los archivos de lanzamiento, dirigida a sistemas donde el daemon SSH (secure shell) se vincula contra liblzma. Un desarrollador la encontró mientras investigaba por qué los inicios de sesión tardaban aproximadamente medio segundo más de lo esperado. Eso fue suerte, y todos los involucrados lo han declarado públicamente.

El dinero ha comenzado a llegar: GitHub Sponsors desde 2019, Open Collective, el Sovereign Tech Fund de Alemania desde 2022 y el proyecto Alpha-Omega de la OpenSSF. Llega de forma desigual y tiende a encontrar los proyectos que ya son famosos. La regulación también está llegando. La Ley de Ciberresiliencia de la Unión Europea entró en vigor en diciembre de 2024, y la mayoría de sus obligaciones se aplicarán a partir de diciembre de 2027. Los borradores iniciales habrían impuesto responsabilidad de fabricante a los voluntarios no remunerados, por lo que el texto final crea una categoría más ligera llamada "administrador de software de código abierto" tras un largo cabildeo por parte de fundaciones y distribuciones.

Lo que la historia del software libre significa para el software en su VPS

Cada aplicación en nuestras guías de alojamiento propio depende de estas decisiones. Nextcloud existe gracias a una bifurcación: en 2016, el fundador de ownCloud y gran parte del equipo abandonaron el proyecto y lo reiniciaron bajo la licencia AGPLv3; desde entonces, ambos productos han evolucionado en paralelo. Esa historia es el contexto de las alternativas a Nextcloud que vale la pena considerar y de las alternativas a Dropbox para alojamiento propio que compiten con ambos.

El mismo patrón se observa en el alojamiento de Git. Gitea comenzó en 2016 como una bifurcación de Gogs. A finales de 2022, la marca comercial y los dominios del proyecto pasaron a manos de una empresa, Codeberg bifurcó Forgejo en diciembre de ese mismo año y Forgejo cambió de la licencia MIT a la GPLv3 con la versión 9 en 2024. Ambos se tratan en las opciones de servidores Git para alojamiento propio, y la diferencia de licencias es una razón importante por la que siguen divergiendo. Mientras tanto, la mayor parte del software libre se desarrolla en GitHub, una plataforma cerrada propiedad de Microsoft, lo cual es un viejo debate con puntos válidos en ambos lados: vea qué es realmente GitHub.

Antes de comprometer un servidor con un proyecto, vale la pena dedicar diez minutos a realizar cuatro comprobaciones.

• Lea el archivo LICENSE en el repositorio, no la página de marketing. Las páginas siguen diciendo "código abierto" mucho después de que el archivo haya dejado de respaldarlo.
• Busque un CLA o una cesión de derechos de autor. Si existe, un único propietario puede cambiar los términos de futuras versiones.
• Averigüe quién posee los derechos de autor: una empresa, muchos colaboradores o una fundación.
• Cuente los mantenedores activos. Un proyecto con uno solo es un riesgo tanto para esa persona como para usted.

Nada de esto sugiere evitar el software de un solo proveedor. Gran parte es excelente, y el hecho de que sea remunerado suele ser la razón por la que se mantiene. Esto le indica a qué está expuesto. Cuando decida qué merece la pena alojar uno mismo, incluya la licencia en la comparación junto a los requisitos de memoria.

Puede leer parte de esta historia en la máquina que tiene delante. Cada paquete en un sistema Debian o Ubuntu incluye sus propios términos:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

El primer número indica cuántos paquetes instalados contienen un archivo de derechos de autor, generalmente unos pocos cientos en un VPS pequeño. El segundo comando imprime el inicio del archivo correspondiente a bash, que menciona la GNU General Public License versión 3. Un archivo ausente significa que el paquete no se compiló siguiendo la política de Debian, lo cual es poco común y merece una revisión adicional antes de confiar en él.

FAQ

¿Cuál es la diferencia entre software libre y código abierto?

Cubren casi el mismo conjunto de licencias y discrepan sobre por qué esas licencias son importantes. "Software libre" es el término más antiguo, acuñado por la Free Software Foundation en 1985, y su argumento es ético: un usuario que no puede modificar el programa no controla su computadora. "Código abierto" se acuñó en febrero de 1998 para facilitar la explicación de las mismas licencias a las empresas, y su argumento es práctico. Las licencias GPL, MIT, BSD y Apache 2.0 están en ambas listas oficiales. Los autores que desean referirse a ambos conceptos a la vez utilizan FOSS o FLOSS.

¿Es el software con código disponible lo mismo que el código abierto?

No. Código disponible (source-available) significa que puede leer el código. El código abierto, según la Open Source Definition, también implica que la licencia no puede restringir quién utiliza el software ni para qué fines. Tanto la SSPL como la Business Source License restringen el uso comercial competitivo, por lo que ninguna es código abierto bajo esa definición, aunque ambas publiquen su código fuente. Si solo realiza autohospedaje para uso personal, es posible que la restricción nunca le afecte. Si desea crear un producto basado en dicho software, lea primero el texto de la licencia con atención.

¿Puede una empresa retirar una licencia de código abierto que ya ha concedido?

No para el código que ya ha publicado. Esa versión permanece bajo la licencia con la que se distribuyó, que es precisamente la razón por la que forks como Valkey y OpenTofu pudieron comenzar desde el último commit con licencia permisiva. Lo que una empresa puede hacer es publicar versiones futuras bajo nuevos términos, y solo puede hacerlo si controla los derechos de autor de todo el proyecto mediante una cesión o un acuerdo de licencia de colaborador (CLA). Los proyectos con muchos titulares de derechos de autor independientes, incluido Linux, no pueden ser relicenciados por nadie.

¿Qué licencia debo buscar en el software autohospedado?

Para el software que usted ejecuta por su cuenta y no revende, cualquier licencia aprobada por la OSI, como GPL, AGPL, MIT o Apache 2.0, le proporciona todo lo que necesita. Una comprobación más útil es quién posee los derechos de autor, ya que eso determina si los términos pueden cambiar en el futuro. Un proyecto gestionado por una fundación o por muchos colaboradores independientes no puede ser relicenciado en contra de sus usuarios. Un proyecto de un solo proveedor con un acuerdo de licencia de colaborador sí puede serlo. Ambos pueden ser buen software. Solo uno de ellos puede cambiar las reglas por su cuenta.