En una compraventa de activos, los contratos de TI no se transfieren automáticamente al comprador. Las licencias de software, los contratos SaaS y los servicios en la nube requieren revisión individual y consentimiento de las contrapartes, un riesgo frecuentemente subestimado en la due diligence.
Tabla de contenidos
- Compraventa de activos versus compraventa de participaciones: el problema de la transferencia
- Licencias de software: § 34 UrhG como obstáculo
- La restricción de transferencia del derecho de autor
- La sentencia UsedSoft y sus límites
- Contratos SaaS: el problema del cambio de control
- Requisitos de consentimiento y derechos de resolución
- Evaluación de riesgos en la due diligence
- Servicios cloud y obligaciones de migración de datos
- El bloqueo de proveedor como riesgo transaccional
- Migración de datos y portabilidad
- Titularidad de la PI: ¿a quién pertenece el software?
- Desarrollos propios y trabajos por encargo
- Componentes de código abierto
- § 613a BGB: la transferencia de equipos de TI
- Transferencia automática en caso de traspaso de empresa
- Particularidades para empleados de TI
- § 25 HGB: responsabilidad por continuación de la empresa
- § 453 BGB: la compraventa de derechos
- Consentimientos de proveedores: la ruta crítica
- Plazos y estrategia
- Checklist de due diligence para contratos de TI
- Conclusión
Compraventa de activos versus compraventa de participaciones: el problema de la transferencia
En una compraventa de participaciones, el comprador adquiere las participaciones de la sociedad objetivo. La sociedad misma -- y con ella todos sus contratos -- continúan existiendo sin cambios. En una compraventa de activos, en cambio, se transfieren activos y contratos individuales. Esto significa que cada contrato debe transferirse al comprador individualmente, y por regla general se requiere el consentimiento de la respectiva contraparte contractual.
Para los contratos de TI, este principio es particularmente crítico porque la infraestructura tecnológica constituye hoy la columna vertebral operativa de prácticamente toda empresa. Si tras el cierre no pueden transferirse licencias de software centrales o dejan de estar disponibles servicios en la nube, la actividad empresarial se paraliza.
Licencias de software: § 34 UrhG como obstáculo
La restricción de transferencia del derecho de autor
La Ley alemana de Derechos de Autor regula la transferencia de derechos de uso en el § 34 UrhG. Como regla general, un derecho de uso solo puede transferirse con el consentimiento del autor. Aunque este consentimiento no puede denegarse sin motivo justificado, en la práctica los contratos de licencia de software contienen casi siempre sus propias disposiciones sobre transferibilidad que se superponen al régimen legal.
Esto significa que incluso si el § 34 UrhG permite una transferencia en principio, el contrato de licencia puede excluirla o vincularla a condiciones adicionales. En una compraventa de activos, por tanto, debe revisarse cada contrato de licencia de software individual en cuanto a sus cláusulas de transferencia.
La sentencia UsedSoft y sus límites
Con su sentencia en el asunto UsedSoft/Oracle (C-128/11) de 2012, el TJUE extendió el principio de agotamiento a las transmisiones en línea de software. Según esta sentencia, la reventa de una licencia de software es generalmente admisible si el software fue puesto en el mercado por primera vez en la UE con el consentimiento del titular de los derechos, se otorgó una licencia perpetua y se pagó una remuneración adecuada. El licenciatario original debe inutilizar su copia antes de la reventa.
Sin embargo, la aplicabilidad de la jurisprudencia UsedSoft a las transacciones de M&A es controvertida. Particularmente en licencias por volumen, licencias nominativas y adaptaciones específicas del cliente, existen considerables incertidumbres jurídicas. La sentencia UsedSoft no proporciona, por tanto, ninguna protección general para la transferencia de licencias en el marco de una compraventa de activos.
Contratos SaaS: el problema del cambio de control
Requisitos de consentimiento y derechos de resolución
Los contratos SaaS (Software as a Service) no se compran sino que se celebran como relaciones contractuales de tracto sucesivo. Su transferencia requiere generalmente el consentimiento del proveedor (denominado consent to assignment). Los estudios muestran que aproximadamente el 85 por ciento de todos los contratos SaaS empresariales contienen una cláusula de cambio de control.
Estas cláusulas pueden desencadenar diversas consecuencias jurídicas:
- Requisito de consentimiento: el proveedor debe consentir la transferencia antes de que pueda cerrarse la transacción
- Derecho de resolución automático: el cambio de control autoriza al proveedor a la resolución extraordinaria
- Derecho de ajuste de precios: el proveedor puede renegociar las condiciones en caso de cambio de control
- Obligación de notificación: la parte contratante debe notificar el cambio de control dentro de un plazo definido
Evaluación de riesgos en la due diligence
Durante la due diligence de TI, todos los contratos SaaS deben revisarse sistemáticamente en los siguientes puntos:
- ¿Existe una cláusula de cambio de control?
- ¿Qué consecuencia jurídica se desencadena (consentimiento, resolución, ajuste de precios)?
- ¿Cuál es el riesgo de que el proveedor deniegue el consentimiento?
- ¿Qué alternativas están disponibles si el contrato no puede transferirse?
- ¿Son portables los datos almacenados bajo el contrato?
Servicios cloud y obligaciones de migración de datos
El bloqueo de proveedor como riesgo transaccional
Los servicios de infraestructura cloud (IaaS, PaaS) implican frecuentemente un bloqueo de proveedor (vendor lock-in), que puede resultar particularmente problemático en una compraventa de activos. Las interfaces propietarias, los formatos de datos específicos y las dependencias de determinadas regiones cloud pueden complicar y encarecer significativamente la migración a una nueva infraestructura.
Migración de datos y portabilidad
El RGPD concede un derecho a la portabilidad de datos en su artículo 20. Sin embargo, este derecho se dirige a las personas afectadas y no es directamente aplicable a las relaciones entre empresas. La regulación contractual de la portabilidad de datos es, por tanto, determinante. Deben examinarse los siguientes puntos:
- ¿En qué formato pueden exportarse los datos?
- ¿Qué plazos se aplican para la entrega de datos tras la finalización del contrato?
- ¿Se eliminarán los datos de forma segura en el proveedor anterior tras la migración?
- ¿Quién asume los costes de la migración de datos?
Titularidad de la PI: ¿a quién pertenece el software?
Desarrollos propios y trabajos por encargo
Antes de la transferencia debe aclararse a quién pertenece realmente el software. Para desarrollos internos realizados por empleados del vendedor, los derechos de uso pasan al empleador conforme al § 69b UrhG -- salvo pacto en contrario. Para trabajos por encargo realizados por desarrolladores externos, en cambio, es determinante el acuerdo contractual. Si no existe una cesión expresa de derechos, los derechos de uso pueden permanecer con el contratista.
Componentes de código abierto
Se requiere especial precaución en el uso de software de código abierto. Ciertas licencias -- especialmente la GNU General Public License (GPL) -- contienen cláusulas copyleft que exigen que las obras derivadas se publiquen bajo las mismas condiciones de licencia. Si el software propietario de la empresa objetivo contiene componentes con licencia GPL, esto puede tener implicaciones significativas para el valor del software.
§ 613a BGB: la transferencia de equipos de TI
Transferencia automática en caso de traspaso de empresa
En una compraventa de activos, puede aplicarse el § 613a BGB cuando se transfiere una empresa o parte de empresa. Conforme al § 613a apartado 1 BGB, el adquirente sucede en los derechos y obligaciones de las relaciones laborales existentes en el momento de la transferencia. Esto afecta también al departamento de TI del vendedor.
Particularidades para empleados de TI
Para los equipos de TI se aplican aspectos particulares:
- Portadores de conocimiento: los empleados clave con conocimientos específicos del sistema son frecuentemente indispensables para la continuidad operativa. Su derecho de oposición conforme al § 613a apartado 6 BGB representa un riesgo considerable.
- Cláusulas de no competencia: las cláusulas de no competencia postcontractuales existentes se transfieren por regla general al adquirente y deben considerarse en los cálculos
- Medidas de retención: las primas de permanencia y los acuerdos de retención para empleados clave de TI deberían negociarse antes del cierre
La IHK Bremen explica en detalle las consecuencias laborales del traspaso de empresa.
§ 25 HGB: responsabilidad por continuación de la empresa
Un riesgo frecuentemente pasado por alto en las compraventas de activos es la responsabilidad conforme al § 25 HGB. Quien continúa un negocio mercantil bajo la razón social anterior responde con todo su patrimonio por todas las obligaciones del anterior titular originadas en la explotación del negocio. Esta responsabilidad se extiende a las obligaciones derivadas de los contratos de TI del vendedor -- como cuotas de licencia pendientes o atrasos de mantenimiento.
La protección más eficaz es la inscripción oportuna de una exclusión de responsabilidad en el registro mercantil conforme al § 25 apartado 2 HGB.
§ 453 BGB: la compraventa de derechos
Las licencias de software y otros activos inmateriales se transfieren en una compraventa de activos como compraventa de derechos en el sentido del § 453 BGB. Las disposiciones sobre la compraventa de bienes se aplican por analogía. Esto tiene consecuencias para la garantía: el vendedor responde de que el derecho transmitido existe realmente y de que está libre de derechos de terceros que el comprador no deba asumir.
En la práctica, esto significa que el vendedor debería otorgar en el contrato de compraventa garantías sobre la existencia y transferibilidad de las licencias de software. El comprador debería insistir en garantías específicas de propiedad intelectual que vayan más allá de las disposiciones legales.
Consentimientos de proveedores: la ruta crítica
Plazos y estrategia
La obtención de los consentimientos de los proveedores constituye frecuentemente la ruta crítica de la transacción. Los grandes proveedores de software como SAP, Microsoft u Oracle disponen de departamentos propios de M&A que revisan las solicitudes de transferencia según procedimientos estandarizados -- esto puede llevar semanas o meses.
Enfoque recomendado:
- Identificación temprana: identificar todos los contratos que requieren consentimiento durante la due diligence
- Priorización: ordenar los contratos por criticidad para la operación del negocio
- Solicitudes paralelas: presentar las solicitudes de consentimiento inmediatamente después de la firma, no solo después del cierre
- Plan de contingencia: desarrollar una solución alternativa para cada contrato crítico
- Condición de cierre: anclar los consentimientos para contratos críticos como condiciones suspensivas en el contrato de compraventa
Checklist de due diligence para contratos de TI
La siguiente checklist resume los principales puntos de verificación para la due diligence de TI en una compraventa de activos:
Licencias de software:
- Registro completo de licencias con plazos, condiciones de uso y cláusulas de transferencia
- Conciliación del uso real con los volúmenes licenciados (auditoría de cumplimiento)
- Revisión de componentes de código abierto y sus condiciones de licencia
- Identificación de licencias no transferibles y determinación de soluciones alternativas
Contratos SaaS y cloud:
- Inventario de todas las suscripciones SaaS con plazos y períodos de preaviso
- Análisis de las cláusulas de cambio de control y requisitos de consentimiento
- Revisión de la portabilidad de datos y opciones de migración
- Evaluación del riesgo de bloqueo de proveedor
Hardware e infraestructura:
- Inventario de todos los activos de TI (servidores, infraestructura de red, dispositivos finales)
- Revisión de contratos de leasing y alquiler en cuanto a su transferibilidad
- Evaluación del estado de mantenimiento y vida útil restante
Personal y conocimiento:
- Identificación de empleados clave de TI y su situación contractual
- Revisión de cláusulas de no competencia y acuerdos de confidencialidad existentes
- Análisis del riesgo de oposición conforme al § 613a BGB
- Planificación de medidas de retención
Protección de datos y cumplimiento:
- Revisión de la conformidad con el RGPD de todos los sistemas de TI
- Evaluación de los contratos de encargado de tratamiento existentes
- Análisis de transferencias internacionales de datos
Conclusión
Los contratos de TI son una de las fuentes de riesgo subestimadas en las compraventas de activos. A diferencia de las compraventas de participaciones, no se transfieren automáticamente al comprador, sino que requieren revisión individual, consentimiento y aseguramiento contractual. Una due diligence de TI exhaustiva y la participación temprana de especialistas en derecho informático y derecho de autor no son, por tanto, opcionales sino obligatorias.
En compleneo le acompañamos en la due diligence jurídica de TI en transacciones de compraventa de activos -- desde la revisión de contratos hasta la comunicación con proveedores y la redacción de las cláusulas de transferencia en el contrato de compraventa. Contáctenos.