Newsgroup: it.lavoro.informatica
Titolo: Deposito sorgenti presso terzi a garanzia del cliente

Salve a tutti,
 
suppongo di non chiedere qualcosa di nuovo o eccezionale e vorrei capire 
qual'è la best practice in merito.
Supponiamo che io erogo un servizio in cloud, il cliente medio si 
abbona, paga i suoi xx euro/mese per il servizio ed in genere è contento 
così, senza che debba porti questioni tecniche sul servizio.
 
Poi arriva il cliente più grosso e strutturato, il quale però si 
convince a rimanere in cloud da te, però contrattualmente gli eroghi il 
servizio su risorse dedicate e fin qui benone.
 
Poi arriva il cliente ancora più grosso che inizia a romperti le balle 
col fatto che vuole il servizio ma vuole erogarlo Onsite.
Tu gli dici che va bene, invece di un canone mensile ci sarà una diversa 
offerta economica + contratto di supporto ed aggiornamento; senza che 
questo preveda il rilascio dei sorgenti.
Il cliente però ti rompe le balle (forse giustamente) perchè si pone il 
problema che se tu tra un anno te ne vai ai caraibi, loro rimangono con 
un oggetto inservibile che non possono sviluppare.
 
Ok, in questa situazione, NON volendo rilasciare i codici sorgente anche 
dietro firma di un accordo blindato, è una opzione percorribile quella 
di depositare periodicamente i codici sorgente presso terzi?
Diciamo non so un avvocato esperto in questioni software che dietro 
compenso annuo si fa garante del fatto che se io domani scompaio, il 
cliente può andar li a reclamare i sorgenti.
Il cliente pagherà una fee annua addizionale per servizio e potremmo 
essere tutti contenti.
 
Che ne dite?

cliente può andar li a reclamare i sorgenti.
 
A me e' capitato esattamente cosi'. Deposito dal notaio, con la clausola che 
il notaio non puo' aprire il plico fino a quando l'azienda e' in essere.
 


Bene, posso chiederti due info?
 
Con gli aggiornamenti quale era l'accordo? Cioè suppongo non fosse un 
blocco monolitico immutabile. Deposito dal notaio ogni x mesi?
 
Spannometricamente il costo annuo dell'operazione per il cliente?
 
Grazie mille!

Il 12/10/2017 07:33, Infradito ha scritto:

Teoricamente e' perfetto, ma nella pratica?...se rilasci, diciamo, 3 fix 
al mese e due release l'anno cosa fai? apri e chiudi il plico continuamente?
Altro metodo potrebbe essere depositare i sources sulle macchine dei 
clienti in modalita' criptata e le chiavi, quelle si, depositate presso 
un notaio eccetera eccetera....
Saluti
 
-- 
The three most dangerous things in the world are a programmer with a 
soldering iron, a hardware type with a program patch and a user with an 
idea.

 
 
