Di chi è un gioco slot su commissione? Codice, framework e domande sulla proprietà intellettuale

La maggior parte dei publisher che commissiona un gioco slot crede di comprare il gioco. In termini di diritto d’autore, di solito sta comprando il permesso di usarlo. L’Ufficio della Proprietà Intellettuale del Regno Unito enuncia la regola predefinita con chiarezza: quando si commissiona a un’altra persona o organizzazione la creazione di un’opera protetta, «il primo titolare legale del diritto d’autore è la persona o l’organizzazione che ha creato l’opera e non il committente, salvo che sia diversamente concordato per iscritto». Quando il contratto non dice nulla, un tribunale può riconoscere solo una licenza implicita, e la guida stessa avverte che ciò «non comporta necessariamente un trasferimento della titolarità», per cui il committente «può ottenere soltanto una licenza limitata e non esclusiva».

Quella frase riassume l’intero problema di approvvigionamento. Un gioco non è una sola opera protetta, ma una pila di opere: la build consegnata, l’arte, il modello matematico, l’audio, il framework riutilizzabile dello studio che sostiene tutto il resto e i componenti di terze parti dentro quel framework. Ogni strato può appartenere a un titolare diverso. Un publisher che firma un documento di perimetro e un calendario di pagamenti senza una mappa dei componenti ha comprato un prodotto che forse non può spostare, rifare, aggiornare o affidare a un secondo studio.

La decisione del compratore non è «vogliamo possedere la proprietà intellettuale». È più stretta e più utile: per ogni strato della build, ci serve la titolarità, una licenza perpetua o nulla — e quale artefatto prova che l’abbiamo ottenuta? Questa domanda appartiene al brief, accanto ai controlli di commissione di un gioco da casinò che coprono consegna, QA e accettazione.

Il valore predefinito non è l’accordo che credi di aver fatto

Due idee sbagliate ricorrono nei brief dei publisher, ed entrambe costano care.

La prima è il «work for hire». Quell’espressione viene dalla prassi statunitense del diritto d’autore. La legge britannica non ha una dottrina equivalente per le opere su commissione; ha la cessione, e il Copyright, Designs and Patents Act 1988 richiede che una cessione del diritto d’autore sia per iscritto e firmata dal cedente o per suo conto. Un modello importato che affermi che lo studio «riconosce che tutto il lavoro è work made for hire» può sembrare decisivo e non fare nulla in un contratto retto dal diritto britannico. Ciò che trasferisce davvero la titolarità è una cessione scritta, e deve individuare le opere.

La seconda idea sbagliata è che pagare il lavoro trasferisca i diritti. Non è così. Il pagamento compra il deliverable e la licenza che il contratto concede. La guida dell’Ufficio della Proprietà Intellettuale cita l’eccezione anteriore al 1989 solo per talune fotografie e incisioni su commissione, il che ricorda quanto queste regole siano specifiche: fuori da quel ristretto caso storico, il committente non acquista nulla per impostazione predefinita.

C’è un secondo valore predefinito da conoscere. Quando un’opera è realizzata da un dipendente nell’esercizio del rapporto di lavoro, il datore di lavoro è il primo titolare, salvo patto contrario. Il personale dello studio produce quindi opera che lo studio possiede. I freelance dello studio di norma no: la guida afferma che chi lavora con un contratto di servizi «di solito conserva il diritto d’autore sulle opere che produce, salvo accordo contrattuale contrario». La titolarità del compratore dipende quindi dal fatto che la documentazione sui collaboratori dello studio abbia ceduto quelle contribuzioni allo studio. È una questione di catena di titolarità, e ha risposta prima della firma.

Separa la build in strati prima di discutere la parola «proprietà»

Una sola frase —«il publisher possiede tutta la proprietà intellettuale»— nasconde cinque cose diverse che si comportano diversamente nella pratica. Chiedi allo studio di scomporre la build in questi strati e di contrassegnare ciascuno.

Il titolo consegnato. Il gioco concreto così com’è lanciato: l’implementazione delle regole, il flusso delle schermate, la build certificata. È lo strato che un publisher quasi sempre vuole ceduto in blocco, perché è ciò a cui si legano la licenza, la certificazione e il rapporto con l’operatore.

Il framework riutilizzabile dello studio. La maggior parte degli studi costruisce sulla propria libreria di componenti: un controller dei giri, una macchina a stati delle feature, un arnese matematico, uno strato di localizzazione. Questo non è il gioco; è il macchinario che lo studio ammortizza tra i clienti. Gli studi di solito si rifiutano di cederlo, e il rifiuto è ragionevole. Ciò che conta è che il publisher ottenga una licenza abbastanza ampia da eseguire, mantenere e modificare il titolo consegnato senza il permesso continuo dello studio.

