¿Cómo quitar la licencia de código abierto?

0 visualizaciones
1. Elimina el archivo LICENSE del repositorio raíz para el cese técnico de la licencia. 2. Comprende que las licencias de código abierto son perpetuas para las versiones ya distribuidas. 3. Obtén el consentimiento de todos los colaboradores que posean derechos de autor sobre el código. 4. Identifica y reemplaza dependencias con licencias restrictivas como GPL. 5. Transiciona a un modelo de licencia dual o 'Open Core' para proteger futuras versiones.
Comentario 0 me gusta

¿Cómo quitar la licencia de código abierto de un proyecto?

Quitar una licencia de código abierto implica mucho más que borrar un archivo, ya que estas licencias suelen ser perpetuas e irrevocables para las versiones que ya han sido distribuidas. Para realizar este cambio de forma legal y efectiva, es necesario obtener el consentimiento de todos los colaboradores originales y evaluar cuidadosamente las dependencias de terceros para evitar conflictos de propiedad intelectual al transicionar a un modelo propietario.

¿Qué implica realmente quitar una licencia de código abierto?

Saber cómo quitar la licencia de código abierto de un proyecto puede parecer una tarea puramente técnica, como borrar un archivo de texto, pero en realidad es un proceso que involucra múltiples capas legales. Esta acción suele estar motivada por el deseo de comercializar el software o cambiar a un modelo de licencia dual. Sin embargo, borrar el archivo LICENSE no soluciona el compromiso legal adquirido previamente: la licencia original sigue vinculada a las versiones del código que ya fueron descargadas o utilizadas por terceros.

Aproximadamente el 80% de los repositorios públicos en plataformas de desarrollo carecen de una licencia clara,[1] lo que genera un limbo legal donde el código es público pero no necesariamente libre de usar. Si tu proyecto ya tiene una licencia, como la MIT o la GPL, eliminarla no borra los derechos que ya otorgaste a quienes descargaron el código antes del cambio. Pero hay un detalle técnico y legal crítico que la mayoría de los desarrolladores pasan por alto al intentar cerrar su código - lo explicaré en profundidad en la sección sobre la irrevocabilidad más adelante.

Pasos técnicos para eliminar el archivo de licencia en GitHub

Desde una perspectiva estrictamente técnica, eliminar la licencia es sencillo si tienes permisos de administrador en el repositorio. El archivo suele llamarse LICENSE, LICENSE.txt o estar embebido en el README.

Procedimiento en la interfaz web

Para eliminar archivo de licencia github directamente desde el navegador, sigue estos pasos: 1. Navega a la raíz de tu repositorio. 2. Haz clic en el archivo LICENSE. 3. Selecciona el icono del bote de basura (Delete file) en la esquina superior derecha. 4. Escribe un mensaje de commit explicando el cambio (por ejemplo, Remove open source license for transition to proprietary). 5. Haz clic en Commit changes.

He visto a muchos desarrolladores - y yo mismo cometí este error al principio - pensar que con esto el código ya es privado. No. Solo has quitado la etiqueta. Si el repositorio sigue siendo público, cualquiera puede seguir viendo el código, aunque ahora no tengan permiso explícito para usarlo, lo cual es el peor escenario para un usuario: ver pero no poder tocar.

La trampa legal: Por qué no puedes borrar el pasado

Aquí es donde resolvemos el misterio mencionado al inicio sobre cómo revocar licencia código abierto: la irrevocabilidad. Las licencias de código abierto más populares, como la MIT (utilizada en casi el 45% de los proyectos licenciados) y la Apache 2.0, están diseñadas para ser perpetuas. Esto significa que una vez que publicaste una versión bajo esos términos, no puedes quitarles la licencia a quienes ya la obtuvieron.

Imagina que liberaste la versión 1.0 como código abierto. Si mañana decides que la versión 2.0 será privada y quitas la licencia del repositorio, cualquier persona que tenga una copia de la versión 1.0 puede seguir usándola, modificándola y distribuyéndola bajo los términos originales. No existe un botón de pánico legal que retire los permisos de forma retroactiva. Es definitivo.

Rara vez he visto a una empresa lograr cerrar un proyecto exitosamente sin enfrentar críticas o bifurcaciones (forks). Si el software es lo suficientemente útil, la comunidad simplemente tomará la última versión abierta y seguirá desarrollándola por su cuenta. Seamos honestos: si intentas quitar la licencia para cobrar por algo que antes era gratis, prepárate para perder a tu comunidad más activa en cuestión de horas, asumiendo así las consecuencias de quitar licencia de software.

Cómo transicionar correctamente a un modelo propietario

Si tu objetivo es dejar de ofrecer nuevas versiones como código abierto, el camino correcto no es solo borrar un archivo, sino cambiar la estrategia de publicación. La mayoría de las empresas que logran cambiar licencia open source a comercial de forma exitosa utilizan el modelo de núcleo abierto (open core).

Reescritura de dependencias críticas

Si tu código utiliza librerías bajo licencias copyleft como la GPL, estás obligado a mantener tu código abierto si lo distribuyes. Para eliminar licencia gpl repositorio y realizar la transición en tu proyecto principal, primero debes identificar y reemplazar cada una de estas dependencias por alternativas comerciales o licencias permisivas. Este proceso suele incrementar el tiempo de desarrollo de manera significativa debido a la necesidad de refactorizar módulos enteros para evitar la contaminación de la licencia original.

