[Linuxtrent] Re: Richard Stallman returns to the FSF board

  • From: Daniele Nicolodi <daniele@xxxxxxxxxx>
  • To: linuxtrent@xxxxxxxxxxxxx
  • Date: Sun, 4 Apr 2021 21:00:53 +0200

On 03/04/2021 20:27, azazel wrote:

"Daniele" == Daniele Nicolodi <daniele@xxxxxxxxxx> writes:

    Daniele> On 25/03/2021 12:56, azazel wrote:
    >> mi trovi molto d'accordo, però mi dico anche che il software libero è
    >> realtà oggi anche grazie al fatto che RMS sia come è. Credo che
    >> probabilmente se avesse avuto "contegno" oggi ci troveremmo in
    >> situazione ben diversa nel contesto delle libertà dell'uomo (e della
    >> donna) nella società informatizzata di oggi. Seguendo questo traccia mi
    >> chiedo se alla luce di ciò RMS non sia proprio ciò che FSF debba avere,
    >> nonostante le sue opinioni personali. Come vedi sono ben lungi da un
    >> giudizio definitivo, ma comunque non sono affiliato ad FSF sento acor
    >> più di poter rimanere nell'incertezza ;-)


    Daniele> Nel caso specifico di Stallman, vorrei far notare che
    Daniele> nessuno sta suggerendo di estrometterlo dalla comunità,
    Daniele> solo di rimuoverlo da un ruolo di rappresentanza.

Si, beh, a volte con argomentazioni che vanno a colpire molto la
persona, mi pare e crredo sia accettabile per una persona che ricopre un
ruolo di rappresentanza e che ha un ruolo anche *politico*, senza mai
però scordarsi che a differenza di Epstein e Minsky le sue rimangono
"solo" opinioni.

La letteratura emersa in questi giorni è ampia e come ho già detto credo
che FSF possa fare scelte migliori riguardo hai propri rappresentanti,
oggi.

    Daniele> Credo che sia evidente a tutti quelli che hanno avuto a che
    Daniele> fare con lui, che RMS costantemente abusi del ruolo che la
    Daniele> comunità del software libero gli riconosce per
    Daniele> comportamenti inappropriati (quello più facile da
    Daniele> riscontrare è l'assumere riverenza da parte di tutti quelli
    Daniele> che interagiscono con lui) e dargli un ruolo ufficiale
    Daniele> all'interno della comunità non fa altro che peggiorare le
    Daniele> cose perché intervenire per limitare tali comportamenti
    Daniele> diventa ancora più complicato.

Ah, l'evindenza! Magari faremmo una cosa giusta a ragionare un attimo
se noi non si stia in realtà discutendo avendo in mano solo informazioni
di seconda se non di terza mano e di conseguenza che merito abbia la
discussione stessa.

Come autore di alcuni pezzettini di codice di cui ho ceduto il copyright
alla FSF e come autore di altri pezzetti di codice sulla cui licenza FSF
ha un sacco di potere, credo che discurtere della direzione in cui la
fondazione sta andando e di quanto il suo consiglio direttivo sia
affidabile e rappresenti il movimento del software libero siano
questioni importanti.

Come dici, non sono mai stato conivolto in nessuno degli "incidenti
importanti" che sono stati riportati da molti, e non condivido il tono e
gran parte dei contenuti della lettera che chiede le dimissioni di RMS e
di tutto il consiglio direttivo della FSF. Allo stesso tempo ho un po'
di esperienza diretta nel cercare di comunicare con RMS ed è qualche
hanno che osservo il comportamento di RMS sulla mailing-list emacs-devel
ed è evidente come il RMS si permetta comportamenti che trovo
estremamente scorretti e che non ho mai riscontatrato in nessun altro
nell'ambito dei progetti di software libero a cui partecipo.

    Daniele> Non credo che come la questione di chi guidi la FSF abbia 
rilevanza solo
    Daniele> se si è affiliati alla FSF se nella propria storia di contributi 
al
    Daniele> software libero si è rilasciato codice con licenza GPLv2 o 
GPLv3: il
    Daniele> testo standard per applicare la licenza GPL lascia la libertà di
    Daniele> applicare ad esso la corrente versione della GPL o qualsiasi 
