Qué es el escrow de código fuente y para qué sirve
El escrow de código fuente es un depósito del código de tu software en manos de un tercero independiente, que te lo entregará si tu proveedor desaparece o deja de darte servicio. Sirve para que la quiebra, la venta o el abandono de la empresa que programó tu sistema no te deje sin poder mantenerlo. Es un seguro, no una forma de propiedad: no te convierte en dueño del código, te garantiza el acceso a él cuando ocurre algo concreto que habéis pactado por escrito. Tiene sentido cuando el software es crítico para tu operación y no tienes el código en tu poder; no tiene ningún sentido si ya te lo entregan en cada entrega.
Qué problema resuelve exactamente
Imagina una empresa de distribución que opera con un sistema de pedidos hecho a medida hace seis años. Funciona bien, nadie lo toca. La empresa que lo programó eran tres socios: uno se jubila, otro monta otra cosa y la sociedad se disuelve. El sistema sigue funcionando hasta que un cambio en el IVA obliga a modificar la facturación. Entonces aparece la pregunta incómoda: ¿dónde está el código para poder cambiarlo?
Sin código fuente, un programa es una caja cerrada. Se puede seguir usando mientras no haya que cambiar nada, pero no se puede corregir un error, ni adaptarlo a una ley nueva, ni conectarlo con otra herramienta. En la práctica tienes que rehacerlo desde cero.
El escrow corta ese riesgo. El código queda depositado desde el principio y tú tienes un derecho contractual a recibirlo si se cumple alguno de los supuestos acordados.
Cuándo el riesgo es real y cuándo no
El riesgo aparece cuando se juntan tres condiciones: el software es importante para tu día a día, está hecho a medida para ti, y el código no lo tienes tú. Si falta cualquiera de las tres, probablemente no necesitas escrow. Una web corporativa construida sobre un gestor de contenidos estándar, con el código en un repositorio al que tú tienes acceso, no justifica el trámite.
Qué se deposita de verdad (y qué suele faltar)
Aquí se concentran la mayoría de los escrows inútiles: se deposita el código y nada más, y cuando llega el momento de usarlo nadie sabe cómo ponerlo en marcha. Un depósito que sirva incluye:
- El código fuente completo, con su historial de versiones, no solo la última copia.
- La documentación técnica: cómo se instala, qué dependencias tiene, qué versiones de cada componente necesita.
- Los scripts de construcción y despliegue, para poder pasar del código a un sistema funcionando.
- La estructura de la base de datos y los procesos de migración de datos.
- El inventario de servicios externos: qué pasarelas, qué APIs de terceros y qué licencias se usan, y a nombre de quién están.
- Las claves y certificados, o al menos el procedimiento documentado para regenerarlos.
Una buena prueba de si el depósito sirve: pregúntate si un programador ajeno al proyecto, con solo lo depositado, podría levantar el sistema en una máquina nueva. Si la respuesta es no, el escrow es un papel sin contenido.
Cómo se articula en España
En España se usan tres vías, de menos a más formal:
- Depósito notarial. Se entrega al notario un soporte con el código y la documentación, y se protocoliza un acta que acredita qué se depositó y cuándo. Es la vía más sencilla y la más habitual en proyectos de pyme. Su límite es que el notario no comprueba el contenido técnico: certifica el depósito, no que el código esté completo.
- Registro de la Propiedad Intelectual. El Registro admite la inscripción de programas de ordenador y conserva un ejemplar. Aporta además prueba de autoría y fecha, útil si algún día hay disputa sobre quién creó qué.
- Empresas especializadas en escrow. Gestionan el depósito, lo actualizan con cada versión y, lo importante, hacen verificación técnica: comprueban que lo depositado compila y arranca. Es la opción más cara y la única que de verdad garantiza que el paquete funcione.
Sea cual sea la vía, lo que convierte el depósito en un derecho es el contrato. Sin cláusula que diga cuándo se libera y para qué puedes usarlo, tienes una copia guardada y poco más.
Las cláusulas que tienen que estar en el contrato
Estas son las que de verdad deciden si el escrow te servirá:
- Supuestos de liberación. Qué tiene que pasar para que te entreguen el código. Los habituales: concurso de acreedores o disolución del proveedor, cese de la actividad, incumplimiento grave y mantenido del mantenimiento, o negativa a renovar el servicio avisando con poco margen.
- Licencia de uso posterior. Recibir el código no implica poder usarlo. Hay que pactar expresamente que, una vez liberado, puedes modificarlo y hacer que lo mantenga otro proveedor.
- Actualización del depósito. Con qué frecuencia se renueva. Un depósito de hace cuatro años no se parece al sistema que usas hoy. Lo razonable es ligarlo a cada versión importante o a una revisión semestral.
- Verificación. Quién comprueba que lo depositado está completo y quién paga esa comprobación.
- Procedimiento y plazos de entrega. A quién se reclama, qué hay que acreditar y en cuánto tiempo se entrega.
- Quién paga. El coste del depósito y sus renovaciones, y si se reparte con el proveedor.
Escrow frente a las alternativas
El escrow no es la única forma de protegerte, y a menudo no es la mejor. Compáralo con las otras dos:
| Opción | Qué consigues | Cuándo encaja | Inconvenientes |
|---|---|---|---|
| Cesión de la propiedad del código | El código es tuyo desde el principio | Desarrollo a medida que financias entero | Hay que pactarlo en el contrato inicial; algunos proveedores lo encarecen |
| Repositorio compartido a tu nombre | Acceso continuo al código en todo momento | Casi cualquier proyecto a medida | No cubre documentación ni conocimiento; requiere que alguien tuyo vigile que se usa |
| Escrow con tercero | Acceso garantizado solo si pasa algo grave | Software con licencia de un producto ajeno que no van a cederte | Coste recurrente; inútil si no se actualiza y verifica |
La conclusión práctica para la mayoría de las pymes: si el desarrollo es a medida y lo pagas tú, negocia la propiedad del código y un repositorio a tu nombre, que es más barato y más eficaz. Reserva el escrow para cuando compras licencia de un producto que el fabricante no va a cederte de ninguna manera.
Cómo plantearlo sin que parezca desconfianza
Muchos empresarios no sacan el tema por miedo a enfriar la relación con un proveedor que les gusta. Es un error de planteamiento: el escrow no protege contra la mala fe, protege contra lo imprevisible. Un proveedor serio lo entiende a la primera porque también le protege a él de discusiones futuras.
La forma de plantearlo que mejor funciona es tratarlo como un punto más de la continuidad del servicio, junto con las copias de seguridad y el acuerdo de nivel de servicio, y hacerlo en la fase de contrato y no cuando ya hay tensión. Si un proveedor se niega en rotundo a cualquiera de las tres opciones de la tabla —cesión, repositorio compartido o escrow—, esa negativa es información valiosa sobre lo que pasaría el día que quisieras cambiar.
En resumen: un seguro que solo vale si está vivo
El escrow de código fuente resuelve un riesgo concreto y poco frecuente pero muy caro: quedarte con un software crítico que nadie puede tocar. Para que funcione necesita tres cosas que casi nunca van juntas: un depósito completo y no solo el código, una actualización periódica que lo mantenga parecido a tu sistema real, y unas cláusulas que digan con precisión cuándo se libera y qué puedes hacer con él. Si falta cualquiera de las tres, estás pagando por una tranquilidad que no tienes. Y antes de contratarlo, comprueba si no te conviene más la vía directa: que el código sea tuyo desde el primer día.
En Tangram Consulting trabajamos los proyectos a medida dejando claro desde el contrato de quién es el código y dónde está, porque creemos que un cliente que puede marcharse es un cliente que se queda por buenas razones. Si tienes un software crítico y no sabes en qué situación estás, escríbenos y lo revisamos contigo.