Devo includere un metodo di autodistruzione alle mie applicazioni?

Non sono un avvocato. Sembra che tu ne abbia già uno allo scopo di denunciare il tuo cliente; mentre tu hai lui o lei in custodia mi raccomando di ottenere il loro consiglio su questo.

Ci sono altre domande su questo sito che trattano di "kill switch" e altri modi per disabilitare il software per il quale lo sviluppatore non ha ricevuto un compenso. Di solito è considerata una cattiva idea semplicemente crearne uno nel software "chiavi in mano" (dove lo svilupperai e poi trasferirai tutti i diritti al cliente), senza che il contratto abbia stipulato questa possibilità.

Prima di tutto, se il tuo contratto non specifica specificamente che puoi disabilitare il software per il mancato pagamento, o che il cliente non ha alcun diritto sul software fino a quando il pagamento non viene ricevuto per intero, allora non puoi capovolgere alcun "kill" passare "senza essere in violazione del contratto. In assenza di parole contrarie, "il possesso è nove decimi della legge", quindi è il suo software una volta che gli è stato dato il possesso, e distruggerlo sarebbe come dinamizzare un nuovo edificio per uffici che avresti costruito per lui se non avesse paghiamo per questo.

Segue il secondo punto; qualsiasi contratto che offri a qualsiasi cliente dovrebbe avere una clausola relativa all'effetto di: "Trasferimenti di proprietà intellettuale su soddisfazione del contratto" . Ciò significa che anche se gli hai dato una copia del software da utilizzare, fino a quando non ti ha pagato per intero, non lo possiede. Questo POTRÀ darti il diritto di disabilitare la sua o qualsiasi copia del software per qualsiasi motivo fino a quando non è stato ricevuto il pagamento completo, perché è ancora tuo e puoi farlo come ti pare. Ora, ha violato il contratto, e non l'hai fatto, quindi il caso è MOLTO più facile da presentare per il tuo avvocato, e nel frattempo il tuo cliente non ottiene alcun beneficio dai suoi beni maltrattati.

L'analogia con un imprenditore edile vale: una volta che un edificio in costruzione è in grado di essere protetto contro l'ingresso illegale, lo è, e l'appaltatore in genere manterrà tutte le copie di tutte le chiavi nei locali fino a quando i lavori non saranno completi e firmati on, e il pagamento ricevuto per intero. Anche dopo che le chiavi sono state consegnate, se il pagamento è scaduto, egli può attribuire un privilegio sulla proprietà e, all'estremo, può farlo rientrare. Lo stesso vale qui; puoi dare al cliente una chiave per entrare nel software, ma tu detieni la chiave "master" e non ottiene accesso amministrativo finché non sei pagato per intero. Se ora può entrare e non ti paga, puoi semplicemente "cambiare le serrature" e bloccarlo fuori dal software.

Tuttavia, hai dato al tuo cliente la chiave "master" per il software, e se n'è andato e ha cambiato tutte le serrature, quindi ora non puoi entrare. Non è così che dovrebbe funzionare. Puoi ancora chiedere il risarcimento dei danni, ma nel frattempo il tuo cliente disonesto può usare il software, copiarlo altrove (è una cosa importante che non può accadere a un appaltatore, se si riprende il suo edificio non deve preoccuparsi che tu hai fatto una copia esatta su un altro lotto, ecc. ecc. Fondamentalmente, il tuo unico rimedio è quello di far rispettare il pagamento per intero, perché non puoi garantire di aver reclamato tutte le copie del software. Probabilmente non saresti felice di riavere il tuo software anche se potresti garantire che non aveva altre copie; è probabilmente un lavoro personalizzato che non puoi semplicemente girare e vendere a qualcun altro.

Comprendi che, indipendentemente dai tuoi diritti sul software, i suoi dati appartengono a lui. Non puoi toccarlo. Puoi interrompere il suo accesso al software che hai costruito, ma se distruggi i suoi dati, è come bruciare i suoi beni dopo aver riaperto l'edificio che gli hai costruito che non ha pagato. Non hai alcun diritto su quei dati, e devi lasciarli sul suo computer intatto, o se i dati non possono essere accessibili in modo ragionevole senza il tuo software, devi rimuoverlo dal entanglement con il tuo software e darlo a lui in un formato utilizzabile (come un database di consumo umano, o copie stampate o elettroniche).

Nel concetto hai ragione. La tua esecuzione è completamente sbagliata.

Devi fornire le licenze di prova che scadono. Dopo il pagamento completo, dargli la licenza "per sempre" finale. Tutto in anticipo e onesto.

No. Se i tuoi clienti scoprissero che saresti linciato. Non è affatto sicuro. Qualcuno, qualcuno come scoprirà come attivarlo e poi all'improvviso avrai il compito di contattare tutti i tuoi clienti per dirglielo e perché devono fare una patch di emergenza.

Se lo fai, ti stai anche aprendo a un procedimento penale. Immagino tu abbia la prova che possiedi ancora il sito? Che hai il diritto di accedervi? Il costo per la sua attività potrebbe essere "astronomico"

