Publicar mis herramientas bajo la Licencia MIT probablemente fue un error (2023)
Los desarrolladores de open source debaten si licencias permisivas como MIT facilitan involuntariamente que oportunistas del SEO y sitios imitadores llenos de anuncios rehosteen herramientas web, a veces superando en ranking y explotando comercialmente a los creadores originales. Muchos argumentan que licencias más estrictas (GPL/AGPL), las marcas registradas o los avisos DMCA ofrecen solo una protección práctica limitada frente a actores maliciosos, y que los autores deben elegir licencias según si realmente aceptan la reutilización sin restricciones, incluso en formas que les desagradan. Otros proponen una separación pragmática: mantener cerrados o bajo copyleft los proyectos emocional o comercialmente importantes, y reservar licencias permisivas para el código que no te importe ver reutilizado sin atribución prominente.
Alcance del problema (clones SEO y monetización)
- Muchos comentaristas repiten la situación: herramientas con licencia MIT están siendo clonadas, modificadas ligeramente, envueltas en anuncios/spam SEO y, a veces, superan en ranking al sitio original.
- Algunos lo ven como frustrante a nivel emocional, pero lógicamente coherente con una licencia permisiva.
- Varios sostienen que “los oportunistas del SEO se aprovecharán de todos modos, independientemente de la licencia”, así que cambiar de licencia puede no resolver el problema de fondo.
Licencia MIT, atribución y aplicación
- Varios comentarios señalan que MIT sí exige conservar el aviso de copyright, pero:
- Solo se aplica cuando el software se distribuye, no cuando simplemente se usa en el lado del servidor.
- La atribución puede quedar enterrada en el código fuente o en archivos; no hay requisito de crédito visible en la interfaz.
- Algunos sugieren avisos DMCA cuando se violan los términos de la licencia; otros dudan de que merezca la pena o de que sea eficaz contra clones de poco esfuerzo.
Copyleft vs permisivas (GPL/AGPL/LGPL/BSD/Apache)
- Un bando: GPL/AGPL o LGPL son mejores opciones cuando quieres que las modificaciones sigan siendo abiertas y desincentivar a los aprovechados.
- Otro bando: incluso AGPL no impediría de forma significativa el comportamiento descrito de SEO/anuncios, ya que basta con un cumplimiento mínimo (enlaces enterrados, pequeños avisos).
- Algunos ven el copyleft como “venenoso” o anti-libertad; otros lo ven como una herramienta necesaria para preservar la apertura y contrarrestar las presiones del mercado.
- Hay desacuerdo sobre con qué frecuencia AGPL realmente disuade a los “parásitos” en la práctica.
Definiciones: “libre” y “open source”
- Un largo subhilo debate quién puede definir “libre” y “open source”.
- Un lado insiste en las definiciones de FSF/OSI (sin discriminación por campo de uso, se permiten anuncios).
- Otros argumentan que el uso del lenguaje común de “free/open” es más amplio y que la gente puede elegir legítimamente términos no-OSI o de “source-available”.
Alternativas: código cerrado, marcas registradas y estrategia de licencias
- Algunos dicen: si no quieres este tipo de reutilización, no hagas open source de la herramienta; mantén algunos proyectos privados y otros con licencias permisivas.
- Se proponen marcas registradas para controlar el uso del nombre y la identidad del proyecto, separadas de la licencia del código.
- Se discute relicenciar; puede ser complicado si hay colaboradores externos.
- Se desaconsejan las licencias CC para código; la gente pide una “CC-BY-like para código”, pero el consenso del hilo es que las licencias de software estándar no se ajustan perfectamente a ese deseo.