Consideraciones sobre la licencia del código fuente

La adquisición del código fuente de una plataforma de exchange se presenta a menudo como el momento en que un operador toma el control de su propia tecnología. En la práctica, lo que se obtiene depende mucho menos del código en sí que de la licencia que lo acompaña. Los mismos archivos pueden entregarse bajo términos que conceden una propiedad genuina y libertad para operar, o bajo términos que dejan al operador dependiente del proveedor original para cada cambio relevante. Leer la licencia con atención, antes de firmar un contrato, es por tanto una de las decisiones de mayor calado en una compra de código fuente.

El tema se lee de forma distinta según el lector. Para una dirección general concierne al valor y la durabilidad de un activo por el que la empresa paga, y al riesgo de una dependencia que sobrevive a la relación. Para una dirección técnica concierne a lo que puede modificarse, reconstruirse y redesplegarse sin permiso, y a qué obligaciones de terceros viajan con el código. Para una función de cumplimiento o jurídica concierne a la claridad de la propiedad intelectual, a la continuidad de la plataforma si un proveedor falla, y a cómo encajan los términos con las expectativas regulatorias que el exchange debe satisfacer. Este artículo expone consideraciones sobre la licencia del código fuente a un nivel conceptual. No constituye asesoramiento jurídico, y los términos de cualquier acuerdo concreto deberían ser revisados por asesores cualificados.

Qué cubre una licencia de código fuente

Una licencia de código fuente es el acuerdo que define qué puede y qué no puede hacer un operador con el código que recibe. Establece si el código se posee en propiedad plena o se concede para su uso, qué derechos se transfieren con la entrega y cuáles retiene el proveedor. Suele abordar el derecho a operar la plataforma, a modificarla, a reconstruirla y desplegarla, a encargar trabajos a otras partes y, en algunos casos, a redistribuirla o revenderla. La presencia del código en los propios servidores de un operador no resuelve por sí sola ninguna de estas cuestiones; la licencia sí.

Definir estos términos de forma deliberada importa porque una compra de código fuente se hace normalmente para asegurar independencia, y una licencia ambigua o restrictiva socava precisamente eso en silencio. Un operador que puede leer y conservar el código pero no puede modificarlo ni reconstruirlo sin la intervención del proveedor ha adquirido menos de lo que quizá cree. Las consideraciones expuestas a continuación existen para hacer explícita la diferencia mientras aún es materia de negociación, en lugar de que aparezca como una limitación descubierta después de que la plataforma esté en producción y el margen de negociación haya pasado.

Por qué los términos de la licencia importan tanto como el código

Dos entregas de código fuente pueden ser idénticas archivo por archivo y representar, sin embargo, activos muy distintos, porque la licencia determina lo que el operador es realmente libre de hacer. Los términos rigen si las modificaciones pueden hacerse internamente o a través de un tercero elegido, si la plataforma puede desplegarse en varias entidades o en una sola, si el código puede trasladarse a otro alojamiento y si alguna parte puede reutilizarse en otros proyectos. Son estos términos los que deciden si una compra ofrece un control duradero o una forma más cómoda de dependencia.

La distinción se vuelve material precisamente en los momentos frente a los que la independencia debe proteger: un proveedor que deja de responder, cambia de rumbo, sube los precios o cesa su actividad. Un operador cuya licencia le permite mantener y evolucionar la plataforma mediante su propio equipo o uno elegido queda a salvo de esos sucesos; uno cuya licencia ata cada cambio relevante al proveedor original no lo está, por mucho que el código en sus servidores pueda sugerir. La licencia, no la entrega, es donde se fija la posición del operador a largo plazo.

Propiedad, modificación y redistribución

