Vasyl’s Dev Notes

Sooner or later, every developer runs into The License Question. You shipped something to GitHub, GitHub asked you to pick a license, and you scrolled the dropdown — MIT, Apache, GPL, AGPL, BUSL, MPL, ISC, Unlicense, “Other” — and picked whatever sounded least scary. That’s how I did it. That’s also how I ended up rewriting my LICENSE file three weeks later.

Licenses are a dark forest for devs. We don’t read legal docs, nothing in our day-to-day teaches us when each one matters, and most online advice is either a wall of legalese or someone’s religious argument. Here’s the version I wish someone had given me: a tour of the five licenses you’ll actually meet, the mistakes that bite, and what changing my license did to my project’s discoverability in the real world.

What a license actually does

By default, your code is “all rights reserved.” That sounds like the default-est thing possible — but it means no one can legally copy, fork, run, or modify your code without your written permission. Sticking your project on a public GitHub repo doesn’t change that. A license is the contract you write with the world that relaxes the default.

The question you’re answering when you pick one: how much can people do with this, and what do you get back?

The five you’ll actually meet

MIT. “Use my code. Just keep my name in the file. Don’t sue me.” Three paragraphs long. Maximum adoption, zero protection. Most of the JavaScript ecosystem runs on MIT, and most of those projects don’t have a monetization plan, which is exactly why it works for them.

Apache 2.0. Like MIT, but explicitly grants patent rights from contributors to users. That sounds boring until you realize half the tech world is built on patented stuff and silently assumes nobody will sue. Apache is the grown-up version of MIT — same vibe, fewer landmines.

GPL-3.0. “Modify and distribute my code? Your modifications are also GPL.” This is copyleft. It infects everything downstream, which is why corporate lawyers hate it and Linux thrives on it (the kernel is GPL-2). Companies can’t quietly fold GPL code into their proprietary stack — the license would force the whole stack open.

AGPL-3.0. GPL with a single, brutal addition: §13. If you modify the code and run it as a network service — a SaaS, a hosted dashboard, anything users hit over the network — you have to publish your modifications. This closes the loophole that GPL leaves open, where a company can fork, modify privately, and host the modified version. AGPL says: nope, your fork has to be public the moment users touch it.

BUSL-1.1. Not actually open source by the OSI’s definition — it’s “source-available.” You can read the code, fork it, run it for yourself; you can’t sell it as a hosted commercial service competing with the original author. After four years it auto-converts to a real OSI license (usually Apache). Sentry, MariaDB, CockroachDB — all BUSL. It’s a defensive license aimed at the “AWS forks our project and undercuts us on hosting” scenario.

(There’s also MPL-2.0 — file-level copyleft, used by Firefox. A reasonable middle ground if MIT feels too loose and AGPL too aggressive. Not your most-likely first encounter, so I’m leaving it as a footnote.)

Mistakes I see all the time

Picking MIT for a thing you might monetize. The most expensive mistake. MIT lets a competitor fork your work, polish it, host it, and out-market you — with zero recourse. Fine for a library nobody wants to commercialize. Bad for a product.

Copying BUSL because Sentry uses BUSL. Different threat models. Sentry has hyperscaler-competition risk; you have nobody-knows-you-exist risk. BUSL solves a problem you don’t have, while costing you contributor goodwill, awesome-list eligibility, and brand clarity. I learned this one personally.

Slapping GPL or AGPL on a library. Copyleft on a library is contagious — anything that links to it inherits your license. Devs see it and walk away because they can’t safely use your code in their proprietary or differently-licensed project. Libraries should almost always be MIT or Apache.

No license at all. The silent killer. “All rights reserved” is the default, so a public repo with no LICENSE file is technically a public repo nobody can legally use. You’re sending the message: here’s my code, but also nobody can touch it. If you want adoption, ship a license.

Picking the most “open” license to look generous. MIT looks generous. It’s also the easiest license to regret. The right question isn’t “how open should I look” — it’s “what business model do I want to keep available?” Be honest with yourself before you optimize for image.

What changing the license actually changed

I shipped TextStack — a reading tool I’m building solo — under BUSL-1.1. My reasoning was the same one MariaDB and Sentry articulated: protect against AWS-style cloning before it happens. Sounded smart. Felt smart. Wasn’t.

The first sign was awesome-selfhosted. I went to add my project to the most-trafficked self-hosted directory on GitHub, opened the contributing guide, and saw a rule I hadn’t expected: OSI-approved licenses only. BUSL doesn’t qualify. The same pattern showed up across every awesome-* list I checked — awesome-react-native, awesome-dotnet-applications, awesome-llm-apps. Most either explicitly require an OSI-approved license or implicitly do. The world of curated, high-traffic developer discovery is gated by the OSI definition, and BUSL sits on the wrong side of the gate.

Then the second-order effects started showing up.

On GitHub Topics, the license filter is how a lot of devs browse for tools — license:agpl-3.0 has its own discovery surface, license:other is essentially invisible. Switching from BUSL to AGPL moved my repo from one bucket to the other.

On the README itself, the license badge is the first thing a potential contributor reads. “BUSL-1.1” makes most devs hesitate — what is this, can I actually contribute? “AGPL-3.0” is recognized instantly. For a portfolio project where you want stars, forks, contributors, and word-of-mouth, that hesitation is the whole game.

And here’s the kicker: AGPL didn’t even cost me the protection I was after. The §13 network-copyleft clause makes most cloud-cloning impractical — the moment a competitor publishes a hosted fork, their differentiator is public. I kept the defensive moat; I shed the friction. On top of that, AGPL leaves dual-licensing on the table — the same playbook that funds Plausible, PostHog, and Cal.com (AGPL for the community, paid commercial license for clients who can’t comply with §13). With BUSL, that revenue path was already pre-closed; BUSL is the commercial-restricted license, there’s nothing to upgrade away from.

The lesson, if you’re building a portfolio project, is uncomfortable: license choice is a discoverability decision, not just a legal one. Awesome lists, GitHub Topics, contributor pipelines — all gated by the OSI definition. Pick the one that opens doors, not closes them.

How to actually decide

Three questions, in order:

1. Library or product? Library → Apache 2.0. Product → keep reading.
2. Will you monetize someday? Yes → AGPL-3.0. No → MIT or Apache.
3. Are your future customers mostly enterprises with strict no-AGPL policies? Some big companies (Google, famously) ban AGPL internally. If your TAM is enterprise, lean Apache.

For most solo-dev side projects: AGPL-3.0. It’s real open source, qualifies for awesome-list submissions, attracts contributors, and keeps the dual-licensing door open if you ever decide to monetize. That’s the honest default.

I picked BUSL-1.1 first, switched to AGPL-3.0 two weeks later, and watched the discovery dynamics flip on the same week. The shorter version of this whole post: pick AGPL, save yourself the relicensing.