Código de GitHub en un producto comercial: licencias y qué comprobar

Estás desarrollando un producto y encuentras algo listo para usar en GitHub: una biblioteca, una plantilla, un proyecto entero que hace exactamente lo que necesitas. Claude te sugiere incorporarlo a tu proyecto. Entonces te paras a pensar: el código parece estar disponible públicamente, pero ¿puedes usarlo de verdad, y mucho menos vender un producto que lo incluya? ¿Podría el autor reclamarte algo más adelante?

Lo explicaré en orden: por qué el código abierto en GitHub no implica por sí solo una autorización, qué licencias te permiten usar código y vender un producto, qué condiciones copyleft pueden exigir fuente correspondiente de una obra cubierta y cómo comprobar una licencia en un minuto antes de usar el código. Sin «depende de la situación».

En la documentación encontrarás información práctica sobre cómo trabajar con Ailoot.

¿Es cierto que, si un código está en GitHub, puedes usarlo gratis?#

La principal trampa aquí es la palabra «abierto». Puedes ver el código fuente y parece que, como no está oculto, tienes permiso para usarlo. Ese razonamiento es erróneo. «Abierto para leer» y «con licencia para usar» son cosas distintas.

Por defecto, toda obra creativa, incluido el código, está protegida por derechos de autor desde el momento en que se crea. Hasta que el autor conceda permiso explícitamente, no puedes usarla. Así lo describe GitHub en su propia página de referencia sobre licencias.

La segunda parte es el propio GitHub. Hay quien piensa que, por haber aceptado las reglas de GitHub al publicar código, también puede usar el código de otras personas que encuentra allí. Las reglas dicen exactamente lo contrario. Al hacer público un repositorio, el autor solo permite a los demás verlo y hacer un fork, es decir, crear una copia dentro del propio GitHub. Eso no autoriza a usar el código en tu propio trabajo.

Las palabras clave están en la última frase: «dentro de las funciones de GitHub» y «los derechos adicionales se conceden mediante una licencia». Un fork permanece dentro de GitHub. En cuanto quieras usar el código en tu propio producto, y más aún venderlo, necesitas una licencia independiente del autor. Sin licencia, no hay derecho, aunque el código esté a la vista de todos.

¿De qué depende que puedas usar el código de otra persona?#

Todo se reduce a un archivo. Un repositorio bien mantenido incluye un archivo de licencia, normalmente llamado LICENSE, a veces LICENSE.md, o una mención directamente en el README. Es el permiso del autor y establece las condiciones en las que puedes usar el código. GitHub suele mostrar el nombre de la licencia en la barra lateral de la página del repositorio, incluso antes de que abras el archivo.

Para no perderte en el lenguaje jurídico, conviene leer la licencia planteándote tres preguntas sobre tu situación:

1. ¿Puedes usar este código en un producto comercial por el que la gente paga?
2. ¿Puedes modificar el código para adaptarlo a tus necesidades?
3. ¿Tienes que abrir después el código fuente de tu producto, o puedes mantenerlo cerrado?

Casi todas las diferencias entre licencias se reducen a distintas respuestas a la tercera pregunta. A las dos primeras, las licencias abiertas más populares suelen responder «sí»: úsalo, modifícalo, véndelo. El tropiezo llega al averiguar si la licencia te obligará a abrir tu propio código. A continuación repasaremos los tipos principales con estas tres preguntas.

¿Qué licencias te permiten usar código y vender un producto?#

Empecemos con una buena noticia. Para quien desarrolla un producto para vender, la mejor opción es un grupo de licencias llamadas permisivas. Hay varias, pero tres son las más comunes: MIT, Apache 2.0 y BSD. Las tres responden «sí» a las dos primeras preguntas y te permiten mantener cerrado tu propio código fuente.

La más común y sencilla es MIT. Su texto cabe en un solo párrafo.

En términos más sencillos, MIT te permite hacer casi cualquier cosa con el código, incluso vender el producto y mantener cerrado tu propio código fuente. La única obligación es incluir el texto de la licencia y la línea de atribución. Babel, .NET y Rails, por ejemplo, se publican bajo MIT, así que casi seguro que ya has usado código con esta licencia.

Apache 2.0 funciona de forma parecida, pero añade dos puntos importantes. Primero, una protección explícita frente a reclamaciones de patentes: los autores del código se comprometen a no demandarte por patentes relacionadas con ese código. Segundo, algunos requisitos formales adicionales para su uso.

BSD (en sus versiones de 2 y 3 cláusulas) es básicamente similar a MIT: usar, modificar, vender y conservar el aviso de derechos de autor. He reunido las tres en una tabla para que veas la diferencia de un vistazo.

Cómo interpretar esto en tu caso: si el código de otra persona tiene una licencia MIT, Apache 2.0 o BSD, puedes estar tranquilo: puedes usarlo en un producto comercial, modificarlo y mantener cerrado tu propio código fuente. Solo tienes que evitar eliminar el archivo de licencia y la atribución de la parte que has usado.

¿Cómo se aplican las obligaciones de código fuente de GPL y AGPL?#

El copyleft mantiene una obra cubierta y sus derivadas bajo la misma licencia cuando se cumplen las condiciones pertinentes. Con GPLv3, distribuir copias de fuente u objeto de una obra cubierta o derivada combinada exige cumplir licencia y obligaciones de fuente correspondiente. No se aplica automáticamente a todo programa independiente del mismo producto o servidor.

En el ejemplo del servicio web, alojar una biblioteca GPL en tu servidor sin entregar copias no exige por sí solo publicar todo el servicio. Distribuir una aplicación combinada cubierta a clientes puede activar obligaciones GPL: revisa integración y licencia antes de decidir qué fuente debe acompañarla. Un cliente de navegador entregado a usuarios plantea una distribución separada.

