Desde hace bastante tiempo, todo software que escribo no sea trivial y que quiera compartir online incluyendo el código porque no lo vaya a explotar comercialmente (o incluso algunos que sí pretendo explotar comercialmente pero no de forma tan obvia), lo publico con licencias como GPL, LGPL y AGPL. La principal razón por la que hago esto es para protegerme a mí y a mis proyectos mediante las cláusulas de viralidad que tiene la familia de licencias *GPL.
Cuando publicas software con licencias como BSD o MIT, estás usando las licencias más permisivas que hay para publicar software dentro de lo mainstream, dándole permiso a cualquier persona a construir a partir de lo que has hecho. Sin embargo, con los años ha quedado evidente que quienes más te van a invitar a publicar bajo esta licencia son también las mayores sanguijuelas del mundo, y es de eso precisamente de lo que me trato de defender.
Al publicar bibliotecas o código con alguna de estas licencias, cualquier persona o empresa puede emplear el código que has hecho como base para crear otras cosas, o usarla como dependencia. No existe ningún tipo de fricción más allá de las pocas cosas que pide la licencia: que no uses el nombre del autor y del proyecto original para implicar apoyo (razón por la que Sony es discreta para decir que el sistema operativo de la PlayStation existe gracias a FreeBSD), y que conserves el texto de la licencia original en el producto final en el que lo usas (esta es la razón por la que tantos programas y aplicaciones móviles hoy día tienen un menú que lista todas las dependencias del mismo y sus licencias).
No existen muchas limitaciones con respecto a lo que se puede hacer con ese código al tomarlo prestado. Puedes escribir el código de una biblioteca JavaScript para crear gráficas SVG, y esa biblioteca puede acabar siendo usada en la pantalla de a bordo de un transbordador espacial, o en la versión web de TikTok o de Instagram.
Cuanto más abierto, más ojos
Eric Raymond con el paso de los años ha tenido el honor de enseñarnos que es un hijo de la grandísima puta, pero cuando escribió originalmente La Catedral y el Bazar después de fundar el concepto «código abierto», acertó con bastantes de las ideas originales que tenía en mente, incluso pese a que, con el paso de las décadas, la manera en la que la sociedad ha acabado usando el código abierto no se ha alineado con lo que originalmente propuso.
Una de esas ideas que nació como una cosa pero que ha acabado convertido en otra completamente diferente es la de que cuanto más abierto y visible sea el desarrollo de un código, más ojos habrá para encontrar los defectos.
Como tal, esto sigue siendo cierto si hay voluntad. Una de las cosas que más feliz me hacen cuando estoy programando con bibliotecas ajenas es tener la oportunidad de depurar un bug, ver que la causa está en una biblioteca ajena, arreglar un archivo que no es mío, y luego enviar la corrección al proyecto original. Y en general esto a pequeña escala sigue siendo frecuente, sobre todo, por parte de personas que tengan menos experiencia.
Sin embargo, no todo el mundo es así. No está de más recordar aquella vez que Microsoft publicó un ticket en el tracker de voluntarios de FFmpeg prácticamente diciendo «lo quiero para ayer» porque la biblioteca falla en una función usada por uno de sus productos estrella. (Siendo justos, FFmpeg está publicado con licencia dual GPL+LGPL, no es una licencia permisiva como la que estoy describiendo aquí.)
Cuando fueron pillados por esto, Microsoft ofreció un simbólico pago de una vez de varios miles de euros por el soporte con este bug. Un bug que, insisto, ocurre en Microsoft Teams. Un programa que a día de hoy mueve el mundo con la energía recíproca con la que miles de trabajadores mueven el ratón cada pocos minutos para que Teams no les marque como ausentes.
Tampoco está de más recordar aquella vez que log4j, una dependencia discreta de Java que normalmente está oculta sin hacer ruido en el fondo de una aplicación, saltó a la fama por una vulnerabilidad que afectaba a demasiadas aplicaciones y que podía reproducirse en productos de Microsoft, Apple, Twitter…
log4j prácticamente por entonces se desarrollaba gratis. Las personas que lo mantenían no habían visto apenas compensación por el trabajo que aportaban a la comunidad, ni siquiera por parte de empresas que habían hecho millones gracias en parte a ese trabajo. Por ponerlo en contexto, uno de los programas donde se usaba log4j era Minecraft, cuyo estudio fue comprado años atrás por Microsoft por 2500 millones de dólares.
log4j ha recibido en los últimos años financiación por parte del STA. Al menos 596.000 €. Su situación sin duda, ha mejorado. Pero es la prueba de que existe mucho software integrado en lo más profundo de la industria, que de desaparecer podría devolvernos atrás varios años, pero que sin embargo no obtiene el reconcimiento que se merece hasta que no es demasiado tarde.
log4j durante un tiempo dio mucho que hablar, y hubo gente que se preocupó por la situación económica y el bienestar de la gente que lo crea, pero con el tiempo volvió a olvidarse el tema. Algo parecido a lo que pasó en 2024 cuando se destapó el backdoor de xz.
Why I GPL
Un artículo antiguo que guardo en mis marcadores como enlace a Web Archive porque ha desaparecido de internet es Why I (A/L)GPL (2011), el cual realmente es bastante parecido a este artículo que estoy escribiendo. En él, se cuenta la historia de Mongrel, uno de los primeros servidores HTTP para Ruby. Las primeras versiones de Ruby on Rails lo usaban, hasta que su creador cambió de stack y el proyecto quedó abandonado y reemplazado por otros servidores HTTP.
Uno de los problemas que su creador se encontró fue que, pese a que Mongrel se volvió durante años en el servidor HTTP de referencia para Ruby on Rails, y pese a ser un stack que durante el boom de la web 2.0 de finales de la década de los 2000s y principios de 2010s creó multimillonarios, no sólo nunca obtuvo reconocimiento, sino que recibió cierto desprecio.
I wrote Mongrel and then gave it away, on the hopes that it would help a bunch of other people, and that giving it away would come back to me in some way. Maybe a job, or some respect, or hell maybe my own company doing more software like it.
Mongrel was a wild success, and lots and lots of companies are making lots and lots of money off it. It not only powered Rails, but nearly every Ruby web framework, other Ruby web servers, and was even ported to other languages. Mongrel is and was a super project and I’m really proud of it.
[…] Sadly, none of Mongrel’s success mattered for me. Even though everyone was using my software, the vast majority of firms using Mongrel were startups. The last thing a startup wants to admit is that they don’t own their intellectual property. They want everyone, especially the VCs and investors, to believe that they’re all geniuses who “innovated” everything they run.
[…] Everyone is using it, and at the same time saying I can’t code.
El resto del artículo es una genialidad y esa es la razón por la que lo he enlazado arriba, para que no se olvide nunca, incluso aunque la copia ya solo esté accesible desde el Web Archive.
El caso de SQLite
SQLite es posiblemente la base de datos más usada en todo el planeta. Es lo suficientemente pequeña como para que no sea una aplicación de red, sino que se integre directamente en las tripas del software donde se usa. En otras palabras: no es una base de datos a la que te conectas, sino que es una dependencia que agregas a tu programa y que usas llamando a funciones, como cualquier otra biblioteca dinámica de programación.
SQLite está publicada en dominio público. Su código se puede usar y tomar para cualquier otro producto, abierto o cerrado, y exprimir comercialmente todo lo que se pueda. (Tangencialmente, SQLite también es ese proyecto que se metió en un drama hace varios años porque su código de conducta estaba prácticamente basado en Los 10 mandamientos, e incluso a día de hoy sigue teniendo un código ético cuya primera regla es «amarás a Dios»; sin embargo, no parece haber razón religiosa detrás del hecho por la que es dominio público.)
Que sea tan permisivo y que no tenga ningún tipo de limitaciones en cuanto a su uso y distribución ha atraído en los últimos años a muchas empresas a derivar el código y crear nuevos motores de bases de datos a partir del SQLite original y tratar de comercializarlos como la nueva idea revolucionaria que merece recibir millones de dólares de capital. DuckDB, Deno KV, Tulso… llámalo como quieras.
Lo venden como «La nueva base de datos ultra ligera para la computación moderna». Y luego resulta que lo que han hecho es «SQLite pero te conectas a través de un puerto TCP», que es justo quitar la única ventaja que tiene SQLite frente a cualquier otra base de datos del mercado. Pero pueden hacerlo porque saben que tienen permiso para hacerlo. Y no tienen miedo de, en el camino, intentar despreciar al producto original cuyo código están desguazando para beneficiarse de él, con frases como «mejor que SQLite» o «hora de dejar atrás SQLite».
La viralidad de la GPL como arma
Frente a esto, la familia de licencias GPL tiene una condición muy importante que es la viralidad. Si derivas un código GPL para transformarlo en otra cosa, eso que hagas también tiene que estar publicado bajo la GPL, salvo que ya esté publicado con una licencia compatible. Si copias un fragmento de código GPL en tu programa de internet sin prestar atención, tu programa automáticamente se vuelve GPL o está inclumpliendo la licencia.
Y esta es la razón también por la que prácticamente cualquier gran empresa no quiere saber nada de ninguna biblioteca publicada como GPL. En el momento en el que un programa se enlaza dinámicamente a nivel sistema operativo con una biblioteca GPL, o en el momento que uno de los empleados copia de internet un fragmento de código GPL y lo inserta en lo que está escribiendo, conforman una única unidad, por lo que todo el producto también se vuelve GPL.
Esto es algo que solo afecta a trozos de código copiados sin contexto y a bibliotecas. Usar un programa GPL de forma separada e independiente no va a volver el programa principal GPL. Esa es la razón por la que, por ejemplo, Apple tradicionalmente ha distribuido Bash y otros componentes GPL con su sistema operativo. Mientras estén sueltos y no combinados, no son peligrosos.
Usar una aplicación GPL en tu empresa para depurar la API del servicio HTTP que estás desarrollando no va a volver lo que estás programando como GPL. Sin embargo, algunos abogados y departamentos de informática tienen estrés postraumático y se ven obligados a prohibir cualquier traza de GPL en una empresa.
No quiero perras, sólo quiero un uso justo y honestidad
¿Estoy dando a entender que no publico con licencias permisivas porque quiero dinero? No necesariamente. He compartido estos ejemplos para probar que lo que nació como un movimiento de «creación de software en comunidad de forma abierta» se ha convertido en un método de extracción de esfuerzo donde algunas empresas poderosas, y otras personas no tan poderosas pero sí con un MBA en su pared, se aprovechan de manera sofisticada del trabajo comunitario de otras personas evitando tomar responsabilidad en las acciones que cometen.
Sobre todo cuando se trata de tomar la dependencia escrita por un programador junior y publicada con licencia permisiva e integrarla en productos de software de lo más variados. Quieren la parte positiva del código abierto (ahorrarse costes de desarrollo), sin pensar en la parte negativa (que es que, tal como dicen tanto la licencia BSD como la MIT, que ese código no tiene ninguna garantía y se ofrece tal cual, o sea, AS IS). ¡Dios mío! El código que he tomado de internet no funciona. ¡Que alguien haga algo!
De forma parecida a lo que mencionaba con SQLite, cuando publico software como GPL, lo estoy haciendo para protegerme precisamente de este tipo de casos. No tengo problema en que haya gente que modifique el código y agregue cosas en las que no había pensado. Precisamente por eso comparto el código. Sin embargo, si alguien pretende derivar el software para compartir de forma pública su versión alterada, debe publicar el código fuente para asegurarme de que actúa de forma honesta y justa.
Conclusión
Para código trivial, implementaciones de bibliotecas que ya existen y que son dificiles de superar, o para bibliotecas de 5 líneas con algoritmos que sean fáciles de replicar, no veo problema en publicar código con licencias permisivas.
Sin embargo, para cualquier otra cosa donde el código que estoy compartiendo realmente valga la pena o haga algo único y especial, no veo a día de hoy razón para usar algo que no sea la GPL. De este modo se comparte de forma mucho más justa el código de manera que nadie intente explotar a nadie, solo mejoremos a la vez de forma colectiva.
