Codice e società/Capitolo 5/1
 |
Questo testo è completo. | |
| ◄ | Capitolo 5 | Capitolo 5 - 2 | ► |
La chiusura cognitiva ha a che fare con le competenze necessarie a comprendere il codice, quand'anche aperto. Questa chiusura ha una doppia valenza: verso chi non si occupa professionalmente di informatica, ma anche verso chi, pur occupandosi professionalmente di informatica, impiegherebbe troppo tempo per comprendere lo stato dell'arte di un determinato progetto.
La chiusura selettiva si intreccia con la chiusura cognitiva ma pone l'accento sul livello di partecipazione a un progetto. Ye et altri (2002) individuano otto livelli di partecipazione al progetto (cfr. cap. III, paragrafo 2). Appartenere ai livelli maggiori, come quelli del core members, o degli active developers, significa avere maggiori opportunità di ottenere commesse nel mercato delle competenze, mentre i bug fixers e i peripheral developers premono dall'esterno. La chiusura selettiva può anche essere vista come la formalizzazione burocratica della chiusura cognitiva.
A tal proposito si veda quanto afferma Stefano Zacchiroli, project leader di Debian, in un'intervista aperta del 17 agosto del 2010, che indica otto livelli, sistematizzati in una forma più burocratica 1 rispetto a quella di Ye.
Il progetto Debian è fortemente incentrato su quelli che si ritengono essere valori democratici e meritocratici, e l'accesso alle cariche più alte avviene attraverso un meccanismo elettorale, binario, volto a superare il paradosso di Condorcet2. La campagna elettorale di Stefano Zacchiroli, in occasione della sua elezione a project leader di Debian, è stata fortemente incentrata sulle competenze e sui meriti nella partecipazione a progetti di sviluppo. Ciò che ai nostri fini è importante rilevare, al di là dei valori sociali (democrazia, meritocrazia, libertà) significativi per gli attori in gioco, e significanti per noi osservatori, è che il consenso viene intercettato nel terreno delle competenze tecniche. Questa dimensione tecno-sociale del consenso è ciò che riesce a legare l'aspetto tecnico con quello burocratico ai fini selettivi.
La chiusura tecnica ha a che fare con la peculiarità di Linux e dei sistemi Unix in genere. Questi sistemi operativi sono utilizzati maggiormente come server: sono i nodi che fanno funzionare gran parte del Web. Un server è un calcolatore molto potente in grado di eseguire molte operazioni che gli vengono demandate dai vari client, cioè i computer degli utenti ad esso connessi tramite la rete. Questi server contengono programmi particolari, dedicati al controllo, allo smistamento di informazioni e alla conservazioni di dati, cioè le basi di dati, che gli informatici chiamano RDBMS3. Uno dei paradossi del paradigma Open Source è che la più usata architettura dei Web-servers LAMP4 costruita con tecnologia Open Source, che ha avuto un enorme successo e annovera servizi famosissimi come Facebook, è di per se inaccessibile. Le critiche maggiori che si rivolgono allo stesso Facebook riguardano l'oscuramento dei meccanismi interni al sistema che gestisce informazioni personali di milioni di persone.
I social networks sono spesso costruiti con tecnologia Open Source, ma è indubbio che questi costituiscano, al pari della tecnologia proprietaria, delle vere e proprie scatole nere, cioè tecnologia pronta all'uso che oscura i suoi meccanismi interni. Gli stessi social networks possono a loro volta costituire dei passaggi obbligati. Uno dei servizi offerti da Facebook è l'accreditamento su altri servizi Web per mezzo dei propri sistemi di autenticazione. Utilizzando le stesse credenziali di Facebook uno stesso utente può accedere a servizi diversi da Facebook, previ accordi commerciali tra Facebook e i gestori di questi altri servizi Web. Ci troviamo quindi di fronte ad un altro caso (crf. Cap. I, paragrafo 1) in cui attori transnazionali entrano in competizione con gli stati ed assumono funzioni governative (Beck, 2001), nello specifico la funzione di certificare l'identità dell'utente su diversi servizi Web, il tutto costruito con tecnologia Open Source. La chiusura normativa ha a che fare con le forme contrattuali, e cioè le licenze d'uso, con cui l'Open Source e il Software Libero vengono distribuiti: esse prevedono clausole restrittive, fino al divieto di contaminazione con il software proprietario nei casi più estremi, allo scopo di preservare i confini e gli standard.
www.questionmaps.net
Fig. 1 - Mappa delle licenze e soggetti approvatori
È il caso della licenza d'uso più diffusa del Software Libero che è la General Public License. Questa licenza impedisce di miscelare il software libero con altro software proprietario, a volte anche altro Open Source; nel caso in cui ciò avvenga, la tecnologia che viene inclusa deve poter diventare a sua volta Software Libero.
Si tratta di una clausola propagativa e conservativa allo stesso tempo. Nell'ambito del codice libero istituzionalizzato, oltre alla licenza GPL ve ne sono altre, più o meno restrittive. Queste licenze a loro volta sono riconosciute o elaborate da organismi istituzionali come la Free Software Foundation, l'Open Source Initiative e la Copy Free Initiative, ma anche da progetti particolarmente importanti e vasti che per la loro rilevanza hanno assunto uno spessore istituzionale, come Debian Project e Fedora Project.
La Fig.1 mette in evidenza le relazioni che esistono tra i soggetti istituzionali che approvano i tipi di licenza e i tipi di licenza stessi. All'esterno si trovano i soggetti approvatori, mentre al centro della mappa si trovano i tipi di licenza approvati. Più il tipo di licenza si trova al centro e più gode dell'approvazione di più soggetti istituzionali. Il centro della mappa costituisce pertanto uno spazio protetto e fortemente istituzionalizzato, mentre l'esterno della mappa rappresenta dei confini porosi, in cui è possibile anche la contaminazione con software proprietario.
Vi è quindi una relazione diretta tra quanti sono gli organismi che approvano un determinato tipo di licenza, e quindi la tecnologia distribuita con quelle clausole, e il grado di istituzionalizzazione. Vi è anche una relazione diretta tra grado di restrizione delle licenze e loro grado di approvazione dalle istituzioni. Quindi più la tecnologia Open Source è distribuita con clausole restrittive, più viene approvata a livello istituzionale da diversi approvatori. Questo avviene anche cronologicamente.
Molte licenze, specialmente quelle legate alle università come la BSD di Berkeley, o la licenza MIT, ottengono una maggiore approvazione passando dalla versione 1 alla versione 2, in virtù della loro maggiore istituzionalizzazione, e dell'inclusione di clausole di volta in volta più restrittive e intolleranti verso il software proprietario.
Significativo è quanto è accaduto con il passaggio dalla versione 1 alla versione 2 della Artistic License in riferimento, in particolare alla clausola che tratta la redistribuzione di questa tecnologia in aggregazione con altra tecnologia:
Artistic License 1.0: […] You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own […]
Artistic Licese 2.0 […] The terms of this license apply to the use and Distribution of the Standard or Modified Versions as included in the aggregation […]
In una prima versione ci si accontenta del fatto che chi redistribuisce tecnologia Open Source con questa licenza non si appropri della paternità della stessa (questo è il tipico stile Berkeley dell'esperienza BSD/Unix degli anni '70 e '80 del '900). In una seconda versione viene inclusa la clausola propagativa, o “virale” in gergo informatico, per cui la tecnologia che vi viene aggiunta assorbe a sua volta le stesse condizioni distributive. Nel passaggio dalla prima versione la Artistic License viene riconosciuta solo dall'Open Source Initiative e dalla Copyfree Initiative. La seconda versione viene invece accettata da più istituzioni, in virtù della sua maggiore severità verso il software non Open Source e non Libero. Essa viene quindi approvata dalla Free Software Foundation, dall'Open Source Initiative, da Debian Project e da Fedora Project, e diventa compatibile con altre licenze GPL: pertanto assume un maggior grado di istituzionalizzazione, spostandosi dai margini della mappa al centro dello spazio istituzionale pubblico.
La maggiore restrizione ha un significato di chiusura, conservazione e istituzionalizzazione. Questa sorta di transizione da forme distributive più aperte e meno istituzionalizzate a forme di maggiore chiusura dell'Open Source, altro non è che la fase terminale dell'istituzionalizzazione di quello che fin dall'inizio abbiamo chiamato codice libero.
Note
- ↑
1. C'è Il project leader, ci sono i suoi delegati. Il segretario e tutti i macchinari che servono per fare andare avanti i meccanismi di voto.
2. Il comitato tecnico, nel caso ci siano conflitti di natura tecnica tra persone all'interno del progetto. È una specie di, come dire, tribunale a cui ci si può appellare per risolvere conflitti di natura tecnica.
3. Quelli che chiamiamo core teams, che hanno dei ruoli specifici e che sono in quanto su carta delegati del proprio project leader, ma che hanno dei ruoli politici abbastanza importanti anche se vuoi di divisione dei poteri.
4. Il cosiddetto DAM, Debian Account Manager, che sono un gruppo di persone che decide chi può diventare sviluppatore Debian e chi no.
5. C'è il gruppo di DSA, Debbian System Administrator, che sono quelli che mantengono tutte le macchine, tutti i server del progetto Debian in giro per il mondo, ed in generale tutta la infrastruttura tecnica.
6. Un gruppo chiamato FTP masters, che sono quelli responsabili su cosa entra nell'archivio software Debian e cosa no, e che hanno un potere molto significativo, nel senso che sono quelli che decidono al momento quali sono le licenza che sono accettabili nell'archivio Debian, decidono quando un pacchetto non raggiunge i criteri minimi di qualità per entrare nell'archivio.
7. C'è un gruppo di Keyring Manager che sono quelli che gestiscono il gruppo di chiavi e di firme digitali che servono a firmare i pacchetti che possono entrare nell'archivio.
8. Il release team che è un gruppo di persone responsabili di valutare il programma verso una release Debiano che è l'outcome principale di un progetto come Debian, fare una nuova release.
- ↑ Si tratta del paradosso per cui all'interno della stessa votazione non viene garantita la volontà della maggioranza nel caso in cui vi siano più di due scelte, anche quando la scelta è presa per maggioranza.
- ↑ Relational Data Base Management System.
- ↑ Linux Apache MySQL PHP