[AcLab] R: google sharing

[Angelo Rosina]

--- Gio 18/11/10, santec a riseup.net <santec a riseup.net> ha scritto:


> Ti esprimo le mie perplessità su Yaci, poi ovviamente tu
> mi dirai se
> sbaglio o se non sei d'accordo:
>
> - La licenza: la GPL2 non è più adatta a garantire la
> libertà del software
> (non ostacola i brevetti, la tivolization, etc etc), e
> comunque non ha mai
> garantito la libertà dei software che girano in rete,
> libertà che può
> essere garantita solo dalla AGPL. Se io installo un forum
> GPL e tu lo usi,
> l'utente sei tu, non certo io. Ma non sei libero di vedere
> le modifiche
> che ho fatto al codice, modificarlo a tuo volta,
> redistribuire versioni
> modificate o non modificate. SUL WEB, la GPL è di fatto
> una licenza
> proprietaria.

Il concetto è abbastanza discutibile: una licenza libera, in realtà, non deve necessariamente includere anche la "clausola virale". Licenze come la FreeBSD sono assolutamente libere, ma non impediscono nemmeno di rilasciare una variante dello stesso programma con licenza proprietaria.

Quello che conta, in realtà, è che tu possa prendere il programma, modificarlo, usarlo e ridistribuirlo liberamente, e che non esistano clausole che permettano di revocare tale libertà in futuro.

Addirittura, alcuni programmi liberi usano il dual-licensing: sono cioè disponibili sia con licenza libera che proprietaria.

