Richard Stallman y el Software Libre: Ideas que cambiaron el código

Por qué Richard Stallman sigue importando

El software no es solo un producto técnico: también es un conjunto de permisos. ¿Quién puede ejecutarlo, copiarlo, compartirlo con un amigo, arreglar un fallo o construir algo nuevo encima? Esas preguntas se responden menos con código y más con licencias. A medida que el software se volvió central para el trabajo, la comunicación y la investigación, las reglas sobre “qué se te permite hacer” empezaron a moldear la innovación tanto como las funcionalidades.

Richard Stallman (a menudo llamado “RMS”) importa porque hizo que esas reglas fueran imposibles de ignorar. A principios de los años 80 vio un cambio: más programas se distribuían sin código fuente y a los usuarios cada vez se les decía que podían usar software solo en los términos de otra persona. Stallman enmarcó esto no como una molestia menor, sino como una pérdida de libertad para usuarios y desarrolladores, y respondió proponiendo un conjunto claro de principios y herramientas legales para proteger esas libertades.

Qué es (y qué no es) este artículo

Este artículo se centra en las ideas de Stallman y sus consecuencias prácticas: la definición de software libre, el Proyecto GNU, el copyleft y la Licencia Pública General GNU (GPL), y cómo esto modeló el ecosistema moderno de código abierto y las normas de licenciamiento.

No es una biografía ni una guía técnica profunda sobre compilar kernels o gestionar repositorios. No necesitas experiencia en programación para seguirlo.

Una visión equilibrada y accesible

Stallman es influyente y también controvertido. El objetivo aquí es mantener los hechos y la legibilidad: qué defendió, qué mecanismos legales surgieron, cómo adaptaron las empresas y los desarrolladores, y dónde continúan los debates hoy—para que veas por qué su trabajo todavía afecta las decisiones cotidianas sobre software.

Qué significa realmente “software libre”

“Software libre” es fácil de malinterpretar porque la palabra libre suena a precio. Richard Stallman usó libre para referirse a la libertad: la capacidad del usuario para controlar el software del que depende.

Si un programa cuesta $0 pero no puedes inspeccionarlo, cambiarlo o compartirlo, puede ser “gratis como una cerveza” y al mismo tiempo no libre en el sentido que a Stallman le importaba.

Las cuatro libertades esenciales

El software libre se define por cuatro permisos básicos:

• Libertad 0: Ejecutar el programa para cualquier propósito.
• Libertad 1: Estudiar cómo funciona el programa y cambiarlo para que haga lo que quieras.
• Libertad 2: Redistribuir copias para ayudar a otros.
• Libertad 3: Distribuir tus versiones modificadas para que la comunidad se beneficie.

Estas libertades van de la mano con la agencia: no eres solo consumidor de herramientas: puedes convertirte en participante que verifica, adapta y mejora.

Por qué el acceso al código fuente es innegociable

Las libertades 1 y 3 son imposibles sin acceso al código fuente: las instrucciones legibles por humanos. Sin él, el software es más como un electrodoméstico sellado: puedes usarlo, pero no sabes qué hace, no puedes arreglarlo cuando falla ni adaptarlo a nuevas necesidades.

El acceso al código fuente también importa para la confianza. Permite revisiones independientes (para privacidad, seguridad y equidad) y hace viable mantener el software aunque el desarrollador original deje de darle soporte.

Una analogía simple: recetas vs comida sellada

Piensa en una comida de restaurante.

• El software propietario es como comprar un plato listo y sellado: puedes comerlo, pero no sabes los ingredientes, no puedes ajustar la receta y no te permiten compartir copias.
• El software libre es como recibir la receta: puedes cocinarla en casa, aprender cómo se hace, ajustarla por alergias y compartir tu versión mejorada con amigos.

Esa es la idea central: el software libre trata de las libertades que los usuarios necesitan para mantener el control de su computación.

El problema al que reaccionó Stallman

Antes de que la “licencia de software” fuera tema de debate general, mucha cultura de programación—especialmente en universidades y laboratorios de investigación—se regía por una suposición: si podías mejorar una herramienta, compartías la mejora. El código fuente viajaba con el software, la gente aprendía leyendo el trabajo de otros y las correcciones se difundían mediante colaboración informal.

De normas de compartir a software bloqueado

