Hi everyone, my name is Alex and I'm the creator of DocuSeal.
I was not happy with the existing mainstream document signing solutions so I decided to create an open-source alternative.
I've been working on this project since the middle of May and here is what the tool can do so far:
- PDF form fields builder
- 10 field types available (Signature/Date/File/Checkbox etc)
- Multiple submitters per document
- Automated emails via SMTP
- File storage on AWS S3, Google Storage, or Azure
- Automatic PDF eSignature
- PDF signature verification
- User management
- Mobile-optimized
DocuSeal can be self-hosted on-premises or used in the Cloud for free.
DocuSeal was built with Ruby on Rails with a bit of Vue3 for complex UI parts like the form builder.
Looking for some feedback and would be happy to answer any questions
This is amazing work, and this space desperately needs an open-source solution!
The signing experience could use some polish, but it's well on its way. A few things: clicking a signature field immediately opens a file upload despite the very functional draw-your-signature canvas. Focusing to type into a field scrolls the page not so the field is in view, but so it's at the top of the viewport, which prevents the reader from seeing the paragraph of context above the field. And minimizing the bottom panel where you type fields should be unminimized if you click another field, otherwise it can cause non-technical users to feel "stuck." Oh, and in terms of demonstrations, the demo PDF should likely be a (fake) legal contract of some sort, to show off how things can be positioned in a realistic document!
If there's one thing I'd suggest you implement, though, it would be the ability to embed the signing interface in an iframe whose URL can be parameterized to prefill values via the query string, e.g. following https://helpx.adobe.com/sign/adv-user/web-form/url-parameter.... (Oh, and postMessage to the parent page when signing is done so the interface can react to that!)
So many real-world workflows can be handled with a simple wizard that pre-populates a PDF to sign, with the values from that wizard. But most of the solutions out there charge an arm and a leg for this, with large minimum order sizes and even charging for the view even if the user doesn't complete the form! Not to mention that letting people self-host, thereby avoiding third-party cookie issues, makes things significantly more accessible.
Thanks for the feedback! All your UI suggestions/fixes make sense and will definitely be brought into the the tool soon! Also I like the idea of using some 'fake' legal document for the demo.
Regarding the iframe - i've been thinking about creating an npm package for better integration with the host app - but maybe giving an option to use iframe should be available as well for companies that don't have developers to implement a better integration with the npm package.
Not to mention making this system usable by folks who haven't ever used modern JS tooling, but who are trying to string together no-code/low-code tools/form builders/Wordpress plugins to automate their workflows and be able to do more creative things with their time!
This kills it as a viable alternative to DocuSign. The point of Docusign is that it is an independent third party that maintains custody of the signed contract and proof of acceptance (i.e., digital signatures) by all parties to the contract.
A self-hosted digital signature system isn't worth anything in court; the other parties will simply reject the authenticity of any data held within it and the amount you'd have to spend to get that data into evidence would probably pay for several centuries of DocuSign's enterprise edition.
That being said, the cloud-hosted option seems viable as a competitor for Docusign if it's offered by you/your organization as a service, and could provide financial support for continued development.
>A self-hosted digital signature system isn't worth anything in court; the other parties will simply reject the authenticity of any data held within it and the amount you'd have to spend to get that data into evidence would probably pay for several centuries of DocuSign's enterprise edition.
When self-hosting it - you can integrate it with AWS s3 Azure or Google Cloud files storage - those are the trustworthy third parties that provide the entire history of logs to ensure that the documents were not altered and signed at specific date/time with the specific content.
So bringing cloud storage providers as a thirdparty when self-hosting will bring enough evidences to the court to defend the signed documents.
How do you prove who actually signed the document? Docusign does this by only sending the signing link to the signer’s email. I don’t see how you could prove that no one else had access to that link if you’re self hosting.
I tested it out briefly and it looks very cool for something put together within a couple months. One thing that doesn't seem to work at the moment is automatically recognizing existing PDF form fields (although perhaps there was a problem with the specific PDF I tested).
Being able to quickly import existing forms and then just add some labels would make things move a lot quicker.
One other thing that would be helpful is to handle variable numbers of signatures required. Some documents I have to deal with have space for many signatures but for any given instance, only one or two might be needed. Perhaps I've missed this, but I'm not sure existing templates would handle this case. I think that ideally a template would contain all the signature fields but then I can specify which ones are actually required when I send out the document for signature.
what a great idea, thank you very much. Two years ago I was evaluating different signing solutions for the company I worked with and there were two killer features that forced us to go with docusign since at the time they were the only ones really supporting it:
1. Relaying of Submissions to other Signers
We often found that we needed to get a Signature from someone at another company. However, we couldn't a priori say "Person X has to sign it". Often we had a contact person that would help us navigate the internal structure of the other company and relay the signing to that person. Docusign has the ability to allow us to say this person we know can decide who has to sign this document, even if we don't know that person. No one else at the time supported that use case.
2. Qualified Electronic Signatures
So... Here in Germany our Government has some kind of Angst (might call it german angst) of anything digital. A Handwritten signature on a piece of paper is held in such high regards that the digital equivalent (qualified electronic signatures) require a video ident workflow with a passport held into the camera and so on. This has to be done via a third party service that takes like 15-20 Euro per validation. I know it's insane. There's a reason that theres no german silicon valley... Anyway, there are many situations where this level of validation is required by law.
Just my 2cts after dealing with this issue here, I think 1. is something you might look into implementing, cause it's a use case that might come up more often, 2. is just really annoying for everyone.
I'm interested in reading more about #2, can you provide a source?
https://www.docusign.com/products/electronic-signature/legal... doesn't mention anything about videos or passports. I could see how that might be one means a third party has chosen to collect proof of intent, but haven't found anything legally mandating it.
> The WebID service VideoID provides call-center functionality, where trained support agents can verify the validity of the provided identity papers and ask security questions to the end-user during a live video call.
This may be german law specific, the overarching EU Legislation can be found by googlign "qualified electronic signature".
In general they require complete, verified cryptographic signatures via smartcards or similar but because no one uses it, videoident has become the defacto alternative in germany
That's a misconception. Most contracts or form-free and can be made by handshake if one wants to. There are however some exceptions, which require either physical signatures or the qualified signatures as declared by eIDAS. Those exceptions are some employment contract and most things related to banking.
The need for identification over video, etc., has more to do with the know-your-customer laws.
Most physical bearers (smart card or similar) of a Qualified Certificate are issued in person or based on a known identity. Here there is no need for remote identification before the issuance of the certificate.
What you are talking about is a “remote signature service”. Such a service will often onboard a user remotely using a physical ID, video and liveliness checks and give them the credentials to produce advanced or qualified electronic signatures with the service in question. These credentials have to meet LoA Substantial or High for a QTSP to be able to issue a QC to a user. Most remote signature services use very short lived certificates (10-15 minutes) that are created for every signature the user produces. (As opposed to the long lived certificates of several years for a physical card).
Germany have to follow the eIDAS-regulation as a member state of the EU/EAA. But what level of signature is needed for what transactions is not regulated in the eIDAS.
> But what level of signature is needed for what transactions is not regulated in the eIDAS.
Yeah, its the issue that germany decided that only the QES is as legally binding as a physical signature and then they made a whole bunch of contracts, especially work related stuff require physical signatures
Hi Alex. Would you be interested in help running this as a non profit like Let’s Encrypt, but for digital signatures? I would be willing to contribute both financially and infra/DevOps/biz ops to bootstrap.
It's hard to say at this point if something like Let's Encrypt can exist in this space - but I'm for sure going to continue offering a free Cloud SaaS option with a generous set of features for document signing.
I'd love to chat to explore more about the potential non-profit solution - please feel free to drop me a line at alex@docuseal.co
I’ll reach out shortly. My thoughts on this are you don’t remain free, but instead charge based on a cost recovery model. You figure out annual people/tech/admin expenses, forecast and observe request volume over time, and then adjust per signing request pricing accordingly (or perhaps sell buckets of requests to high volume consumers, contracts ensure smooth cashflow). This enables longevity and stability of the service (which gives warm fuzzies to consumers of it), no concern of an acquisition or buyout, while enabling servers to spin and people to eat.
TLDR think electric cooperative or similar. You’re building an internet utility/primitive for long term consumption.
I run a small tech nonprofit (see profile) and have also been unsatisfied with DocuSign and alternatives in the past. I'd be happy to help if I can be useful here, either with hosting (and PKI) or with development directly.
One of the tough things about a party-controlled, self-hosted e-signature is that it becomes easier to repudiate because a party to the contract has custody of the platform.
The non-custodial party can claim they never signed, and when the custodial party produces evidence of IP address and timestamp, the non-custodial party may have a credible argument that they are faked and the person asserting those authenticated details has the motive and means to fake them.
That argument is much harder to assert with something like DocuSign because it is unlikely DocuSign would put their business on the line to fake someone's signature.
I'm not saying repudiation based on custody of the e-signature platform is a winning argument, but it's something to consider before self-hosting if you are going to use the platform to sign your own contracts.
The problem is that it would require everyone to monitor the ledger for falsified versions of their own signature. That works a lot better in the world of Certificate Transparency where Google can scan for google.com registrations. It does not scale well to every human being doing that, or outsourcing it.
The fundamental challenge here is that there's no way to tell, based on a the signature alone, which signatures are "valid" and which are "forged"; they're not cryptographic signatures. And getting cryptographic signatures for lay people is apparently too hard to do, outside of Estonia's digital citizenship initiatives.
It might be neat if the big guys agreed on an OIDC extension that let you piggyback text to be affirmed by the user. Cryptographic proof that jane.doe@gmail.com saw text with hash H at time T and chose "Accept".
Wait... You're talking about Git, right? Brilliant idea! You could sign a pull request, and once it's signed, you can then merge the businesses. But how do you show a diff of the signature? And what if it's not for a corporate merger?
But what keeps someone from forking your git repository and insisting that their HEAD is the source of truth? How can we get a globally agreed upon source of truth?
As long as we're talking about non-cryptographic-signatures, the party hosting the e-signing software can claim any signature to have happened at any time. The whole point was DocuSign would be unlikely to do this.
someone should combine a chain of blocks for identity management with one for financial transactions/tokens and one for signature attestation. We could call it the cube chain and usher in web 4.0.....
Yeah, I really like this initiative, but this is not a technology problem. This is a trust problem. The EUJ actually has a not-terrible framework in place around electronic signatures, and _some_ countries are pushing hard for adoption and implementation.
> That argument is much harder to assert with something like DocuSign because it is unlikely DocuSign would put their business on the line to fake someone's signature.
This seems like the claim that the USG will be unlikely to put it's Military on the line so they won't leak any tank designs on discord.
Happy to concede that the CEO of DocuSign wouldn't do this but surely some 15$/h employee doesn't have that same opinion.
The support person should not have that kind of access without auditability and traceability. Even Sundar should not be able to log into a console and read your emails either.
Someone implied that counterfeiting a sig or altering one, etc. was just as easy in Docusign as it would be with on on-site one-party controlled system. It just isn't.
IP addresses and browser User Agent strings are stored for each signature/submission - those are the only measures for 'non-repudiation' currently available.
but i think it doens't differ from other mainstream SaaS solutions - if you read through their terms of services - they put 'non-repudiation' liability on users of their services
From my research this has 0 legal validity, at least in germany in regards to the EU eIDAS. They are just smoke and mirrors for companies to make them "feel" secure but without cryptographic ensurances (Advanced Electronic Signature) or TLS like Signed Cryptography (Qualified Electronic Signature) this is just as legally binding or not binding as an E-Mail
> just as legally binding or not binding as an E-Mail
Which is legally binding. In Germany most contracts are free-form contracts (Formfreiheit) and only need declarations of intent in the form of offer and acceptance. This can be a handshake or even a head shake.
Yeah, it’s not like in the spirit of the law you can perform your part of the contract and then get away with saying “I never agreed”.
In the US, we have a federal law that covers electronic contract signing. I believe it’s part of the UCC? (I’m not an attorney, and that area isn’t one I practice with in tech either.)
I am involved with two nonprofits that need to have an easy way to get many non-technical people to sign a document. Each is paying for their own DocuSign account. The thing is, they only need to do 6-12 documents per year each, so the cost per document is insane.
Testing it now with fingers crossed and hoping that the cloud version sticks around.
Darn. I created a document, setup the info for three sigs, added the recipients emails and then it was unclear how to push it out. I guessed at "Submit it yourself," which required me to add my email so I used the first recipient's and then it opens the doc for me to fill out. It asks for full name and then when I submit, "next" just keeps spinning. FWIW, I am running FireFox with UBO, etc.
This is really important to me, so I'd be glad to work with you to troubleshoot and provide detailed user feedback.
The emails are automatically sent to the recipients after you submit the modal window to add them (there should be 'SENT' status displayed next to their emails)
Regarding the form issue - it looks like some js client side bug - i'll try to investigate this.
> Looking for some feedback and would be happy to answer any questions
It would be great if you could add support for AWS QLDB. It's an immutable blockchain database (basically, "git with an SQL interface"), and you can periodically "stamp" it by notarizing its hash with one of the public blockchains.
This way you can guarantee that the records are going to be immutable and unalterable.
thanks, i think that's an interesting space to explore. there were many comments regarding the 'consistency' of the data/documents so solving this 'trust' issue especially when selfhosting it is really important
I love the fact that this exists, however my major concern is that because this is self-hosted, in the event of a dispute, the other party can claim that I forged the document. In such a scenario, how would I ever prove that I didn't?
When self-hosting it it's possible use merkle tree to ensure the documents integrity (similar to how git works with its commit hashes).
So to forge one document it will require to change all document hashes after the disputed document making it impossible to cheat by the organization that is self-hosting it. This will be added into the project soon.
Alternatively I'm thinking about adding a third party AWS QLDB integration - QLDB allows to maintain an immutable, cryptographically verifiable log of data changes.
This looks great. What's the best way to contribute a translation?
I think a great feature would be an email with a confirmation link after the pdf gets signed to ensure the owner of the email was the person who signed the document, if the link share option is used.
It's not possible at the moment - but i've been planning to add this feature to use phone number and text messages (including WhatsApp) as a second layer of authorization when signing docs. Stay tuned!
> - File storage on AWS S3, Google Storage, or Azure
I'm guessing it's just a mistake/miss in this comment, but for file storage it is also possible to store it locally on the server right? Otherwise all "editions" are "in the Cloud" yes or yes, so would kind of defeat the purpose of the self-hosted version.
It's possible to use local storage or Aws s3, Azure, Google Cloud to store files.
When storing locally it makes all the documents 100% owned by you - but in some cases companies might want to bring a third party files storages to ensure the integrity of the documents.
But as was mentioned before in the comments - maybe bringing AWS QLDB as a third party to ensure the consistency of data with a local files storages is the best option. This way all documents can be logged with a third party so they can't be altered - while to content of the documents won't be shared with any third party.
It's not perfect for a single person just using it for themselves (a lot of workflows seems very company/team oriented), but it's still better than nothing which is what I had before. Thank you for open sourcing it, this will absolutely help me :)
> DocuSeal can be self-hosted on-premises or used in the Cloud for free.
Charge something for the cloud product. If you feel your product is good, then don't give it away for free. Your product charges will help sustain future development down the road.
The E-Sign Act grandfathered in existing agreements that existed digitally prior to Oct. 1, 2000. All agreements after this date, however, must comply with the following set of guidelines in the E-Sign Act to be considered legally binding:
- Intent to sign. Electronic signatures are only valid if the involved parties have the intention to sign. Signature requests can be declined.
- Consent to do business electronically. Involved parties must agree to conduct transactions electronically.
- Attribution. The signature must uniquely attribute to the individual signing the document.
- Association of signature with the record. E-signatures must have a mark on the document from the signer that can then be associated with the record.
- Record retention. Electronic documents must be savable, viewable and printable by either party.
I think the tool provides all that - usually when working as a contractor i've been signing documents in PDF viewer and sending them back via email and that was what my clients wanted me to do.
Tools like DocuSeal are making the process of signing docs easier than doing it via email.
When self-hosting it - it's up for the company that is using the tool hosted on-premises to ensure that all their specific requirements are met - i think DocuSeal provides enough features to make this happen.
AWS S3 to store documents can be integrated with DocuSeal to ensure the documents integrity - AWS services have their own logs that can't be altered and so can be used as a source of trust.
And to ensure that the document was signed by a real person companies can include photo attachments into the documents signing process (this could be a photo of an ID card or a selfie)
Currently it’s possible to sign documents only using the autogenerated pkcs7 certificate in self-hosted DocuSeal (it’s done automatically be default).
But it should be doable to make it work with different certificate formats to bring your own certificates.
I’d be happy to explore those options and would appreciate it if you could open on issue on GH in case you’re interested to have this supported this in the tool.
These projects never realize that eSign tech is a commodity, the actual business you are in is creating market level Trust for your platform.
Eg if you’re a CFO, would you being willing to take the risk just to save a couple of bucks on a no-name eSign service for all your sensitive legal & vendor agreements, or use the worldwide Trusted eSign platform of DocuSign - which has gained acceptance by regulators as being an authoritative legal signature of contracts.
We learned this pretty quickly with our banking products. Having your own bundled, first-party e-sign features can help differentiate your product from other vendors, but if the only thing you are selling is e-sign, they probably won't look at you. We do have an in-house e-sign feature in our product now. We evaluated integration with Adobe & DocuSign, but their APIs were so far away from what we needed that we decided to DIY.
Consider this - what is a bank going to do with raw access to something approximating docusign APIs? They outsource everything. Their vendors are the ones who would be consuming something like this and then reselling it. Getting onto the QVL for a US financial institution (and staying there) is usually a monster battle if you are a new kid on the block.
If you still wanted to market this solution towards US financial institutions, I'd start with the vendors of those institutions. Companies like Jack Henry & Associates, FiServ, CSi, FIS, Harland Clarke, et. al.
That's interesting that you ended up developing an in-house document e-signing feature for your product. I'm curious, would it be possible for you to choose a self-hosted and open-source solution like Docuseal, integrated with your product to outsource the complexity and speed up the development? (if such an option existed back then?)
Honestly the bulk of complexity seemed to emerge from the mismatch between what we thought would be a good e-sign API and what APIs were actually available.
The way our product works, we need to have access to the raw signature specimen at various stages of the signing process because we have a document generation feature that dynamically inserts the specimens into the appropriate fields. Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant. This is basically the exact opposite of how most vendors work, but our customers really like it this way.
We also needed a way to in-line bank-specific e-sign consent documents into the experience, giving the e-signer a way to decline consent and have this decline kick off an appropriate back-office workflow. The other reason we went in house is we wanted to completely close the loop. After the last e-signer completes their piece, our product detects this condition and submits all final documents to the institution's long-term cold storage system. Getting this to work with a 3rd party API looked like a total non-starter to me - We can't just send the docs right away. There are time-of-day constraints on when those systems will be available throughout the week.
Our e-sign solution ultimately turned into a workflow-style experience with 6-7 steps.
> The way our product works, we need to have access to the raw signature specimen at various stages of the signing process because we have a document generation feature that dynamically inserts the specimens into the appropriate fields. Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant. This is basically the exact opposite of how most vendors work, but our customers really like it this way.
Can you elaborate on this? Why people would want to have the signature first before showing the document?
In our solution, providing the up-front signature does not construe immediate consent to terms of whatever hypothetical documents. We have a subsequent review phase where the customer is expected to confirm each document meets their expectations (i.e. with their actual signature on it). Only after confirming all of the documents is the transaction considered to be completed and the signed copies taken as official.
The more complicated answer is that we are serving e-signatures for business accounts wherein there might be 10+ authorized signers involved. In these cases, we want to permit parallel sign completion. To allow this, each signer gets to view an isolated scope of documents with just their signature affixed. This also helps to conceal the signature specimens of other parties until the entire transaction is considered finalized. If a required party to an account does not want to participate, then no one gets to see anyone else's ink.
At the very end, all participants of the signing ceremony receive emailed copy of documents that combine signatures from all participants.
> Put differently, we don't show the documents until we first have a signature (and initials) specimen collected from the e-sign participant.
Why would I sign something I haven't seen?
Businesses & government in USA seems to like asking for my signature on a little LCD pad, without showing me what I'm signing. That's absolutely horrible and anti-consumer behavior.
(And yes, I do diff DocuSign-style PDFs before and after the insertion of the pseudosignatures and visible watermarks, or PDFs from before and after a email-print-sign-scan-email cycle.)
If your company has a board and a CFO then sure, go with the trusted solution. If you're starting a scrappy, modern, real world business, things like this can help avoid death by a thousand cuts that is paid microservices.
>"Eg if you’re a CFO, would you being willing to take the risk just to save a couple of bucks "
Typical FUD preached by many online companies to lure customers.
Even verbal contracts are enforceable (with the caveats of course). These will be fine for the most boring cases. The others are signed with lawyers anyways.
This is the important part you're ignoring. Yes, verbal contracts between businesses are binding, but only to the extent you can actually prove the terms in a court of law.
Using DocuSign (or similar) is about risk mitigation, specifically about being able to prove the the contents of the contract in legal proceedings.
The risk with being a business that allows for verbal contracts is that one of your vendors may be unscrupulous and truly screw you over. And that's a matter of when, not if.
I've never understood how DocuSign mitigates the risk any more than both parties signing a PDF in Preview (or similar) and exchanging via email. Doesn't the email part validate that you are the person signing the document?
I think that's a valid point - and actually in their terms of services say that they are not responsible for the signer authenticity.
Here is a summary from their TOS:
"DocuSign provides tools and features that help to establish the authenticity of a signer, such as email verification, access code, SMS verification, phone verification, and knowledge-based authentication. However, it's important to note that while these tools can enhance the security and authenticity of the signing process, DocuSign itself does not guarantee the authenticity of the signers. The responsibility of ensuring the identity of the other party lies with the user"
Competition is a good thing and a core tenet of capitalism. If we don't have competition and regulators are wedding themselves to one particular business then that means we have a government sanctioned monopoly.
The way a system like docusign works is that it is a (trusted) independent third party that will verify that the owner of email address X is the one that "signed" the specific version of an agreement.
By self-hosting, you have access to the infrastructure and can manipulate it to your will. There is no proof that the counterparty signed anything - you could just manipulate it to say they did.
This potential for misuse could make it difficult to enforce your contract should you be required to do so.
I do wonder about that for self-hosting a service like this. But how often do actual disputes arise between parties as to whether a document was actually signed or fraudulently altered?
TBH, even a contract rests on a certain amount of trust between the involved parties.
When selfhosting it - it's possible to connect AWS S3 to store the documents - AWS with S3 logs could be used as a source of trust to ensure the documents are not altered.
Nothing prevents the person running the software from submitting a "bad document" stating anything they want, with plausible IPs and timestamps etc. That is the problem.
A third party like DocuSign is somewhat comparable to using an escrow company to buy a house. You trust the escrow company to not steal the money, but you don't have to trust the seller. You trust DocuSign to not forge document metadata.
Not entirely true, cryptographic signatures exist. For example the EU eIDAS Law allows Advanced Cryptographic Signatures to basically just be PGP Signed Emails
Which unfortunately nobody uses because non-cryptographic signatures (such as Docusign or this but hosted by an independent third-party) are considered good enough in practice.
Hell, nobody even has a smartcard reader, and as far as I know none of the eID cards have contactless capability that phones (who all have NFC readers nowadays) can use.
I wish smartcards took off and computers included readers as standard. This would not only solve strong authentication but also payments (just insert your bank card and do EMV-style payments with comparable levels of security).
Latvian eID also provides cryptographic signing, and it's widely used when communicating with governmental institutions, because it's mandated by law that they must accept such digitally signed documents, and they have the same legal power as regular documents. I believe the situation in Estonia and Lithuania is probably similar. Many businesses also accept them but it's not universal.
We do use this type of signatures here but for specific use cases, generally with administration like bodies, but not only. Generally speaking, the basic eSign covers 9x% of the needs.
I can sign documents with my goverment ID card, I use my phone NFC as card reader in my computer with an goverment app, it is kind of clunky but it works.
What is the bar for a "legally binding digital signature"? Is this a very complicated topic - or is it quite simple?
I can sign a PDF with OSX Preview for free. I can pay a bunch of money to sign with Docusign. Both produce a PDF with a digital image of my signature. I assume both documents constitute a legally binding agreement, so long as I actually preformed the digital signature. What justification do the e-signature SaaS companies have for their exorbitant prices? I understand the "audit trail" angle - that's just collecting my IP every time I interact with the document.
> What justification do the e-signature SaaS companies have for their exorbitant prices?
They will defend their digital signature in court.
I was shocked to find these "click here to sign" contracts manage to do it all without an ounce of cryptography, but the fact is lawyers don't need cold hard math, they need a warm body to be a subject matter expert to explain to a jury that unless you're claiming someone else has access to your inbox, you're the one that clicked the button.
Yeah, I find it funny to see technologists being surprised that in most cases judges won't mind that the signature wasn't done with quantum-resistent cryptography stored in a blockchain or whatever. Technical solutions to political problems...
I had to get a notary to sign my I-9 form for a new remote job. The process of identity verification involved a seemingly 19 year old dude looking at my ID and then signing a piece of paper.
A website sending you an email and tracking your IP and keeping a log... seems to be about the same level of trust to be honest.
Ageism aside, you are describing a system where an unrelated third party who has experience validating state/federal identity documents validated yours, visually compared the person presenting the documents to the picture on the ID, then signed a log in his possession that he’d testify to in court if needed.
That feels like a pretty damn good system to me, and far beyond the system you handwave at. Where’s the complaint?
Notaries are personally responsible for any misconduct with up to a felony criminal case for violations. Including not sufficiently verifying the identity of the person in front of them. Sure, most states will just slap them with a $500 penalty, but they'll also revoke the notary status pretty quickly.
I would like to re-emphasize personally. It's not a business risk, it's a personal liability.
Not really applicable, in that situation there were local court rules requiring physical documents and "wet" signatures (i.e., signed in person with a pen). The UST specifically noted that absent those rules DocuSign would have been acceptable.
Of course it is applicable. The Docusign users failed to use it in a way that would be legally valid.
If you have a more recent case that seems relevant or invalidates that result, post it. Otherwise I'm not sure what being 7 years old has to do with anything.
You're attempting to make a mountain of a single instance, years ago, of an electronic signature being rejected by a non-judicial officer in a quasi-judicial proceeding and trying to make it out like a general policy when it is so rare an exception that no court before or since has ruled against the consensual use of electronic signatures by the parties.
If you have any evidence that electronic signatures can't be used in court proceedings, and not just in the limited circumstance of one US Trustee's meeting room, the onus is on you.
I never claimed I did, and I have no interest in talking to someone intent on making up crap that I never said, so I'm going to ignore you now. Life is too short to put up with bad-faith bullshitters.
See the recent Canadian case of the thumbs up emoji signature [0]. The bar for a legally binding contract is much lower than what most people believe. The main thing you need is to be able to prove that the other party actually did express their assent to the contract. In the thumbs up case, who sent the text was not disputed, so the issue hinged on whether a reasonable person would interpret thumbs up emoji as expressing assent.
Mostly yes.
In the EU at least, the rule is "An electronic signature shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures."
However, the burden of proof is higher if you dispute a "qualified electronic signature". To be qualified, there's no specific technical requirements, e.g. use of cryptographic signatures, but you'd need to be certified and registered as a “Remote QSCD” according to ETSI EN 419 241‐2 PP.
Self-hosting this solution (or using PGP) won't magically make you a certified QSCD trust provider. You need to convince some certifying body that everything is nice and safe, which will mostly involve a lot of paper work and (evidence of) processes being in place.
> Self-hosting this solution (or using PGP) won't magically make you a certified QSCD trust provider. You need to convince some certifying body that everything is nice and safe, which will mostly involve a lot of paper work and (evidence of) processes being in place.
This! Just like a self-signed SSL certificate for a website: yes, the traffic will be encrypted but you cannot be sure that the website is who it says it is.
Docusign makes it easy to collect lots of signatures from lots of people. That’s the use-case from my POV. 1 signature on 1 doc, use any PDF tool—no problem. When a board needs to approve 4 docs and you need 5 signatures on each, it needs to be easy.
Whether that’s worth Docusign’s pricing or if there’s better alternatives, up to you. But it’s objectively a helpful tool.
> Docusign makes it easy to collect lots of signatures from lots of people. That’s the use-case from my POV. 1 signature on 1 doc, use any PDF tool—no problem.
Collecting lots of signatures isn’t Docusign’s value prop.
The value is signature certification, and a proven track record in court.
A single signature on a PDF is not technically difficult. The machinery to reasonably guarantee (edit: verify is a better word here) that it was you who signed the PDF is the thing that matters.
The value increases from there as the complexity of the document being signed increases.
DocuSign doesn't really do anything to reasonably guarantee that it was any particular person who signed the PDF. Not that it really matters. If there was something worth suing over then usually there will be plenty of other evidence as to who signed the agreement.
Really the only thing that DocuSign does is timestamp the actions on the document. In order to get that a self hosted implementation would need some kind of third party system to act as a witness.
They’re capturing more than just timestamps. If possible, they’ll associate a signature with a DocuSign profile, which itself has a history of interactions with DocuSign servers. They also capture associated emails, IP/browser info, drop cookies, location data if enabled, etc.
None of this guarantees Person A signed the doc, but the point is to systematically collect as much info as possible to be used if someone does sue, and to check the boxes that customers need checked in a consistent manner that they can sell as an effective solution that stands up in court.
I’m not saying they’re doing anything unique here, but customers - especially enterprise customers - buy it for all of these things, not just because it makes coordinating many signatures easier.
The typical “no one gets fired for buying DocuSign” adage applies here.
Depends on country how much verification DocuSign is able to do, and also the higher levels of verification are opt-in. In some countries it can be backed with fairly strong auth schemes, in other places stuff like video calls are used.
This link has list of different IDs they support in different countries:
I know that I can sign things on a brand new device without making an account. They can log what any web site can log. None of it really proves anything, except as other commenters pointed out - if I sign tons of stuff with the same browser/session, with an account I made, or if I used some premium ID verification they offer. (which I've never done)
My point that it doesn't really matter that much. If I DocuSigned some contract, delivered work described in the contract, maybe got paid for some of that, and then later some dispute comes up.. at that point we're arguing about terms or other facts.. Neither party is going to be in any position to argue "oh I never DocuSigned that agreement" because all of the other work and communication and transactions are enough to prove that's not true.
As always, it depends on the jurisdiction. The EU has the eIDAS [1] which allows simple signatures such as these for most form-free-contracts (the majority). There are however some, which need a digital cert and have to be encrypted.
And Switzerland ZertES: https://en.wikipedia.org/wiki/ZertES - There are not normally various levels of trust with afaik only QES (Qualified Electronic Signature), the highest level to legally be on the same level as a hand signature.
I had same feeling when I build a free tools to unlock the password protected pdf. It can be easily done with OSX Preview. Then I see that people who don’t have technical knowledge and tools, they can easily unlock pdf from browser itself.
I think there's more to that. A proper digital signature requires you to obtain some certificate/key from an authority which you can then use to sign documents (this doesn't even require an image of your physical signature in the document). This proves that it was actually you who signed the document. The document also can't be altered afterwards without rendering the signature invalid etc.
Just adding the image of your signature to a PDF is probably fine for unimportant things, but it certainly isn't enough to be legally binding (at least in the EU).
The legal rules around formality are somewhat complicated. To give you an idea, here are the broad laws in England and Wales.
Not a lot of formality is required for most contract signing, and so long as the other side of a contract is sure that you signed it, a PDF signed in a standard PDF editor like Preview is almost certainly fine.
For property transactions, there's still an issue in use of e-signatures. There's a statutory scheme for "e-conveyancing" set out in Part 8 of the Land Registration Act 2002 which gives the Land Registry the ability to set up provision for using e-signatures for formalities that previously required wet ink signatures. They never got round to actually implementing this up until COVID restrictions made it somewhat impractical to get wet ink signatures so made a temporary change to allow it. When the COVID restrictions were lifted, they've gone back to the old practice but have promised that they're totally going to sort out a permanent solution. Whether they will is another matter.
I've personally used an iPad with an Apple Pencil to sign and have attested a (non-company) deed that had to comply with the LP(MP)A requirements and nobody seemed to have any trouble with it.
I suspect the target audience of a lot of e-signature SaaS products are companies where there are teams managing a lot of documents being signed across multiple jurisdictions, and juggling between sales, in-house legal and so on. Most of the problems those products are solving are likely business process issues rather than strictly legal requirements.
Documenso doesn't have all the features that are currently available at DocuSeal - also Docuseal if free in the Cloud when Documenso is $30/month
Afaik the only thing Documenso can do is to place a signature - when with Docuseal it's possible to create more complex PDF forms with different field types like file/image/checkbox etc.
While Documenso looks like an ambitions project - DocuSeal already appears to be more robust and can become a true DocuSign alternative with all the features already available and open-source
Signing documents online is not a technical problem but a business and legal problem. DocuSign and other commercial companies have a business not necessarily because they have any unique technology or the best user experience (they often do), but because they handle all the complex stuff around signing documents.
A reality many people don't see is that many commercial companies really have the expertise in certain areas and have the resources to handle the non technical side of things, at least much better than open source communities. Similar to "open source tax filing software", I'm afraid this is another example of people thinking open source solves every problem. I for one don't see myself using any of such tools unless they are actually reliable, competitive and trusted by many corporations and individuals.
> I for one don't see myself using any of such tools unless they are actually reliable, competitive and trusted by many corporations and individuals.
People said the same in 1999 for online banking.
"According to research by Online Banking Report, at the end of 1999 less than 0.4% of households in the U.S. were using online banking. At the beginning of 2004, some 33 million U.S. households (31%) were using some form of online banking. Five years later, 47% of Americans used online banking, according to a survey by Gartner Group"
Just today I was forced by Docusign to pay $45/user/mo in order to continue using the service for a single document I had to send out for signatures. Seeing this pop up on HN right after feels really nice. The cloud-hosted version seems to be very simple to use, so nice job on this.
Like some of the other comments pointed out, the key element here is trust -- in the 3rd-party platform collecting signatures, and in the confidence that it cannot be manipulated. These are solvable challenges, but calling that out explicitly in your documentation and website copy will help convert skeptics, or at least convince them to give it a try.
They don't advertise it, but if you start the trial then cancel, it'll downgrade you to the free plan. The features are limited - you have to upload every time and recreate the fields every time, but it works for occasional use.
I suggest a new name. `SealDoc` etc. The `Docu` part is going to cause you trouble imo.
I would also suggest maybe an explainer about how it's possible. Specifically, what makes a contract legally binding if it uses this system? The main reason people use DocuSign/ HelloSign is, in my opinion, because it feels safe legally to do so. Are there laws that make it possible for your service to work?
Definitely going to formally evaluate this; it looks straightforward enough to administer and prices outfits like Docusign charge are just north of silly.
I just tried it out and it was totally unintuitive how to add fields to a PDF. I tried to chat with support, but it wants you to use WhatsApp. (?!) Then I went to their youtube channel to see if I could see a walk through and every video is in Spanish. I guess they aren't interested in other geos like the US.
Thanks for pointing this out - it actually didn't expect that because of GitHub and GitLab and i haven't hears any trademark dispures between them.
When Gitlab differs from Github by only 2 letters - DocuSeal vs DocuSign is already 3 letters.
But i think that's a valid concern and i need to better investigate this - changing the name shouldn't be a problem when the project is still very new.
Yeah, it's one of those things where there's no definitive guidance, just loose tests. It's possible, for example, that DocuSign wouldn't care.
But, it seems different from GitLab/GitHub since the second word starts differently. GitHut, GitHow, GitHot, etc, vs GitHub would be more similar here.
I'd keep the name and not worry too much (I like it). Going after a small open source project would be bad press for DocuSign and even if they did, it would be a promotion for DocuSeal and you could change the name afterwards.
I'm a rare user of these platforms, but all I ever see is that I get an email with a link to sign something. Sometimes it's DocuSign and sometimes it's Adobe or something else, but I certainly don't feel any loyalty towards one over another, and as a signer, I certainly don't trust the platforms to hold onto my copy for me.
It seems that unless you've got clients who are trying to use DocuSign as their personal document management system, as long as the interaction flow is essentially the same it should be fine.
As i understood it the difference was esignature (was what this was providing) and esign was to sign with a digital certificate. esignature is plenty for most things.
Docudeal looks really cool and simple! and compared to the crazy costs of HelloSign, Docusign etc.
One thing I would say is provide a RestAPI so easy to integrate into our own applications so we can have the GUI on our side.
One of the features DocuSign charges a lot of money for is batch envelopes, like uploading a CSV to fill out fields and send to different recipients (basically Mail Merge). Is this something that could work in DocuSeal?
I was planning to add this week a feature to download csv or xlsx with all the data from submitted documents (the person that posted this link on HN somewhat spoiled the release - it was not be posting this link and wanted to wait just a bit )
But I’m sure this can work the other way around - it should be easy to make it possible to import contacts from csv to collect signatures and data from the PDF submissions form in batches.
Our product Bulksign https://bulksign.com does this, the name of the product is directly inspired by that feature (sending same documents for signature to hundreds of recipients).
In order for this to be legally useful to users in the EU/UK, this would need to comply with the eIDAS regulations. I’m not sure what that entails, but it would be worth looking into.
A lot of the value of a signature provider comes from it being a neutral trusted third party. They slap a signature and a time stamp on a document, and you can get them to testify that the document existed in a particular state at a particular time.
one more point i want to mention - if u intend this to be used for genuine document signing, you may want to switch to a .com domain and do a registry lock[1]. I mean these are legal documents at the end of the day.
If u ever want to do enterprise contracts, they will insist on this. Might as well do it now, while ur still early.
registry lock is only possible for a limited set of TLD AFAIK.
Thanks for this. An open source solution is so necessary in this space. There is a need for some common trusted party who hosts that thing, as self-hosting doens't make sense I think.
How do these electronic signatures work? Is it PGP? Where does one store the secret (e.g. private key) and how can someone prove that it is really my signature?
Currently the documents are signed with PKCS#1 signature, signed documents can be verified at https://demo.docuseal.co/settings/esign (to ensure that they were produced by the tool and not altered/forged by some third party). Additionally I'm planning to add a merkle-based log of documents to ensure that documents were not altered by the party that is self-hosting the tool.
can you please elaborate which use-cases? - maybe that's something that actually can be possible by splitting some parts of the project into MIT licensed dependencies?
I'm thinking of cases where the pdf is accessed over a network. Like integrations with systems that do billing, invoicing, taxes, tickets to a game, rent receipts, pulling pdfs from your email, pulling pdfs from S3, almost everything?
"who saw my document and how much time" on a page level. thats basically the only incremental value of docsend over docuseal. most other features overlap.
It's great to see fresh efforts being made in this space. I categorically refuse to use DocuSign, due to objectionable clauses in their Terms and Conditions (
https://www.docusign.com/legal/terms-and-conditions or https://archive.ph/y27U4). Some examples are below. As far as I'm concerned nobody should agree to use their service.
Unfortunately DocuSign has monopolized electronic signatures in some contexts (examples from my own local experience: healthcare, real estate), to the extent that it's become exceedingly difficult to request a simple PDF to print, hand-sign, scan and return. Such friction is common at companies who outsource their paperwork to third party workflow providers. I'm fortunate that folks I do business with tend to want my signature badly enough to escalate to someone with authority who can make a procedural exception, but I doubt everyone is so lucky and suspect many users are effectively "bullied" into accepting the Terms regardless of their wishes.
Clauses I find objectionable include:
- various consents to analytics, including use of my data to feed their machine learning (might have been more palatable if they provided some insight and stronger confidentiality assurances)
- 2.1.1 waiver of jury trials and class actions
- 8 indemnification (a and e are a little broad, I'm not going to pay for your lawyers in circumstances that don't warrant it)
- 9.2 is unfair; any damages caps should be reciprocal
- confusing and possibly overly-broad intellectual property rights clause 1.1 (they should explicitely restrict their protections to only DocuSign's IP, not "all IP").
- They expressly disclaim any warranties regarding accuracy, quality, fitness for purpose or that information they provide will be error-free. That feels dangerous in the context of forming contracts. A fundamental value proposition of their business is accuracy ("Oops we made a mistake and actually your counterpart did not really sign the document..."). Liability here falls back to the parties, and as a consumer I refuse to be liable for their mistakes.
- Nor am I a fan of increasingly common clauses along the lines of "we can modify our terms at any time and you'll be deemed to accept the revisions" or "you further agree to any other notices we might choose to inject elsewhere onto our site" or vague expectations I consent to additional third party licenses not disclosed at this time (and ironically some of their preamble along these lines seems to be in conflict with 10.8). If you and I agree to something, then later you want to change your mind, you'd better come back and seek fresh consent. If you're making changes so often as to make that annoying and inconvenient, then it's a sign you have too many salaried lawyers on staff and need to replace them with a team empowered to stop wasting my time and yours and get this right the first time. Customer attention is a precious resource, and companies sending out legal updates on a frequent basis can't possibly in good faith expect consumers to keep up with reading them.
- I take offense to their Terms page making connections to Twitter, Facebook, Salesforce, Google analytics, etc. and subjecting me to cookies prompts. All this is not required to simply provide me with your terms of use, and somewhat inappropriate seeing as I haven't yet consented to anything.
These are off their current website, but I recall similarly problematic terms the last time I started (and subsequently abandoned) a signature attempt some years back.
And don't even get me started on their Privacy policy. (Among the various problems... nobody should have to "opt out" of their personal data being sold to other parties).
I was not happy with the existing mainstream document signing solutions so I decided to create an open-source alternative.
I've been working on this project since the middle of May and here is what the tool can do so far:
- PDF form fields builder
- 10 field types available (Signature/Date/File/Checkbox etc)
- Multiple submitters per document
- Automated emails via SMTP
- File storage on AWS S3, Google Storage, or Azure
- Automatic PDF eSignature
- PDF signature verification
- User management
- Mobile-optimized
DocuSeal can be self-hosted on-premises or used in the Cloud for free. DocuSeal was built with Ruby on Rails with a bit of Vue3 for complex UI parts like the form builder.
Looking for some feedback and would be happy to answer any questions