Depósito de software según la ley holandesa

Si su negocio depende de un software que usted no desarrolló, depende de la empresa que lo hizo. Usted posee el código objeto y una licencia; el proveedor posee el código fuente, el proceso de compilación y el conocimiento. Esta asimetría es tolerable mientras el proveedor sea solvente y competente, y deja de serlo en cuanto deja de serlo. El depósito en garantía de software es la solución habitual, pero solo funciona si se redacta teniendo en cuenta la legislación neerlandesa sobre insolvencia, y la mayoría de los acuerdos no lo hacen.

Qué es el depósito en garantía y el riesgo que aborda

El proveedor deposita el código fuente y los materiales de soporte en un tercero independiente, que los retiene hasta que ocurre un evento definido y luego los entrega al cliente, quien puede usar y modificar el código para mantener el software en funcionamiento. El riesgo radica en la continuidad, no en la propiedad: un cliente que gestiona el procesamiento de pedidos, los registros de pacientes o la planificación de la producción con el producto de un proveedor no puede cambiar de la noche a la mañana, ya que la migración lleva meses y generalmente requiere la ayuda del proveedor saliente. El depósito en garantía permite ganar tiempo para una salida ordenada. Tres situaciones son importantes:

• Insolvencia. El proveedor es declarado en quiebra, se nombra un administrador concursal, el personal se marcha y se interrumpe el apoyo. Este es el escenario para el que se redacta el contrato de depósito en garantía, y donde la legislación neerlandesa tiene mayor relevancia.
• Discontinuación. El proveedor retira el producto, deja de comercializar tu versión o es adquirido por alguien que no tiene interés en tu implementación. Esto es más común que la quiebra y, a menudo, no se incluye en la cláusula de liberación de responsabilidad.
• Fallo persistente en el mantenimiento. El proveedor sigue existiendo y sigue facturando, pero ya no corrige los defectos, no envía parches de seguridad ni mantiene el producto compatible con sus dependencias.

Acuerdos entre dos y tres partes

Un acuerdo bilateral implica una promesa en el contrato principal de que el proveedor entregará el código fuente si se produce un evento específico. Es una medida barata y poco sólida: nadie verifica de forma independiente que se haya depositado o mantenido al día la documentación, y —lo que es crucial—, en caso de quiebra, se le está pidiendo al síndico que cumpla con una obligación de la masa patrimonial que no está obligado a realizar.

Un acuerdo tripartito incorpora a un agente fiduciario como parte contratante. El agente toma custodia del depósito, lo verifica, lo retiene y tiene la obligación directa de liberarlo. Esa es la razón principal para contratar sus servicios: la liberación se convierte en una prestación realizada por un tercero solvente en virtud de su propio contrato, no por una masa patrimonial en quiebra. El agente también decide si se ha producido un evento que justifique la liberación, lo que le quita esa responsabilidad a un síndico que no tiene ningún incentivo para ayudarle.

¿Qué es lo que realmente se deposita?

El error más común es la ilegalidad. Se trata de un depósito que contiene únicamente el código fuente. El código fuente por sí solo no compila: si se entrega a un desarrollador sin instrucciones de compilación ni lista de dependencias, un código extenso puede requerir semanas de ingeniería inversa antes de generar un binario funcional; tiempo del que no se dispone cuando el sistema ya no cuenta con soporte. Un depósito sin instrucciones de compilación no tiene ningún valor.

Añade una obligación de actualización. Un depósito realizado una sola vez al firmar caduca en uno o dos ciclos de lanzamiento. Vincula los depósitos al calendario de lanzamientos (cada lanzamiento importante o a intervalos fijos) y establece el derecho a ser notificado cuando uno se retrase.

Verificación: lo que estás pagando

Adquiera la opción intermedia que se muestra a continuación como estándar, y la prueba completa en caso de que una interrupción sea crítica. La verificación a nivel de archivo por sí sola prácticamente no tiene valor.