Rispondo a entrambi.
Nella pratica non serve a un cazzo, ovviamente.
I sorgenti sono li da tempo e non sono stati mai aggiornati perche' 
questo ha un costo (che pero', per rispondere a Marcus, non conosco. Si 
e' occupato di tutto il cliente). Magari tra un po' si fara' un refresh 
del deposito.
E' una sicurezza per il cliente, poi praticamente non serve a molto. Su 
progetti di questo tipo solo per capire come funziona dal sorgente ci 
vorrebbero mesi o anni.

 vorrebbero mesi o anni.
 
Su questo quoto senza riserve.


Azzardo una risposta: utenza github "professionale", quindi con accesso 
username-password e/o con certificato, depositati in copia dal notaio.
 
In questo modo il codice è sempre aggiornato. Eventualmente non è il 
repository di sviluppo ma ci confluisce solo un'unica patch cumulativa 
ad ogni rilascio.

 un oggetto inservibile che non possono sviluppare.
 
scusa, per capire: perché "inservibile"?
considerato che ce l'avrebbero in casa, diventa *davvero* inservibile nel 
momento in cui, per qualsiasi ragione, viene meno il supporto?
 
 

 E' una sicurezza per il cliente, 
 
bah.
 
a me sembra più una logica del tipo: faccio prima a metterglielo nel culo 
che nel capo.
solo per fare un esempio: se tu domattina decidessi di abbandonare quel 
software perchè fatti due conti vedi che non ti conviene (cosa che è 
nelle tue facoltà di imprenditore), che deve aspettare che tu chiuda la 
società per avere tutela?


Magari al pagamento del canone viene rilasciata una chiave di 
attivazione senza la quale il software diventa appunto "inservibile".


in tal caso basterebbe rilasciargli una chiave permanente. senza stare ad 
inventarsi chissà quale soluzione complicata.


Beh, oddio posto che non smetterebbe di funzionare il giorno dopo e 
posto che non vi siano strumenti di licenza da essere rinnovati, tu come 
azienda potresti affidarti ad un software non più manutenuto di cui non 
hai i sorgenti?
 
Come minimo dovrebbero usare il tempo che il sistema ancora funziona per 
migrare altrove, almeno nella mia opinione.
 

 migrare altrove, almeno nella mia opinione.
 
giusto, e non è la stessa cosa che hanno accettato quando hanno comprato 
(ad esempio) windows xp?
 


In genere, chi pratica questa politica, non sono pochi, rilascia chiavi 
temporanee per assicurarsi il pagamento dei canoni ricorrenti.
Sei libero di chiamarlo ricatto, se vuoi. :-)

 considerazione il tuo software, frega niente dei sorgenti.
 
Ecco. Credo questo sia il busillis.
Lo confesso: io, i sorgenti, li ho sempre lasciati presso il cliente. Li, belli in vista e disponibili - se poi i sorgenti sono in Python o Ruby, allora il problema manco si pone.
Resto dell'idea che ciò che conta del software non siano i sorgenti, sia l'idea e la conoscenza che stanno dietro i sorgenti, e il servizio che io do nel tempo alla loro manutenzione ed evoluzione. 
La dimostrazione che do è personale e limitata, me ne rendo conto. Però TUTTI i clienti che ho - tranne uno, con cui ho baruffato a fuoco - quando hanno esigenze nuove, chiamano me. D'altra parte, dare a un qualcuno che non l'ha mai visto un pacco di qualche decina di migliaia di righe di codice (è un progetto che sto revisionando proprio adesso) senza che il tapino abbia almeno una vaga idea dei perché e percome, è un salto nel buio economicamente molto pericoloso e senza garanzia di successo.
 
-- 
Ciao!
Luca

 Sei libero di chiamarlo ricatto, se vuoi. :-)
 
sono d'accordo. ma se da una parte si è disposti a lasciare al cliente in 
testamento i sorgenti per garantirlo dopo la propria dipartita, credo che 
questa politica con quel cliente non sia più compatibile.
 


Non e' detto che i sorgenti dell'applicazione debbano comprendere anche 
le routine di protezione, che potrebbero essere realizzate tramite API 
dell' OS, per cui del tutto esterne all'applicazione. In tal caso 
l'eredita' dovrebbe consistere soprattutto della chiave perpetua, ed 
eventualmente anche dei sorgenti.

 Lo confesso: io, i sorgenti, li ho sempre lasciati presso il cliente.
 
chiaro, bisogna però fare un distinguo importante.
 
se il software è sviluppato su commessa di quel cliente, ci può stare 
benissimo di lasciargli anche i sorgenti. d'altra parte ha pagato per 
intero lo sviluppo.
 
ma se il software non è sviluppato per quel cliente ma è un prodotto, per 
di più erogato come servizio cloud ad altri clienti, il discorso cambia 
radicalmente. vuoi i sorgenti? eh insomma, parliamone. quel software è a 
tutti gli effetti un asset della mia azienda. io t'ho nel cuore se senti 
il bisogno di garanzie, ma per dartele mica mi posso levare il pane di 
bocca.
 

 di più erogato come servizio cloud ad altri clienti, 
 
Ecco. Forse sbagliando, qui io ho dato per assodato che un pacchetto closed source, o un servizio in cloud, per definizione non prevede il rilascio di sorgenti (con i distinguo legati alle varie licenze xGPL). 
 
