chardet y LGPL: cuando relicenciar viola derechos

El debate que sacude al ecosistema open source: ¿pueden los mantenedores relicenciar un proyecto sin permiso?

Si alguna vez has creado o contribuido a un proyecto de software libre, la controversia que rodea al paquete chardet debería preocuparte —y mucho. En su versión 7.0.0, los mantenedores actuales del proyecto cambiaron la licencia de LGPL v2.1 a MIT, una decisión que desató una tormenta legal y ética en la comunidad open source. El issue #327 del repositorio en GitHub se convirtió en el epicentro de un debate que va mucho más allá del código: habla de propiedad intelectual, consentimiento y los límites reales del software libre.

¿Qué es chardet y por qué importa?

chardet es una popular librería de Python para la detección automática de codificación de caracteres. Es utilizada por proyectos emblemáticos del ecosistema Python como Requests (PSF), httpx y herramientas de Microsoft AzureML. Su amplia adopción la convierte en un caso de estudio crítico: cualquier cambio en su licencia tiene consecuencias en cadena para miles de proyectos que dependen de ella.

La LGPL y por qué no puedes relicenciar sin permiso

La GNU Lesser General Public License (LGPL) v2.1 es una licencia de software libre con naturaleza copyleft. Esto significa que, si bien permite la integración con proyectos propietarios mediante enlace dinámico (dynamic linking), impone reglas claras sobre las modificaciones:

Cualquier obra derivada basada en el código LGPL debe mantenerse bajo la misma licencia.
El código fuente de la parte LGPL debe estar disponible públicamente.
Los usuarios deben conservar el derecho a reenlazar (relinking) contra versiones modificadas de la librería.

Lo más relevante aquí es que la LGPL no incluye una cláusula que permita el relicenciamiento unilateral a una licencia más permisiva como MIT. Para hacerlo de forma legítima, se requiere el consentimiento expreso de todos y cada uno de los titulares de derechos de autor del código. Cada contribución al repositorio es una cesión de derechos independiente, y violar esto puede derivar en demandas por infracción de copyright o incumplimiento contractual.

Qué ocurrió en chardet 7.0.0

Con el lanzamiento de la versión 7.0.0, los mantenedores de chardet actualizaron los metadatos en PyPI para reflejar la licencia MIT, eliminando las obligaciones de la LGPL. El argumento principal fue que la carga de la LGPL dificultaba la adopción en proyectos con licencias permisivas (Apache, BSD) o código propietario.

Sin embargo, en el issue #327 de GitHub, contribuidores históricos del proyecto denunciaron que jamás dieron su consentimiento para el cambio. Los mantenedores sostuvieron que habían contactado a los contribuidores y que los no respondientes se consideraban implícitamente de acuerdo, un argumento que no tiene respaldo legal sólido. El historial de git blame se convirtió en evidencia directa de qué fragmentos de código pertenecen a qué autores, y algunos de esos autores reclamaron públicamente sus derechos.

El resultado: discusiones sobre forks del proyecto bajo LGPL, advertencias en ecosistemas de packaging de Python y un debilitamiento de la confianza en los mantenedores.

Precedentes en disputas de licencias open source

Este tipo de conflicto no es nuevo. La historia del software libre está marcada por casos que sirven como referencia:

BusyBox vs. múltiples empresas (años 2000): Las demandas por violaciones de la GPL demostraron que los derechos de autor por contribución individual son plenamente exigibles.
React.js: de BSD+Patents a MIT (2017): Facebook logró relicenciar con éxito gracias a un proceso de consulta amplio y un Contributor License Agreement (CLA) previo que simplificó el proceso.
Intento fallido de relicenciamiento de Nginx: Fue abandonado ante el rechazo de contribuidores, demostrando que sin consenso total, el proceso no puede avanzar.
MySQL y Oracle: El descontento post-adquisición generó el fork MariaDB, que hoy es ampliamente adoptado.

El patrón es claro: las relicencias sin CLA previo y sin consentimiento explícito son una bomba de tiempo.

Implicaciones prácticas para founders y equipos tech

Si estás construyendo un producto, una startup o contribuyendo a proyectos open source, este caso tiene lecciones directas y aplicables:

1. Define la gobernanza de licencias desde el día cero

No esperes a que tu proyecto tenga mil contribuidores para pensar en esto. Implementa un Contributor License Agreement (CLA) desde el inicio. Herramientas como CLA Assistant (gratuita y open source) automatizan este proceso directamente en GitHub.

2. El historial de Git es evidencia legal

Cada commit en tu repositorio puede ser rastreado hasta su autor. Si alguien contribuyó bajo una licencia específica, esa contribución retiene esos derechos de autor aunque el código sea refactorizado posteriormente. La discusión sobre si una «reescritura completa» elimina los derechos de los autores originales es un área gris que los tribunales aún debaten.

3. LGPL puede ser un obstáculo para la tracción comercial

Varios proyectos importantes como Requests y herramientas de Microsoft buscaron alternativas a chardet precisamente por sus obligaciones LGPL. Si tu librería o producto open source aspira a integración empresarial amplia, evalúa desde el principio si licencias como MIT, Apache 2.0 o BSD se alinean mejor con tu modelo de negocio.

4. La transparencia genera confianza (y el silencio la destruye)

El error más costoso en el caso chardet no fue técnico, sino de comunicación y proceso. Asumir que «quién no responde, consiente» es una práctica que puede costar demandas y la reputación del proyecto. La comunidad open source valora el proceso tanto como el resultado.

¿Qué pasa si dependes de chardet en tu stack?

Si tu proyecto o producto usa chardet como dependencia, aquí tienes un mapa de acción:

Audita tu uso actual: Determina si tu integración cae bajo las obligaciones LGPL (modificación directa vs. enlace dinámico).
Evalúa alternativas: charset-normalizer es hoy la alternativa más popular, permissive-licensed y recomendada por el equipo de Requests. La librería httpx ya migró hacia ella.
Monitorea el issue #327: La resolución legal puede tomar tiempo. Si el caso escala judicialmente, usar la versión 7.0.0 de chardet podría exponerte a riesgo legal si los reclamantes tienen éxito.
Documenta tu decisión: Si decides quedarte con chardet 7.x, documenta internamente el razonamiento legal para transparencia con inversores y due diligence futuros.

Conclusión

El caso chardet es una advertencia concreta para todo el ecosistema tech: las licencias de software libre no son un formalismo burocrático, son contratos con consecuencias reales. Ignorar los derechos de los contribuidores originales puede destruir la reputación de un proyecto, fragmentar comunidades y exponer a quienes adoptan el software a riesgos legales significativos.

Como founder o líder técnico, la gobernanza de licencias es una decisión estratégica de primer orden. Implementar un CLA, elegir la licencia adecuada al modelo de negocio y comunicar cambios con transparencia absoluta no son extras opcionales: son parte de construir un proyecto tecnológico sostenible y confiable.

El código es tuyo. Los derechos de tus contribuidores, también suyos. Respeta esa línea desde el inicio.

Profundiza estos temas con nuestra comunidad de founders y expertos en tecnologia open source

Unirse gratis