¿Puedo vender un videojuego creado con código open source?

Open source no significa «sin dueño»

Aunque en la práctica del desarrollo exista cierta tendencia a equiparar «open source» con «uso libre» o incluso con «ausencia de restricciones», desde la perspectiva del Derecho de propiedad intelectual esa premisa es incorrecta.

El software open source no carece de titularidad, ni queda fuera del sistema de exclusiva: sigue siendo una obra protegida, respecto de la cual sus autores o titulares conceden una autorización de uso, modificación y distribución sometida a condiciones. Por tanto, la cuestión no es si el open source «puede usarse», sino en qué términos jurídicos puede integrarse en un videojuego y qué efectos produce sobre su explotación y titularidad.

Conviene además deshacer otra confusión frecuente, la que iguala open source con dominio público. Una obra en dominio público ha perdido la exclusiva y puede usarse sin permiso de nadie. Un programa open source está plenamente protegido y lo que hay es una licencia, es decir, una autorización con condiciones que su titular puede exigir. La diferencia no es terminológica: determina si tienes obligaciones o no las tienes.

Qué protege exactamente la ley

Para responder hay que partir del régimen jurídico aplicable a los programas de ordenador en Derecho español y europeo. En España, la Ley de Propiedad Intelectual dedica a esta materia su Título VII (artículos 95 a 104), y en el plano europeo la protección se articula, entre otros instrumentos, a través de la Directiva 2009/24/CE sobre protección jurídica de programas de ordenador.

Tres preceptos concretan lo que aquí importa:

• El artículo 96 dispone que los programas de ordenador quedan protegidos como obras literarias, y precisa algo que a menudo se pasa por alto: la protección alcanza al programa tanto en forma de código fuente como de código objeto. Es decir, distribuir únicamente el ejecutable no deja el asunto fuera del ámbito de la ley.
• El artículo 99 enumera los derechos de explotación, que comprenden la reproducción, la traducción, la adaptación, el arreglo o cualquier otra transformación del programa, y la distribución al público del original o de copias.
• El artículo 102 califica como infracción toda reproducción, traducción, adaptación o transformación realizada sin autorización.

La consecuencia esencial es clara: el código fuente preexistente del que partes sigue estando protegido, y su reutilización no supone una apropiación de titularidad, sino el ejercicio de una facultad concedida por licencia.

Dos planos que se mezclan: explotación y titularidad

Esto obliga a distinguir dos planos que en muchas conversaciones se solapan:

• Por un lado, la explotación comercial del videojuego.
• Por otro, la titularidad jurídica sobre el resultado desarrollado.

En cuanto a la explotación, la respuesta general es que sí, en principio puedes comercializar un videojuego que parte de código open source, incluso obteniendo un rendimiento económico directo mediante venta, licencias, distribución en plataformas o monetización indirecta.

Ahora bien, esa posibilidad no existe «con total libertad» en sentido técnico-jurídico, porque no deriva de un derecho originario tuyo sobre la totalidad del código, sino del marco de autorización delimitado por la licencia open source aplicable.

Aquí la licencia es el eje del análisis, porque define el perímetro de uso legítimo. Y conviene subrayar que ese perímetro no lo fija una etiqueta genérica («esto es open source»), sino el texto concreto de la licencia concreta que acompañaba a ese componente concreto. Dos librerías igualmente calificadas de open source pueden imponer obligaciones radicalmente distintas.

Licencias permisivas: MIT, BSD y Apache

Si la licencia es de carácter permisivo (como MIT, BSD o Apache) el sistema te permite normalmente usar, modificar e integrar ese código en un producto comercial sin obligación de publicar el resto de tu código fuente, siempre que respetes las cargas impuestas por la licencia.

Dichas cargas suelen consistir en:

• la conservación de avisos de copyright;
• la incorporación del texto de licencia;
• el mantenimiento de exclusiones de garantía;
• y, en determinados casos, la inclusión de notices o advertencias relativas a modificaciones.

Son obligaciones de cumplimiento sencillo, y precisamente por eso se descuidan. En un videojuego lo habitual es resolverlas con una pantalla de créditos o un apartado de «licencias de terceros» accesible desde el menú de opciones, que reproduzca los avisos y los textos de licencia de cada componente. No es una formalidad decorativa: es el cumplimiento material de la única contraprestación que esas licencias exigen.

