Newsgroup: it.comp.lang.c++
Titolo: RM Come si fa a mettere una BOMBA informatica ?

Scusate non sono un dinamitardo, ma un semplice libero professionista che
molto spesso visto che non c'è più onestà da parte di molti clienti, sono
costretto a chiedere informazioni di questo tipo.
Mi spiego.
Spesso eseguo programmi per clienti vari, e alla fine benchè i miei
programmi lavorino perfettamente il cliente ha sempre qualcosa da ridire pur
di non pagare del tutto il compenso stabilito.
O meglio mi ricatta dicendo che se non gli faccio un upgrade o addirittura
un altro programma non mi salda ciò che lui stesso aveva firmato.
Capite bene che non sono in grado di fargli causa perchè attenderei anni,
per cui volevo sapere se qualcuno di voi conosce la maniera più idonea
possibile di inserire una "bomba" (magari all'interno di una DLL) che ad un
certo giorno esploda bloccando il programma (senza creare danni ai dati, ma
che costringa il cliente moroso a dovermi richiamare).
Chiaramente chiedo qualcosa che non sia identificabile da chiunque cerchi di
capire cosa è successo.
Magari qualcosa che ad un certo giorno, cancelli una LIB o altro.
Potrei lavorare in C C++ VB o altro.
Non sono un terrorista ma un semplice "NON" pagato.
Grazie
Rispondere a 
vman...@ainet.it
-- 
Posted from 
vmail.mclink.it
 [195.110.128.11] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Hai provato a mettere una bomba VERA nell'ufficio del cliente *moroso* e
*ricattatore*???
;-)
Io credo che la questione sia più semplice, anche per te.
Quando scrivi il software fai in modo che dopo tot tempo (es. un mese o due
mesi)
e magari per un tot di volte (1 o 2, ma qui si esagera col "rompimento di
balls") il
tuo programma richieda al cliente un codice di attivazione che gli consenta
di andare
avanti. Naturalmente tu sarai tanto furbo da fornirgli il codice di
attivazione SOLO
a pagamento totale avvenuto, e soprattutto se non salda totalmente il debito
non gli
farai cenno del fatto che dovrà inserire in futuro questo codice.
Per i problemi legali immagino che richiamare nella finestrella di richiesta
codice
qualcosa legato al saldo completo del pagamento dovrebbe bastare. In fondo
mica
ti fai firmare la ricevuta per il saldo completo se questo non è stato
effettuato, vero ;-)?
--
----------
Lello Mele
c/o VTM VideoTecnica Mele
Via San Sebastiano, 22
84036 Sala Consilina (SA)
Cell.:0347/643.35.25
HOMEPAGE:
http://www.lellomele.supereva.it
eMAIL:
v...@libero.it
me...@programmazione.it
-------------
"Esistono due modi per elaborare il progetto di un software.
 Il primo consiste nel renderlo semplice al punto tale che non
 manifesti lacune evidenti. Il secondo consiste nel renderlo
 complicato al punto tale che non manifesti lacune evidenti.
 Il primo metodo e' di gran lunga piu' difficile." [C.A.R. Hoare]

 ha scritto nel messaggio
news:lVKt6.65955$6W.63...@news.infostrada.it...


Nessuna delle risposte date e' secondo me applicabile nel contesto.
Per prima cosa non credo che abbia senso rispondere alla domanda "come metto la
bomba" dicendo "metti una bomba".
Il secondo aspetto, che e' quello per cui posto, e' di tipo legale.
Partiamo dal discernere il tipo di contratto. Se il contratto e' di prestazione
d'opera, allora l'azienda ha diritto automaticamente ad avere i sorgenti.
Se e' un appalto (quindi con una societa' e non con un professionista) i
sorgenti possono rimanere (se esplicitato nel contratto) di proprieta'
dell'azienda.
Se e' un contratto di vendita del prodotto, allora l'acquirente non paga uno
sviluppo ma paga un prodotto, ed il prezzo e' ovviamente molto diverso.
Nel caso di un prodotto, la soluzione piu' semplice e' non consegnarlo fino al
pagamento. A meno che non lo vuoi commercializzare come freeware (non ti fai
pagare) o come shareware (ti fai pagare da chi e' tanto gentile da farlo). Nota:
lo so che lo shareware non e' questo, ma lo e' in pratica comune italiana!
Fatto salvo quel caso, la consegna del prodotto (che potrebbe comprendere i
sorgenti nel caso di prestazione d'opera) avviene normalmente in concomitanza
del saldo.
Per le prestazioni d'opera tu consegni i prodotti intermedi (ovvero i sorgenti)
ogni tot giorni (di solito un mese) e vieni contestualmente pagato. Il tuo
rischio e' di una mensilità. Se smettono di pagarti a meta' lavoro semplicemente
tu smetti di sviluppare e, a seconda del contratto, potrebbe essere salvo non
solo il tuo diritto a non continuare il lavoro e a essere comunque pagato per la
parte fatta, ma anche un diritto ad un risarcimento parziale per il mancato
guadagno relativo al lavoro residuo.
Per gli appalti fra societa', indipendentemente dal fatto che i sorgenti siano
previsti o meno in consegna, i pagamenti sono normalmente "a tranche". E queste
corrispondono normalmente a delle milestone intermedie per funzionalità. Anche
in questo caso il rischio dovrebbe essere ridotto al valore di una tranche e
all'eventuale mancato guadagno per le successive.
Detto questo passiamo all'ipotesi che tu voglia proteggere proprio quella trance
finale o quella mensilità finale che sono a rischio. La maniera corretta e' di
prevedere "la bomba" nel contratto stesso. Ovvero una funzionalita'
esplicitamente "problematica" del SW che non verrà da te risolta fino
all'avvenuto pagamento. Ogni altra funzionalità dovrà essere implementata come
da contratto prima che tu maturi il diritto al pagamento della tranche.
Se la "bomba" non e' prevista nel contratto e tu ce la metti lo stesso e loro
possono dimostrare che lo hai fatto apposta (non e' difficile) nota che potresti
perdere il diritto ad essere pagato o persino dover pagare tu i danni a loro
(dipende dai casi).
Ultima nota: siamo OT.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
=8-o , appunto...rilassati ogni tanto!
LM