¿Qué es un software license agreement?

Un software license agreement, en español un contrato de licencia de software, es un contrato por el que el titular de un programa de ordenador concede a otra parte el derecho a usar ese programa en condiciones definidas, mientras conserva la titularidad del software. El contrato establece para qué puede usarse el software, por cuántas personas o en cuántas máquinas, durante cuánto tiempo, a qué precio y qué ocurre cuando una de las partes quiere salir.

El contrato importa porque el software está protegido por derechos de autor. En Estados Unidos, el titular del copyright ostenta los derechos exclusivos de reproducir una obra, preparar obras derivadas y distribuir copias [1]. Instalar, copiar o adaptar un programa afecta a esos derechos. La licencia es el permiso que hace lícito el uso, y su redacción marca el límite de lo que una empresa puede hacer realmente.

Esa distinción tiene consecuencias. Los tribunales federales de Estados Unidos han sostenido que un usuario de software es licenciatario y no propietario de un ejemplar cuando el titular del copyright concede una licencia, restringe significativamente la transmisión e impone restricciones de uso relevantes. Bajo ese razonamiento, un licenciatario no puede invocar la first sale doctrine ni la excepción de essential step de la section 117, y sus derechos derivan únicamente de los términos de su contrato de licencia [2]. Comprar software y ser propietario de software no son lo mismo.

El mismo instrumento circula con varios nombres, y las diferencias tienen que ver sobre todo con quién firma y hasta qué punto son negociables las condiciones.

Denominación	Qué suele ser
Software license agreement (SLA)	El término general para el contrato que concede derechos de uso
End user license agreement (EULA)	El formulario estándar no negociable que se presenta al instalar o registrarse
Contrato de licencia corporativa o por volumen	Un contrato negociado para una organización que compra a escala
Contrato de suscripción o SaaS (software as a service)	Acceso concedido por un plazo, normalmente alojado por el proveedor
Licencia perpetua	El derecho a ejecutar una versión concreta de forma indefinida, con soporte aparte
Licencia de código abierto	Una licencia pública que concede derechos amplios sujetos a condiciones

Conviene señalar dos trampas terminológicas. Primera: en el ámbito del software asset management, la abreviatura SLA designa el software license agreement [3], mientras que en la mayoría de contextos contractuales SLA significa service level agreement, un documento distinto sobre disponibilidad y tiempos de respuesta. Compruebe a cuál de los dos se refiere la contraparte antes de responder. Segunda: un EULA es un tipo de contrato de licencia de software, no una especie aparte; es la versión estandarizada que se presenta al usuario final [3].

Las licencias de código abierto también son contratos de licencia de software, con una economía poco habitual. Para calificarse como código abierto según la definición de la Open Source Initiative, una licencia debe permitir la redistribución libre, facilitar el código fuente y admitir modificaciones y obras derivadas [4]. Las obligaciones suelen ser de atribución y condiciones de distribución en lugar de pagos, y precisamente por eso se pasan por alto.

Finalidad y usos habituales

El contrato cumple cuatro funciones a la vez. Concede un permiso que la normativa de derechos de autor negaría de otro modo. Limita ese permiso para que el proveedor pueda vender distintos alcances a distintos precios. Reparte el riesgo mediante las cláusulas de garantía, indemnidad y responsabilidad. Y fija el ritmo comercial: qué se paga, cuándo y cómo se renueva o termina la relación.

Situaciones típicas en las que aparece:

• Una empresa se suscribe a un producto SaaS y acepta las condiciones al registrarse.
• Un proveedor y un cliente negocian un contrato corporativo que abarca varios productos y unidades de negocio.
• El software se integra en hardware o se revende a terceros, lo que suele exigir un contrato de distribución o reventa independiente.
• Una desarrolladora licencia una biblioteca de componentes dentro de un producto comercial.
• Un organismo público adquiere software comercial. Las normas federales de contratación de Estados Unidos disponen que el software comercial se adquiera bajo las licencias que habitualmente se ofrecen al público, en la medida en que esas licencias sean compatibles con el derecho federal [5].

Partes del contrato

Hay dos partes designadas y varias más cuya conducta queda regulada por el contrato sin que lo firmen.

El licenciante es titular o controla los derechos sobre el software. Concede la licencia y suele comprometerse a entregar el software, prestar el soporte acordado, defender frente a reclamaciones por infracción de propiedad intelectual y cumplir las obligaciones de protección de datos cuando trata datos del cliente.

El licenciatario recibe el derecho de uso. Sus obligaciones suelen ser pagar las contraprestaciones, mantenerse dentro del alcance licenciado, proteger credenciales e información confidencial, respetar las restricciones de uso y cooperar en la verificación de licencias.

Más allá de las firmas, el contrato suele alcanzar a usuarios autorizados como empleados y colaboradores externos, a sociedades del grupo del licenciatario y, a veces, a clientes finales cuando el licenciatario está autorizado a integrar o revender. El licenciatario sigue siendo normalmente responsable de su cumplimiento. Esa es la cláusula que convierte el descuido de un solo equipo en responsabilidad de la entidad firmante.

Cláusulas y términos clave

Esto es información general sobre cómo se estructuran estos contratos, no asesoramiento jurídico sobre un contrato concreto.

Concesión de licencia. La frase central. Observe si es exclusiva o no exclusiva, perpetua o de plazo limitado, mundial o territorial, transmisible o no, y si se permite la sublicencia.

Alcance y métricas de licencia. Qué se cuenta: usuarios nominales, usuarios concurrentes, núcleos de CPU (central processing unit), dispositivos, entornos, volumen de transacciones o tramo de facturación. La métrica es lo que el proveedor medirá el día de una auditoría.

Restricciones. Las prohibiciones habituales cubren la ingeniería inversa, el benchmarking, compartir accesos fuera del grupo licenciado, el uso como centro de servicios y la retirada de avisos de propiedad.

Propiedad intelectual y titularidad. Confirma que el licenciante conserva la titularidad y regula a quién pertenecen las sugerencias, las configuraciones y los datos o resultados del cliente.

Contraprestaciones, regularización y subidas. Precio, periodicidad de facturación, qué desencadena importes adicionales por uso fuera de alcance y cualquier subida limitada o sin límite en la renovación.

Soporte, mantenimiento y niveles de servicio. A menudo un anexo aparte. Cuando existen compromisos de disponibilidad y tiempos de respuesta, suelen figurar en un service level agreement unido al contrato principal.

Garantías y exclusiones. Qué promete el proveedor que hará el software, durante cuánto tiempo y qué queda expresamente excluido.

Indemnidades. Lo más frecuente es que el licenciante indemnice frente a reclamaciones de terceros por propiedad intelectual y que el licenciatario indemnice frente al uso indebido.

Limitación de responsabilidad. Límites y exclusiones, además de los supuestos en los que el límite no se aplica.

Derechos de auditoría y verificación. El derecho del proveedor a inspeccionar el uso, el preaviso exigido y quién paga las diferencias.

Plazo, renovación y terminación. Se trata más abajo, porque ahí es donde se pierde más dinero en el día a día.

Protección de datos y seguridad. Cuando el proveedor trata datos personales, junto a la licencia suele situarse un contrato de encargo del tratamiento.

Una nota estructural sobre las copias de seguridad. En Estados Unidos, la autorización de copia de archivo de la section 117 corresponde al propietario de un ejemplar, y todas las copias de archivo deben destruirse cuando la posesión continuada deja de ser lícita [1]. En la Unión Europea la posición es distinta: la copia de seguridad realizada por quien tiene derecho a utilizar el programa no puede impedirse por contrato en la medida en que sea necesaria para ese uso, y la primera venta de una copia en la Unión por el titular agota el derecho de distribución de esa copia [6]. La jurisdicción cambia la respuesta, así que lea la cláusula de ley aplicable antes de dar por supuesta una u otra regla.

Fechas importantes y eventos del ciclo de vida

Los contratos de licencia de software se rigen por fechas, y esas fechas rara vez están en el mismo documento que la página de firmas.

• Fecha de efectos e inicio del plazo. A veces la fecha del pedido, a veces el aprovisionamiento, a veces el fin de un piloto.
• Fin del plazo de suscripción o licencia. La fecha en que los derechos decaen si no se hace nada.
• Fecha de renovación automática. La mayoría de contratos de suscripción se renuevan solos salvo preaviso.
• Fecha límite de preaviso de no renovación. El plazo real. Se sitúa semanas o meses antes de la fecha de renovación, y perderlo compromete a la empresa a otro periodo completo.
• Fecha de comunicación de subida de precios. Cuando el proveedor debe anunciar un incremento antes de poder aplicarlo.
• Fechas de regularización o reporte de uso. Conciliación periódica del uso real frente a los derechos contratados.
• Renovación de soporte o mantenimiento. En licencias perpetuas suele seguir su propio ciclo.
• Plazos de preaviso de auditoría. El aviso previo que el proveedor debe dar antes de verificar.
• Obligaciones posteriores a la terminación. Supresión o devolución de software y datos, y cualquier periodo de salida o transición.

Cada uno de estos puntos pertenece a una persona, no a una carpeta. La decisión de renovación es de compras, la conciliación de uso es de IT (tecnología de la información) y la confirmación de borrado suele ser de seguridad.

Riesgos y errores frecuentes

Renovación automática silenciosa. La ventana de preaviso se cierra, el plazo se renueva y el presupuesto queda comprometido antes de que nadie haya evaluado si la herramienta se sigue usando.

Desviación del alcance. Un equipo añade usuarios, levanta un segundo entorno o traslada una carga a más núcleos. El uso crece de forma orgánica y los derechos contratados no.

Auditorías sin preparar. Las auditorías de proveedor son frecuentes y caras. El informe 2026 State of ITAM (IT asset management) de Flexera concluyó que el 48 por ciento de las organizaciones encuestadas fueron auditadas en el último año, que el 64 por ciento de las organizaciones auditadas reportaron auditorías de Microsoft y que el 44 por ciento de los encuestados gastó más de un millón de dólares en auditorías a lo largo de tres años [7]. El mismo informe concluyó que solo el 36 por ciento de las organizaciones tiene visibilidad completa de su parque de IT [7].

Tratar una licencia firmada como una compra. Como muestra la distinción entre licenciatario y propietario, la reventa, la transmisión e incluso ciertas copias pueden estar restringidas de formas que sorprenden a los equipos que creen haber comprado el software [2].

Perder el conjunto documental. Una relación de licencia suele ser un contrato marco más pedidos, adendas, anexos de soporte y un contrato de encargo del tratamiento. Cuando solo se archiva el marco, faltan justamente las condiciones comerciales que rigen de verdad.

Obligaciones de código abierto sin gestionar. Las condiciones de atribución y disponibilidad del código fuente no llevan factura, así que nada obliga a revisarlas hasta que un cliente o un comprador pregunta [4].

Sin responsable. El fallo más habitual no es una cláusula mala. Es un contrato firmado del que nadie se ha hecho responsable.

Tipos de contrato relacionados

• Un master service agreement (MSA) rige una relación de servicios continuada y suele ser el documento matriz del que cuelgan los pedidos. Una licencia de software concede derechos de uso; un MSA define cómo se presta el trabajo.
• Un service level agreement define compromisos de rendimiento, bonificaciones y remedios. Normalmente se une a una licencia o suscripción en lugar de sustituirla.
• Un contrato de encargo del tratamiento regula cómo trata el proveedor los datos personales por cuenta del cliente.
• Un contrato de reventa de software autoriza a un tercero a vender o distribuir el software, algo que una licencia de usuario final estándar no hace.
• Un EULA es un contrato de licencia de software en formato estandarizado de aceptación con un clic, no un tipo contractual distinto [3].

Lista de comprobación para la gestión de contratos

Recórrala contra un contrato real, no de memoria.

