Licensing

Status: the CLA is IMPLEMENTED (2026-08-10). The licence choice is not.

The owner asked whether AstroBaaS can do what Magento does: a free community edition and a paid commercial edition. The short answer is yes, and the reason is specific enough to be worth writing down — along with the one thing that would quietly destroy the option.

I am not a lawyer. The structural facts below are checkable; the legal conclusions are the sort of thing to confirm with someone qualified before money changes hands.

---

1. What Magento actually does

Worth being precise, because the shape is often described wrongly:

• Magento Open Source is licensed OSL-3.0 (not GPL, though also copyleft).
• Adobe Commerce is a separate, proprietary distribution that includes and extends the open-source code.
• Adobe can do this because Adobe owns the copyright. The open-source licence binds everyone who receives the code; it does not bind the author.

That last point is the whole mechanism. It is not a loophole and it is not unusual — it is how MySQL, Qt, GitLab, Sentry and Redis have all operated.

2. Why AstroBaaS can do the same thing

Verified in this repository, 2026-08-08:

Sole copyright means the GPL does not constrain you. You may:

• publish the core under GPL-3.0 as the community edition;
• ship a proprietary paid edition or module built on the very same code;
• grant a customer a commercial licence with different terms entirely.

Nobody else can do any of that with your code. That asymmetry is the commercial moat.

3. The one thing that destroys this option

The first external contribution.

The moment someone else’s code lands in the core under GPL-3.0, you no longer own all of it. You cannot relicense their contribution into a proprietary edition without their individual permission — and “we merged a typo fix from a stranger in 2027” is a genuinely hard problem to unwind later.

This is not hypothetical: it is the single most common way a project loses the ability to dual-license, and it happens by accident, in a friendly pull request nobody thought about.

This is now handled. CLA.md exists and .github/workflows/cla.yml gates every pull request on it, so the window described above no longer closes on the first merged external PR.

One caveat worth stating plainly: the gate is not live until the owner creates the signature repository and the PERSONAL_ACCESS_TOKEN secret. Until then the workflow fails closed — it blocks merges rather than passing them, which is the correct direction for this particular failure, but it does mean the setup is not optional.

To be precise about the scope of that claim: an external contribution destroys the option only when it arrives without a contributor agreement. With one in place, contributions and a commercial edition coexist indefinitely — which is exactly what Magento does, and §3b explains how.

The dependency half, which is easy to forget

The CLA protects the copyright in code written for the Project. It says nothing about the code the Project depends on, and that side fails silently: one transitive AGPL-3.0 or SSPL dependency arrives on a routine npm install, no test goes red, and the paid module has become unsellable.

npm run audit:licenses gates the production tree on every pull request, and THIRD-PARTY-NOTICES.md records what is in it. As of the last audit: 220 production packages, all permissive except libvips (LGPL-3.0, loaded as a shared library through sharp — permitted, with obligations that are written down) and caniuse-lite (CC-BY-4.0, attribution only).

What to put in place before going public

Pick one, in rough order of strength:

1. CLA with copyright assignment — contributors assign copyright to you. Strongest, most friction, some contributors refuse on principle.
2. CLA with a broad licence grant — contributors keep copyright but grant you an irrevocable right to relicense, including commercially. This is what most dual-licensed projects use, and it is the sensible default here.
3. DCO only (Signed-off-by:) — asserts the contributor had the right to submit, but grants you nothing beyond the project’s licence. Good hygiene, useless for dual-licensing. Do not mistake one for the other.

Tooling exists (CLA Assistant and similar) that gates a PR until the contributor signs once.

3b. How Magento takes community contributions AND sells Enterprise

This is the obvious objection to §3 — Magento Open Source has thousands of external contributors and Adobe still sells a proprietary edition. If external contributions destroyed dual-licensing, that could not be true.

It is true because of a CLA. Magento has required a Contributor License Agreement since it opened Magento 2 to outside contributions; Adobe continues it. The mechanism is the whole answer to the question:

• The contributor keeps their copyright. Nothing is signed away in the sense people usually fear.
• They grant the project owner a broad, irrevocable licence to use, modify, sublicense and relicense the contribution — including under proprietary terms.
• It is signed once, usually by a bot on the first pull request, and covers everything that contributor sends afterwards.

So the contribution lands in the open-source edition under the open licence and Adobe holds a separate right to ship it in Adobe Commerce. Both are true simultaneously. There is no contradiction because the contributor granted both.

This is not a Magento invention. It is the same instrument used by Apache Software Foundation projects, Google’s open-source projects, Elastic, MongoDB, GitLab and Qt — most of the dual-licensed world runs on it.

The structural half: two repositories, one direction

The CLA answers the legal question. The other half is organisational, and it is worth copying:

• Community contributions land only in the open-source repository. That is the repo people file issues and pull requests against.
• The commercial edition is a separate, private codebase that consumes the open-source one and adds to it.
• Code flows open → proprietary, never the reverse. No external contributor ever sees, touches, or acquires rights in the commercial code.