Ci sono alternative accettabili. Metti una filigrana sul sito, quindi ogni pagina mostra un messaggio. A pagamento è possibile rimuovere la filigrana.

Questa mi sembra una pessima idea che potrebbe atterrarti in prigione.

1. Non è etico. Il cattivo comportamento del tuo cliente non lo rende adatto per hackerare il loro sistema.
2. È illegale. Questo è accaduto prima , con esiti negativi per le parti incriminate.
3. È inutile. Cosa faresti con questa backdoor che non ti metterebbe nei guai? Vuoi ricattare il client?
4. È stupido. Anche se si potesse fare questo senza essere scoperti, i potenziali rischi superano di gran lunga qualsiasi possibile guadagno.

Per favore non chiedere ai programmatori, chiedi a un avvocato. Immagino almeno che tu voglia includere una clausola nel tuo contratto dicendo che hai il diritto di fare ciò che la tua domanda prevede di fare. (La clausola del "danno irreparabile" di alcuni contratti non ti consente di ottenere l'ordine del tribunale di chiudere immediatamente il software fino a quando il tribunale non ha la possibilità di risolverlo?) Penso che un ordine del tribunale sarebbe molto più sicuro per te di un codice bomba (che potrebbe essere considerato criminale, se un tribunale ha scoperto che non possedevi il software potrebbe essere la distruzione di proprietà, negli Stati Uniti potrebbe rientrare nelle sezioni di crittografia digitale del Digital Millennium Act, ecc. immagina di vincere i danni in tribunale civile e di essere ancora condannato in un tribunale penale).

Le regole variano a seconda di dove tu e il tuo cliente vivete e operate, quindi penso davvero che vorreste un avvocato.

Ethically is this a good idea?

Assolutamente no. Non solo ti fa sembrare poco professionale per i clienti onesti e onesti, ma ritengo che sia anche dannoso per la professione nel suo complesso. Gli ingegneri del software hanno una responsabilità nei confronti dei propri clienti o datori di lavoro, compresa la fornitura di software di altissima qualità. In caso di controversia sul pagamento o sui contratti, ci sono canali appropriati. La riduzione della qualità del tuo software non è un canale appropriato.

Have you guys ever had to hack your own software, because of similar issues with the client(s)?

Mai, anche se non ho mai fatto un contratto o un lavoro indipendente. Sono sempre stato un dipendente di un'organizzazione più grande (che, in alcuni casi, stava lavorando con un contratto). Per me, il pensiero è impensabile. Preferirei distribuire software di cui sono orgoglioso di avere il mio nome attribuito e che viene truffato da una piccola percentuale di clienti rispetto alla riduzione della qualità del mio software e delle mie responsabilità etiche per gli utenti del sistema.

Any recommendations on this idea, code and method wise?

Non farlo.

What may be the possible drawbacks or repercussions of selfdestruct-scripts?

Oltre agli ovvi problemi etici, sarei preoccupato per problemi legali. Non sono sicuro che sabotare il tuo lavoro sia legale, e anche se lo fosse, l'utilizzo di un simile exploit potrebbe non esserlo.

Implementa semplicemente un modulo di licenza con licenze a tempo limitato che disabiliterà il software alla scadenza. Questa è una pratica ben nota nell'industria del software e i tuoi clienti non dovrebbero opporvisi, poiché in seguito rimuoverai la limitazione.

Potrebbe anche rivelarsi utile quando desideri limitare le funzionalità e offrire versioni diverse del tuo prodotto.

Gli interruttori di uccisione hanno troppi rischi e non ne valgono la pena.

Una funzione di autodistruzione segreta è un'idea orrenda . Sì, sarai intelligente e potrebbe avere l'opportunità di attaccarlo a un cliente orribile in futuro, ma è molto più difficile del suo valore.

1. Non sarai ancora pagato per il lavoro che hai svolto. Sì, l'altra persona non utilizzerà il tuo codice; ma continuerai a soffrire di mancanza di pagamento. Pensi che alcuni criminali decideranno di pagare la persona che ha già fatto scendere il loro sito una volta lontanamente? Troveranno qualche nuovo chump per rendere il loro sito gratuitamente.

2. Utilizzando la sequenza di autodistruzione, sei responsabile dei tuoi problemi legali. A seconda delle giurisdizioni, potreste facilmente essere visti come hackerare / distruggere i loro dati (quando stavano per pagare e avevano un sacco di circostanze attenuanti per il motivo per cui non avevano pagato prima). Anche se non sei condannato / con successo, potresti comunque aumentare le spese legali e avere molti più problemi del suo valore.

3. Cosa succede se qualche buon cliente pagante naviga il tuo codice più tardi (o ha un amico CS che lo ha appena sfogliato per fare un piccolo aggiustamento), vede la funzione con strana parte base64, è come quello che è, prova a eseguirlo, e cancella accidentalmente l'app web (e lo fa mentre sei in vacanza, quindi ci vuole un po 'per risolvere)? O pubblica un sacco di recensioni pubbliche su di te ovunque affermando che non sei etico e lasci backdoors nel tuo lavoro? Certo, puoi rimuoverlo dal prodotto finito dopo che hanno pagato, ma con VCS possono sfogliare la fonte più vecchia o non volerti sul loro server dopo aver pagato (e sarebbe una conversazione imbarazzante, sì ho bisogno di un account di nuovo, perché non ho 't rimosso la backdoor segreta di autodistruzione).

4. Cosa succede se il criminale esegue il backup dei propri dati? Se cancelli il loro server web con una backdoor segreta, il sito è offline per un giorno o due mentre loro (o un amico) trovano la funzione backdoor della funzione incriminata e la sua back online.

In futuro, fai in modo che le persone firmino un semplice contratto, ti paghino per fasi e non lasci che il codice lasci il server di sviluppo e il computer che solo tu controlli finché non sei stato pagato. (Se ne hanno bisogno per essere live prima che tutto il lavoro sia finito, assicurati che abbiano pagato approssimativamente la frazione di codice che sta diventando live). Se vogliono vedere il lavoro come in fase di sviluppo, fagli avere alcuni indirizzi IP che aprirai il tuo firewall per il tuo server di sviluppo (e magari con un CNAME intelligente per l'effetto di unpaid_work_in_development.example.com ). Non dare garanzie di operatività del tuo server di sviluppo e se stai ottenendo più traffico di quanto dovresti essere (ad esempio, scopri che stanno reindirizzando molte persone sul tuo sito), chiudi il firewall finché non paga. Se hanno bisogno di contribuire al contenuto del tuo server web, fai in modo che ti inviino via email con i suggerimenti del contenuto o crei una cartella condivisa dropbox per loro che abbia solo le autorizzazioni per scrivere sul piccolo sottoinsieme di file (sotto il controllo VCS al di fuori di dropbox) può contribuire in modo significativo a (ad esempio, modelli html).

Hai fatto la domanda sbagliata. La cosa su cui lavorare e migliorare non è aggiungere una sorta di kill switch remoto (aggiungendo una vulnerabilità che o qualcun altro può usare), ma per risolvere il tuo vero problema, che era un modo scadente di organizzare il pagamento e la consegna. Sembra che tu avessi bisogno di un sistema di escrow migliore (o qualunque sia il concetto che si chiama dove vivi).

Non sprecare il tuo tempo con un kill-switch, scopri dove hai rovinato l'affare in parte.

Penso che vorrei ideare un qualche tipo di meccanismo di licenza. Questo potrebbe essere basato su un numero qualsiasi di idee commerciali o prodotte a casa e potrebbe causare l'interruzione del funzionamento del software dopo la scadenza della licenza. Nel momento in cui il sistema viene accettato dal cliente e pagato, è possibile fornire una licenza completa che non scade.

Questo approccio richiede anche l'approvazione di un avvocato nel tuo territorio, ma ha il vantaggio che non è necessario disattivare a distanza il software e puoi stabilire che questo è parte del sistema in anticipo. Tuttavia mi sembra molto triste che tu abbia a che fare con persone che si rifiutano di pagare in primo luogo.

Non si chiama DRM? Finché rimuovi la "bomba" dopo aver ricevuto il pagamento, non vedo alcun problema legale con esso. Assicurati di avere una patch prontamente disponibile per coprire il tuo culo e mostra che non hai intenzioni malevole.

Mi ricorda la disposizione della "pillola velenosa" contenuta nell'atto costitutivo di alcune società che viene attivata in caso di un'acquisizione ostile.

Ad esempio, la mentalità espressa da alcuni degli altri poster qui mi ricorda il motivo per cui alcuni programmatori vengono calpestati continuamente. Se più persone inseriscono tali bombe nel loro codice, penso che i programmatori potrebbero essere pagati più prontamente ... Non avrei alcun problema se questa fosse la norma. La gente ama rubare il duro lavoro degli altri. Periodo. E se Apple, et al. puoi DRM fuori dai loro affari, quindi penso che anche i programmatori freelance possano ...

Da un punto di vista pratico, sicuramente il cliente controllerebbe i propri registri, troverebbe la richiesta di eliminazione, ripristinerà il codice da un backup, rimuoverà il kill switch e ridistribuirà.

I dettagli della tua domanda chiariscono che questa sarebbe un'idea assolutamente orribile. Il primo client a rilevare tale kill switch (probabilmente dopo averlo utilizzato e recuperato da un backup) pubblicherebbe il kill switch e il fatto che lo avessi incluso nel codice che gli hai consegnato. La tua reputazione verrebbe quindi completamente distrutta.

E prima che tu dica "beh, sarebbero un deadbeat, come distruggeranno la mia reputazione?" Considera uno scenario come questo: il cliente ha una buona reputazione, ma uno dei dipendenti prende una copia del codice. Sparano a quell'impiegato, guarda il codice, capisce l'interruttore di uccisione e lo usa. Indovina chi riceve la colpa? (Suggerimento: sei tu.)