versione
    Daniele> successiva _definita dalla FSF_.

Una libertà che si può tranquillamente rimuovere cancellando quelle
poche parole. La FSF ha avuto e avrà rilevanza per il software libero
anche ben oltre la vita di RMS spero, a cui auguro di vivere a
lungo. Detto questo è una fondazione privata e decide autonomamente.

Cancellare quelle poche parole è fattibile per progetti con meno di una
manciata di autori. Un cambio di licenza per progetti più grandi è
estremamente difficile, come testimonia la mole di lavoro che hanno
dovuto fare i pochi medio-grandi progetti che hanno tentato di farlo,
ultimo (in senso temporale) esempio eclatante OpenSSL.

Tornando alle licenze mi pare che vadano sempre lette e scelte con
attenzione: il software libero non è un culto nel quale le cose
funzionano se si ha fede.

Assiolutamente. Ma in molti abbiamo riposto un sacco di fiducia nella
FSF. Con il senno di poi, ho una lettura decisamente diversa della
scelta di Torvald di usare GPLv2-only per gran parte del kernel.

    Daniele> La rilevanza della FSF è ancora maggiore per tutti quei progetti 
che
    Daniele> sono sviluppati sotto l'ombrello del progetto GNU e che 
richiedono
    Daniele> cessione del copyright alla FSF.

Mi pare che la cessione del copyright serva per far valere più
efficacemente la licenza in sede legale. Le modalità di utilizzo di tale
software sono comunque decise nella licenza. 

Il problema è che, detenendo il copyright, la FSF è libera di cambiare
la licenza a suo piacimento. Visto la strana dinamica con cui si stanno
dipanando gli eventi legati al ritorno di RMS nel consiglio direttivo di
FSF, non mi sento di escluidere completamente che ci possa essere
qualche colpo di mano simile sul lato delle licenze.

    Daniele> Vorrei anche evidenziare che l'intransigenza di RMS ha
    Daniele> anche creato grossi problemi ad alcuni progetti che hanno
    Daniele> avvantaggiato progetti alternativi non rilasciati con
    Daniele> licenze copyleft. Un esempio importante è quello del
    Daniele> rifiuto categorico di RMS di permettere un sistema efficace
    Daniele> di plug-in per GCC: l'impossibilità di estendere GCC ha
    Daniele> portato moltissimi sviluppatori a costruire progetti
    Daniele> importanti su LLVM. Questo ha portato ad uno sviluppo molto
    Daniele> veloce di LLVM che è adesso forse migliore del GCC ed il
    Daniele> punto di riferimento per le suite di compilatori
    Daniele> compilatore con nuovi linguaggi come Go e Rust implementati
    Daniele> in LLVM e con GCC che arranca per stare al passo.

Ho sentito parlare del caso che menzioni, ma ancora na volta non vi ho
partecipato in prima persona, quindi non saprei dire. Da quanto leggo la
presenza di LLVM (finanziato almeno inizialmente da Apple) ha portato la
comunità GCC migliorare il proprio prodotto, che mi pare ancora "sano".
Riguardo alle prestazioni del GCC e dei binari che produce mi pare che
non se la cavi male ( un benchmark a caso tra quelli degli ultimi tempi:
https://www.phoronix.com/scan.php?page=article&item=gcc10-clang10-x86&num=1
)

Non intendevo dire che le performance di GCC sono peggiori di quelle di
LLVM, ma che ho la netta impressione che chi sviluppa nuovi linguaggi o
chi voglia spertimentare nuove fuonzionalità per un compilatore è molto
più probabile che oggi guardi a LLVM, mentre fino a qialche anno fa GCC
era di gran lunga la scelta più probabile.

Il compilatore di default di Go non fa uso né di LLVM, né di GCC,
secondo la sua faq (
https://golang.org/doc/faq#Do_Go_programs_link_with_Cpp_programs ;) ma
esistono back-end alternativi per entrambi i compilatori.

Hai ragione, non uso Go e avrei dovuto controllare prima di scrivere.
-- 
Per iscriversi  (o disiscriversi), basta spedire un  messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx


Other related posts:

  1. Home
  2. linuxtrent
  3. Archive
  4. 04-2021