Más del 10 % de los paquetes de Python en PyPI se distribuyen sin licencia

Imagina que instalas un paquete de Python cualquiera desde PyPI. Hay un 13,5 % de probabilidad de que el paquete no tenga información sobre su licencia. Si consideramos que no es raro que una aplicación típica de Python tenga cientos de dependencias y subdependencias, es muy probable que se esté usando código sin licencia. Según el contexto, las consecuencias de usar software sin licencia pueden ser insignificantes o desastrosas. De acuerdo, es un rango muy amplio; por eso, en esta publicación profundizaremos en el tema.

¿Qué es PyPI?

PyPI es el repositorio central de paquetes de Python más utilizado. Lo creó y mantiene Python Software Foundation. Normalmente se accede a él mediante herramientas de administración de paquetes, como pip, para descargar e instalar bibliotecas y aplicaciones de Python. Es similar a los repositorios de paquetes de otros lenguajes, como npm para Javascript, RubyGems.org para Ruby y crates.io para Rust.

Antecedentes

Snyk analiza las dependencias de proyectos de software y detecta problemas, como vulnerabilidades de seguridad y licencias inadecuadas. Con ese fin, hace poco me contrataron para obtener de PyPI todos los metadatos sobre los paquetes y sus versiones publicadas, incluida la información sobre las licencias. Con estos datos, examiné la situación de las licencias de todos los paquetes de Python en PyPI.

A continuación se presentan algunos hallazgos clave de este análisis, seguidos de recomendaciones basadas en ellos y una descripción de los métodos utilizados para obtenerlos.

¿Cómo está la situación de las licencias en el ecosistema de Python?

Antes que nada, una aclaración rápida: no soy abogado. Soy ingeniero de software con experiencia y cierto conocimiento sobre licencias de software, pero no soy especialista en el tema. Nada de lo que sigue debe considerarse asesoría legal. Si la necesitas, te recomendamos consultar con un abogado.

Tipos de licencias

En general, casi todas las licencias de software de código abierto se pueden dividir en unas pocas categorías amplias:

• Las licencias «copyleft» son un tipo de licencia relativamente restrictiva. Entre ellas se encuentra la conocida licencia GPL, sus numerosas variantes y otras licencias similares. Permiten usar el software prácticamente para cualquier propósito, pero exigen que cualquier modificación que hagas también se ponga a disposición del público. Además, algunas licencias copyleft «más estrictas» exigen que, en ciertas circunstancias, también se haga público el código que use software con esa licencia.

• Por otro lado, las licencias «permisivas» permiten modificar el software sin tener que hacer públicas esas modificaciones. Además, suelen ser mucho más sencillas y tener menos restricciones.

• En el extremo opuesto están las licencias de «dominio público», que generalmente no imponen ninguna restricción de uso.

Para obtener más información sobre las licencias copyleft y permisivas, consulta una publicación anterior sobre el tema en nuestro blog.

En los últimos años han aparecido varias licencias «copyleft débil». Están pensadas principalmente para bibliotecas de software y permiten usarlas con menos restricciones, o sin ninguna, para el software que las utiliza. Para obtener más información sobre la diferencia entre copyleft «débil» y «estricto», consulta la sección del artículo de Wikipedia sobre el tema.

También es posible, aunque no recomendable, no especificar ninguna licencia. Esto suele deberse a un descuido o a desconocimiento, pero en algunos casos excepcionales se hace intencionalmente. Sin una licencia, el uso del software simplemente queda sujeto a las leyes de derechos de autor (¡de cada país!) y a otros tipos de legislación, como la de patentes.

Distribución por tipo de licencia

Veamos los tipos de licencias que se usan en PyPI:

Estos datos muestran lo siguiente:

• La mayoría de los paquetes de PyPI, el 64 %, usan una licencia «permisiva», como MIT, Apache 2.0 y las licencias BSD de 2 o 3 cláusulas.

• El 18,5 % usa una licencia «copyleft estricta», como GPL y AGPL.

• El 3 % usa una licencia «copyleft débil», como LGPL y MPL.

• Solo el 1 % usa una licencia de «dominio público», como CC0, WTFPL y Unlicense.

• El 13,5 % no incluye ninguna licencia.

Esto no sorprende, ya que es similar a las tendencias generales que se observan en GitHub y en los repositorios de paquetes de otros lenguajes.

Licencias más comunes para paquetes de Python

