The reason a team starts looking for an open source form builder is rarely ideology. It is usually a monthly bill that grew with response volume, a security review that asked where the data sits, or a limit that arrived at the worst possible moment. Somebody says the word self hosted, the room nods, and the search begins.
The search is worth doing. It is also worth doing with clear eyes, because the phrase covers at least three different arrangements with very different consequences. Some of these projects hand over the whole application under a copyleft licence. Some hand over most of it and keep a directory back. One of them uses a licence whose own website has a section titled "Why not Open Source?". And in every case, the part of the job that eats the most time later is the part that happens after a form is submitted, which no licence file has anything to say about.
What the phrase means once the LICENSE file is open
Four projects come up repeatedly in this search, and all four describe themselves as open source on their marketing pages. The licence files tell a more specific story.
LimeSurvey Community Edition is the plainest case. Its licence file states the GNU General Public License, version 2 or any later version, with no carve outs. What is published is what runs.
OpnForm places everything under AGPLv3 except one directory. Its licence file names api/app/Enterprise as carrying a separate licence of its own, and puts the rest under the AGPLv3 text that follows.
Formbricks uses the same pattern with more moving parts. Its licence file puts content under apps/web/modules/ee on a separate enterprise licence, marks the JavaScript, Android, iOS and API client packages as MIT, and puts everything outside those boundaries under AGPLv3.
Typebot is the one that does not fit the category. Its licence file is the Functional Source License 1.1 with an Apache 2.0 future licence. The FSL website describes it as a Fair Source licence that converts to Apache 2.0 or MIT after two years, and answers the question of why it is not open source by arguing that open source does not protect against free riding. Running it is permitted. Calling it open source is not accurate, and a procurement team that checks will notice.
None of this makes any of them a bad choice. It does change what a legal review will conclude, and it changes whether the enterprise features shown in a demo are actually in the code that gets cloned.
The AGPL question that comes up in review
AGPLv3 is a network copyleft licence. A team running a modified copy as an internal tool for staff is on well travelled ground. A team that modifies it and puts it in front of external users is in the territory the licence was written for, and someone should read the text rather than a summary of it. This is a five minute conversation if it happens early and a three week one if it happens after launch.
The bill changes shape rather than disappearing
The licence costs nothing. The rest of it is a list.
A server, or a container platform. A database with a backup schedule that has actually been restored from at least once. A TLS certificate that renews without anyone remembering it. Object storage if the forms accept file uploads, because storing uploads on the application disk works until the disk is full. A transactional email provider, because sending from the box itself lands in spam. Monitoring that notices when the form page returns a 500, ideally before the person collecting applications does. And upgrades, which for these projects arrive regularly and include database migrations.
Set against that, the hosted price for the same category is a known number. Formbricks Cloud lists a free Hobby plan with one workspace and 250 responses per month, Pro at $74 per month with three workspaces and 2,000 responses per month, and Scale at $325 per month with five workspaces and 5,000 responses per month. Typebot lists a free Personal plan with unlimited bots and 200 chats per month, Starter at $39 per month with two seats and 2,000 chats per month, and Pro at $89 per month with five seats and 10,000 chats per month.
The honest comparison is not the licence fee against zero. It is the hosted plan against the infrastructure bill plus the hours. Half a day a month of engineering attention is worth more than most of these plans cost. The decision is genuinely close, and it turns on whether the constraint pushing the team toward self hosting is money or something that money cannot fix, such as a requirement that data never leaves a particular jurisdiction or a particular network.
Four projects, side by side
| Project | Licence of the main code | Separate directory | Hosted free tier | Hosted paid entry |
|---|---|---|---|---|
| LimeSurvey Community Edition | GPL v2 or later | None | Hosted plans sold separately | Priced per plan on the site |
| OpnForm | AGPLv3 | api/app/Enterprise |
Unlimited forms and submissions, one workspace, branding shown | Paid tiers remove branding |
| Formbricks | AGPLv3 | apps/web/modules/ee |
250 responses per month, one workspace | $74 per month |
| Typebot | FSL 1.1, Apache 2.0 future licence | None | 200 chats per month | $39 per month |
Two things fall out of this table. The free hosted tiers are metered differently in each case, so a volume comparison between them is close to meaningless until the unit is fixed. And the projects that keep a directory back are the ones whose paid features tend to be the ones a growing team asks for, such as roles, audit logs and single sign on. Self hosting those projects means self hosting the part without those features, unless a commercial licence is bought on top.
Email is where self hosted forms actually break
The form renders. The submission saves. The confirmation email goes to spam, and nobody finds out for two weeks because the people who did not get it simply assume the submission failed and send it again.
Outbound mail is the single most common failure in a self hosted form deployment, and it has nothing to do with the form software. It is SPF, DKIM and DMARC records that have to be right on the sending domain, a sending IP with no history behind it, and a bounce handling path that somebody reads. Most teams solve this by pointing the application at a transactional email provider instead of sending directly, which is the correct move and which reintroduces a monthly bill and an external dependency into the architecture that was chosen to avoid both.
Worth checking before committing: whether the project sends the auto reply to the respondent at all, or only a notification to the team. Those are different features. A respondent who gets no acknowledgement will email to ask whether the form worked, and that email arrives in a different inbox than the one holding the submissions.
Uploads, spam, and the upgrade that keeps getting postponed
File uploads change the operational picture more than most teams expect. A CV or a portfolio attachment means storage that grows, a retention policy that somebody has to decide, and an access rule that stops the file being downloadable by anyone who guesses the URL. Predictable file paths on a public bucket are a recurring finding in security reviews of self hosted form deployments.
Spam arrives within days of a public form going live. Every project here offers some combination of a honeypot field, a captcha, or rate limiting, and each of those has a cost in completion rate. A captcha in front of a job application form filters out bots and also filters out some applicants on slow connections.
Upgrades are the quiet one. These are active projects with frequent releases, and security fixes land in them. A deployment that is nine months behind is not saving money. It is deferring a migration that will be larger and riskier when it finally happens, and it is running known issues in public. Whoever owns the deployment needs a recurring slot for this, not an intention.
The part no licence file covers
Everything above concerns getting the form up and keeping it there. The work that actually consumes a team's week starts one second after submit.
A response arrives. Someone has to own it. It has a state, which changes as it moves from new to reviewed to replied to closed. Two people must not reply to the same applicant, and nobody must be left waiting because each person assumed the other had it. When the same person submits twice, that should be visible. When a colleague asks what happened with a submission from last month, the answer should be on one screen rather than reconstructed from a spreadsheet and a search of a shared mailbox.
Most form projects, open source and commercial alike, are built around collection. They produce a table of responses and a CSV export, and the reply happens somewhere else, usually in email. That handoff is where the work leaks out. A team of four handling thirty applications a month can hold the state in their heads. The same team at three hundred a month cannot, and the fix they reach for is a spreadsheet that tracks the responses alongside the tool that holds them, which is two sources of truth and an argument waiting to happen.
Before choosing on licence terms, it is worth writing down what the team does with a response after it arrives, and checking that list against the shortlist. A tool that covers collection and the reply on one screen removes the spreadsheet rather than adding to it, and the use cases that come up most often, hiring, event sign ups and enquiry handling, all share the same shape: the form is the small part.
When self hosting is the right answer
It is the right answer when the requirement is categorical rather than financial. Data that cannot leave a jurisdiction or a private network. An air gapped environment. A regulator who wants to see the servers. A research context where the questionnaire logic itself needs modification. In those cases the infrastructure work is not overhead, it is the requirement, and the licence terms decide which projects are even eligible.
It is the wrong answer when the driver is the monthly price and there is nobody whose job description includes keeping it running. A form deployment with no owner degrades quietly. The failure mode is not a loud outage, it is a confirmation email that stopped sending three weeks ago, and the cost of that is measured in applicants who went elsewhere.
What to change first
Open the licence file of whichever project is currently in front of the team, and find out whether the features shown in the demo are in the code that would be cloned. That single check settles more of this decision than any feature comparison. Then write down what happens to a response after it lands, and if that list has more than three steps, weigh the self hosting question against a tool that already covers those steps, such as Halict, before committing to run one.
Q1. Is an open source form builder actually free?
The software licence costs nothing. Running it costs a server, a database with working backups, object storage for any file uploads, a transactional email provider so that confirmations are delivered, and recurring time for upgrades. Compare that total against a hosted plan rather than against zero, because the close calls usually turn on the hours rather than the infrastructure bill.
Q2. Which of these projects is under a genuine open source licence?
LimeSurvey Community Edition is GPL v2 or later with no carve outs. OpnForm and Formbricks both use AGPLv3 for the main body of code while keeping one directory under a separate enterprise licence. Typebot uses the Functional Source License 1.1, which its own website describes as Fair Source rather than open source, and which converts to Apache 2.0 or MIT after two years.
Q3. Does AGPLv3 mean the code has to be published?
The AGPL is a network copyleft licence, and its obligations are triggered by modifying the software and making it available to users over a network. Running an unmodified copy internally is a different situation from running a modified copy in front of external users. This is worth a short conversation with whoever handles legal review before the deployment happens, not after.
Q4. Why do self hosted form confirmations end up in spam?
Because the deliverability problem belongs to the sending domain, not to the form software. Mail sent directly from a new server with no SPF, DKIM or DMARC alignment and no sending reputation is treated as suspicious by receiving providers. Pointing the application at a transactional email provider and setting the DNS records correctly is the usual fix, and it reintroduces a monthly cost.
Q5. What is the strongest argument against self hosting a form tool?
That nobody owns it. The infrastructure work is manageable when it is somebody's job and invisible when it is not, and the invisible failures are the expensive ones. If no name can be put against the deployment for the next twelve months, the monthly price of a hosted tool is usually the cheaper option once the first missing confirmation email is counted.