È giunto il momento di rivedere la definizione di Open Source?
I recenti sviluppi potrebbero rafforzare la necessità di esplorare miglioramenti ai dati di idoneità operativa.
L'Open Source Definition (OSD), mantenuta dall'Open Source Initiative (OSI), è un pilastro fondamentale del movimento open source. Il punto di vista dell'OSI è che il software validamente etichettato come "open source" deve essere reso disponibile in un modo che soddisfi i 10 criteri stabiliti nell'OSD, tutti tranne uno relativi ai termini di licenza.
Attraverso il processo di revisione della licenza, l'OSI determina se una licenza inviata è conforme all'OSD. Ampiamente riconosciuta come autorevole, la OSD è comunemente invocata nel linguaggio contrattuale ed è stata citata in statuti e regolamenti. L'OSD è stato redatto e adottato dall'OSI poco dopo la sua fondazione nel 1998. Si tratta essenzialmente di un rebranding delle Linee guida per il software libero Debian (DFSG) con modifiche relativamente minori. È stata modificata solo una volta, nel 2002, con l'aggiunta di un decimo punto ("La licenza deve essere neutrale dal punto di vista tecnologico").
La stabilità del testo OSD riflette un conservatorismo più generale nel trattamento di importanti testi giuridici nella comunità open source. Le licenze open source ampiamente adottate, che sono state chiamate "costituzioni di comunità", vengono raramente riviste, in parte a causa di ostacoli pratici e politici. L’OSD sembra più analogo a un vero testo costituzionale che a qualsiasi licenza conforme all’OSD e, naturalmente, le costituzioni vengono riviste meno spesso delle leggi ordinarie che autorizzano. La difficoltà di rivedere le licenze open source è problematica – ad esempio, aumenta probabilmente i costi di un’interpretazione giudiziaria avversa nelle controversie sull’applicazione delle licenze – ma non sembrerebbe che ci siano costi paragonabili a una revisione poco frequente dell’OSD. Si potrebbe giustamente dire dell'OSD: "se non è rotto, non aggiustarlo".
Tuttavia, i recenti sviluppi potrebbero rafforzare l’ipotesi che sia il momento opportuno per esplorare miglioramenti ai dati di idoneità operativa. Si è verificato un aumento dei tentativi di "ingannare" l'OSD nel processo di approvazione della licenza e altrove. L'autorità dell'OSI nel dire cosa significa open source e la continua rilevanza dell'OSD sono state messe in discussione da una serie di critici, tra cui imprenditori e venture capitalist che promuovono licenze "source-available" che proteggono il modello di business, sostenitori della nascente " fonte etica" e iconoclasti generali che sembrano vedere l'OSI e l'OSD come prodotti di un'era passata associati a un insieme di valori screditati. Anche se non vi è alcuna necessità urgente di rivedere l'OSD, l'OSI potrebbe trarre vantaggio dall'intraprendere uno sforzo di revisione tattica volto a preservare e migliorare lo status dell'OSD come qualcosa di legittimo, autorevole e coerente con le prospettive contemporanee.
Come potrebbe essere un rinnovamento
Ci sono alcune direzioni che potrebbe prendere un ipotetico rinnovamento dell’OSD. Si può sostenere un'importante riformulazione stilistica. Sebbene il DFSG possa essersi rivelato un documento organico di successo per guidare la politica di pacchettizzazione di Debian, direi che la fondazione DFSG dell'OSD non è ben adatta alla politica piuttosto diversa dell'OSI sulla revisione delle licenze non specifiche del progetto. L'OSD incorpora alcuni riferimenti alle controversie sulla licenza della distribuzione Linux degli anni '90 e alcune parti di esso sono chiaramente scritte pensando alle preoccupazioni di una distribuzione multi-pacchetto. (Vedi, ad esempio, OSD 1, 4 e 9.) In passato, mi sono chiesto se l'OSI non avrebbe fatto meglio a eliminare la forma attuale dell'OSD in favore della relativamente elegante Definizione di Software Libero (FSD) mantenuta da la Free Software Foundation (spesso definita le "quattro libertà"). Ma sembra improbabile che l’OSI possa mai apportare un cambiamento così radicale, o anche revisioni testuali relativamente minori e frammentarie, per ragioni principalmente di stile.
Si può anche immaginare che l’OSI cerchi di apportare modifiche sostanziali alle politiche dell’OSD, per ammettere alcune categorie di licenze precedentemente trattate come vietate o per rifiutare alcune categorie precedentemente ritenute consentite. Consideriamo un esempio del tutto irrealistico ma tempestivo: l'OSI potrebbe abbracciare le licenze promosse dal movimento etico della fonte o le varie recenti licenze disponibili alla fonte sostenute da alcune "società open source" modificando le disposizioni antidiscriminazione degli OSD 5 e 6 per specificatamente autorizzare i tipi di classificazioni effettuate in tali licenze. Tuttavia, non credo che l’OSI ritenga effettivamente che l’OSD presenti carenze politiche sostanziali che valga la pena affrontare attraverso la revisione dell’OSD, quindi anche questa forma di riforma dell’OSD sembra altamente improbabile.
Un terzo tipo di revisione dell'OSD comporterebbe sforzi per chiarire o rendere più esplicita la comprensione esistente da parte dell'OSI dei requisiti e dei limiti delle licenze open source. Come ho notato in un articolo precedente, nel 2019, l’OSI ha chiarito che lo scopo del suo processo di approvazione delle licenze era garantire che le licenze approvate non solo fossero conformi all’OSD ma fornissero anche la libertà del software. Ciò è stato motivato dai tentativi di "giocare" all'OSD nel processo di revisione della licenza sfruttando lacune di copertura o vaghezza nel testo. L'attenzione alla questione della libertà del software fornisce un modo per correggere questo problema senza allontanarsi dall'interpretazione pratica dell'OSI dell'OSD. La revisione dei dati di idoneità operativa per colmare tali lacune o chiarire le ambiguità del testo dei dati di idoneità operativa è un mezzo alternativo e preferibile per affrontare lo stesso problema. Sembra che l'OSI abbia più probabilità di prendere in considerazione una forma di revisione dei dati di idoneità operativa orientata al chiarimento.
Cose da considerare
Ecco alcune questioni specifiche che l'OSI potrebbe voler prendere in considerazione:
1. Brevetti
Non sorprende, date le sue origini negli anni ’90, che l’OSD non dica nulla sui brevetti. Alcune controversie relative all'interpretazione dei dati di idoneità operativa si sono incentrate sulla relazione tra licenza open source e licenza di brevetto. Ad esempio, la presentazione del CC0 nel 2012 ha acceso il dibattito sulla possibilità che una licenza open source possa escludere espressamente la concessione di una licenza di brevetto.
Più recentemente, e al di fuori del contesto dell'approvazione delle licenze, alcune aziende con modelli di business basati sulla concessione di licenze FRAND di brevetti essenziali standard hanno (per ragioni che in realtà non sono chiare) spese considerevoli risorse promuovendo l'idea che le licenze open source validamente etichettate possano essere "copyright" soltanto." L'OSI si è fortemente opposta a questo punto di vista. Nelle discussioni sulla revisione della licenza, l'OSD 7 ("I diritti allegati al programma devono applicarsi a tutti coloro ai quali il programma viene ridistribuito senza la necessità di ottenere una licenza aggiuntiva da parte di tali parti") è stata citata come base per ritenere che Le licenze "solo copyright" non possono essere considerate open source, ma molto probabilmente quell'asse non è stata scritta pensando ai brevetti. Sarebbe difficile affrontare in modo soddisfacente la questione dei brevetti attraverso una revisione della OSD, ma la certezza che ne deriverebbe potrebbe essere molto vantaggiosa.
2. Copyleft e software non correlato
Alcune recenti richieste di licenza hanno sollevato la questione di quanto estese possano essere le condizioni di licenza copyleft senza entrare in conflitto con l'OSD. La License Zero Reciprocal Public License (L0-R) richiedeva effettivamente che il software creato o eseguito da strumenti con licenza L0-R, ma altrimenti non correlato a tali strumenti, fosse pubblicato con una licenza open source. In modo simile, la Server Side Public License (SSPL) richiede la pubblicazione sotto SSPL del codice sorgente dell'intero stack utilizzato per implementare MongoDB come servizio. (Sia L0-R che SSPL furono sottoposti a pesanti critiche sulla revisione della licenza, ma furono ritirati prima che l'OSI potesse prendere una decisione al riguardo.)
Anche se è possibile sostenere che questo tipo di licenze violano le disposizioni antidiscriminazione dell’OSD, ciò non è molto soddisfacente poiché qualsiasi licenza FOSS non banale conterrà classificazioni suscettibili di essere caratterizzate come discriminazione contro persone, gruppi o campi di attività. L'OSD 9 ("La licenza non deve limitare altri software") affronta il tipo di problema in questione qui, ma è scritto in un modo specifico per un contesto di distribuzione. L'OSI potrebbe presumibilmente generalizzare il linguaggio dell'OSD 9, magari adattando la mera clausola di aggregazione della GPL, per affrontare le future licenze presentate che estendono il copyleft a software non correlato.
3. Libertà 0
Un buon esempio di un divario di copertura involontario nell'OSD è l'assenza di qualsiasi controparte alla "Libertà 0" nella FSD: "La libertà di eseguire il programma come desideri, per qualsiasi scopo". Il commento di accompagnamento alla FSD suggerisce che Freedom 0 incarna una sorta di diritto alla privacy: l'utente gode della libertà "senza essere obbligato a comunicare [sul software] con lo sviluppatore o qualsiasi altra entità specifica". Ho il sospetto che chiunque consideri autorevole l'OSD presupporrebbe che l'OSD in qualche modo comprenda l'equivalente di Libertà 0, implicitamente o come proprietà emergente o in altro modo. Non è chiaro il motivo per cui sia assente nel testo del DFSG, ma potrebbe essere stato ritenuto troppo ovvio dalla comunità Debian per essere degno di nota.
Almeno una licenza presentata per l'approvazione dell'OSI negli ultimi anni, L0-R, viola presumibilmente la Libertà 0. Ma Kyle Mitchell, l'autore di L0-R, ha sottolineato che un'oscura licenza approvata dall'OSI in precedenza nella sua storia (e considerata come non-free dalla FSF e Debian) avevano caratteristiche simili. Nel 2017, McCoy Smith ha osservato che l’idea che la Libertà 0 non sia inerente all’OSD porta a conclusioni bizzarre. Sembrerebbe auspicabile, e forse relativamente semplice, che l’OSI adattasse il semplice linguaggio della Libertà 0 nella FSD come nuovo criterio esplicito nella OSD.
Rischi contro benefici
Ci si può aspettare che uno sforzo da parte dell’OSI per intraprendere revisioni dell’OSD sia un processo sostanzialmente pubblico, aperto all’osservazione e alla partecipazione della comunità. I punti di vista della rete dell'OSI di organizzazioni affiliate all'open source, che hanno dichiarato il loro impegno nei confronti dell'OSD, potrebbero diventare particolarmente importanti in un tale processo.
Data l’importanza dell’OSI e l’importanza dell’OSD, il processo riceverebbe probabilmente visibilità e controllo significativi. In un’attività di questo tipo, è probabile che alcuni individui e gruppi cerchino di distorcere o esercitare un’influenza indebita sulla sua direzione, ma un’attenta attenzione alla governance e alle procedure potrebbe prevenire questo problema. Credo che i potenziali benefici per l’open source e l’OSI supererebbero i rischi.