Ad esempio, se io scrivo un linguaggio di programmazione nuovo, potrei rilasciarlo con una licenza come la GPL o la AGPL: se anche il modulo runtime è sotto una di queste licenze, ciò significherebbe che tutti i programmi scritti usando il mio tool di sviluppo dovrebbero essere rilasciati con tali licenze (perchè includono il runtime).
Per te o per me, credo che una condizione del genere andrebbe benissimo; ma un utente che volesse a tutti i costi realizzare un programma proprietario non potrebbe usare il mio tool. A questo punto, io potrei però rilasciare (a pagamento) una edizione dello stesso programma con licenza EULA, che non permetta nè la modifica, nè la ridistribuzione del mio programma, ma che autorizzi l'uso del runtime (non modificato) all'interno di programmi con altre licenze. Non c'è il rischio che nascano dei fork non liberi, dal mio programma, perchè tu hai il programma con licenza AGPL (che ti permette di realizzare dei fork, ma solo liberi), mentre l'utente che ha comprato la versione con licenza proprietaria non può nè ridistribuirla, nè realizzare dei fork di qualunque tipo.
In questo modo, siamo tutti contenti: tu hai il programma libero, nella versione più aggiornata, e puoi anche forkarlo, nel caso in cui le mie scelte non ti piacessero; io posso continuare lo sviluppo, e mi guadagno anche un po' di soldi; e l'utente che voleva usarlo per sviluppare programmi proprietari (e che comunque non l'avrebbe mai usato per realizzare programmi liberi, piuttosto avrebbe usato qualcos'altro, quindi non c'è da avere rimpianti) potrà farlo.
Inoltre, con una soluzione del genere ogni utente contribuisce allo sviluppo di un programma libero: alcuni utenti contribuiscono a migliorare la versione libera del programma, altri utenti usano quel programma per scrivere nuovi programmi liberi, e infine altri utenti, che per principio non vogliono saperne di scrivere software libero, almeno contribuiranno fornendo soldi.

Per quanto ne so, il linguaggio di programmazione kbasic usa una soluzione simile.

Tutto questo, per ricordare che anche il software libero può seguire diversi modelli, e che quindi è meglio non pensare in termini di licenza, ma in termini delle 4 libertà:

http://it.wikipedia.org/wiki/Software_libero#Le_.22quattro_libert.C3.A0.22

La domanda, quindi, è: se adesso io mi metto ad usare Yacy, usufruisco delle quattro libertà? La risposta è: sì, finchè per farlo io mi scarico il programma sul mio computer, e lo uso lì. Non usufruisco delle suddette libertà (non è detto, almeno) se mi collego ad un server con yacy installato sopra. D'altra parte, ogni giorno, quando ci colleghiamo a qualche sito, quante volte ci viene messo a disposizione il sorgente del server? Ben poche. Non possiamo pretendere di controllare i server degli altri; l'importante è che possiamo avere il pieno controllo sui nostri.



> - Lo sviluppo sembra aperto, ma guardando la pagina su
> berlios... vedo un
> solo bug, nessuna feature request, nessuna patch, strano
> perchè i forum
> del sito sono molto usati... è difficile capire se è
> abbandonato
> (perdonabile) o se lo sviluppo sembra aperto ma non lo è
> (in questo caso
> non mi scandalizzo perchè non è aperto, ma perchè finge
> di esserlo)

In realtà, un software libero non richiede necessariamente un modello di sviluppo aperto. L'unico requisito è che, per ogni build che viene pubblicata, sia pubblicato anche il sorgente corrispondente. C'è chi mantiene il sorgente online, e aggiunge ogni minima modifica, ma c'è anche chi preferisce sviluppare a casa sua le versioni sperimentali, e pubblicare solo le versioni stabili.
Personalmente, ho sviluppato un paio di programmi (ora sono su sourceforge), entrambi liberi, ma non pubblicato tutte le versioni intermedie, anche perchè mi è capitato molte volte di fare qualche modifica e poi, dopo qualche giorno, di accorgermi che non andava bene e tornare alla versione originale: pubblicare tutto mi avrebbe richiesto troppo tempo, e avrebbe comportato più problemi che altro.
Quando riuscivo a ottenere dei miglioramenti significativi, pubblicavo una versione funzionante, con tanto di sorgente: così, chi voleva poteva ricompilarsela subito. Inoltre, in certi casi, ho dovuto anche bloccare delle features, perchè incomplete o buggate (con un po' di fortuna, spero di riuscire a renderle funzionanti nelle versioni future): nel sorgente ci sono, e possono essere riattivate, volendo, ma il mio scopo è impedire che gli utenti alle prime armi le attivino per sbaglio, e si ritrovino poi a lottare con problemi di non facile risoluzione; un utente capace di trovare le funzioni inattive, e riattivarle, dovrebbe possedere almeno le conoscenze di base necessarie per rendersi conto dei potenziali problemi di tali funzioni, e regolarsi di conseguenza (anzi, se per caso riesce a trovare una soluzione funzionante e me lo dice mi fa un favore).

Perciò, posso anche capire le scelte dei progettisti di yacy: un programma come yacy richiede che esistano tanti peer in circolazione, tutti in grado di usare gli stessi protocolli. La diffusione di un numero eccessivo di copie in versione alpha, con funzioni sperimentali e piene di bug, rischierebbe di creare malfunzionamenti sull'intera rete.


> - Mi lasciano perplesso gli sponsor.
> - Mi sembra lento, ma questo forse è dovuto al fatto che
> ci sono poche
> installazioni.

La lentezza è, effettivamente, un problema. Dipende in parte dal fatto che il programma è in Java (che, notoriamente, non è velocissimo), ma soprattutto dalla natura intrinseca delle ricerche in P2P.
Se hai usato emule, qualche volta, sai cosa intendo: con emule potevi cercare un file sfruttando i server (e in tal caso, la ricerca era abbastanza veloce, ma i server potevano raccogliere dati su di te), oppure potevi usare la rete kadmelia (una vera e propria ricerca P2P, anche se più semplice) per cercare i file: la ricerca sulla rete kadmelia era molto più lenta che la ricerca con i server, e poteva richiedere anche diversi minuti per mostrare tutti i risultati.
Se pensi a come funziona una ricerca basata sul P2P, capisci subito il perchè: quando tu digiti la tua richiesta, il peer interrogato per prima cosa controlla se è in grado di fornirti qualche risultato (e in tal caso, i suoi risultati, anche se poco attinenti, compaiono subito); poi, interroga i peer a cui è connesso (che di solito non sono molti), si fa trasmettere le risposte, e le visualizza (e questo richiede già un po' di tempo); poi, i peers interogati ritrasmettono la richiesta ai peers connessi a loro, e così via, in una cascata che richiede sempre più passaggi, quanto più è grande la rete. Dal momento che molti peers non rispondono subito, e che alcune linee non sono molto veloci, ognuno di questi passaggi può richiedere anche qualche secondo. Più la rete si ingrandisce, più lungo sarà il tempo necessario per completare una ricerca (anche se, in realtà, spesso i risultati desiderati diventano visibili prima che la ricerca sia
completa: quando i server più lenti, o più lontani, stanno ancora venendo interrogati, i risultati dei peers più veloci sono già visibili).
La "catena" di chiamate, da un peer all'altro, è fatta in modo che ad ogni passaggio in più diventa possibile contattare un numero di peers circa doppio: quindi, man mano che il numero di peers cresce, la velocità di ricerca diminuirà, ma diminuirà in misura minore (se si passa da 1000 a 2000 utenti, la velocità si riduce di 1: però, poi, la rete può crescere fino a 4000 prima che la velocità diminuisca nuovamente di 1)

Purtroppo, per questo limite c'è poco da fare, perchè è intrinseco nel modello P2P; anche se riprogettassimo un motore di ricerca P2P da zero, incontreremmo lo stesso problema.

Mi rendo conto perfettamente che yacy è ben lontano dal rimpiazzare Google. Posso solo fare un parallelismo: negli anni 90, quando Windows stava dominando nell'ambito desktop, e gnu/linux era poco più che un progetto per appassionati, ben pochi lo usavano sui loro computer, e quasi nessuno lo usava come unico sistema operativo. Linux non poteva competere con i sistemi proprietari: mancavano i moduli per un mucchio di periferiche, c'era pochissimo software, e quel poco software che c'era era molto indietro: i word processor erano testuali (oppure c'era AbiWord, che però era molto indietro, rispetto a MS Word), non c'erano giochi (a parte scacchi, e qualche altro gioco del genere), l'unico browser era lynx, e così via. Era praticamente impossibile convincere l'utente medio a rimpiazzare windows con una distro linux.
E anche chi installava una distro linux, spesso si teneva anche un altro sistema operativo, e lo usava per il lavoro di tutti i giorni. Ma il risultato qual'è stato? Piano piano, questi appassionati hanno iniziato a creare un parco software più avanzato: inoltre, molti hanno iniziato a sviluppare per più piattaforme, includendo anche linux, e così oggi abbiamo un sistema operativo libero, competitivo, e usabile nelle attività quotidiane.

Allo stesso modo, oggi, non possiamo sostituire Google con Yacy. Ma possiamo iniziare ad usarli entrambi, a favorire uno sviluppo di Yacy, e così forse in futuro Yacy sarà una vera alternativa ai motori di ricerca proprietari.

Non possiamo buttare Google e usare solo Yacy, esattamente come dieci anni fa non potevamo buttare Windows e usare solo Linux: ma usandoli entrambi, possiamo trasformare Yacy in qualcosa di veramente valido.
La soluzione, di sicuro, non è quella di cercare di ingannare Google, esattamente come dieci anni fa la soluzione non era quella di craccare windows.

Bye