Tres derechos se sitúan en el centro de la mayoría de las negociaciones de código fuente. El primero es la propiedad: si la propiedad intelectual del código entregado se transfiere al operador, o si el operador recibe una licencia para usar un código que el proveedor sigue poseyendo. El segundo es el derecho de modificación: si el operador puede cambiar el código con libertad, internamente o a través de un tercero, o solo dentro de los límites que fija el proveedor. El tercero es la redistribución: si el operador puede revender, sublicenciar o redesplegar el código más allá de su propio uso, algo que la mayoría de los proveedores restringe y que la mayoría de los operadores en realidad no necesita.

Ninguno de estos derechos es intrínsecamente correcto o incorrecto; lo que importa es que cada uno se entienda y se ajuste a la intención del operador. Un operador que busca plena independencia ponderará con fuerza la propiedad y la modificación sin restricciones, mientras que uno satisfecho con una plataforma con soporte puede aceptar una licencia de uso con derechos de modificación definidos a cambio de otros beneficios. El error está en suponer que recibir el código fuente resuelve estos derechos automáticamente. No es así, y la diferencia entre una cesión de propiedad y una licencia de uso es una de las distinciones más importantes de todo el acuerdo.

Componentes de terceros y de código abierto

Pocas plataformas se escriben enteramente desde cero, y una base de código de exchange casi siempre incorpora bibliotecas de terceros y componentes de código abierto, cada uno con su propia licencia. Estas obligaciones viajan con el código estén o no detalladas en el acuerdo principal, y pueden imponer condiciones sobre cómo se usa, modifica y distribuye el software. Un operador que toma la propiedad de una base de código hereda la responsabilidad de las licencias de todo lo que contiene, y un proveedor que no puede dar cuenta de sus propias dependencias es, en sí mismo, una advertencia.

El enfoque meditado consiste en pedir, antes de la compra, claridad sobre qué componentes de terceros y de código abierto emplea la plataforma y bajo qué términos. Algunas licencias de código abierto son permisivas e imponen poco más allá de la atribución; otras llevan condiciones que importan mucho a una empresa que pretende mantener su plataforma como propietaria. La cuestión no es que algún componente concreto sea descalificante, sino que el operador sepa qué está adquiriendo y acepte esas obligaciones con conocimiento de causa, en lugar de descubrirlas en una auditoría o disputa posterior.

Depósito en garantía, soporte y mantenimiento

Cuando no se transfiere la plena propiedad del código fuente, el depósito de código fuente en garantía es una vía intermedia habitual. En un acuerdo de depósito, una copia del código la custodia un tercero independiente y se entrega al operador solo si ocurren sucesos definidos, como que el proveedor cese su actividad o incumpla obligaciones acordadas. El depósito no da acceso diario al código, pero protege la continuidad: la plataforma no se vuelve imposible de mantener por el mero hecho de que el proveedor ya no pueda o no quiera darle soporte.

Los términos de soporte y mantenimiento merecen el mismo escrutinio que la concesión de la licencia. Un operador que posee el código pero carece de documentación, de instrucciones de compilación o de cualquier transferencia de conocimiento puede tener un activo que en la práctica no puede mantener. El arreglo maduro trata la licencia, la documentación y un periodo de soporte definido como partes de una única adquisición, de modo que el operador pueda de verdad hacer avanzar la plataforma en lugar de poseer nominalmente algo que sigue sin poder cambiar sin el equipo original.

Modelos de licencia y alcance de uso

Las licencias también difieren en estructura y en el alcance de uso que permiten. Una licencia perpetua concede el derecho a usar el código de forma indefinida, normalmente por una tarifa única, mientras que una licencia por suscripción o de plazo concede el uso durante un periodo definido a cambio de un pago recurrente. Más allá de la duración, las licencias fijan el alcance del despliegue: cuántos entornos o entidades puede servir el código, si puede usarse para una sola marca o varias, y si el uso se ciñe al operador o se extiende a las sociedades que pueda adquirir o constituir más adelante.

