Deposito sorgenti presso terzi a garanzia del cliente

di il
4 risposte

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?

Grazie,
Michele

4 Risposte

  • Re: Deposito sorgenti presso terzi a garanzia del cliente

    Più che un avvocato, direi un notaio.
    Secondo me comunque un'azienda che si rivolge ad una piccola (o media) o software house per un servizio cloud dovrebbe accettare il rischio che la software house interrompa di colpo il servizio. Altrimenti si rivolga a Google, Microsoft o Oracle (in realtà il rischio c'è comunque, ma dovrebbe essere molto ridotto).
  • Re: Deposito sorgenti presso terzi a garanzia del cliente

    Potete vendere i sorgenti, e farvi pagare la proprietà intellettuale.
    In tal caso ne fanno ciò che vogliono.
    Altre forme sono 'fuori mercato', ma voi siete comunque liberi di fare come più vi aggrada.

    Gli accordi blindati lasciano il tempo che trovano, a mio avviso.
  • Re: Deposito sorgenti presso terzi a garanzia del cliente

    gibra ha scritto:


    Potete vendere i sorgenti, e farvi pagare la proprietà intellettuale.
    In tal caso ne fanno ciò che vogliono.
    Altre forme sono 'fuori mercato', ma voi siete comunque liberi di fare come più vi aggrada.
    Non mi è chiaro perchè sarebbero fuori mercato.

    gibra ha scritto:


    Gli accordi blindati lasciano il tempo che trovano, a mio avviso.
    Non potrei essere più d'accordo
  • Re: Deposito sorgenti presso terzi a garanzia del cliente

    mikele78 ha scritto:


    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?...
    certo che sì, ma la questione dipende da un approccio dilettantesco o professionale.
    nel primo caso ci sono da prendere in considerazione solo i sorgenti, nel secondo una macchina virtuale, preconfigurata con tutto quanto il necessario
    .
    Infatti non è per nulla scontato che i sorgenti siano sufficienti per poter tenere in piedi "la baracca" (se essa è complessa, ovviamente se parliamo di 4 scriptini PHP il problema è minimo), così come non lo è essere certo che l'applicazione X scritta oggi e che funziona bene con la versione Y di Java, PHP, Apache, Nginx o "stica..." funzioni bene magari con una versione diversa tra anni.

    Ovviamente di nuovo dipende se vuoi fare una cosa "seria" (cioè pacco-completo) o "problemi del cliente".
    ---
    Comunque la prassi è quella che tu carichi su uno spazio DEL CLIENTE (es. FTP) la macchina virtuale, o i sorgenti, CRIPTATI (così problemi del cliente conservarli, non farti "fregare" prendendoti questa incombenza).
    Questo elemento è importante: dovrà essere contrattualmente stabilito che è il CLIENTE a dover verificare sia il caricamento, sia la data, sia la conservazione (tipicamente carico due file: i sorgenti numerati sorg00000001.zip, sorg00000002.zip... e sorg00000001.txt, dove ci metto l'hash SHA256 del file, sicchè il cliente possa verificare che è ben caricato).

    Sarà il cliente a pagare lo spazio (normalmente un banale FTP di un suo server): a me è capitato nel caso di semplici sorgenti piccoli di usare caselle gmail: ogni TOT una procedura fa uno snapshot dei sorgenti, li cripta, e li spedisce alla casella gmail concordata e in BCC a me stesso. Costo essenzialmente zero per il cliente e sbattimento quasi zero per me.

    In altri casi ho depositato uno ZPAQ della macchina virtuale che uso per lo sviluppo (quindi con l'ambiente, il compilatore, le librerie e insomma tutto quanto necessario per fare una build "da zero") aggiornato con rsync --append.

    In tal modo nel filettone ci sono dentro tutte le versioni "da sempre a sempre" (cosa utile anche a me a scopo di backup) e l'upload richiede (con fibra normalissima) una ventina di minuti.

    Infine mi è capitato come sopra, cioè uno ZPAQ, ma di un volume truecrypt (sorgenti troppo grandi per essere comodamente "zippati e uploadati"), che ha pure il vantaggio di essere ovviamente criptato di suo, oltre a darmi la certezza al 100% di copiare tutto quanto (dentro tipicamente ci lascio l'immagine ISO dell'installatore del compilatore nella versione che ho usato, non si sa mai...)

    La password però la comunichi a qualcuno di fiducia (es. avvocato-non-bandito, insomma uno affidabile che nel caso non si faccia "corrompere"), in busta chiusa, il quale la consegnerà al cliente solo qualora capiti l'evento X.

    Ovviamente l'avvocato lo scegli tu, ma lo paga il cliente.
    Se sei paranoico all'inverosimile puoi anche prenderne due, di avvocati, dando a ciascuno mezza password, ma mi pare eccessivo anche per i miei standard

    Lascerei perdere i notai perchè non hanno in generale molta "voglia" di impelagarsi in queste beghe (almeno quelli che ho conosciuto).
    Magari un notaio giovane (<40 anni) è più portato a queste "tecnologie", non lo posso escludere.
    Puoi sempre fare un giro di telefonate.
Devi accedere o registrarti per scrivere nel forum
4 risposte