-- 
Ciao!
Luca


non ho capito il nesso di questa precisazione.
 

 bocca.
 
Esattamente, è chiaramente questa situazione.
 
Mettiamo che io erogo un servizio cloud, in continua evoluzione e 
costato millemila ore di sviluppo.
Mettiamo che adesso ho un centinaio di clienti e fatturo diciamo 100k.
Tra un anno potrei avere 500 clienti e fatturare 500k e magari tra tre 
anni potrei fatturare qualche milione con clienti in vari paesi.
 
Non esiste una sola ragione al mondo percui un cliente seppur grosso, 
anche dandomi 4/5k all'anno, possa ottenere i sorgenti.
 
Pur non fornendogli TUTTI i dettagli e sorgenti dell'infrastruttura, 
potenzialmente prendi quei sorgenti, li rimarchi e fai partire un 
servizio a me concorrente.
Ovviamente non esiste. Preferisco perdere il cliente.
 
Michele


Mi sembra che ci stiamo dirigendo un po' fuori tema....
Tu ipotizzi un'attivita' in costante ascesa.
Il tema all'oggetto contemplava solo il caso di fallimento/chiusura 
dell'azienda autrice del software, e comunque non era ipotizzata una 
legge che obbligasse lo shop a depositare presso qualcuno il sw. Era 
solo un'ipotesi di accordo fra le parti.


 nelle tue facoltà di imprenditore)...
 
Rootkit, mi è chiaro che il tuo è un esempio, ma mi sembra che in tal caso i 
problemi del cliente siano ben altri, perché sarà anche nelle tue facoltà di 
imprenditore ma non ti si potrebbe definire un professionista in 
quanto non sei grado di assumersi responsabilità. È vero che i contratti o 
accordi di questo tipo si rinnovano automaticamente mensilmente o 
trimestralmente senza previsione di un termine, permettendo al cliente di 
troncare in ogni momento, però è ovvio che se dai un servizio del genere 
devi poterlo continuare nel tempo. Non solo, in qualsiasi momento il cliente 
ha diritto alla copia dei dati con le intestazioni dei campi, anche se non 
sei obbligato a rivelare la tua struttura, perché i dati sono i suoi.
 
Se si avesse sbagliato a fare il prezzo, può capitare, si propone un'offerta 
diversa e se non si arriva all'accordo allora si fissa un termine di qualche 
anno, non si tronca il giorno dopo o il mese dopo, perché così si può 
mandare alla malora i clienti.
Io la vedo come una totale mancanza di serietà, altro che facoltà di imprenditore.


  Ciao,
 
non no mi pare si stia andando fuori tema.
L'ho premesso nel post d'apertura che si tratta di un servizio erogato 
in cloud, in cui in genere il cliente paga un canone mensile o annuale 
ed usa il servizio.
 
E' il il cliente "grosso" che oltre a volere l'OnSite vorrebbe anche 
avere i sorgenti per sua sicurezza, in caso per qualche motivo dovessimo 
"sparire"
 
Io sono sicuro che il nostro business crescerà ad un ritmo sempre 
maggiore ed anzi, proprio per questo avrà un valore sempre maggiore, 
ragion percui avere il sorgente in giro non mi piace proprio.
 
 

 il notaio non puo' aprire il plico fino a quando l'azienda e' in essere.
 
LOL :)
 
E` il bello e` che certe cose le dice (e le fa) seriamente.
 

 di depositare periodicamente i codici sorgente presso terzi?
 
No, perche` "periodicamente" non da` comunque nessuna garanzia. Quanto sarebbe lungo quel periodo? E quanto ti costerebbe questo deposito periodico? Io, in qualche ORA di lavoro (neanche giorni o settimane), posso variare/estendere significativamente qualunque software su cui lavoro. L'unica soluzione percorribile (in teoria) sarebbe quella di vendergli l'accesso continuo ai sorgenti; il che vorrebbe dire presumibilmente lavorare su un repository locale nel loro sistema. Pero` dovrebbero essere cosi` intelligenti da capire che un accesso del genere ai sorgenti si paga e si paga carissimo. Gli conviene?

 No, perche` "periodicamente" non da` comunque nessuna garanzia. Quanto
