¿De quién es el código fuente que un colaborador sin contrato aporta a tu videojuego? ¿Puede obligarte a retirarlo?

Qué ha pasado con Skyblivion

Skyblivion es un proyecto sin ánimo de lucro del grupo de modding TES Renewal Project, que reconstruye The Elder Scrolls IV: Oblivion con el motor de Skyrim. Lo hacen voluntarios y, según recoge Eurogamer, Bethesda lo tolera con la condición de que se sustituyan todos los recursos del juego original.

Según el comunicado que el equipo publicó el 30 de octubre, y que ha recogido la prensa especializada, un voluntario dejó el proyecto y las dos partes no se pusieron de acuerdo sobre el uso y el mantenimiento del código que había aportado. Al equipo se le retiró el acceso al repositorio original, y para poder corregir fallos y mantener ese sistema en funcionamiento descompiló parte del código. El antiguo colaborador respondió, siempre según el equipo, con amenazas legales y con la exigencia de conocer los nombres reales y los domicilios de los responsables.

El equipo afirma que ha consultado a un abogado y que está «completely confident in our right to maintain the code they submitted», es decir, plenamente seguro de su derecho a mantener el código aportado. Aun así decidió eliminarlo y reconstruir el sistema entero para proteger a sus voluntarios. Dos cautelas antes de seguir. Solo conocemos la versión del equipo, porque el antiguo colaborador no ha hablado en público, y no consta que la demanda se haya presentado.

Lo que me interesa del caso es lo que tiene de corriente. Un proyecto que crece con gente que entra y sale, sin un solo papel firmado, y un sistema del juego que depende del código de alguien que ya no está. Le puede pasar igual a un mod que a un estudio indie de cinco personas.

La propiedad intelectual del código fuente nace en quien lo escribe

En España el código de un videojuego se protege como programa de ordenador, por derechos de autor, tanto en su versión fuente como en su versión compilada. Lo que no se protege son las ideas y los principios en los que se basa, de acuerdo con el artículo 96 de la Ley de Propiedad Intelectual. La mecánica es libre, pero la forma concreta en que alguien la ha programado tiene dueño.

Ese dueño es, de entrada, quien escribe el código. El artículo 97.1 de la ley considera autor del programa a «la persona o grupo de personas naturales que lo hayan creado». No hace falta registro ni aviso de copyright, porque el derecho nace con la creación. Registrar el código o depositarlo sirve para probar quién lo tenía y en qué fecha, pero no decide de quién es.

A partir de ahí, la ley solo contempla dos caminos para que el código acabe siendo del estudio. El primero es que lo haya escrito un trabajador. El segundo es que su autor lo haya cedido.

El empleado, el freelance y el voluntario no están en la misma situación

El trabajador asalariado. Es el único caso en que la ley hace el trabajo por el estudio. Cuando un empleado crea un programa en el ejercicio de sus funciones o siguiendo instrucciones del empresario, los derechos de explotación corresponden «exclusivamente, al empresario, salvo pacto en contrario», tanto sobre el código fuente como sobre el código objeto. Lo dice el artículo 97.4.

El freelance. No hay regla equivalente. El programador externo que factura por un sistema de inventario, por el netcode o por una herramienta interna sigue siendo el titular de lo que escribe hasta que lo ceda. Y la cesión tiene dos exigencias que casi nadie cumple cuando el encargo se cierra por Discord. Debe formalizarse por escrito, según el artículo 45, y solo alcanza a lo que diga de forma expresa. Si el contrato no fija el tiempo, la cesión dura cinco años. Si no fija el territorio, vale solo para el país en que se firmó. Si no detalla las modalidades de explotación, queda limitada a la que se deduzca necesariamente del propio contrato y sea indispensable para cumplir su finalidad. Todo esto sale del artículo 43, y es el motivo por el que una factura con el concepto «desarrollo de software» no acredita que el código sea tuyo.

El voluntario, el amigo y el socio de hecho. Es el caso de Skyblivion y el de muchos estudios que empiezan. No hay salario y no hay contrato, así que no hay ni presunción legal ni cesión escrita. Quien aporta código en esas condiciones conserva todos sus derechos sobre él.

De quién es la propiedad intelectual del código fuente cuando no hay nada firmado