Esa cultura empezó a cambiar cuando el software se convirtió en un producto por derecho propio. Empresas (e incluso algunas instituciones) comenzaron a considerar el código fuente como una ventaja competitiva. La distribución vino con términos de “no compartir”, el código dejó de acompañar a los programas y los acuerdos de confidencialidad se volvieron habituales. Para desarrolladores acostumbrados a resolver problemas colectivamente, este cambio no fue solo inconveniente: pareció un cambio de reglas que hacía que la resolución comunitaria de problemas fuera legalmente arriesgada.

La historia de la impresora (ejemplo, no mito)

Una de las historias de origen más repetidas involucra una impresora en el AI Lab del MIT. Stallman describió cómo llegó una nueva impresora con software distribuido solo en forma binaria, sin código fuente. El problema práctico era mundano: el laboratorio quería modificar el programa para manejar cosas como notificar atascos o enrutar trabajos de manera más inteligente. Bajo las antiguas normas “hacker”, alguien parchearía el código y compartiría la corrección. Aquí no pudieron—porque no tenían permitido ver ni cambiar el código fuente.

Vale la pena ponerlo en proporción: no fue una impresora la que por sí sola creó un movimiento global. Fue un ejemplo claro y relatable de una tendencia más amplia: herramientas de las que dependía la gente se volvían inreparables por sus usuarios.

Por qué esto condujo a nuevas ideas de licenciamiento

Para Stallman, el problema central no era solo el acceso técnico; era la pérdida de la libertad de cooperar. Si no puedes estudiar cómo funciona un programa, no puedes controlarlo de verdad. Si no puedes compartir mejoras, las comunidades se fragmentan y todos acaban reinventando soluciones en privado.

Esa motivación moldeó las innovaciones de licencias que vinieron después. En lugar de confiar en la buena voluntad o normas informales, Stallman quería reglas que preservaran la capacidad de usar, estudiar, modificar y compartir software—para que la colaboración no pudiera retirarse en el momento en que un programa se volviera valioso comercialmente.

El Proyecto GNU: construir un sistema operativo libre

El gran movimiento de Stallman no fue solo escribir un manifiesto: fue iniciar un esfuerzo práctico de ingeniería. En 1983 anunció el Proyecto GNU, con una meta ambiciosa: construir un sistema operativo completo que cualquiera pudiera usar, estudiar, modificar y compartir, manteniendo compatibilidad con Unix para que la gente pudiera ejecutar programas y flujos de trabajo familiares.

Un sistema completo, no una sola herramienta

Un sistema operativo no es un solo programa: es toda una pila. GNU se propuso crear todas las piezas cotidianas necesarias para que un ordenador fuera útil, incluyendo:

• Compiladores (más famoso: GCC) para que los desarrolladores convirtieran código en programas ejecutables
• Utilidades básicas de la línea de comandos (herramientas para copiar archivos, buscar texto, gestionar procesos)
• Bibliotecas y herramientas de desarrollo para apoyar la construcción de más software
• Intérpretes de comandos y editores para trabajar en la máquina día a día

En términos simples: GNU estaba construyendo la plomería, el cableado y los interruptores—no solo un electrodoméstico.

GNU + Linux: cómo la mayoría lo encontró

A comienzos de los 90, GNU había producido gran parte de ese “userland”, pero faltaba una pieza crítica: el núcleo (kernel), la parte que gestiona hardware y recursos del sistema. Cuando Linux apareció en 1991, encajó en ese hueco.

Por eso muchos sistemas populares hoy combinan componentes GNU con el kernel Linux—a menudo denominados “GNU/Linux”.

La infraestructura importó tanto como los ideales

GNU hizo la idea del software libre real al crear una base funcional sobre la que otros pudieran construir. La filosofía explicaba por qué la libertad importaba; GNU entregó las herramientas que hicieron la libertad práctica, repetible y escalable.

Copyleft en palabras sencillas

El copyleft es una estrategia de licenciamiento diseñada para mantener el software libre (en el sentido de libertad) no solo en su primera versión, sino en las siguientes. Si recibes código con copyleft, puedes usarlo, estudiarlo, modificarlo y compartirlo—pero cuando distribuyes tu versión modificada, debes transmitir las mismas libertades a los demás.

