Open source or just ‘source-available’? Check the license

More and more e-commerce integration tools market themselves as “open source.” Some genuinely are. Others have their code publicly visible — which is not the same thing. The difference is legal, concrete, and has direct consequences for what you’re allowed to do with the software. If you’re an agency deciding what to build a client offering on top of, that difference decides your business model. This post explains it without the legalese.

Up front: we’re not lawyers and this isn’t legal advice. It’s an explanation of the terms so you can ask the right questions — for a serious decision, still read the specific license or run it past someone who knows the area.

What open source is — and what it isn’t

“Open source” has a formal definition, set by the Open Source Initiative (OSI), which since 1998 has approved licenses that meet the Open Source Definition. A license is open source if, among other things, it permits using, modifying, and distributing the software for any purpose, including commercial, with no added restrictions.

OSI-approved licenses include MIT, Apache 2.0, GPL, and AGPL. Each grants different rights in the details, but all meet the same baseline: you can use the code without asking anyone’s permission for a particular use.

Licenses that are not open source under OSI include Elastic License 2.0 (ELv2), the Server Side Public License (SSPL), and the Business Source License (BSL). None is OSI-approved, and none qualifies as open source — regardless of how the vendor markets it. The code is publicly visible, but the license restricts how you may use it. This is called source-available — code you can read, but not freely use.

What you can do — it depends on the license

The three licenses you’ll meet most often in e-commerce tooling differ fundamentally — not in the fine print, but in what they let you do.

Apache 2.0 — use the software for any purpose, including commercial. Modify it, deploy it for a client, build and sell your own products on it, run it as a hosted service for others. The only requirement is preserving the license and copyright notices in your distribution. Apache 2.0 also includes an explicit patent grant — every contributor automatically grants you a patent license, which matters in enterprise environments where patent risk is real. (Note MIT has no such grant.)

Elastic License 2.0 (ELv2) — use, copy, modify, and distribute the software, but ELv2 forbids offering it as a hosted service to others. In practice, an agency can’t deploy it for a client as a service — only as an install the client maintains themselves. ELv2 also bars circumventing the license-key functionality: you can’t technically bypass the built-in license controls, even with the source in hand.

SSPL (Server Side Public License) — use and modify freely, but if you offer the software to others as a service, you must publicly release not just your modifications but the entire infrastructure code behind that service — databases, monitoring, deployment tooling. In practice, companies with proprietary code can rarely use SSPL software in commercial products, because the price of running the service is publishing your whole technical architecture.

What it means for a merchant

If you’re choosing a tool to sync your shop with marketplaces and wondering whether it’s “really open source,” ask one simple question: what license is it released under?

If the answer is Apache 2.0, MIT, or another license on the OSI list — you have a guarantee the rules won’t change under your install. OSI licenses are irrevocable for already-released versions: the vendor can’t retroactively block your access to the code or change the terms of software you already run. (The Apache 2.0 patent grant can terminate if you initiate patent litigation — but your right to use the code stays.)

A real-world example: a shop deploys an integration tool under a source-available license. A year later the vendor changes the terms — the new version carries tighter restrictions. Under Apache 2.0, the old version stays on the old terms forever. Under source-available, it depends on a license you only really read once you’ve already installed something.

If the answer is Elastic License, SSPL, or just “source-available” — read the terms carefully, because your right to use it may depend on how you use it. That’s not an accusation, just a fact worth checking while you’re deciding, not after you’ve deployed.

What it means for an agency or developer

For an agency that wants to deploy a tool for clients or build its own services on it, the license has even more direct consequences.

What you want to do	Apache 2.0	Elastic License 2.0
Deploy for a client as an install	✅	✅
Operate it as a service for a client	✅	⚠️ needs analysis
Modify the code and keep changes as your own	✅	✅
Build your own products on the code	✅	✅ with limits
Offer it as hosted SaaS for many clients	✅	❌
Use it without legal review	✅	⚠️ review advised

The line between “I deployed it and handed it to the client to maintain” and “I operate it for the client as a service” can be subtle. Under Apache 2.0 that line has no legal weight — you can do both. Under Elastic License it’s worth a lawyer’s read before you build an offering on it. This is exactly why OpenLinker’s agency model works the way it does: you can host, support, and resell it on your own margin.

Why it matters in e-commerce

E-commerce integration tools increasingly get described as “open source” or “open” — without saying under which license. Directories like Open Source Alternatives list only tools under OSI-approved licenses; source-available tools under SSPL, BSL, or Elastic License don’t appear, because they don’t meet the Open Source Definition.

This matters in two situations.

First: when a vendor decides to change its license — which has happened repeatedly (Elasticsearch in 2021, HashiCorp/Terraform in 2023, Redis in 2024). Under an OSI license you’re protected: the version you have stays under that license forever. Under source-available, new versions can carry different restrictions.

Second: when you want to check whether you’re even allowed to do something with the tool — under an OSI license the answer is simple and needs no legal review.

Where OpenLinker stands

OpenLinker is released under Apache 2.0. Not source-available, not a license key, not commercial restrictions. You can use it, deploy it for a client, build your own solutions on it, and modify it — without asking us for permission and without license fees.

Concretely: no per-order fee, no monthly license subscription, code you can inspect and modify, and a license that won’t change under your install. You pay for your own infrastructure and developer time — that’s the total cost of the license.

OpenLinker is alpha, pre-1.0. Choosing Apache 2.0 is a deliberate decision about the kind of project we want to build — not a moat against competitors, but a commitment to the people who use it. The license is the foundation; the rest you can read in the code.

What you can do now

• See the pricing and cost model — what you actually pay when there’s no license fee and no per-order meter.
• Read why we built OpenLinker — where the open-source-as-foundation decision came from.
• See the agency model — how you host, support, and resell OpenLinker services on your own margin.
• Check the full integrations list — what’s live today, what’s in progress, and what’s planned.
• Star it on GitHub — if you want to back an integration platform built on Apache 2.0.

The license is the first question worth asking, not the last. Ours has a short answer: Apache 2.0, no asterisks.