sarebbe lungo quel periodo? E quanto ti costerebbe questo deposito
periodico? Io, in qualche ORA di lavoro (neanche giorni o settimane),
posso variare/estendere significativamente qualunque software su cui lavoro.
 
Addirittura... Neanche Superman si avvicina a questa velocità...
 
 

 ai sorgenti si paga e si paga carissimo. Gli conviene?
 
nel caso in cui si trova l'op (ricordo, un prodotto utilizzato anche da 
altri clienti in cloud) l'unica condizione in qualche modo percorribile 
sarebbe che il cliente interessato allo sviluppo acquisisca quote della 
società. in genere succede questo. in questo modo ha tutte le garanzie 
che vuole, in cambio finanzia il progetto.
 

 società per avere tutela?
 
In molte realta' magari e' cosi', ma non e' il nostro caso.
Giusto per dire, siamo (plurale maiestatis, io sono qui da 5) nel 
mercato da oltre 30 anni in un settore tecnologicamente avanzato e di 
nicchia con clienti noti e prestigiosi in tutti e 5 i continenti.
Gia questo e' garanzia per il cliente, noto e prestigioso pure questo 
tra l'altro, il resto e' roba da legali.
Magari gli riferiro' che "rootkit" non e' d'accordo.


Toh, eppure stavolta non parlavo di coglioni ma sei comunque spuntato 
fuori tu.

 Addirittura... Neanche Superman si avvicina a questa velocità...
 
anche più velocemente. Per variare significativamente da "perfettamente funzionante" a "inutile monnezza" un codice sorgente bastano pochi secondi di cerca&sostituisci. E' il passaggio inverso che puà richiedere un attimo di tempo in più ;)
 
bye!

 tutti contenti.
 
 
Dico che qualcosa si muove:
http://www.corrierecomunicazioni.it/digital/49288_scommessa-blockchain-per-i-notai-debutta-notarchain.htm
 
 
Cerca anche "deposito escrow codice sorgente", credo risponda alla tua domanda, 
tipo questo servizio:
https://www.ewitness.eu/escrow-del-codice-sorgente/
 
 
 
ciao,
Gabriele


ma guarda caro io non sto mettendo in dubbio che siate giovani & forti. 
sto dubitando delle garanzie che offre *quel* metodo. a maggior ragione 
se la vostra azienda fornisce già di per se sufficienti garanzie 
finanziarie.
 

 
http://www.corrierecomunicazioni.it/digital/49288_scommessa-blockchain-
 
per-i-notai-debutta-notarchain.htm
 
ok, ma mi verrebbe da obiettare è una soluzione tecnica validissima ma 
per un altro problema.
il notaio dovrebbe comunque garantire sia l'identità del depositante (e 
questo è facile) che la correttezza e completezza dei dati. come fa con i 
sorgenti di un sw che nel tempo viene manutenuto?
probabilmente sono altri gli scopi di questo meccanismo, per esempio 
tutelare la proprietà intellettuale.


Apprezzabile il tentativo di sensibilizzare ciccino in merito
all'ignoranza con la quale è solito farcire i suoi post.
Apprezzabile, quanto inutile, trattandosi del soggetto in questione.
 

 anche piÃ¹ velocemente. Per variare significativamente da "perfettamente 
funzionante" a "inutile monnezza" un codice sorgente bastano pochi secondi 
di cerca&sostituisci.
 
Ah ok, quindi era a questo che si riferiva...
 
 
 

Madame Damentami <mdd...@nomail.address> ha scritto:

NON apprezzabile la tua totale ignoranza in informatica, dato che
qui dentro non hai MAI PARTECIPATO AD UNA DISCUSSIONE
DANDO ANCHE UN MINIMO CONTRIBUTO.
 
 

 ha scritto:

..Il problema è che ha detto:
 
"Io, in qualche ORA di lavoro (neanche giorni o settimane), posso 
variare/estendere significativamente qualunque software su cui lavoro."
 
Per cui non sarebbe molto a suo vantaggio questa affermazione...