Open Core Model for AI Agents: Licenses and Dual Licensing

Open core is a business model where a company releases a basic version of its software as open source and sells proprietary add-ons, premium editions or a hosted service on top, as Wikipedia's open-core article describes it. For an AI agent, MCP server or skill, it lets you charge without alienating users if you keep what is already free, free, and charge for something new. The most common paths are open core (a free base plus paid pro features), a hosted version, paid support, and dual licensing (copyleft for the public, a commercial license for companies). Users get upset when something they relied on is taken away or quietly made worse. They rarely mind when you add a paid layer on top.

Your license choice shapes which of these paths are open to you. MIT and Apache-2.0 let anyone use your code commercially, including competitors. AGPL-3.0 requires people who modify it and offer it over a network to share their changes, which is why it pairs well with commercial licensing. This article explains each option and is part of our larger guide on how to sell AI agents, MCP servers and skills.

What are you selling if the code is open?

Code that is already public under an open-source license cannot be un-released. Anyone who has it can keep using it under that license. So you are not selling the existing code. You are selling one or more of these:

• New features that are not in the open version.
• Convenience: a hosted version, a one-click installer, a preconfigured bundle.
• Assurance: support, guaranteed fixes, security reviews, a stable release schedule.
• Different legal terms: a commercial license for companies that cannot accept copyleft obligations.

Pick the one your users already ask for. Issue threads and support questions are a good guide. If you publish developer tools, AgenticMart's developer tools page is one example of an open-source CLI sitting next to a hosted API.

How does the open core model work for an MCP server?

In an open-core model, the core stays open source and paid features live in a separate module, package or repo. Many listings in the MCP server directory are MIT or Apache 2.0, which is a common base for this. For an MCP server, the paid layer might be extra tools, integrations with enterprise systems, team management, audit logs or higher limits on a hosted version. For a skill collection, it might be a larger curated pack with tested scripts.

Where to draw the line

A useful rule: features an individual developer needs stay free; features a team or company needs can be paid. Things like single sign-on, shared configuration, audit logs and admin controls fit the paid side naturally. Core functionality, bug fixes and security fixes should stay in the open version.

Open core examples

• GitLab says on its stewardship page that it has an open core business model and earns almost all its revenue from subscriptions to paid tiers. It promises that a feature, once open source, will not move to a paid tier, and that the open codebase will have no artificial limits on repositories, users or size.
• MongoDB licensed its Community Server under AGPL-3.0, then moved releases from 16 October 2018 onward to the Server Side Public License, per MongoDB's SSPL FAQ.
• Elastic shipped free proprietary features alongside Apache-licensed Elasticsearch and Kibana, then changed the license of the open part (see the timeline below).
• HashiCorp licensed its products, including Terraform, under MPL 2.0 until its 2023 change to the Business Source License.

Relicensing timeline

Three well-known open core companies changed the license of their open part. Each change applied to future releases only.

Date	Company	Change	Primary source
16 October 2018	MongoDB	Community Server releases move from AGPL-3.0 to SSPL. MongoDB states the SSPL has not been approved by the OSI.	MongoDB SSPL FAQ
14 January 2021	Elastic	Elasticsearch and Kibana move from Apache 2.0 to a dual SSPL and Elastic License, from release 7.11.	Elastic licensing change
10 August 2023	HashiCorp	Future product releases move from MPL 2.0 to Business Source License 1.1; APIs, SDKs and almost all libraries stay MPL 2.0.	HashiCorp adopts BSL
20 September 2023	Linux Foundation	Announces OpenTofu, an open source successor to the MPL-licensed Terraform, in response to the BSL change.	Announcing OpenTofu
29 August 2024	Elastic	Adds AGPL as a third license option next to ELv2 and SSPL.	Elasticsearch is open source again

The lesson for agent and MCP server authors: a license change can be done, but users can fork the last open version, and someone may.

How not to alienate users

• Never remove features from the free version to push people to pay.
• Ship security fixes to the free version. Holding them back puts users at risk and damages trust fast.
• Announce the plan publicly before launching paid features. Explain what stays free.
• Keep contributions welcome. If contributors now help a paid product, say so plainly and update your contribution terms.
• Keep the free version useful. If it becomes a demo, people will fork it.

Which license should an open core agent use?

License	Type	Commercial use by others	Others can host it as a service without sharing changes	Explicit patent grant	Works for dual licensing
MIT	Permissive	Yes	Yes	No	Rarely useful
Apache-2.0	Permissive	Yes	Yes	Yes	Rarely useful
AGPL-3.0	Strong copyleft	Yes, under AGPL terms	No; modified network versions must offer source	Yes	Yes, the usual choice
Commercial	Proprietary	Only as your contract allows	Only as your contract allows	As your contract says	The paid half
BSL, ELv2, SSPL	Source-available, not open source	Restricted	Restricted	Varies	Sometimes

Here is how the main licenses work, in plain terms. Read the full texts at the Open Source Initiative and compare them at choosealicense.com.

MIT

The MIT License is short and permissive. Anyone can use, copy, modify, merge, publish, distribute, sublicense and sell the code, as long as they include the copyright and license notice. It has no explicit patent grant and no protection against someone hosting your code as a competing service.

Apache-2.0

The Apache License 2.0 is also permissive, but more detailed. It includes an explicit patent license from each contributor. That patent license ends for anyone who sues claiming the work infringes a patent. It also requires keeping copyright and NOTICE files and stating changes in modified files. Like MIT, it allows closed-source and commercial use, including hosting.