Que no haya documento no significa que el estudio esté usando el código sin permiso. Quien sube su trabajo al repositorio común de un proyecto para que se integre en el juego lo está autorizando con sus propios actos. El problema es hasta dónde llega esa autorización y cuánto dura, porque todo lo que no esté escrito se discutirá después, y la ley empuja la respuesta hacia lo mínimo indispensable.

Cuando el conflicto estalla, el estudio suele apoyarse en una de estas dos figuras.

• La obra en colaboración. Si el juego es el resultado unitario del trabajo de varios autores, los derechos son de todos ellos en la proporción que acuerden, y así lo prevén los artículos 7 y 97.3. Tiene una ventaja para el proyecto, y es que una vez divulgada la obra ningún coautor puede negarse sin justificación a que se siga explotando en la forma en que se divulgó. Y tiene un coste alto, porque para modificarla hace falta el consentimiento de todos y, si no hay acuerdo, decide el juez.
• La obra colectiva. Si el juego se crea por iniciativa y bajo la coordinación de una persona o de una empresa que lo edita y lo divulga con su nombre, y las aportaciones se funden en una creación única, los derechos corresponden a quien la edita y divulga, salvo pacto en contrario. Es lo que establecen los artículos 8 y 97.2, y es la figura que más conviene a un estudio. Ahora bien, hay que probar esa iniciativa y esa coordinación, y es difícil sostenerla cuando el colaborador ha desarrollado por su cuenta un módulo que se puede separar del resto.

Ninguna de las dos sustituye a un contrato. Las dos obligan a pleitear para saber cuál se aplica, y ese es exactamente el escenario que hay que evitar.

¿Puede el colaborador obligarte a retirar su código?

Depende de lo que se pueda probar, y por eso la respuesta honesta es que puede intentarlo y que el resultado es incierto.

El titular de un derecho de propiedad intelectual puede pedir el cese de la actividad que lo infringe y la indemnización de los daños, y puede solicitar medidas cautelares urgentes antes de que haya sentencia. Son las acciones del artículo 138 de la ley. Un colaborador que sostenga que su permiso era limitado, o que lo ha retirado, tiene por tanto una vía para pedir que su código salga del juego. El estudio se defenderá con la autorización que se deduce de los hechos y con las dos figuras del apartado anterior. Quien no tenga un papel llega a esa discusión con los correos, los mensajes y el historial del repositorio como única prueba.

Hay además un derecho que ningún contrato elimina. El autor puede exigir siempre que se reconozca su condición de autor, porque es uno de los derechos morales del artículo 14, que son irrenunciables. En la práctica son los créditos. Quitar de ellos a quien se ha ido enfadado es la forma más rápida de regalarle un argumento.

Y hay un coste que llega aunque nadie demande. Lo primero que revisa un publisher antes de firmar, y un inversor antes de entrar, es la cadena de titularidad, es decir, que cada pieza del juego tenga detrás un documento que diga de quién es. Un sistema escrito por alguien que no firmó nada es un hueco en esa cadena, y se traduce en una rebaja del precio, en una garantía personal de los socios o en una firma que se retrasa hasta que aparezca el papel. Lo explicamos al hablar de la banda sonora compuesta por un freelance, donde el problema es idéntico.

¿Es legal descompilar un juego? Ingeniería inversa y caso Top System

Descompilar es reconstruir el código fuente a partir del programa compilado. Como supone reproducir y transformar el código, es un acto reservado al titular. La ley lo permite sin su autorización en dos supuestos.

Para corregir errores. El artículo 100.1 de la Ley de Propiedad Intelectual permite al usuario legítimo reproducir y transformar el programa, «incluida la corrección de errores», cuando sea necesario para utilizarlo conforme a su finalidad, salvo disposición contractual en contrario. El Tribunal de Justicia de la Unión Europea aclaró el alcance de esta regla en su sentencia de 6 de octubre de 2021, en el asunto C-13/20, Top System. Un organismo público belga había descompilado parte de un programa que tenía licenciado para desactivar una función que fallaba, y el desarrollador lo demandó. El Tribunal declaró que el adquirente legítimo de un programa «tiene derecho a descompilar total o parcialmente dicho programa con el fin de corregir errores que afecten a su funcionamiento», sin tener que cumplir los requisitos previstos para la interoperabilidad.

La misma sentencia marca los límites, y son los que importan en un caso como el de Skyblivion.

