Occorre sostituire un flusso contrattuale, ma la nuova soluzione non può inviare contratti a un SaaS di firma. DocuSeal, Documenso e OpenSign meritano un posto nella selezione di alternative a DocuSign. Tutti hanno un nucleo ospitabile autonomamente; il confronto utile riguarda l’edizione che puoi gestire, le prove che puoi esportare e i servizi che il deployment continua a chiamare. Il permesso di noleggiare un server e quello di inviare documenti a un responsabile del trattamento sono decisioni distinte.
Mantenere un flusso DocuSign già approvato può restare ragionevole finché le prove o la gestione della soluzione sostitutiva sono incomplete, purché quel flusso soddisfi i requisiti dell’organizzazione. Se una policy vieta il suo modello di trattamento, la familiarità non elimina il vincolo. Definisci i criteri di accettazione della nuova soluzione prima di trasferire contratti reali.
In breve
- DocuSeal: L’edizione self-hosted gratuita supporta più firmatari e il tuo server SMTP. Pro aggiunge funzioni come promemoria automatici, SSO SAML, ruoli e team, e capacità avanzate di API e integrazione incorporata. Consulta il confronto delle edizioni on-premises.
- Documenso: Community Edition include firma di base, modelli e accesso API. Le funzioni commerciali comprendono il portale di autenticazione dell’organizzazione, la riautenticazione per le azioni sui documenti e la creazione incorporata. Consulta il confronto delle edizioni.
- OpenSign: Il repository documenta modelli riutilizzabili, sequenze di firma, codici e-mail per ospiti e certificati di completamento. La documentazione dei token API distingue token di produzione a pagamento e token sandbox gratuiti. Conferma i diritti di accesso all’API self-hosted per la build scelta; questa pagina non li stabilisce chiaramente.
Confronta le edizioni gratuite e i loro requisiti operativi
La tabella seguente confronta l’ambito del codice gratuito, i requisiti di deployment e le funzioni commerciali di ogni strumento.
| Strumento | Ambito del codice gratuito | Componenti del deployment | Vincoli commerciali o da chiarire |
|---|---|---|---|
| DocuSeal | La licenza del repository è AGPLv3. La pagina dei prezzi di DocuSeal distingue Open Source on-premises gratuito da Pro on-premises commerciale. | Docker/Compose; SQLite per impostazione predefinita, oppure PostgreSQL/MySQL, come descritto nelle opzioni di installazione. Pianifica la persistenza di file e database e l’invio delle e-mail. | La guida alla configurazione di Pro colloca branding, promemoria, SSO, ruoli/team, webhook e API/integrazione incorporata nell’offerta commerciale. Conferma i diritti esatti di integrazione e i costi di utilizzo; le indicazioni generali sulle integrazioni nel repository non li chiariscono. |
| Documenso | Il suo confronto delle edizioni distingue Community Edition gratuita, una licenza annuale Business Edition ed Enterprise Edition personalizzata. Il repository contiene anche codice commerciale con licenza separata. | Il documento dei requisiti specifica PostgreSQL, trasporto e-mail, un reverse proxy e un certificato di firma, con archiviazione compatibile S3 opzionale. Includi documenti e registrazioni di audit del database nel progetto di persistenza. | L’elenco delle funzioni commerciali include autenticazione dell’organizzazione e riautenticazione per le azioni sui documenti. La documentazione delle edizioni include anche creazione incorporata, anche white-label, e firma remota CSC. Chiarisci esportazioni richieste, configurazione delle marche temporali e ambito gratuito dell’API per l’edizione scelta. |
| OpenSign | La pagina sul self-hosting descrive un nucleo self-hosted gratuito. La licenza AGPLv3 alla radice prevede eccezioni per directory e componenti di terze parti. | La guida Docker configura MongoDB, archiviazione file locale o esterna, SMTP/Mailgun e un certificato di firma. Esamina persistenza ed esposizione del database del deployment scelto. | La guida ai token API distingue token di produzione a pagamento e token sandbox gratuiti, mentre la pagina sul self-hosting pubblicizza un’API REST. Conferma i diritti dell’edizione self-hosted scelta prima di farvi affidamento. La guida ai modelli di OpenSign documenta l’impostazione «Merge Certificate to PDF»: attivandola, il certificato di completamento viene incluso nel PDF finale; disattivandola, viene fornito un PDF del certificato separato. Verifica le impostazioni di esportazione disponibili nella build installata. |
Un’applicazione di firma elettronica open source può avere un nucleo gratuito utilizzabile accanto a pacchetti commerciali. Considera ogni flusso proposto come una verifica dei diritti: identifica l’azione, l’edizione che la consente e il servizio che richiama. Un repository pubblico non basta a dimostrare che una funzione necessaria sia gratuita.
Conserva una breve scheda di selezione: pacchetto scelto, flusso richiesto, vincolo irrisolto e persona incaricata di ottenere una risposta. Non compilare un campo senza risposta con «sì» perché esiste una funzione cloud dal nome simile. Un requisito irrisolto deve ritardare l’adozione di quel flusso, anche se il resto dell’applicazione sembra adatto.
Scegli un candidato adatto al tuo flusso di firma
Partirei da DocuSeal per un flusso di modelli PDF gestito manualmente, Documenso Community quando l’accesso gratuito all’API è indispensabile e OpenSign quando modelli e codici e-mail per ospiti si adattano al processo. Sono punti di partenza per un progetto pilota basati sulla documentazione ufficiale; non ho svolto test di installazione o firma.
DocuSeal per un flusso basato su PDF e modelli
DocuSeal è un primo pilota sensato per preparare PDF e riutilizzare modelli di firma quando il nucleo gratuito copre il flusso. Le FAQ sul certificato di audit descrivono una registrazione di completamento scaricabile con eventi per ogni parte e campi di verifica condizionali. Valuta il metodo registrato rispetto ai tuoi requisiti prima di considerare il certificato una prova di un particolare livello di identità.
Il certificato registra indirizzi e-mail delle parti, orari degli eventi, indirizzo IP, ID di sessione, informazioni sul browser e fuso orario. La verifica via e-mail o telefono dipende dal metodo usato; la presenza di un campo non prova che sia stato eseguito un metodo più forte. Richiedi un esempio generato dalla configurazione prevista, inclusa una richiesta rifiutata o delegata se quei percorsi sono pertinenti.
Interrompi la selezione se l’autenticazione o l’integrazione necessaria dipende da un’offerta commerciale non ancora approvata. L’editor può soddisfare il requisito visibile mentre un’azione essenziale a valle resta irrisolta.
Documenso per un modello operativo PostgreSQL esistente
Vale la pena provare Documenso quando puoi gestire insieme le sue dipendenze di database, posta e certificati. I requisiti di self-hosting indicano una trappola precisa: l’applicazione può avviarsi senza certificato di firma mentre la firma dei documenti fallisce. Un’interfaccia che risponde non può quindi essere il test di accettazione del deployment.
I requisiti descrivono firma digitale X.509 mediante un certificato .p12 fornito o generato e registri di audit conservati nel database. Ciò descrive l’infrastruttura di firma; non stabilisce quale credenziale personale abbia usato un destinatario né cosa contenga un’esportazione specifica.
Il ciclo di vita dei documenti di Documenso descrive un PDF firmato e completato con un registro di audit allegato. Il changelog v2.14.0 documenta anche download separati, tramite API, di certificato e registro di audit in PDF. Durante il pilota, esporta questi elementi dalla build installata, esaminane il contenuto e convalida il PDF firmato in modo indipendente.
OpenSign per requisiti di modelli e ordine di firma
OpenSign è un candidato quando modelli riutilizzabili e partecipazione ordinata sono requisiti centrali. Il README del progetto documenta più firmatari, sequenze di firma e codici e-mail per ospiti. Prova questi percorsi con il backend completo e la configurazione di archiviazione scelta; un codice e-mail registra l’accesso a una casella di posta, non un’identità personale o un’autorità organizzativa verificate indipendentemente.
Le istruzioni di installazione per lo sviluppo indicano che il percorso con solo frontend usa il backend di staging del progetto, inclusi i caricamenti dei documenti. Escludi quel percorso da un deployment di contratti privati. Eseguire un frontend sul tuo computer non stabilisce dove il backend elabori i documenti.
Esamina le prove di una firma completata
Un PDF completato e un rapporto degli eventi rispondono a domande diverse. Raccogli prove delle azioni di firma, dell’integrità del documento, dell’identità e autorità del firmatario e del momento. Le FAQ eSignature della Commissione europea e la legge ESIGN distinguono il riconoscimento della firma elettronica da requisiti più ampi. Nessuna esportazione o campo tecnico determina da solo l’esito giuridico di un contratto specifico.
Per le transazioni statunitensi nel commercio interstatale o estero, o che vi incidono, ESIGN §7001 limita il diniego di effetti fondato soltanto sul formato elettronico di una firma o registrazione. Questa legge sulle firme elettroniche preserva gli altri obblighi e non impone a tutti di accettare registrazioni elettroniche. In determinate circostanze si applicano condizioni informative per i consumatori. Le eccezioni della sezione 7003 comprendono documenti testamentari e di diritto di famiglia, specifiche materie del codice commerciale, documenti giudiziari e alcuni avvisi; tali esclusioni non vietano di per sé l’uso elettronico.
Le FAQ eSignature della Commissione distinguono la firma elettronica dalla sua implementazione digitale e crittografica. In base a eIDAS dell’UE, il solo formato elettronico o non qualificato non giustifica il diniego di effetti giuridici a una firma. Le firme qualificate hanno effetti equivalenti a quelle autografe. Le firme avanzate richiedono collegamento all’identità, controllo del firmatario e rilevamento delle modifiche; quelle qualificate aggiungono un certificato qualificato e un dispositivo qualificato per la creazione della firma. Queste regole non risolvono formazione del contratto, autorità, formalità documentali o controversie individuali e non classificano uno strumento specifico.
Esegui quattro controlli quando esamini un pacchetto di prove di esempio:
- Eventi e controllo. Una traccia di audit della firma elettronica dovrebbe permettere di verificare chi ha agito, cosa ha visto o accettato, quale verifica è stata eseguita e quando si è concluso il flusso. Registra le prove di consenso pertinenti al processo. Identifica chi può modificare o eliminare eventi, se le modifiche sono registrate e cosa protegge la copia conservata indipendentemente dall’amministratore dell’applicazione. Un registro eventi da solo non dimostra resistenza alle alterazioni.
- Integrità del documento. Conserva il PDF completato originale e convalida le eventuali firme digitali presenti, le relative catene di certificati e i byte coperti. La definizione di funzione hash del NIST descrive una rappresentazione condensata dell’input. Un controllo hash che riveli alterazioni richiede un riferimento autenticato: un digest di cui puoi stabilire origine e protezione. Sostituire sia un PDF sia l’hash accanto a esso vanifica un semplice confronto. Un hash da solo non stabilisce l’identità del firmatario. Chiedi se è protetto anche il registro di audit separato.
- Identità e autorità. Registra il metodo di verifica e come si collega alla persona indicata. L’accesso alla casella di posta o un codice monouso non stabiliscono da soli l’identità o l’autorizzazione a vincolare un’azienda. La definizione di firma digitale del NIST collega autenticazione dell’origine e integrità a un’implementazione corretta. Il certificato di firma di un server non deve diventare implicitamente un’affermazione secondo cui ogni destinatario possedeva una credenziale individuale.
- Tempo ed emittente. Distingui la data di un evento dell’applicazione da un token di marca temporale emesso indipendentemente. RFC 3161 definisce un protocollo di marcatura temporale con un’impronta del messaggio, ossia un digest dei dati marcati. Verifica il token rispetto al documento conservato ed esamina l’emittente. Lo status di marca temporale qualificata è un’ulteriore distinzione: la Commissione descrive presunzioni di accuratezza di data e ora e integrità dei dati collegati, con i servizi qualificati nelle liste di fiducia. Il solo supporto RFC non stabilisce quello status né garantisce un esito per il documento.
Mappa dove vanno documenti, metadati e digest
Un’applicazione self-hosted di firma elettronica può comunque inviare PDF completati tramite un relay esterno, come mostrano le impostazioni e-mail di completamento di DocuSeal. Il self-hosting identifica chi gestisce l’applicazione; ogni servizio configurato richiede una propria revisione. Distingui contenuto contrattuale, metadati personali e digest, poi registra endpoint e trattamento consentito per ogni percorso prima di introdurre documenti reali nel sistema.
Se il vincolo vieta un SaaS di firma ma ammette infrastruttura noleggiata approvata, restano possibili l’hardware aziendale e un VPS o cloud privato approvato. Un VPS noleggiato è infrastruttura di terzi. Un divieto letterale di tutta l’infrastruttura di terzi non si soddisfa acquistandone una; usa infrastruttura controllata dall’azienda e valuta ogni servizio di supporto rispetto a quel limite.
Il nostro VPS DocuSeal con installazione in un clic include DocuSeal preinstallato: puoi saltare l’installazione manuale dell’applicazione e concentrarti sulla configurazione del flusso di firma. Scegli tra le nostre sedi VPS globali in base alle esigenze di collocazione dei dati del deployment.
Un servizio fiduciario espressamente approvato può restare utile quando è vietato il trattamento documentale SaaS. Valuta dati trasmessi e finalità rispetto alla policy anziché presumere che un’applicazione amministrata da te fornisca automaticamente prove più forti.
| Percorso dei dati | Dati o capacità documentati | Domande da risolvere nella configurazione |
|---|---|---|
| E-mail e casella del destinatario | Le impostazioni e-mail di completamento di DocuSeal possono allegare PDF firmati e PDF di audit. La documentazione dei modelli e-mail di OpenSign descrive dettagli delle richieste, link di firma e allegati del documento completato e del certificato. Questi percorsi possono trasportare contenuti e metadati personali. | Quali relay e caselle li ricevono? Esamina oggetto, corpo, link e allegati. Disattivare gli allegati non elimina i metadati di destinatario, titolo o link. Conferma separatamente i dati effettivi contenuti nelle e-mail di Documenso. |
| File principali e backup | I documenti di deployment descrivono archiviazione in database e file e archivi esterni opzionali. Le copie possono includere documenti completi e metadati personali di audit. | Dove sono conservati file, repliche e backup? Chi può leggerli, per quanto tempo restano conservati e dove li collocherà un ripristino? |
| Identità, SMS e SSO | Le opzioni di autenticazione documentate variano per prodotto ed edizione; OpenSign documenta codici e-mail per ospiti. | Quale metodo è attivo? Un servizio approvato riceve identificatori, numeri telefonici o materiale d’identità? Non presumere che il caricamento di documenti d’identità sia predefinito. |
| Servizio di marcatura temporale | La configurazione del server temporale di DocuSeal accetta un endpoint RFC 3161 proprio o esterno. Il protocollo usa un digest; ciò non stabilisce tutte le richieste effettuate dall’applicazione. | Quale edizione lo abilita, quale emittente risponde ed è richiesto lo status qualificato? Esamina richieste effettive e metadati di rete. |
| Certificati, firma remota e licenze | La configurazione dei certificati, l’opzione commerciale di firma remota di Documenso e la registrazione di DocuSeal Pro pongono domande di configurazione separate. | Il percorso scelto trasmette un PDF, un digest, identificatori o dati d’uso? Ottieni dettagli sui dati trasmessi per licenze e misurazione dell’uso; non presumere un trattamento limitato ai digest. |
| Integrazioni e automazione opzionale | Webhook e integrazioni sono percorsi configurabili, non la prova di un inventario completo delle comunicazioni in uscita. | Inventaria endpoint, corpi degli eventi e registri dei servizi, incluse funzioni di IA o analisi attive. Cerca URL di documenti, contenuti e metadati personali. |
| Hosting e assistenza | Un server noleggiato aggiunge un rapporto infrastrutturale oltre all’applicazione di firma. | Approva separatamente collocazione fisica, backup, accesso amministrativo e accesso dell’assistenza. |
Applica lo stesso inventario delle chiamate esterne usato per altre applicazioni aziendali: segui ogni connessione oltre l’interfaccia. Esamina endpoint configurati e dati trasmessi con file sintetici. Un accesso locale riuscito non prova nulla sui percorsi in uscita non esaminati.
Prevedi il budget per l’edizione e il lavoro che resta a tuo carico
Un deployment senza costi di licenza richiede comunque archiviazione, invio e-mail e un responsabile del recupero. La guida Pro di DocuSeal e il confronto delle edizioni di Documenso distinguono i diritti software dalla proprietà dell’infrastruttura. Calcola il budget del flusso esatto, incluse azioni a pagamento e servizi di supporto, poi assegna la responsabilità operativa. «Illimitato» per documenti o utenti non significa capacità server illimitata né gestione gratuita.
Prevedi il budget per calcolo, archiviazione di database e documenti, backup, invio e-mail, certificati o servizi fiduciari, licenze commerciali, costi d’uso e tempo dell’amministratore.
| Voce di budget | Cosa registrare prima dell’approvazione |
|---|---|
| Licenza e utilizzo | Edizione necessaria, termini di rinnovo, costi di integrazione e unità che attiva ogni addebito. Ottieni conferma per esportazioni o opzioni di autenticazione ambigue. |
| Calcolo e dati conservati | Hosting di applicazione/database, file principali, capacità dei backup, crescita dei dati conservati e infrastruttura di ripristino. Anche l’hardware aziendale comporta costi di capacità e manutenzione. |
| Servizi di supporto | Invio e-mail, identità/SMS, certificati di firma e servizi di marcatura temporale o firma remota necessari al flusso. Includi eventuali costi basati sull’uso. |
| Tempo dedicato alla gestione | Aggiornamenti, revisioni degli accessi, configurazione di sicurezza, errori di consegna, monitoraggio ed esercitazioni di ripristino isolate. Nomina un operatore principale e un sostituto per le assenze. |
Stima in base a dimensioni dei documenti, periodo di conservazione e picchi di firma. Evita di confrontare un abbonamento SaaS con la sola fattura di calcolo della soluzione sostitutiva; comprendono lavori diversi. Se un vincolo commerciale o servizio necessario resta sconosciuto, il budget è incompleto anche con una licenza gratuita.
Un flusso approvato più limitato è un punto di partenza ragionevole. Rimanda l’automazione opzionale finché diritti, percorso dei dati e responsabile non sono chiari.
Esegui un pilota sintetico prima di trasferire i contratti
Usa un accordo fittizio e destinatari di test per valutare l’edizione scelta prima di trasferire i contratti. I requisiti di Documenso e la guida Docker di OpenSign identificano le dipendenze; il pilota proposto deve testare insieme firma, esportazione delle prove e recupero. È un piano di accettazione, non un rapporto di test eseguiti. Registra errori e questioni aperte insieme alla configurazione valutata.
- Fissa la release o immagine e registra edizione, licenza e versione installata. Definisci azioni necessarie e prove accettabili prima dell’installazione. Conserva questa registrazione con la configurazione del deployment per ripetere gli stessi controlli dopo un aggiornamento.
- Approva endpoint e destinazioni di archiviazione. Includi i percorsi esterni nella scheda, poi esamina e-mail sintetiche di invito e completamento, allegati e dati trasmessi osservati. Verifica che il percorso OpenSign scelto includa il tuo backend, se pertinente.
- Completa un invito rappresentativo con destinatari esterni di test. Prova il metodo di verifica richiesto, l’ordine di firma, il rifiuto o la scadenza e il completamento. Conferma che i destinatari possano accedere dall’esterno della rete aziendale ed esamina gli errori di consegna.
- Esporta il PDF completato e la registrazione di audit nel formato richiesto. Convalida firme, certificati e ogni token di marca temporale indipendentemente dalla schermata di successo dell’applicazione. Confronta l’integrità con il riferimento autenticato conservato; altera una copia separata e verifica cosa rileva la convalida. È un controllo tecnico, non una prova dell’esito giuridico.
- Riavvia il deployment e conferma che le registrazioni siano ancora accessibili. Ripristina in un ambiente isolato e ripeti il recupero dei dati e la convalida. Assegna a destinazioni dei backup e responsabilità del recupero criteri di accettazione espliciti; il successo segnalato da un processo di backup non basta.
- Pianifica una transizione controllata. Conserva PDF completati e prove originali separati dai nuovi modelli. Decidi come si concluderanno le richieste aperte. Importare un PDF in un’altra applicazione non ne ricostruisce la cronologia di firma originale.
Il nostro deployment DocuSeal in un clic aiuta con la configurazione iniziale quando l’infrastruttura noleggiata approvata è adatta all’accesso dei destinatari; resta possibile l’installazione manuale su hardware aziendale o presso qualsiasi provider approvato. Scegli tra le nostre sedi VPS globali in base alle esigenze di collocazione dei dati del deployment.
Domande frequenti
Unità di fatturazione, licenze dei pacchetti e build installate richiedono registrazioni separate anche dopo la scelta del flusso.
I destinatari firmatari sono fatturati come utenti della piattaforma?
No. La spiegazione della fatturazione Pro di DocuSeal distingue gli utenti della piattaforma dai destinatari firmatari. L’unità d’uso di API e integrazione incorporata è un invio completato, che può contenere più file e parti. Registra sia i diritti degli utenti della piattaforma sia i costi d’uso applicabili; non applicare questo modello di fatturazione a un altro progetto.
Una licenza copre tutti i componenti del repository?
Esamina file e pacchetti scelti. Documenso ha una licenza separata per la directory commerciale; le eccezioni della licenza radice di OpenSign escludono una directory specifica delle route del server, se presente. Per una build personalizzata, registra componenti inclusi e relative licenze prima di presumere che la licenza principale del repository descriva ogni componente.
Una release upstream identifica la mia build installata?
No. Una release upstream identifica il software upstream, mentre un’installazione ha una propria build distribuita ed edizione. Registra la versione esposta dall’applicazione in esecuzione o dai metadati di deployment prima del pilota. Non dedurre quella corrispondenza da un annuncio di release e ripeti i controlli di accettazione quando cambia la build installata.
Discussione
Commenti
Accedi per partecipare alla discussione.