Una herramienta legal basada en el copyright

El copyleft suena a “anti-copyright”, pero en realidad se apoya en la ley de derechos de autor. El autor usa su copyright para establecer reglas de permiso en una licencia: “Puedes copiar y modificar esto, pero si lo redistribuyes debes mantenerlo bajo esta misma licencia.” Sin copyright no habría mecanismo legal para hacer cumplir esas condiciones.

La idea de “compartir igual” (con ejemplos simples)

Piénsalo como una regla que sigue al código:

• Forks: Forkeas un proyecto con copyleft, añades funciones y publicas tu fork. Debes publicar el código fuente y mantener la misma licencia para que otros puedan también forkearte.
• Redistribuciones: Empaquetas el programa en un producto que envías a clientes. Puedes cobrar dinero, pero debes proporcionar el código fuente y los mismos derechos a los destinatarios.

El objetivo es evitar un patrón que preocupaba a Stallman: alguien toma el trabajo comunitario, lo mejora y luego encierra esas mejoras.

Copyleft vs licencias permisivas

Las licencias permisivas (como MIT o BSD) te permiten casi cualquier cosa con el código, incluyendo redistribuir versiones modificadas bajo una licencia propietaria. Las licencias con copyleft (como la GPL) permiten uso y modificación amplios, pero exigen que las derivadas redistribuidas sigan bajo los mismos términos copyleft—de modo que la libertad se preserve en la cadena.

Cómo la GPL remodeló el licenciamiento

La Licencia Pública General GNU (GPL) cambió el licenciamiento del software al convertir el “compartir” en una regla exigible, no solo en un gesto amable. Antes de la GPL, podías recibir código fuente, mejorarlo y luego distribuir una versión cerrada que los usuarios no pudieran estudiar ni modificar. La GPL invirtió esa dinámica: protege las libertades de los usuarios al adjuntar condiciones a la redistribución.

Qué da la GPL—y qué pide a cambio

A nivel práctico, la GPL concede a los usuarios el derecho a ejecutar el programa para cualquier propósito, leer y modificar el código y compartir las versiones originales o modificadas.

Si redistribuyes software GPL (especialmente como producto), debes transmitir esas mismas libertades. Eso normalmente implica:

• Proporcionar el código fuente (o una manera válida de obtenerlo) a los destinatarios
• Incluir el texto de la licencia y preservar los avisos de copyright
• Licenciar tus modificaciones bajo la GPL también, para que los usuarios downstream no queden “bloqueados”

Obligaciones de distribución (cuándo aplican)

Las obligaciones de la GPL se activan principalmente cuando distribuyes el software a otros: enviar binarios, vender dispositivos con el software o dar copias a clientes. Si modificas código GPL para uso interno y no lo distribuyes, generalmente no tienes que publicar el código.

“Obra derivada” en términos sencillos

No necesitas teoría legal para entender la idea: si tu programa incorpora código GPL de forma que crea una obra combinada (por ejemplo, enlazándolo a tu aplicación), el resultado suele considerarse derivado y debe distribuirse bajo la GPL. Simplemente ejecutar un programa GPL o comunicarte con él como proceso separado a través de interfaces estándar suele ser distinto.

Variantes de la GPL: v2, v3 y LGPL

GPLv2 es la versión clásica muy usada. GPLv3 añade protecciones sobre acuerdos de patentes y la “tivoización” (dispositivos que impiden software modificado). La LGPL está pensada para bibliotecas: permite enlazar desde programas propietarios bajo ciertas condiciones mientras la propia biblioteca sigue siendo libre.

Derechos y responsabilidades de los desarrolladores bajo licencias libres

Las licencias libres (especialmente la GNU GPL) no solo “permiten” compartir: protegen el derecho a estudiar, modificar y redistribuir software de una manera difícil de revertir. Para los desarrolladores, eso significa que tus mejoras pueden permanecer disponibles para otros bajo las mismas condiciones, en lugar de ser absorbidas por un producto cerrado sin que la comunidad se beneficie.

Qué derechos obtienes

Bajo la GPL puedes:

• Trastear con confianza: leer el código, cambiarlo y ejecutar tu versión modificada.
• Compartir tu trabajo: distribuir copias del programa original o modificado.
• Construir sobre las mejoras de otros: porque los destinatarios deben recibir las mismas libertades.

