Re: Scacco matto al software proprietario [lungo]
On 8 Nov 2002, at 8:48, Paolo Pedaletti wrote:
> > > Ovviamente il mezzo preferito per i pagamenti sarà 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 è quello tipico dei "micropagamenti". Quei pagamenti di
misura limitata in cui il costo della transazione è notevole sul valore
dello stesso. Spesso si ricorre al contante, ma non sempre è
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. È 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 è 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 ïnternet"emessa da alcune
banche, ma ha un piccolo problemuccio: è prepagata, ossia tu
prima cacci fuori i soldi, che poi puoi usare per pagare. A parte il
lucro per l'emittente c'è il problema psicologico del pagamento
anticipato.
Restano le tecniche della carta valore e della password one shot:
la carta valore non è applicabile, in quanto richiede l'accesso
diretto alla stessa, il tocken elettronico è invece più 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ò 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à 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à solo all'ultimo momento, quando
tutta la procedura non è più possibile per motivi di tempo.
L'idea del punto di raccolta però crea un'altro tipo di problema:
mentre se contribiuiosci allo sviluppatore sai già le spese di
transazione a chi vanno, se dai a una organizzazione ti è 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 è 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à sarebbe di inviatere tutti coloro che
vogliono sostenere a dare il contributo ...
come ?
una "organizzazione" alla quale ciscauno "prometterà" 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à una somma decente
(diciamo 50 euro ... ) oppure trascorso un certo tempo dalla prima
promessa (diciamo 3 mesi) sarà richiesto il pagamento in unica
soluzione a questa "organizzazione"che provvederà 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ù 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
Reply to: