La protección jurídica del software: derechos, licencias y auditorías legales

El software parece intangible, pero rara vez es “solo código”. Detrás de una aplicación hay decisiones de arquitectura, horas de desarrollo, documentación, librerías, contratos, usuarios, datos y, muchas veces, una dependencia crítica para que una organización funcione. Por eso me parece un error tratar las licencias como un trámite administrativo o como algo que solo preocupa al departamento legal.

La protección jurídica de los programas de ordenador conecta dos mundos que a veces se miran poco: el derecho y la ingeniería. Y cuando se entiende bien, ayuda a responder preguntas muy prácticas: ¿quién es el titular del programa?, ¿qué puedo hacer con una licencia?, ¿puedo modificarlo?, ¿cómo demuestro que el software instalado es legal?, ¿qué controles debería tener una empresa para no meterse en problemas?

Qué protege realmente la ley cuando habla de software

En España, los programas de ordenador se protegen principalmente mediante la propiedad intelectual. No se protege una “idea” abstracta, sino su forma de expresión: el código fuente, el código objeto, la documentación preparatoria, los manuales técnicos, las versiones sucesivas y los programas derivados. La clave está en que el programa sea original, es decir, una creación intelectual propia de su autor.

Esto es importante porque evita una confusión habitual. La ley no concede un monopolio sobre “la idea de una app para gestionar tareas” o “un algoritmo genérico para ordenar datos”. Lo que protege es la concreta implementación de ese programa. Dos equipos podrían resolver el mismo problema con arquitecturas y código diferentes sin que eso implique, por sí solo, una infracción.

También conviene distinguir propiedad intelectual, patente, marca y secreto empresarial. Un software puede estar protegido por derechos de autor y, además, incorporar una marca comercial, documentación confidencial, know-how interno o incluso formar parte de una invención con protección industrial. Pero el punto de partida, en la mayoría de los casos, es la propiedad intelectual.

Autoría, titularidad y programas creados en el trabajo

Otra cuestión esencial es separar autoría y titularidad de derechos de explotación. El autor suele ser la persona o grupo de personas que crea el programa. Sin embargo, cuando el software se desarrolla dentro de una relación laboral y en el ejercicio de las funciones encomendadas, la titularidad de los derechos de explotación corresponde al empresario, salvo pacto en contrario.

Esto tiene mucha relevancia práctica. Si una empresa encarga un desarrollo externo, no basta con pagar la factura y asumir que “el programa ya es mío”. Hay que revisar el contrato: cesión de derechos, alcance territorial, duración, posibilidad de modificación, acceso al código fuente, uso de componentes de terceros, mantenimiento, reutilización por el proveedor y régimen de entregables.

En proyectos reales, muchos problemas nacen por no documentar bien estas cuestiones desde el principio. Un desarrollo a medida sin cláusulas claras puede acabar siendo una caja negra: funciona, pero nadie sabe con precisión quién puede modificarlo, explotarlo, revenderlo o migrarlo.

Derechos de explotación y límites del usuario legítimo

El titular de los derechos de explotación puede autorizar o prohibir actos como la reproducción, la transformación, la adaptación, la distribución o el alquiler del programa. Traducido a lenguaje técnico: instalar, copiar, ejecutar, desplegar en servidores, modificar, crear versiones derivadas o distribuir copias no son actos neutros. Dependen de la licencia.

Ahora bien, la ley también reconoce límites a favor del usuario legítimo. Por ejemplo, no se puede impedir por contrato una copia de seguridad cuando sea necesaria para el uso del programa. También se permite observar, estudiar o verificar el funcionamiento del software para conocer sus ideas y principios, siempre dentro de las operaciones que el usuario tiene derecho a realizar. Y existe una excepción concreta para obtener información necesaria para la interoperabilidad, con condiciones estrictas.

Esto no convierte cualquier ingeniería inversa en legal. La frontera está en la finalidad, la necesidad, el alcance y el respeto a los derechos del titular. Una cosa es analizar lo imprescindible para que un programa propio interopere con otro; otra muy distinta es copiar la expresión del software ajeno para crear un producto sustancialmente similar.

Licencias: el contrato que define lo que puedes hacer

