I primi a muoversi in questo senso furono proprio alcuni degli
artefici di Mozilla, i quali sotto la guida di Eric Raymond costituirono la Open Source Initiative (di cui
abbiamo già parlato) con lo scopo appunto di farsi supremi custodi e garanti del concetto di ‘software Open
Source’. Come base per questo progetto, la OSI raccolse i suoi esperti di informatica e di diritto per stilare
una sorta di documento-decalogo in cui venissero delineati gli standard secondo i quali un software potesse
essere definito Open Source: la Open Source Definition, ovvero la ‘definizione di open source’. Fedele alla sua vocazione di “statuto dei diritti dell’utente” questo testo focalizza la centralità di tre diritti primari che la tipologia di distribuzione del software deve rispettare:
- il diritto di fare copie del programma e di ridistribuirle liberamente,
- il diritto di accesso al codice sorgente,
- il diritto di poter intervenire sul programma e modificarlo. Dunque la Open Source Definition (OSD) non è un modello di licenza per software opensource (come
qualcuno potrebbe pensare) bensì una “specifica di quanto è ammesso in una licenza software perché possa
essere considerata Open Source” ; può esser vista, in un certo senso, come una “licenza per le licenze”.
Dopo una breve introduzione che ammonisce il lettore a non considerare ‘Open Source’ come
semplice sinonimo di ‘disponibilità del sorgente’, il documento si estrinseca in 10 sezioni che da un lato
chiariscono e riconfermano alcuni principi cardine del software libero, dall’altro ne creano alcuni
indipendenti ed appositi per il concetto di Open Source.
Per esempio, nel primo gruppo, ovvero quello coerente a grandi linee con quanto abbiamo già incontrato a proposito della GPL, possiamo inserire la ‘Sezione 1’ (sulla libertà della ridistribuzione), la ‘Sezione 2’ (sulla disponibilità del codice sorgente), la ‘Sezione 3’ (sulla possibilità di apporre modifiche e realizzare così opere derivate), le ‘Sezioni 5 e 6’ (sul divieto di discriminazione di persone o settori di applicazione). Altre disposizioni sembrano invece allontanarsi dalle finalità della GPL: basti pensare alla ‘Sezione 9’ (sui rapporti fra diversi regimi di licenza), la quale stabilisce che “la licenza non deve contaminare altro software”: letto così, tale imperativo sembrerebbe concepito solo ed appositamente per contrapporsi alla ‘viralità’ della GPL, ma ad un’attenta lettura si può notare che la sezione in esame si riferisce non alla derivazione ma alla mera aggregazione; cioè non si riferisce alla miscelazione di codice libero/aperto con codice proprietario (derivazione), bensì alla distribuzione su un unico media (CD-ROM o floppy-disk) di un software Open Source e di uno proprietario (aggregazione).
Molto interessante dal punto di vista giuridico la ‘Sezione 7’, che sottolinea la trasposizione automatica degli effetti della licenza a tutti coloro ai quali il programma è ridistribuito senza necessità di alcuna firma o di necessità di una ulteriore licenza per ogni “gradino” della distribuzione. Un discorso a parte merita invece la ‘Sezione 10’, recentemente novellata per intero a causa dei problemi di poca lungimiranza ed elasticità che il suo dettato denotava. Nella versione originale essa faceva cenno ad alcune “licenze esemplari” da considerarsi modelli conformi alla OSD, che erano la GNU GPL, la BSD, la X Consortium e la Licenza Artistica; questa elencazione avrebbe però creato problemi di interpretazione della OSD nel caso (nemmeno molto improbabile) che una di queste fosse stata modificata così da risultare invece incompatibile col concetto di Open Source. Si è deciso così di eliminare ogni richiamo preciso ad alcune licenze e di sostituirlo con una nuova sezione del tutto diversa ma stavolta molto lungimirante e scaltra: s’introduce il concetto (finora non ufficialmente contemplato dai “manifesti” del movimento Opensource) della neutralità della tecnologia. Si proibisce infatti di usare la licenza di un software Open Source per creare eventuali privilegi in ambito hardware; la libertà del software diventa quindi un by-pass per toccare un altro tema scottante: le implicazioni col diritto industriale fra hardware, software e disciplina antitrust. Infatti, per il già citato fenomeno delle network externalities, i diritti di proprietà d’intellettuale possono avere ‘effetti di rete’ limitativi della libertà di scelta del consumatore. Questa dunque la breve enunciazione della ‘Sezione 10’: “La licenza dev’essere tecnologicamente neutrale. Nessuna condizione della licenza può essere prevista per qualche particolare tecnologia o tipo di interfaccia.” Eliminato dunque dalla OSD ogni richiamo formale ed esplicito ad alcune licenze, la OSI però intraprese comunque – come abbiamo già accennato – un’opera di cernita e monitoraggio delle licenze in circolazione, definendo nel sito ufficiale del progetto quali di queste andassero intese come “Open Source compatibili”. L’obbiettivo della OSI, a dire il vero, è molto più ambizioso: cioè addirittura trasformarsi in una specie di “consorzio” che vigili sulla corretta interpretazione e applicazione della Open Source Definition, attribuisca una certificazione ai prodotti che ne rispettavano i principi e apponga su di essi un marchio di garanzia. Inizialmente è stata richiesta la registrazione dell’espressione “Open Source” come marchio, ma l’autorità americana a ciò preposta non l’ha accettata poiché troppo generica e descrittiva; la OSI ha dunque optato per il meno equivocabile “OSI certified”, cioè “certificato dalla OSI”. La OSI quindi non solo consente l’uso dell’espressione Open Source per i software che rispettino i criteri della OSD, ma autorizza su di essi l’apposizione ufficiale del marchio registrato; si crea così un riconoscimento più forte di quello che abbiamo simbolicamente chiamato “patrocinio”, espressione più calzante per la prassi utilizzata dalla FSF . Sul sito ufficiale della OSI si trova un’apposita pagina web contenente i termini e le formalità utili per perfezionare il procedimento di apposizione del marchio e i file d’immagine in diversi formati con lo stemma grafico da inserire sui supporti stampati: la formula ufficiale è “ This software is OSICertified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative” (cioè, “Questo software è un software Open Source certificato dalla OSI. ‘OSI certified’ è un marchio di certificazione della Open Source Initiative”). Nel sito, inoltre è presente un elenco costantemente aggiornato di tutte le licenze che hanno appunto ricevuto tale riconoscimento, così da consentire all’utente di verificare in tempo reale l’effettiva corrispondenza di un software ai requisiti della OSD ed ovviare eventuali abusi. Tornando all’analisi esplicativa e comparativa compiuta da Perens nel suo saggio
-manifesto, è possibile rileggere le principali licenze di software che abbiamo fin qui esaminato alla luce dei criteri della Open Source Definition, rilevando quattro fondamentali aspetti:
- la possibilità che il codice (sotto quella particolare licenza) venga miscelato con codice di matrice commerciale; - la possibilità che le modifiche apportate al codice siano mantenute, senza quindi essere restituite all’autore originale;
la possibilità che il codice così realizzato venga liberamente ri-licenziato da chiunque; - la permanenza di alcuni privilegi speciali sulle modifiche per chi detiene il copyright originale. E’ possibile ora costruire un tabella a doppia entrata che metta in relazione questi parametri con le caratteristiche delle sei modalità di distribuzione che abbiamo esaminato: ovvero la GNU GPL, la GNU LGPL, la BSD license, la Netscape Public License, la Mozilla Public License e infine il dominio pubblico
Open Source e opere non software:
Per esempio, nel primo gruppo, ovvero quello coerente a grandi linee con quanto abbiamo già incontrato a proposito della GPL, possiamo inserire la ‘Sezione 1’ (sulla libertà della ridistribuzione), la ‘Sezione 2’ (sulla disponibilità del codice sorgente), la ‘Sezione 3’ (sulla possibilità di apporre modifiche e realizzare così opere derivate), le ‘Sezioni 5 e 6’ (sul divieto di discriminazione di persone o settori di applicazione). Altre disposizioni sembrano invece allontanarsi dalle finalità della GPL: basti pensare alla ‘Sezione 9’ (sui rapporti fra diversi regimi di licenza), la quale stabilisce che “la licenza non deve contaminare altro software”: letto così, tale imperativo sembrerebbe concepito solo ed appositamente per contrapporsi alla ‘viralità’ della GPL, ma ad un’attenta lettura si può notare che la sezione in esame si riferisce non alla derivazione ma alla mera aggregazione; cioè non si riferisce alla miscelazione di codice libero/aperto con codice proprietario (derivazione), bensì alla distribuzione su un unico media (CD-ROM o floppy-disk) di un software Open Source e di uno proprietario (aggregazione).
Molto interessante dal punto di vista giuridico la ‘Sezione 7’, che sottolinea la trasposizione automatica degli effetti della licenza a tutti coloro ai quali il programma è ridistribuito senza necessità di alcuna firma o di necessità di una ulteriore licenza per ogni “gradino” della distribuzione. Un discorso a parte merita invece la ‘Sezione 10’, recentemente novellata per intero a causa dei problemi di poca lungimiranza ed elasticità che il suo dettato denotava. Nella versione originale essa faceva cenno ad alcune “licenze esemplari” da considerarsi modelli conformi alla OSD, che erano la GNU GPL, la BSD, la X Consortium e la Licenza Artistica; questa elencazione avrebbe però creato problemi di interpretazione della OSD nel caso (nemmeno molto improbabile) che una di queste fosse stata modificata così da risultare invece incompatibile col concetto di Open Source. Si è deciso così di eliminare ogni richiamo preciso ad alcune licenze e di sostituirlo con una nuova sezione del tutto diversa ma stavolta molto lungimirante e scaltra: s’introduce il concetto (finora non ufficialmente contemplato dai “manifesti” del movimento Opensource) della neutralità della tecnologia. Si proibisce infatti di usare la licenza di un software Open Source per creare eventuali privilegi in ambito hardware; la libertà del software diventa quindi un by-pass per toccare un altro tema scottante: le implicazioni col diritto industriale fra hardware, software e disciplina antitrust. Infatti, per il già citato fenomeno delle network externalities, i diritti di proprietà d’intellettuale possono avere ‘effetti di rete’ limitativi della libertà di scelta del consumatore. Questa dunque la breve enunciazione della ‘Sezione 10’: “La licenza dev’essere tecnologicamente neutrale. Nessuna condizione della licenza può essere prevista per qualche particolare tecnologia o tipo di interfaccia.” Eliminato dunque dalla OSD ogni richiamo formale ed esplicito ad alcune licenze, la OSI però intraprese comunque – come abbiamo già accennato – un’opera di cernita e monitoraggio delle licenze in circolazione, definendo nel sito ufficiale del progetto quali di queste andassero intese come “Open Source compatibili”. L’obbiettivo della OSI, a dire il vero, è molto più ambizioso: cioè addirittura trasformarsi in una specie di “consorzio” che vigili sulla corretta interpretazione e applicazione della Open Source Definition, attribuisca una certificazione ai prodotti che ne rispettavano i principi e apponga su di essi un marchio di garanzia. Inizialmente è stata richiesta la registrazione dell’espressione “Open Source” come marchio, ma l’autorità americana a ciò preposta non l’ha accettata poiché troppo generica e descrittiva; la OSI ha dunque optato per il meno equivocabile “OSI certified”, cioè “certificato dalla OSI”. La OSI quindi non solo consente l’uso dell’espressione Open Source per i software che rispettino i criteri della OSD, ma autorizza su di essi l’apposizione ufficiale del marchio registrato; si crea così un riconoscimento più forte di quello che abbiamo simbolicamente chiamato “patrocinio”, espressione più calzante per la prassi utilizzata dalla FSF . Sul sito ufficiale della OSI si trova un’apposita pagina web contenente i termini e le formalità utili per perfezionare il procedimento di apposizione del marchio e i file d’immagine in diversi formati con lo stemma grafico da inserire sui supporti stampati: la formula ufficiale è “ This software is OSICertified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative” (cioè, “Questo software è un software Open Source certificato dalla OSI. ‘OSI certified’ è un marchio di certificazione della Open Source Initiative”). Nel sito, inoltre è presente un elenco costantemente aggiornato di tutte le licenze che hanno appunto ricevuto tale riconoscimento, così da consentire all’utente di verificare in tempo reale l’effettiva corrispondenza di un software ai requisiti della OSD ed ovviare eventuali abusi. Tornando all’analisi esplicativa e comparativa compiuta da Perens nel suo saggio
-manifesto, è possibile rileggere le principali licenze di software che abbiamo fin qui esaminato alla luce dei criteri della Open Source Definition, rilevando quattro fondamentali aspetti:
- la possibilità che il codice (sotto quella particolare licenza) venga miscelato con codice di matrice commerciale; - la possibilità che le modifiche apportate al codice siano mantenute, senza quindi essere restituite all’autore originale;
la possibilità che il codice così realizzato venga liberamente ri-licenziato da chiunque; - la permanenza di alcuni privilegi speciali sulle modifiche per chi detiene il copyright originale. E’ possibile ora costruire un tabella a doppia entrata che metta in relazione questi parametri con le caratteristiche delle sei modalità di distribuzione che abbiamo esaminato: ovvero la GNU GPL, la GNU LGPL, la BSD license, la Netscape Public License, la Mozilla Public License e infine il dominio pubblico
Open Source e opere non software:
Nessun commento:
Posta un commento