Cuatro licencias predominan en PyPI: MIT, BSD-2-Clause, GPL-3.0 y Apache-2.0.

También se usan muchas otras licencias (en al menos 100 paquetes). Dos de ellas son exclusivas del ecosistema de Python: la licencia Python Software Foundation (PSF) y la Zope Public License (ZPL).

¡Qué debes hacer AHORA!

Dado el estado de las licencias de los paquetes de Python en PyPI, te recomiendo lo siguiente:

• Verifica si usas software, de forma directa o indirecta, que tenga licencias «copyleft» y asegúrate de comprender las implicaciones para tu código.

  1. Si escribes código propietario (que no es de código abierto), esto podría representar una responsabilidad legal importante, sobre todo por las licencias «copyleft estrictas» que usan más del 18 % de los paquetes de PyPI.

  2. Si desarrollas software de código abierto, esto podría obligarte a publicar tu código bajo términos de licencia similares.

• Verifica si alguna de tus dependencias no tiene licencia.

  1. Si necesitas modificar una dependencia así, o podrías necesitar hacerlo en el futuro, es posible que no tengas autorización para hacerlo según las leyes de derechos de autor.

  2. Es probable que las versiones futuras de esas dependencias incluyan una licencia, pero no puedes saber qué tipo de licencia será.

• Configura una herramienta automatizada para revisar periódicamente o de forma continua las licencias de tus dependencias.

  1. A lo largo del ciclo de vida de un proyecto, es común agregar y cambiar dependencias.

  2. Las dependencias pueden cambiar de licencia entre versiones, por lo que actualizar una versión podría implicar un cambio de licencia.

Más información

Esto es solo una introducción; las licencias podrían ser más importantes de lo que imaginas, así que te recomendamos leer más. Considera investigar los siguientes temas:

• Licencias múltiples (unos 500 paquetes de PyPI tienen varias licencias)

• Compatibilidad de licencias

• Software sin licencia

• Análisis y explicación de las licencias permisivas más comunes

• El aspecto legal del código abierto, en especial la sección sobre cómo elegir una licencia para tu software.

Metodología

A continuación se ofrecen algunos detalles sobre cómo se recopilaron y analizaron los datos.

Primero, recopilé los metadatos de todos los paquetes de PyPI y de todas sus versiones publicadas. Lo hice durante varios días a principios de agosto de 2018. En ese momento había casi 150.000 paquetes en PyPI.

Luego extraje la información de las licencias de cada versión de cada paquete, tanto de los campos «license» como «classifiers». Después, reuní esos datos en una sola estructura, con las versiones ordenadas según una interpretación basada en el versionado semántico.

A continuación, depuré y normalicé los datos de las licencias. Partí de una versión de un normalizador de licencias SPDX utilizado en Snyk. Fui mejorando el normalizador de forma iterativa para que identificara correctamente una mayor variedad de licencias y, después, creé manualmente una amplia tabla de correspondencias para gestionar los numerosos casos excepcionales.

Después, me propuse analizar el 18 % de los paquetes sin licencia. Hasta ese momento, todavía no había revisado los archivos de las versiones publicadas. Seleccioné al azar 50 paquetes sin licencia, descargué sus versiones más recientes y busqué información sobre las licencias. Tras recopilarla, clasifiqué los paquetes en cinco categorías, de la siguiente manera:

Solo los paquetes de la categoría «Licensed» tienen realmente una licencia. La gran mayoría de los que pertenecían a las categorías «training», «throwaway» y «placeholder» incluían algo de código, y podrían usarse como dependencia, intencionalmente o por error (por ejemplo, debido a un error tipográfico). Por eso, consideré razonable clasificarlos como paquetes realmente sin licencia. Al extrapolar estos resultados, estimé que ~18% × 72% = ~13.5% de los paquetes de PyPI no tienen licencia.

Cabe señalar que no realicé un análisis similar de los paquetes con licencia en PyPI. Es probable que haya muchos paquetes de «training», «throwaway» y «placeholder» que sí mencionen una licencia. Por lo tanto, adoptar una postura conservadora y estimar que solo ~18% × 28% = ~5% de los paquetes «reales» de PyPI no tienen licencia probablemente sería muy inexacto. Lamentablemente, no tuve tiempo de realizar ese análisis, así que me limité al análisis descrito anteriormente.

Si tienes preguntas o comentarios, ¡me encantaría saber de ti! Escríbeme en Twitter a @taleinat.