Recuerdo un proyecto en el que trabajé donde tuvimos que reescribir todo el módulo de red porque dependía de una librería GPL que no permitía el cambio a una licencia comercial cerrada. Mis manos estaban entumecidas después de tres días de refactorización intensa, pero era la única forma legal de proteger el producto final. Fue una lección cara sobre la importancia de elegir bien desde el primer día.

Consideraciones sobre la propiedad intelectual y colaboradores

Otro obstáculo gigante es la autoría. Si tu proyecto recibió contribuciones de otros desarrolladores (pull requests), tú no eres el único dueño del código. Cada colaborador posee los derechos de autor de sus líneas de código. Para quitar la licencia y hacer el proyecto privado o comercial, necesitarías el permiso explícito de cada persona que haya aportado al repositorio.

Sin un Acuerdo de Licencia de Colaborador (CLA) firmado previamente, cambiar la licencia de un proyecto comunitario es casi imposible legalmente. Por eso, muchos proyectos grandes que intentan cambiar sus términos terminan teniendo que reescribir todas las partes que fueron aportadas por terceros. Es un trabajo monumental que a menudo no vale la pena.

Modelos de Licencia y su Facilidad de Cambio

No todas las licencias se comportan igual cuando intentas retractarte o cambiar el modelo de negocio. Aquí comparamos las tres categorías principales.

Licencias Permisivas (MIT, BSD)

- Muy sencillo; permiten cerrar el código derivado sin problemas legales.

- Moderado; la comunidad puede bifurcar si el autor original se vuelve restrictivo.

- Totalmente permitido, ideal para startups que buscan inversión.

Licencias Copyleft (GPL, AGPL)

- Extremadamente difícil; obliga a que todo código derivado sea también abierto.

- Muy alto; estas licencias están diseñadas para evitar que el software se cierre.

- Permitido, pero el código fuente debe estar disponible para los usuarios.

⭐ Licencia Dual (Open Core)

- Nativo; el autor mantiene una versión libre y vende una versión con extras.

- Bajo, siempre que la versión gratuita siga recibiendo actualizaciones críticas.

- Optimizado para generar ingresos mientras se mantiene la adopción gratuita.

Si tu intención es mantener la flexibilidad para cerrar el código en el futuro, las licencias permisivas como MIT son la opción pragmática. Las licencias GPL actúan como un 'candado' de libertad que es casi imposible de quitar una vez que el proyecto escala con múltiples colaboradores.

El dilema de Carlos: De script útil a producto SaaS

Carlos, un desarrollador independiente en Valencia, publicó una herramienta de automatización en GitHub bajo licencia MIT en 2024. El proyecto ganó tracción rápidamente, alcanzando 2.000 estrellas y varios colaboradores externos en pocos meses.

Cuando Carlos decidió convertirlo en un SaaS de pago, simplemente borró el archivo LICENSE del repositorio pensando que eso invalidaba el uso gratuito. Sin embargo, una empresa local siguió usando su código base para un producto competidor, citando la versión que descargaron antes del borrado.

Tras consultar con un experto, Carlos comprendió que no podía revocar los derechos ya otorgados. Su frustración fue enorme al darse cuenta de que su 'limpieza' no tenía valor legal retroactivo.

La solución final fue crear la versión 2.0 desde una rama privada, reescribiendo el 40% de las funciones clave aportadas por otros y publicándola bajo una licencia comercial, manteniendo la v1.0 como un legado comunitario que ya no actualiza.

Preguntas complementarias

¿Puedo borrar el archivo LICENSE de GitHub y que nadie más use mi código?

Puedes borrarlo, pero eso no afecta a quienes ya descargaron el código bajo esa licencia. Además, si el repositorio sigue siendo público, la gente puede verlo, pero al no tener licencia, quedan en una zona gris donde legalmente no pueden usarlo, lo que suele ahuyentar a los usuarios legítimos pero no a los infractores.

¿Qué pasa si cambio la licencia de MIT a GPL?

Puedes hacerlo para las nuevas versiones de tu código, pero la versión anterior seguirá siendo MIT perpetuamente. Los cambios de licencia solo afectan al código que publiques a partir del momento del cambio.

¿Necesito permiso de los colaboradores para quitar la licencia?

Sí, absolutamente. A menos que hayan firmado un CLA transfiriéndote los derechos, cada colaborador es dueño de su aporte. Sin su permiso, no puedes cambiar los términos de las partes del código que ellos escribieron.

Evaluación final

La revocación no es retroactiva

Borrar una licencia solo afecta a las versiones futuras; las copias distribuidas anteriormente mantienen sus derechos originales para siempre.

Cuidado con las dependencias copyleft

Si usas librerías GPL, no puedes cerrar tu código sin antes reemplazarlas, lo que puede aumentar el trabajo de desarrollo hasta en un 50%.

Si antes de tomar una decisión drástica quieres repasar conceptos legales básicos, te sugerimos revisar qué quiere decir licencia de código abierto.
Los colaboradores son co-dueños

Sin un acuerdo legal previo, necesitas el consentimiento de cada persona que haya enviado un pull request para cambiar la licencia del proyecto.

El modelo Open Core es más seguro

Es mejor mantener un núcleo abierto y añadir capas comerciales privadas que intentar cerrar un proyecto que ya nació como 100% abierto.

Fuentes Citadas

  • [1] Github - Aproximadamente el 80% de los repositorios públicos en plataformas de desarrollo carecen de una licencia clara.