1. Archive el conjunto completo. Reúna el contrato marco, cada pedido, las adendas, el anexo de soporte y el contrato de encargo del tratamiento en un repositorio de contratos con búsqueda, enlazados como una sola relación.
2. Registre la métrica de licencia y la cifra. Anote qué se cuenta y cuál es el derecho exacto, para poder responder a una pregunta de uso sin reabrir el PDF.
3. Extraiga las cláusulas que llevan riesgo. Capture alcance de licencia, restricciones, contraprestaciones y mecánica de subidas, derechos de auditoría, plazos de preaviso y límites de responsabilidad como campos estructurados. La extracción de datos contractuales convierte esto en un paso repetible en vez de un ejercicio de lectura.
4. Agende la fecha de preaviso, no la de renovación. Configure el recordatorio con suficiente antelación respecto al plazo de no renovación como para que quepa una decisión real, y diríjalo a la persona que puede tomarla.
5. Nombre un responsable por contrato. Una persona que responda de la renovación, del uso y de la respuesta a auditorías.
6. Concilie el uso antes de cada renovación. Compare usuarios, dispositivos o entornos reales con los derechos contratados y resuelva la diferencia antes de que la encuentre el proveedor.
7. Conserve evidencias de auditoría sobre la marcha. Justificantes de derechos, registros de despliegue y correspondencia, guardados donde puedan aportarse con rapidez.
8. Revise las obligaciones con una cadencia fija. Trimestral para los contratos grandes, anual para el resto. Revise las obligaciones de código abierto en el mismo momento.
9. Confirme que los pasos posteriores a la terminación se ejecutaron. La supresión, la devolución y la revocación de accesos son obligaciones, no intenciones.

Para la versión operativa paso a paso, consulte cómo gestionar los contratos de licencia de software. Para la panorámica más amplia de proveedores, la gestión de contratos con proveedores aborda la misma disciplina en toda una cartera de suministradores.

Contracko trabaja en el lado contractual de las licencias de software. Guarda las licencias firmadas y sus documentos asociados, extrae las cláusulas y fechas clave con inteligencia artificial (IA) y avisa a la persona adecuada antes de que se cierre una ventana de preaviso. No descubre software instalado ni cuenta instalaciones, que es el trabajo de las herramientas de software asset management. Si la carencia está en seguir la pista de los propios contratos, empiece una prueba gratuita y cargue unos cuantos contratos de licencia para ver qué sale.

Fuentes

[1] U.S. Code, Title 17, sections 106 y 117 (derechos exclusivos del titular del copyright; límites a la copia y a las copias de archivo de programas de ordenador por parte del propietario de un ejemplar). law.cornell.edu/uscode/text/17/117

[2] United States Court of Appeals for the Ninth Circuit, Vernor v. Autodesk, Inc., 621 F.3d 1102 (2010) (test de tres factores entre licenciatario y propietario, e inaplicabilidad de las defensas first sale y essential step a los licenciatarios). cdn.ca9.uscourts.gov/datastore/opinions/2010/09/10/09-35969.pdf

[3] Flexera, entrada de glosario sobre software license agreements (terminología SLA y relación entre un SLA y un EULA). flexera.com/resources/glossary/what-is-a-software-license-agreement

[4] Open Source Initiative, The Open Source Definition (redistribución libre, disponibilidad del código fuente y obras derivadas). opensource.org/osd

[5] U.S. Federal Acquisition Regulation 27.405-3 (software comercial adquirido bajo las licencias que habitualmente se ofrecen al público). acquisition.gov/far/27.405-3

[6] Unión Europea, Directive 2009/24/EC sobre la protección jurídica de programas de ordenador (agotamiento del derecho de distribución y copia de seguridad que no puede impedirse por contrato). eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0024

[7] Flexera, 2026 State of ITAM Report (frecuencia de auditorías, gasto en auditorías, mezcla de proveedores y visibilidad del parque de IT). flexera.com/blog/it-asset-management/state-of-itam-2026-audits

Las imágenes de este artículo se han generado con ayuda de IA.