La guerra de las licencias de código abierto, una batalla de retaguardia

La batalla por las licencias de código abierto es una batalla de retaguardia. Esta es la observación hecha por Matt Asaycolaborador de IDG y responsable de las relaciones con los desarrolladores en MongoDB. Recordemos que este último ha ocupado otros cargos, incluido el de director de Amazon Web Services y jefe del ecosistema de desarrolladores de Adobe. Hoy, vuelve a las licencias de código abierto y lo que representan a medida que el ecosistema LLM explota. Recientemente, Meta (Facebook) ha puesto a disposición Llama 2un potente modelo de lenguaje grande (LLM) con más de 70 mil millones de parámetros. En el pasado, Meta había limitado el uso de sus LLM con fines de investigación, pero con Llama 2, Meta lo abrió. La única restricción que impone la licencia elegida es que la plantilla no puede utilizarse con fines comerciales. En última instancia, sólo un puñado de empresas tienen la potencia informática necesaria para implementarlo a gran escala (Google, Amazon o Microsoft, que acaba de firmar una asociación con Meta).

Esto significa, por supuesto, que no es “código abierto” en sentido estricto según la definición de Código Abierto (OSD), incluso si Meta lo anuncia como tal. Por eso, algunos puristas gritaron, como Rambo: “Tuvieron que derramar la primera sangre, no yo” y “ ¡Nada ha terminado! Nada ! Todo continúa gracias a ti", insistente que Meta deje de llamar a Llama 2 “código abierto”. En cierto modo tienen razón, pero no se dan cuenta de que sus preocupaciones ya no son relevantes. Durante años, los desarrolladores han optado por ser "lo suficientemente abiertos" con sus repositorios de GitHub. No es que el código abierto no importe, sino que nunca importó tanto como algunos esperaban o creían.

Una breve historia de los días del código abierto

Hace más de 10 años, la tendencia hacia la concesión de licencias permisivas era tan pronunciada que James Governor, analista de RedMonk, dijo : “Los jóvenes [développeurs] hoy son software de código abierto post-POSS. Al diablo con las licencias y la gobernanza, simplemente comprométete con GitHub”. En respuesta, los internautas reaccionaron con preocupación y quejas, afirmando que tendencias anteriores de este tipo habían dado lugar a "aglomeraciones épicas" o que "el intercambio sin licencia condujo a virus transmitidos por software". Y, sin embargo, millones de repositorios de GitHub sin licencia después, no hemos entrado en la era oscura de las licencias. Hoy en día se encuentra software gratuito o “suficientemente abierto” en casi todas las aplicaciones, independientemente de la licencia otorgada al usuario final. Ideal ? Quizás no. ¿Pero es esto una realidad? Sí.

En respuesta, GitHub y otros han diseñado formas de incentivar a los desarrolladores a elegir licencias de código abierto para gobernar sus proyectos. Todas estas iniciativas probablemente ayudarán, pero la realidad es que tampoco importarán, al igual que la propia noción de código abierto. Al menos no como una contracultura rabiosa contra el software propietario. Todo esto lleva a la conclusión de que estamos en plena revolución post-open source, una revolución en la que el software es más importante que nunca, pero donde su licenciamiento está perdiendo interés. Todo tiende a un acceso lo más permisivo y abierto posible al código, hasta el punto de que la licencia subyacente es menos esencial que la facilidad de acceso y uso del software.

El código abierto amplía el acceso a software de calidad

Demasiados defensores del código abierto piensan que las licencias son un objetivo final, en lugar de simplemente un medio para otorgar acceso en gran medida sin restricciones al código. Siguen preocupándose por las licencias mientras que los desarrolladores se preocupan sobre todo por el uso, como siempre lo han hecho. Tengamos en cuenta que, más que cualquier otra cosa, el código abierto amplía el acceso a software de calidad sin involucrar equipos de adquisiciones o (generalmente) expertos legales. Esto es muy similar a lo que la nube ha hecho con el hardware. El problema nunca fue la licencia. Siempre se trató de acceso. Cuando trabajaba en AWS, realizamos una encuesta a desarrolladores para preguntarles qué valoraban más sobre el liderazgo en código abierto.

Se podría pensar que contribuir con código a proyectos conocidos sería la mejor opción, pero ese no es el caso. Ni siquiera en segunda o tercera posición. En cambio, el criterio número uno que utilizan los desarrolladores para juzgar el liderazgo de código abierto de un proveedor de nube es que "facilita la implementación del software de código abierto preferido en la nube". No digo que las contribuciones no sean importantes, pero no lo son por las razones que podrías pensar. Una de las cosas que hicimos bien en AWS fue trabajar con equipos de productos para ayudarlos a descubrir su propio interés en contribuir a proyectos en los que estaban creando servicios en la nube, como Elasticache (un almacén de datos en memoria). No buscábamos recibir elogios de nadie, sino más bien poner al equipo de producto en una mejor posición para ayudar a los clientes. Y funcionó. Aunque no es perfecto, una población cada vez mayor de equipos en AWS está contribuyendo significativamente a proyectos de código abierto.

Una manera efectiva de cumplir con los estándares

Sin embargo, para los desarrolladores que utilizan estos servicios, el código abierto es una preocupación secundaria después de "esto me ayuda a ser más productivo y más rápido". Lo cual, nuevamente, no quiere decir que el código abierto no importe en nuestro mundo de software "en la nube". El código abierto es una forma eficaz de acordar estándares, lo que facilita que los desarrolladores (y las empresas) accedan a habilidades e infraestructura comunes.

Pero no es un fin en sí mismo, y los grandes defensores del código abierto deben darse cuenta de ello. El objetivo del código abierto, la nube, las API abiertas, una excelente documentación, etc. es brindar a los desarrolladores la capacidad de construir con menos fricción y más oportunidades. ¿Llama 2 es lo suficientemente abierto como para que el 99,999% de los desarrolladores puedan usarlo con acceso ilimitado? Sí. ¿Es de código abierto? La pregunta ya no importa realmente.