Come pacchettizzare una soluzione per rivenderla con licenza

[Giovannino]

Salve a tutti,

tempo fa ho sviluppato un progetto simile ad un Crm come concetto ma comunque molto diverso nel contenuto.
Potrebbe esserci la possibilità di un acquirente interessato ad una implementazione della soluzione nella sua realtà.
Qualcuno gentilmente mi può spiegare come si agisce in questi casi per trasformare una soluzione standard aperta e senza limiti in qualcosa che si vende per utente o per blocchi di utente (1-5; 6-10 etc) ? E' la prima volta e spero la domanda non sia così stupida.
Bisogna sviluppare qualcosa di specifico o SC ha qualche trucco da sfruttare ? Si deve aquistare un pacchetto PHP a parte che gestisce licenze etc.
Spero di esser stato chiaro...
Grazie

[Vincenzo]

Ciao, non credo SC abbia qualcosa di pronto, se non il codice che usa lei stessa per limitare utenti contemporanei o connessioni a DB non inclusi nella licenza.

Come prima cosa è da vedere se fai tu l'hosting o se devi installare dal cliente o da terzi, nel secondo caso devi offuscare il codice altrimenti, volendo, qualsiasi "blocco" può essere più o meno facilmente rimosso.

Deciso poi dove e cosa vuoi bloccare, devi implementare il codice che faccia i controlli, se c'è un limite in una anagrafica per esempio, non basterà "nascondere" il tasto NUOVO, dovrai anche controllare, al login o altrove che il numero dei record sia conforme alla licenza, per evitare che qualcuno inserisca l'anagrafica direttamente nel database.

Poi va "memorizzato" in qualche modo la licenza acquistata e quindi capire cosa il programma può o non può fare, di solito si usano le CHIAVI, studi un algoritmo che codifica una stringa, che contiene cosa può fare o meno il programma, date di scadenza etc, e nel codice avrai la decodifica, questa a maggior ragione offuscata, che data la chiave ottiene la stringa con i "permessi".

Un'altra cosa che penso abbia aggiunto anche SC al suo ambiente, è il calcolo del checksum per i file installati, ogni tanto controlla il checksum, se un file ha il checksum cambiato vuol dire che è stato modificato, ovvio che il checksum va blindato altrimenti uno toglie quello e poi modifica tutti i file che vuole.

Poi vedi tu, di fatto quasi nulla è impenetrabile, sta a te decidere quanto investire rispetto all'eventuale danno se ti crackano il codice.

[Giovannino]

Grazie Vincenzo della spiegazione,

ovviamente non sono in grado di fare una cosa così complessa ma pensavo allora di introdurre un programma di login esterno a SC.
Googlando con 'license manager' ho visto qualcosa come IonCube, Zendguard , FlexPM etc. che lo fanno di mestiere. Non ho la competenza per
capire se potrebbero andare bene o meno.
Da quanto tu dici comunque bypassato il primo controllo di questi programmi poi il codice SC rimane comunque facilmente attaccabile.
Per il prospect (che spero di avere) it tutto dovrebbe essere attivato solo per un controllo di utenti nominali che usano.
Non essendo una soluzione a larga diffusione magari mi potrei accontentare di qualcosa di semplice.

[Vincenzo]

IonCube etc, fanno proprio l'offuscamento così , com per SC, lo puoi usare ma non li puoi modificare. Poi il sistema fornisce altre protezioni, come ad esempio codificare il codice così che possa funzionare SOLO fino ad una certa data, oppure che funzioni SOLO su un determinato IP server (così non può essere spostato o copiato), se queste protezioni ti bastano sei a posto, altrimenti devi implementare tu altro, potrebbe anche essere pià che sufficiente come protezione.

[Fabio]

Ciao,
Scriptcase offre una macro per cambiare connessione, quindi database.
Questa macro è utilissima anche per distribuire software a più clienti. Devi creare per ognuno un suo database e, tramite un'adeguata login, far lavorare ognuno sul proprio database.
Per le limitazioni sugli utenti puoi agire internamente a ciascun database, impostando dei limiti "per contratto".

[Giovannino]

Ciao,
ho ripreso in mano le cose che avevo abbozzato. La strada più semplice per me è quella di fare un check al login sull'esistenza di una activation_code.
Per inserire i codice licenza fuori dal db del progetto ho creato un Db esterno con una tabella in cui associo utenti con la loro licenza.
Qui ho creato un form di inserimento semplice.
Il form contiene user, nome .... etc e il famoso campo {activation_code}.
Ho trovato una routine su google che crea codici casuali e l'ho inserita in un metodo "generate_key".
La funzione si chiama generate_license(); e l'output è una stringa tipo ad es. LMCQ5-92LQY-9Z2B9-6W8BK
Sul form ho creato un bottone PHP che fa questo;

$key_license = generate_license();

//Echo $key_license;

if(empty({activation_code}))
{
{activation_code} = $key_license;
}
else
{
Echo " Attenzione codice già presente ";
}

Il problema che premendo il bottone non succede nulla....
1) E' perchè il codice bottone è PHP ?
2) Ho provato inserire Ajax evento on click sullo stesso campo {activation_code} e funziona
3) Ho provato fare un campo addizionale tipo testo con codice html di un bottone nell'help.
In questo caso sempre usando Ajax on click event e inserendo lo stesso PHP di 2) non funziona

Cosa sbaglio ?? Grazie

[rino]

Argomento complesso regolamentato dalla legge sul diritto d'autore , dal codice Civile , dal GDPR oltre che dalel norme sui reati informatici .

Innanzi tutto va realizzata la licenza d'uso , questa deve indicare tutte le clausole , i vincoli sul SW , senza una licenza d'uso i problemi aumentnao e di molto .
Il software è proteggible , la banca dati no, ovvero questa è proteggibile solo in alcuni limitati e specifci casi, da altronde ha n senso , i dati contenuti sono del cliente non certo del fornitore del sw. per questo ogni limite sulla banca dati è illegittimo salvo che il sw non sia in versione demo. I tracciati record sono disponibili come le regole sui dati , il GDPR è chiaro . Ci sono diverse norme che impongono la conoscenza del tracciati , il non renderli disponibili pone il prduttore SW in seri rischi.

Il SW è proteggibile senza limiti .
Nel caso SC ,che produce script eseguibili in PHP la forma fisica di protezioen è l oscuramento del codice , in toto o in parte .
Questo avviene tramite diversi prodotti alcuni in licenza d'uso altri in licenza GPL , uso libero.
Quelli in licenza offroon anche alte forme di controllo oltre l oscuramento, per esempio le date di validità, il legame con un ambiente , un sistema centralizzato di controllo, ecc.
La scelta è ampia come i costi .
Di solito i sistemi di oscuramento dle codice non creano problemi di esecuzione ma può accadere che alcune configurazioni dei server possano andare in conflitto .

[Giovannino]

Beh... molte grazie inanzitutto per la completa risposta.
Penso interessi anche altri nel gruppo oltre a me.
Vedrò intanto cosa il prospect farà e semmai mi attiverò a riguardo.
Saluti