Licencias de software de IA y open source explicadas: MIT vs Apache vs GPL vs AGPL vs propietaria

Datos rápidos

• MIT es la licencia permisiva más corta y común — unas 170 palabras, sin cláusula de patentes.
• Apache-2.0 añade una concesión de patente explícita que MIT no tiene, por lo que muchas empresas la prefieren para proyectos de origen corporativo.
• GPL exige divulgar el código fuente solo al distribuir el software; AGPL-3.0 extiende esa exigencia a ejecutarlo como servicio de red.
• El "open source" aprobado por la OSI es una certificación concreta de la Open Source Initiative; "source-available" y "fair-code" son términos de marketing para licencias que no cumplen esa definición.
• Las licencias de modelos de IA son una categoría aparte de las licencias de código. El código de una herramienta puede ser Apache-2.0 mientras que los pesos del modelo que descarga llevan condiciones totalmente distintas, a menudo más restrictivas.

¿Qué son las licencias permisivas? MIT, Apache-2.0 y BSD

• La licencia MIT se originó en el Massachusetts Institute of Technology como forma de liberar software desarrollado en la universidad con restricciones mínimas. Tiene unas 170 palabras, otorga derechos casi ilimitados y solo pide que el texto original de copyright y licencia se mantenga en cualquier copia o parte sustancial que redistribuyas.
• La Apache License 2.0 proviene de la Apache Software Foundation, creada para dar a colaboradores corporativos y comunitarios un marco legal común para proyectos colaborativos grandes. A diferencia de MIT, incluye una concesión de patente explícita — los colaboradores otorgan a los usuarios sus derechos de patente sobre el código — por lo que muchas empresas con carteras de patentes la prefieren.
• Las licencias BSD (de 2 y 3 cláusulas) se originaron en la Universidad de California en Berkeley para el sistema operativo Berkeley Software Distribution. La variante de 3 cláusulas añade una cláusula de no aprobación que impide usar el nombre de los autores originales para promocionar un producto derivado sin permiso.
• Efecto práctico para quien la adopta: puedes hacer fork, modificar, incorporar y vender una herramienta con licencia permisiva como parte de un producto cerrado sin publicar nunca tu propio código fuente — el único riesgo real es omitir el aviso de copyright/licencia requerido en tu distribución.
• Ejemplos reales de las reseñas de este sitio: Ollama y llama.cpp usan MIT; vLLM usa Apache-2.0 — las tres se pueden incorporar en un producto comercial sin generar ninguna obligación de divulgar el código fuente.

¿Qué es el copyleft? La familia GPL y LGPL

• La GNU General Public License (GPL) fue escrita por Richard Stallman y la Free Software Foundation como licencia del Proyecto GNU, basada en la idea de que la libertad del software debe preservarse hacia adelante — quien reciba una copia modificada debe tener los mismos derechos que el autor original.
• GPL v2 y GPL v3 difieren sobre todo en el lenguaje sobre patentes y las disposiciones de compatibilidad; la v3 añadió cláusulas explícitas de represalia por patentes y anti-tivoización (para impedir hardware que bloquee ejecutar software modificado que tienes derecho legal a ejecutar).
• La GNU Lesser General Public License (LGPL) relaja GPL específicamente para bibliotecas — puedes enlazar una biblioteca LGPL en una aplicación propietaria sin abrir el código de la aplicación en sí, siempre que el componente de biblioteca siga siendo intercambiable y su propio código fuente esté disponible.
• Lo que realmente activa la obligación: distribuir una copia modificada del código cubierto por GPL. Usar internamente software GPL sin modificar, o ejecutar software propietario sobre un sistema operativo con licencia GPL, no somete por sí solo tu propio código a GPL.
• Quién debe tener cuidado: una startup que planee hacer fork y modificar una herramienta GPL como núcleo de un producto comercial necesita un plan — abrir esas modificaciones o evitar el fork; una empresa que solo ejecuta internamente una herramienta GPL sin modificar no tiene esa obligación.