En este escenario, la comercialización del videojuego es jurídicamente compatible con un modelo propietario, pero conviene precisar algo: no se trata de una libertad originaria e ilimitada, sino de una libertad derivada y condicionada. Puedes explotar el videojuego porque el titular originario del código te ha autorizado a hacerlo bajo ciertos términos. Si incumples esos términos, el uso deja de estar amparado por la licencia y puede reconducirse al terreno de la infracción de derechos de propiedad intelectual.

Licencias copyleft: GPL y variantes

Por el contrario, si el código de base está sujeto a licencias de tipo copyleft (por ejemplo GPL y, según el caso, otras variantes equivalentes) la situación cambia de manera estructural.

En esos supuestos, el uso, modificación e integración del código pueden quedar sometidos a obligaciones más intensas, como la necesidad de redistribuir el código fuente de la obra derivada o de mantener la misma licencia en determinadas partes del producto distribuido.

Es decir: no se impide necesariamente la comercialización, pero sí se condiciona severamente el modo en que el videojuego puede salir al mercado y el grado de cierre o apropiación exclusiva que puedes pretender sobre su código.

Dentro del propio copyleft hay grados, y la diferencia es económicamente relevante. Las licencias de copyleft fuerte tienden a proyectar sus obligaciones sobre el conjunto del producto distribuido. Las de copyleft débil (del tipo LGPL o MPL) suelen limitar la obligación al componente afectado y a sus modificaciones, permitiendo que el resto del juego permanezca cerrado. Determinar en cuál de los dos escenarios estás no es una cuestión de etiquetas, sino de analizar cómo se ha integrado técnicamente ese componente en tu producto.

Un apunte práctico para estudios: esta es la razón por la que el motor que elijas condiciona todo lo demás. Los motores propietarios se rigen por sus propios acuerdos de licencia, con sus propias obligaciones (que son otro análisis distinto), mientras que los motores publicados bajo licencias permisivas trasladan el problema a las librerías y dependencias que vayas añadiendo encima. El riesgo rara vez está en el motor: está en las decenas de dependencias que entran en el proyecto sin que nadie las apunte en ningún sitio.

De quién es realmente el código de tu videojuego

La segunda gran cuestión es la titularidad. Y aquí la respuesta debe formularse con precisión: sí eres titular de tu aportación original al videojuego, pero no eres, por el mero hecho de desarrollar el producto final, el único titular de todo el código si éste nace de un código open source preexistente.

Esto se debe a que el Derecho de autor no premia el ensamblaje como si extinguiera derechos anteriores. Si tu videojuego incorpora o transforma código preexistente, el autor original conserva sus derechos sobre ese código base, mientras que tú adquieres derechos sobre los elementos originales que hayas creado o añadido. Por tanto, desde un punto de vista técnico, no hay una absorción de titularidad, sino una superposición o concurrencia de capas de derechos sobre distintos componentes del mismo producto digital.

La ley lo dice expresamente

No es una construcción doctrinal: es lo que resulta del texto legal. El artículo 99 de la Ley de Propiedad Intelectual, al enumerar los actos sujetos a autorización, incluye la transformación del programa «sin perjuicio de los derechos de la persona que transforme el programa de ordenador». La propia norma reconoce, en la misma frase, que quien transforma adquiere derechos y que el titular originario los conserva. Esa es exactamente la superposición de capas de la que hablamos.

Dicho de forma más jurídica: el uso de open source no te convierte en titular del código preexistente, sino en licenciatario respecto del mismo. Tú eres autor (y en su caso titular, si no median cesiones laborales o contractuales) de las partes nuevas que cumplan el requisito de originalidad, pero el código originario sigue perteneciendo a sus autores o titulares iniciales.

Por eso, cuando un videojuego «nace» de open source, lo correcto no es afirmar que «todo el código es mío», sino que el videojuego integra elementos propios sometidos a titularidad originaria del desarrollador y elementos preexistentes explotados en virtud de una licencia de terceros.

Una capa más: el código que escriben tus empleados

Conviene añadir un matiz que en la práctica genera tantos problemas como el anterior. El artículo 97 de la Ley de Propiedad Intelectual establece que, cuando un trabajador asalariado crea un programa de ordenador en el ejercicio de sus funciones, los derechos de explotación corresponden al empresario, salvo pacto en contrario.

Para un estudio esto suele ser una buena noticia respecto de su plantilla, pero tiene dos lecturas que conviene tener presentes. La primera es que esa regla está pensada para la relación laboral, de modo que con colaboradores externos, freelances o contratistas la titularidad no se transmite sola: hace falta una cesión expresa por escrito. La segunda es que esa cesión, cuando existe, no puede alcanzar más de lo que el cedente tenía. Si el freelance integró en su entrega un componente open source, lo que te cede es su aportación, no la titularidad del componente de terceros.

