DEV Community: Juan Isidoro García Cifuentes

Open Source Licenses: Which One Should You Pick? MIT, GPL, Apache, AGPL and More (2026 Guide)

Juan Isidoro García Cifuentes — Fri, 27 Feb 2026 10:37:49 +0000

You just finished your side project. You push it to GitHub, hit "Create repository" and there it is — that dropdown you always skip:

Choose a license.

MIT, GPL, Apache, BSD... does it really matter?

Short answer: yes, a lot. Pick the wrong one and a big company can take your work and never give anything back. Pick none and technically nobody can legally use your code at all — even if it's sitting there in a public repo.

This isn't a theoretical problem. Let me give you a real example that shook the industry.

HashiCorp is a company behind some of the most widely used tools in cloud infrastructure. One of their flagship products is Terraform — a tool that thousands of companies (from startups to Fortune 500) use to manage their servers, databases, and cloud resources. Think of it as the "remote control" for your entire cloud infrastructure. It was open source for years, with a massive community building plugins, writing tutorials, and integrating it into their workflows.

In August 2023, HashiCorp changed Terraform's license from MPL (a permissive open source license) to the Business Source License (BSL) — which, as we'll see later, is not open source. Overnight, companies that had built their entire infrastructure around Terraform had to ask themselves: can we still use this the way we do?

The community's response? They forked the entire project — took a copy of the code from before the license change — and created OpenTofu, a fully open source alternative backed by the Linux Foundation. Thousands of contributors, millions of lines of code, infrastructure teams across the world scrambling to evaluate their options. All because of a license change.

That's how much this stuff matters. A single license decision can split a community, create competing projects, and force entire organizations to rethink their tech stack.

As someone who builds SaaS products and works as a freelance developer, I've learned to check licenses before adding any dependency to my stack. It's one of those things you ignore until it bites you. This guide is everything I wish someone had explained to me when I started — the most common licenses with real use cases, no legal jargon, no fluff.

Here's what we'll cover:

Key concepts you need before diving in
Quick comparison table
Each license explained with real use cases
Dual licensing explained
License compatibility rules
Common licensing mistakes
AI tools and code licensing
FAQ for solo developers
Decision tree to pick your license

Key Concepts Before Diving In

If you already know what copyleft means and why distribution matters, skip ahead to the comparison table. If not, spend 2 minutes here — everything else will make a lot more sense.

What Is a Software License?

A license is just a document that tells people what they can and can't do with your code. Think of it as the "house rules": you decide whether others can copy, modify, sell, or redistribute your work.

Without a license, nobody has permission to do anything with your code — even if it's public on GitHub. Public does not mean free to use. It just means visible.

What Does "Open Source" Actually Mean?

It means the source code is available and anyone can view, use, modify, and distribute it under certain conditions (defined by the license). It doesn't mean "free" and it doesn't mean "no rules."

For a license to be officially considered open source, it must be approved by the OSI (Open Source Initiative) — they're the ones who set the standard.

Open Source vs. Source-Available: What's the Difference?