Cómo AGPL-3.0 cierra el vacío del SaaS

• El vacío que cierra: bajo GPL sola, ejecutar una versión modificada como servicio web alojado no constituye "distribución" en el sentido legal que activa la licencia — una empresa podía tomar código GPL, modificarlo, ofrecerlo solo como producto SaaS, y nunca tener que liberar las modificaciones. Esto se conoció informalmente como el "vacío ASP" (application service provider) o "vacío SaaS".
• AGPL-3.0 se escribió específicamente para cerrar ese vacío añadiendo una cláusula de interacción por red: ofrecer la funcionalidad del software modificado a usuarios a través de una red activa la misma obligación de disponibilidad de código fuente que distribuir una copia física.
• Por qué importa para el hosting y la reventa: una agencia o proveedor de hosting que toma una herramienta con AGPL, la modifica y la ofrece a clientes como servicio alojado debe poner el código fuente modificado a disposición de esos usuarios — ejecutarla sin modificar no genera esa obligación.
• Ejemplos reales de las reseñas de este sitio: Jan, KoboldCpp, SillyTavern y text-generation-webui usan AGPL-3.0 — sin problema para autohospedaje sin modificar para uso personal o interno; la situación cambia radicalmente en cuanto modificas una y revendes acceso alojado a ella.
• Esto es una explicación general de cómo funciona el mecanismo de la licencia, no asesoría legal — si un despliegue concreto cuenta como "ofrecerlo a través de una red" según el texto exacto de AGPL-3.0 es una pregunta para un abogado que revise tu arquitectura específica.

¿Qué son las licencias source-available y "fair-code"?

• La Business Source License (BSL, también llamada BUSL) otorga desde el inicio acceso al código fuente y amplios derechos de uso, con una fecha futura definida en la que la licencia se convierte en una licencia genuinamente open source (a menudo Apache-2.0 u otra licencia permisiva similar) — hasta esa conversión, aplica una restricción declarada de uso comercial, dirigida típicamente a impedir una oferta alojada competidora.
• La Server Side Public License (SSPL), creada por MongoDB, exige que quien ofrezca el software como servicio también libere como open source toda la pila de servicio construida a su alrededor — una obligación mucho más amplia que la de AGPL-3.0, escrita deliberadamente para hacer impráctico el hosting comercial por parte de un proveedor cloud rival.
• La Commons Clause es una restricción adicional superpuesta a una licencia base por lo demás permisiva o copyleft, que prohíbe específicamente vender el software u ofrecerlo como servicio alojado de pago, mientras sigue permitiendo el uso y la modificación libres.
• Por qué algunos proyectos migran a estas licencias: un proyecto que empieza bajo una licencia totalmente abierta y luego adopta una source-available suele estar respondiendo a un gran proveedor cloud que ofrece el proyecto como servicio alojado sin contribuir de vuelta — migrar a una licencia source-available permite al mantenedor conservar la mayor parte de la apertura mientras bloquea ese uso competidor concreto.
• Efecto práctico para quien la adopta: normalmente puedes leer, autohospedar y modificar software source-available para uso interno sin problema; la restricción actúa cuando intentas revenderlo como producto alojado que compite con la oferta del titular de la licencia — lee la cláusula concreta de uso comercial, ya que la redacción varía mucho entre proyectos.

¿Qué significan las licencias propietarias y freemium "gratis"?

