When a company says "open source," it can mean many things. Some mean "you can read the code but not use it commercially" (source available). Some mean "the core is open but the useful parts are proprietary" (open core). Some mean "it's open until we change the license" (the Elastic/HashiCorp model). Some mean "it's open but you need our proprietary runtime to actually use it" (the MongoDB Atlas model).
We mean MIT. No asterisks. No footnotes. No future license change clauses. Here's what that means concretely, why we chose it over every alternative, and why we believe any company that paywalls MCP servers is making a strategic mistake.
What MIT means for you
Use it commercially. Build a product on top of our MCP servers. Sell it. Charge your customers. No attribution required beyond keeping the license file. No revenue sharing. No usage caps. No "community edition" limitations. No phone-home telemetry. The MIT license is 171 words long and says, in essence: do whatever you want, just don't sue us.
Fork it. Copy the entire repo. Modify it. Publish your own version under a different name. Build a competing product. We genuinely encourage this. Every fork that improves on our work makes the ecosystem better. Every competitor that uses our MCP servers as a foundation validates the protocol choice and the market opportunity.
Bundle it. Include our MCP servers in your proprietary product. Ship them to your customers. Embed them in your SaaS platform. No copyleft obligations. No requirement to open-source your own code. No AGPL-style "network use is distribution" clause. No SSPL-style "if you offer this as a service you must open source your entire stack" trap.
Depend on it. Build your agent infrastructure on our MCP servers without worrying that we'll pull the rug. The license is irrevocable. Once code is published under MIT, that specific version remains MIT forever. Even if we (hypothetically) changed the license for future versions, every version published under MIT stays MIT. That's how the law works, and it's why MIT is the gold standard for dependable infrastructure.
The open-core vs open-source debate: why we chose fully open MIT
The standard playbook for VC-backed infrastructure companies is open core: open source the engine, paywall the enterprise features. MongoDB open-sourced the database but kept MongoDB Atlas (the managed service) and advanced features (encryption at rest, LDAP auth, automated backups) proprietary. Elastic open-sourced Elasticsearch but kept machine learning features, security, and alerting behind a commercial license. HashiCorp open-sourced Terraform but kept Sentinel policy engine, cost estimation, and team management proprietary.
Open core works. It built multiple billion-dollar companies. But it has a structural flaw: the boundary between "open" and "core" is a constant source of tension. And that tension, left unresolved, eventually destroys the thing that made the project successful in the first place: community trust.
The boundary problem
In an open-core model, every feature decision is a licensing decision. Should this new capability go in the open source version or the commercial version? If you put too much in open source, you cannibalize revenue. If you put too much behind the paywall, you slow adoption and alienate the community.
This tension is not theoretical. It destroyed trust in multiple companies. And understanding exactly how is essential context for why we chose differently.
The license wars: what we learned from four cautionary tales
Between 2018 and 2024, four of the most prominent open-source infrastructure companies changed their licenses. Each followed the same playbook. Each suffered the same consequences. Each offers a lesson we internalized before writing a single line of code.
Elasticsearch → OpenSearch (2021): the fork that won
Elastic changed Elasticsearch's license from Apache 2.0 to SSPL (Server Side Public License), a license specifically designed to prevent cloud providers from offering Elasticsearch as a managed service. The stated reason: AWS was offering Elasticsearch as a managed service without contributing back. The SSPL's key clause requires anyone offering the software "as a service" to open-source their entire stack — not just the modified software, but the management tools, monitoring infrastructure, deployment automation, everything. It was designed to be so onerous that no cloud provider would comply.
The community response was swift and devastating. Amazon forked Elasticsearch as OpenSearch under Apache 2.0. Within 18 months, OpenSearch had more contributors than the original project. Elastic's stock dropped 8% on the announcement day. Five years later, developers still cite the license change as a reason to choose OpenSearch over Elasticsearch.
SSPL is the most aggressive copyleft license in production use. Unlike AGPL (which only requires you to share modifications to the AGPL-covered software), SSPL requires you to share the source code of your entire service stack if you offer the software as a service. For any SaaS company, this is a non-starter. Legal teams flag SSPL as "do not use" by default. This is why SSPL is not approved by the OSI as an open-source license. It's source-available, not open source.
MongoDB → SSPL (2018): the pioneer of the bait-and-switch
MongoDB switched from AGPL to SSPL for the same reason — preventing cloud providers from offering MongoDB as a managed service. MongoDB was the first major project to use SSPL, and the license was written by MongoDB's own legal team. The difference from Elastic: MongoDB had already IPO'd and had the market power to absorb the backlash. They could afford to alienate parts of the community because enterprise contracts provided revenue stability.
But the damage was real. Several Linux distributions dropped MongoDB from their default repositories. The Open Source Initiative explicitly rejected SSPL as an open-source license. Developers who had evangelized MongoDB as "the open-source alternative" felt betrayed. The company survived — but the trust never fully recovered. MongoDB went from "beloved by developers" to "tolerated by enterprises." That's a meaningful shift for any infrastructure company.
HashiCorp → BSL (2023): the Linux Foundation responds
HashiCorp changed Terraform's license from MPL 2.0 to BSL (Business Source License). BSL is subtler than SSPL: it allows most uses, but prohibits offering the software as a competitive service. The community forked it as OpenTofu, which became a Linux Foundation project within weeks. HashiCorp was subsequently acquired by IBM for $6.4 billion — but the Terraform community fractured irreversibly. The fork attracted contributions from every major cloud provider and became the default recommendation in infrastructure-as-code communities.
The BSL is particularly instructive because it represents the "moderate" approach to license restriction. It's not as aggressive as SSPL. It includes a conversion clause (the code becomes open source after a time period, usually 4 years). It's designed to be reasonable. And it still caused a fork, a community fracture, and permanent trust erosion.
Redis → dual RSALv2/SSPL (2024): the community has learned
Redis Labs changed Redis's license from BSD to a dual RSALv2/SSPL license, restricting commercial use by cloud providers. By 2024, the community response was almost mechanical. Linux Foundation supported Valkey, a community fork, within weeks. AWS, Google, Oracle, and Ericsson backed it immediately. The playbook was established: change the license, lose the community, watch the fork absorb your developer mindshare.
Every license change follows the same pattern: company grows on open source goodwill, gets scared of cloud providers, changes license, community forks the project, trust is permanently destroyed. We are choosing not to enter this cycle.
The copyleft spectrum: why each alternative fails for MCP servers
Understanding why we chose MIT requires understanding what we rejected and why. The license landscape is a spectrum from permissive to restrictive, and each point on the spectrum carries different risks for both the publisher and the user.
Why not AGPL? AGPL adds a "network use is distribution" clause to GPL. If you modify AGPL software and offer it as a web service, you must share your modifications. For MCP servers that run as services in agent infrastructure, this means every company that customizes a server would be forced to open-source their modifications. Legal teams at enterprises flag AGPL as "requires VP-level approval" or "do not use." We want enterprises to adopt our servers without friction, not route them through legal review.
Why not GPL? GPL requires any "derivative work" to also be GPL-licensed. An MCP server running inside a proprietary agent framework could trigger copyleft obligations for the entire application, depending on how tightly integrated the components are. The definition of "derivative work" is ambiguous enough that risk-averse companies avoid GPL entirely. We need risk-averse companies to use our servers — they're our enterprise pipeline.
Why not SSPL? SSPL is a poison pill disguised as open source. It requires anyone offering the software "as a service" to open-source their entire stack — management software, monitoring, deployment tools, everything. No SaaS company can comply with this. SSPL-licensed software is effectively proprietary for any company that runs services. The OSI doesn't recognize it as open source. We would be lying if we called SSPL-licensed code "open source."
Why not BSL? BSL prohibits competitive use until the code converts to open source (typically after 4 years). It's the "reasonable restriction" approach. But as HashiCorp proved, even reasonable restrictions cause community fractures. And BSL has a deeper problem: it signals that you're afraid of competition. If your moat requires a license to protect it, it's not a moat.
Why MIT, specifically? MIT is the most permissive widely-used license. It has no copyleft, no service clause, no competitive-use restriction, no requirement to share modifications. It is approved by the OSI. It is understood by every legal team on earth. It is 171 words long. There is no ambiguity, no edge case, no "but what if" scenario that causes legal hesitation. When a developer evaluates a dependency, MIT is the license that gets an instant "approved." Everything else requires a conversation.
The moat paradox: open source as wedge, not moat
VCs often ask: "If the MCP servers are open source, what's your moat?"
The question reveals a misunderstanding of where value accrues in infrastructure markets. The MCP servers are the wedge, not the moat. They are the distribution mechanism that gets us into developer workflows. The moat is everything above them.
Let me illustrate with the most relevant analogy in fintech history.
The "Stripe for agents" analogy
Stripe did not build payment rails. Visa, Mastercard, ACH, and SEPA existed long before Stripe. The payment rails are open infrastructure (or at least, accessible infrastructure). Stripe's moat is not the rails. It's the developer experience built on top of them: the API design, the documentation, the dashboard, the fraud detection, the compliance handling, the global payment method coverage, the Connect marketplace platform. Stripe made $14 billion in revenue in 2023 without owning a single payment rail.
CodeSpar doesn't own the APIs. Asaas owns its payment API. Nuvem Fiscal owns its fiscal API. Melhor Envio owns its shipping API. We don't own any of them. We build the agent layer on top — the same way Stripe built developer experience on top of payment rails it didn't own.
Our MCP servers are the rails. Open, MIT-licensed, commoditizable. The moat is everything above them:
The servers (Layer 0) are the wedge. They get developers in the door. Layers 2-5 are the business. This is not an original insight — it's the Red Hat model, the Databricks model, the HashiCorp model (before they broke trust by changing the license). Open source the infrastructure, monetize the managed experience.
The difference in our case: we commit to never moving the boundary. The servers stay at Layer 0, MIT licensed, forever. We don't need to paywall them because the layers above them are valuable enough to build a business on.
Where the real moat lives
A moat is something a competitor cannot easily replicate. Let's evaluate each layer:
MCP servers (Layer 0): no moat. An MCP server for Asaas is a wrapper around the Asaas REST API with error handling, auth management, and tool descriptions. A competent developer can build one in a week. If we paywall our servers, competitors will build free alternatives. The servers are commoditizable by definition.
SDK (Layer 1): shallow moat. The SDK is more complex than individual servers — meta tool routing, session management, framework adapters — but it's still replicable. The moat here is developer familiarity and ecosystem integration, not technical complexity.
Managed hosting + orchestration (Layers 2-3): deep moat. Running 50+ MCP servers at scale, with intelligent routing, cost optimization, compliance enforcement, and 99.9% SLA is operationally expensive and technically non-trivial. This is where Stripe's analogy is most precise: the operational excellence of managed infrastructure is hard to replicate and impossible to fork.
Dashboard + enterprise (Layers 4-5): deepest moat. Product surface area, customer relationships, compliance certifications, SLA commitments, and domain-specific intelligence (e.g., knowing that Brazilian NF-e requires CNPJ validation before issuance). These are compounding assets that get more valuable with time and usage. No fork can replicate them.
The moat paradox: the thing we give away for free is the thing that makes everything else valuable. Restrict it, and you weaken the entire stack. Open it wider, and you strengthen the business.
Why we will never paywall MCP servers
This is not a philosophical position. It's a strategic one, grounded in how we understand our market and where revenue should come from.
MCP servers are the distribution mechanism, not the revenue mechanism. Our MCP servers are how developers discover CodeSpar. A developer building an AI agent for a Brazilian e-commerce company searches npm for "mcp pix" and finds @codespar/mcp-asaas. They install it, use it, and it works. They discover that CodeSpar has 50 more servers. They install the SDK. They try the meta tool layer. They upgrade to managed hosting because they don't want to run MCP servers in their own infrastructure. That's the funnel. Paywalling the servers would be like Stripe charging developers to read their API documentation.
Open MCP servers create network effects that proprietary servers cannot. When a developer uses our MCP server for Asaas, they file bug reports, contribute error code mappings, and share edge cases they encountered in production. This makes the server better for everyone. If the server were proprietary, that feedback loop would be limited to paying customers — a fraction of the developer population. Open source maximizes the feedback surface area.
Trust is a compounding asset; distrust is a compounding liability. Every month that passes with our servers remaining MIT-licensed builds trust. Developers tell other developers. Blog posts cite us as the "truly open" alternative. Conference talks mention our licensing commitment. This trust compounds over years. A single license change would reverse all of it — not gradually, but instantly and permanently, as every cautionary tale above demonstrates.
Paywalling creates an incentive for competitors to undercut you. If we charged for MCP servers, the most predictable response would be: a competitor open-sources free alternatives, captures our developer mindshare, and builds their own managed platform on top. We would be funding our competitor's distribution strategy. By making the servers free and open from day one, we remove the economic incentive for this attack vector entirely.
Open source servers are the distribution. The managed platform is the business. Restricting distribution to protect the business is backwards.
The business model: managed hosting, orchestration, billing
Let us be precise about how CodeSpar makes money, because the "if the servers are free, where's the revenue?" question deserves a concrete answer.
The revenue comes from three sources. None of them involve charging for MCP servers.
1. Managed hosting
Developers install our MCP servers from npm and run them locally during development. When they move to production, they face operational complexity: running 5-15 MCP servers as persistent processes, handling auth token rotation, monitoring uptime, scaling under load, managing environment variables across staging and production. Managed hosting eliminates all of this. We run the servers. They call the API.
This is the same conversion path that drives revenue for every open-source infrastructure company. Redis is free. Redis Cloud is not. PostgreSQL is free. Amazon RDS is not. Kubernetes is free. GKE/EKS is not. The pattern works because the operational burden of running infrastructure at scale is genuinely painful, and paying someone else to do it is genuinely valuable.
2. Orchestration SDK
The SDK is MIT-licensed and free. But the orchestration features that run on our infrastructure are not: BACR scoring (which routes tool calls to the optimal server based on cost, latency, and reliability), PolicyEngine (which enforces compliance rules before transactions execute), MandateGenerator (which produces legally compliant fiscal documents), and smart routing across multiple providers for the same API category. These features require server-side computation, proprietary data models, and continuous updates as regulations change. They're valuable enough that companies pay for them willingly.
3. Billing infrastructure
When an AI agent processes a Pix payment or generates a fiscal document, someone needs to track usage, calculate costs, generate invoices, and handle settlements. Our billing layer does this automatically. It's metered, transparent, and integrated with the dashboard. For companies running agents that process thousands of transactions, the billing infrastructure is a requirement, not an optional upgrade.
The math works. Not because we're being altruistic with open source. Because open source is the economically optimal distribution strategy for developer infrastructure in a market where no one has heard of us yet.
Composio comparison: open-core vs. fully open
Composio is the closest comparable in the MCP tooling space, so the comparison is worth making explicit. They offer MCP servers and tool integrations for AI agents. We respect what they've built. But our licensing strategies are fundamentally different, and that difference has strategic implications.
Composio is open-core. Their GitHub repo is open source, but the managed platform has usage tiers. The free tier is limited — rate-limited API calls, capped connections, restricted server counts. To unlock full capability, you pay. The open-source version is functional but deliberately constrained to drive upgrades.
CodeSpar is fully open. Every MCP server, every tool, every error code mapping — MIT licensed, no restrictions. No rate limits on the open-source servers. No feature flags that degrade after a trial period. No telemetry that phones home. The open-source version is the full version. The managed platform is a separate product that adds operational convenience, not a gated upgrade of the same product.
The distinction matters because it changes the developer's calculus. With open-core, a developer evaluates the free tier and mentally maps the upgrade path: "I can use this for prototyping, but production will cost X." The open-source version is a demo. With fully open, a developer evaluates the complete product: "I can use this in production, forever, for free. If I want managed hosting, that's an additional service." The open-source version is the product. The managed platform is a service built on top of it.
Both strategies can work. But in a market where trust and developer adoption are the primary competitive assets, we believe fully open wins. Developers who feel constrained by a free tier don't become advocates. Developers who use a genuinely free product and choose to pay for managed services become evangelists.
Strong opinion: any company that paywalls MCP servers is making a mistake
This is a strong opinion, held with conviction and open to revision by evidence. But here's the argument:
MCP servers are wrappers around existing APIs. They translate REST endpoints into tool interfaces that AI models can call. The technical complexity is real (error normalization, auth management, input validation, tool descriptions optimized for model comprehension) but not prohibitive. A competent team can build a production-quality MCP server in 1-2 weeks.
This means MCP servers are inherently commoditizable. If you charge for them, you create an arbitrage opportunity for anyone willing to build the same thing for free. The only scenario where paywalling works is if you have a monopoly on domain knowledge — which, in the age of API documentation and AI-assisted code generation, is increasingly unlikely.
The companies that will win the MCP infrastructure market are the ones that give away the servers and monetize the orchestration, hosting, and intelligence layers above them. This is not a prediction. It's the same pattern that played out in databases (MySQL/PostgreSQL free, managed hosting paid), containers (Docker/Kubernetes free, orchestration paid), and developer tools (VS Code free, GitHub Copilot paid). The infrastructure layer commoditizes. The experience layer monetizes.
Any company that paywalls MCP servers is building a moat out of sand. The tide of open source will wash it away. Build the moat higher up the stack, where the value compounds and the competition can't follow.
What stays proprietary
We're transparent about what's open and what isn't. No ambiguity. No "open source but also check the license addendum."
| Layer | License | Why |
|---|---|---|
| All MCP servers | MIT | Maximum adoption, standard infrastructure |
| @codespar/sdk | MIT | SDK should be as frictionless as the servers |
| Dashboard | Proprietary | Product differentiation, managed experience |
| Enterprise packages | Commercial | PolicyEngine, MandateGenerator, PaymentGateway |
| Managed hosting | SaaS | The business model |
The pattern is deliberate. Everything that touches the developer's code is MIT: the servers, the SDK, the type definitions, the CLI tools. Everything that runs on our infrastructure is proprietary: the hosting, the routing, the compliance engine, the dashboard. The boundary is clear, permanent, and aligned with how developers evaluate technology risk.
A developer's worst nightmare is building on open source infrastructure that gets pulled out from under them. Our architecture makes that impossible. Even if CodeSpar ceased to exist tomorrow, every MCP server and every SDK version published under MIT would remain available on npm, forkable, usable, forever. Your agent code doesn't break. Your integration doesn't break. You lose managed hosting and the dashboard. You keep the infrastructure.
Competitive analysis: who else is building commerce MCP servers?
Nobody. That's the point.
The MCP ecosystem has over 5,800 servers as of April 2026 (per the MCP Server Registry). The vast majority cover developer tools (GitHub, Jira, Slack, databases), data sources (web scraping, PDF parsing, knowledge bases), and AI utilities (image generation, embedding, RAG pipelines). Commerce coverage is essentially zero.
Search the MCP registry for "Pix": 0 results. Search for "CFDI": 0 results. Search for "boleto": 0 results. Search for "Melhor Envio": 0 results. Search for "NF-e": 0 results. Search for any LatAm commercial API: 0 results.
This is not because the market is small. Brazil alone processes over R$17 trillion in Pix transactions annually. Mexico's e-commerce market exceeds $40 billion. The combined addressable market for commerce infrastructure in LatAm is massive. The gap exists because building commerce MCP servers requires deep domain knowledge of LatAm financial systems, tax regulations, and payment ecosystems — knowledge that doesn't exist in Silicon Valley and isn't documented in English.
The "Finance" category is instructive. There are MCP servers for QuickBooks, Xero, and Plaid — all US/European-focused fintech APIs with English documentation and standard OAuth flows. There are zero servers for Asaas, Zoop, PagSeguro, Cielo, or any Brazilian payment provider. Zero for FacturAPI, Conekta, or any Mexican provider. Zero for Wompi, AFIP, or any South American provider.
This vacuum is our opportunity. By open-sourcing the entire catalog, we're making a bet: the first company to establish the standard MCP servers for LatAm commerce wins the developer mindshare. And developer mindshare, in infrastructure markets, is the most durable competitive advantage.
Stripe built DX on rails it didn't own. We're doing the same.
Before Stripe, accepting online payments required a merchant account, a payment gateway contract, PCI compliance certification, and weeks of integration work. Stripe reduced that to 7 lines of code and a 5-minute signup. The payment rails existed. Stripe made them accessible.
Before CodeSpar, making an AI agent process a Pix payment required understanding the Asaas API, implementing OAuth, handling error codes, managing webhooks, and building the tool interface for the AI model. CodeSpar reduces that to:
Stripe made payments accessible to developers. We're making LatAm commerce accessible to AI agents. The open source MCP servers are the foundation — the "payment rails" of the analogy. The SDK, the managed hosting, and the orchestration layer are the developer experience — the "Stripe" of the analogy.
And just as Stripe never charged developers to access the payment rails (Visa and Mastercard do that), we will never charge developers to access the commerce APIs (Asaas and Nuvem Fiscal do that). We charge for the layer above: the experience, the orchestration, the managed operations.
Community strategy: contributors, not just users
Open source projects fail when they attract users but not contributors. Users consume value. Contributors create it. The difference between a sustainable open-source project and an abandoned one is the ratio of contributors to users. Our community strategy is designed to maximize that ratio through three mechanisms.
1. Low-friction contribution paths
The most common contribution is an error code mapping. A developer encounters an error in production that our server doesn't handle well. They open an issue with the error code, the provider response, and the expected behavior. We add it to the error normalization table in less than a day. This is a 5-minute contribution from the developer and a 30-minute fix from us, but it improves the server for every future user. We've received over 80 error code contributions since January 2026.
The key insight: contributions don't need to be code. Error reports, tool description improvements, and API behavior documentation are contributions that require domain knowledge, not engineering skill. A payment operations manager who knows that Asaas returns error code 422-INSUFFICIENT_BALANCE when the sub-account has insufficient funds (not the main account, as the error message implies) is contributing knowledge that no engineer outside that company would discover independently.
2. Country expansion as community contribution
We can't have deep domain knowledge of every country's commercial API landscape. But developers in those countries do. Our contribution guide includes a "Country Expansion Playbook" that walks developers through the process of proposing, designing, and building MCP servers for their local APIs. The Mexico servers were bootstrapped by a contributor in Monterrey who knew the CFDI system inside-out. The Argentina AFIP server was built by a developer in Buenos Aires who had spent years integrating with AFIP's WSAA authentication system.
This is where open source becomes a geographic expansion strategy, not just a distribution one. Each country's commerce ecosystem is a distinct domain. LatAm has 20+ countries, each with its own payment providers, fiscal authorities, and regulatory requirements. No single company can build expertise in all of them. But a community of developers, each contributing knowledge of their local ecosystem, can cover the continent in a way that no proprietary company could replicate.
3. Transparent roadmap driven by demand
Our roadmap is our GitHub Issues page, sorted by upvotes. The most-requested servers get built first. The most-reported bugs get fixed first. This isn't agile theater — it's the actual mechanism by which we decide what to build next. Developers see their requests turn into shipped code within weeks. That builds trust and converts users into advocates.
Transparency about what we're building next, why, and when serves a dual purpose: it gives contributors visibility into where their work fits, and it gives potential users confidence that the project is actively maintained and responsive to community needs.
23 external contributors across 4 countries. 80+ error code contributions. 12 tool description improvements. 3 complete server implementations from community contributors (AFIP, Tienda Nube, Colppy). 147 GitHub stars. Not huge numbers. But for a project that's been public for 3 months, in a niche market (LatAm commerce MCP), with zero marketing budget, it's meaningful traction.
The economics of open source MCP servers
Let's be direct about the business math because VCs ask and developers deserve transparency.
Building and maintaining 50+ MCP servers costs approximately $180,000/year in engineering time (2 full-time engineers focused on the catalog). That's the investment. The return comes from three channels:
1. Developer acquisition cost: effectively $0. Every npm install of a CodeSpar MCP server is a zero-cost developer touchpoint. No Google Ads, no conference sponsorships, no content marketing campaigns. The servers themselves are the marketing. A developer who installs @codespar/mcp-asaas has self-qualified as someone building AI agents for Brazilian commerce — our exact target customer. Traditional developer tool companies spend $50-200 to acquire a developer lead through paid channels. Our CAC for developers who find us through npm is $0.
2. Conversion to managed hosting. Of developers who install the SDK, approximately 15% upgrade to managed hosting within 60 days. They start by running MCP servers locally, hit scaling or reliability issues, and switch to our hosted infrastructure. At our current pricing ($49/mo for indie developers, $199/mo for teams, custom for enterprise), the unit economics work. The $180K/year catalog investment pays for itself when 30 teams are on paid plans.
3. Enterprise pipeline generation. Every enterprise deal we've closed started with an engineer at the company using our open source MCP servers. They built a prototype, showed it to their manager, and the company entered an enterprise conversation with us. The MCP servers are the wedge that gets CodeSpar into the evaluation process. The enterprise deal (PolicyEngine, MandateGenerator, dedicated hosting, SLA) is where the revenue lives.
The math works. Not because we're being altruistic with open source. Because open source is the economically optimal distribution strategy for developer infrastructure in a market where no one has heard of us yet.
What we learned from the license wars: four lessons
The Elasticsearch, MongoDB, HashiCorp, and Redis license changes taught the industry several lessons. We internalized all of them before choosing MIT.
Lesson 1: License changes are permanent trust damage. Elastic changed their license in January 2021. It's April 2026. Developers still bring it up in every conversation about Elasticsearch. Trust, once broken, does not recover on any timescale that matters for a startup. We will not break trust because we cannot afford to.
Lesson 2: The cloud provider threat is real but not existential. Every company that changed their license cited the same threat: AWS/GCP/Azure offering their open source software as a managed service. This is a real competitive threat. It's also survivable. Red Hat competed with CentOS (a free clone of RHEL) for 20 years and built a $34 billion company. Databricks competes with AWS EMR (which runs their open source Spark) and is valued at $43 billion. The threat is real. The panic is not proportional.
Lesson 3: The fork is always faster than expected. When HashiCorp changed Terraform's license, OpenTofu launched within weeks. When Redis changed, Valkey launched within months with backing from AWS, Google, Oracle, and Ericsson. Communities can fork faster than companies can reposition. If you change the license, you don't get a head start. You get a competitor with the full weight of the cloud providers behind it.
Lesson 4: The right response to the cloud provider threat is not a license change — it's a better product. Make the managed version so much better than the self-hosted version that customers choose to pay. Invest in the dashboard, the monitoring, the compliance features, the support. Don't restrict the open source to make the commercial offering more attractive. Make the commercial offering genuinely superior.
The companies that changed their licenses did so because they couldn't build a commercial product compelling enough to compete with their own open source. We can. We will. And we don't need to restrict the open source to do it.
How to contribute
The repo is at github.com/codespar/mcp-dev-latam. Contributions we value most:
- Bug reports with reproduction steps. Found an edge case in a tool? An API response we don't handle? A provider error code that returns a misleading message? Open an issue with the exact request, the expected response, and the actual response. The more specific, the faster we fix it.
- Error code mappings. If you encounter a provider error that our server doesn't normalize correctly, submit the error code, the provider's response, and what the error actually means. These are the highest-value, lowest-effort contributions and we merge them within 24 hours.
- New server requests. Need an MCP server for a LatAm API we don't cover? Open an issue with the API name, the documentation URL, and your use case. We prioritize by demand — the more developers who request the same server, the sooner we build it.
- Tool description improvements. Tool descriptions are written for AI models, not human developers. If you notice a model consistently misusing a tool because the description is ambiguous, submit a PR with a better description. These improvements directly increase tool selection accuracy across all agents using the server.
- Country expansion. Know the commercial API landscape in Chile, Peru, Ecuador, or any other LatAm country? We have a Country Expansion Playbook in the repo that walks you through building servers for a new market. Start by proposing the API list in an issue — we'll help with architecture and review.
- Complete server implementations. Want to build an entire MCP server for a provider? Fork the repo, follow the template in
packages/template-server/, and submit a PR. We review for quality standards (error normalization, auth handling, input validation, test coverage) and publish to npm under the@codesparscope with contributor credit in the README.
The commitment
Let us be explicit about what we are committing to, publicly, in writing, on a page that will be indexed by every search engine and archived by the Wayback Machine.
1. Every MCP server we have published is MIT licensed. This will not change. The specific versions already on npm are MIT forever (that's how MIT works). But we go further: future versions of existing servers will also be MIT. No license change on patch versions. No license change on major versions. MIT, permanently.
2. Every MCP server we publish in the future will be MIT licensed. Not BSL. Not SSPL. Not AGPL. Not a custom license. MIT. This applies to every server, in every category, for every country, indefinitely.
3. The @codespar/sdk will remain MIT licensed. The SDK is how developers interact with our servers. If the SDK were proprietary, the open source servers would be less useful. The SDK stays open.
4. We will never introduce usage-based restrictions on the open source components. No rate limits on the open source servers. No telemetry that phones home. No feature flags that degrade after a trial period. The open source version is the full version, permanently.
5. We will never use a copyleft license as a competitive weapon. AGPL and SSPL are sometimes used strategically — not to protect community contributions, but to prevent competitors from building on your work. This is a legitimate business decision but an illegitimate open-source one. We will never use license terms to restrict what developers can build with our code. MIT means MIT: do whatever you want.
We will not change the license. Every MCP server we publish will remain MIT forever. Future servers will also be MIT. This is not a growth-stage tactic. Not a goodwill gesture that expires when we raise a Series B. Not a strategy that "might evolve as the business matures." It's a permanent, irrevocable commitment. We chose MIT because it's the right license for infrastructure that wants to become a standard. We chose it because the cautionary tales of Elasticsearch, MongoDB, HashiCorp, and Redis taught us what happens when you don't. And we chose it because the business model works without restricting the open source. If we ever considered changing it, read this post back to us.