Case Study: Choosing Source-Available Licensing as a Maintainer in 2026

Case Study: Choosing Source-Available Licensing as a Maintainer in 2026

I run a small open-source tool used by about 4,200 developers. We ship a CLI and a tiny web UI. For years we used MIT and moved fast. Then a few things happened in 2025 that forced a rethink.

Timeline

• Jan 2025: Project hits 1,000 weekly active users.
• Apr 2025: A startup forked the repo, shipped a paid hosted service, and closed the fork.
• Sep 2025: Two companies asked for a license that prevents rehosting without contributions.
• Dec 2025: We considered source-available licenses to protect community value.
• Mar 2026: We chose a source-available license with a clear policy for contributors.

What broke and why I cared

I wanted users to copy and improve the code. I didn't want companies to copy it, add a thin wrapper, and sell it as a service while offering no code contributions back. That happened twice. We lost potential contributors because they felt the project was becoming a free R&D engine for companies.

There are also legal costs. We had to track who used our code and whether they complied. That costs time. Time is the one thing I don't have.

How I approached the choice

I treated it like a small product decision. I gathered data. I asked three questions:

1. What do we want contributors to get out of this? I wanted a healthy contributor base and shared maintenance.
2. What behaviors do we want to discourage? Mainly rehosting for profit without contribution.
3. What trade-offs can the community accept? Some contributors prefer maximum freedom. Others prefer stronger guardrails.

I ran a short survey. 120 active contributors responded. 72 said they preferred permissive. 48 wanted stronger protections. That split mattered.

Options I evaluated

• Keep MIT/Permissive: fastest for adoption. Lower friction. But no protection against rehosting.
• Add a CLA + contributor policy: keeps license permissive but requires contribution agreements. Hard to enforce at scale.
• Source-available (non-commercial/rehost restrictions): protects against rehosting but reduces adoption by some users.
• Dual licensing (AGPL for commercial, MIT for community): possible but complex and can scare contributors.

What we tried

Step 1: Draft a policy. I wrote a 1-page contributor policy. It explained expectations for maintainers and companies. It asked companies to open-source any modifications used in a hosted service.

Step 2: Talk to the community. I posted the draft to the repo. I held two live Q&A sessions. 45 people came to the first session. 19 to the second. Feedback was concrete. Some worried about corporate adoption. Others asked for a clear, short enforcement path.

Step 3: Pick a license. We chose a source-available license with a rehost clause. It allows code reuse for forks and internal use. It disallows offering the exact product as a closed hosted service without offering the core modifications back under the same terms.

Why this license worked for us

• It matched the community split. We kept open forks free but made plain rehosting for profit less attractive.
• It reduced friction for hobbyists. They could still fork and run the project locally.
• It gave us leverage in conversations with companies. We now had a written policy to cite.

Enforcement and the real costs

License text alone is not enforcement. We paired the license with a simple tracking and outreach process.

1. We added a lightweight usage notice in the README and the license header. It asks companies to reach out if they run the project as a paid service.
2. We automated basic detection. We watch for public websites that use specific CSS class names or endpoints unique to our project. That heuristic finds likely rehosts.
3. When we find a candidate, one of the core maintainers sends an outreach email. The tone is plain. We ask: are you running our project? If yes, can you open-source the modifications or discuss a contribution plan?

So far, in 3 months, we found 4 likely rehosts. Two responded and agreed to open-source minor patches (about 3–10 files each). One negotiated a partnership. One ignored us and kept a closed fork. We spent about 6 person-hours total handling these cases.

Numbers that mattered

• Contributors: active contributors stabilized at 140 after the license change (from 132). Net +8 contributors in 3 months.
• Corporate adopters willing to engage: 3 out of 7 companies we reached out to replied positively and opened small patches.
• Maintenance time spent on enforcement: ~6 hours over 3 months.
• Support requests from companies: decreased by 12% after we added clearer business usage docs.

What I learned

1. Talk first. Put the policy draft in public. Let people react. That avoids surprises.
2. Keep the enforcement cheap. Automate detection and use human outreach only when needed.
3. Accept trade-offs. We lost a handful of potential integrators who wanted zero restrictions. But we gained clarity and a better contributor experience.
4. Be explicit about commercial usage. Put a short FAQ and a contact email. Companies prefer clarity.

Things that still bother me

• License language is messy sometimes. Lawyers see edge cases we don't. I haven't found a perfect short license that fits all scenarios.
• Some downstream users still don't get the spirit. They treat rehosting as a right. That causes tension.
• Enforcement scales poorly if we get 100 rehosts. Right now it's fine.

Quick checklist if you consider source-available

• Run a short survey. Even 50 replies helps.
• Draft a 1-page policy before changing the license.
• Keep the license text short and add a plain-language FAQ.
• Automate detection of obvious rehosts.
• Prepare a one-paragraph outreach template.

Final thoughts

I don't think this is for every project. For small projects with an active contributor base and real maintenance cost, source-available can protect contributor value. For libraries meant to be building blocks, permissive licenses still make sense.

This was messy. I still worry about edge cases. But honestly, the community feels more respected now. We traded a bit of adoption speed for more long-term contributor engagement.

If you want my outreach template or the checklist, I can paste them in another post.