"Source-available" is a newer term. It means you can see the code (it's transparent), but you can't do whatever you want with it. There are restrictions, usually around commercial use. The BSL (Business Source License) is a good example — we'll cover it later.

The key difference: open source lets you use the code freely. Source-available lets you look at it, but with limits on usage.

Permissive vs. Copyleft Licenses: The Big Split

Every open source license falls into one of two families. Understanding this is the single most important thing in this entire post:

🟢 Permissive licenses (MIT, Apache, BSD)

The relaxed ones. They basically say: "Do whatever you want with my code. Use it in your commercial app, modify it, sell it. Just give me credit."

Your code can end up inside closed-source proprietary software, and that's totally fine. The author gives up control over what happens with the code once it's shared.

🟠 Copyleft licenses (GPL, AGPL, LGPL)

The protective ones. They say: "You can use and modify my code, but if you distribute your work, you must share it under the same conditions."

The term copyleft started as a wordplay on "copyright." While copyright restricts copying, copyleft flips copyright on its head: instead of preventing copies, it forces you to keep things open. If you use copyleft code, your derived work must be open too.

This creates what people call a "viral" effect — the license spreads to everything it touches. If you include GPL code in your project, your entire project becomes GPL. It's not literally a virus, but the practical effect is similar.

Why would anyone choose copyleft? Because it protects the community's work. Without it, a big company could take your open source project, improve it, close it, and sell it without giving anything back. With copyleft, that can't happen.

What Does "Distribute" Mean in Software Licensing?

This concept comes up everywhere in licensing and it's not always obvious. Distributing means delivering a copy of the software to someone else. This includes:

Publishing an app on a store (App Store, Google Play)
Sending a binary or installer to a client
Uploading a package to npm, PyPI, or any public registry

Not considered distribution:

Using the software internally at your company
Running the software as a web service (SaaS) — this is where the AGPL comes in, and we'll get to that

This distinction is critical: if you use GPL code only internally and never distribute anything, you're not required to open your code.

Why Do Software Patents Matter for Licensing?

Some companies patent specific techniques or algorithms. If a license doesn't mention patents, someone could contribute code to your project and later sue you for using a technique they've patented. Licenses like Apache 2.0 include a patent grant that protects you from this.

If you're a solo developer working on small projects, this probably won't affect you. But if your code will be used by larger companies or receive external contributions, it's worth thinking about.

Quick Comparison Table

License	Type	Commercial use?	Copyleft?	Must open source?	Best for
MIT	Permissive	✅	❌	❌	Maximum adoption
Apache 2.0	Permissive	✅	❌	❌	Enterprise projects
BSD	Permissive	✅	❌	❌	MIT-like + brand protection
GPL v3	Strong copyleft	✅	✅	✅ (entire project)	Software that must stay free
AGPL v3	Strong copyleft	✅	✅	✅ (even SaaS)	Protection against cloud providers
LGPL	Weak copyleft	✅	✅	✅ (library only)	Libraries used by closed software
BSL	Source-available	⚠️ Restricted	❌	❌ (during restriction period)	Companies wanting transparency

Here's the full spectrum at a glance — from most permissive to most restrictive:

 PERMISSIVE                              COPYLEFT                         SOURCE-AVAILABLE
 ─────────────────────────────────────────────────────────────────────────────────────────
 MIT        BSD       Apache 2.0       LGPL        GPL v3      AGPL v3         BSL
 │          │         │                │           │           │               │
 Do what    Same as   MIT + patent     Copyleft    Everything  GPL + SaaS      Visible but
 you want   MIT but   protection       only for    must stay   must also       restricted
            protects                   the lib     open        be open         commercially
            your name                  itself

MIT License

What Is the MIT License and When Should You Use It?

The world's most popular open source license. Use it, modify it, sell it, distribute it. The only requirement: keep the copyright notice.

📦 Used by: React, Node.js, Meilisearch, jQuery, VS Code

💡 Real-world scenario

You build a React component library. You want every company and developer out there to use it in their commercial projects with zero friction. The more people use it, the more contributions you get and the more your reputation grows.

You don't mind if someone puts it in a closed-source product — your goal is maximum adoption.

Pick MIT when: you want your code to spread everywhere and you don't care who makes money from it.

Apache 2.0 License

What Is the Apache 2.0 License and How Does It Differ From MIT?

Very similar to MIT but with one key difference: patent protection. If someone contributes code to your project, they automatically grant you a license to any related patents. If they later sue you over those patents, they lose their rights to the project.

📦 Used by: Kubernetes, TensorFlow, Apache Kafka, Android (AOSP)

💡 Real-world scenario

Your startup is building a machine learning framework. You know big companies will contribute code. You need the legal guarantee that they won't sue you later over patents covering the features they contributed themselves.

With MIT, that protection doesn't exist. With Apache 2.0, every contributor automatically grants you a patent license.

Pick Apache 2.0 when: you're in an enterprise environment where patents are a real risk.

BSD License (2-Clause and 3-Clause)

What Is the BSD License?

Almost identical to MIT. The 3-clause version adds one extra rule: you can't use the author's name or the project's name to promote a derivative product without permission.

📦 Used by: Nginx, FreeBSD, Flask, PostgreSQL (similar variant)

💡 Real-world scenario

You publish a high-performance networking tool. You're fine with others using or modifying it commercially. But you don't want a company to fork it and market it saying:

"Built on the work of [your name]" or "From the creator of [your project]"

...to gain credibility at your expense without your consent.

Pick BSD 3-clause when: you want MIT-level freedom but with brand protection.

GPL v3 (GNU General Public License)

What Is the GPL License and What Does Copyleft Mean in Practice?

Strong copyleft. If you distribute software that includes GPL code, your software must also be GPL and open source. That means publishing your full source code under the same terms.

Remember: distributing means handing a copy to someone (publishing an app, sending a binary, uploading a package). If you use GPL code only internally and never distribute it, you're not required to open your code.

📦 Used by: Linux kernel, WordPress, GIMP, GCC

💡 Real-world scenario

You're building a content management system. You want to make sure that if a company takes it, improves it, and distributes it, those improvements must come back to the community. Nobody can "close" your work.

WordPress works exactly like this. That's why its ecosystem is massive: every theme and plugin that gets distributed must keep the GPL license.

Pick GPL when: you want to guarantee your code and all its derivatives stay free forever.

⚠️ Keep in mind

GPL is "viral" (as we explained earlier): if you include GPL code in your project, your entire project becomes GPL. This scares away many companies working with closed source. That's not a bug — it's the whole point.

AGPL v3 (Affero General Public License)

What Is the AGPL and Why Does It Matter for SaaS?

Just like GPL but with one crucial addition. The GPL has a loophole: offering software as a web service (SaaS) is not considered "distribution." So a company can take your GPL code, run it on their servers, charge customers for it, and never share a single line of their modifications.

The AGPL closes that gap. If you make the software available over a network, you must also publish the source code, including your changes.

📦 Used by: Grafana, Nextcloud, Mastodon, MongoDB (before switching to SSPL)

💡 Real-world scenario

You create a self-hosted analytics platform. Without the AGPL, Amazon could take your code, launch it as a managed service on AWS, charge money for it, and give nothing back.

With AGPL, if they offer it as SaaS, they're required to publish their modifications.

This is the anti-cloud-giant shield. MongoDB eventually moved from AGPL to the even more restrictive SSPL — the AGPL wasn't enough to hold off AWS.

Pick AGPL when: your software will be offered as a web service and you want anyone monetizing it to contribute back.

LGPL (Lesser General Public License)

What Is the LGPL and When Should You Use It for Libraries?

A softer version of GPL. It allows proprietary software to use your library (by linking to it dynamically) without becoming GPL themselves. But if someone modifies your library directly, those modifications must be open source.

The difference from full GPL: with GPL, if you use the library, your whole project becomes GPL. With LGPL, only direct modifications to the library itself must be opened — the rest of your application can stay closed.

📦 Used by: FFmpeg (partially), Qt (community edition), GNU C Library (glibc)

💡 Real-world scenario

You build a video processing library. You want every app — including closed-source commercial ones — to be able to use it. But if someone improves your compression algorithm, that specific improvement must come back to the community.

The rest of their application can stay proprietary. Only the direct changes to your library need to be shared.

Pick LGPL when: you're building a library you want everyone to use, while protecting direct improvements to it.

BSL (Business Source License)

What Is the BSL and Is It Open Source?

No, the BSL is not open source — it's "source-available" (as we discussed earlier). The code is visible and auditable, but production or commercial use is restricted for a set period (usually 3–4 years). After that period, it automatically converts to a fully open source license (typically Apache 2.0).

Remember the HashiCorp/Terraform story from the intro? This is the license they switched to — and the reason the community forked the project.

📦 Used by: MariaDB, Sentry, CockroachDB, HashiCorp (Terraform, Vault), Elastic

💡 Real-world scenario

You're launching a database as a SaaS product. You want developers to see your code, audit it, learn from it, and use it in development. But you don't want AWS to clone your product and compete against you using your own code.

BSL gives you a window of commercial exclusivity. Once the period expires, the code becomes fully open.

Pick BSL when: you want transparency and trust without handing your business model to the hyperscalers.

Dual Licensing: How Some Projects Offer Two Licenses

Some projects don't pick just one license — they offer two (or more) and let you choose. This is called dual licensing, and it's more common than you might think.

How does dual licensing work?

The project is available under a copyleft license (usually GPL or AGPL) for free. But if the copyleft terms don't work for you — say, you're building a closed-source product and can't go GPL — you can buy a commercial license that lets you use the code without copyleft obligations.

📦 Real examples:

Qt — Free under LGPL/GPL. Need to keep your code closed? Buy a commercial license from The Qt Company.
MySQL — Free under GPL. Don't want your project to be GPL? Oracle sells a commercial license.
MongoDB (before SSPL) — Used this model with AGPL + commercial option.
FFmpeg — Parts are LGPL, parts are GPL. If you need the GPL parts in a closed-source product, you need a separate agreement.

💡 When does this matter to you?

If you're using a dual-licensed library and the free license is copyleft, ask yourself: "Am I okay with my project being copyleft too?"

Yes → Use the free license. No problem.
No → You'll need to buy the commercial license. Budget for it.

As a freelancer, I've had to factor this into project estimates more than once. A "free" library isn't always free if your client needs a closed-source product.

Consider dual licensing for your own projects if: you want to keep the code open for the community but also generate revenue from companies that need proprietary terms.

License Compatibility: Can You Mix MIT and GPL?

This is where most developers mess up — and I'll be honest, I had to learn some of these the hard way while auditing dependencies in my own projects. Not all licenses play well together. Mix incompatible ones and you've got a legal problem.

The basic compatibility rules

Permissive → Copyleft = ✅ Generally OK
You can use MIT or Apache code inside a GPL project. The result will be GPL.

Copyleft → Permissive = ❌ Nope
You can't take GPL code and put it in an MIT project. Copyleft propagates upward.

GPL + AGPL = ⚠️ Careful
GPL v3 and AGPL v3 are compatible with each other. GPL v2 (without the "or later" clause) is not compatible with AGPL.

Apache 2.0 + GPL v2 = ❌ Incompatible
Apache 2.0 has patent clauses that clash with GPL v2. It is compatible with GPL v3 though.

How copyleft propagation actually works

Think of it like mixing paint. If you pour a drop of red paint (copyleft) into a bucket of blue paint (permissive), the entire bucket changes. You can't take the red out.

Your project (MIT) + Library A (MIT) + Library B (MIT) = Your project stays MIT ✅

Your project (MIT) + Library A (MIT) + Library B (GPL) = Your ENTIRE project becomes GPL 🔴

That second scenario catches a lot of people off guard. You didn't write the GPL code, you just used it as a dependency — but the copyleft still propagates to your whole project.

💡 Real example

You're building a commercial app. You pick 15 libraries, all MIT. Then you add one small utility library that happens to be GPL. Your entire app must now be GPL — meaning you have to publish your source code. If your business model depends on keeping the code closed, that one dependency just blew it up.

I've seen this happen in freelance projects. The fix is almost always painful: find an alternative library with a permissive license, or rewrite the functionality yourself.

Tip: check the license before adding any dependency. Tools like FOSSA, license-checker (npm), or pnpm licenses can audit your project for you. Make it a habit — future you will thank you.

5 Open Source Licensing Mistakes Developers Make

1. Not adding a license to your GitHub repo

"It's on a public GitHub repo, so it's open source."

Wrong. Without an explicit license, nobody has legal permission to use, copy, or modify your code. Public ≠ free to use. I've reviewed GitHub repos that had hundreds of stars but no license file — technically, none of those stargazers could legally use the code in their projects.

2. Using GPL code in a closed-source product

If you distribute software that includes a GPL dependency, your entire project must be GPL. This isn't hypothetical — it has real consequences. In 2008, Cisco had to release the source code for their Linksys router firmware after the Free Software Foundation found they were using GPL-licensed code (from the Linux kernel and other projects) without complying with the license terms. They settled the case and had to make the code available. A multi-billion dollar company, caught by a license they didn't take seriously.

3. Confusing source-available with open source

BSL, SSPL, and similar licenses are not open source according to the OSI. You can see the code, but you can't do whatever you want with it. If your README says "open source" and your license is BSL, that's misleading. This distinction matters — especially if your users or contributors care about open source principles.

4. Ignoring transitive dependencies and their licenses

Your project is MIT. But you use a library that depends on another library that's GPL. That chain of dependencies can change the rules without you even noticing. This is why automated license auditing tools aren't optional — they're essential. One npm install can pull in hundreds of transitive dependencies, each with its own license.

5. Assuming "non-commercial" means open source

Creative Commons licenses with an NC (Non-Commercial) clause are not open source. They're designed for content (text, images, music), not software. If you see a project on GitHub with a CC BY-NC license, you cannot use it in any commercial context — and it's not considered open source by the OSI definition.

AI Tools, GitHub Copilot, Claude Code, and Open Source Licenses

This deserves its own section because it's reshaping how we think about code ownership. If you use GitHub Copilot, Claude Code, ChatGPT, Cursor, or any other AI-powered coding tool, you need to understand what's happening under the hood.

Who owns AI-generated code?

This is genuinely uncharted territory. Current copyright law in most countries requires a human author for something to be copyrightable. If an AI generates a block of code, there's no clear human author — which means it might not be copyrightable at all.

What does that mean in practice? It's still being debated. Courts in different countries are reaching different conclusions. The safest approach for now: treat AI-generated code as if you wrote it yourself, and take full responsibility for it.

The training data problem

Here's where it gets tricky. Tools like GitHub Copilot were trained on publicly available code — including code under GPL, AGPL, MIT, and every other license. When Copilot suggests a code snippet, it might be reproducing (or closely paraphrasing) code from a GPL-licensed project.

If you accept that suggestion and put it in your closed-source app, are you violating the GPL? Nobody knows for certain yet. There are active lawsuits on exactly this question. In 2022, a class-action lawsuit was filed against GitHub, Microsoft, and OpenAI arguing that Copilot violates open source licenses by reproducing licensed code without attribution or license compliance.

What about AI coding agents like Claude Code?

AI coding agents (Claude Code, Copilot Workspace, Cursor Agent, etc.) can write entire files, modules, or even full applications. The license question gets more complex here because:

The tool's license — Claude Code itself is licensed under Apache 2.0. This means the tool is open source, but it doesn't say anything about the code it generates for you.
The generated code — Code that these tools write for you is generally considered yours. Anthropic's terms (and similar terms from other providers) typically grant you ownership of the output. But "ownership" doesn't resolve the question of whether the generated code might accidentally reproduce GPL-licensed patterns from the training data.
Your responsibility — Regardless of how the code was generated, you are responsible for the licenses in your project. If an AI tool writes code that looks suspiciously like a well-known open source library, you should verify the original license and comply with it.

Practical advice for developers using AI coding tools

Don't blindly accept large code blocks from AI tools without reviewing them. If a suggestion looks like it could be copied from a specific project, check.
Run license auditing tools on your project regularly — they won't catch AI-reproduced code directly, but they'll catch any dependencies you add.
Be especially careful with unique or distinctive code patterns. Generic patterns (a for loop, a REST endpoint) are fine. But if the AI outputs a complex algorithm that feels very specific, it might be reproducing someone's copyrighted work.
Check the terms of service of your AI tool. Most providers (Anthropic, OpenAI, GitHub) include clauses about code ownership and liability. Know what you're agreeing to.
When in doubt, rewrite. If you're unsure whether a generated block might have license implications, rewrite it in your own style. It's safer and you'll understand the code better anyway.

This whole area will keep evolving as courts rule on pending cases and as AI tools mature. Stay informed — the rules might be very different a year from now.

FAQ: Open Source Licensing for Solo Developers and Small Teams

If you work alone, build your own apps, and rely on third-party libraries and services, this section is for you. These are the real questions that come up day to day — answered without the legal jargon.

Can I use React (MIT) in my closed-source commercial app?

Yes, completely. MIT lets you use, modify, and distribute the code in commercial and closed-source projects. You just need to keep the copyright notice somewhere (usually a LICENSES file or an "about" section in your app). You don't need to open your code or pay anyone.

If I install a GPL library via npm, does my whole project become GPL?

It depends on whether you distribute your project. If your app is a SaaS running on a server and you never deliver the code to anyone, you're technically not "distributing" — so the GPL doesn't force you to open your code. But heads up: if it were AGPL instead, you would have to.

If you do distribute your app (upload to a store, package as a binary, ship to clients), then yes — your project becomes GPL.

Practical advice: if your project is closed-source, avoid GPL dependencies and look for MIT or Apache alternatives. In my experience, there's almost always a permissively licensed alternative for whatever you need.

Can I use code from Stack Overflow in my project?

Technically, you should give credit. All content on Stack Overflow is published under CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike). If you copy a code block, you should attribute it. For small snippets (a few lines), the real-world risk is minimal, but for substantial blocks, good practice is to credit the source.