Componenti di terze parti. Una build contiene runtime, font, librerie audio e SDK che non appartengono a nessuna delle due parti. Il publisher non deve possederli; deve sapere quali sono, cosa consentono le loro licenze e se la licenza sopravvive alla fine del rapporto con lo studio. Un inventario è il minimo.

Proprietà di marchio e personaggi. Un gioco su commissione di solito porta personaggi, simboli e world-building originali. Sono opere separate con una propria catena dal concept art all’asset finale, e un publisher che pianifichi sequel o merchandising ha bisogno anche del materiale della fase di concept, non solo degli sprite consegnati.

I contributi del publisher stesso. I marchi, l’elenco dei mercati, la specifica matematica e gli asset forniti dall’operatore restano al publisher. Il brief deve dirlo esplicitamente, perché il modello standard di uno studio rivendicherà spesso la cessione di tutto ciò che ha toccato.

Questa mappa di strati è anche la risposta onesta a una domanda che i compratori fanno troppo tardi: cosa succede se ci separiamo? Una cessione del titolo più una licenza perpetua sul framework è una divisione praticabile. La cessione di tutto raramente viene concessa. La licenza su tutto è l’esito che lascia il publisher bloccato.

Cessione, licenza ed escrow sono tre strumenti diversi

La cessione trasferisce la titolarità. Deve individuare le opere, i diritti (riproduzione, adattamento, distribuzione, comunicazione al pubblico), il territorio e la durata. Va eseguita alla consegna o al pagamento finale, non promessa in una proposta. I diritti morali —il diritto a essere riconosciuto e il diritto di opporsi a un trattamento denigratorio— restano al creatore salvo rinuncia; la legge britannica consente la rinuncia, e un publisher che intenda modificare un titolo dovrebbe chiederla per iscritto.

La licenza concede il permesso mentre la titolarità resta allo studio. Una licenza di framework è la risposta commerciale normale, ma i suoi termini decidono se è utile. Una licenza che si estingue quando l’accordo di sviluppo finisce trasforma il gioco consegnato in qualcosa che il publisher non può aggiornare. Chiedi termini perpetui, irrevocabili, mondiali, sublicenziabili e trasferibili, con diritto di modifica, e conferma che sopravvive all’insolvenza o all’acquisizione dello studio. Una licenza che non può essere trasferita a un operatore successore non è una licenza su cui un publisher possa costruire un prodotto.

L’escrow è continuità, non titolarità. Il codice sorgente presso un agente indipendente, rilasciato con trigger definiti —insolvenza, abbandono, mancata correzione prolungata di un difetto di severità uno— dà al publisher una via d’uscita senza costringere lo studio a regalare il proprio framework. L’accordo deve specificare cosa viene depositato (il sorgente completo compilabile, i componenti del framework nella revisione consegnata, la toolchain e le istruzioni di build), con quale frequenza e come si attiva il rilascio. Un escrow che deposita uno snapshot non compilabile soddisfa la clausola e non l’esigenza.

I tre strumenti rispondono a tre paure diverse. La cessione risponde a «di chi è questo». La licenza risponde a «possiamo continuare a eseguirlo». L’escrow risponde a «e se lo studio sparisce». Un brief che ne sceglie uno ha lasciato due paure senza gestione.

La catena di titolarità è un deliverable, non una promessa

Il guasto più comune nella proprietà intellettuale dei giochi su commissione non è uno studio ostile. È uno studio onesto che ha usato tre freelance per l’arte dei personaggi e uno per il tappeto audio, e non ha mai ottenuto cessioni scritte da loro. Lo studio crede di possedere l’arte perché l’ha pagata. Secondo la regola predefinita, può non possederla — e non può cedere al publisher ciò che non ha.

Per questo il pacchetto di consegna ha bisogno di un fascicolo di catena di titolarità, non di un’assicurazione. Come minimo: un calendario dei collaboratori che nomini ogni persona e azienda che ha creato qualsiasi parte delle opere consegnate; lo strumento di cessione o licenza di ciascuno; una conferma scritta dello studio che i suoi accordi con i collaboratori cedono i contributi allo studio; e la rinuncia ai diritti morali dei collaboratori nominati. Se un collaboratore non è identificabile o rintracciabile, è un difetto del deliverable, non una nota a piè di pagina.

La stessa disciplina vale per l’inventario di terze parti. Una distinta dei materiali software con ogni componente, versione e licenza —più il testo della licenza o un link— trasforma «abbiamo usato qualche pezzo open source» in un calendario verificabile. Due domande contano più dell’elenco: qualche licenza obbliga il publisher a divulgare o licenziare il proprio sorgente, e la licenza di qualche componente decade quando lo studio smette di pagare una postazione commerciale? Una licenza runtime per postazione che lo studio teneva per il proprio team non copre automaticamente il futuro manutentore del publisher.

