Jake Bauer: la GPL fracasó como defensa del software libre

Un ensayo que se actualiza desde 2021 y que incomoda a la industria

Jake Bauer, desarrollador y ex evangelista del software libre, publicó Free Software is an Abject Failure en noviembre de 2021 y lo ha actualizado seis veces desde entonces, la última en agosto de 2026. Su tesis: el movimiento del software libre, el del copyleft y la GPL no solo no cumplieron sus objetivos declarados, sino que le hacen más daño al ecosistema FOSS del bien que aportan.

Para un founder, esto no es filosofía de sobremesa. La licencia que eliges decide qué código puedes integrar en tu producto, qué te van a preguntar en una due diligence y, en algunos casos, si puedes distribuir tu software como quieres.

La distinción que casi nadie hace al elegir licencia

Bauer usa «software libre» en sentido estricto: software con licencias copyleft, como la GPL, y lo diferencia explícitamente del open source con licencias permisivas (MIT, BSD, Apache). La Free Software Foundation hace la misma distinción. Es exactamente el punto donde muchos equipos se pierden: creen que «open source» y «software libre» son lo mismo y eligen licencia sin entender que están comprando dos filosofías distintas.

La contradicción central: software sin dueño, pero con dueño

El argumento de Richard Stallman en Why Software Should Be Free es que el software no debería tener dueños y que las razones para retener la propiedad —emocionales y económicas— no se sostienen. Bauer dice estar de acuerdo con esa premisa. Su crítica es que el movimiento que la predicó hizo lo contrario.

En casi todo proyecto de software libre hay un dueño claro: el titular del copyright, un «benevolent dictator for life» o el líder de facto por donde pasan todas las contribuciones. Menciona el kernel de Linux (donde Linus Torvalds mantiene poder de veto), Qt (controlado por la empresa, que libera versiones antiguas) y Android (donde Google mantiene el control).

El punto más incómodo es otro. El Manifiesto GNU afirma que GNU «no está en el dominio público» y que aplicará restricciones a las modificaciones futuras, con esta justificación de Stallman: «Quiero asegurarme de que todas las versiones de GNU sigan siendo libres». Para Bauer, ese es el mismo apego emocional que Stallman descalificó en su propio ensayo. También cita el texto donde Stallman se opone a reformas de copyright que beneficiarían a la sociedad, porque reducirían el control que las licencias libres ejercen sobre la distribución.

¿La GPL te protege o te encierra?

El Manifiesto GNU prometía algo concreto: eliminar «la carga de considerar quién es dueño del software del sistema y qué puede o no hacer uno con él». Bauer sostiene que la GPL fracasó en eso.

• La licencia es tan compleja que exige formación legal avanzada para interpretarla. Incluso los abogados no coinciden del todo en sus alcances, y muchas empresas la evitan por miedo a verse obligadas a revelar código propietario.
• La cláusula «o cualquier versión posterior» multiplica el problema: hoy conviven versiones que no son compatibles entre sí. Un proyecto GPLv2-only, como el kernel de Linux, no puede integrar código GPLv3 sin relicenciarse.
• El efecto se ve en la práctica: los sistemas BSD no pueden tomar mejoras del kernel de Linux e integrarlas directamente, y ZFS no puede entrar en el kernel de Linux aunque sí se distribuye con FreeBSD.

Dos citas resumen el malestar. Linus Torvalds dijo que la GPLv3 está diseñada expresamente para impedir el encuentro entre el mundo open source y el del software libre, «exactamente porque la FSF nos considera herejes». Theo de Raadt fue más lejos: el gran problema no fue que las empresas tomaran código BSD sin devolver nada, sino que ahora «la gente envuelve nuestro código con la GPL y nos deja afuera». El propio Bauer reconoce que hay muchas empresas que sí devuelven código y que la GPL no es tan obstructiva como una licencia propietaria: simplemente, sostiene, no es mucho mejor.

El copyleft no impide que una empresa se quede con tu proyecto

Aquel objetivo del Manifiesto —que los usuarios dejen de estar «a merced de un programador o una empresa que posee el código fuente»— tampoco se cumplió, según el autor. Sus ejemplos:

