El software de código abierto ha dejado de ser patrimonio de comunidades de desarrolladores para convertirse en el núcleo técnico de compañías de todos los sectores. Hoy, una plataforma de gestión empresarial, un sistema de control industrial o un producto SaaS pueden incorporar decenas de componentes de código abierto sin que el equipo directivo tenga plena conciencia de ello. Y ahí reside la oportunidad perdida que más lamentamos en nuestra práctica: empresas que construyen valor sobre activos que no controlan.
El código abierto no es un tipo de software gratuito. Es un modelo de distribución basado en licencias que otorgan al destinatario derechos de uso, estudio, modificación y redistribución, pero que imponen condiciones a cambio. Esas condiciones son obligaciones contractuales y, en última instancia, obligaciones jurídicas.
En nuestra experiencia asesorando a empresas tecnológicas en España, la confusión más extendida es precisamente esta: los equipos de desarrollo asumen que "gratuito" equivale a "sin restricciones". El riesgo no está en el coste de la licencia, sino en las condiciones de redistribución, atribución y, sobre todo, en las cláusulas de copyleft.
El copyleft es la obligación, presente en ciertas licencias, de distribuir cualquier obra derivada bajo la misma licencia que el componente original. Para una empresa que desarrolla software propietario o que mantiene un secreto empresarial sobre su código, incorporar un componente con una licencia de copyleft fuerte puede forzar la publicación de todo el código del producto. Ese escenario no es teórico: ha provocado litigios internacionales y ha bloqueado operaciones de inversión y adquisición.
¿Por qué afecta esto al consejo de administración? Porque el valor del intangible tecnológico, que en muchas empresas constituye el activo más relevante, puede quedar comprometido sin que la alta dirección haya tomado ninguna decisión consciente al respecto.
La regulación jurídica del software en España descansa sobre tres pilares que interactúan entre sí.
El primero es la legislación de propiedad intelectual. El software se protege como obra literaria, lo que significa que el titular de los derechos de autor conserva el control sobre su reproducción, distribución y transformación. Una licencia de código abierto no extingue esos derechos: los moviliza de forma condicionada. El incumplimiento de las condiciones de la licencia no genera simplemente una responsabilidad contractual; puede constituir una infracción de los derechos de autor del titular original.
El segundo pilar es el contrato de licencia. Cada componente de código abierto que una empresa incorpora a su producto viene acompañado de un acuerdo de licencia cuyas condiciones son vinculantes. Las licencias más permisivas, como MIT o BSD, exigen únicamente la inclusión de un aviso de atribución. Las licencias de copyleft fuerte, como la GPL, exigen que cualquier obra derivada se distribuya bajo las mismas condiciones. Las licencias de copyleft débil, como la LGPL o la MPL, presentan matices relevantes que conviene analizar caso a caso.
El tercer pilar es la protección del secreto empresarial. La legislación española en materia de secretos empresariales, transpuesta desde una directiva de la Unión Europea, exige que la empresa adopte medidas razonables para mantener el carácter secreto de la información. Si una parte del código propietario queda expuesta por el cumplimiento forzoso de una licencia de copyleft, la empresa puede perder la protección que el régimen del secreto empresarial le confería. Una vez divulgado el secreto, esa pérdida es irreversible.
Además, en operaciones transfronterizas, conviene verificar qué ley rige la licencia y qué tribunal o árbitro tiene competencia para conocer de posibles controversias, ya que muchas licencias de origen anglosajón contienen cláusulas de sumisión que pueden no ser operativas en España sin un análisis previo.
No todas las licencias de código abierto son iguales. Clasificarlas correctamente es el primer paso del análisis jurídico.
Las licencias permisivas (MIT, BSD 2-Clause, Apache 2.0) imponen obligaciones mínimas: conservar los avisos de atribución y, en el caso de Apache 2.0, incluir una copia de la propia licencia. Son compatibles con el desarrollo de software propietario. Sin embargo, Apache 2.0 contiene cláusulas sobre patentes que conviene revisar en contextos donde la empresa es titular o licenciataria de patentes tecnológicas.
Las licencias de copyleft débil (LGPL, MPL, EUPL) permiten la integración en software propietario bajo ciertas condiciones. La clave está en el tipo de enlace o integración entre el componente abierto y el código propietario. Un enlace dinámico puede tratarse de forma diferente a uno estático. Este detalle técnico tiene consecuencias jurídicas directas y requiere un análisis conjunto con el equipo de desarrollo.
Las licencias de copyleft fuerte (GPL v2, GPL v3, AGPL) son las más restrictivas. La AGPL extiende la obligación de distribución incluso cuando el software se presta como servicio a través de una red, lo que la convierte en la licencia de mayor impacto para los modelos de negocio SaaS. Una empresa que sirve un producto basado en software con licencia AGPL puede quedar obligada a publicar su código fuente completo aunque nunca distribuya el software en sentido estricto.
En nuestra práctica hemos observado que las empresas que gestionan productos SaaS suelen desconocer el impacto de la AGPL hasta que aparece en el proceso de diligencia debida (due diligence) de una ronda de inversión o una operación de compraventa de empresa.
El riesgo jurídico del código abierto no es estático. Se activa en momentos concretos del ciclo de vida de la empresa, y en cada uno de esos momentos la dirección tiene un margen de actuación que se estrecha con el tiempo.
El primer momento crítico es la distribución del producto. En tanto el software permanece en uso interno, las obligaciones de las licencias de copyleft no se activan plenamente. En el momento en que el producto se distribuye a terceros, o se presta como servicio en el caso de la AGPL, las obligaciones contractuales devengan exigibles. Actuar antes de la primera distribución es siempre más eficiente que remediar una situación de incumplimiento.
El segundo momento crítico es la ronda de inversión o la operación de M&A. Todo inversor institucional y toda contraparte en una adquisición realizará una diligencia debida tecnológica que incluirá un análisis del inventario de componentes de código abierto (el llamado Software Bill of Materials o SBOM). Si ese inventario no existe, si hay licencias incompatibles o si la empresa no puede acreditar el cumplimiento de sus obligaciones, la operación puede quedar bloqueada, el valor se reduce o se imponen garantías adicionales.
El tercer momento crítico es la protección de la propiedad industrial. El registro de marcas ante la Oficina Española de Patentes y Marcas (OEPM) y ante la Oficina de Propiedad Intelectual de la Unión Europea (EUIPO) debe planificarse antes de que el producto llegue al mercado, no después. La marca en España dura diez años renovables desde la fecha de registro, y el plazo de oposición a una solicitud de marca ajena es de dos meses desde su publicación. Dejar pasar esa ventana tiene costes que van mucho más allá del procedimiento de registro.
El cuarto momento crítico es la contratación con clientes y socios. Si el producto incorpora componentes de código abierto bajo licencias que exigen atribución o divulgación, los contratos de licencia con clientes deben contemplar esas obligaciones de forma expresa. De lo contrario, la empresa puede enfrentarse a reclamaciones por incumplimiento contractual simultaneas a las que pueda plantear el titular del componente de código abierto.
La gestión del riesgo empieza por el conocimiento. Una empresa no puede cumplir obligaciones que desconoce.
El primer paso es la realización de un inventario técnico-jurídico de todos los componentes de código abierto presentes en el producto. Este inventario, conocido como SBOM, debe identificar para cada componente: el nombre y la versión, la licencia aplicable, el modo de integración y la presencia de restricciones relevantes. Existen herramientas automatizadas de análisis de composición de software que facilitan esta tarea, pero su resultado debe ser revisado por un especialista para extraer conclusiones jurídicas.
El segundo paso es la clasificación de riesgos. No todos los componentes presentan el mismo nivel de exposición. La prioridad la marcan los componentes con licencias de copyleft fuerte integrados en módulos que forman parte del núcleo del producto distribuido o servido a terceros.
El tercer paso es la implementación de una política interna. La política debe establecer qué licencias están aprobadas para su uso sin revisión adicional, cuáles requieren aprobación caso a caso y cuáles están prohibidas. Esta política debe integrarse en el proceso de desarrollo y mantenerse actualizada, ya que las versiones de los componentes pueden cambiar de licencia entre actualizaciones.
Hemos protegido marcas, software y secretos empresariales de compañías tecnológicas e industriales que en su momento carecían de este tipo de estructura. La diferencia entre actuar en la fase de diseño del producto y actuar cuando ya existe un conflicto o una operación corporativa en curso es significativa, tanto en términos de coste como de opciones disponibles.
El código abierto no existe en el vacío. Para la empresa tecnológica, la estrategia de propiedad industrial e intelectual debe contemplar de forma integrada el software, la marca, las eventuales patentes sobre procedimientos técnicos y la protección del secreto empresarial.
La marca identifica el producto ante el mercado y ante los inversores. El registro ante la OEPM protege el territorio nacional; el registro de marca UE ante la EUIPO extiende la protección a todos los estados miembros de la Unión Europea. Que el código sobre el que corre el producto sea abierto, cerrado o mixto no afecta a la titularidad de la marca. Sin embargo, si la empresa no registra su marca antes de lanzar el producto, un tercero puede anticiparse y hacerlo.
Las patentes, gestionadas ante la OEPM para el territorio nacional o a través de los procedimientos europeos para una protección más amplia, protegen invenciones técnicas. El software puro no es patentable en Europa, pero los procedimientos técnicos implementados mediante software sí pueden serlo si cumplen los requisitos de novedad e inventiva. Con una duración de veinte años no renovables, la patente otorga un monopolio de explotación que puede ser relevante para tecnologías diferenciadas. Conviene verificar, además, que el uso de componentes de código abierto bajo licencias como Apache 2.0 no conlleva concesiones de licencias implícitas sobre patentes propias.
El secreto empresarial es, en muchos casos, el instrumento más adecuado para proteger algoritmos, modelos de inteligencia artificial o metodologías propias, especialmente cuando no se quiere revelar la invención a través del proceso de patente. Pero el secreto solo existe mientras se mantiene en secreto. La política de control del código abierto y la política de secreto empresarial deben diseñarse conjuntamente para evitar que la una neutralice a la otra.
¿Qué sucede cuando una empresa descubre que parte de su know-how protegido como secreto ha quedado expuesta por un incumplimiento en la gestión de licencias de código abierto? La respuesta corta es que la empresa pierde una protección que no puede recuperar. La respuesta larga implica analizar si existe alguna vía de reclamación frente a quien provocó la divulgación, pero esa vía siempre es más costosa e incierta que la prevención.
En la contratación entre empresas, las obligaciones derivadas del código abierto pueden trasladarse contractualmente de forma expresa o quedar latentes por omisión. Ambas situaciones generan riesgo.
Cuando una empresa contrata el desarrollo de software a medida con un proveedor externo, debe exigir que el contrato incluya: una declaración del proveedor sobre los componentes de código abierto utilizados, las licencias aplicables y la compatibilidad con el uso previsto por el cliente. Sin esa declaración, el cliente puede encontrarse con un producto que no puede distribuir o que requiere la publicación de su código.
Cuando una empresa licencia su software a terceros, el contrato de licencia debe contemplar con precisión qué derechos otorga, qué restricciones impone y cómo gestiona las obligaciones derivadas de los componentes de código abierto incorporados. Una cláusula de indemnización que haga recaer sobre el licenciante las consecuencias de incumplimientos en materia de código abierto no cumplimentados correctamente puede ser determinante en un eventual conflicto.
Los acuerdos de confidencialidad (NDA, por sus siglas en inglés) en operaciones que implican acceso al código fuente deben ser especialmente cuidadosos. Si el código que se comparte en el marco de una diligencia debida o de una colaboración tecnológica incluye componentes de código abierto con obligaciones de atribución o divulgación, el NDA no puede contradecir esas obligaciones. La interacción entre el acuerdo de confidencialidad y las obligaciones de las licencias de código abierto debe analizarse antes de la firma.
En nuestra experiencia, los conflictos más recurrentes en este ámbito se producen precisamente en la fase de integración postfusión, cuando dos empresas fusionan sus bases de código y descubren incompatibilidades de licencias que ninguna de las dos había detectado durante la diligencia debida.
La prevención es siempre menos costosa que el remedio. Esta afirmación, que puede sonar a lugar común, tiene una traducción práctica muy concreta en el ámbito del código abierto corporativo.
El coste de revisar el inventario de licencias y establecer una política interna antes del lanzamiento de un producto es marginal en relación con el coste de una reclamación judicial por infracción de derechos de autor, de la pérdida de valor en una operación de M&A o de la divulgación forzosa del código propietario.
Un asesoramiento temprano permite a la empresa elegir: qué componentes incorporar, bajo qué licencias, con qué estructura de integración y con qué salvaguardas contractuales. Cuando el problema ya ha aflorado, esas opciones se reducen drásticamente.
Además, la presencia de una política documentada de gestión del código abierto es, en sí misma, un argumento de valor ante inversores y adquirentes. Demuestra que la dirección gestiona sus riesgos de forma proactiva y que el activo tecnológico está bajo control. En un contexto donde la valoración de empresas tecnológicas descansa en gran medida sobre sus activos intangibles, esa demostración tiene un impacto económico real.
Si su empresa está en fase de desarrollo de producto, de preparación para una ronda de financiación o de expansión internacional, el momento para ordenar la estrategia de propiedad intelectual y la gestión del código abierto es ahora. Cuanto más avanzado esté el producto y más cerca el evento corporativo, más estrecho será el margen de maniobra.
¿Tiene su empresa un inventario actualizado de los componentes de código abierto que utiliza? Si la respuesta no es afirmativa e inmediata, conviene actuar antes de que la respuesta la dé un inversor, un adquirente o una reclamación judicial.
Las siguientes verificaciones permiten a la dirección identificar las áreas de exposición más comunes y priorizar las acciones de mejora.
Este checklist no sustituye un análisis jurídico específico. Es un punto de partida para que la dirección identifique dónde existen lagunas y cuándo es necesario acudir a asesoramiento especializado.
La gestión jurídica del código abierto se integra en una estrategia más amplia de protección de la propiedad intelectual e industrial de la empresa. En nuestra área de Propiedad intelectual y tecnología abordamos desde el registro de marcas y patentes hasta la estructuración de contratos de licencia y la protección del secreto empresarial, con un enfoque orientado a la empresa y a sus operaciones.
Para empresas del sector inmobiliario y de la construcción que también utilizan software y herramientas tecnológicas en su actividad, el análisis de los riesgos específicos de ese entorno está desarrollado en nuestro análisis sectorial sobre código abierto en el sector inmobiliario y de la construcción. Asimismo, si su empresa se encuentra ante una situación concreta que involucra acuerdos sobre propiedad intelectual con terceros, puede consultar el caso práctico sobre acuerdos de coexistencia para ilustrar cómo se estructura la negociación y qué factores determinan el resultado.
Para una primera valoración, escríbanos a info@velardevidal.com.
Plantear mi casoEste contenido es informativo y no constituye asesoramiento jurídico. Para un análisis de su situación, contacte con info@velardevidal.com.