Explora la filosofía del software libre de Richard Stallman, el Proyecto GNU y la GPL, y cómo transformaron el licenciamiento, los derechos de desarrolladores y el ecosistema open source.
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.
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.
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.
“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.
El software libre se define por cuatro permisos básicos:
Estas libertades van de la mano con la agencia: no eres solo consumidor de herramientas: puedes convertirte en participante que verifica, adapta y mejora.
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.
Piensa en una comida de restaurante.
Esa es la idea central: el software libre trata de las libertades que los usuarios necesitan para mantener el control de su computación.
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.
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.
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.
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 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 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:
En términos simples: GNU estaba construyendo la plomería, el cableado y los interruptores—no solo un electrodoméstico.
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”.
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.
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.
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.
Piénsalo como una regla que sigue al código:
El objetivo es evitar un patrón que preocupaba a Stallman: alguien toma el trabajo comunitario, lo mejora y luego encierra esas mejoras.
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.
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.
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:
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.
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.
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.
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.
Bajo la GPL puedes:
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.
Esas libertades conllevan obligaciones cuando distribuyes software:
Estas responsabilidades no son trampas: son el mecanismo que evita que la colaboración se convierta en extracción unidireccional.
Los equipos deberían tratar el cumplimiento de licencias como higiene de liberación. Lleva registro de:
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.
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.
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.
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.
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”.
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.
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.
Algunos modelos probados:
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.
La elección de licencia puede moldear quién captura valor:
“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.
Antes de adoptar o apostar por un producto en un proyecto FOSS, pregunta:
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.
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).
Hacer el código visible puede ayudar la seguridad, pero no la garantiza. Un proyecto puede ser open source y aun así:
La seguridad viene de mantenimiento activo, auditorías, divulgación responsable y buenas prácticas operativas—no del sello de la licencia.
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.
Regla práctica: las obligaciones se activan principalmente con la distribución.
Cuando importa, obtén una lectura precisa basada en cómo se combina y distribuye el código—no en suposiciones.
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.
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:
Estas preguntas importan, porque las licencias establecen términos legales, pero no crean procesos saludables de toma de decisiones por sí solas.
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.
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.
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.
Si dudas, decide según tu objetivo: adopción (permisiva) vs reciprocidad (copyleft) vs reciprocidad amigable para bibliotecas (copyleft débil).
LICENSE en la raíz del repositorio (copia el texto completo de la licencia).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.
Hazla aburrida y repetible:
Para comparaciones más profundas, véase /blog/choosing-an-open-source-license y /blog/gpl-vs-mit-vs-apache.
“Software libre” significa libertad, no precio.
Un programa puede costar $0 y aun así ser no libre si no puedes inspeccionarlo, modificarlo o compartirlo. El software libre se centra en los derechos de ejecutar, estudiar, cambiar y redistribuir el software del que dependes.
La definición se basa en cuatro permisos:
Si falta cualquiera de estas, los usuarios pierden control y la colaboración se vuelve más difícil.
Porque no puedes estudiar ni modificar de forma realista el software sin el código fuente.
El acceso al código fuente permite:
El copyleft usa la ley de derechos de autor para exigir “compartir de la misma manera” cuando redistribuyes.
Puedes usar, modificar e incluso vender el software, pero si distribuyes una versión modificada, debes dar a los destinatarios las mismas libertades (normalmente publicando el código fuente correspondiente bajo la misma licencia).
La GPL concede amplios derechos (usar, estudiar, modificar, compartir) y pide reciprocidad cuando hay distribución.
Si redistribuyes binarios cubiertos por la GPL, por lo general debes:
En general, no.
Para el software GPL, las obligaciones suelen activarse al distribuir. Si modificas código GPL para uso interno y no das copias fuera de tu organización, normalmente no tienes que publicar esos cambios.
(Los casos límite existen: esto es una regla práctica, no asesoramiento legal.)
Depende de cómo se combine el código.
En términos generales:
Cuando importe, mapea el patrón exacto de integración antes de distribuir.
Atacan diferentes preocupaciones:
Elige según quieras reciprocidad fuerte (GPL) o reciprocidad amigable para bibliotecas (LGPL).
Normalmente no bajo la GPL.
Si ejecutas software GPL en tus servidores y los usuarios solo interactúan por la red, por lo general no estás “distribuyendo” copias, así que las obligaciones de compartir código de la GPL no se activan.
Si quieres que el uso por red obligue a compartir el código, considera la AGPL y evalúa cuidadosamente tu modelo de despliegue.
Sí: muchas empresas monetizan software libre/abierto con servicios y entrega, sin restringir derechos de los usuarios.
Modelos comunes:
La elección de licencia afecta la estrategia: la permisiva puede maximizar adopción; el copyleft puede desalentar forks cerrados y favorecer modelos basados en servicios.