Qué convence a las empresas tecnológicas para colaborar con ARROWS
protección de la propiedad intelectual y una configuración a prueba de fallos de las licencias de software
Según el Derecho checo, si la cesión de derechos sobre el código de los desarrolladores externos no está resuelta por contrato, la empresa no es, en la práctica, titular del software. Además, una biblioteca de código abierto de tipo GPL mal utilizada puede obligarla a publicar su propio código fuente. Descubra cómo proteger su propiedad intelectual y configurar las licencias para que superen también una due diligence.

Resumen
Por qué la protección de la propiedad intelectual y de las licencias es fundamental para las empresas tecnológicas
Las empresas tecnológicas se diferencian de las empresas tradicionales por la estructura de sus activos. Su valor reside mucho menos en edificios o maquinaria y mucho más en activos intangibles: el código, las bases de datos, los algoritmos, la marca, los datos y el know-how del equipo. Estos activos están protegidos jurídicamente sobre todo por los derechos de autor, los derechos de propiedad industrial, el secreto empresarial y los contratos, y en ello desempeña un papel clave la forma en que se configuran las distintas relaciones y licencias. Para configurar modelos de licencia, transmisiones de derechos sobre el código y la protección contractual del know-how suele ser conveniente recurrir a la especialización en Derecho de las TI y del software y ciberseguridad. Si la propiedad intelectual está mal protegida, esto se refleja de inmediato en el valor de la empresa y en su posición negociadora frente a inversores y socios.
Otra particularidad es la rapidez de los cambios. El software se desarrolla en iteraciones cortas, el código se refactoriza continuamente, los componentes se sustituyen y se utilizan con frecuencia amplias bibliotecas de código abierto. Prácticamente cualquier aplicación moderna contiene hoy una proporción muy elevada de código ajeno –normalmente de código abierto–, por lo que la empresa es de hecho parte de decenas o cientos de acuerdos de licencia que está obligada a cumplir. El incumplimiento de las condiciones de licencia de un solo módulo constituye una infracción de los derechos de autor, con el riesgo de indemnización de daños, de la obligación de modificar el producto o incluso de poner a disposición el propio código fuente cuando se trata de las llamadas licencias copyleft de tipo GPL. Las repercusiones prácticas de la configuración de licencias en el negocio (incluido el trabajo con pedidos y contratos) se resumen también en el artículo relacionado Contrato mercantil frente a pedido: cuándo basta un pedido y cuándo la empresa se expone a problemas.
Para los órganos de administración de las empresas tecnológicas, el cumplimiento en materia de licencias no es solo una cuestión de gestión económica, sino también de responsabilidad personal. El uso no autorizado de software –ya sea en forma de software pirata, de superación del número de licencias o de incumplimiento de las condiciones de licencia– puede dar lugar a una combinación de reclamaciones civiles, multas administrativas y, en casos extremos, incluso responsabilidad penal si la infracción es de mayor alcance o reporta un beneficio considerable.
Desde el punto de vista de los inversores y compradores, la protección de la propiedad intelectual y la política de licencias empiezan a ser uno de los primeros puntos de toda due diligence. Las auditorías de PI especializadas analizan si la empresa dispone realmente de derechos sobre lo que vende, si partes clave del código no están en manos de contratistas externos sin cesión de derechos y si el uso de componentes de código abierto se corresponde con la estrategia de licencias elegida. En cuanto se descubre que la cadena de derechos de propiedad intelectual («chain of title») está interrumpida o que las condiciones de una licencia de código abierto exigen publicar el código fuente, esto puede conducir a una reducción del precio de compra, a garantías estrictas en el contrato de compraventa o incluso a la paralización total de la operación. Con ello se relaciona también la práctica transaccional, ya que en la venta de una empresa tecnológica la PI y las licencias suelen abordarse en el marco de la venta de empresas y el asesoramiento transaccional.
Los abogados de ARROWS no solo dominan el Derecho checo y europeo de autor y de licencias, sino que también saben leer los term sheets de los inversores, entienden cómo funciona el negocio SaaS y saben configurar las condiciones de licencia para que la empresa pueda escalar su producto a largo plazo y, al mismo tiempo, minimizar los riesgos regulatorios y judiciales. Así, a sus clientes no solo les aportan «seguridad jurídica», sino sobre todo un apoyo práctico en el crecimiento y la monetización de sus tecnologías.
Qué tipos de propiedad intelectual suelen gestionar las empresas tecnológicas
La base de un producto técnico suele ser un programa de ordenador que, según la Ley de Derechos de Autor checa (Ley n.º 121/2000 Sb., sobre derechos de autor, derechos conexos y modificación de determinadas leyes, en adelante «Ley de Derechos de Autor»), se considera una obra protegida desde el momento de su creación, sin necesidad de registro. La protección se extiende al software con independencia de su forma de expresión, es decir, tanto al código fuente como al código máquina, e incluye también los materiales preparatorios si alcanzan el umbral de actividad creativa. Si la empresa se plantea proteger una solución técnica también fuera del marco de los derechos de autor, puede resultarle útil consultar el resumen La patente europea con efecto unitario en la práctica: cómo defender eficazmente sus innovaciones frente a plagiadores en todo el mercado de la UE. Los acuerdos internacionales, en particular el ADPIC (TRIPS), equiparan expresamente los programas de ordenador a las obras literarias, lo que significa que gozan de plena protección de derechos de autor conforme al Convenio de Berna.
Para una empresa tecnológica es importante entender que los derechos de autor protegen la expresión concreta del programa (el código), no la idea ni el algoritmo como tales. En la práctica, esto significa que dos desarrolladores pueden crear de forma independiente dos implementaciones distintas de la misma idea; cada implementación estará protegida por separado si es original y expresa la actividad creativa individual de su autor. La infracción de los derechos de autor solo se produce cuando alguien toma o modifica sin autorización código ajeno, no por inspirarse en una función general o en un modelo de negocio.
Los derechos patrimoniales protegen el componente económico e incluyen, en particular, el derecho a reproducir, distribuir, arrendar, prestar o comunicar públicamente la obra. Estos derechos patrimoniales son transmisibles o licenciables, y precisamente con ellos se trabaja en los contratos de desarrollo de software y en los contratos de licencia. Por ello, una empresa tecnológica debe tener claramente definido quién está facultado para ejercer los derechos patrimoniales y en qué medida los concede a clientes o socios.
En la práctica surgen diferencias fundamentales según que el software lo cree un empleado o un contratista externo. En las llamadas obras de empleados, los derechos patrimoniales sobre la obra los ejerce por ley el empleador, salvo pacto en contrario. Esto significa que, si un desarrollador crea software en el marco de una relación laboral, la empresa normalmente adquiere el derecho a usar, modificar y sublicenciar el software sin tener que celebrar un contrato de licencia específico con cada empleado.
En cambio, en el caso de programadores externos (autónomos, freelancers o empresas proveedoras), los derechos patrimoniales permanecen en el autor, salvo que el contrato regule expresamente la cesión del ejercicio de estos derechos o la concesión de una licencia en el alcance necesario. Este matiz es una fuente frecuente de litigios y de bloqueos de operaciones, ya que, sin derechos o licencias debidamente cedidos, la empresa a menudo no dispone plenamente del código que vende.
Derechos de propiedad industrial: patentes, modelos de utilidad y marcas
Para muchas startups puramente de software, las patentes quedan en un segundo plano, mientras que en ámbitos como la ciberseguridad, el control industrial, el IoT o la biotecnología una estrategia de patentes bien elegida puede aumentar considerablemente el valor de la empresa y su poder de negociación frente a los inversores.
Por ello, los abogados del despacho ARROWS combinan con frecuencia la configuración de derechos de autor y licencias con el asesoramiento en propiedad industrial, para que el cliente no desaproveche la posibilidad de una protección más sólida allí donde sea realista y económicamente razonable.
La patente otorga un derecho exclusivo sobre una solución técnica que es nueva, resulta de una actividad inventiva y es susceptible de aplicación industrial. En el Derecho checo y en el sistema europeo de patentes, la patente sobre programas de ordenador «como tales» está excluida; no obstante, pueden patentarse soluciones técnicas en las que el software desempeñe un papel si la invención produce un efecto técnico que vaya más allá de la mera ejecución del programa en un ordenador. Una patente concedida en la República Checa suele tener una vigencia de veinte años desde la presentación de la solicitud, siempre que se abonen las tasas de mantenimiento, y su infracción genera plena responsabilidad civil y penal.
Los modelos de utilidad ofrecen una forma de protección de la solución técnica más breve (máximo 10 años) pero más rápida, mientras que las marcas protegen la denominación de un producto o servicio, como el nombre de una aplicación o un logotipo. Para las empresas tecnológicas, el registro de una marca suele ser el primer paso para construir su imagen en el mercado, mientras que las patentes y los modelos de utilidad se aplican sobre todo a las innovaciones técnicas.
Secreto empresarial y know-how
Una gran parte del valor de una empresa tecnológica no está protegida mediante registro, sino que entra en la categoría de secreto empresarial y know-how. El Código Civil checo (Ley n.º 89/2012 Sb., en adelante «Código Civil») entiende por secreto empresarial los hechos competitivamente relevantes, determinables, valorables y no accesibles habitualmente en los círculos comerciales correspondientes, que están relacionados con la empresa y cuyo titular garantiza su confidencialidad en el marco de su actividad.
Aquí se incluyen típicamente algoritmos, procedimientos técnicos internos, la arquitectura del sistema, estrategias de marketing, listas de clientes o, por ejemplo, la configuración de la infraestructura. La protección del secreto empresarial dura mientras se cumplan las condiciones de confidencialidad y las medidas de seguridad y la información no se publique ni pierda de otro modo su carácter reservado.
En la práctica, esto significa que no basta con marcar un documento como «secreto empresarial». La empresa debe demostrar que ha implantado realmente medidas técnicas, organizativas y jurídicas razonables, como accesos restringidos, cifrado de datos, derechos de acceso, directrices internas y, sobre todo, acuerdos de confidencialidad (NDA) con empleados, proveedores y socios. El acuerdo de confidencialidad debe delimitar con precisión qué categorías de información están protegidas –por ejemplo, el código fuente, la arquitectura del sistema, el know-how relativo a la actividad principal, la base de datos de clientes o la información financiera– y establecer la obligación de no divulgarla, no utilizarla indebidamente y protegerla suficientemente.
Las empresas tecnológicas suelen acudir a los abogados del despacho ARROWS precisamente cuando comparten know-how con inversores, integradores o socios estratégicos. En estas situaciones es clave configurar los NDA y los mecanismos contractuales de modo que, por un lado, permitan una comunicación abierta y concreta y, por otro, protejan el know-how esencial frente a abusos o su paso no deseado a futuros competidores.
Titularidad del código: empleados, contratistas y proveedores
Uno de los problemas prácticos más frecuentes en las empresas tecnológicas es la cuestión de quién «dispone realmente de los derechos sobre el código». Como ya se ha indicado, en el caso de los empleados los derechos patrimoniales los ejerce por ley el empleador, salvo que las partes pacten otra cosa. Sin embargo, con los proveedores externos no se produce ninguna transmisión automática; si el contrato no regula expresamente la cesión del ejercicio de los derechos patrimoniales o la concesión de una licencia de alcance suficiente, quien ejerce los derechos patrimoniales sigue siendo el autor, y no la empresa que encargó el desarrollo.
Esto repercute directamente en la capacidad de la empresa de seguir desarrollando el código, licenciarlo a terceros o darlo en garantía o venderlo en una salida (exit). Sin un procedimiento contractual claro de cesión de derechos o de concesión de licencia, la empresa solo puede ofrecer realmente a los inversores o al comprador posibilidades de uso limitadas, y no el pleno control sobre un activo clave. Este problema es tanto más delicado cuanto que a menudo solo se manifiesta durante la revisión legal en la fase final de la operación, cuando los costes y las expectativas de ambas partes ya son elevados. Los abogados del despacho ARROWS ayudan habitualmente a sus clientes a revisar los contratos históricos con los fundadores, los primeros desarrolladores y las agencias, para sanear la cadena de derechos antes de la entrada de un inversor.
En la práctica, además, a menudo se combinan varios tipos de relaciones: equipos internos de desarrollo, freelancers externos, nearshoring u outsourcing de partes del desarrollo, uso de bibliotecas de terceros o soluciones white-label. Cada una de estas relaciones tiene su propia lógica jurídica y, sin una gestión sistemática, puede ocurrir que parte de la funcionalidad clave esté bajo una licencia que no permite sublicenciar, otra parte sea propiedad de un proveedor con el que no se ha resuelto la cesión de derechos y una tercera parte se base en código abierto copyleft que exige abrir el código.
Aquí es donde más se nota el valor añadido de un equipo jurídico experimentado: no se trata de un único contrato, sino de una estrategia global para «ensamblar» jurídicamente el código de forma que sea explotable comercialmente a largo plazo.
Qué significa realmente una «licencia de software» en la práctica jurídica
Desde el punto de vista jurídico, una licencia de software es una autorización contractual para utilizar una obra protegida –es decir, el software– de una determinada manera y en determinadas condiciones. Para el licenciatario no se trata de comprar software en el sentido tradicional, sino de obtener una autorización de uso que puede ser más o menos amplia y estar limitada en el tiempo o en el territorio. La licencia representa, por tanto, una combinación de la autorización para usar el software, la oferta de celebrar un contrato de licencia y las condiciones concretas en las que el uso es legal.
Un ejemplo típico es la llamada licencia «click-wrap» durante la instalación o el registro del software, en la que el usuario acepta el acuerdo de licencia haciendo clic en el botón «Acepto». Desde el punto de vista jurídico, se trata de una forma estándar de celebrar un contrato, siempre que las condiciones sean accesibles y comprensibles. De manera análoga, en el entorno B2B la licencia puede estar recogida en un contrato independiente, en las condiciones generales o en el contrato de suministro e implantación del sistema. Sin embargo, siempre rige que lo que la licencia no permite expresamente está prohibido respecto de la obra, salvo las excepciones legales, como las copias de seguridad para uso propio o las reproducciones legales.
En la práctica empresarial es fundamental distinguir si la licencia es exclusiva o no exclusiva. La licencia exclusiva otorga al licenciatario el derecho a usar el software en el alcance pactado con exclusión de todas las demás personas, incluido el propio autor, salvo que el contrato disponga otra cosa. La licencia no exclusiva, en cambio, permite al autor conceder licencias a otros sujetos en paralelo; para los proveedores es el modelo típico del software empaquetado o de los servicios SaaS. La licencia puede limitarse además territorialmente (p. ej., al EEE), temporalmente (p. ej., suscripción anual) y cuantitativamente (número de usuarios, dispositivos, instancias o transacciones).
Principales tipos de licencias de software en la práctica de las empresas tecnológicas
En la práctica, los modelos de licencia pueden clasificarse según varios criterios. El primero es la apertura del código fuente. Las licencias propietarias se basan en un código cerrado al que solo tiene pleno acceso el autor o la empresa licenciante, y otorgan al licenciatario un alcance de uso limitado sin derecho a modificar ni redistribuir el código. Por el contrario, las licencias de código abierto permiten el acceso al código fuente y establecen las condiciones en las que el software puede usarse, modificarse y difundirse; lo más habitual son las condiciones de mantener la licencia, indicar la autoría o publicar las modificaciones.
Las licencias de código abierto se dividen a su vez en permisivas y restrictivas (llamadas copyleft). Las licencias permisivas, como MIT o Apache 2.0, permiten un uso, una modificación y una integración en software propietario relativamente libres, a menudo con la única condición de conservar el aviso de copyright y el texto de la licencia. Las licencias restrictivas, típicamente la GNU General Public License (GPL), funcionan con el principio «share-alike»: si utiliza un componente GPL y crea una obra derivada que distribuye, debe licenciarla de nuevo bajo la GPL y poner a disposición el código fuente.
En algunas licencias (p. ej., la Affero General Public License – AGPL), esta obligación se extiende también a la explotación del software como servicio a través de la red, donde la distribución se produce mediante acceso remoto. Una empresa que no conozca bien estas licencias puede «contagiar» involuntariamente su producto propietario con la obligación de abrir el código fuente, lo que tiene consecuencias fundamentales para los inversores y para su competitividad.
Las ventajas son una menor inversión inicial, una implantación más rápida y un escalado más sencillo; el inconveniente puede ser una mayor dependencia del proveedor (vendor lock-in) y la necesidad de resolver cuidadosamente las cuestiones contractuales de disponibilidad, protección de datos y terminación de la colaboración. Otro criterio es la forma de suministro del software: on-premise frente a nube (SaaS).
En el modelo on-premise, el software se instala en las instalaciones del cliente y la licencia suele ser única, eventualmente complementada con un mantenimiento anual. El cliente tiene mayor control sobre la explotación y, a menudo, sobre los datos, pero debe ocuparse del hardware y de la administración. En el modelo en la nube, el software se presta como servicio, normalmente mediante una licencia temporal (suscripción) con pagos periódicos y actualizaciones.
Transmisión y reventa de licencias
Merece especial atención la posibilidad de redistribuir las licencias de software. El Tribunal de Justicia de la Unión Europea, en la sentencia C-128/11 UsedSoft GmbH contra Oracle International Corp., concluyó que, en las licencias de software por tiempo indefinido, el derecho de distribución se agota con la primera «venta», incluso cuando el software se ha obtenido mediante descarga.
En la práctica, esto significa que el licenciatario puede, en determinadas condiciones, revender la licencia si deja de usar el software y transmite la licencia en su totalidad, y no por partes, si originalmente se concedió en bloques. Este principio limita la posibilidad de los proveedores de prohibir de forma absoluta la reventa de licencias en sus condiciones contractuales.
Para las empresas tecnológicas esto tiene dos dimensiones. Como proveedoras de software, deben tener en cuenta esta sentencia al configurar su modelo de negocio y sus condiciones de licencia, para evitar cláusulas nulas y el riesgo de litigios. Como usuarias de software ajeno, pueden en cambio aprovechar la posibilidad de optimizar su cartera de licencias comprando licencias «de segunda mano», aunque a costa de un mayor énfasis en la due diligence y en las garantías contractuales de que la licencia se adquirió realmente de forma válida y es transmisible.
Impuestos y servicios de licencia
Desde el punto de vista del impuesto sobre el valor añadido (IVA), la concesión de licencias de software se considera normalmente una prestación de servicios, y no una entrega de bienes. Esto afecta sobre todo a las operaciones transfronterizas, en las que ya la primera recepción de un servicio del extranjero puede generar la obligación de registrarse a efectos del IVA en la República Checa, incluso para un sujeto que hasta entonces no era sujeto pasivo.
En las empresas tecnológicas que adquieren servicios de licencia o soluciones en la nube a proveedores extranjeros es, por tanto, necesario coordinar las cuestiones de licencias y fiscales; también en este ámbito resulta ventajoso para la dirección contar en un mismo equipo con los abogados y los asesores fiscales del despacho ARROWS.
Preguntas más frecuentes sobre los modelos de licencia
En la práctica de las empresas tecnológicas se repiten preguntas similares sobre los modelos de licencia.
La primera pregunta frecuente es si se puede combinar «sin más» el código propietario de la empresa con bibliotecas de código abierto. La respuesta es sí, pero con la condición de seleccionar cuidadosamente las licencias y vigilar si surge una obra derivada que active la obligación copyleft o si se trata de una conexión independiente en la que puede mantenerse el carácter propietario del conjunto.
La segunda pregunta típica es si se puede conceder al cliente una «licencia ilimitada» sin riesgos para el proveedor. En la práctica, la licencia puede configurarse de forma muy amplia, pero la decisión debe basarse en el modelo de negocio, el tipo de producto y el poder de negociación de las partes; una licencia ilimitada puede afectar significativamente a las posibilidades de monetización posterior y al retorno de la inversión en desarrollo.
La tercera cuestión que se plantea con frecuencia es la diferencia entre licencia y cesión del ejercicio de los derechos patrimoniales. La licencia otorga al licenciatario la autorización para usar la obra en un alcance definido, mientras que la cesión del ejercicio de los derechos patrimoniales transfiere el ejercicio de estos derechos al adquirente, que puede disponer de la obra de forma análoga al autor original (con la salvedad de los derechos morales del autor, que son intransmisibles). Para los inversores la diferencia es fundamental: en una adquisición suelen insistir en la cesión más amplia posible del ejercicio de los derechos patrimoniales sobre el código central, y no solo en una licencia limitada.
Riesgos de unas licencias y una protección de la propiedad intelectual mal configuradas
El uso no autorizado de software en las empresas adopta muchas formas: desde instalar un programa adquirido legalmente en varios puestos, pasando por superar el número de usuarios pactado, hasta la descarga totalmente ilegal de software de fuentes piratas o el incumplimiento de las condiciones de licencia mediante un uso comercial no permitido.
La consecuencia es, sobre todo, la obligación de indemnizar los daños: según el § 40, apdo. 4, de la Ley de Derechos de Autor, el titular puede exigir una indemnización equivalente a la remuneración que habría sido habitual por obtener dicha licencia, y como mínimo el doble de dicha remuneración; además, pueden sumarse sanciones penales conforme al § 270 del Código Penal checo (Ley n.º 40/2009 Sb., en adelante «Código Penal») si se trata de una infracción de mayor alcance o de la obtención de un beneficio considerable.
El despacho ARROWS ayuda a sus clientes en estas situaciones de dos maneras. Por un lado, de forma preventiva, mediante la auditoría de la cartera de licencias, la elaboración de directrices internas para la adquisición de software y la formación de los empleados sobre cómo gestionar las licencias. Por otro, de forma reactiva, es decir, mediante la representación en auditorías de licencias, la negociación de acuerdos transaccionales sobre las reclamaciones de los fabricantes y la defensa frente a multas o demandas desproporcionadas. Subestimar la gestión de las licencias de software no es solo un error administrativo: es una decisión empresarial con consecuencias financieras, jurídicas, operativas y reputacionales potencialmente devastadoras.
La incautación de servidores por la policía, la interrupción del funcionamiento del sistema, la imposibilidad de hacer valer la garantía sobre software ilegal y la asociación pública de la marca de la empresa con la piratería de software son riesgos que ninguna dirección seria puede permitirse ignorar. Para los órganos de administración es además importante poder demostrar que no se ha descuidado el cumplimiento en materia de licencias, algo que facilita considerablemente un sistema de control interno y documentación bien configurado.
Vendor lock-in y dependencia del proveedor
Otro riesgo importante es el llamado vendor lock-in, es decir, la dependencia financiera y tecnológica de un único proveedor que impide a la empresa pasar a otra solución sin costes desproporcionados, retrasos o riesgo de interrupción. El vendor lock-in puede tener un componente técnico (formatos propietarios, API atípicas, configuraciones incompatibles), pero también un componente jurídico; por ejemplo, condiciones de licencia que impiden la modificación del software por un tercero, prohíben la ingeniería inversa, excluyen el acceso a los códigos fuente y no regulan qué ocurre en caso de terminación del contrato, insolvencia del proveedor o su adquisición por un competidor.
Casos conocidos en la República Checa muestran que la dependencia absoluta de un único proveedor de software puede llevar a que un poder adjudicador o una gran empresa se vean obligados a pagar por las modificaciones y el desarrollo del sistema precios que no serían habituales en un entorno competitivo, o a que no puedan desarrollar el sistema según sus propias necesidades porque el proveedor no facilita los códigos fuente. Desde el punto de vista de la empresa tecnológica que vende software, el vendor lock-in es un arma de doble filo. Por un lado, puede reforzar a corto plazo su posición negociadora; por otro, puede disuadir a clientes sofisticados que son conscientes de los riesgos e insisten en condiciones contractuales más equilibradas, incluida la posibilidad de cambiar de proveedor.
En la práctica, el despacho ARROWS combina a menudo la regulación contractual de la licencia, del servicio y del escrow para que la dependencia del proveedor sea proporcionada y previsible, y no absoluta. La solución jurídica del vendor lock-in combina con frecuencia la negociación del derecho a la entrega de los códigos fuente en determinadas condiciones (p. ej., en caso de insolvencia del proveedor, incumplimiento grave del contrato o incumplimiento de las obligaciones de servicio) con un acuerdo de software escrow, es decir, el depósito del código fuente ante un tercero independiente que lo pondrá a disposición del cliente si se producen los supuestos de activación definidos. En algunos casos, el derecho a la entrega del código fuente puede deducirse también de la propia finalidad del contrato, sobre todo en el software desarrollado a medida, si la falta de entrega del código impidiera o dificultara de forma desproporcionada su mantenimiento y desarrollo.
Códigos fuente, escrow y derecho a realizar modificaciones
La cuestión de si el cliente tiene derecho a la entrega del código fuente es uno de los ámbitos más delicados del Derecho del software. Si el contrato establece expresamente que la licencia se concede solo sobre el código máquina y que los códigos fuente siguen siendo secreto empresarial del proveedor, el cliente, por regla general, no tiene un derecho automático a su entrega. Por otro lado, si el software se ha creado a medida y no existe contrato de servicio o el proveedor no puede cumplir sus obligaciones, la jurisprudencia alemana y parte de la doctrina admiten que puede deducirse la obligación del proveedor de entregar los códigos fuente para poder subsanar defectos y seguir desarrollando el software.
La solución intermedia suele ser precisamente el software escrow, en el que el código fuente, la documentación y otros materiales se depositan ante un agente de escrow independiente y se liberan al cliente si el proveedor quiebra, deja de prestar soporte o incumple gravemente el contrato de otro modo. El contrato de escrow define con precisión en qué condiciones se liberarán los materiales y cómo puede utilizar el cliente el código fuente; normalmente solo para el mantenimiento y el desarrollo para uso propio, y no para su posterior explotación comercial.
Los abogados del despacho ARROWS ayudan a sus clientes a configurar estos mecanismos para que sean técnicamente viables (incluida la obligación del proveedor de actualizar periódicamente las versiones depositadas del código y de la documentación) y jurídicamente exigibles. En los proyectos transfronterizos también es importante la elección de la jurisdicción y de las normas procesales para resolver litigios sobre la liberación de los materiales en escrow.
Software de código abierto y riesgos de licencia «ocultos»
Hoy en día, el uso de software de código abierto es prácticamente inevitable. Aporta un rápido aumento de la productividad, acceso a bibliotecas contrastadas y apoyo de la comunidad, pero también riesgos jurídicos nada desdeñables si no se gestiona correctamente. Los principales riesgos son el desconocimiento de las condiciones exactas de licencia, la combinación de licencias incompatibles en un mismo producto y el incumplimiento de las obligaciones de indicar la autoría, publicar el código fuente o proporcionar la obra derivada bajo la misma licencia.
Desde el punto de vista jurídico, el concepto clave es el de «obra derivada». En materia de derechos de autor, se trata de una obra resultante de la transformación de la obra original, por ejemplo mediante su modificación, traducción o combinación con otra obra. Sin embargo, en el ámbito del software, la frontera entre una «obra derivada» y una conexión independiente (por ejemplo, a través de una API) es a menudo poco clara, tanto técnica como jurídicamente. En las licencias copyleft, sobre todo la GPL, es precisamente el nacimiento de una obra derivada lo que activa la obligación de licenciar el resultado bajo la misma licencia y poner a disposición el código fuente. Una arquitectura de la aplicación errónea durante el desarrollo puede tener así consecuencias jurídicas fundamentales en el momento en que la empresa empieza a distribuir comercialmente el producto o en que entra un inversor.
En la práctica, los abogados del despacho ARROWS recomiendan a las empresas implantar una política interna de OSS que defina qué tipos de licencias de código abierto son admisibles en el producto central, cómo se registran los componentes utilizados, quién aprueba la incorporación de nuevas bibliotecas y cómo se cumplen obligaciones como la publicación del texto de la licencia o la puesta a disposición del código fuente de determinadas partes del sistema. Suele incluirse también una auditoría técnico-jurídica periódica (auditoría de PI, escaneo de OSS) que combina herramientas de detección de componentes de código abierto en el código con un análisis jurídico de las consecuencias de cada licencia.
Riesgos en operaciones de M&A e inversiones
En la adquisición de una empresa tecnológica o la entrada de un inversor, la calidad de la protección de la propiedad intelectual y de la configuración de las licencias desempeña un papel clave en la llamada due diligence de PI. El comprador necesita verificar si la empresa dispone realmente de los derechos sobre el software que vende, si no tiene litigios relativos a licencias, si no infringe derechos de terceros y si el uso de componentes de código abierto no pone en peligro la estrategia de monetización del producto.
La auditoría de PI suele incluir la identificación de todos los activos de PI, la revisión de los contratos con empleados y proveedores externos, el análisis de los contratos de licencia con clientes y proveedores, el mapeo de los componentes de código abierto y la evaluación de la «freedom to operate», es decir, del riesgo de que las tecnologías clave infrinjan patentes de terceros. Las conclusiones de la due diligence de PI pueden dar lugar a un ajuste del precio de compra, a la inclusión en el contrato de garantías específicas y cláusulas de indemnidad o a la exigencia de subsanar las deficiencias detectadas (por ejemplo, cesión posterior de derechos, modificación de las condiciones de licencia frente a los clientes o eliminación de un componente OSS problemático) antes del cierre de la operación.
En este contexto, el despacho ARROWS actúa tanto del lado de las empresas tecnológicas que se preparan para una inversión o una venta como del lado de los inversores y compradores que necesitan una imagen detallada y comprensible del estado de la PI de la sociedad objetivo. La combinación de experiencia jurídica en Derecho de las TI, M&A y cuestiones fiscales permite a los abogados de ARROWS diseñar la estructura de las operaciones de modo que los riesgos de PI queden reflejados contractualmente y también tenidos en cuenta financieramente.
|
Posibles problemas |
Cómo ayuda ARROWS (consultas@arws.cz) |
|
Titularidad del código poco clara: contratos históricamente mal configurados con fundadores, desarrolladores y agencias |
Auditoría de PI y revisión contractual: identificamos las lagunas en la cadena de derechos y preparamos adendas y cesiones del ejercicio de derechos para que la empresa disponga realmente de los derechos sobre el software clave y pueda licenciarlo y venderlo con seguridad. |
|
Riesgo de licencias copyleft y OSS en el producto: amenaza de tener que publicar el código fuente o cambiar el modelo de monetización |
Cumplimiento OSS y estrategia de licencias: analizamos los componentes utilizados, establecemos reglas internas para el OSS y proponemos cambios en la arquitectura o en las condiciones de licencia para que el producto siga siendo explotable comercialmente. |
|
Vendor lock-in y dependencia de un único proveedor: imposibilidad de cambiar sin costes elevados o interrupciones |
Negociación de salvaguardas contractuales: preparamos contratos de licencia y de servicio con condiciones claras de terminación, derecho a cambiar de proveedor, depósito del código en escrow y una regulación equilibrada de los derechos sobre los códigos fuente. |
|
Auditorías de licencias y riesgo de multas: desorden en la documentación de licencias, instalaciones «de más», incumplimiento de condiciones |
Auditoría de la cartera de licencias y representación en inspecciones: mapeamos el uso real del software, preparamos directrices internas y, en caso de auditoría, le representamos, negociamos acuerdos sobre las reclamaciones y minimizamos el impacto financiero. |
|
Bloqueo de una inversión o de la venta de la empresa por riesgos de PI: problemas detectados en la due diligence |
Preparación previa a la operación: revisamos a tiempo con usted el estado de la PI y de las licencias, proponemos la subsanación de los puntos débiles y preparamos la documentación para los inversores de modo que los riesgos de PI no impidan la operación ni reduzcan el precio. |
Preguntas relacionadas sobre los riesgos de licencias y PI
1. ¿Con qué frecuencia tiene sentido realizar una auditoría interna de licencias?
En las empresas tecnológicas de crecimiento dinámico, que implantan con frecuencia nuevo software o cambian su infraestructura, es razonable realizar una revisión básica al menos una vez al año y una auditoría más detallada ante cambios significativos, como la migración a la nube, una gran actualización del ERP o la adquisición de otra sociedad.
2. ¿Tiene sentido abordar el vendor lock-in si somos un cliente «pequeño» de un gran proveedor?
Sí, precisamente en esos casos es importante negociar al menos las condiciones básicas de terminación, exportación de datos, entrega de configuraciones y, en su caso, una solución de escrow, para que su empresa no quede atrapada sin una posibilidad real de pasar a otra solución.
3. ¿Cuándo tiene sentido plantearse un software escrow?
Típicamente en el caso de software crítico sobre el que descansan los procesos clave de la empresa y de soluciones muy personalizadas cuyo mantenimiento por un tercero sin el código fuente sería difícil o imposible; el escrow es entonces una herramienta eficaz de gestión del riesgo de proveedor.
Cómo configuran en la práctica los abogados de ARROWS la protección de la propiedad intelectual y las licencias
El mercado tecnológico no es homogéneo: una startup en fase inicial tiene necesidades distintas de las de una scale-up antes de una ronda de inversión o de una empresa de software consolidada que se expande al extranjero. El despacho ARROWS adapta la estrategia de PI y de licencias al tipo de cliente, a su modelo de negocio y al horizonte previsto (crecimiento orgánico, entrada de un inversor, venta de la empresa).
En las startups en fase inicial, el mayor riesgo suele ser una «higiene contractual subestimada». Los fundadores y los primeros desarrolladores escriben código sin contratos formales, usan bibliotecas OSS sin registrarlas y llegan a acuerdos «de palabra» con freelancers y primeros clientes.
En esta fase, los abogados del despacho ARROWS ayudan a sentar las bases: pactos de fundadores, contratos laborales y de prestación de servicios para desarrolladores, una política marco de OSS y los primeros contratos de licencia con clientes o socios. El objetivo no es cargar al cliente con burocracia, sino crear un marco mínimo funcional que permita a la empresa crecer con seguridad y no bloquee una futura inversión.
En las scale-ups y en las sociedades a punto de una ronda de inversión o de una operación de salida, el encargo típico es una auditoría integral de PI y el «saneamiento» del pasado. Esto incluye la revisión de los contratos con empleados y desarrolladores externos (también extranjeros), la cesión posterior de derechos, el establecimiento de una nueva política de licencias para el producto clave, la adaptación de los contratos con clientes para que sean compatibles con un futuro escenario de M&A y, en su caso, el registro de marcas o la presentación de solicitudes de patente. Suele incluirse también la preparación de las secciones de PI en los contratos de inversión y de las garantías de los vendedores, para que los riesgos de PI se repartan entre las partes de forma previsible.
Las software houses consolidadas y las corporaciones suelen acudir a los abogados del despacho ARROWS en busca de asesoramiento jurídico externo a largo plazo. Esto incluye la preparación y revisión continuas de contratos de licencia, la adaptación de las condiciones generales, el apoyo en licitaciones, las negociaciones con grandes clientes y proveedores, la representación en auditorías de licencias y la formación de los equipos internos (RR. HH., TI, compras, jurídico, desarrollo de negocio).
Contratos de desarrollo de software y cesión del ejercicio de derechos
El contrato de desarrollo de software es la base jurídica para crear una solución de software a medida. Debe definir no solo los parámetros técnicos y los hitos, sino también resolver con claridad la cuestión de la propiedad intelectual: quién ejercerá los derechos patrimoniales, en qué medida se cederán o licenciarán los derechos, qué ocurrirá con el know-how previo del proveedor y qué limitaciones se aplican al uso posterior del código.
Un contrato de desarrollo de software bien configurado contiene una especificación detallada de los requisitos y del alcance del proyecto, incluidas las especificaciones funcionales y técnicas, los requisitos de integración, los parámetros de rendimiento y los estándares de seguridad. Desde el punto de vista jurídico, es clave incluir cláusulas sobre la cesión del ejercicio de los derechos patrimoniales de autor o la concesión de una licencia a favor del cliente.
En la práctica se utilizan distintos modelos: la cesión del ejercicio de todos los derechos patrimoniales sobre el código resultante, una licencia con derecho a modificar el código fuente y a sublicenciar, o un modelo combinado en el que el proveedor conserva el ejercicio de los derechos sobre sus componentes genéricos, que utiliza en varios proyectos, y el cliente adquiere los derechos sobre la parte creada a medida.
Los abogados del despacho ARROWS ayudan a sus clientes a encontrar el equilibrio entre estos intereses. Del lado del cliente, suelen perseguir la cesión más amplia posible del ejercicio de los derechos sobre el núcleo del producto que constituye la ventaja competitiva de la empresa, así como la posibilidad contractual de modificar el código, combinarlo con otras obras y seguir licenciándolo.
Del lado de los proveedores, en cambio, es necesario proteger los componentes reutilizables, las bibliotecas y el know-how, para que no se «vendan» en un solo proyecto y no bloqueen la actividad futura. Un equipo jurídico experimentado sabe estructurar el contrato de modo que ambas partes obtengan lo que realmente necesitan: el cliente, el control sobre su solución, y el proveedor, la posibilidad de seguir desarrollando su cartera.
Configuración de los contratos de licencia con clientes y socios
El contrato de licencia con el cliente es el documento que determina el marco jurídico y comercial del uso del producto. Para una empresa tecnológica es la herramienta con la que controla cómo se utilizará su software, cómo se facturará, cómo se gestionarán las incidencias, qué límites de responsabilidad tiene y cómo se procederá en caso de terminación del contrato o de litigio.
Un contrato de licencia B2B típico debe contener una delimitación clara del alcance de la licencia (exclusiva o no exclusiva, limitación territorial y temporal, número de usuarios, dispositivos e instancias), reglas de instalación y uso, la prohibición de modificar el código sin el consentimiento del licenciante, pero también reglas para posibles personalizaciones, integraciones y ampliaciones. Es importante la regulación de la responsabilidad, incluidas las posibles garantías de funcionamiento o disponibilidad (SLA), la limitación de la indemnización y la exclusión de responsabilidad por daños indirectos, pérdida de datos o lucro cesante, en la medida en que el ordenamiento jurídico lo permita.
En la práctica, los abogados del despacho ARROWS velan por que la licencia, el contrato de mantenimiento y las posibles adendas formen un conjunto coherente y claro, comprensible también para los equipos comerciales y de TI del cliente. Los contratos de licencia modernos deben reflejar también que el software cambia: actualizaciones, upgrades, cambios de funcionalidad, parches de seguridad. Por ello, conviene regular las condiciones de mantenimiento y soporte, incluidos los tiempos de respuesta y de resolución para los distintos tipos de incidencias, el derecho a actualizaciones y las posibles tarifas por nuevas versiones.
Directrices internas, NDA y formación
El marco jurídico no se limita a los contratos externos. Igual de importantes son los procesos y directrices internos que determinan quién puede aprobar el uso de nuevo software, cómo se gestiona la documentación de licencias, cómo se tratan los componentes de código abierto, cómo se crea y revisa la documentación y cómo se protege el secreto empresarial.
El despacho ARROWS prepara con frecuencia para empresas tecnológicas políticas internas de licencias y de PI que explican a desarrolladores, product managers y compradores qué reglas rigen en la adquisición de software, la incorporación de OSS, el intercambio de código fuente, el uso de servicios en la nube o el intercambio de know-how con socios externos. Suele formar parte de ello también un sistema de NDA para empleados, contratistas y colaboradores externos que sea práctico, exigible y adecuado a la realidad del trabajo diario.
Los abogados del despacho ARROWS imparten además formación especializada tanto para la dirección como para los equipos técnicos: desde los fundamentos del Derecho de autor y de licencias, pasando por la gestión del OSS, hasta procedimientos concretos en auditorías de licencias o en la due diligence del lado vendedor o comprador. Así, las empresas no solo obtienen contratos, sino también una comprensión que les permite gestionar los riesgos también entre proyectos.
Resumen final
La protección de la propiedad intelectual y una configuración sólida de las licencias de software no son para las empresas tecnológicas un tema teórico, sino una realidad cotidiana con impacto directo en el valor de la empresa, su crecimiento y la responsabilidad personal de la dirección. Los derechos de autor sobre el software, el secreto empresarial y, en su caso, las patentes y marcas constituyen la columna vertebral del negocio tecnológico, mientras que los contratos de licencia determinan cómo se monetizará el producto, qué riesgos asume la empresa y con qué flexibilidad puede reaccionar a los cambios del mercado, de la regulación o de su estructura de propiedad.
Como muestran los ejemplos de la práctica y la jurisprudencia, errores aparentemente menores –la falta de cesión de derechos por parte de un freelancer, un componente de código abierto copyleft mal utilizado, un vendor lock-in insuficientemente resuelto o una auditoría de licencias subestimada– pueden tener consecuencias graves en una fase posterior. Desde la reclamación de daños (como mínimo el doble del precio habitual de la licencia) y la responsabilidad penal por piratería de software, pasando por la necesidad de abrir el código fuente de un producto clave, hasta el bloqueo de una inversión o adquisición por los riesgos de PI detectados.
Los abogados del despacho ARROWS combinan un profundo conocimiento del Derecho checo y europeo de la propiedad intelectual, del software y de las TI con experiencia práctica en proyectos tecnológicos, operaciones de M&A y litigios sobre licencias. Gracias a ello, pueden proponer a sus clientes soluciones no solo jurídicamente correctas, sino también comercialmente razonables: desde la configuración de los contratos básicos en una startup, pasando por una auditoría integral de PI antes de una inversión, hasta la negociación de complejas estructuras de licencia y escrow en proyectos internacionales.
Si no quiere arriesgarse a errores, daños, retrasos, multas o la depreciación de un activo de software clave, es más seguro confiar la protección de la propiedad intelectual y la configuración de las licencias de software a los experimentados abogados del despacho ARROWS. Para una consulta sin compromiso sobre la situación concreta de su empresa, puede escribirnos en cualquier momento a consultas@arws.cz.
Preguntas frecuentes
1. ¿En qué fase de crecimiento tiene sentido abordar la protección de la propiedad intelectual y las licencias con el despacho ARROWS?
La experiencia práctica demuestra que cuanto antes, más barato y eficaz resulta tratar los riesgos. En las startups tiene sentido establecer los contratos básicos y la estrategia de PI justo después del nacimiento del producto; en las scale-ups suele tocar una auditoría de PI antes de una inversión o de la expansión al extranjero, y en las empresas consolidadas se trata de la gestión a largo plazo de las licencias, del OSS y de las relaciones con proveedores. Si no está seguro de por dónde empezar, escriba una breve descripción de su situación a consultas@arws.cz y los abogados del despacho ARROWS le propondrán el procedimiento adecuado.
2. ¿Qué suele hacer el despacho ARROWS como primer paso con una nueva empresa tecnológica?
Normalmente se realiza un breve «screening»: una conversación con la dirección y un mapeo del producto, del modelo de negocio y de los contratos básicos, incluido el uso de OSS y los proveedores críticos. A partir de ello, los abogados proponen los pasos prioritarios, por ejemplo la adaptación de los contratos con los desarrolladores, la configuración de los contratos de licencia con los clientes o una política básica de OSS. Este procedimiento puede adaptarse al tamaño y al presupuesto de la empresa. Si desea realizar este screening, concierte una cita a través de consultas@arws.cz.
3. ¿Cómo puede ayudar el despacho ARROWS si ya estamos en plena negociación de una licencia con un gran cliente?
En esa situación, los abogados suelen analizar rápidamente el borrador de contrato recibido, identificar las cláusulas de riesgo (por ejemplo, una responsabilidad desproporcionada, una regulación problemática de la PI, vendor lock-in o SLA) y proponer una redacción alternativa. También pueden participar directamente en la negociación comercial o en una «redline call» y explicar los argumentos jurídicos de un modo que respete el objetivo comercial de la operación. Si actualmente se encuentra en una negociación de este tipo, envíe el borrador de contrato a consultas@arws.cz y el equipo del despacho ARROWS se pondrá en contacto con usted para indicarle los siguientes pasos.
4. ¿Puede el despacho ARROWS resolver también cuestiones de licencias y PI con elemento internacional?
Sí; gracias a su integración en la red ARROWS International, los abogados de ARROWS colaboran con socios en numerosas jurisdicciones y son capaces de coordinar estructuras de PI y de licencias para proyectos que implican, por ejemplo, a inversores estadounidenses o británicos, el registro de marcas dentro y fuera de la UE o la prestación de servicios SaaS en varios Estados. Además, el equipo local entiende la realidad regulatoria checa, de modo que el cliente recibe un resultado de utilidad práctica que tiene en cuenta tanto los requisitos checos como los extranjeros. Si tiene un proyecto transfronterizo, puede consultarlo con total confianza con el despacho ARROWS a través de consultas@arws.cz.
5. ¿Cómo actúa el despacho ARROWS si el problema ya se ha producido, por ejemplo una auditoría de licencias o un litigio sobre códigos fuente?
En situaciones de crisis es clave un análisis rápido de los hechos y de los documentos. Los abogados de ARROWS analizan primero el marco contractual, la documentación de licencias y las circunstancias técnicas, y después proponen una estrategia de representación, ya se trate de negociar con el fabricante del software durante la auditoría, de interponer una demanda o defenderse de ella o, en su caso, de solicitar medidas cautelares. Paralelamente, se suele buscar también una solución a más largo plazo para que una situación similar no se repita. Si ya se enfrenta a un problema, conviene ponerse en contacto cuanto antes a través de consultas@arws.cz, para que el despacho ARROWS pueda intervenir a tiempo.
Sobre el autor
Lea también:
- La patente europea con efecto unitario en la práctica: cómo defender eficazmente sus innovaciones frente a plagiadores en todo el mercado de la UE
- Tratamiento fiscal de las inversiones en TI y software: la frontera entre gasto corriente y activo en la digitalización de la empresa
- Implantación de la inteligencia artificial (IA): marco jurídico y gestión de riesgos
- El contrato de obra en 2026: experiencias actuales de los abogados
- Contratos y negociación
- Revocación con éxito de la denegación de una marca
- Una defensa precisa de ARROWS logró archivar un proceso penal por supuesto uso indebido de know-how
