Embrollos digitales: ¿Qué es la proliferación de licencias?

La principal medida con la que se logra hacer de código abierto o libre a un proyecto es el licenciamiento. Las licencias son documentos de carácter legal simples, claros y específicos. Por lo tanto, es razonable pensar que no es complicado decidir uno a la hora de abrir nuestro programa al mundo.

¿O no?

Aunque esta declaración parezca un poco surreal, la especificidad se está volviendo un problema para el licenciamiento de software, especialmente para la comunidad de desarrollo de software libre y de código abierto (FOSS, como siempre; ya lo saben). Además de la especificidad, existen otros factores que están acrecentando la proliferación de licencias, un fenómeno que trataremos de diagnosticar en el presente artículo.

¿Qué es la proliferación de licencias?

Es un término que se refiere a un conjunto de problemas que nacen a partir del crecimiento descontrolado de las licencias de software. Naturalmente, uno puede preguntarse, ¿cómo podría ser la ampliación del repertorio de licencias algo "descontrolado"? ¿Acaso esto no empoderaría más al desarrollador al dotarlo de más elecciones?

La respuesta a esos cuestionamientos se halla en solo una palabra: incompatibilidad. La encuesta Octoverse 2024, organizada por GitHub, estimó que cada 32 segundos se realizaba una contribución a un proyecto FOSS, sumando a un impresionante total de 2.7 millones de contribuciones al día¹. Mientras que la jungla digital del FOSS siga creciendo, también lo harán las aspiraciones a combinar proyectos en algo más grande.

Pero, ¿qué pasa cuando las licencias de los programas que quieres fusionar, a pesar de autodenominarse FOSS, son incompatibles? El panorama sería totalmente desastroso no solo para quienes pretenden construir proyectos multilicencia, sino para desarrolladores que desean programar herramientas pequeñas que cumplan el rol inherente de parte de un todo. El costo de analizar si una licencia es compatible con el resto aumentaría sustancialmente. Hay que tener presente, al mismo tiempo, que un ecosistema de licencias compatible y predecible es esencial para fomentar la innovación colaborativa que caracteriza al movimiento FOSS².

Vanidad; o, el avance del Not Invented Here

Hay que imaginar al desarrollador. Después de largas jornadas invertidas en programar una nueva empresa, por fin llega a la etapa final: hacer a su programa de código abierto. Solo está a una licencia de que todo acabe y, sobre todo, de que sea apreciado por los otros por el trabajo que realizó en nombre del bien común. Sin embargo, y para sorpresa de sus camaradas, al último momento decidió esbozar su propia licencia. ¿El resultado? Aunque hubo muchos interesados en el gran trabajo de nuestro desarrollador, ninguno lo utilizó. Todo esto pasó a raíz del uso de una licencia no estándar, sin grandes corporaciones u organizaciones que la respalden... una licencia fantasmal, se puede decir.

Este escenario sirve para mostrar los peligros de crear licencias por el mero hecho de crear licencias, ya sea por ignorancia o, específicamente, por la fuerte aberración a aplicar cosas de origen foráneo, externo. Esto último puede ser descrito como una etapa más avanzada de lo descrito por la famosa frase angloparlante: Not Invented Here (No inventado aquí), con notable sentimiento tribalista. El producto de ignorar licencias que pueden ser aptas para tu proyecto con el objetivo de concretar otra licencia sin fundamento y, peor aún, sin muestra de mejora alguna frente a competidoras, se le denomina "licencia vanidosa" o, en más claros términos, "licencia de vanidad". Así pues, las licencias de vanidad exacerban la proliferación de licencias.

Contramedidas

Algunas instituciones han buscado contener el problema de la proliferación de licencias desde sus propias perspectivas.

Caso famoso: GitHub lanzó en 2013 su asistente choosealicense, que simplifica el proceso de selección a solo tres licencias principales: MIT, Apache 2.0 y GPL³. Así, para 2015 cerca del 77% de los proyectos usaron al menos una de estas⁴. Google Code impuso entre 2006 y 2010 un conjunto reducido de licencias permitidas, restringiendo aquellas que fomentaban duplicación innecesaria, como la AGPLv3⁵. Por su parte, la Open Source Initiative (OSI), tras años de haber aprobado licencias menores y redundantes, reaccionó en 2004 con el License Proliferation Project. Actualmente, la OSI mantiene una lista que aboga por licencias con comunidades comprometidas y facilidad de reutilización⁶. Finalmente, la Free Software Foundation (FSF) ha defendido continuamente la necesidad de mantener la compatibilidad con la GPL, bajo el argumento de que en la mayoría de los casos basta con reutilizar lo que ya existe⁷.

Algunas contramedidas son más efectivas que otras, como se puede ver. Si bien la proliferación no puede erradicarse del todo, sí puede reducirse con herramientas, recomendaciones y una clara preferencia por estándares reconocidos y probados en años de uso.