• Verificación a nivel de archivo. El agente confirma que el depósito es legible, está libre de virus y coincide con la lista de archivos. Esto demuestra que se recibió algo, no que funcione.
• Revisión exhaustiva y de la documentación. El agente verifica las instrucciones de compilación y las dependencias con respecto al depósito e informa sobre las discrepancias. Esta opción intermedia es la adecuada para la mayoría de los clientes: detecta los fallos comunes (pasos de compilación faltantes, dependencias no documentadas, un componente que no se tiene derecho a usar) a una fracción del costo de una prueba completa.
• Compilación completa y prueba de ejecución. El agente compila el depósito en un entorno limpio y lo compara con datos de prueba. Es el único nivel que demuestra que el depósito funciona, pero es más lento, más caro y requiere repetición a medida que el software cambia.

Eventos de lanzamiento, redactados de manera que no se pueda discutir sobre ellos.

Una cláusula de liberación es un mecanismo que el agente fiduciario debe activar bajo presión y sin asesoramiento legal. Todo evento debe poder determinarse mediante un documento o el transcurso del tiempo, no a partir de un juicio sobre la conducta del proveedor.

Dos puntos son clave. Primero, que la carga de la prueba recaiga sobre el proveedor: el cliente notifica al agente con pruebas, el proveedor dispone de un plazo fijo para presentar objeciones y, en ausencia de objeciones, el agente libera al proveedor. Y segundo, que se establezca de antemano el procedimiento para la resolución de disputas —determinación pericial o arbitraje en un plazo breve—, de modo que una objeción solo sirva para ganar días, no meses.

La cuestión de la insolvencia en los Países Bajos

Todo lo anterior se refiere al diseño del contrato. Lo que sigue determina si se mantiene vigente en caso de quiebra del proveedor.

Lo que el administrador puede rechazar

Conforme al art. 37 Fw, cuando un contrato recíproco no ha sido cumplido íntegramente por ninguna de las partes al momento de la declaración de quiebra, la contraparte puede otorgar al síndico un plazo razonable por escrito para que declare si cumplirá con lo pactado; de no hacerlo, pierde el derecho a exigir el cumplimiento recíproco. El art. 37 Fw no extingue el contrato ni otorga al síndico la facultad de extinguirlo. El contrato permanece vigente; el síndico simplemente no está obligado a cumplirlo, y la contraparte conserva un derecho de reclamación en el procedimiento de quiebra conforme al art. 37a Fw.

En el caso del software, esto significa que el administrador puede rechazar el mantenimiento, el soporte, las actualizaciones, el alojamiento y los depósitos adicionales: servicios que suponen un coste para el patrimonio. Cabe esperar una negativa. La cuestión es si puede ir más allá e impedirle utilizar lo que ya tiene.

Nebula, berzona y Credit Suisse/Jongepier

Durante una década, esta situación fue realmente incierta. En el caso Nebula (Hoge Raad, 3 de noviembre de 2006, ECLI:NL:HR:2006:AX8838), el Tribunal Supremo dictaminó que, si bien la quiebra no extingue por sí misma los acuerdos existentes, una contraparte que ostenta un derecho de uso no puede seguir ejerciéndolo frente al síndico como si no se hubiera producido la quiebra; esto permitiría a un acreedor ignorar la quiebra en detrimento de los demás. Esta decisión se interpretó ampliamente como una autorización para que el síndico anulara un derecho de uso preexistente, lo que alarmó a los licenciatarios.

Esa interpretación no se mantuvo. En el caso ABN AMRO/Berzona (Hoge Raad, 11 de julio de 2014, ECLI:NL:HR:2014:1681), el Tribunal Supremo sostuvo que la quiebra no afecta a los acuerdos recíprocos existentes ni a las obligaciones derivadas de ellos, y no otorga al síndico ningún poder que la ley o el contrato no le confieran; por ejemplo, no puede rescindir un contrato de arrendamiento que aún esté vigente.