Por eso la GPL suele describirse como “reciprocidad exigible”. Si alguien distribuye un programa cubierto por la GPL (o una obra derivada), no puede añadir restricciones que impidan a los usuarios downstream hacer las mismas modificaciones y compartirlas.

Qué responsabilidades asumes

Esas libertades conllevan obligaciones cuando distribuyes software:

• Preservar avisos de copyright y de licencia.
• Proveer (u ofrecer) el código fuente correspondiente cuando la GPL lo exige.
• Mantener la licencia intacta para que los destinatarios conozcan sus derechos.

Estas responsabilidades no son trampas: son el mecanismo que evita que la colaboración se convierta en extracción unidireccional.

Nota práctica sobre cumplimiento

Los equipos deberían tratar el cumplimiento de licencias como higiene de liberación. Lleva registro de:

• qué componentes de código abierto envías,
• sus versiones y licencias,
• dónde proporcionas código fuente (u ofertas escritas),
• y cualquier modificación que hayas hecho.

Un Bill of Materials de software (SBOM) y una lista de comprobación repetible para lanzamientos pueden prevenir la mayoría de problemas antes de que intervengan abogados.

Software libre vs open source: una separación de valores

A nivel de código, “software libre” y “open source” a menudo describen muchos de los mismos proyectos. La diferencia principal es por qué compartir importa.

Prioridades distintas: libertad vs adopción

El movimiento del Software Libre (asociado con Richard Stallman y la Free Software Foundation) trata la libertad del software como una cuestión ética: los usuarios deben tener el derecho a ejecutar, estudiar, modificar y compartir software. El objetivo no es solo mejor ingeniería: es proteger la autonomía del usuario.

El enfoque Open Source enfatiza resultados prácticos: mejor colaboración, iteración más rápida, menos errores y mayor seguridad mediante transparencia. Le resulta cómodo presentar la apertura como un modelo de desarrollo superior sin exigir una postura moral.

Por qué “open source” se popularizó

En 1998 la Open Source Initiative (OSI) popularizó el término “open source” para hacerlo más amigable para negocios. “Free software” se malinterpretaba con frecuencia como “sin coste” y algunas empresas se mostraban reticentes a un mensaje centrado en derechos y ética. “Open source” dio a las organizaciones una forma de decir “podemos trabajar así” sin sonar ideológicas.

Mismas licencias, distinto encuadre

Muchos proyectos que se llaman open source usan la GPL u otras licencias copyleft, mientras que otros eligen licencias permisivas como MIT o Apache. El texto legal puede ser idéntico; cambia la narrativa que se cuenta a contribuyentes, usuarios y clientes. Un mensaje dice “esto protege tus libertades”, otro dice “esto reduce fricción y mejora calidad”.

Una guía simple para decidir

Si la prioridad de tu equipo es asegurar que los usuarios downstream mantengan las mismas libertades, promueve el encuadre del software libre y considera el copyleft.

Si tu prioridad es maximizar la adopción (incluyendo empresas que no quieren obligaciones recíprocas), el encuadre open source y una licencia permisiva pueden encajar mejor.

Si quieres colaboración amplia pero también que las mejoras regresen, usa lenguaje abierto para acercamiento y elige una licencia copyleft para lograr el resultado.

Modelos de negocio e incentivos en el mundo real

Software libre no significa “nadie cobra”. Significa que los usuarios tienen la libertad de ejecutar, estudiar, modificar y compartir el código. Muchas empresas construyen ingresos saludables alrededor de esa libertad—a menudo cobrando por lo que las organizaciones realmente necesitan: fiabilidad, responsabilidad y tiempo.

Cómo ganan dinero las empresas con FOSS

Algunos modelos probados:

• Soporte y servicios: mesas de ayuda, SLAs, formación, auditorías, funciones personalizadas y migraciones.
• Hosting y ofertas gestionadas: vender una versión alojada donde los clientes pagan por conveniencia, escalado, backups y cumplimiento.
• Doble licencia: ofrecer el mismo software bajo una licencia libre (a menudo copyleft) y también una licencia comercial paga para clientes que necesitan otros términos.
• Open core (con cautela): mantener una base realmente libre mientras se venden complementos propietarios. Puede funcionar, pero también tensiona la confianza comunitaria si la parte “libre” parece intencionadamente limitada.

