Dichiarazione

Noi, i membri sottoscritti della comunità Open Source, affermiamo che l’Open Source è definito esclusivamente dalla Definizione Open Source (OSD) versione 1.9.

Eventuali modifiche o nuove definizioni saranno riconosciute solo se dichiarate da un chiaro consenso della comunità attraverso un processo trasparente da determinare.

---

2024-10-28

Cari amici e alleati dell’Open Source,

Per oltre due decenni, la Definizione Open Source (OSD) è stata la nostra base comune, garantendo le libertà del software e favorendo un ecosistema collaborativo. Derivata dalle Linee Guida per il Software Libero Debian (DFSG), ma fino ad oggi allineata ad esse, l’OSD ha costantemente stabilito lo standard per l’Open Source. Eppure oggi, l’Open Source Initiative (OSI) ha introdotto una nuova e divisiva Definizione Open Source per l’IA (OSAID) 1.0, sviluppata attraverso processi a porte chiuse che confliggono fondamentalmente con i principi di apertura e trasparenza che sono alla base del nostro movimento. Coprendo ampiamente qualsiasi software che “inferisca, a partire dagli input ricevuti, come generare output”, l’OSAID è in diretto conflitto con lo standard esistente, fallendo sia nella dimensione dell’apertura che in quella della completezza.

Sfide di gestione

La gestione dell’OSAID da parte dell’OSI ha evidenziato problemi di lunga data. Negli ultimi anni, la governance dell’OSI è stata criticata per non rappresentare pienamente gli interessi della comunità, con controversie che includono partenze e divieti di co-fondatori e dimissioni di membri del consiglio. Trascurando tendenze come il cloud computing (il passaggio dai prodotti ai servizi) e la crescente importanza dei dati, inclusi i modelli di IA (ma anche audio, video, immagini e database), l’OSI ha trascurato aspetti essenziali del software moderno. Ora, con l’OSAID, l’OSI sta cercando di ridefinire ciò che è aperto, questa volta con scarso riguardo per i feedback che non si allineano al suo approccio predeterminato ai dati. Per loro stessa ammissione, “un processo che non è aperto non può essere considerato affidabile per produrre un prodotto che possa essere considerato aperto”.

Le Quattro Libertà Essenziali

Al cuore del Software Libero & Open Source (FOSS) ci sono le Quattro Libertà Essenziali, che la OSAID ha riproposto abbastanza correttamente:

1. La libertà di usare il sistema per qualsiasi scopo e senza dover chiedere permesso.
2. La libertà di studiare come funziona il sistema e come funzionano ciascuno dei suoi componenti.
3. La libertà di modificare il sistema per qualsiasi scopo, inclusa la modifica dei suoi output.
4. La libertà di condividere il sistema affinché altri lo possano usare, con o senza modifiche, per qualsiasi scopo.

Queste libertà assicurano che gli utenti - non solo i fornitori - mantengano il controllo sul software, consentendo loro di usarlo, studiarlo, modificarlo e condividerlo come ritengano opportuno, e di “salire sulle spalle dei giganti” nel creare opere derivate. Ciò però viene meno con l’OSAID, che non riesce a proteggere completamente queste libertà poiché non rende più l’accesso al marchio Open Source condizionale all’accesso ai dati necessari.

Apertura e Completezza

Ci sono due dimensioni nella Definizione Open Source: apertura e completezza. Le sue esigenze di apertura sono già ben stabilite, ma la completezza è implicita e viene messa in discussione dall’aumento della complessità dei sistemi e del numero di componenti che potrebbero dover essere inclusi sotto le licenze Open Source per proteggere le Quattro Libertà. Ad esempio, una guida di viaggio che include dati OpenStreetMap (licenza ODbL) e Wikivoyage (licenza CC-BY-SA) è Open Source, ma il codice sorgente dell’applicazione “batterie non incluse” senza dati (o con dati proprietari) non è libero. Questo è particolarmente vero per i sistemi di Intelligenza Artificiale (IA), dove il codice di inferenza è poco più di un sistema di supporto vitale per il modello.

Secondo Bruce Perens (autore originale dell’OSD), “i dati sono il codice sorgente”, e afferma “puoi applicare la Definizione Open Source originale all’apprendimento automatico”. Ha avvertito che quando i dati e i modelli non sono accessibili, “il risultato è meno di Open Source.” Questo suggerisce che lo standard esistente copre già le esigenze evolutive dell’apprendimento automatico senza modifiche, e che il nuovo documento è superfluo.