Can I change my project's license from MIT to GPL?

Yes, with caveats. If you're the sole author, you can change the license whenever you want. Older versions you published under MIT stay MIT (anyone who already downloaded them keeps those rights), but new versions can be GPL.

If you have external contributors, you need consent from every single one of them to change the license — unless you set up a CLA (Contributor License Agreement) upfront that grants you those rights. That's why many large projects require a CLA before accepting contributions. It's also why the HashiCorp situation was possible — they owned the copyright, so they could change the license unilaterally.

Do Firebase, Supabase, Stripe, or AWS SDKs impose license obligations?

Client SDKs and libraries from these services are usually permissively licensed (MIT or Apache 2.0), so you can use them freely in closed-source projects. But always verify: go to the SDK's GitHub repo and check the LICENSE file. Don't assume the license based on the service name.

The Terms of Service (ToS) of the service itself are a separate thing — they define how you can use the platform, not the SDK code. I make it a habit to check both when integrating any third-party service into a project.

Can I charge money for software that uses open source libraries?

Absolutely. "Open source" does not mean "free of charge." You can charge for your software even if it uses open source libraries. What matters is respecting each license's conditions:

MIT / Apache / BSD libraries: Charge freely. Just give credit.
LGPL libraries: You can charge, but if you modify the library itself, those modifications must be open.
GPL libraries: If you distribute your software, the whole project must be GPL — meaning your code must be accessible. You can still charge, but anyone who gets your software has the right to see and redistribute the source.