La posición se resolvió en Credit Suisse/Jongepier qq (Hoge Raad, 23 de marzo de 2018, ECLI:NL:HR:2018:424). El síndico puede negarse pasivamente a cumplir, pero la quiebra no le otorga la facultad de anular una prestación realizada por el deudor antes de la quiebra, ni de poner fin a una prestación continuada en la medida en que consista en tolerar o abstenerse de algo.

Esa frase es crucial para el software. Una licencia es, en esencia, un compromiso del titular de los derechos para tolerar un uso que, de otro modo, infringiría los derechos de autor; una prestación continua que consiste en dicha tolerancia. Por lo tanto, según la legislación vigente, una licencia otorgada válidamente antes de la quiebra sigue vigente y el síndico no puede revocarla. El síndico puede rechazar cualquier actividad en curso, pero no puede anular un derecho de uso que usted posea.

¿Qué significa eso para su acuerdo?

De ahí se derivan dos puntos. La obligación de liberación recae sobre el agente fiduciario, no sobre el proveedor: al constituirse como una custodia independiente a cargo de un tercero, la liberación es responsabilidad del propio agente, y la facultad del fiduciario, conforme al art. 37 Fw, se aplica a las prestaciones adeudadas por la herencia, no a un agente solvente, mientras que una promesa bilateral exige el cumplimiento por parte de la herencia, que el fiduciario puede rechazar. Además, la licencia debe otorgarse por adelantado, en lugar de al momento de la liberación, que es el punto más importante de la redacción, el cual se aborda más adelante.

En una reestructuración, y no en una quiebra, el art. 373 Fw restringe la confianza en las cláusulas ipso facto — disposiciones que permiten a una contraparte modificar, suspender o rescindir un contrato simplemente porque se ha iniciado un procedimiento de reestructuración—. Esta restricción opera en el procedimiento de reestructuración, no en la quiebra, y la solución es nuevamente estructural: cuando el acuerdo se redacta como una custodia independiente por un tercero, el mecanismo de liberación opera sobre la propia obligación del agente y no constituye una disposición ipso facto susceptible de ser anulada, tanto en una reestructuración WHOA como en una quiebra.

Cómo debe estructurarse la licencia

El depósito en garantía te proporciona una copia del código fuente, pero no el derecho a hacer nada con él. El código fuente es una obra protegida; compilarlo, modificarlo y ejecutar el resultado son actos restringidos. Sin una licencia que los cubra, un depósito liberado es una carpeta que no puedes abrir. Combina el depósito en garantía con una licencia que permita expresamente al cliente, una vez liberado el código, usar, compilar, modificar y desarrollar aún más el código fuente, y que esto lo realice un tercero; en la práctica, no tendrás que hacer el trabajo tú mismo.

Luego está el tema del momento oportuno. Una licencia otorgada al momento de la liberación es frágil. Si el evento de liberación es la propia quiebra, la concesión tendría que ser realizada por un deudor que, desde el día de la orden de quiebra, haya perdido la facultad de disponer de los bienes de la masa concursal; los artículos 23 Fw y 35 Fw lo impiden, y el síndico no otorgará la licencia en su nombre. Credit Suisse/Jongepier significa que el síndico no puede revocar una licencia que usted ya tenía, pero no hay nada que revocar si nunca tuvo una.

Otorgarlo en el propio contrato, antes de cualquier insolvencia, sujeto a una condición suspensiva: otorgado ahora, surtiendo efecto al producirse un evento de liberación. El derecho existe desde la fecha del contrato; solo su efecto se difiere. El derecho neerlandés es generalmente receptivo a esta estructura. En Rabobank/Reuser (Hoge Raad, 3 de junio de 2016, ECLI:NL:HR:2016:1046), el Tribunal Supremo aceptó que cuando un derecho condicional se creó antes de la quiebra, el cumplimiento de la condición surte efecto posteriormente sin ningún otro acto por parte del deudor. Ese caso se refería a una transferencia condicional de bienes y una prenda sobre el derecho condicional. Aplicarlo a una licencia de derechos de autor otorgada condicionalmente es una extrapolación respaldada por la doctrina jurídica, más que una cuestión resuelta por los tribunales, y debe presentarse como tal.