That one-directional flow is what keeps the arrangement clean. If proprietary code leaked back into the open repo it would have to be published; if community code arrived without a CLA it could not be shipped commercially.

Why contributors accept a deal that looks asymmetric

It is worth understanding rather than assuming goodwill, because it determines whether anyone will actually contribute to AstroBaaS:

• Most contributions are small fixes to code the company wrote. Someone patches a bug that is costing them money today; the alternative is carrying a private fork forever.
• Upstreaming is the selfish choice. A merged fix is maintained by someone else from then on.
• The company funds the thing existing at all. Contributors are usually clear-eyed that without the commercial edition there is no Magento.

But the friction is real and should not be waved away: some developers refuse to sign CLAs on principle, seeing the asymmetry as extraction. Linux uses a DCO precisely to avoid it — and as a direct consequence Linux can never be dual-licensed by anyone. That is the trade, stated plainly: a CLA costs you some casual contributors and buys you the commercial option; a DCO costs you the commercial option and buys you the contributors.

For a project whose funding model is paid modules, the CLA is the side of that trade that keeps the project alive.

4. What GPL-3.0 does and does not stop

Three points that change the strategy, each worth knowing precisely:

GPL-3.0 has no network copyleft. Running AstroBaaS as a hosted service is not distribution, so none of the copyleft obligations trigger. A SaaS offering is unencumbered today, with no licence change and no CLA needed. If preventing that for others matters, AGPL-3.0 is the licence that closes it — but it would close it for you too until you dual-license.

A proprietary module you distribute is fine — for you. You own the core, so your paid optical module has no GPL problem regardless of how tightly it couples.

But it is murky for everybody else, and that is the strategic catch. A third party wanting to sell a closed-source AstroBaaS plugin runs straight into the same argument that has followed WordPress for twenty years: is a plugin that links a GPL host a derivative work? Automattic says yes. Others disagree. Nobody has settled it in court.

If the ambition is “the new WordPress” with a paid third-party plugin marketplace, a GPL core actively discourages the sellers you want to attract. That is a real cost, and it is the strongest argument for a permissive core.

5. The three viable shapes

A. Keep GPL-3.0, sell your own modules (the Magento shape)

• Core stays GPL-3.0; you sell the optical module and future verticals proprietarily, as sole copyright holder.
• Needs: a CLA before the first external contribution.
• Cost: third parties are discouraged from selling proprietary plugins.
• Fit: good if the paid ecosystem is mostly yours.

B. Relicense the core permissively (Apache-2.0), sell modules proprietarily

• Anyone may build and sell plugins with no legal ambiguity — the strongest possible signal to an ecosystem.
• Apache-2.0 also carries an explicit patent grant, which GPL-3.0 has but MIT does not.
• Cost: a competitor may fork and close it. In practice the moat is the paid modules, the brand and the pace of development, not the licence.
• Fit: best if you want other people selling plugins.
• You can do this today, unilaterally — sole copyright, not yet public. After publication it is still possible but noisier.

C. Keep GPL-3.0, sell hosting and support (the Red Hat shape)

• Everything stays open. Revenue is managed hosting, updates, SLAs.
• Needs: no CLA, no licence change, no licensing code at all.
• Cost: revenue scales with operations, not with software.
• Fit: the fastest to start, and it composes with A or B later.

6. Recommendation

Do these two things before the repository goes public, in this order:

1. Add a CLA with a broad relicensing grant. Done, 2026-08-10 — CLA.md, option 2 (contributor keeps copyright, grants an irrevocable right to relicense including commercially), enforced by .github/workflows/cla.yml.

   Two things still need the owner personally, and neither can be written in code: create the signature repository and PAT (the workflow header lists the three steps), and confirm the governing-law clause, CLA §8, currently set to Greece.

2. Decide GPL vs Apache on one question: do you want third parties selling plugins for AstroBaaS? If yes, Apache-2.0 removes an ambiguity that has suppressed exactly that market around WordPress for two decades. If the paid ecosystem is going to be yours, GPL-3.0 is fine and keeps the core from being forked closed.

Given the stated goal — “the new WordPress for vibe coders”, with an ecosystem — Apache-2.0 for the core plus proprietary paid modules is the combination that best matches the ambition. But it is a business decision, not a technical one, and the CLA matters more than which way it goes.

7. What NOT to build yet

Repeating the constraint from OPTICAL_MODULE.md, because it is the tempting place to start and the wrong one:

• The two live shops must never be gated. Fail-open, always.
• No licence check on the request path. A shop’s uptime must not depend on a licence server’s uptime.
• The core must behave identically when a paid module is absent — the same degradation rule sections already follow.
• Enforcement is a business problem before it is a technical one. Every client-side licence check is bypassable; what actually works is that paying customers get updates, support and liability cover. Build the value, not the lock.