Open Source eSignature APIs: Six Projects, All Copyleft
Verdocs Team
Every open-source eSignature project we could find is licensed under copyleft terms. Not one is MIT, Apache, or BSD. The three largest are AGPL-3.0, which extends its source obligation to software used over a network, and that is the fact most likely to matter if you are embedding signing in a commercial product.
This post is the data and the method behind that, so you can re-run it rather than trust us. If you are searching for an open source eSignature API, the license is the first thing to settle and the last thing most comparisons mention.
What we measured, and how
Six projects, chosen as the open source eSignature and signing tools we could identify that have meaningful traction or are widely referenced. License, language, popularity, and last commit all read from the GitHub API on 2026-08-22, not from the projects' marketing pages.
Two caveats, stated up front. This is not a claim to have found every such project; it is the set we could identify, and we will add any we missed if you tell us. And GitHub's reported license comes from the repository's LICENSE file, which is not always the whole story, as the OpenSign entry below shows.
| Project | License | Language | Stars | Last commit |
|---|---|---|---|---|
| docusealco/docuseal | AGPL-3.0 | Ruby | 18,331 | 2026-08-17 |
| documenso/documenso | AGPL-3.0 | TypeScript | 14,664 | 2026-08-22 |
| OpenSignLabs/OpenSign | AGPL-3.0, with carve-outs | JavaScript | 6,896 | 2026-08-21 |
| esig/dss | LGPL-2.1 | Java | 1,025 | 2026-08-18 |
| LibreSign/libresign | AGPL-3.0 | PHP | 790 | 2026-08-22 |
| Keyfactor/signserver-ce | LGPL-2.1 | Java | 431 | 2026-01-30 |
Four AGPL-3.0, two LGPL-2.1, zero permissive. Star counts are the weakest signal in open source and are included only because they are the one directly comparable number every project publishes.
Why does the license matter more for an API than for an app?
Because embedding is the whole point of using an API, and embedding is where copyleft engages.
If you run a signing tool as a standalone internal application, copyleft obligations are usually easy to satisfy: you did not modify it and you are not distributing it. The moment you call it from your own product, and particularly the moment your customers interact with it over a network, the analysis changes. AGPL-3.0's section 13 is written precisely for that case: it extends the obligation to offer Corresponding Source to users interacting with the software remotely, not only to those handed a copy.
Whether your specific integration triggers it depends on facts a table cannot settle: whether you created a combined or derivative work, how it is deployed, and what your users actually touch. That is a question for your counsel, and it is cheaper to ask before you build than after. Any vendor telling you confidently that it does or does not apply to your architecture, us included, is guessing. Once licensing is settled, API-first eSignature covers the questions worth putting to any signing vendor, open source or not.
The market's own answer is instructive. Both of the two largest projects sell commercial or enterprise licenses alongside the open-source one, and position them partly around licensing and compliance. That product line exists because this question keeps arriving.
What does OpenSign's license actually say?
This one is worth singling out because GitHub cannot classify it, reporting only "Other".
Reading the LICENSE file: the bulk of the project is AGPL-3.0, but content under the apps/OpenSignServer/cloud/customRoute directory is carved out separately, and third-party components retain their original licenses. So the accurate description is AGPL-3.0 with exceptions rather than plain AGPL-3.0.
Nothing about that is improper, and dual or partitioned licensing is common. It is worth knowing because "it is AGPL" is the answer you will get from a summary, and the file says something more specific.
Are the two LGPL projects the same kind of thing?
No, and grouping them with the others would be misleading.
esig/dss and Keyfactor/signserver-ce are signing libraries and servers, not signing products. They give you cryptographic signature creation and validation to build on, with no signer-facing experience, no templates, and no workflow. DSS in particular is oriented to European signature formats and validation.
LGPL-2.1 is also weaker copyleft than AGPL-3.0: linking to an LGPL library from proprietary code is contemplated by the license in a way that AGPL network use is not. So if what you need is signature primitives rather than a signing product, these two are a materially different proposition, and the licensing conversation is easier.
One maintenance note from the same data: signserver-ce last saw a commit on 2026-01-30, roughly seven months before the others, four of which were committed to within a week of our reading. Treat that as a question to ask rather than a verdict.
What does the hosted version cost if you skip self-hosting?
Both of the two largest sell a hosted plan, which is how most teams actually consume them. Read from each vendor's pricing page on 2026-08-22, and worth re-checking before you budget:
- DocuSeal (pricing): free tier at 10 signature request emails a month. Pro at $20 per user per month unlocks API and embedding, then $0.20 per document signed in production, with a free unlimited sandbox.
- Documenso (pricing): free tier at 5 documents a month. Embedded signing arrives on Teams at $40 a month for 5 users, and white-labeled embedding on Platform at $250 a month.
Note what happens to the license question here: on a hosted plan you are a customer of a service, not a distributor of software, so the copyleft analysis that dominates the self-hosted decision largely recedes. Teams sometimes reach for open source for licensing freedom and then buy the hosted plan, which is a reasonable outcome but worth arriving at deliberately.
So what should you actually do?
Self-host one of these if running signing on your own infrastructure is a hard requirement, from data residency, an air-gapped environment, or a procurement position you do not control. That requirement is real and open source is the honest answer to it. Take the license question to counsel first. Our DocuSeal and Documenso comparison goes through that choice in detail.
Buy the hosted plan from one of them if you want the project's product without the infrastructure or the copyleft analysis.
Use a commercially licensed platform if what you need is signing embedded across many of your own customers' brands, and the license question needs to be closed rather than argued.
On that last case, our own position stated plainly so you can discount it appropriately: Verdocs is commercial, not open source. Our client SDKs are MIT licensed (npm), so the code you embed carries no copyleft obligation, and the API and SDKs ship 75+ web components that render in your own DOM. Pricing is per envelope rather than per seat, from $1,500 a year. We do not offer self-hosting. If that is your requirement, the table above is where to look and we are not on it.
Method, so you can check it
Everything above is reproducible in a few minutes:
- License, language, stars, and last commit:
GET https://api.github.com/repos/{owner}/{repo}for each project. - OpenSign's carve-outs:
GET https://api.github.com/repos/OpenSignLabs/OpenSign/license, which returns the LICENSE file itself rather than GitHub's guess at its name. - Hosted pricing: each vendor's own pricing page, linked above.
All figures read 2026-08-22. Projects ship and prices change; if a number here is stale or a project is missing, tell us and we will correct it.