• "Gratis (cerrado)" en una tabla comparativa significa software propietario sin costo. Puedes usar la aplicación compilada según los términos de servicio del proveedor, pero no tienes acceso al código fuente ni derecho a modificarlo, auditarlo o hacer fork.
• El compromiso principal frente a alternativas open source: una app gratuita propietaria suele ser más pulida y fácil de instalar, ya que un único proveedor controla toda la experiencia — pero dependes por completo de su disposición continuada a mantenerla gratis, segura y actualizada.
• Riesgo de dependencia del proveedor (vendor lock-in): sin acceso al código fuente, no puedes autohospedar una versión modificada, auditar exactamente qué hace la aplicación con tus datos, ni continuar el desarrollo si el proveedor deja de mantenerla, cambia el modelo de precios o cierra.
• Quién debe prestar más atención: cualquiera que construya un flujo de trabajo o proceso de negocio alrededor de una herramienta gratuita propietaria debería tener un plan de respaldo documentado — la misma diligencia que aplicarías a cualquier dependencia de proveedor, porque "gratis" no significa "permanente" ni "garantizado".
• No es lo mismo que source-available: las licencias source-available (BSL, SSPL) al menos permiten leer y auditar el código aunque el uso comercial esté restringido; una herramienta totalmente propietaria no ofrece ni el código ni esas garantías.

¿Cómo funcionan las licencias de modelos de IA? Open weights, RAIL y restricciones de uso

• Pesos totalmente permisivos: algunas familias de modelos publican sus pesos bajo una licencia de software permisiva estándar (habitualmente Apache-2.0), otorgando los mismos derechos amplios de uso que esa licencia da al código, incluido el uso comercial sin restricción de ámbito.
• Las licencias RAIL y OpenRAIL (Responsible AI License) surgieron con el lanzamiento del modelo BLOOM por parte de BigScience y se diseñaron junto con investigadores legales para combinar acceso abierto con una lista concreta de usos prohibidos — normalmente vetando la generación de desinformación, la toma de decisiones discriminatoria o contenido que viole la ley, mientras permiten un uso comercial amplio por lo demás.
• Licencias "comunitarias" o "open-weight" a medida: varios proveedores importantes de modelos publican sus pesos bajo una licencia hecha a medida que se lee como una licencia abierta pero añade condiciones de ámbito de uso. El ejemplo más citado es la licencia comunitaria que Meta adjunta a los pesos de modelo que publica abiertamente, que otorga uso gratuito amplio pero añade un umbral de escala de uso por encima del cual se requiere un acuerdo comercial aparte, junto con restricciones de uso aceptable.
• Qué revisar específicamente: si el uso comercial está permitido en absoluto, si hay un umbral de escala de uso o ingresos que cambia los términos, qué prohíbe la política de uso aceptable, y si la licencia restringe usar las salidas del modelo para entrenar un modelo competidor — una restricción que ha aparecido en varias licencias específicas de modelos y no tiene equivalente en las licencias de software estándar.
• Esto no es asesoría legal — los términos de licencia de los modelos cambian entre lanzamientos del mismo proveedor, así que verifica el texto exacto de licencia adjunto a los pesos de modelo concretos que planeas desplegar en lugar de asumir continuidad con un lanzamiento anterior de la misma organización.

¿A quién le importa cada licencia?

Checklist antes de adoptar una herramienta: 7 puntos a verificar

1. 1
   Lee el archivo LICENSE real del repositorio
   Why it matters: La afirmación "open source" de una landing page puede ser marketing, no un hecho legal — el archivo LICENSE (o NOTICE/COPYING) del repositorio fuente es el documento con autoridad, no una insignia ni una página de precios.
2. 2
   Revisa si la licencia cambió recientemente
   Why it matters: Algunos proyectos migran de una licencia permisiva o copyleft a una source-available tras ganar tracción comercial — este patrón se ha repetido en la industria del software conforme proveedores cloud alojaban proyectos open source populares sin contribuir de vuelta. Revisa el historial de licencia del repositorio, no solo el archivo actual.
3. 3
   Verifica si la licencia está realmente aprobada por la OSI, si eso te importa
   Why it matters: Licencias source-available como BSL y SSPL suelen anunciarse como open source pero no están en la lista aprobada por la Open Source Initiative — si la aprobación de la OSI es un requisito para tu caso de uso, revisa la lista directamente en lugar de confiar en la descripción del proyecto.
