<br><div class="gmail_extra"><div class="gmail_quote">Il giorno 02 novembre 2012 11:38, Carlo Stemberger <span dir="ltr"><<a href="mailto:carlo.stemberger@gmail.com" target="_blank">carlo.stemberger@gmail.com</a>></span> ha scritto:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Il 01/11/2012 20:01, Guerrisi Antonio ha scritto:<div class="im">

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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?<br>


</blockquote>
<br></div>
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.<div class="im">

<br></div></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In che modo esattamente Google limita la libertà dei propri utenti?<br>
</blockquote>
<br></div>
Solo qualche esempio che mi viene in mente al volo, senza alcuna pretesa di completezza:<br>
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.<br>


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.<br>
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.<br>


<br>
Sicuramente di esempi analoghi se ne possono trovare a decine, per ognuno dei servizi forniti da Google.</blockquote><div><br></div><div>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 <a href="http://www.masternewmedia.org/it/2006/11/26/online_video_publishing_dove_condividere.htm">millemila servizi</a> 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).</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
quali sarebbero queste licenze che non verrebbero rispettate e che "contano meno della carta igienica"?<br>
</blockquote>
<br></div>
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.<div class="im">

<br></div></blockquote><div> </div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>


</blockquote>
<br></div>
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:<div class="im">

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
prendiamo il caso di Google: e' indubbio, usa largamente sw libero.<br>
non solo: in molti casi promuove attivamente, e spesso addirittura<br>
finanzia, i progetti del sw libero.<br>
</blockquote>
<br></div>
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ì.</blockquote>

<div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
Non ho capito...<br>
<br>
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.<br>
<br>
E così è per quasi tutto il software che trovi nei repository Debian. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

 </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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?<br>
</blockquote>
<br></div>
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.<br>


<br>
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.<br>
<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div><br></div><div>--</div><div>Guerrisi Antonio</div><div><a href="http://antonio.guerrisi.info">http://antonio.guerrisi.info</a></div></div></div>