I've shipped three CRM forks under three different licenses, and the license decision has caused me more long-term pain than any code decision I've made.

If you're picking a codebase to fork, or deciding what to release your own under, this post is the cheat sheet I wish I'd had in February.

TL;DR

• MIT, Apache 2, BSD: ship whatever you want, attribute correctly, move on
• GPL v2/v3: anyone you distribute the binary to gets the source
• AGPL: anyone who uses your software over a network gets the source. This is the SaaS killer
• Proprietary: your problem to write and enforce, but you control everything

Pick Apache 2 if you're forking and shipping SaaS. Pick proprietary if you're selling source code as a product. Skip AGPL unless you're prepared to release every backend change you make.

The quick license table

That table is your 90% answer. The rest of this post is the why.

MIT - the "do whatever" license

MIT is four paragraphs of plain English. You can fork it, close-source it, sell it, ship it as SaaS, and the only thing you have to do is keep the copyright notice in the source.

Here's the actual obligation:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

That's it. You don't need a NOTICE file, you don't need to publish anything, you just keep the header in the source files you redistribute. If you compile MIT code into a binary and ship that binary, technically you're supposed to surface the license text somewhere your users can find it (an About screen, a /legal route, a LICENSES.md in the install bundle).

In a CRM context, MIT is gold for utility libraries. If you find an MIT-licensed React table component, you can use it forever, never publish your fork, and ship it to clients without a second thought.

What MIT does NOT give you: an explicit patent grant. If the original author has a patent that covers what their code does, MIT doesn't expressly license that patent to you. Courts have generally treated MIT as an implied patent license, but if you're shipping a real product with real revenue, this is the gap that Apache 2.0 closes.

Apache 2.0 - MIT with adult supervision

Apache 2.0 is what I'd recommend to anyone forking a permissively-licensed CRM and shipping SaaS. It gives you:

• The same "do whatever" rights as MIT
• An explicit patent grant from contributors
• A termination-on-patent-litigation clause (if you sue someone for patent infringement on the project, your license dies)
• A NOTICE file mechanism for attribution

The NOTICE piece is what trips most people up. If the upstream repo ships a NOTICE file, you have to redistribute its contents in any derivative work. So if you fork an Apache 2.0 CRM, you can't just delete NOTICE and replace it with your own. You can ADD to it. You can't subtract.

Here's what an Apache 2.0 source file header looks like:

/*
 * Copyright 2024 Original Author Name
 * Copyright 2026 Your Company Here
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 */

And your NOTICE file might look like:

Acme CRM
Copyright 2026 Acme Inc.