4. 4
   Lee las cláusulas de uso comercial y ámbito de uso específicas de modelos de IA
   Why it matters: La licencia de un modelo puede permitir el uso comercial ampliamente, restringirlo por encima de un umbral de escala de uso, o prohibir aplicaciones específicas por completo — estas cláusulas quedan fuera del lenguaje habitual de las licencias de software y son fáciles de pasar por alto si solo revisas la licencia del código.
5. 5
   Determina si autohospedar o alojar como SaaS cambia tus obligaciones
   Why it matters: Bajo AGPL-3.0, ofrecer software modificado a través de una red activa la misma obligación de divulgación que distribuir una copia bajo GPL — confirma en qué categoría cae tu despliegue planeado antes de modificar el código.
6. 6
   Revisa si existe un acuerdo de licencia de colaborador (CLA) si piensas contribuir
   Why it matters: Un CLA puede otorgar al mantenedor del proyecto derechos más amplios sobre tu contribución que los que la propia licencia del proyecto otorga a los usuarios — relevante sobre todo si planeas enviar código de vuelta al proyecto, no si solo lo consumes.
7. 7
   Revisa las restricciones de marca por separado de la licencia del código
   Why it matters: Una licencia de código permisiva o copyleft no otorga automáticamente derechos sobre el nombre o logo del proyecto — hacer fork y renombrar una herramienta puede estar bloqueado por derecho de marca aunque la licencia del código permitiría el fork.

Errores comunes

• Confiar en la afirmación "open source" de una página de marketing en lugar de leer el archivo LICENSE real del repositorio.
• Suponer que AGPL-3.0 solo importa si distribuyes una copia del software — también aplica al ofrecer código modificado como servicio alojado.
• Tratar la licencia del código de un modelo y la licencia de sus pesos como el mismo documento — con frecuencia no lo son.
• Hacer fork y renombrar una herramienta sin revisar las restricciones de marca, separadas de la licencia del código.
• Suponer que una licencia permisiva al inicio de un proyecto sigue aplicando tras una relicenciación posterior — revisa la licencia actual, no la que recuerdas.
• Saltarte la revisión legal de una herramienta copyleft o source-available porque "es gratis" — gratis de usar y libre de obligaciones no son lo mismo.

Fuentes

• Open Source Initiative — The Open Source Definition — la definición formal que una licencia debe cumplir para certificarse como open source por la OSI.
• Proyecto GNU — Free Software Licenses — las explicaciones de la Free Software Foundation sobre GPL, LGPL y AGPL.
• Apache Software Foundation — Apache License 2.0 — texto completo de la licencia.
• Texto de la licencia MIT (Open Source Initiative) — texto completo de la licencia.
• MongoDB — Server Side Public License — términos y justificación propios de la SSPL.
• FAQ de la Business Source License — explicación de cómo funciona la conversión de BSL/BUSL, de un adoptante ampliamente citado de la licencia.

Preguntas frecuentes

Lecturas relacionadas

• El directorio completo de software de LLM local — más de 160 herramientas de LLM local con la licencia de cada entrada.
• Reseña de Dify AI Workflow Builder — una reseña que nombra su licencia; usa esta guía para entender qué significa esa licencia para tu despliegue.
• Contenido generado por IA y riesgo de propiedad intelectual — las cuestiones de propiedad intelectual que acompañan a la licencia cuando despliegas comercialmente salidas generadas por IA.
• Seguridad de la IA agéntica: identidad y acceso — consideraciones de seguridad y gobernanza para despliegues de IA autohospedados, un aspecto complementario al cumplimiento de licencias.
• RAG local compatible con RGPD para documentos sensibles — el riesgo de licencia y el riesgo de residencia de datos/cumplimiento son checklists separadas; esta guía cubre el lado del cumplimiento.