Home > Soluzioni > ICT Legal > Blog > Proprietà intellettuale > Modelli di sviluppo Open e titolarità del software
Modelli di sviluppo Open e titolarità del software Stampa
Proprietà intellettuale
Scritto da Gianluca Craia   

Gli interventi modificativi del codice sorgente di un programma software sono riconducibili a tre grandi categorie: la ricombinazione del codice, l’aggiunta di moduli di tipo plug-in ed il linking. Se per l’ultima categoria l’applicazione è generalmente limitata alle librerie di funzioni, le altre due opzioni possono verificarsi in ogni tipo di intervento modificativo che riguardi il codice sorgente.

In questa sede verrà trattato il problema della categorizzazione delle modifiche in questi ultimi due casi, lasciando l’analisi del linking ad altro articolo. Si premette che l'argomento di trattazione è la titolarità delle modifiche dirette al codice originario e dei moduli associati via plug in. La titolarità delle opere derivate risultanti dalla modifica del codice sorgente originale, secondo quanto disposto dalla normativa sul diritto d'autore, attiene invece al livello di creatività dell'opera derivata.

 

Analizzando il modello di business alla base della logica di sviluppo del software open source, si riconosce il seguente schema: viene immesso in rete su uno spazio condiviso (ad esempio sourceforge.net) la bozza del progetto, costituito da una buona quantità di linee di codice il cui ordine, organizzazione e interazione costituisce lo scheletro del programma.Nella generalità dei casi il codice pubblicato e condiviso è funzionale ad uno scopo e in questo senso può dirsi creato, ma è comunque ad uno stato larvale e necessita di continui interventi correttivi e migliorativi. La condivisione mira proprio a questo risultato. La community interviene in maniera diffusa secondo il modello di sviluppo Bazaar (The Cathedral & the Bazaar, Raymond), non vi è un’assegnazione stringente dei tasks come nel modello classico di sviluppo (il c. d. modello Cathedral): la migliore soluzione nasce dalla condivisione e integrazione delle soluzioni proposte ed elaborate.

Le soluzioni ottenute hanno però bisogno di un ordine: è necessario che qualcuno ricopra il ruolo di coordinatore, supervisionando il lavoro, magari senza intervenire direttamente nello sviluppo. Il sistema è simile a quello applicato nella redazione di una testata giornalistica dove il capo redattore compone il giornale sulla base dei contributi dei singoli giornalisti. Continuando l'analogia, nel modello a bazaar non viene però assegnato nessun titolo al singolo giornalista, che è libero di sviluppare qualsiasi tema purchè collegato all'ambito di interesse del quotidiano stesso.

Un’analisi dei progetti open ritenuti di successo (uno per tutti Mozilla) evidenzia che per quanto il modello Bazaar venga utilizzato, è necessaria comunque la presenza di una sorta di autorità (in generale una fondazione) che si preoccupi di coordinare i contributi della community e ne tenga le fila.

Il processo descritto ha il suo culmine nella fase di rilascio del software. Nel modello classico il prodotto è rilasciato al termine del processo di produzione: è possibile avere varie versioni, ma, in linea generale, il software non ha bisogno di ulteriori interventi.

Nel modello Open, invece, non si ha mai una versione inamovibile: il progetto è costantemente in fase di Beta, in continuo miglioramento grazie alla possibilità di accesso e modifica al codice sorgente.

Perché il progetto mantenga la propria coerenza, i continui interventi hanno bisogno di essere disciplinati: ciò di norma viene fatto imponendo una licenza che regoli la distribuzione e la possibilità di modifica. Ma ciò non è sufficiente.

Ad esempio, dotare la licenza di copyleft ha il sicuro vantaggio di impedire la chiusura del codice da parte degli utilizzatori/licenziatari, ma nulla dice rispetto alla titolarità degli interventi modificativi al codice.

Chi deve essere considerato autore delle linee di codice inserite a scopo migliorativo/correttivo nel programma iniziale?

La questione necessita di essere trattata partendo dall’analisi di alcuni articoli della vigentel 633/1941 (L.D.A.):

L’art 4 della LDA disciplina i contributi che, se sufficientemente creativi, possono costituire un’opera derivata, da tutelarsi indipendentemente dall’opera originaria e senza pregiudizio dei diritti esistenti su quest’ultima.

L’art 7 della LDA disciplina i contributi che, quando non sussistano i requisiti per costituire opera derivata, ma siano distinguibili e scindibili dall’opera originaria, sono soggetti all’applicazione della disciplina delle opere collettive, in forza della quale ciascun contributo potrà avere autonoma protezione, mentre autore dell’opera risultante dall’unione dei vari contributi sarà chi ha organizzato e diretto la creazione dell’opera stessa.

Il modello di business su tratteggiato sembra essere richiamato più nella norma dell’art. 7 che in quella dell’art. 4: secondo questa interpretazione, i continui interventi migliorativi/correttivi/integrativi, in quanto non caratterizzati da una sostanziale autonomia creativa, potranno essere inseriti e organizzati tra loro nell’ unico progetto dal quale dipendono. In ultima analisi sarà il coordinatore ad avere la titolarità dell’opera e poter decidere con quale/quali licenza e rilasciare il prodotto.

Una leggera distinzione invece necessita il caso in cui l’intervento dei contributori al progetto avvenga tramite l’associazione di moduli via plug-in.

In questo caso il coordinatore del progetto sarà sì titolare dei diritti sull’opera, ma i singoli contributi potranno essere comunque utilizzati autonomamente dai loro materiali autori. A fronte di ciò ben potrebbe accadere che il plug-in sia coperto nell’opera da una licenza (quella disposta dal titolare dei diritti sull’opera collettiva/composta) e, contemporaneamente, sia rilasciato dal suo materiale autore con altra licenza autonomamente, ovvero in altro lavoro indipendente. In ogni caso, in capo al coordinatore del progetto rimane la facoltà di scelta rispetto al rilascio dell’opera collettiva composita realizzata tramite le elaborazioni dei vari contributori.

cc_somerights20