Niente di tutto ciò richiede un avvocato al primo briefing. Richiede che il compratore chieda gli artefatti presto, quando lo studio può ancora cambiare il proprio modello senza rinegoziare un contratto firmato. Il costo di una mappa dei componenti al via è una riunione; il costo di scoprire la lacuna durante una migrazione è il prodotto.

Il test pratico: un secondo studio potrebbe subentrare?

C’è una domanda di accettazione che attraversa la formulazione di qualsiasi clausola di proprietà intellettuale. Se il publisher consegnasse la build, la documentazione e il rilascio dell’escrow a uno studio diverso, quello studio potrebbe ricostruire, aggiornare e reinviare il gioco senza chiedere permesso allo studio originale?

Se la risposta è sì, il publisher ha ciò che serve: una cessione o una licenza sufficientemente ampia sul titolo, una licenza di framework trasferibile, un inventario completo di terze parti e un deposito di sorgente compilabile. Se la risposta è no —perché la licenza del framework non è trasferibile, perché l’arte di un freelance non è mai stata ceduta o perché le istruzioni di build vivono solo nella testa del team originale— allora il publisher ha comprato una dipendenza con un gioco attaccato.

Quel test è anche il modo equo di negoziare. Consente allo studio di tenere il proprio framework riutilizzabile mentre dà al publisher un’uscita credibile, e trasforma la conversazione sulla titolarità in una questione di prove invece che di fiducia. In una build su Engine, lo stesso test attraversa anche lo strato di piattaforma: il motore appartiene alla piattaforma, il framework dello studio sta sopra e lo strato del titolo è ciò che la commissione deve chiudere. Il brief di progetto Engine è la via per richiedere un preventivo di progetto con la divisione di titolarità, i termini di licenza e gli artefatti di consegna concordati prima dell’inizio della produzione.

Quando un publisher commissiona una sequenza di titoli invece di uno solo, la mappa degli strati diventa un attivo di portafoglio: una licenza di framework negoziata una volta può coprire più giochi, purché l’accordo sia redatto per consentirlo. È una conversazione più economica che ripetere la stessa negoziazione di proprietà intellettuale per ogni titolo — e più chiara che presumere che ogni commissione parta dallo stesso valore predefinito.

Domande frequenti

Di chi è il diritto d’autore di un gioco slot su commissione?

Per impostazione predefinita è della persona o organizzazione che ha creato l’opera, non del committente. La guida dell’Ufficio della Proprietà Intellettuale del Regno Unito stabilisce che, quando si commissiona un’opera protetta, il primo titolare legale è il creatore salvo che la titolarità sia concordata per iscritto. Un publisher che voglia possedere il gioco consegnato ha bisogno di una cessione scritta; altrimenti può detenere solo una licenza implicita, limitata e non esclusiva.

La formula «work for hire» basta a trasferire la titolarità nel Regno Unito?

No. «Work made for hire» è una dottrina statunitense e non ha un equivalente diretto nel Regno Unito per le opere su commissione. Secondo il Copyright, Designs and Patents Act 1988, una cessione del diritto d’autore deve essere per iscritto e firmata dal cedente o per suo conto. Un brief che usa l’espressione senza una cessione scritta che individui le opere può non trasferire nulla.

Lo studio possiede il lavoro creato dai suoi freelance?

Di solito lo possiede il freelance, salvo accordo scritto contrario. L’eccezione del datore di lavoro vale per i dipendenti: quando un’opera è realizzata da un dipendente nell’esercizio del rapporto di lavoro, il datore di lavoro è il primo titolare. Chi lavora con un contratto di servizi conserva normalmente il diritto d’autore su ciò che produce. Per questo un fascicolo di catena di titolarità e le cessioni dei collaboratori dello studio appartengono al pacchetto di consegna.

Un publisher dovrebbe pretendere la cessione del framework dello studio?

Raramente, e di solito senza successo. Il framework riutilizzabile di uno studio è il macchinario che ammortizza tra i clienti, e la maggior parte lo licenzia invece di cederlo. La richiesta utile è una licenza perpetua, irrevocabile, mondiale, trasferibile e sublicenziabile per usare, modificare e mantenere il titolo consegnato, sostenuta da un escrow del sorgente con trigger di rilascio definiti.

Cosa deve contenere il pacchetto di consegna ai fini della proprietà intellettuale?

Una mappa dei componenti che assegni ogni strato della build al suo titolare; la cessione eseguita del titolo; i termini della licenza del framework; un inventario di terze parti o distinta dei materiali software con le licenze; un calendario dei collaboratori con cessioni o rinunce per ogni creatore nominato; e l’accordo di escrow che descriva cosa viene depositato e quando viene rilasciato. Ogni voce è verificabile prima del pagamento finale, a differenza di un’assicurazione in una proposta.