Un giro moderno en el modelo de “oferta gestionada” es la aparición de plataformas que generan y ejecutan aplicaciones rápidamente. Por ejemplo, Koder.ai es una plataforma de vibe-coding que ayuda a equipos a crear aplicaciones web, backend y móviles vía chat—y que además admite la exportación del código fuente. Esa combinación (iteración rápida más propiedad del código) encaja bien con los valores detrás de la libertad del software: la capacidad de inspeccionar, cambiar y mover tu software cuando lo necesites.

Por qué permisiva vs copyleft afecta la estrategia

La elección de licencia puede moldear quién captura valor:

• Licencias permisivas (como MIT/Apache) facilitan que otros—incluidos grandes proveedores—reusen tu código en productos propietarios. Eso puede aumentar la adopción, pero reducir la capacidad de monetizar exclusividad.
• Licencias copyleft (como GPL) exigen a los redistribuidores downstream compartir modificaciones bajo los mismos términos. Eso puede desalentar forks cerrados y favorecer modelos basados en servicios, distribuciones certificadas o doble licencia.

“Comercial” y “software libre” no son opuestos

“Comercial” describe cómo se vende; “software libre” describe los derechos del usuario. Una empresa puede vender software libre, cobrar por soporte y seguir respetando la libertad del software.

Lista de verificación de sostenibilidad

Antes de adoptar o apostar por un producto en un proyecto FOSS, pregunta:

• ¿Hay una comunidad activa (issues, releases, reviews)?
• ¿La gobernanza es clara (quién decide, cómo se resuelven conflictos)?
• ¿El financiamiento es visible (patrocinadores, respaldo empresarial, fundación)?
• ¿La carga de mantenimiento es sostenible (bus factor, señales de burnout)?
• ¿Las prácticas de seguridad están documentadas (cadencia de parches, avisos)?

Malentendidos comunes sobre la GPL y el FOSS

La GPL y el “FOSS” se discuten mucho, pero algunos mitos recurrentes enturbian —sobre todo para equipos que solo quieren lanzar un producto sin romper licencias.

“GPL significa dominio público”

No lo hace. Dominio público significa que no hay propietario de copyright que imponga condiciones—cualquiera puede reutilizar la obra sin obligaciones.

La GPL es lo opuesto a “sin condiciones”. El autor mantiene el copyright y otorga permisos amplios para usar, modificar y compartir, pero solo si cumples los términos de la GPL (más famoso: compartir el código cuando distribuyes binarios cubiertos).

“El código abierto siempre es seguro”

Hacer el código visible puede ayudar la seguridad, pero no la garantiza. Un proyecto puede ser open source y aun así:

• estar sin mantenimiento,
• recibir pocas revisiones,
• tener vulnerabilidades que duran años antes de ser descubiertas.

La seguridad viene de mantenimiento activo, auditorías, divulgación responsable y buenas prácticas operativas—no del sello de la licencia.

La etiqueta de “licencia viral”

Mucha gente llama a la GPL “viral” para sugerir que se propaga sin control. Es una metáfora cargada.

Normalmente se refiere al copyleft: si distribuyes una obra derivada de código GPL, debes proporcionar el código fuente correspondiente bajo la GPL. Esa exigencia es deliberada: preserva las libertades del usuario downstream. No es una “infección”; es una condición que puedes aceptar o evitar usando otro código.

“¿Puedo usar código GPL en mi app o servicio?” (regla general)

Regla práctica: las obligaciones se activan principalmente con la distribución.

• Uso interno: usar software GPL dentro de tu empresa normalmente no requiere publicar cambios.
• Enviar una app/dispositivo: si distribuyes un programa licenciado bajo la GPL (o una derivada), generalmente debes proporcionar código y avisos.
• SaaS / servicios web: ejecutar software GPL en tus servidores normalmente no obliga a liberar el código a los usuarios. (La AGPL fue creada para cerrar ese hueco.)

Cuando importa, obtén una lectura precisa basada en cómo se combina y distribuye el código—no en suposiciones.

Críticas, controversias y debates en curso

Richard Stallman es una figura controvertida. Es posible reconocer eso y aun así hablar con claridad sobre la influencia perdurable de las ideas y licencias asociadas a él.