Estas elecciones estructurales acarrean consecuencias que sobreviven a la compra inicial. Un operador que planea operar varias marcas, o expandirse a nuevos mercados y entidades, necesita una licencia cuyo alcance anticipe ese crecimiento en lugar de una tarifada y redactada en torno a un único despliegue. Ajustar el modelo de licencia y su alcance a los planes del operador, en el momento de la negociación, evita la alternativa más costosa de renegociar desde una posición más débil una vez que la plataforma está en producción y es central para el negocio.

Expectativas en el Reino Unido y la UE

Una licencia no queda al margen de las expectativas regulatorias que se aplican al exchange. En el Reino Unido, se espera que las empresas que manejan criptoactivos mantengan resiliencia operativa y demuestren que pueden seguir operando pese a la falla de un proveedor, lo que convierte las cláusulas de continuidad de una licencia, incluido cualquier depósito en garantía, en una cuestión tanto de resiliencia como de negocio. El registro conforme a las Money Laundering Regulations es una puerta de entrada en materia de delito financiero y no una autorización completa, y el futuro régimen FSMA para criptoactivos eleva aún más estas expectativas.

En la Unión Europea el marco está asentado. La transición de MiCA ha terminado. Los nuevos proyectos de criptoactivos de la UE deben diseñarse desde el principio para un modelo operativo de CASP autorizado, y DORA fija expectativas en torno a las dependencias tecnológicas de terceros que alcanzan directamente a cómo se estructura un acuerdo de código fuente y soporte. No emitimos dictámenes jurídicos ni garantizamos autorizaciones. Implementamos los requisitos regulatorios y de auditoría en la tecnología, la infraestructura y las operaciones. Una licencia bien redactada respalda la resiliencia operativa y una propiedad clara de la plataforma, pero no satisface ninguna de estas obligaciones por sí sola; la gobernanza, los registros y la planificación de la continuidad a su alrededor convierten una licencia en evidencia de una operación controlada.

Evaluar una licencia

Los términos adecuados se siguen de lo que el operador pretende lograr con la compra. Un operador que busca una independencia genuina priorizará la propiedad o una amplia licencia perpetua, la modificación sin restricciones, un recuento claro de los componentes de terceros y protección de la continuidad mediante depósito en garantía o transferencia. Un operador satisfecho con una plataforma con soporte puede razonablemente aceptar términos más estrechos a cambio de un compromiso de soporte más firme. El error común a ambos es centrarse en la entrega del código y tratar la licencia como una fórmula estándar, cuando es en la licencia donde realmente se decide el valor de la compra.

Las preguntas que hacer a cualquier proveedor se siguen de esto. ¿Se transfiere la propiedad o es una licencia de uso y, en ese caso, es perpetua? ¿Puede modificarse el código internamente o a través de un tercero sin permiso adicional? ¿Qué componentes de terceros y de código abierto se incluyen, y bajo qué términos? ¿Hay depósito en garantía disponible cuando la propiedad no se transfiere, y qué desencadena su entrega? ¿Qué documentación, soporte y transferencia de conocimiento acompañan al código? Para una visión más amplia de cómo encajan estas preguntas en la decisión de plataforma en su conjunto, las páginas de software de exchange de criptomonedas y asesoría de arquitectura fintech aportan el contexto circundante.

Resumen y próximos pasos

Las consideraciones sobre la licencia del código fuente determinan lo que un operador adquiere realmente cuando compra el código de una plataforma de exchange: si se transfiere la propiedad o se concede el uso, qué puede modificarse y redistribuirse, qué obligaciones de terceros y de código abierto viajan con el código, y cómo se protege la continuidad mediante depósito en garantía, soporte y transferencia de conocimiento. Dos entregas idénticas pueden representar activos muy distintos, y la diferencia se fija en la licencia y no en los archivos. Leída y negociada de forma deliberada, antes de que la plataforma esté en producción, la licencia convierte una compra de código fuente en el control duradero que se supone que debe ofrecer. Las expectativas propias de cada región se exponen en las páginas de preparación para el Reino Unido y la Unión Europea.