Can I change the license if I fork an open source project?

Depends on the original license:

MIT / BSD / Apache: Yes. You can fork and relicense (even as closed-source), as long as you keep the original copyright notices.
GPL / AGPL: No. Your fork must keep the same GPL/AGPL license. That's the entire point of copyleft — and that's exactly what happened with OpenTofu. They could fork Terraform because the code was still under MPL at the time, but they couldn't have forked it if the code had always been BSL.
LGPL: Direct modifications to the library must stay LGPL, but the project using it can be closed.

Which open source license matters when building a SaaS?

This is the million-dollar question, and as someone who builds SaaS products, it's the first thing I check before picking any open source tool as a base. It depends on the project's license:

MIT / Apache / BSD: Full freedom. Run it as SaaS, modify it, keep everything closed.
GPL: As long as it's purely SaaS and you don't distribute the code, you're technically not required to open it. But this is a gray area that generates a lot of debate.
AGPL: You must publish your source code, including any modifications. This license was specifically designed for this scenario.
BSL: Check the specific terms. Usually you can't use it in commercial production during the restriction period without a separate commercial license.

Do open source licenses apply if I don't distribute my app?

Barely. If the software is for personal or internal use and you don't distribute it or offer it as a service, most open source licenses don't impose obligations beyond keeping copyright notices. Even the GPL won't force you to publish code if you never distribute the software.