Mentre la posizione predefinita è non apportare modifiche allo standard, è anche importante assicurarsi che rimanga pertinente e completo. Un’area di potenziale esplorazione è un’espansione dell’ambito per coprire i dati, ma questo dovrebbe essere affrontato con gli stessi standard di alto livello di un emendamento costituzionale, richiedendo un ampio consenso e una considerazione attenta per evitare conseguenze indesiderate. Ciò non è avvenuto con la OSAID, che presenta rischi considerevoli per i progetti esistenti e l’innovazione futura.

Pilotare, Navigare, Comunicare

Nell’aviazione, quando i piloti incontrano un’emergenza, seguono tre passi: Pilotare, Navigare, Comunicare. Questo approccio si applica anche qui, aiutandoci a recuperare il controllo, tracciare un percorso sicuro e migliorare la comunicazione.

1. Pilotare: Il primo passo è tirare fuori l’aereo dalla caduta e riguadagnare stabilità. Innanzitutto, questo significa mantenere l’integrità dell’OSD. Il nuovo sito della Definizione Open Source https://opensourcedefinition.org serve da zattera di salvataggio, preservando la Definizione Open Source corrente alla versione 1.9, e gli artefatti richiesti per un ecosistema Open Source funzionale, oltre a funzioni aggiuntive come una cronologia delle versioni e un repository Git. Invitiamo tutti a clonare e distribuire ampiamente i contenuti con licenza CC-BY, cementando la sua disponibilità preso l’intera comunità piuttosto che affidarsi a un qualsiasi repository centrale.
2. Navigare: Riottenuta stabilità, possiamo valutare attentamente se mantenere la rotta, assumendo che il percorso attuale serva ancora tutte le sfaccettature dell’Open Source. Dopo due decenni, la comunità potrebbe concordare sull’espansione dell’ambito dell’OSD in nuove aree — come i dati e il machine learning — senza danneggiare i progetti esistenti, oppure potrebbe considerare i cambiamenti non degni dei rischi. La stabilità rimane la norma, e ogni emendamento deve rispettare (e idealmente incorporare esplicitamente) le Quattro Libertà Fondamentali, evitando perturbazioni inutili alle norme stabilite. La comunità deve guidare questo processo, e alla luce della pesante censura che ha caratterizzato il forum esistente, offriamo un’alternativa non censurata su https://discuss.opensourcedefinition.org, aperta a tutti così che ogni voce possa esprimersi sul tema.
3. Comunicare: Infine, dobbiamo coinvolgere ed educare coloro che si affidano all’Open Source, che scelgano o meno di partecipare al processo. Una definizione di Open Source coerente è il fondamento di vite e mezzi di sussistenza, ricerca ed imprese in tutto il mondo, collegati dall’ecosistema Open Source che sostiene Internet, servizi cloud, sistemi di IA e altro ancora. Anche se non si impegnano direttamente con la comunità Open Source, il loro lavoro e la loro affidabilità si basano su questa base comune. È fondamentale che comprendano sia la posta in gioco che la propria capacità di supportare e proteggere le Quattro Libertà.

Perché è importante

Proteggere l’integrità della definizione di Open Source impatta più di una semplice locuzione, si tratta di preservare un impegno condiviso per la libertà. Con i sistemi di IA che toccano, trasformano e potenzialmente avvelenano ogni aspetto del futuro impegno umano, i rischi sono molto elevati. Supportando questa dichiarazione, sviluppatori, utenti, accademici e altri portatori di interesse affermano che i principi del vero Open Source possono essere definiti solo dalla comunità stessa.

Firmare questa dichiarazione è un atto di supporto per la trasparenza, la collaborazione e la proprietà collettiva dell’etica Open Source. Insieme, possiamo garantire che l’Open Source continui ad essere plasmato da coloro che lo costruiscono, lo usano e ci credono, piuttosto che principalmente dagli interessi aziendali. Il tuo supporto non solo afferma il tuo impegno, ma invia anche un messaggio a coloro che vorrebbero ignorerare la voce della comunità.

---

• Per firmare via email, invia una email in testo normale con contenuto qualsiasi o vuoto a ~osd/sos@lists.sr.ht.
• Per firmare su GitHub, per favore commenta su questo problema, usa l’interfaccia web per creare un nuovo file o sottoponi una pull request.
• Per firmare su Codeberg, per favore commenta su questo problema o sottoponi una pull request.
• In alternativa, clona e fork il repo, crea manualmente il file _data/signed/<username>.yaml, quindi commit e invia un PR.
• Puoi anche proporre modifiche alla lettera informativa sopra la linea aprendo un problema.