La licencia es el instrumento que baja la teoría jurídica al uso cotidiano. Puede ser una licencia propietaria clásica, una suscripción SaaS, una licencia por usuario, por dispositivo, por núcleo, por servidor, por entorno, por volumen de uso o por métrica cloud. Y cada modelo cambia la forma de controlar la legalidad.

En software propietario, el riesgo típico es instalar más copias de las contratadas, usar una edición distinta, activar módulos no licenciados o desplegar en entornos no cubiertos. En SaaS, el foco se desplaza a usuarios nominativos, cuentas compartidas, límites contractuales, retención de datos y condiciones de servicio.

En software libre y open source el riesgo es diferente. No significa “sin obligaciones”. Licencias permisivas como MIT o Apache 2.0 no imponen lo mismo que licencias copyleft como GPL. Si incorporo componentes open source en un producto, debo conocer sus condiciones: atribución, avisos legales, distribución del código fuente, compatibilidad entre licencias y obligaciones al redistribuir.

Aquí enlaza muy bien con la seguridad de la cadena de suministro. En Tecnoic ya he tratado cómo los fallos de dependencias aparecen en el contexto del OWASP Top 10. La gobernanza del software no va solo de pagar licencias: también va de saber qué componentes tengo dentro, de dónde vienen y qué obligaciones arrastran.

Medios de comprobación de la legalidad del software

Comprobar la legalidad del software no debería improvisarse cuando llega una auditoría. La organización tendría que poder demostrar, con evidencias, qué software usa, dónde está instalado, quién lo utiliza y bajo qué título jurídico.

Los medios de comprobación más habituales son el inventario de activos, las facturas, contratos, certificados de licencia, órdenes de compra, registros de suscripción, consolas de administración, evidencias de activación, informes de despliegue, listados de usuarios, documentación de bajas y trazabilidad de instalaciones.

En entornos modernos hay que ampliar la mirada. No basta con revisar portátiles. Hay software en máquinas virtuales, contenedores, imágenes Docker, pipelines CI/CD, repositorios, servicios cloud, extensiones de navegador, plugins, librerías de terceros y paquetes instalados automáticamente por gestores como npm, pip, Maven o NuGet.

Por eso cada vez tiene más sentido apoyarse en herramientas de Software Asset Management, inventario automatizado, escáneres de dependencias, SBOM, control de endpoints, MDM y revisión de repositorios. El objetivo no es generar burocracia, sino tener una fotografía fiable del ecosistema software.

Auditorías de legalidad y control interno

Una auditoría de software puede ser interna, impulsada por un fabricante, derivada de una revisión contractual o planteada dentro de un proceso más amplio de cumplimiento. En todos los casos, la lógica debería ser la misma: comparar el uso real con los derechos efectivamente adquiridos.

Yo lo ordenaría en cuatro capas. Primero, inventario: qué hay instalado y ejecutándose. Segundo, titularidad: qué licencias, contratos o suscripciones existen. Tercero, correspondencia: si el uso encaja con las condiciones pactadas. Cuarto, remediación: retirar software no autorizado, regularizar licencias, ajustar despliegues o cambiar procesos.

El control preventivo es mucho mejor que la regularización a posteriori. Políticas de instalación, catálogo autorizado, repositorios corporativos, bloqueo de software no permitido, segregación de entornos, revisión de compras TIC y control de dependencias open source reducen el riesgo de forma significativa.

Además, hay una dimensión de ciberseguridad. El software sin licencia suele venir asociado a cracks, activadores, binarios manipulados o fuentes no confiables. Eso abre la puerta a malware, robo de credenciales y persistencia en equipos corporativos. Lo jurídico y lo técnico se mezclan más de lo que parece. Ya lo comenté al hablar de seguridad a nivel de aplicación: proteger el software exige mirar el ciclo completo, no solo el perímetro.

Conclusión

La protección jurídica del software no es un tema decorativo para juristas. Afecta a cómo se desarrolla, compra, instala, modifica, audita y mantiene cualquier sistema informático serio. Entender derechos, licencias y controles permite evitar sanciones, litigios, dependencias opacas y riesgos de seguridad.

Mi resumen sería este: el software debe gobernarse como un activo crítico. Hay que saber quién lo ha creado, quién puede explotarlo, bajo qué licencia se usa y cómo se demuestra su legalidad.

¿Lo ves igual? ¿Crees que las organizaciones controlan bien su software o siguen funcionando demasiado “a ojo”? Te leo en comentarios.