Por qué esto afecta a tu discurso comercial

Este punto es esencial porque afecta directamente al discurso comercial y documental del estudio. Si un desarrollador presenta el videojuego como si la totalidad de su base de código fuera de su exclusiva creación, puede estar incurriendo en una formulación jurídicamente inexacta, e incluso problemática, si omite las obligaciones de atribución o licenciamiento impuestas por la base open source utilizada.

Y esto deja de ser teórico en dos momentos muy concretos: cuando firmas un contrato de publishing en el que declaras y garantizas ser titular de todo el material entregado, y cuando entra un inversor y encarga una revisión legal del estudio. En ambos casos alguien va a leer esa declaración con lupa, y una manifestación inexacta sobre titularidad puede activar las cláusulas de indemnidad que tú mismo has firmado.

Obra derivada: hasta dónde llega la calificación

Desde el punto de vista dogmático, el supuesto suele reconducirse al concepto de obra derivada o, cuando menos, a una creación que incorpora elementos preexistentes protegidos. La intensidad de esa calificación dependerá del grado de incorporación, transformación y dependencia del código originario.

Pero incluso sin entrar en debates excesivamente técnicos sobre interoperabilidad, linking o modularidad, hay una idea que permanece constante: cuando el nuevo desarrollo trae causa de una base open source identificable y protegida, la creación posterior no neutraliza la titularidad anterior.

Qué han dicho los tribunales

Durante años se discutió algo que hoy está resuelto: si incumplir una licencia de software es solo un incumplimiento contractual o si permite además ejercitar las acciones propias de la infracción de propiedad intelectual. La diferencia no es académica, porque de ella dependen las medidas cautelares disponibles, el régimen de cálculo de la indemnización y la propia estrategia procesal.

Sentencia del Tribunal de Justicia de la Unión Europea de 18 de diciembre de 2019 (asunto C-666/18, IT Development contra Free Mobile). El Tribunal resolvió que la vulneración de una cláusula de un contrato de licencia relativa a los derechos de propiedad intelectual (en aquel caso, la modificación del código fuente por parte del licenciatario) queda comprendida en el concepto de infracción a efectos de la Directiva 2004/48 sobre respeto de los derechos de propiedad intelectual. Dicho en corto: el titular puede acudir al régimen reforzado de protección de la propiedad intelectual, y no solo a la vía del incumplimiento contractual.

Sentencia de la Cour d'appel de París de 14 de febrero de 2024 (Entr'ouvert contra Orange). Es la resolución europea que mejor ilustra el coste real de estos incumplimientos. Orange había integrado la librería Lasso, distribuida bajo GNU GPL versión 2, en una plataforma de gestión de identidad que comercializó sin respetar las condiciones de la licencia. Tras un procedimiento que se prolongó más de doce años, el tribunal apreció infracción de derechos de autor y fijó una indemnización de 800.000 euros (500.000 por el perjuicio económico, 150.000 por los beneficios obtenidos por las sociedades demandadas y 150.000 por daño moral), a los que se sumaron 60.000 euros en concepto de gastos procesales.

No son resoluciones españolas, pero la primera es doctrina del Tribunal de Justicia y vincula la interpretación de la normativa aplicable en España, y la segunda muestra cómo se está aplicando ese criterio en un Estado miembro. La lectura para un estudio es directa: la idea de que «como mucho me obligarán a cumplir la licencia» ya no se sostiene.

Qué pasa si incumples la licencia

A efectos prácticos, todo lo anterior se traduce en tres consecuencias relevantes.

La primera es que puedes ser autor del videojuego en cuanto a su diseño, mecánicas concretas, narrativa, arte, música, niveles, interfaz, código adicional y estructura original desarrollada por ti, pero ello no elimina la titularidad de terceros sobre la base open source utilizada. La autoría sobre tu aportación y la existencia de derechos previos sobre el material de partida son perfectamente compatibles.

La segunda es que tu facultad de explotación está condicionada por la licencia del componente open source, no solo durante el desarrollo, sino también en el momento de la distribución. El verdadero control de riesgos no se agota en «haber podido usar el código», sino en verificar si el modo de lanzar el juego al mercado respeta todas las exigencias del régimen de licencia.

La tercera es que, si el componente open source utilizado estaba sujeto a obligaciones formales o materiales y no las cumples, el problema no es meramente reputacional o documental. El incumplimiento puede abrir la puerta a acciones de cesación, requerimientos de regularización, exigencia de cumplimiento de licencia e incluso reclamaciones indemnizatorias, en función del caso y de la jurisdicción implicada.