AGPLv3 añade una condición de red: si modificas el programa y los usuarios interactúan remotamente con esa versión, debe ofrecerles de forma visible su fuente correspondiente. Es más preciso que decir que alojar cualquier componente AGPL abre todas las partes independientes del servicio.

Para un producto propietario, examina la obra cubierta, la combinación de componentes, si se distribuyen copias y si se aplica interacción de red AGPL. Elige una alternativa permisiva compatible u obtén permiso separado si no puedes cumplir las obligaciones. El uso comercial está permitido; la cuestión es cumplir la licencia y la integración reales.

¿Qué debes hacer si el repositorio no tiene ningún archivo de licencia?#

Un error común es suponer que, si no hay licencia, no hay restricciones y puedes usar el código libremente. Es justo lo contrario. No tener licencia no significa tener permiso; por defecto, significa que no hay permiso. El código sin licencia sigue protegido por todos los derechos de autor de su autor y no puedes tocarlo.

Se vuelve a aplicar la regla que vimos al principio: por defecto, el código está protegido por derechos de autor y, sin permiso explícito, no puedes copiarlo, modificarlo ni distribuirlo. Poder verlo y hacer un fork dentro de GitHub no supera esa barrera ni te concede el derecho a utilizar el código en tu propio producto.

Qué hacer en la práctica si el código no tiene licencia pero realmente lo necesitas:

1. Escribe al autor. Pregunta directamente en la sección de debates del repositorio o por correo electrónico si puedes usar el código y bajo qué condiciones. A veces el autor simplemente olvidó añadir una licencia y la añadirá si se lo pides.
2. Busca un reemplazo. Para casi cualquier tarea hay un segundo, un tercero y un décimo repositorio similar: encontrarás alguno que tenga una licencia MIT o Apache adecuada.
3. No lo uses. Si no tienes permiso y no hay reemplazo, el código no es tuyo y no puedes incluirlo en un producto que piensas vender. La tentación de pensar «¿quién se va a enterar?» acaba mal justo cuando el producto empieza a generar ingresos y a llamar la atención.

¿Y si Claude añadió al proyecto el código de otra persona?#

Aquí hay otra dimensión que es fácil confundir con la primera. Una cosa es visitar un repositorio y copiar un archivo: en ese caso, todo lo explicado anteriormente sobre la licencia es una obligación directa para ti. Otra es que Claude escriba código para ti como respuesta a una petición.

En los casos habituales, la IA produce texto propio, compuesto para tu tarea, en lugar de copiar el archivo de otra persona. Entonces la cuestión pasa a otro ámbito: ¿quién es titular del código generado y puedes venderlo? Es un tema amplio por sí mismo, que traté en un artículo sobre quién es titular del código escrito por IA.

Pero hay una excepción que conviene tener presente. A veces, la IA genera casi palabra por palabra una parte reconocible del código de otra persona, como una función entera de una biblioteca conocida. En ese caso, la licencia de la biblioteca sigue aplicándose, independientemente de quién haya pulsado las teclas. Por eso, debes comprobar los grandes bloques listos para usar que Claude haya incorporado íntegramente, igual que si los hubieras copiado tú.

Cómo comprobar una licencia antes de usar código: pasos que debes seguir#

Resumamos todo en una breve lista de comprobación para revisar cualquier código de terceros antes de incorporarlo a tu proyecto. Sigue los pasos de arriba abajo.

1. Busca el nombre de la licencia en la página del repositorio

   Abre el repositorio en GitHub. El nombre de la licencia suele aparecer en la columna de la derecha o debajo de la lista de archivos; por ejemplo, «MIT License», «Apache-2.0» o «GPL-3.0». Si no aparece nada y no hay archivo de licencia, ya es una señal de alerta; vuelve a comprobarlo en el último paso.

2. Abre el propio archivo de licencia

   Busca LICENSE, LICENSE.md o COPYING en la lista de archivos y ábrelo. Asegúrate de que el nombre coincida con lo que aparece en la barra lateral y de que la licencia se aplique al código que vas a usar, no solo a una parte separada del repositorio.

3. Identifica el tipo: permisiva o copyleft

   MIT, Apache 2.0 y BSD son permisivas; puedes usar el código en un producto comercial cerrado. GPL y AGPL son copyleft: revisa obra cubierta, distribución y condición de red AGPL antes de determinar obligaciones de fuente. El nombre no establece qué componentes independientes quedan cubiertos.

4. Compárala con tu situación

   Responde a tres preguntas: ¿vendes el producto?, ¿modificas el código?, ¿quieres mantener cerrado el código fuente? MIT, Apache y BSD son adecuadas para un producto cerrado que se vende. Para GPL y AGPL, determina qué obra cubierta o combinada necesita fuente correspondiente y cuándo se activa la obligación; evalúa si puedes cumplirla.

5. Si no hay licencia, no lo uses

   Si no hay archivo de licencia y el README no dice nada sobre los permisos, no puedes usar el código. Escribe al autor para pedir permiso o busca un equivalente con una licencia adecuada. «Está disponible públicamente» no significa que tengas permiso.

Esta comprobación parece tediosa hasta la primera vez que tu producto crece, empieza a generar ingresos y alguien pregunta por el código de terceros que contiene. Dedicar dos minutos al principio cuesta menos que afrontar una disputa más adelante. En otro artículo explico qué hacer después con tu producto para que no se estanque tras el lanzamiento: He creado un producto con IA; ¿qué viene después?.

Abrir Ailoot.