[Diritto] Re: Scacco matto al software proprietario [lungo]

[Leonardo Boselli]

On 8 Nov 2002, at 8:48, Paolo Pedaletti wrote:
> > > Ovviamente il mezzo preferito per i pagamenti sar=E0 la carta di
> > > credito
> > conosci qualcuno qui in italia disposto a usare una carta di credito
> > su internet? conosci qualcuno disposto a donare soldi a uno
> > sviluppatore di free software? hai provato ad intersecare le due
> > categorie?
> infatti l'idea e' quella di evitare l'uso della carta di credito o
> della donazione da parte del singolo "sponsor" per limitare al massimo
> lo spreco di soldi dovuto alla transazione (internazionale, anche)
> Servono(servirebbero) punti di raccolta locali, concentrati durante
> eventi nazionali.

Il problema =E8 quello tipico dei "micropagamenti". Quei pagamenti di 
misura limitata in cui il costo della transazione =E8 notevole sul valore 
dello stesso. Spesso si ricorre al contante, ma non sempre =E8 
possibile: le altre tecniche sono quelle delle carte valore del 
fastpay e delle password one-shot.
Il fast pay lavora su carte bancarie e carte di credito per pagamenti 
di valore "limitato" . in questo caso basta il passaggio fisico della 
carta per cui la transazione viene registeata e viene inoltrata 
all'istituto di credito in modo batch, mensile o al raggiungimento di 
un certo importo. =C8 la tecnica utilizzata per il pagamento delle 
autostrade e l'acquisto dei biglietti ferroviari con carta di credito ai 
distributori automatici.
Il problema di questo metodo =E8 che occorre che la istituzione che 
lo utilizza sia di fiducia, e che fornisca un qualcosa che possa 
essere verificato (il titolo di passaggio) . A nessuno in un 
autostrada o in trenitalia verrebbe in mente di clonare una carta e 
fatturare biglietti inesistenti in quanto non ci sarebbe un ritorno 
immediato proporzionale al rischio. Ma dare i codici in mano a 
"sconosciuti" che se li passano sarebbe rischioso, quindi si 
esclude.
Esiste la tecnica della carta di credito =EFnternet"emessa da alcune 
banche, ma ha un piccolo problemuccio: =E8 prepagata, ossia tu 
prima cacci fuori i soldi, che poi puoi usare per pagare. A parte il 
lucro per l'emittente c'=E8 il problema psicologico del pagamento 
anticipato.
Restano le tecniche della carta valore e della password one shot: 
la carta valore non =E8 applicabile, in quanto richiede l'accesso 
diretto alla stessa, il tocken elettronico =E8 invece pi=F9 interessante: 
l'emittente ti vende un numero di monete elettroniche, diciamo 50 
monete da 1 euro, che consistono in pratica in un assegno 
amesso all'ordine del richiedente.
Chi deve pagare fa la girata elettronica (firma digitale) a nome del 
beneficiario che pu=F2 quindi presentare all'incasso l'assegno 
(messaggio e-mail) e avere accreditato sul suo conto.
L'emittente quindi periodicamente o al raggiungimento di una 
somma minima effettuere il pagamento o il bonifico al beneficiario.
Lo stesso potrebbe avvenire con  normali assegni "digitali".
problema: occorre una struttura efficiente per le firme digitali e che 
gli istituti bancari riduicano drasticamente le commissioni per 
questo tipo di operazioni (alcune gi=E0 lo fanno, ma richiedon0o un 
pagamento di un canone mensile, ragionevole per chi fa un uso 
intenso della cosa, non ragionavole per chi invece ne fa un uso 
"normale" o limitato).
Fra l'altro capita spesso che chi ha bisogno di fare questo tipo di 
pagamenti ne senta la necessit=E0  solo all'ultimo momento, quando 
tutta la procedura non =E8 pi=F9 possibile per motivi di tempo.

L'idea del punto di raccolta per=F2 crea un'altro tipo di problema: 
mentre se contribiuiosci allo sviluppatore sai gi=E0 le spese di 
transazione a chi vanno, se dai a una organizzazione ti =E8 meno 
chiaro chi paghi le spese, per cui ci sono altre remore, per tacere 
del fatto che questo implica o che ti incontri di persona, oppure che 
spedisci i soldi (e il problema riparte)

Una prima idea che mi era venuta era quella di chiedere a chi 
vende delle distribuzioni di vendere anche una versione "contributo" 
.
In questo caso chi la acquista riceverebbe anche un token che gli 
consente di decidere  inviandolo per posta elettronica o meno in 
che percentuale distribuire tale contribiuto tra gli sviluppatori dei 
vari programmi presente _e_non_
Il problema =E8 che di fatto su questo contribito andrebbe a caricarsi 
anche una percentuiale al rivenditore e non so se tutti siano onesti 
da non caricarci o caricarci solo una quata nominale ...
Una seconda possibilit=E0 sarebbe di inviatere tutti coloro che 
vogliono sostenere a dare il contributo ...
come ?
una "organizzazione" alla quale ciscauno "prometter=E0" con 
messaggi e-mail o altro il versamento di contributi per lo sviluppo 
del software (ma potrebbe essere anche per opere letterarie o 
musicali) a beneficio di singoli sviluppatori o team di sviluppo.
(magari potrebbe decidere nel tempo, dopo provati i vari prodotti ... 
come prendere un libro e decidere quanto pagarlo dopo averlo letto).
Quando la somma "promessa" raggiunger=E0 una somma decente 
(diciamo 50 euro ... ) oppure trascorso un certo tempo dalla prima 
promessa (diciamo 3 mesi) sar=E0 richiesto il pagamento in unica 
soluzione a questa "organizzazione"che provveder=E0 a redistribuire 
la somma tra tutti gli sviluppatori (direttamente a quelli locali, 
indirettamente con un unico trasferimento di fondi a beneficio di 
altre organizzazioni locali per altri gruppi pi=F9 o meno organizzati).
In questo m do certamente si ridurrebbe il numero dei 
microtrasferimenti ma >
 Non si rischia di avere una copia della SIAE ? 
 Dal punto di vista tributario che probvlemi potremmo avere ?


--
Leonardo Boselli
Nucleo Informatico e Telematico del Dipartimento Ingegneria Civile
Universita` di Firenze , V. S. Marta 3 - I-50139 Firenze
tel +39 0554796431 cell +39 3488605348 fax +39 055495333
http://www.dicea.unifi.it/~leo