Non molto tempo fa abbiamo raccontato della creazione del fork di ONLYOFFICE chiamato Euro-Office, un’iniziativa europea guidata da NextCloud e IONOS il cui scopo è provare a rendere “Made in Europe” la piattaforma che attualmente è sviluppata per la maggioranza in Russia.

La vicenda, per ovvi motivi, unisce svariati temi che spaziano dalla geopolitica alla Sovranità Digitale, dallo sviluppo di software al licenziamento dello stesso, poiché secondo ONLYOFFICE il fork creato in Europa violerebbe la licenza AGPL per via della modifica dei termini di licenza originali, con l’aggiunta di esplicite motivazioni geopolitiche (in realtà unico vero motivo della creazione del fork).

Proprio su questo punto è intervenuta recentemente la Free Software Foundation, con due articoli apparentemente slegati tra loro, ma che chiariscono alcuni punti cardine che tutti dovrebbero conoscere se operano all’interno del mondo open-source.

Il primo si intitola “Relicensing versus license compatibility” ed è una riscrittura riveduta e corretta di un articolo dallo stesso titolo scritto da Yoni Rabkin per chiarire quale sia la differenza tra cambiare la licenza di un progetto open-source ed utilizzare invece licenze compatibili a quelle esistenti.

La differenza è semplice:

• Rilicenziare vuol dire cambiare la licenza sotto cui viene distribuita un’opera. Questo potere spetta esclusivamente al titolare del copyright (o ai titolari, che devono essere tutti d’accordo). Se domani il solo titolare di un progetto decide di passare dalla GPLv3 all’Apache 2.0, può farlo. Nessun altro può farlo al posto suo.
• Scegliere una licenza compatibile vuole invece dire combinare due opere indipendenti, ciascuna con la propria licenza, in un unico lavoro più grande. Due licenze sono compatibili se i loro rispettivi requisiti non sono in contraddizione, permettendo di rispettare contemporaneamente tutti i termini di entrambe. Ad esempio, la GPLv3 e la Modified BSD sono compatibili: si può prendere codice sotto l’una e sotto l’altra, distribuirle insieme come un unico programma, e chi riceve il tutto potrà poi estrarre la parte BSD e ridistribuirla separatamente con la sua licenza originale intatta.

Stabilito con chiarezza questo, ecco il secondo articolo che stavolta spiega come non sia possibile fare quello che ha fatto ONLYOFFICE senza violare la licenza AGPL. In particolare il quadro tracciato dalla FSF racconta di una mossa ibrida e scorretta che confonde proprio i due concetti descritti, in quanto ONLYOFFICE:

1. Ha preteso di fare un “rilicenziamento parziale” senza esserne il solo titolare (nel codice ci sono contributi di terzi? Non è chiaro, ma la FSF insinua il dubbio).
2. Ha aggiunto restrizioni (logo) spacciandole per “termini aggiuntivi compatibili” , quando in realtà sono incompatibili con la AGPLv3.

In buona sostanza quello che la FSF vuole evidenziare riguarda cosa succederebbe se la pratica di ONLYOFFICE venisse ritenuta lecita:

• Allo stato attuale delle cose solo il copyright holder può rilicenziare, ma se la pratica venisse accettata chiunque potrebbe aggiungere restrizioni arbitrarie e creative.
• Al momento la compatibilità delle licenze è binaria: o un progetto è compatibile, oppure non lo è, mentre nel secondo caso si andrebbe a formare una zona grigia di compatibilità forzata.
• Le licenze, nel mondo open-source attuale, sono testi stabili, mentre nel secondo caso diverrebbero modificabili unilateralmente.

L’atteggiamento della FSF vuole quindi essere il più conciliante possibile, far capire come nei fatti ONLYOFFICE si stia sbagliando e, considerato come nel corso della storia i casi in cui la FSF sia scesa in tribunale sono stati rarissimi, vuole confermare la bonarietà di queste considerazioni, per risolvere tutto con il buon senso.

Chissà se un punto di incontro lo si potrà trovare… La AGPLv3, alla Sezione 7, permette esplicitamente a chi riceve il software di rimuovere qualsiasi “restrizione ulteriore“. L’obbligo di mantenere il logo, secondo la FSF, rientra proprio in questa categoria, mentre ONLYOFFICE, dal canto suo, sostiene che la licenza modificata vada presa come un pacchetto indivisibile, e che rimuovere il logo costituirebbe una violazione della Sezione 8 della AGPLv3.

Come andrà a finire la faccenda nessuno lo sa, e noi saremo lì a controllare, ma volendo guardare gli aspetti positivi, è bello notare come in un mondo dove tutto si riduce a questioni di business e perdita di quote di mercato, la FSF difenda valori alti come quello della preservazione della libertà del software.

Una cosa che potrebbe essere scontata, ma non lo è affatto.