[glux] qualche riflessione in ordine sparso ....

Ven 2 Nov 2012 16:01:04 CET

Il giorno 02 novembre 2012 11:38, Carlo Stemberger <
carlo.stemberger@gmail.com> ha scritto:

> Il 01/11/2012 20:01, Guerrisi Antonio ha scritto:
>
>  Comunque la sostanziale differenza tra Red Hat/Canonical e Google è che
>> le prime non vendono un prodotto, ma il supporto al prodotto. Google non fa
>> assistenza (o per lo meno, non in maniera massiccia. Si limita a un
>> supporto clienti via mail, molto basilare) e guadagna sulle licenze per
>> ogni utente registrato sui domini che utilizzano Google Apps for Businnes.
>> Se l'azienda permette di installare il prodotto agli utenti sui loro server
>> chi è il fesso che paga fior fior di quattrini a Google se può benissimo
>> evitarlo?
>>
>
> Per quanto ne so io, ma non ho dati affidabili alla mano (se trovate
> qualcosa leggo volentieri) la quasi totalità del fatturato (più del 90%) di
> Google è realizzata con la pubblicità. Quindi anche perdendo quegli
> introiti, cosa che sarebbe tutta da verificare, il suo bilancio resterebbe
> analogo.
>
>
Ma non vuol dire niente. E' ovvio che un'azienda grossa non perirebbe per
la perdita di uno dei suoi prodotti. Ma va da se che se vendi un prodotto e
non fai neppure assistenza, non è che un giorno di punto in bianco ti metti
a regalare questo prodotto. Lavoreresti completamente a perdere in quel
settore. Lo stesso discorso non vale per Red Hat e Canonical perchè il
prodotto su cui lavorano è già gratis. Il loro compito è esclusivamente
quello di fare assistenza, e se lo fanno pagare, a prescindere dal fatto
che tu abbia pagato o meno il prodotto.

>  In che modo esattamente Google limita la libertà dei propri utenti?
>>
>
> Solo qualche esempio che mi viene in mente al volo, senza alcuna pretesa
> di completezza:
> 1) hai la libertà di cancellare tutti i dati che ti riguardano presenti
> sui server di Google (il cosiddetto "diritto all'oblio", tema d'assoluta
> attualità)? Su un PC o un server in cui io ho accesso diretto, posso
> lanciare DBAN per ottenere un disco come uscito di fabbrica. Col cloud non
> potrai _mai_ essere sicuro di aver spazzato via tutto definitivamente.
> 2) hai la libertà di usare i servizi di mappe di Google per qualsiasi
> scopo (anche commerciale)? No, ed è proprio in risposta a questi limiti che
> è nato OpenStreetMap.
> 3) hai la libertà di scegliere sotto che licenza pubblicare su YouTube _i
> tuoi_ contenuti multimendiali, di cui detieni i diritti d'autore? No, puoi
> solo scegliere tra 2 possibilità (licenza YouTube standard e Creative
> Commons - Attribuzione), la seconda tra l'altro aggiunta solo di recente.
> Questa cosa la trovo molto irritante, perché ad esempio Wasembo non potrà
> essere pubblicato su YouTube, a meno di non rinunciare alla clausola share
> alike.
>
> Sicuramente di esempi analoghi se ne possono trovare a decine, per ognuno
> dei servizi forniti da Google.

Tu stai solamente elencando le modalità di operatività di Google. Il punto
però è che nel contempo la stessa azienda non sta acquistando altri
prodotti per toglierli dal mercato come faceva Microsoft. L'utente HA
SEMPRE la libertà di non utilizzare il prodotto se non trova giusti i TOS.
Un esempio pratico con Wasembo. Il progetto è finito e ti trovi davanti a
una scelta. Sfruttare l'enorme potenziale di diffusione e pubblicità che ti
offre youtube, rinunciando alla clausola share alike, o pubblicarlo su un
altro dei millemila
servizi<http://www.masternewmedia.org/it/2006/11/26/online_video_publishing_dove_condividere.htm>
come
ad esempio Blip.tv o OurMedia che dalle descrizioni nel link di prima a
quanto pare ti permettono di scegiere diverse licenze o addirittura
caricarne una tua. Che poi la scelta più conveniente sia Youtube perchè il
parco di utenti che possono accedere al video e praticamente il mondo
intero, non significa che tu sia costretto o limitato in qualche maniera a
pubblicarlo li. (e in ogni caso la clausola share alike su youtube è un po
anacronistica visto che "in teoria" non si potrebbero scaricare i video da
youtube, quindi neanche ricondividerli).

