La mayoría de los publishers que encargan un juego de tragaperras cree que está comprando el juego. En términos de derechos de autor, normalmente está comprando permiso para usarlo. La Oficina de Propiedad Intelectual del Reino Unido expone la regla por defecto con claridad: cuando se encarga a otra persona u organización la creación de una obra protegida, «el primer titular legal de los derechos de autor es la persona u organización que creó la obra y no usted, el comitente, salvo que se acuerde lo contrario por escrito». Cuando el contrato no dice nada, un tribunal puede apreciar solo una licencia implícita, y la propia guía advierte de que esto «no conduce necesariamente a una transmisión de la titularidad», de modo que el comprador «puede obtener únicamente una licencia limitada y no exclusiva».
Esa frase resume el problema de contratación entero. Un juego no es una sola obra protegida, sino una pila de ellas: la build entregada, el arte, el modelo matemático, el audio, el framework reutilizable del estudio que sostiene todo lo anterior y los componentes de terceros dentro de ese framework. Cada capa puede pertenecer a un titular distinto. Un publisher que firma un documento de alcance y un calendario de pagos sin un desglose de componentes ha comprado un producto que quizá no pueda mover, reversionar, parchear ni entregar a un segundo estudio.
La decisión del comprador no es «queremos ser dueños de la propiedad intelectual». Es más concreta y más útil: para cada capa de la build, ¿necesitamos titularidad, una licencia perpetua o nada en absoluto, y qué artefacto demuestra que lo hemos obtenido? Esa pregunta pertenece al brief, junto a las comprobaciones de encargo de un juego de casino que cubren entrega, QA y aceptación.
El valor por defecto no es el acuerdo que crees haber hecho
Dos ideas equivocadas se repiten en los briefs de los publishers, y ambas son caras.
La primera es el «work for hire». Esa expresión procede de la práctica estadounidense del derecho de autor. La ley británica no tiene una doctrina equivalente para las obras por encargo; tiene cesión, y la Copyright, Designs and Patents Act 1988 exige que una cesión de derechos de autor conste por escrito y esté firmada por el cedente o en su nombre. Una plantilla importada que afirme que el estudio «reconoce que todo el trabajo es work made for hire» puede parecer contundente y no hacer nada en un contrato regido por el derecho británico. Lo que realmente transmite la titularidad es una cesión escrita, y debe identificar las obras.
La segunda idea equivocada es que pagar por el trabajo transmite los derechos. No lo hace. El pago compra el entregable y la licencia que conceda el contrato. La guía de la Oficina de Propiedad Intelectual menciona la excepción anterior a 1989 solo para ciertas fotografías y grabados por encargo, lo que recuerda hasta qué punto estas reglas son específicas: fuera de ese estrecho caso histórico, el comitente no adquiere nada por defecto.
Hay un segundo valor por defecto que conviene conocer. Cuando una obra la realiza un empleado en el ejercicio de su empleo, el empleador es el primer titular, salvo pacto en contrario. El personal del estudio produce, por tanto, obra que el estudio posee. Los freelancers del estudio normalmente no: la guía señala que quien trabaja bajo un contrato de servicios «normalmente conservará los derechos de autor de las obras que produzca, salvo que exista un acuerdo contractual en contrario». Así que la titularidad del comprador depende de si la propia documentación de contratistas del estudio cedió esas aportaciones hacia el estudio. Es una cuestión de cadena de titularidad, y tiene respuesta antes de firmar.
Separa la build en capas antes de discutir la palabra «propiedad»
Una sola frase —«el publisher es dueño de toda la propiedad intelectual»— esconde cinco cosas distintas que se comportan de forma distinta en la práctica. Pide al estudio que desglose la build en estas capas y marque cada una.
El título entregado. El juego concreto tal como se lanza: la implementación de sus reglas, el flujo de pantallas, la build certificada. Es la capa que un publisher casi siempre quiere cedida en bloque, porque es aquello a lo que se vinculan la licencia, la certificación y la relación con el operador.
El framework reutilizable del estudio. La mayoría de los estudios construye sobre su propia biblioteca de componentes: un controlador de giros, una máquina de estados de features, un arnés matemático, una capa de localización. Esto no es el juego; es la maquinaria que el estudio amortiza entre clientes. Los estudios suelen negarse a cederla, y esa negativa es razonable. Lo que importa es que el publisher obtenga una licencia lo bastante amplia para ejecutar, mantener y modificar el título entregado sin el permiso continuo del estudio.
Componentes de terceros. Una build contiene runtimes, tipografías, librerías de audio y SDK que no pertenecen a ninguna de las dos partes. El publisher no necesita poseerlos; necesita saber cuáles son, qué permiten sus licencias y si la licencia sobrevive al fin de la relación con el estudio. Un inventario es el mínimo.
Propiedad de marca y personajes. Un juego por encargo suele llevar personajes, símbolos y world-building originales. Son obras separadas con su propia cadena desde el concept art hasta el asset final, y un publisher que planifique secuelas o merchandising necesita también el material de la fase de concepto, no solo los sprites enviados.
Las aportaciones del propio publisher. Las marcas, la lista de mercados, la especificación matemática y los assets que aporte el operador se quedan con el publisher. El brief debe decirlo de forma explícita, porque la plantilla estándar de un estudio a menudo reclamará la cesión de todo lo que tocó.
Este mapa de capas es también la respuesta honesta a una pregunta que los compradores hacen demasiado tarde: ¿qué pasa si nos separamos? Una cesión del título más una licencia perpetua sobre el framework es un reparto viable. La cesión de todo rara vez se concede. La licencia sobre todo es el resultado que deja al publisher atrapado.
Cesión, licencia y escrow son tres instrumentos diferentes
La cesión transmite la titularidad. Debe identificar las obras, los derechos (reproducción, adaptación, distribución, comunicación al público), el territorio y el plazo. Debe otorgarse en la entrega o en el pago final, no prometerse en una propuesta. Los derechos morales —el derecho a ser identificado y el derecho a oponerse a un trato denigrante— permanecen en el creador salvo renuncia; la ley británica permite la renuncia, y un publisher que planee alterar un título debería pedirla por escrito.
La licencia concede permiso mientras la titularidad sigue en el estudio. Una licencia de framework es la respuesta comercial normal, pero sus términos deciden si resulta útil. Una licencia que se extingue cuando termina el acuerdo de desarrollo convierte el juego entregado en algo que el publisher no puede parchear. Exige términos perpetuos, irrevocables, mundiales, sublicenciables y transferibles, con derecho a modificar, y confirma que sobrevive a la insolvencia o la adquisición del estudio. Una licencia que no puede transferirse a un operador sucesor no es una licencia sobre la que un publisher pueda construir un producto.
El escrow es continuidad, no titularidad. El código fuente en manos de un agente independiente, liberado con detonantes definidos —insolvencia, abandono, un fallo sostenido en la corrección de un defecto de severidad uno— da al publisher una salida sin obligar al estudio a regalar su framework. El acuerdo debe especificar qué se deposita (el código fuente completo compilable, los componentes del framework en la revisión entregada, la cadena de herramientas y las instrucciones de build), con qué frecuencia y cómo se activa la liberación. Un escrow que deposita una instantánea no compilable cumple la cláusula y no la necesidad.
Los tres instrumentos responden a tres miedos distintos. La cesión responde a «de quién es esto». La licencia responde a «podemos seguir ejecutándolo». El escrow responde a «qué pasa si el estudio desaparece». Un brief que elige uno ha dejado dos miedos sin gestionar.
La cadena de titularidad es un entregable, no una promesa
El fallo más común en la propiedad intelectual de juegos por encargo no es un estudio hostil. Es un estudio honesto que usó tres freelancers para el arte de personajes y uno para el lecho de audio, y nunca obtuvo cesiones escritas de ellos. El estudio cree que posee el arte porque lo pagó. Según la regla por defecto, puede que no lo posea, y no puede ceder al publisher lo que no tiene.
Por eso el paquete de entrega necesita un expediente de cadena de titularidad, no una garantía. Como mínimo: un calendario de colaboradores que nombre a cada persona y empresa que creó cualquier parte de las obras entregadas; el instrumento de cesión o licencia de cada uno; una confirmación escrita del estudio de que sus acuerdos con contratistas ceden las aportaciones al estudio; y la renuncia a derechos morales de los colaboradores nombrados. Si un colaborador no puede identificarse o localizarse, eso es un defecto del entregable, no una nota al pie.
La misma disciplina se aplica al inventario de terceros. Una lista de materiales de software con cada componente, versión y licencia —más el texto de la licencia o un enlace al mismo— convierte «usamos algunas piezas de código abierto» en un calendario auditable. Dos preguntas importan más que la lista: ¿alguna licencia obliga al publisher a revelar o licenciar su propio código fuente?, y ¿la licencia de algún componente caduca cuando el estudio deja de pagar un asiento comercial? Una licencia de runtime por asiento que el estudio mantenía para su propio equipo no cubre automáticamente al futuro mantenedor del publisher.
Nada de esto exige un abogado en la primera reunión. Exige que el comprador pida los artefactos pronto, cuando el estudio todavía puede cambiar su plantilla sin renegociar un contrato firmado. El coste de un desglose de componentes al inicio es una reunión; el coste de descubrir el hueco durante una migración es el producto.
La prueba práctica: ¿podría un segundo estudio asumirlo?
Hay una pregunta de aceptación que atraviesa la redacción de cualquier cláusula de propiedad intelectual. Si el publisher entregara la build, la documentación y la liberación del escrow a un estudio distinto, ¿podría ese estudio reconstruir, parchear y reenviar el juego sin pedir permiso al estudio original?
Si la respuesta es sí, el publisher tiene lo que necesita: una cesión o una licencia suficientemente amplia sobre el título, una licencia de framework transferible, un inventario completo de terceros y un depósito de código fuente compilable. Si la respuesta es no —porque la licencia del framework no es transferible, porque el arte de un freelancer nunca se cedió o porque las instrucciones de build solo viven en la cabeza del equipo original—, entonces el publisher compró una dependencia con un juego adherido.
Esa prueba también es la forma justa de negociar. Permite al estudio conservar su framework reutilizable mientras da al publisher una salida creíble, y convierte la conversación sobre titularidad en una cuestión de evidencias en lugar de confianza. En una build sobre Engine, la misma prueba recorre también la capa de plataforma: el motor pertenece a la plataforma, el framework del estudio se sitúa por encima y la capa del título es lo que debe cerrar el encargo. El brief de proyecto Engine es la vía para solicitar un presupuesto de proyecto con el reparto de titularidad, los términos de licencia y los artefactos de entrega acordados antes de empezar la producción.
Cuando un publisher encarga una secuencia de títulos en lugar de uno solo, el mapa de capas se convierte en un activo de cartera: una licencia de framework negociada una vez puede cubrir varios juegos, siempre que el acuerdo se redacte para permitirlo. Es una conversación más barata que repetir la misma negociación de propiedad intelectual para cada título, y más clara que suponer que cada encargo parte del mismo valor por defecto.
Preguntas frecuentes
¿De quién son los derechos de autor de un juego de tragaperras por encargo?
Por defecto, son de la persona u organización que creó la obra, no del comitente. La guía de la Oficina de Propiedad Intelectual del Reino Unido establece que, cuando se encarga una obra protegida, el primer titular legal es el creador salvo que la titularidad se acuerde por escrito. Un publisher que quiera poseer el juego entregado necesita una cesión escrita; de lo contrario, puede tener solo una licencia implícita, limitada y no exclusiva.
¿Basta la fórmula «work for hire» para transmitir la titularidad en el Reino Unido?
No. «Work made for hire» es una doctrina estadounidense y no tiene equivalente directo en el Reino Unido para las obras por encargo. Según la Copyright, Designs and Patents Act 1988, una cesión de derechos de autor debe constar por escrito y estar firmada por el cedente o en su nombre. Un brief que usa la expresión sin una cesión escrita que identifique las obras puede no transmitir nada.
¿El estudio es dueño del trabajo creado por sus freelancers?
Normalmente lo es el freelancer, salvo acuerdo escrito en contrario. La excepción del empleador se aplica a los empleados: cuando una obra la realiza un empleado en el ejercicio de su empleo, el empleador es el primer titular. Quien trabaja bajo un contrato de servicios conserva normalmente los derechos de autor de lo que produce. Por eso un expediente de cadena de titularidad y las cesiones de contratistas del estudio pertenecen al paquete de entrega.
¿Debería un publisher exigir la cesión del framework del estudio?
Rara vez, y normalmente sin éxito. El framework reutilizable de un estudio es la maquinaria que amortiza entre clientes, y la mayoría lo licenciará en lugar de cederlo. La exigencia útil es una licencia perpetua, irrevocable, mundial, transferible y sublicenciable para usar, modificar y mantener el título entregado, respaldada por un escrow de código fuente con detonantes de liberación definidos.
¿Qué debe contener el paquete de entrega a efectos de propiedad intelectual?
Un desglose de componentes que asigne cada capa de la build a su titular; la cesión ejecutada del título; los términos de la licencia del framework; un inventario de terceros o lista de materiales de software con sus licencias; un calendario de colaboradores con cesiones o renuncias para cada creador nombrado; y el acuerdo de escrow que describa qué se deposita y cuándo se libera. Cada elemento es verificable antes del pago final, a diferencia de una garantía en una propuesta.