• Audacity: Muse Group compró los derechos del código y del proyecto. La comunidad bifurcó el software, pero eso no impide que vuelva a pasar con otros proyectos.
• Gitea: el mismo patrón se repitió después, según una de las actualizaciones del ensayo.
• Red Hat: pasó a ofrecer el código fuente de Red Hat Enterprise Linux solo a clientes de pago —algo que, según Bauer, está dentro de la letra de la GPLv2— y advirtió que terminará los contratos de soporte de quienes redistribuyan ese código.
• AGPL: el caso más reciente es Forgejo, que tuvo que dejar de usar una librería de imágenes al descubrir que estaba bajo AGPL, lo que habría obligado a distribuir todo el proyecto bajo esa licencia. «Fuego amigo» dentro del propio FOSS, lo llama.

La aplicación de la licencia también es desigual. Bauer menciona incumplimientos sin consecuencias y describe a instituciones como la Software Freedom Conservancy o la FSF Europa dependiendo de demandas por violación de la GPL, con la demanda contra Vizio como caso visible y violaciones públicas como las de OnePlus sin respuesta.

La cultura: bifurcar es «robar» y los usuarios no pueden arreglar nada

• Los usuarios siguen dependiendo de los mantenedores para que acepten sus cambios. Un pedido de función en GNOME —un modo de vista con miniaturas— se abrió en 2004 y tardó cerca de 20 años en resolverse.
• Bifurcar un proyecto se trata como «fork hostil» o directamente como robo: ocurrió con Gogs y Gitea, y con el episodio de XFree86, donde un desarrollador original fue apartado del proyecto. Si el software no tiene dueño, pregunta Bauer, ¿qué se está robando?

Una fundación que pelea batallas simbólicas

Para Bauer, la FSF lleva dos décadas perdiendo relevancia: envió un disco duro a Microsoft pidiendo el código de Windows 7, acusó a Apple de «censurar el software libre» cuando lo que ocurre es que el contrato de la App Store impone condiciones que la GPL no permite, y nunca publicó su kernel HURD de forma significativa. Mientras tanto, componentes históricos de GNU pierden terreno frente a Clang/LLVM, BusyBox o musl. A eso suma la conducta pública de Stallman, como el hilo que abrió en 2007 en la lista de correo de OpenBSD titulado «Real men don't attack straw men».

¿Qué significa esto para tu startup?

No hace falta compartir el diagnóstico para aprovechar la discusión. Estas son las decisiones que el debate debería forzar en tu equipo:

• Audita tus dependencias, no solo tu código propio. El efecto «viral» del que se queja Bauer no depende de lo que escribes, sino de lo que importas. Arma un inventario de licencias de todo el árbol de dependencias antes de una ronda o de una venta.
• Trata la AGPL como un riesgo de producto. Si tu negocio es SaaS y no quieres abrir tu código, verifica que ninguna dependencia sea AGPL. El caso de Forgejo muestra que ni siquiera los proyectos GPL quedan a salvo.
• Elige licencia según lo que quieres lograr. Si buscas adopción e integraciones, la licencia permisiva reduce fricción. Si quieres evitar que un tercero cierre tu código, el copyleft sirve, pero asume el costo: menos proyectos podrán integrarte y no te protege de una adquisición.
• No pongas toda tu defensa en la licencia. Los casos de Audacity, Gitea y Red Hat sugieren que el control real se juega en la gobernanza: quién es dueño de la marca, quién decide el roadmap y qué acuerdos firmas con quienes contribuyen.
• Documenta la decisión. En una due diligence, un inversor o un comprador va a preguntar por componentes GPL y AGPL en tu stack. Tener la decisión escrita y justificada te ahorra semanas de ida y vuelta.

Conclusión

Bauer cierra con una afirmación que incomoda a los dos bandos: el grado de apertura que existe hoy en el software se debe, en gran medida, al movimiento open source, y ocurrió «a pesar del movimiento del software libre, no gracias a él». Se puede discrepar con el tono y con el diagnóstico —él mismo pide que las críticas se dirijan a las ideas y no a la persona—. Pero la pregunta que deja el ensayo es útil y concreta: ¿qué está logrando realmente la licencia que elegiste? Si la respuesta es «nada medible», mejor revisarla antes de que lo haga el abogado de la otra parte.

Fuentes

No se encontraron fuentes periodísticas adicionales verificables sobre este debate.

• Free Software is an Abject Failure (Jake Bauer) (fuente original)