Un punto de partida útil es separar dos conversaciones: (1) debates sobre Stallman como persona y miembro de la comunidad, y (2) el impacto medible de los principios del software libre, el Proyecto GNU y la GPL sobre licenciamiento y derechos de los desarrolladores. Lo segundo puede discutirse con fuentes primarias (textos de licencias, historias de proyectos, patrones de adopción) incluso cuando se discrepa fuertemente sobre lo primero.

Gobernanza y “¿quién decide?”

Una crítica recurrente no trata de licencias sino de gobernanza: cómo los proyectos toman decisiones, quién tiene autoridad y qué pasa cuando fundadores, mantenedores y usuarios quieren cosas distintas. Las comunidades de software libre han lidiado con preguntas como:

• ¿Cómo debería elegirse o reemplazarse el liderazgo?
• ¿Deben las fundaciones ser dirigidas por miembros, juntas o mantenedores?
• ¿Cuándo entra en conflicto la “libertad” del mantenedor con las necesidades de los contribuidores?

Estas preguntas importan, porque las licencias establecen términos legales, pero no crean procesos saludables de toma de decisiones por sí solas.

Inclusividad, conducta y normas comunitarias

Otro debate continuo se centra en la inclusividad y las normas: cómo los proyectos definen expectativas de comportamiento respetuoso, cómo gestionan conflictos y cuán acogedores son para nuevos participantes. Algunas comunidades enfatizan códigos de conducta formales; otras prefieren reglas mínimas y moderación informal. Ningún enfoque es automáticamente “correcto”, pero las compensaciones son reales y merecen discusión sin ataques personales.

Mantener la discusión anclada

Si evalúas el legado de Stallman, ayuda mantener las afirmaciones verificables: qué exige la GPL, cómo cambió el cumplimiento, y cómo influyeron estas ideas en licencias e instituciones posteriores. Puedes ser crítico, partidario o indeciso—pero apunta a la precisión, el respeto y la claridad sobre lo que se está criticando.

Conclusiones prácticas: elegir licencias y contribuir

El mayor regalo práctico de Stallman a equipos cotidianos es una pregunta clara: ¿qué libertades quieres garantizar downstream? Responderla convierte la “elección de licencia” de un gesto a una decisión.

Un árbol de decisiones simple

• ¿Quieres que otros (incluidos competidores) reutilicen tu código con mínimas condiciones? Elige una licencia permisiva (p. ej., MIT, Apache-2.0).
• ¿Quieres que las mejoras a tu código sigan siendo compartibles al redistribuirse? Elige copyleft fuerte (p. ej., GNU GPL).
• ¿Quieres que el intercambio aplique principalmente a modificaciones de tu biblioteca, permitiendo que aplicaciones propietarias la enlacen? Elige copyleft débil (p. ej., LGPL, MPL).

Si dudas, decide según tu objetivo: adopción (permisiva) vs reciprocidad (copyleft) vs reciprocidad amigable para bibliotecas (copyleft débil).

Pasos prácticos para distribuir software responsablemente

1. Elige una licencia por proyecto y dilo claramente en tu README.
2. Añade un archivo LICENSE en la raíz del repositorio (copia el texto completo de la licencia).
3. Incluye cabeceras de copyright donde tu organización lo requiera.
4. Documenta dependencias (directas y transitorias importantes) y sus licencias.
5. Si distribuyes binarios, prepara los avisos requeridos, ofertas de código (si aplica) y atribuciones.

Si construyes productos con desarrollo asistido por IA (incluyendo plataformas de chat como Koder.ai), esta lista importa aún más: sigues emitiendo dependencias reales, artefactos reales y obligaciones de licencia reales. La velocidad no quita responsabilidad: hace más valiosos los procesos repetibles de cumplimiento.

Crear una rutina interna ligera de cumplimiento

Hazla aburrida y repetible:

• Genera un SBOM durante las compilaciones.
• Mantén una plantilla de notices y actualízala conforme cambian las dependencias.
• Añade un punto de control de revisión de licencias a PRs/lanzamientos (incluso una lista de comprobación de 10 minutos).

Para comparaciones más profundas, véase /blog/choosing-an-open-source-license y /blog/gpl-vs-mit-vs-apache.