Meccanismo di applicazione della licenza e/o dell'uso simultaneo per un prodotto UNIX abbastanza aperto?

Question

Sarei grato per qualsiasi suggerimento su come aggiungere l'applicazione della chiave di licenza o l'applicazione dei limiti degli utenti simultanei a un prodotto software (basato su UNIX) che, sebbene non esplicitamente open source, l'utente finale ha nominalmente il codice sorgente per, o potrebbe, plausibilmente, ottenere con relativa facilità perché i server che lo eseguono si trovano nei loro locali, ecc.

Ovviamente non cerco né mi aspetto una tecnica che non possa essere aggirata da qualcuno fortemente motivato a farlo, e/o da 1337 h4x0rs che siano semplicemente buoni così.Lo scopo di tali meccanismi antipirateria non è quello di impedire all'utente di fare qualcosa che vuole veramente fare, ma solo di renderlo abbastanza fastidioso da non valere la pena rispetto alla relativa facilità di pagare semplicemente per un'altra licenza (economica), almeno per un utente finale con capacità semplicemente medie.

Ciò richiede qualcosa di più sofisticato della semplice sicurezza tramite l'oscurità (che ti farà ridere anche dagli utenti che potrebbero incontrarlo, anche inavvertitamente senza l'intento di modificare l'impostazione), ma niente di simile a ciò che è necessario per proteggere un silo missilistico.Basta qualcosa da dire: "Sì, questo prodotto limita davvero l'uso a ciò che hai acquistato". Non dovrebbe essere nulla di abbastanza interessante da motivare qualcuno in cerca di fama e fortuna per pubblicare un post sul blog su come romperlo, idealmente, anche se dato quanto sia assolutamente nicchia il prodotto e quanto sia economico, non lo vedo come essere una preoccupazione.

L'unica vera tecnica a cui riesco a pensare è compilare alcune routine che sono funzionalmente essenziali per il resto del programma in un oggetto ricaricabile binario statico o dinamico e, insieme ad esso, includere i controlli.È necessario che la routine sia critica per qualche aspetto inscindibile, piuttosto che un controllo artificiale solo per quella particolare condizione, altrimenti l'utente potrebbe semplicemente andare a disabilitare la chiamata alla funzione.L'idea è che disabilitare la chiamata alla funzione abbia anche altre conseguenze poco attraenti.

Non c'è niente che un hacker intelligente non possa smontare e, ovviamente, se la funzione è abbastanza banale da essere incorporata in un binario altrimenti senza scopo, è abbastanza banale da essere reimplementata anche al di fuori di esso.Ma è uno sforzo maggiore di quello che un tipico utente finale si prenderebbe la briga di sostenere.E ovviamente, ancora una volta, il punto non è fermare meccanicamente la pirateria, ma solo porre un piccolo limite in modo che il prodotto non funzioni puramente sul sistema d'onore, anche se sono sicuro che sia sufficiente per molti acquirenti aziendali negli Stati Uniti.

Si tratta di un approccio comune?Ce ne sono di migliori?

Answer 1

Tutto ciò non farà altro che far incazzare i tuoi utenti onesti, mentre qualsiasi pirata degno di questo nome riuscirà a risolverlo in cinque minuti: non farlo.