[AcLab] Linux-Libre e TC

[alexus / dotcommon]

On Wed, 17 Feb 2010 11:19:33 +0100, davide89v <davide89v a riseup.net>
wrote:

> Sembra che già sia possibile disabilitare il TC durante la compilazione.
> http://www.fsfla.org/pipermail/linux-libre/2010-February/001028.html

e vabbé...

> Acquanto pare il chip fritz può essere usato solo da software
> appositamente progettato, di solito proprietario, se libero basta
> modificare il codice sorgente e ricompilarlo.
> 
> http://www.fsfla.org/pipermail/linux-libre/2010-February/001029.html
> 
> Per quanto riguarda invece il blocco del boot che il chip fritz è in
> grado di fare si tratta della cosiddetta tivoization.
> 
> http://www.fsfla.org/pipermail/linux-libre/2010-February/001030.html
> 
> Suggerimenti ditemi cosa ne pensate, in fatto di tc sono parecchio
> ignorante.

mah... come spesso accade anche su questo mi pare che vi siano delle
contraddizioni di fondo...

il "solito" problema, a mio parere, è che ci si limita a valutare la
libertà del codice sorgente *solo e strettamente* rispetto ai termini della
licenza

LL fa qualcosina in più... ma anche qui la cosa è contraddittoria...

nella home page del progetto, leggo:
"Linux-libre is a project to maintain and publish 100% Free distributions
of Linux, suitable for use in Free System Distributions, removing software
that is included without source code, with obfuscated or obscured source
code, under non-Free Software licenses, that do not permit you to change
the software so that it does what you wish, and that induces or requires
you to install additional pieces of non-Free Software."

attenzione - si dice in particolare: "removing software that [...]
*induces or requires you to install* additional pieces of non-Free
Software"... 

considerazione 1) -  si dice che viene rimosso il software che induce o
richiede di INSTALLARE "pezzi" di software non libero: non si parla però di
rimuovere il codice che induce o richiede di USARE software non libero

considerazione 2) - dato che si dice che viene rimosso il software che
induce o richiede di INSTALLARE "pezzi" di software non libero, mi
aspetterei che, oltre ai blob binari, sia rimosso anche il codice (anche se
codice libero) relativo a driver che per funzionare necessitano di firmware
non liberi: infatti, la presenza del codice di questi driver (anche se
codice libero) quantomeno "induce" l'utente a (re)installare
blob/firmware/patch non-liberi (cosa che spesso molti utenti sono porati a
fare e fanno, come dimostrano i tantissimi howto e download disponibili, ad
esempio, per i driver di schede wifi)

leggo poi qui: 
http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.33
(è lo script "deblob" usato da LL per "pulire" il kernel)

# This script, [...]
# attempts to remove only non-Free Software bits, without removing
# Free Software that happens to be in the same file.
# Drivers that currently require non-Free firmware are retained, [...]

sottolineo: "are retained"... la contraddizione con 2) mi pare evidente...


riguardo il TC, mi pare ovvio che il "software" dentro i chip TMP non si
possa considerare libero (se qualcuno mi volesse dimostrare il contrario,
potrebbe iniziare facendomi vedere come leggere in chiaro le chiavi
crittografiche memorizzate dal sistema TC...)

fatta questa premessa:

- il codice TC sarebbe da rimuovere dal kernel se (vedi: considerazione 1)
la policy di LL parlasse anche di USARE (e non solo di INSTALLARE) "pezzi"
di software non libero...

- se facciamo questo parallelo (dove ":" significa "sta a" e "=" significa
"come"):

driver wifi (software libero) : blob-firmware (hardware non libero) =
codice sorgente TC nel kernel (software libero) : chip TMP (hardware non
libero, v. chiavi di crittografia)

allora (v. considerazione 2) ne dovrebbe discendere (a meno che la logica
non sia una geometria variabile) che anche il codice TC (come i driver che
richiedono firmware non-liberi) andrebbe rimosso dal kernel... 
e invece sta lì... anche in questo caso in chiara contraddizione con 2),
come per i driver...


ultima cosa... è vero (come detto nel thread della lista LL) che il
problema reale sta, essenzialmente, a livello hardware (e poco o nulla può
farci il software libero quando si tratta di situazioni, diciamo, di
"tivoizzazione")... 
ma se FSF ha la mission di supportare il software libero e parla contro i
DRM (vedi anche DbD), contro la "tiviozzazione" (vedi la GPLv3) e contro il
TC... beh... allora personalmente penso che non ci si dovrebbe stupire
(come invece fanno alcuni) se poi le persone si aspettano da FSF & C.
comportamenti conseguenti e non contraddittori....

scusate per la lunghezza e per l'esposizione "confusa" e magari spesso
poco chiara...

saluti
al3xu5 / dotcommon

-- 
Support free software! Join FSF: http://www.fsf.org/jf?referrer=7535