AGPL-3.0

The GNU Affero General Public License v3 is a strong copyleft license. Like the GPL, anyone distributing the code or a derivative must do so under the same license with source available. Its key addition (section 13) covers network use: if someone modifies the program and users interact with it remotely over a network, those users must be offered the modified source. This closes the gap where a company could run a modified version as a service without sharing changes. For a hosted MCP server or agent, that matters a lot.

Many companies have policies against using AGPL code. That is exactly why AGPL works well with dual licensing.

Commercial licenses

A commercial (proprietary) license is a contract you write. It can allow closed-source use, set seat or deployment limits, and include warranties or support terms. Get a lawyer to draft or review it.

Source-available licenses

Licenses such as the Business Source License or the Elastic License let people read the code but restrict some uses, often competing hosted offerings. They are not open source under the Open Source Definition, so call them source-available. Switching an established project to one of these has caused public backlash for some well-known projects, so weigh it carefully.

How does dual licensing work?

Dual licensing means offering the same code under two licenses. The usual pattern is AGPL-3.0 for everyone, plus a commercial license for companies that want to use it without AGPL obligations.

It only works if you have the right to relicense every line. That means:

• You wrote all of it, or
• Every contributor signed a contributor license agreement (CLA) or copyright assignment that lets you relicense their contributions.

A Developer Certificate of Origin (DCO) sign-off confirms a contributor has the right to submit code, but it does not by itself grant you the right to relicense. If you plan to dual license, set up a CLA early, before outside contributions pile up.

Contributor license agreements

A contributor license agreement is a document each outside contributor signs before their code is merged. Depending on its wording, it grants you a broad license to their contribution or assigns copyright to you. For open core and dual licensing, it is what lets you ship their code in a paid edition or under a commercial license.

Some contributors dislike CLAs for exactly that reason: their free work can end up in a product they cannot use for free. Wikipedia's open-core article notes this criticism. If you need a CLA, say why in your CONTRIBUTING file, and say what you promise in return, as GitLab does with its stewardship page.

Criticisms of open core

• It is not "really" open source. Many developers see the open part as a demo for the paid product, as noted in Wikipedia's open-core article.
• The incentive to hold back the free version. The company decides what goes in each edition, and every useful free feature is a feature that does not sell the paid one.
• CLAs can feel one-sided. Contributors give rights that the owner can use in proprietary code.
• Relicensing risk. The timeline above shows that the license on the open part can change for future releases, and that users and distributions react.

Pros and cons of open core

Pros	Cons
Free users find, test and trust the code before paying	Constant tension over what is free and what is paid
Contributors improve the core	Needs a CLA if contributions go into paid editions
Clear upgrade path for teams and companies	Competitors can host a permissively licensed core
Security fixes reach everyone through the open core	Users may fork if they feel the free version is being starved

Changing your license

You can change the license for future versions of code you own. You cannot take back the license on versions already released. Users can keep using, and forking, the last version under the old terms.

If you move from MIT to AGPL or to a source-available license, expect some users to fork the last permissive version. Communicate early, explain why, and make sure the new license still serves the people who got you here. This is not legal advice; for a license change on an established project, talk to a lawyer.

Other paid paths that keep the code open

• Hosted version. Keep the server fully open and charge for running it for people. Many teams will pay to skip setup and maintenance. Note that a permissive license lets others host it too.
• Paid support. Response-time guarantees, private channels, help with deployment.
• Sponsorships. GitHub Sponsors tiers with clear benefits.
• Paid bundles. The same open code, packaged with tested configs, extra docs and setup scripts, sold as a download.

Pricing these options is covered in pricing AI agents and MCP servers.

Keep trust high during the switch

When money enters the picture, users look more carefully at what your code does. Make your security posture visible: declare permissions and network access, keep dependencies patched, and publish scan results. The AI agent security checklist shows what careful users check.

If your open-source repo was imported into a marketplace, claim it so you control the listing. On AgenticMart, maintainers with admin or maintain permission can claim an imported listing by signing in with GitHub. Any listing can get a free automated scan; each listing page shows whether it has one. A scan is a malware and risk check, not a safety guarantee. Paid selling is not open yet; the planned platform fee is 12%.

FAQ

Can I sell code that is MIT licensed?

Yes. MIT allows selling, and so do Apache-2.0 and AGPL-3.0. The catch with MIT is that anyone else can also sell or host your code. So most MIT projects charge for something extra, like hosting, support or pro features.

Is AGPL a good choice for a paid MCP server?

It can be, especially for hosted servers. AGPL requires anyone who runs a modified version as a network service to share their changes, which discourages closed competing services. It also lets you sell commercial licenses to companies that avoid AGPL, provided you own all the rights to the code.

What is the open core model?

Open core is a business model where the basic version of the software is open source and the company sells proprietary add-ons, premium editions or a hosted service. GitLab is a well-known example and describes itself that way.

What are examples of open core companies?

GitLab, MongoDB, Elastic and HashiCorp are commonly cited. MongoDB, Elastic and HashiCorp later moved their open part to source-available licenses, and Elastic added AGPL as an option in 2024.

Do I need a CLA for open core?

Only if outside contributions will go into a paid edition or be sold under a commercial license. If paid features are entirely your own code in a separate module, you may not need one. Get legal advice for your case.

Will users be upset if I start charging?

Some may be, but most accept it if nothing they already use is taken away. Keep the free version useful, keep security fixes free, and explain the plan in public before you launch. Charge for new value, not for things that used to be free.