>  quali sarebbero queste licenze che non verrebbero rispettate e che
>> "contano meno della carta igienica"?
>>
>
> Non ci sono licenze che non vengono rispettate; non ho mai detto niente
> del genere. Qualsiasi licenza software (libera o proprietaria o del tutto
> assente è indifferente) non conta niente in ambito cloud, perché la perdita
> di controllo avviene con l'utilizzo stesso del servizio, indipendentemente
> da come esso venga realizzato dal punto di vista tecnico.
>
>
Questo non è vero. Il fatto è che tu registrandoti al servizio stai
accettando una licenza che copre le altre. Se non ti sta bene puoi sempre
continuare a utilizzare il tuo software sul tuo server per continuare a
fare quello che ti pare.

>  Per quanto riguarda chromium ok, ho esibito tutta la mia ignoranza
>> sull'argomento, ma continui a darti sempre di più la zappa sui piedi. Non
>> solo l'azienda ti rilascia un suo prodotto senza vincoli, ma ti rilascia
>> pure la versione che ancora sta sviluppando. Un motivo in meno per
>> lamentarsi (perchè si, uno che esordisce dicendo che "stiamo" perdendo la
>> partita e che il futuro è apocalittico, non lo fa perchè è contento della
>> situazione.
>>
>
> Ma infatti nessuno si sta lamentando del software libero sviluppato da
> Google! Google supporta il software libero in tantissime occasioni; gli
> esempi si sprecano. Cito nuovamente la premessa fatta nell'e-mail da cui è
> partita tutta la discussione:
>
>  prendiamo il caso di Google: e' indubbio, usa largamente sw libero.
>> non solo: in molti casi promuove attivamente, e spesso addirittura
>> finanzia, i progetti del sw libero.
>>
>
> Il punto però non è questo. La questione riguarda l'utilizzo dei servizi
> cloud, che rischiano di rendere vane le conquiste compiute negli anni
> precedenti nei confronti delle libertà degli utilizzatori di prodotti
> informatici. Il fulcro del ragionamento si sta spostando dalla libertà del
> codice sorgente, alle possibilità di controllo dei dati. Prima bastava
> usare un software libero installato sulla propria macchina per avere il
> pieno controllo dei propri dati. Con i servizi web-based, da alcuni anni e
> man mano in modo sempre più pervasivo, non è più così.

Come sopra, a scegliere di usare i servizi cloud è l'utente. Di server
housing ce n'è a non finire. hai ancora tutta la facoltà di tirarti in
piedi un server mail o di condivisione file, e fare le stesse cose che fai
con le Google Apps.

>  Per quanto riguarda il software su android non è affatto vero che sarebbe
>> come ricominciare da capo. Basta prendere il software ed adattarlo ai
>> processori e ai sistemi su cui andrà a girare.
>>
>
> Non ho capito...
>
> Prendi un qualsiasi software scritto, chessò, in PySide (Python + Qt).
> Fallo girare su Android. Non riesci, a meno di non riscriverlo totalmente
> da zero in Java con le librerie grafiche di Google.
>
> E così è per quasi tutto il software che trovi nei repository Debian.

>  Allora siccome si è sviluppato software unix per 30 anni per i prossimi
>> 30 bisogna utilizzare solo sistemi UNIX perchè nessuno ha voglia di
>> adattare ed evolvere?
>>
>
> No, chi ha detto mai questo? Il programmino di cui sopra girerà senza
> problemi su Debian, su Fedora, su [altra distro a scelta], su MacOSX, su
> Windows (che non è unix), su Meego, su Symbian (che non è unix)... il tutto
> senza cambiare una riga di codice.
>
> Su Android non è possibile. Punto. A me sembra di essere tornati indietro
> di almeno 15 anni, considerando che la programmazione multipiattaforma era
> cosa ormai assolutamente assodata.
>
>
Se il software gira su Windows e Symbian che sono la cosa più lontana da un
sistema UNIX, significa che qualcuno li ha riscritti o adattati già dal
principio per farceli girare su quei sistemi. Allora perchè non lo puoi
fare per Android? Il sistema del futuro è quello, quindi bisognera adattare
i programmi ANCHE a quello se l'idea è di farli girare su mobile.

--
Guerrisi Antonio
http://antonio.guerrisi.info
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/pipermail/glux/attachments/20121102/07598cb9/attachment.html>