Confirme también que el uso del material publicado no requiere ningún consentimiento adicional del proveedor o de su administrador, y que se permite la sublicencia a un desarrollador sucesor.

SaaS y nube: el código fuente no es suficiente

Para el software que usted mismo administra, el código fuente, las instrucciones de compilación y una licencia constituyen una solución casi completa. Para un servicio, no lo es. Si la plataforma del proveedor deja de funcionar, usted pierde la aplicación, el entorno en el que se ejecutaba y sus datos; y el código fuente solo restaura lo primero, lentamente. Un acuerdo de continuidad SaaS debe incluir tres elementos:

• El entorno operativo. Imágenes de contenedores, definiciones de infraestructura como código, configuración, ajustes de red y seguridad, dependencias de tiempo de ejecución: todo lo necesario para implementar la plataforma en otro lugar.
• Los datos. Exportaciones periódicas de sus propios datos en un formato documentado y no propietario, con el esquema correspondiente. Los datos que no puede leer no son datos que usted posea, y las exportaciones deben realizarse durante toda la vigencia del contrato, no solo al momento de la publicación.
• La relación de alojamiento. Una vía para subrogarse en el contrato del proveedor con su proveedor de alojamiento, o notificar a dicho proveedor que usted puede hacerse cargo de la cuenta y pagar directamente.

Alternativas y quién paga

El depósito en garantía no siempre es la mejor opción, especialmente para productos estándar donde usted es un cliente más entre miles y el riesgo real es una interrupción del servicio en lugar de un fallo. Tres opciones más sencillas suelen ser más útiles: un derecho de salida de datos (exportaciones periódicas en un formato documentado, probado al menos una vez) que cubre gran parte de la exposición prácticamente sin coste alguno; un derecho a una copia en ejecución (una imagen desplegable que puede ejecutar durante un período de transición, restaurando el servicio mucho más rápido que una reconstrucción); y el pago directo al proveedor de alojamiento , manteniendo el entorno en funcionamiento mientras migra (la opción de continuidad en la nube más económica y, a menudo, la que se pasa por alto).

Cuando utilice un servicio de depósito en garantía, espere una tarifa de configuración única, una tarifa de custodia anual recurrente y cargos adicionales por verificación que varían según la profundidad de la misma. El costo recae sobre quien busca la protección, normalmente el cliente, aunque un proveedor que ofrece el depósito en garantía como argumento de venta puede asumirlo, y un acuerdo con múltiples beneficiarios que cubre a varios clientes de un mismo producto distribuye el costo, que suele ser el punto en el que un proveedor se resiste. En caso de impago, el agente debe notificarle, y usted tiene derecho a pagar en su lugar.

Lista de verificación para negociar un acuerdo de depósito en garantía.

• ¿Se trata de un acuerdo genuino entre tres partes con un agente independiente que le debe una obligación de liberación directa?
• Se otorga la licencia para usar, compilar, modificar y desarrollar aún más el código fuente. ahora¿Sujeto a una condición previa, en lugar de prometido en el momento del lanzamiento?
• ¿La lista de depósitos incluye instrucciones de compilación, dependencias, claves de licencia y documentación, y no solo el código fuente, actualizado en cada lanzamiento?
• ¿Qué nivel de verificación se contrata y con qué frecuencia se repite?
• ¿Los hechos que propiciaron la liberación de la autorización pueden determinarse a partir de un documento o del transcurso del tiempo, con un breve período de objeción y un procedimiento de resolución de disputas rápido?
• En el caso del SaaS: ¿se cubren el entorno, los datos y la relación de alojamiento, o solo el código?
• ¿Quién paga, qué sucede si el proveedor deja de pagar y el acuerdo de depósito en garantía se ajusta a la ley aplicable y a las cláusulas de propiedad intelectual del contrato principal?