Hay además un efecto que suele pasar inadvertido y que en un videojuego es especialmente gravoso: buena parte de estas licencias prevén que el incumplimiento extingue la autorización concedida. Si la licencia decae, el uso posterior deja de tener amparo, y eso alcanza a un producto que ya está publicado, vendido y actualizándose. El coste no es el de rehacer una cláusula, sino el de reconstruir o retirar una parte del juego con el título ya en el mercado.

Lo que viene: el Reglamento de Ciberresiliencia

A este análisis se le va a sumar pronto una obligación de naturaleza distinta pero que apunta al mismo sitio: saber exactamente qué hay dentro de tu producto.

El Reglamento (UE) 2024/2847, conocido como Reglamento de Ciberresiliencia o Cyber Resilience Act, establece requisitos de ciberseguridad para los productos con elementos digitales que se comercializan en la Unión Europea, categoría en la que encaja el software destinado al consumidor. Entró en vigor en diciembre de 2024, las obligaciones de notificación de vulnerabilidades resultan aplicables desde septiembre de 2026 y el grueso del régimen desde el 11 de diciembre de 2027.

Lo relevante aquí es doble. Por un lado, el Reglamento introduce la figura del administrador de software libre (open-source steward), con un régimen de obligaciones aligerado respecto del fabricante, y deja fuera el software libre desarrollado al margen de una actividad comercial. Por otro, y esto sí afecta de lleno a cualquier estudio que publique, el cumplimiento pasa por documentar los componentes que integra el producto y gestionar sus vulnerabilidades a lo largo del tiempo.

Dicho de otro modo: el inventario de componentes de terceros, que hasta ahora era una buena práctica recomendable para no incumplir licencias, va camino de ser además una exigencia regulatoria. Quien lo tenga hecho por motivos de propiedad intelectual llegará con medio trabajo adelantado.

Comprobaciones antes de lanzar

Como el riesgo se concentra en la distribución, conviene revisar cada canal y cada entrega antes del lanzamiento:

• Steam, consolas y móvil: cada tienda impone sus propios términos, que se suman a los de la licencia open source.
• Publicación de binarios: distribuir el ejecutable ya es un acto de distribución a efectos de licencia, aunque no publiques el repositorio. Recuerda que el artículo 96 protege el programa tanto en código fuente como en código objeto.
• Actualizaciones y parches: cada entrega posterior vuelve a activar las obligaciones.
• SDK incluidos: los kits de terceros que empaquetas con el juego arrastran sus propias licencias.
• Repositorios compartidos: lo que se comparte con publishers, porteadores o socios también cuenta.
• Inventario de componentes: una lista viva de cada librería, su versión y su licencia. Es la única forma de responder en un día a una revisión legal, y pronto será además materia regulatoria.

En definitiva, la formulación jurídicamente correcta sería la siguiente: sí, un videojuego construido a partir de open source puede comercializarse, incluso de forma lucrativa, siempre que la licencia del código base lo permita y se respeten íntegramente sus condiciones. Pero no puede afirmarse, con rigor, que el desarrollador sea el único titular del código del videojuego cuando éste incorpora o deriva de código open source preexistente, ya que la titularidad sobre ese código originario permanece en sus autores, coexistiendo con los derechos del desarrollador sobre su aportación original.

O, dicho aún más claro:

• Sí puedes venderlo.
• Sí puedes ser titular de lo que tú has creado.
• No eres automáticamente titular exclusivo de todo el código.
• No tienes libertad absoluta al margen de la licencia del open source de partida.

La clave jurídica, por tanto, no está en si el videojuego «nace» de open source, sino en qué licencia regía ese material preexistente, qué parte del resultado final procede realmente de él y qué obligaciones sobreviven en la comercialización del producto final.

Preguntas frecuentes

Fuentes

• Real Decreto Legislativo 1/1996, texto refundido de la Ley de Propiedad Intelectual (BOE)
• Directiva 2009/24/CE sobre la protección jurídica de programas de ordenador (EUR-Lex)
• STJUE de 18 de diciembre de 2019, asunto C-666/18, IT Development contra Free Mobile (EUR-Lex)
• Cour d'appel de Paris, pôle 5 ch. 1, arrêt du 14 février 2024, Entr'ouvert contra Orange (Legalis)
• Reglamento (UE) 2024/2847 de Ciberresiliencia (EUR-Lex)
• Licencias aprobadas por la Open Source Initiative
• GNU General Public License v3.0