On 8/2/06, Andrea Rossato <mailing_list@xxxxxxxxxxxxxxxxx> wrote:
Il Wed, Aug 02, 2006 at 09:02:30AM +0200, Roberto Resoli ebbe a scrivere: > Mi pare sia tu a non capire (o a non volerlo). > Il punto sta che alcuni utilizzi di sw prevedono che esso possa essere > modificato solo da una fonte fidata, che non coincide con chi lo usa > (quindi la chiave non la può generare lui). Lo si fa soprattutto per > fare in modo che la fonte fidata sia garante e RESPONSABILE del > comportamento del sw. Se il garante rilascia la chiave con cui firma > il sw non può più essere ritenuto responsabile di un bel nulla, > altrettanto se chi usa il sw genera una propria chiave. > La richiesta di modifiche controllate non ha necessariamente intenti > malevoli, ma semplicemente fa parte della natura stessa dell'utilizzo > del sw. E' l'esempio della macchina di voto. Si vuole che la fonte che > emette il sw sia responsabile per esso. Nel contempo si vuole che il > sw sia libero. Com la GPLv2 si salvavano capra e cavoli, con la v3 no.
d'accordo, ma non mi pare proprio che ciò centri con la gpl3. se firmo un binario per garantirne la provenienza, ciò non significa affatto che la modifica di quel binario (rectius, una compilazione del sorgente, modificato, che precedentemente produceva quel binario) comporti l'impossibilità di installarlo ed eseguirlo. non con il trusted computing, almeno.
mah, non so se c'entri il tc o meno. Sta di fatto che esistono sw come quello citato per cui sarebbe auspicabile la copertura con una licenza di sw libero, ma cui, a quanto pare, la GPLv3 nella formulazione attuale non è applicabile.
io leggo la clausola sulla corresponding source come una clausola che si applica a casi in cui il drm è implementato direttamente via software (quindi non in caso di TC). ed è ciò che mi lascia perplesso, perché in tal caso io, autore, non potrei usare la gpl3 per distribuirlo (perché qualcuno potrebbe chiedere ad un giudice di obbligarmi a distribuire la chiave di criptazione o di autorizzazione). questa mi sembra una politica un po' miope della fsf, volta principalmente ad entrare in conflitto con la comunità linux.
ok, allora la dico tutta: io vedo la gpl3 come il tentativo di rms e fsf di mettere in un angolo la comunità degli sviluppatori di linux. l'unica novità rilevante della gpl3, infatti, è che essa è incompatibile con la gpl2, salvo per quei progetti che hanno rilasciato il codice come gpl2 "or any later version". ora, tra i progetti famosi l'unico a non fare così è proprio il kernel.
Ah. Capisco che LT sia arrabbiato.
questa non penso possa essere una coincidenza. e la ragione di questa coincidenza, la necessità della compatibilità con la licenza apache - per ragioni giuridico/sofistiche, sebbene non false -, non mi sembra forte a sufficienza da richiedere una nuova gpl. i veri problemi che rms indicava anni fa (i web services, ad esempio) non vengono invece affrontati. la parte sui brevetti cosa cambia effettivamente? la termination avviene prima (come nel caso della licenza apache) - se si da inizio ad un contenzioso - invece che alla definizione del contenzioso stesso. una rappresaglia che cambia assai poco le cose. la parte sul drm è fumosa - e la confusione della nostra discussione lo dimostra ampiamente!
si
allora? io leggo lo scontro lt<->rms come uno scontro politico, dove gli argomenti usati (da entrambi) hanno solo un sapore propagandistico.
io sono convinto che questo scontro per la supremazia finale sia nocivo, ma francamente me ne frego: detesto il software opensourse, ho già dato in tema di software libero, ed ora mi occuperò di altro. a partire da haskell...;-)
Boh. Sinceramente anch'io trovo questo genere di diatribe molto stancante. Convengo che sicuramente abbiamo di meglio da fare.
Ciao, Rob.
ciao andrea -- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
-- Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO "subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
