View Full Version : Quando ti rubano un programma...
Gonnario
01-05-2016, 05:02
Ciao,
L'ora è tarda ma sono troppo preso da un discorso. La discussione è molto generica ed è sul come intervenire correttamente quando scopri che qualcuno ti ha rubato un programma. Farò degli esempi assurdi per semplificare il discorso al massimo quindi non vi soffermate sui dettagli.
Poniamo l'esistenza di questo pseudo codice che protegge il nostro programma:
IF(HAI PAGATO): AVVIA_PROGRAMMA
ELSE: MUORI;
Ora poniamo che un'azienda pur di non pagare modifichi il codice di cui sopra in questo:
IF(NON HAI PAGATO): AVVIA_PROGRAMMA
ELSE: MUORI;
In qualche modo veniamo a scoprire che questa azienda ha rubato il nostro programma e vogliamo fargli causa per danni. Tutto sta nel raccogliere prove sufficienti per dimostrare il dolo. Come tutti sappiamo, è sempre difficile dimostrare oltre ogni ragionevole dubbio che una persona abbia rubato un programma perchè l'unico modo per verificarlo con assoluta certezza sarebbe piombargli in ufficio, sequestrargli il server e trovare il pezzo di codice cracked prima che sia stato fatto sparire. Nel mondo reale purtroppo sappiamo che le cose non vanno così perchè alla prima avvisaglia si cancellerebbero tutte le prove in un attimo.
Ciò premesso, supponiamo di essere in grado di chiedere al nostro programma, anche se è stato rubato, di mostrare a video il codice sorgente. Si vederebbe chiaramente ed inequivocabilmente il codice cracked ed il tutto proveniente direttamente dal server del cliente. Credo che nemmeno l'avvocato più borioso potrebbe avere qualcosa da dire sulla veridicità dei dati.
Il discorso regge? Questa sarebbe una prova schiacciante?
Gonnario
01-05-2016, 18:09
Grazie per la risposta.
Sto parlando di un programma che girerebbe su un webserver scritto in Ruby, Java, PHP (quello che preferisci) ed offuscato in modo che il sorgente non sia visibile. L'offuscamento terrebbe a bada la maggior parte delle persone ma si sa che c'è sempre quella piccola percentuale di stronzi disposti a pagare per deoffuscare il sorgente e rimuovere le protezioni per utilizzare il programma aggrastis.
Detto questo, per rispondere alla tua domanda, si, il cliente avrebbe il sorgente offuscato. Il solo fatto che lo deoffuschi sarebbe già di per sè una violazione. Se poi lo avesse anche modificato, aggraverrebbe ulteriormente la sua situazione.
Chiarito questo aspetto, potendo obbligare il suo server a mostrare il sorgente a sua insaputa, si vedrebbe chiaramente se:
a) Il sorgente è stato deoffuscato
b) Se lo è stato, cosa altro è stato modificato
Trovandolo con le mani nel sacco (opzioni A e B vere), mi chiedo se questa prova di colpevolezza sia sufficientemente schiacciante. Non vorrei muovermi solo con prove indiziarie.
ciao guarda, secondo me ci vuole la consulenza di un avvocato che si occupi (o si sia occupato) di queste cose.
non è banale.
dipende sia dalla licenza che da quali siano prove usabili.
tu hai accesso al server?
obblighi il server a dirti se il sorgente è modificato? come?
puoi farlo? la licenza lo prevede?
altrimenti vai nell'illecito tanto quanto chi modifica.
temo ti serva un parere solido prima di qualsiasi azione.
io ho scoperto a mie spese che in questo paese assurdo se uno cambia la serratura di casa mia e io sfondo la porta eseguo un "esercizio arbitrario delle proprie funzioni" o qualcosa del genere, che è perseguibile penalmente.
detto questo ti dico anche che per lavoro mi trovo spesso a modificare, deoffuscare e controllare codice di terze parti. per vari motivi, il primo è che a volte modifichi qualcosa per farla andare "meglio" e non necessariamente cracckarla.
l'altra è perchè tu hai comprato il software ed è tuo, sviluppo compreso ;)
ho da due anni pronta una utility per decifrare l'offuscamento su oracle, vorrei vendere l'app sugli store e per i motivi di cui parli ho l'app nel cassetto.
non so cosa possa succedere con oracle.
quest'azienda che ha "rubato" il vostro software come l'ha avuto?
l'ha comprato da voi inizialmente? in questo caso la vedo complessa,
se invece l'ha copiato e riusato puro puro allora diventa più facile dimostrare che si tratta di copia e violazione di diritti.
rimango a disposizione fino dove posso con le mie competenze, anche privatamente.
ciao :)
Gonnario
01-05-2016, 22:21
tu hai accesso al server?
obblighi il server a dirti se il sorgente è modificato? come?
puoi farlo? la licenza lo prevede?
No, non ho accesso al server del cliente ma il software comunica con me per questioni di licensing. Da remoto posso anche sospendere le licenze nel caso in cui il cliente non rinnovi (il software ha un costo ricorrente). Tutto questo è ampiamente supportato dal contratto che ognuno di essi sottoscrive dove si dice chiaramente che è vietato deoffuscare. Anche se non ci sarebbe bisogno di specificarlo, è anche vietato tentare di vedere e/o modificare il codice nemmeno per il motivo più "sano" e positivo. È vietato punto. Con l'acquisto del software il cliente acquisisce la sola licenza d'uso e nessuna proprietà o diritto sull'opera.
Fatte queste puntualizzazioni, il cliente ha acquistato il software (la licenza d'uso) e lo ha deoffuscato (prima violazione) per togliere la protezione (seconda violazione) al fine di non pagare. Io sono in grado di vedere il sorgente direttamente dal suo server dove si vederebbero entrambe le violazioni. Mi domando se questo è abbastanza schiacciante come prova :D
guarda, vale comunque il discorso per cui devi sentire un avvocato che già si è occupato della cosa.
Come fai a vedere il sorgente senza collegarti al suo server?
bisogna capire se possa essere usato come prova e che tu lo facia con il consenso del cliente.
ps. che zona sei? vuoi un contatto?
(di un avvocato intendo)
zebmckey
02-05-2016, 15:26
Buongiorno a tutti;
penso che la prima domanda che vi verrà fatta prima di mettere mano ai loro server è: "in base a cosa affermi che questa ditta ha craccato il vostro programma? che prove ha?"
e dimostrarlo è complicato ....come dice les2 ti serve un ottimo avvocato e anche un buon analista forence per acquisizione dei dati...
devil_mcry
03-05-2016, 19:29
No, non ho accesso al server del cliente ma il software comunica con me per questioni di licensing. Da remoto posso anche sospendere le licenze nel caso in cui il cliente non rinnovi (il software ha un costo ricorrente). Tutto questo è ampiamente supportato dal contratto che ognuno di essi sottoscrive dove si dice chiaramente che è vietato deoffuscare. Anche se non ci sarebbe bisogno di specificarlo, è anche vietato tentare di vedere e/o modificare il codice nemmeno per il motivo più "sano" e positivo. È vietato punto. Con l'acquisto del software il cliente acquisisce la sola licenza d'uso e nessuna proprietà o diritto sull'opera.
Fatte queste puntualizzazioni, il cliente ha acquistato il software (la licenza d'uso) e lo ha deoffuscato (prima violazione) per togliere la protezione (seconda violazione) al fine di non pagare. Io sono in grado di vedere il sorgente direttamente dal suo server dove si vederebbero entrambe le violazioni. Mi domando se questo è abbastanza schiacciante come prova :D
Credo che sia più illegale l'accesso al server senza autorizzazione onestamente, di sicuro così non puoi fare. Il contratto stipulato prevede delle penali in caso di condizioni illecite o solo il mero decadimento del contratto? Inoltre nel tuo software è presente codice sotto licenza GNU GPL 3 (che è quella per lo più usata dalle librerie open source)? Ha una firma?
E' davvero difficile vincere in modo sicuro ed inoltre è da essere certi al 100% che il contratto sia inattaccabile. Tieni inoltre presente che seppur è vero tutto anche la dove c'è un contratto molto rigido e definito, dove c'è una firma e magari pure un brevetto, soluzioni del genere non porterebbero mai a molto almeno che lui non ha ridistribuito il software.
Inoltre te hai la debolezza del fatto che devi anche dimostrare che il tuo codice quando è stato consegnato non fosse già così, in Italia come garanzia self in questi casi c'è un metodo che vale abbastanza, ovvero si crea una copia su supporto non riscrivibile e si invia tramite raccomandata con ricevuta di ritorno a se stessi. Queste copie (di solito più di una) non devono essere aperte se non in caso di contenzioso per dimostrare che tu non hai a tua volta modificato il software.
Nel tuo caso te non puoi vedere il codice ne accedere al server, se lo fai mi sa che rischi molto ma molto più di loro, da quanto ho capito ti rendi conto dell'illecito solo perché risulta attivo seppur la licenza è bloccata sul tuo server ma non è che magari potrebbero aver messo un proxy in mezzo e validare le licenze o scaricarle in quel modo? Queste tecniche sono usatissime in molte situazioni e di fatto non ha alterato in nessun modo il codice ad esempio (e li ti distruggerebbero in tribunale). Ovviamente se ho capito bene. Dipende tutto da come è fatta l'architettura e il sw ambo due le parti.
Comunque sono curioso di sapere come va avanti
Gonnario
07-05-2016, 03:52
Buongiorno a tutti;
penso che la prima domanda che vi verrà fatta prima di mettere mano ai loro server è: "in base a cosa affermi che questa ditta ha craccato il vostro programma? che prove ha?"
e dimostrarlo è complicato ....come dice les2 ti serve un ottimo avvocato e anche un buon analista forence per acquisizione dei dati...
Le prove le ho e sarebbero lampanti tanto che non farebbe fatica a capirlo nemmeno un calciatore di serie A. Anche a chi non capisce nulla di programmazione si spiegherebbe in non più di 5 minuti.
Credo che sia più illegale l'accesso al server senza autorizzazione onestamente
Alt :p non ho mai parlato di avere accesso al server. È tutto molto più semplice. Parliamo di script PHP solo offuscati. Il contratto è fatto con i fiocchi e vieta il deoffuscamento e la modifica, anche solo parziale, del codice. Non entro nei dettagli ma sono previste delle conseguenze per il cliente.
Detto questo io ho modo di vedere, da remoto, il sorgente dei miei soli file installati nel server del cliente. Niente backdoor o accesso non autorizzato. Semplicemente posso farlo e così facendo in un attimo posso vedere se prima di tutto hai deoffuscato il codice (prima violazione), se hai rimosso la licenza per non pagare (seconda violazione) e se lo hai fatto è implicito che lo hai modificato (terza violazione). Non c'è molto a cui aggrapparsi. Il dolo è chiaramente visibile ed il discorso proxy non si applica.
Volendo fare un esempio è come se io avessi inventato la parola "Benvenuto" che può essere scritta solo da chi abbia acquistato la licenza.Vado davanti la porta di casa del cliente truffaldino e, senza dover entrare nè violare la sacralità del suo appartamento, vedrei lo zerbino fuori dalla porta di casa con tanto di scritta "Benvenuto". La violazione è palese.
ma se ha già violato i termini della licenza di quali altri prove hai bisogno?
poi se l'ha fatto con te magari l'ha fatto anche con altri, una bella visita della guardia di finanza e magari trovano che usa altro software tarocco
se uno non ti paga l'affitto è già in torto dolo o non dolo e tu lo puoi sfrattare
se uno usa un tuo software non rispettando i termini della licenza tu puoi agire in via giudiziale o extragiudiziale
dipende solo se il gioco vale la candela, immagino che tu non abbia i milioni che la microsoft o la BSA
sai che continuo a non essere convintissimo del tuo sistema,
salvo che non mi stia perdendo qualcosa.
hai una funzione web che ti mostra a video il sorgente e la licenza?
quindi richiami il suo server per farlo?
anche se è così temo tu debba sentire un avvocato, il contratto lo deve prevedere. in ogni caso se vuoi fare anche due chiacchiere da bar telefoniche io se posso ci sono, magari un confronto aiuta :P
rimane interessante l'argomento per tutti
Ho letto con interesse il thread ma il tutto continua a non convincermi.
Gonnario
08-05-2016, 00:04
Facciamo così, vuoto parzialmente il sacco.
Vedo che alcuni di voi sono perplessi perchè posso visualizzare il sorgente da remoto senza avere accesso diretto al server del cliente. Per ovvi motivi non scendo nei particolari ma il concetto è paragonabile al fare un curl() (un POST HTTP) dal mio server al mio script installato nel server del cliente. Solo quando il POST contiene determinate informazioni che nessuno può conoscere all'infuori di me, lo script è "istruito" affinchè mi restituisca il sorgente e da qui le prove schiaccianti. Il tutto è previsto da contratto. Banalmente è un sistema equiparabile ad un licensing script oppure una funzione che controlla che tu stia eseguendo l'ultima versione di un dato software dal server del cliente a quello dello sviluppatore.
Per ovvi motivi non scendo nei particolari ma il concetto è paragonabile al fare un curl() (un POST HTTP) dal mio server al mio script installato nel server del cliente. Solo quando il POST contiene determinate informazioni che nessuno può conoscere all'infuori di me, lo script è "istruito" affinchè mi restituisca il sorgente e da qui le prove schiaccianti. Il tutto è previsto da contratto.
Questo l'avevo intuito ergo, di fatto, pur non essendoci una vera e propria autenticazione al server, la comunicazione con quest'ultimo avviene comunque (Out--->In anziché l'inverso).
Bisognerebbe tenere a mente alcuni concetti, giuridici piuttosto che informatici in senso stretto:
-è stato così facile manomettere il codice in modo da rendere il sorgente visibile e quindi modificabile?
Aldilà della volontà di provare a bucare il codice, il livello di difficoltà con cui ci si scontra (o, al contrario, il livello di protezione con cui viene tutelato il codice) determina l'aggravio o, a volte, la responsabilità stessa dell'atto.
Per chiarirci: se io proteggo la mia casa con una porta corazzata e questa viene forzata e subisco un furto, la responsabilità ricade tutta sul ladro in quanto io posso dimostrare di aver messo in atto tutti i mezzi per proteggere il mio immobile; se io dimentico la porta aperta o la porta è chiusa ma dimentico le chiavi dentro la serratura e subisco un furto, per quanto possa apparire paradossale, c'è una sorta di concorso di colpa (vedasi le Assicurazioni che non ti rimborsano il furto).
La domanda quindi è scontata: era così facile aggirare la protezione in modo tale da rendere il codice visibile o, ponendola in altro modo, sei sicuro di aver preso tutte le precauzioni possibili (precauzioni tecniche, non contrattuali) affinché la sprotezione era un evento da considerare poco o del tutto improbabile?
devil_mcry
08-05-2016, 10:12
Questo l'avevo intuito ergo, di fatto, pur non essendoci una vera e propria autenticazione al server, la comunicazione con quest'ultimo avviene comunque (Out--->In anziché l'inverso).
Bisognerebbe tenere a mente alcuni concetti, giuridici piuttosto che informatici in senso stretto:
-è stato così facile manomettere il codice in modo da rendere il sorgente visibile e quindi modificabile?
Aldilà della volontà di provare a bucare il codice, il livello di difficoltà con cui ci si scontra (o, al contrario, il livello di protezione con cui viene tutelato il codice) determina l'aggravio o, a volte, la responsabilità stessa dell'atto.
Per chiarirci: se io proteggo la mia casa con una porta corazzata e questa viene forzata e subisco un furto, la responsabilità ricade tutta sul ladro in quanto io posso dimostrare di aver messo in atto tutti i mezzi per proteggere il mio immobile; se io dimentico la porta aperta o la porta è chiusa ma dimentico le chiavi dentro la serratura e subisco un furto, per quanto possa apparire paradossale, c'è una sorta di concorso di colpa (vedasi le Assicurazioni che non ti rimborsano il furto).
La domanda quindi è scontata: era così facile aggirare la protezione in modo tale da rendere il codice visibile o, ponendola in altro modo, sei sicuro di aver preso tutte le precauzioni possibili (precauzioni tecniche, non contrattuali) affinché la sprotezione era un evento da considerare poco o del tutto improbabile?
Ma in teoria qui il discorso è un po' diverso, se il contratto è fatto bene la terza parte non poteva modificare il codice anche se questo non fosse stato offuscato... Nel senso uno non dovrebbe farlo e basta.
Quello che dico io è che non vale la pena, ci ha messo 8 post a dire a noi che fa una POST parametrizzata in modo diverso alle API per farsi restituire i sorgenti, una cosa abbastanza banale ma che immagino che in tribunale sarà una cosa che andrà avanti mesi per capire bene (e non so comunque se sia al 100% legale in ogni caso) e alla fine probabilmente non ne uscirà quasi niente se lui non può provare che al momento della consegna il codice era diverso (questo è un punto fondamentale, serve una copia non riscrivibile del codice al momento della consegna).
Dal mio punto di vista non vale la pena
pabloski
08-05-2016, 10:28
Facciamo così, vuoto parzialmente il sacco.
Vedo che alcuni di voi sono perplessi perchè posso visualizzare il sorgente da remoto senza avere accesso diretto al server del cliente.
Ho capito cosa intendi dire e in effetti non sono d'accordo con coloro che dicono che le prove sono difficili da raccogliere.
Se il programma continua a comunicare da te da un server che non appartiene ad un tuo cliente pagano, e' gia' un indizio sufficiente per avviare un procedimento legale. Se poi puoi accedere pure ai sorgenti del programma in remoto, allora puoi spulciarli e raccogliere ulteriori favorevoli indizi.
E parliamo di indizi che non spariscono nel giro di 5 minuti, perche' il programma sta li', sta girando e continuera' a girare.
Non sono un avvocato, ma non credo che sia difficile convincere un giudice a spiccare un mandato di perquisizione.
Gonnario
08-05-2016, 14:14
Il contratto, in modo molto semplice e chiaro, vieta in ogni modo di deoffuscare il codice. Dirò anche di più. C'è un meccanismo che corrompe automaticamente il file anche solo se lo apri, premi spazio, torni indietro e salvi. Ogni file è "forgiato" alla nascita per trovarsi in un dato posto, per un dato tempo mantenendo la sua integrità.
Questo sistema remoto che mi permette di vedere il sorgente in realtà è un'idea nata da una semplice altra esigenza molto più spicciola: verificare, come sviluppatore, le versioni del software in ogni file. Capita infatti che un cliente sia convinto di avere una tale versione perchè così sta scritto nel backend ma che poi in realtà non ha sostituito il 100% dei file interessati. La struttura dei file offuscati è simile a questa:
<?
// DISCLAIMER
// [...]
// DIVIETI
// [...]
// COPYRIGHT
// [...]
// INFORMAZIONI
// [...]
?>
49650688539237733540
35552943075527471292
34191258950604933320
[...]
Quando un cliente mi segnala problemi, sono solito andarmi a checkare da remoto in un click, prima di mettermi magari inutilmente delle ore a capire perchè qualcosa non funziona, l'intestazione dei file da dove posso verificare velocemente l'integrità dei file e le loro informazioni. Dal limitarmi a guardare solo l'intestazione a guardare pochi centimetri più in basso se il codice è ancora offuscato non credo ci voglia un'autorizzazione ministeriale.
questo è un punto fondamentale, serve una copia non riscrivibile del codice al momento della consegna.
Dal mio punto di vista non vale la pena
Sono d'accordo ma non credo ci voglia una copia del codice al momento della consegna per dimostrare il dolo. Il codice viene SEMPRE consegnato offuscato e, se non lo è, non ci vuole un luminare a distinguere la differenza tra....
49650688539237733540
35552943075527471292
34191258950604933320
e
echo "Ciao mondo";
p.s. Ne vale sempre la pena :) Non sarebbe la prima volta che faccio valere le mie ragioni nelle sedi opportune. Ammetto che all'inizio è sempre dura perchè i funzionari preferiscono di gran lunga occuparsi di casi di iPhone comprati su un sito e mai arrivati piuttosto che delle mie questioni complicate ma io sotto questo punto di vista sono un mastino.
devil_mcry
08-05-2016, 14:30
Il contratto, in modo molto semplice e chiaro, vieta in ogni modo di deoffuscare il codice. Dirò anche di più. C'è un meccanismo che corrompe automaticamente il file anche solo se lo apri, premi spazio, torni indietro e salvi. Ogni file è "forgiato" alla nascita per trovarsi in un dato posto, per un dato tempo mantenendo la sua integrità.
Questo sistema remoto che mi permette di vedere il sorgente in realtà è un'idea nata da una semplice altra esigenza molto più spicciola: verificare, come sviluppatore, le versioni del software in ogni file. Capita infatti che un cliente sia convinto di avere una tale versione perchè così sta scritto nel backend ma che poi in realtà non ha sostituito il 100% dei file interessati. La struttura dei file offuscati è simile a questa:
Quando un cliente mi segnala problemi, sono solito andarmi a checkare da remoto in un click, prima di mettermi magari inutilmente delle ore a capire perchè qualcosa non funziona, l'intestazione dei file da dove posso verificare velocemente l'integrità dei file e le loro informazioni. Dal limitarmi a guardare solo l'intestazione a guardare pochi centimetri più in basso se il codice è ancora offuscato non credo ci voglia un'autorizzazione ministeriale.
Sono d'accordo ma non credo ci voglia una copia del codice al momento della consegna per dimostrare il dolo. Il codice viene SEMPRE consegnato offuscato e, se non lo è, non ci vuole un luminare a distinguere la differenza tra....
p.s. Ne vale sempre la pena :) Non sarebbe la prima volta che faccio valere le mie ragioni nelle sedi opportune. Ammetto che all'inizio è sempre dura perchè i funzionari preferiscono di gran lunga occuparsi di casi di iPhone comprati su un sito e mai arrivati piuttosto che delle mie questioni complicate ma io sotto questo punto di vista sono un mastino.
Si certo, ma il punto è che devi dimostrare cosa hai dato non cosa ha ora... tu questo lo puoi fare? Il codice viene sempre consegnato offuscato magari è vero nel tuo caso ma legalmente sono parole, potrebbe esserci stata una svista oppure un problema, pensa in ottica di aziende più grandi e mal gestite. Per questo da solo non basta. Ad esempio da noi non viene sempre consegnato offuscato, spesso si firmano solo NDA e basta. Questa cosa del dimostrare cosa hai consegnato è importante altrimenti è la tua parola contro la loro (controlli sull'hashing etc), te lo posso dire con certezza perché è capitato ad una azienda che conosco e alla fine non hanno ottenuto nulla dopo anni.
Ne vale la pena solo se vinci, se perdi o non ottieni niente oltre il danno ti trovi la beffa di doverti pagare le tue spese giudiziarie (o peggio ancora anche le loro).
Già il fatto che tu sia qui a chiederlo vuol dire che non ne sei sicuro senno avresti già mandato la diffida
Cmq nel caso in cui decidi di procedere facci sapere come va che sono curioso
Gonnario
08-05-2016, 14:43
È impossibile che venga consegnato il sorgente non offuscato perchè, restando valido il divieto per il cliente di modificarlo, semplicemente il tutto non funzionerebbe. Se lo script si rende conto di non essere offuscato sa cosa fare (muore) e se non lo fa allora vuol dire che il cliente lo ha modificato per non farlo morire. Direi che è il classico caso del cane che si morde la coda. Comunque la si voglia vedere le cose sono state fatte per funzionare in un certo modo e se non funzionano in questo modo c'è per forza lo zampino del cliente che commette un illecito.
Sono qui a chiedere info nel forum è perchè mi interessa l'opinione di altri. La certezza non mi manca ma ho bisogno di "avvocati del diavolo" che mi smonitono queste certezze e che mi facciano venire dubbi in modo da valutare al meglio come risolvere.
pabloski
08-05-2016, 15:46
Sono qui a chiedere info nel forum è perchè mi interessa l'opinione di altri. La certezza non mi manca ma ho bisogno di "avvocati del diavolo" che mi smonitono queste certezze e che mi facciano venire dubbi in modo da valutare al meglio come risolvere.
Visto il meccanismo che hai messo su, direi che l'unico dubbio puo' riguardare l'effettiva liceita' di una clausola che impone al cliente di non effettuare il reverse engineering.
In Europa se n'e' discusso molto e mi pare che un limite del genere non sia imponibile per contratto. Altro discorso e' quello del cliente che sfrutta il reverse engineering per modificare il software ed usarlo senza pagare.
avevo immaginato un meccanismo simile, quello però che continua a lasciarmi "perplesso" e per cui consigliavo un avvocato e la leicità del metodo.
un conto è il software che in autonomia chiama a casa e fa un check sulla licenza, e nel contratto comunque lo devi scrivere.
un altro è che tu interroghi e chiami il server del cliente.
ne hai diritto?
è questo il mio dubbio, perchè mi sono trovato più volte dall'altra parte
(banalmente un sorgente offuscato con versioni vecchie e non compatibile con le nuove versioni del php ;) ) o per risolvere bug dei fornitori, in ogni caso licenza o no sul mio server credo che un'interrogazione tipo la tua sia poco digeribile.
peraltro un conto è se in ritorno hai una chiave di verifica e un'altro se hai tutto il sorgente, temo.
però vedilo sempre come un dubbio, non una certezza (non sono avvocato e nemmeno lo voglioe ssere :D).
ad ogni modo coprire php con un offuscatore ormai serve a poco :P
Gonnario
10-05-2016, 23:42
ne hai diritto?
Da contratto si, ne ho diritto. Posso intraprendere determinate azioni, inclusa questa che ho descritto, per verificare l'utilizzo regolare del software ed il cliente acconsente a questo trattamento.
ad ogni modo coprire php con un offuscatore ormai serve a poco :P
In senso lato è ancora estremamente utile se il tuo software è un SaaS (software as service) che necessita di continui e frequenti aggiornamenti. Se non esegui sempre l'ultima versione ne paghi le conseguenze che vanno dal tenersi i bug ad avere problemi di compatibilità e rinunciare a tutto ciò che è nuovo e migliore. Questo software infatti è un "accrocchio" che lavora all'unisono con un altro sistema. Ogni volta che quest'ultimo viene aggiornato anche il software deve cambiare di conseguenza. Rinunciare agli aggiornamenti significa accettare di vivere nel passato. Dico questo perchè, essendo gli aggiornamenti così frequenti, il truffaldino di turno è costretto a farsi deoffuscare i file anche 100 volte l'anno. Ad una media di 6$ a botta (prezzo di mercato) fanno 600$ l'anno che è un costo nettamente superiore al costo "legale" del software stesso e tra le altre cose non hai nemmeno diritto all'assistenza. A lungo andare se non sei scemo, come questo mio unico cliente truffaidino che evidentemente ama vivere nel passato, capisci subito che deoffuscare un SaaS è una perdita di tempo e soldi.
premesso che da sviluppatore sono perchè il software venga pagato, 600 euro poi è un nulla...
il senso nella mia frase era perchè:
1) io ad esempio deoffusco php autonomamente (dipende come è offuscato ovviamente)
2) le ultime evoluzioni del php fanno cadere un po' l'uso dell'offuscatore.
3) i normali hosting non hanno installato il modulo zend guard o equivalente
ps. ha senso e gambe mettersi in più teste e creare un sistema di licenze da remoto? nel caso ci sono :P
Gonnario
11-05-2016, 18:36
Da quel punto di vista son fortunato :D il mio "accrocchio" funziona sopra a un "sistemone" che è offuscato anche lui quindi è implicito che l'hosting supporti sicuramente l'offuscatore.
Per il resto son scelte. Io deoffusco senza guardare in faccia nessuno solamente i codici malevoli ma se si tratta di script leciti prima mi leggo i termini del contratto di quello sviluppatore e se c'è scritto che non lo posso fare non lo faccio. Nel mio vecchio lavoro in una azienda medio/grande mi veniva richiesto di fottermene ma in tal senso non ho mai cambiato idea. Gli script allora li facevano deoffuscare e modificare da un mio collega meno dotato e senza scrupoli. Io non ci mettevo nemmeno un dito lì dentro :ciapet: manco guardarlo.
ps. ha senso e gambe mettersi in più teste e creare un sistema di licenze da remoto? nel caso ci sono :P
Un bel sistema di licenza da remoto lo tengo già. È bello e fantastico... premi il pulsante "Revoca licenza" ed i siti del cliente smettono di funzionare, vedi dove si trovano gli script, il log di tutti i check delle licenze ecc. peccato che basta cambiare un return false in true (in realtà no ma si fa per dire) per aggirare il sistema :D :D :D (offuscamento permettendo). Il tal senso non mi illudo. Puoi fare il sistema più avanzato e complesso del mondo ma se la logica sta dentro lo script un modo per fotterti lo trovano sempre.
È impossibile che venga consegnato il sorgente non offuscato perchè, restando valido il divieto per il cliente di modificarlo, semplicemente il tutto non funzionerebbe. Se lo script si rende conto di non essere offuscato sa cosa fare (muore) e se non lo fa allora vuol dire che il cliente lo ha modificato per non farlo morire. Direi che è il classico caso del cane che si morde la coda. Comunque la si voglia vedere le cose sono state fatte per funzionare in un certo modo e se non funzionano in questo modo c'è per forza lo zampino del cliente che commette un illecito.
Sono qui a chiedere info nel forum è perchè mi interessa l'opinione di altri. La certezza non mi manca ma ho bisogno di "avvocati del diavolo" che mi smonitono queste certezze e che mi facciano venire dubbi in modo da valutare al meglio come risolvere.
Al di la della sviluppi legali della cosa quello che stanno cercando di dirti con questo :
Se il cliente dice che il software lo ha ricevuto cosi e la tua parola con la sua.
Certo tu dici che tu dai i software offuscati con il controllo della licenza.
Lui può dire che il software che non ha mai modificato il software lo hai spedito cosi.
devil_mcry
11-05-2016, 22:50
Al di la della sviluppi legali della cosa quello che stanno cercando di dirti con questo :
Se il cliente dice che il software lo ha ricevuto cosi e la tua parola con la sua.
Certo tu dici che tu dai i software offuscati con il controllo della licenza.
Lui può dire che il software che non ha mai modificato il software lo hai spedito cosi.
Esatto è quello che dicevo io, deve avere una prova che dimostri che non sia così. Con altre tipologie di sw è molto più facile dimostrarlo (c'è un supporto fisico o una prova tangibile) ma in questo caso la difficoltà più grossa la vedo li.
Poi boh, tentare non costa nulla (avvocato a parte)... ma rimane sempre li, vincere non è detto e io so di persone che oltre al danno subito hanno anche pagato le spese processuali
tomminno
12-05-2016, 08:18
Io però mi sono perso: la licenza è a tempo? Il cliente sta usando il software oltre il tempo previsto dal contratto?
Se si è facile da dimostrare, specialmente se il software controlla un'apparecchiatura esterna specifica.
Se invece la licenza è perpetua il fatto che il cliente abbia modificato il software, oltre ad essere difficilmente dimostrabile (hai mandato tutto in uno zip firmato digitalmente tramite pec?) non è nemmeno causa di danno economico. Difficile arrivare a qualcosa di concreto.
Sicuramente chiudi ogni supporto al cliente e prima o poi il software smetterà di funzionare per cui sarà obbligato a tornare all'ovile o cambiare fornitore
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.