Docuseal: Open-source DocuSign alternative
github.com
github.com
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
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.
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.
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.
This describes how docusign uses video identification for document signing.
> If they request qualified signatures, you must verify your identity with the IDnow video service after selecting the SIGN button.
Signicat, another document signing service, uses WebID to do video verification
https://www.signicat.com/identity-methods/web-id
> 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.
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
The need for identification over video, etc., has more to do with the know-your-customer laws.
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.
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
What mechanism(s) is used to ensure non-repudiation?
I appreciate that the demo is not behind a sign up wall, but is account creation and email verification required for invitees to sign any documents?
Are IP addresses stored as part of the digital signature?
Any other mechanism?
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
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.
IANAL but in the common law world a contract requires 3 things:
* Offer and acceptance
* Consideration (something of value)
* An intention to form legal relations.
Acceptance is, of course, what a signature signifies. Acceptance is "a matter of fact" and thus in reality pretty much anything will do.
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.)
In practice, the security involved only has to reach the "good enough" threshold and not a 100% hack proof level.
It requires you to know the phone number of the signer, but for important stuff you typically do.
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.
To cheat, the party hosting it would probably have to forge signatures for everyone after the disputed signature.
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".
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.
Is it possible at the moment to send signature requests via WhatsApp? (even at a cost per send)
E.g. for T-mobile it is @tmomail.net.
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.
That is the whole point of signatures. Otherwise it is just an image editor.
- 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.
How secure is it? How confidential are the records? How does it guarantee integrity?
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)
This is the "I have a friend that does it cheaper" of e-signature solutions.
Testing it now with fingers crossed and hoping that the cloud version sticks around.
This is really important to me, so I'd be glad to work with you to troubleshoot and provide detailed user feedback.
Regarding the form issue - it looks like some js client side bug - i'll try to investigate this.
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.
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.
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.
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.
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.
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.
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.
Really looking forward to how this progresses!
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.
TLDR think electric cooperative or similar. You’re building an internet utility/primitive for long term consumption.
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.
https://en.wikipedia.org/wiki/Merkle_tree
Alternatively I'm thinking about adding a third party AWS QLDB integration - QLDB allows to maintain an immutable, cryptographically verifiable log of data changes.
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.
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.
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"
Alternative to eSign is to just send PDF documents. And as the person to add their signature to it.
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.
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.
Can you elaborate on this? Why people would want to have the signature first before showing the document?
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.
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.)
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.
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).
The first time I used it for anything, apart from signing pgp keys, was to collect 200€ rent assistance and it worked flawlessly in 4 minutes.
I'm not even sure how i can use my signature outside the AWFUL experience that is the government esig portal.
I dont think they are accessible for non-resident entities either - i.e. i can only get lithuanian signatures through the lithuanian portal.
This likely explains why they arent used b2b as you would need a separate contract process for foreign and domestic.
TBH, even a contract rests on a certain amount of trust between the involved parties.
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.
I think the infrastructure need here is extensible messaging. There are a lot of multiparty flows with notification and recordkeeping requirements
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.
Is this a big SaaS scam?
Whether that’s worth Docusign’s pricing or if there’s better alternatives, up to you. But it’s objectively a helpful tool.
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.
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.
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.
This link has list of different IDs they support in different countries:
https://support.docusign.com/s/document-item?language=en_US&...
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.
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.
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.
That feels like a pretty damn good system to me, and far beyond the system you handwave at. Where’s the complaint?
I would like to re-emphasize personally. It's not a business risk, it's a personal liability.
https://www.cryptomathic.com/news-events/blog/us-court-rejec...
That was fact-specific and doesn't call Docusign invalid, but it does demonstrate why simply "using Docusign" might not save you in a dispute.
Also...the article is from 7 years ago...
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.
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.
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).
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.
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.
https://en.wikipedia.org/wiki/Electronic_Signatures_in_Globa...
“may not be denied legal effect, validity, or enforceability solely because it is in electronic form”
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.
But if you are making a deed, there are attestation requirements under s1 of the Law of Property (Miscellaneous Provisions) Act 1989 - see https://www.legislation.gov.uk/ukpga/1989/34/section/1
If a company is executing a document, it has to follow the rules in sections 43 to 47 of the Companies Act 2006. See https://www.legislation.gov.uk/ukpga/2006/46/part/4/crosshea...
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.
See https://www.gov.uk/government/publications/electronic-signat...
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.
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
WTF? Considering that DocuSign is $25 or even $10 and has the name and weight behind it, I can't imagine that they are selling many subs.
In beta though, so consider that when using.
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.
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"
https://en.wikipedia.org/wiki/Online_banking#Internet_and_cu...
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.
Looks like it is $10/mo for 5. I don't see free...
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?
Also won't DocuSign accuse you of "misleading" their customers by using a name that is "too similar" to their ?
Docuseal would be the winner with all the free press, and changing a name costs almost nothing.
I'd have gone with "DocSeal" or something that was a harder break from the "DocuSxxx" pattern.
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.
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'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.
If I can't use DocuSign usually I need to print a PDF, sign it, scan it and send it back.
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.
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.
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.
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.
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).