This product includes software developed at
Upstream Project (https://github.com/upstream/crm-core).
Copyright 2024 Original Author Name

If you're shipping a JS bundle, the convention is a LICENSES.txt in your /public directory linked from a /legal page or your app footer. I've seen plenty of "Apache 2.0 violating" forks in the wild because the founder didn't realize that minifying away source headers is technically a violation.

BSD - like MIT, lawyer-flavored

BSD comes in 2-Clause and 3-Clause flavors. 3-Clause adds a "you can't use my name to endorse your fork" provision. For CRM purposes, BSD is functionally MIT with extra text. Keep the notice, ship the product.

The only thing to watch: there's an older "4-Clause BSD" that requires an advertising clause ("All advertising materials mentioning features must display..."). This is GPL-incompatible and rare in modern code, but if you're forking something from before 1999, check the LICENSE file carefully.

GPL v2 and v3 - copyleft for distributed binaries

Here's where most developers get confused.

GPL says: if you distribute a binary built from GPL code, anyone who gets that binary has the right to demand the source code, modifiable and rebuildable. This is "copyleft."

In a CRM SaaS context, GPL is fine in practice. You're not distributing the binary. Your users hit a web app. The binary sits on your server. They never receive a copy. So technically, GPL doesn't trigger.

This is the "SaaS loophole" the AGPL was written to close.

You CAN fork a GPL CRM, modify it, run it on your servers, sell SaaS access, and never release a single line of code. Legally clean. Ethically, that's a conversation for the project's community.

But the moment you ship a desktop app, a mobile app, or an on-prem installer to a client? You're distributing. Source code must be available. And not just on an "I'll send it if you ask" basis. GPL v3 requires you to either:

1. Include the corresponding source with every binary, or
2. Provide a written offer valid for 3 years to send the source, or
3. (For non-commercial distribution) Pass along the offer you received

Here's the kicker: any code you LINK to GPL code typically has to be GPL too. So if you fork a GPL CRM core and add your closed-source billing module, the billing module is supposed to be GPL also. This is the "viral" nature of GPL that scares enterprise lawyers.

GPL v3 adds explicit patent grants and an anti-Tivoization clause (you can't ship a device where the user can't actually modify and reinstall the GPL software). For CRM SaaS, v2 vs v3 rarely matters in practice.

AGPL - the SaaS killer

If GPL is "copyleft on distribution," AGPL is "copyleft on network use."

The relevant section is AGPL Section 13:

Notwithstanding any other provision of this License, if you modify
the Program, your modified version must prominently offer all users
interacting with it remotely through a computer network ... an
opportunity to receive the Corresponding Source of your version by
providing access to the Corresponding Source from a network server
at no charge ...

Translation: if your users hit your CRM over the internet, AND you've modified the source, AND the project is AGPL, you have to make YOUR modified source available to those users.

So if you fork an AGPL CRM, build it into your SaaS product, and a customer logs into your dashboard, that customer can demand your full source code. Including the billing logic you wrote, the integrations you built, the security patches you applied.

Some people are fine with this. Some companies used AGPL as a strategic moat: nobody can host a competing version of our product without releasing all their improvements. That's the whole point.

But if you're a small agency or solo dev planning to stand out on the proprietary stuff you build on top, AGPL will torch your plan. I evaluated two AGPL-licensed CRM projects in February before deciding it wasn't worth the legal exposure for a SaaS play.

If you want to ship SaaS with an AGPL-licensed base, you have exactly two options:

1. Release your modifications under AGPL (the project's intent)
2. Buy a commercial license from the copyright holder (the project's revenue model)

There is no option 3.

How to read a LICENSE file in 60 seconds

When I'm evaluating a codebase, here's the script I run mentally:

1. Open LICENSE, LICENSE.txt, or COPYING in the repo root. No file? Walk away. Unlicensed code is "all rights reserved" by default, which means you have no rights.

2. Look at the first identifying line. Is it "MIT License," "Apache License Version 2.0," "GNU GENERAL PUBLIC LICENSE Version 3," etc.? That tells you 90% of what you need.

3. Check for a NOTICE file. If present, you must redistribute its contents. Open it.

4. Look at package.json or pyproject.toml. The license field should match the LICENSE file. Mismatches happen and they're a red flag.

5. Search the repo for "Commons Clause," "Business Source License," or "SSPL". You'll see more of these lately. They look like open source but explicitly forbid commercial use or SaaS hosting. They're not OSI-approved and they don't behave like the licenses above.

Here's a one-liner I use to check a repo before forking:

curl -sL https://api.github.com/repos/OWNER/REPO/license \
  | jq -r '.license.spdx_id, .license.name, .download_url'

That returns the SPDX identifier, friendly name, and a URL to the raw license text. If spdx_id comes back NOASSERTION or null, GitHub's auto-detection couldn't figure out the license. That's almost always bad news.

The real story - why I built mine from scratch instead

I had a decision to make in February. I'd been paying GHL monthly for years to run my agency, and I was tired of the subscription treadmill. The play was either:

• Fork an existing AGPL or GPL CRM, eat the license obligations, and rebrand
• Buy a commercial source-code license from a proprietary CRM vendor
• Build from scratch

I went deep on the open source side. The two most viable forks I looked at were both AGPL. One had a beautiful UI and decent architecture. The other had a more mature feature set but a Frankensteined backend.

The math didn't work. Both would have meant either:

• Releasing every backend modification to my customers under AGPL Section 13, or
• Buying a commercial license that cost more than building from scratch

So I closed the tabs, opened Cursor, and started writing Next.js + Convex code. 800+ hours later, I had a CRM I could license however I wanted, because I owned every line.

I'm shipping it under a proprietary source-code license. One-time payment, you get the code, you can modify it, you can't resell it as a competing product. That model doesn't work with AGPL upstream. It barely works with GPL upstream. It works fine with Apache 2.0 upstream (which is why my dependency tree is almost entirely Apache 2.0 and MIT). And it works perfectly with code I wrote myself.

This is the same lesson I keep relearning in agency work: ambiguity will absolutely DESTROY you. I had a client rebrand a while back and Google basically lost its mind trying to figure out what they did. I spent weeks playing detective with press releases and citation cleanup, the leads coming in were unqualified, and we eventually parted ways. Same principle for licenses. If you don't know exactly what you're allowed to do with your codebase, you'll spend more time playing lawyer than shipping product.

Attribution - the bare minimum

For any permissively-licensed dependency in your CRM, here's the minimum attribution stack.

In your package.json:

{
  "name": "your-crm",
  "license": "SEE LICENSE IN LICENSE.txt",
  "dependencies": {
    "some-apache-thing": "^1.0.0"
  }
}

In /public/licenses.json or /legal/oss, dump the output of:

npx license-checker --production --json > public/licenses.json

That gives you every dependency, its license, and its copyright notice in one file. Most courts and most lawyers consider this sufficient for permissive licenses. For Apache 2.0, also concatenate any upstream NOTICE files into a single NOTICE.txt in your distribution.

In your app footer or settings page:

<a href="/legal/oss" className="text-xs text-gray-500">
  Open source licenses
</a>

This is the part most "I forked a CRM in a weekend" tutorials skip. It takes 20 minutes. Do it once, never think about it again.

Compatibility matrix

The question I get most: "can I combine X-licensed code with Y-licensed code in the same project?"

Key gotcha: Apache 2.0 is incompatible with GPL v2 (because of the patent retaliation clause), but compatible with GPL v3. That's why the Linux kernel (GPL v2 only) can't directly include Apache-licensed code, but plenty of GPL v3 projects do.

Combining GPL-family code with proprietary code in a single distributable binary is generally not allowed. Some projects use a "linking exception" to permit this. Most don't.

What to actually do

If you're forking, pick a project under Apache 2.0 or MIT. Do the attribution work upfront. Build your SaaS, sleep well.

If you're forking AGPL and planning to ship SaaS, either commit to releasing your modifications or buy a commercial license. Don't try to find a loophole. There isn't one that won't blow up during due diligence.

If you're writing your own and selling source code, write a proprietary license. Get a lawyer to review it. The standard structure: perpetual license to use and modify, no right to resell as a competing product, attribution preserved. That's the lane I'm in with Seedly, and I wrote up the white-label playbook for reselling CRM code if you want the business side of it.

If you're not sure what license your dependency is under, run the SPDX check above. If you're still not sure, drop the repo link in the comments. Happy to take a look.

If the white-label side is what you're actually weighing, I broke down the three real options (license a SaaS, fork open source, or buy a codebase outright) in this Quora answer.

Not a lawyer. Just a guy who's read more LICENSE files this year than he ever wanted to.