CUMPLIMIENTO Y DERECHO · TRATADO
El software se compra, desarrolla, ensambla a partir de componentes existentes y se utiliza a través de diferentes modelos. Esto crea diferentes derechos y obligaciones. Una factura de licencia aún no prueba que se permita ningún uso real. Comprobamos los derechos de uso, los contratos de desarrollo y el manejo de componentes de código abierto.
Capturar el uso real
Al principio hay un inventario: ¿Qué programas y versiones se utilizan dónde, por quién y en qué medida? Las métricas de licencia pueden relacionarse con usuarios, dispositivos, procesadores, accesos o ciertas aplicaciones. La virtualización, los entornos de prueba, las operaciones en la nube y el uso en grupo deben compararse con las condiciones respectivas.
También puede ser pertinente el cambio de proveedor de servicios o una reestructuración. Una licencia para una empresa en particular no cubre automáticamente a todas las empresas asociadas. Antes de renovar el contrato, la utilización efectiva y la contratación pública deben reunirse de manera comprensible.
Derechos al software desarrollado por sí mismo
Para los programas de empleados, § 69b UrhG contiene una regulación especial si el software se crea en el desempeño de las tareas o de acuerdo con las instrucciones del empleador. Esta regla no se puede aplicar a los desarrolladores libres o cualquier otro resultado de trabajo.
Para los desarrolladores externos, los derechos de uso requeridos deben ser garantizados contractualmente. Dependiendo del proyecto, esto incluye el procesamiento, el desarrollo ulterior, la transferencia a los clientes, la integración en los productos y el uso por las empresas afiliadas. El acceso al código fuente, la documentación, los componentes de terceros y la participación en un cambio de proveedor deben tratarse explícitamente. El pago de la tasa de desarrollo no responde a estas preguntas por sí solo.
Open Source no es un stock legal
El software de código abierto se puede utilizar de acuerdo con los términos de la licencia respectiva. Estas condiciones difieren considerablemente. A menudo se trata de avisos de copyright, textos de licencia y referencias a cambios. Para ciertas licencias copyleft, se pueden agregar obligaciones de proporcionar código fuente. Si esto sucede y en qué medida depende en particular de la versión de licencia, edición, conexión con otro código y el uso o forma de distribución.
La AGPL contiene requisitos especiales para ciertos usos a través de una red. Esto no implica que cualquier uso de software de código abierto requiera la publicación de todo el código propio, ni que un modelo de alojamiento puro siempre permanezca sin obligaciones de licencia. La evaluación debe basarse en la arquitectura concreta.
Un directorio de componentes y escaneos automatizados facilitan el inventario. No sustituyen la evaluación jurídica de las referencias poco claras, las diferentes opciones de concesión de licencias o los metadatos contradictorios. Los subcontratistas también deben proporcionar la información necesaria.
Un proceso de liberación para el desarrollo
- Los nuevos componentes se registran con la versión, fuente, licencia y uso previsto.
- Términos distintivos y conflictos de licencia se comprueban antes de la liberación del producto.
- Se proporciona toda la información necesaria, textos de licencia y, en su caso, ofertas de código fuente.
- Los cambios, las dependencias y las actualizaciones de seguridad posteriores siguen siendo comprensibles.
El proceso debe apoyar el desarrollo cotidiano. Son útiles unas responsabilidades claras y una norma breve para los casos poco claros. La prohibición general de todos los componentes libres no es una prueba adecuada ni una liberación sin conocimiento de las condiciones.
Licencias y solicitudes de auditoría
En el caso de una solicitud de auditoría, primero se examinan la base contractual, el alcance, los plazos y la confidencialidad. Los datos no deben emitirse de manera desordenada. Al mismo tiempo, deben respetarse las obligaciones de cooperación existentes. Un inventario técnico, el examen de la métrica de licencias y la clasificación legal de las reclamaciones pertenecen a un mismo grupo.
Apoyamos los acuerdos de licencia, los acuerdos de desarrollo, las reglamentaciones de código abierto y la tramitación de quejas concretas. Por una Solicitud Producto o proyecto, condiciones de licencia, modelo operativo y plazos ya establecidos son útiles.
Base jurídica y decisiones: UrhG, en particular 69a–69g; Licencia Pública General GNU, Versión 3; Licencia Pública General GNU Affero, Versión 3.
Situación al 2 de noviembre de 2026.
Más información: Empresas de software · Ley de Resiliencia Cibernética para fabricantes y proveedores de software · Adquisiciones y participaciones
Cuatro ejemplos prácticos
Los siguientes casos ficticios ilustran preguntas típicas de examen. La solución concreta depende de las circunstancias del caso individual.
01 · Sobreutilización de licencias
Una empresa tiene usuarios más productivos que accesos reservados. La medición de las licencias, el alcance del contrato y el ajuste se verifican antes de que se proporcione información no garantizada al proveedor.
02 · Copyleft en el producto
Un desarrollador integra una biblioteca. El texto de la licencia, la integración técnica y el formulario de venta determinan el examen de las posibles obligaciones de divulgación.
03 · Desarrollo por Freelancer
El contrato no dice nada sobre el desarrollo y la transferencia. La extensión de los derechos y los derechos de transformación requeridos se aclaran antes de la comercialización del producto.
04 · Auditoría de licencia del fabricante
Un proveedor requiere datos del sistema. La ley de examen, el alcance, la confidencialidad y un procedimiento controlado son acordados; no toda la información requerida debe ser emitida sin verificación.
Tu siguiente paso
¿Desea transferir los requisitos a su empresa o tener un proceso específico comprobado? Una breve descripción y una referencia a los plazos existentes son suficientes para el primer contacto. Votaremos sobre el alcance del examen y la compensación antes de la puesta en marcha.