• La descompilación tiene que ser necesaria. No lo es cuando el código fuente es accesible para el usuario por ley o por contrato, como dice el apartado 63. Si al equipo se le retiró el acceso al repositorio, como sostiene, ese dato es el que puede hacer necesaria la descompilación.
• Solo se puede descompilar en la medida necesaria para la corrección y respetando lo pactado con el titular. El contrato puede regular cómo se corrigen los errores, por ejemplo encargando el mantenimiento al propio autor, pero no puede excluir toda posibilidad de corregirlos, según los apartados 66 y 67.
• El resultado no se puede usar para otra cosa. Ni para desarrollar un programa similar ni para distribuir el código obtenido, de acuerdo con los apartados 69 a 72.

Para la interoperabilidad. Los apartados 5 a 7 del artículo 100 permiten descompilar cuando sea indispensable para que un programa creado de forma independiente funcione con otros, con requisitos estrictos. Solo las partes necesarias, solo si la información no estaba disponible de manera fácil y rápida, y sin usar lo obtenido para crear un programa sustancialmente similar.

Las dos excepciones tienen un punto de partida común. Protegen al usuario legítimo, es decir, a quien tiene derecho a usar el programa. Y eso devuelve la discusión al principio, porque el estudio que no puede acreditar su permiso sobre el código tampoco tiene fácil acreditar que lo descompiló con derecho. La falta de papel contamina también esta defensa.

El contrato de cesión de derechos del software que tu estudio debe firmar antes de la primera línea de código

Desde NN Agency recomendamos que nadie toque el repositorio sin haber firmado antes un acuerdo de colaboración, aunque sea un amigo y aunque no cobre. Estos son los puntos que no pueden faltar.

• Cesión de derechos por escrito y en exclusiva. La exclusiva tiene que decirse de forma expresa, como exige el artículo 48. Si no se dice, la cesión no es exclusiva y el autor puede dar el mismo código a otro.
• Modalidades, tiempo y territorio. Reproducción, distribución, comunicación pública y transformación, en todas las plataformas, para todo el mundo y por toda la duración de los derechos. Lo que no se nombre no se entiende cedido.
• Versiones sucesivas y obras derivadas. El artículo 100.4 ya impide al autor oponerse a que el cesionario haga versiones sucesivas del programa, salvo pacto en contrario. Conviene dejarlo escrito y extenderlo a secuelas, ports y DLC.
• El repositorio es del estudio. Las cuentas, los accesos y las copias las controla la sociedad, no la persona que montó el servidor el primer día. Y el código se entrega siempre en fuente, documentado.
• Qué pasa si se va. Entrega de todo el material, mantenimiento durante un periodo de transición y confirmación de que la cesión sigue en pie aunque la relación se acabe mal.
• Créditos. Cómo y dónde aparecerá su nombre, también si deja el proyecto.
• Código de terceros. Declaración de que lo aportado es original y lista de las librerías de código abierto que incluye, con sus licencias. Lo vimos en cómo comercializar un videojuego que usa código open source.
• Confidencialidad. El código y las herramientas internas son también un secreto empresarial, y se protegen como explicamos en cómo proteger el know-how de un estudio.

Si el proyecto es abierto o comunitario, como un mod, la alternativa es publicar el código bajo una licencia de código abierto y exigir a cada colaborador que acepte sus términos al contribuir. Los mods tienen además su propio problema con el titular del juego original, que tratamos en de quién es un mod.

Y si ya hay código de alguien que no firmó, el momento de regularizarlo es ahora, mientras la relación es buena. Una cesión firmada hoy cuesta una conversación. La misma cesión, pedida la semana antes de cerrar con un publisher, tiene precio. El resto de frentes que conviene dejar atados los repasamos en los aspectos legales de crear un videojuego en 2026.

Preguntas frecuentes

Fuentes

• Ley de Propiedad Intelectual, artículos 5, 7, 8, 14, 43, 45, 48, 96, 97, 100 y 138, BOE, texto consolidado
• Sentencia del Tribunal de Justicia de 6 de octubre de 2021, Top System, asunto C-13/20, EUR-Lex
• Directiva 2009/24/CE, sobre la protección jurídica de programas de ordenador, EUR-Lex
• Eurogamer, el equipo de Skyblivion dice que un antiguo voluntario amenaza con demandar por una disputa sobre el código, 31 de octubre de 2026