The exception: if you run a network-accessible service (a website, an API, a backend) and use AGPL code, you must publish the source even though you're not "distributing" anything in the traditional sense.

Who is responsible for licenses in AI-generated code (Copilot, Claude Code, Cursor)?

This is the question everyone's asking right now. Short answer: you're responsible. The code the AI generates is considered yours (check your tool's ToS to confirm), but if that code happens to reproduce patterns from a GPL-licensed project in the training data, you could theoretically be on the hook.

Practical advice: use AI tools freely, but review the output. If something looks like it was lifted from a specific library, check the source. And always run your usual license auditing tools on the final project — AI-generated code isn't exempt from license compliance.

Which Open Source License Should You Pick? Decision Tree

Want maximum adoption?
├── Worried about patents?
│   ├── Yes → Apache 2.0
│   └── No → MIT
│
Want derivatives to stay free?
├── Is it a library?
│   ├── Yes → LGPL
│   └── No → GPL v3
│
Will your software run as SaaS?
├── Want contributors to give back?
│   ├── Yes → AGPL v3
│   └── No, but I want to protect my business → BSL
│
Want to protect your brand?
├── Yes → BSD 3-clause
│
Want open source + revenue from closed-source users?
└── Yes → Dual licensing (GPL/AGPL free + commercial option)

Useful Resources

choosealicense.com — GitHub's interactive guide for picking a license
tl;drLegal — License summaries in human-readable language
FOSSA — Automated license auditing for your dependencies
OSI Approved Licenses — The official list of approved open source licenses
OpenTofu — The Terraform fork born from a license change (a cautionary tale)

Wrapping Up

Remember that Terraform story from the beginning? HashiCorp built an incredible tool, grew a massive community, and then changed the license. The result: a split community, a competing fork, and years of trust gone in a single announcement.

Licenses aren't an afterthought. They're a promise to your users and your community. They define the relationship between your code and everyone who touches it.

Whether you're pushing your first repo or maintaining a project with thousands of users, take 5 minutes to understand the license you're choosing. It's one of the few decisions in software that's genuinely hard to undo.

What license do you use in your projects and why? Have you ever run into a licensing issue that caught you off guard? I'd love to hear your stories in the comments. 👇

If you found this useful, hit ❤️ and share it with someone about to push their first repo without a license.

Hexagonal Architecture in Plain JavaScript: Why I Use Objects as Interfaces (And Validate Them at Startup)

Juan Isidoro García Cifuentes — Wed, 25 Feb 2026 16:37:15 +0000

How do you enforce contracts between layers in plain JavaScript? This is how I implemented hexagonal architecture — ports and adapters — in a Node.js monolith without TypeScript.

This is the system I found. It's been running in production since last summer without a single issue.

If you're coming from the previous post in this series, I promised I'd talk about those interfaces with throw new Error('Not implemented'). Here we are.

The problem with importing everything directly

Early on, my code looked like every other Node.js project. Controllers imported Firestore directly. The customer service imported the WooCommerce API. Everything worked, but everything was glued together.

The moment I realized this was a problem: I wanted to support shops without WooCommerce. Shops that only manage data from the app, no external CMS. I searched for where WooCommerce was used and found it hardcoded all over the place.

If I wanted a shop to work without WooCommerce, I'd have to add if/else checks everywhere. That wasn't going to scale.

I needed a way to say: "this service needs something that can create customers, update them, and delete them — but it doesn't care if it's WooCommerce, Shopify, or nothing at all."

Drawing boundaries with plain objects

The solution was what Hexagonal Architecture calls "ports." In my case, they're plain JavaScript objects — not classes — with methods that throw if you don't implement them:

// modules/customers/core/ports/CustomerRepository.js

const CustomerRepositoryInterface = {
  createCustomer: async (shopId, customerData) => {
    throw new Error('Not implemented');
  },
  updateCustomer: async (shopId, customerId, updates) => {
    throw new Error('Not implemented');
  },
  findById: async (shopId, customerId) => {
    throw new Error('Not implemented');
  },
  findByEmail: async (shopId, email) => {
    throw new Error('Not implemented');
  },
  // ... 19 methods total
};

No inheritance. No abstract class. It's a contract: "this is what I expect you to know how to do."

The adapters, on the other hand, are classes — FirestoreCustomerRepository, WooCommerceCustomerAdapter. They implement the port's methods with real logic. Ports define the shape. Adapters do the work. That's the split.

I have three types of ports per entity:

Repository — the write side (Firestore)
ReadModel — the read side (Meilisearch or optimized queries)
CMSAdapter — the connection to the external CMS (WooCommerce, or nothing)

Each one defines its contract separately. The application service only knows the ports, never the concrete implementations.

But JavaScript won't tell you if a method is missing...

This is the real problem. You can build an adapter, implement 18 out of 19 methods, and JavaScript says nothing. Everything works great until someone calls the missing method in production.

My solution: validateImplementation(). Each port exports the list of required methods and a function that checks if an implementation has all of them:

// modules/customers/core/ports/CustomerRepository.js

const REQUIRED_METHODS = Object.keys(CustomerRepositoryInterface);

function validateImplementation(implementation) {
  const missingMethods = REQUIRED_METHODS.filter(
    method => typeof implementation[method] !== 'function'
  );

  if (missingMethods.length > 0) {
    throw new Error(
      `CustomerRepository missing methods: ${missingMethods.join(', ')}`
    );
  }
  return true;
}

Notice: REQUIRED_METHODS is derived from the interface object with Object.keys(). If I add a method to the port, it's automatically required in validation. No duplicate list to maintain — that was an early mistake I already fixed.

Now here's the important part — each adapter validates itself when Node.js loads the module:

// Bottom of FirestoreCustomerRepository.js, BEFORE module.exports

validateImplementation(FirestoreCustomerRepository.prototype);

It validates the .prototype of the class against the port's contract. Port is a plain object that defines the contract. Adapter is a class that implements it. The validation bridges the two.

If I forget a method, the app won't start. Not at 3am when a customer places an order. At startup. When I'm at my desk and can fix it in two minutes.

Dependency injection without a framework

With ports defined, application services receive their dependencies through the constructor. They don't know if there's Firestore, PostgreSQL, or a mock behind them:

// modules/customers/application/services/CustomerService.js

class CustomerService {
  constructor(dependencies) {
    this.customerRepository = dependencies.customerRepository;
    this.customerReadModel  = dependencies.customerReadModel;
    this.cmsAdapter         = dependencies.cmsAdapter;
    this.addressRepository  = dependencies.addressRepository;
    this.eventBus           = dependencies.eventBus;
    this.logger             = dependencies.logger || console;
  }
}

No Inversify. No IoC container. Just an object with dependencies.

And where does it all come together? In a factory that acts as the composition root:

// modules/customers/application/services/index.js

function createCustomerServices(dependencies) {
  const { customerRepository, customerReadModel,
          cmsAdapter, addressRepository, eventBus } = dependencies;

  const customerService = new CustomerService({
    customerRepository, customerReadModel,
    cmsAdapter, addressRepository, eventBus,
  });

  const addressService = new CustomerAddressService({
    addressRepository, customerRepository, eventBus,
  });

  return { customerService, addressService };
}

This is where you decide which concrete adapter goes to each port. The service never knows.

The Null Object that saved me

Back to the original problem: supporting shops without WooCommerce.

The bad option was adding if (shop.hasCMS) everywhere the adapter was called. The good option was creating a StandaloneCustomerAdapter — it implements the exact same port, but does nothing:

// modules/customers/infrastructure/adapters/StandaloneCustomerAdapter.js

class StandaloneCustomerAdapter {
  async syncCustomer(shopId, customer) {
    return { success: true }; // No CMS, nothing to sync
  }

  async *fetchAllCustomers(shopId) {
    // Empty generator — no external customers to fetch
  }

  getType() { return 'standalone'; }
  supports(feature) { return false; }
}

// Same validation pattern as every other adapter
validateImplementation(StandaloneCustomerAdapter.prototype);

And a factory that picks the right one based on the shop's config:

// modules/customers/infrastructure/adapters/CustomerAdapterFactory.js

function createCustomerAdapter(cmsType, shopId, options = {}) {
  switch (cmsType?.toLowerCase()) {
    case 'woocommerce':
      return getWooCommerceCustomerAdapter(shopId, options);
    case 'standalone':
    case null:
    case undefined:
      return getStandaloneCustomerAdapter(options);
    default:
      throw new Error(`Unsupported CMS type: ${cmsType}`);
  }
}

CustomerService doesn't know which adapter it gets. And it doesn't care. That's the whole point.

Tomorrow, if I want to add PrestaShop, I create a new adapter, register it in the factory, and zero application services change.

The honest part

It's not perfect. Without TypeScript you lose autocomplete and types on hover. That hurts day to day.

validateImplementation() only checks that methods exist as functions — it doesn't validate signatures, return types, or anything beyond "is the method there?" It's a basic safety net, not a type system.

Sometimes I wonder if I should have started with TypeScript from the beginning.

But for a solo dev, the simplicity of "an object with methods" outweighs full type safety. I don't have a team of 10 where someone can break a contract without realizing it. It's just me, and validating at startup is enough to catch my own mistakes.

It's been in production since last summer. Not a single missing method at runtime.

What's next

Now we have ports separating the write side from the read side, and adapters implementing them. But there's a missing piece — when I write to Firestore, how does Meilisearch find out?

The answer is the event system. And it has a two-level naming trick — domain events (ecommerce.*) and infrastructure events (firestore.*) — that solved the coupling problem in a way I didn't expect.

That's the next post.

Do you enforce interfaces at runtime, or does TypeScript give you enough confidence?

How I Ended Up Doing CQRS in a Node.js Monolith (Without Planning It)

Juan Isidoro García Cifuentes — Fri, 20 Feb 2026 09:47:25 +0000

📌 This is part 1 of a series on building event-driven architecture in a Node.js monolith. No microservices, no Kafka — just patterns that actually work at scale.

I didn't set out to implement CQRS. I'm a solo developer building a sync platform for e-commerce stores. Node.js, Express, Firestore. Nothing fancy.

But at some point, I needed search. Real search. With filters, facets, and sorting. And Firestore just... couldn't.

So I made a decision that changed my entire architecture without me even realizing it.

The moment it broke

Here's the thing about Firestore — it's great for writes. Atomic operations, real-time listeners, scales without thinking. I was happy with it.

Then the frontend came along and asked for this: "I need to search products by name, filter by three categories, sort by price, and show me how many results are in each status."

If you've tried doing this in Firestore, you know the pain. Composite indexes for every combination. Client-side filtering. Queries that kinda work but not really. I spent two days trying to make it happen before accepting it wasn't going to.

I needed a search engine. I went with Meilisearch.

Two stores, one problem

The moment I added Meilisearch, I had two data stores. Products lived in Firestore (my source of truth) and also in Meilisearch (for the frontend to query).

At first it was messy. Some parts of the code read from Firestore, some from Meilisearch. The logic for "where do I get this data?" was scattered everywhere.

So I did what any developer does when things get messy — I drew a line.

Drawing the line

I created two interfaces. Simple JavaScript objects with methods that throw 'Not implemented'. No TypeScript, no abstract classes. Just contracts.

The write side — ProductRepository:

const ProductRepositoryInterface = {
  saveProduct: async (shopId, productData, options) => {
    throw new Error('Not implemented');
  },
  updateStock: async (shopId, productId, stockData, options) => {
    throw new Error('Not implemented');
  },
  updatePrice: async (shopId, productId, priceData, options) => {
    throw new Error('Not implemented');
  },
  deleteProduct: async (shopId, productId, options) => {
    throw new Error('Not implemented');
  },
  // 12 methods total
};

The read side — ProductReadModel:

const ProductReadModelInterface = {
  listProducts: async (shopId, query) => {
    throw new Error('Not implemented');
  },
  searchProducts: async (shopId, query, options) => {
    throw new Error('Not implemented');
  },
  getProductStats: async (shopId) => {
    throw new Error('Not implemented');
  },
  checkSKUExists: async (shopId, sku, excludeProductId) => {
    throw new Error('Not implemented');
  },
  // 5 methods total
};

12 write methods. 5 read methods. Zero overlap.

That's it. That's CQRS.

Why it matters (practically)

This isn't about architecture buzzwords. It's about not going crazy when your codebase grows.

Before the split, I had this constant question: "where does this data come from?" After the split, it's obvious:

Mutating something? → ProductRepository → Firestore
Querying something? → ProductReadModel → Meilisearch

Each store gets to be good at what it's good at:

	Write Side (Firestore)	Read Side (Meilisearch)
Good at	Atomic writes, real-time	Full-text search, facets
Data shape	Normalized, nested	Denormalized, flat
Consistency	Strong	Eventual

The write side doesn't import Meilisearch. The read side doesn't import Firestore. They don't know about each other. And that's the whole point.

The catch: eventual consistency

I won't pretend this is free. There's a cost.

When I save a product to Firestore, it doesn't appear in search results immediately. There's a projection system that picks up the change and syncs it to Meilisearch. Usually takes a few seconds.

For a management platform where admins are editing products, a few seconds is fine. For a customer-facing checkout page? Probably not. Know your context.

I'll go deeper into how the projection system works in a later post. For now, just know it exists and it's the glue between the two sides.

The thing nobody tells you

I read about CQRS months after I implemented it. I was looking at my codebase one day and thought "wait, this is that pattern from the DDD book."

I think that's actually the best way to learn architecture patterns. Not by reading about them first and trying to force them into your code. But by solving a real problem and then discovering the pattern has a name.

The best patterns don't feel like patterns. They feel like common sense.

What's next

In the next post, I'll talk about those throw new Error('Not implemented') interfaces. Why I use plain JavaScript objects as port definitions, how I validate them at startup, and why I chose this over TypeScript interfaces for my use case.

If you've ever split your reads and writes — on purpose or by accident — I'd love to hear what triggered it. Was it search? Was it performance? Something else?

AI agents are wasting 90% of tokens on your navbar — I built a protocol to fix it

Juan Isidoro García Cifuentes — Thu, 19 Feb 2026 08:31:06 +0000

The Problem Nobody Talks About

I was spending hundreds of dollars on AI API calls. Half of it wasn't buying me useful information — it was paying to process navigation bars, cookie banners, and inline scripts.

A typical e-commerce product page? 47,000 tokens. The useful product information? ~300 tokens.

In many cases, over 90–99% of the processed tokens are structural or navigational noise.

I kept thinking: what if the server could just... give the agent what it needs?

Enter MAKO

MAKO (Markdown Agent Knowledge Optimization) is an open protocol that uses standard HTTP content negotiation to serve AI-optimized content.

The idea is dead simple:

An AI agent sends Accept: text/mako+markdown in its request header
The server detects this header
Instead of HTML, it responds with structured markdown + YAML frontmatter
The agent gets exactly what it needs in ~280 tokens

No new endpoints. No special APIs. Just HTTP, the way it was designed.

MAKO does not replace HTML. Browsers still receive HTML.
Only agents explicitly requesting text/mako+markdown receive the optimized version.

What a MAKO Response Looks Like

---
mako: "1.0"
type: product
entity: "Nike Air Max 90"
updated: "2026-02-10"
tokens: 280
language: en
summary: "Mid-range running shoe, 47% off"
links:
  - url: /running-shoes
    context: "Browse all running shoes"
actions:
  - name: add_to_cart
    description: "Add to shopping cart"
    endpoint: /api/cart/add
---

# Nike Air Max 90

## Key Facts
- Price: €79.99 (was €149.99, -47%)
- In stock (23 available)
- Sizes: 38-46
- Rating: 4.3/5 (234 reviews)

## Overview
Casual running shoe, mid-range. Leather/mesh upper.
Competitors: Adidas Ultraboost (€129), NB 1080 (€139).
Strong point: price. Weak point: narrow fit per reviews.

Why Not Just Scrape HTML?

Scraping pushes complexity to the client.
MAKO moves structure to the source.

Instead of:
Agent → Parse DOM → Remove noise → Infer structure

You get:
Agent → Receive structured semantic content

Lower token cost. Clear semantic boundaries. Deterministic machine-readable structure.

These numbers come from real-world pages measured using GPT tokenization.
Exact savings depend on site structure, but the pattern is consistent.

The Numbers

Page Type	HTML Tokens	MAKO Tokens	Savings
E-commerce product	47,000	280	99.3%
Blog article	35,000	670	98.1%
Documentation	38,000	980	97.4%
Landing page	110,000	640	99.4%

You can see a real generated MAKO page here:
👉 https://makospec.vercel.app/en/p/aZo89_kQ

How to Implement It

Using the SDK

npm install @mako-spec/js

import { MakoGenerator, MakoParser } from '@mako-spec/js';

// Generate a MAKO file
const generator = new MakoGenerator();
const mako = generator.generate({
  type: 'product',
  entity: 'Nike Air Max 90',
  language: 'en',
  body: '# Nike Air Max 90\n\nCasual running shoe...',
  links: [{ url: '/running', context: 'More running shoes' }],
  actions: [{ name: 'add_to_cart', description: 'Add to cart' }]
});

// Parse a MAKO file
const parser = new MakoParser();
const result = parser.parse(makoContent);
console.log(result.frontmatter.entity); // "Nike Air Max 90"

Express Middleware (3 lines)

import { makoMiddleware } from '@mako-spec/js/middleware';

app.use(makoMiddleware({
  getContent: async (req) => {
    // Return your MAKO content for this URL
    return await fetchMakoForUrl(req.path);
  }
}));

Free Tools

MAKO Score — Audit any site's AI-readiness (0-100). Checks 30 criteria across 4 categories.
MAKO Analyzer — Paste any URL and see the generated MAKO output + token savings.
WordPress Plugin — Full WooCommerce support, AI generation with your own API key.

How MAKO Fits In

Tool	Scope	MAKO Difference
llms.txt	1 file per site	MAKO: 1 file per page
Cloudflare MD	Auto-converted HTML	MAKO: Semantically optimized
Schema.org	For search engines	MAKO: For AI agents
WebMCP	Actions only	MAKO: Content + actions + context

MAKO is complementary — it works alongside all of these.

Why This Matters

AI agents are becoming a first-class web audience.

If search engines needed HTML, AI agents need structured representations.

The web evolved once for browsers. It's evolving again for agents.

Visually, the difference looks like this:

Traditional Web Flow

Browser   → HTML → Rendered Interface → Human
AI Agent  → HTML → DOM Parsing → Layout + Navigation + Script Overhead

With MAKO

Browser   → HTML → Rendered Interface → Human
AI Agent  → MAKO → Structured Semantic Content → Deterministic Extraction

Open Source

Everything is Apache 2.0 licensed:

Spec: github.com/juanisidoro/mako-spec
JS SDK: npmjs.com/package/@mako-spec/js
CLI: npmjs.com/package/@mako-spec/cli
WordPress: github.com/juanisidoro/mako-wp
Website: makospec.vercel.app

I'd love your feedback — on the protocol design, the scoring system, or anything else. Star the repo if you find it useful.

How are you handling web content extraction in your AI apps right now? Drop it in the comments.