Open-source license cheat sheet for vibe coders
Open-source licenses range from "use freely, even commercially" to "if you ship this on the network, your entire app's source must be public." AI coding tools reproduce code from all of them with no license headers attached. The license obligations travel with the code anyway. This is the cheat sheet you can reference when something flags in a scan or shows up unexpectedly in a dependency tree.
The big picture
OSS licenses sort onto three rough buckets: permissive (do almost anything), weak copyleft (share modifications, keep your app private), strong copyleft (share modifications AND your derivative app). A fourth bucket — non-OSS source-available licenses (SSPL, BSL, Commons Clause) — looks open but isn't really, and trips up founders who assume it is.
Permissive licenses (use freely)
MIT
The most popular OSS license, period. Requirements: include the original copyright notice and the MIT license text when you redistribute. That's it. You can use MIT code in proprietary commercial products, modify it, sublicense it, sell it. Most of npm is MIT. AI tools reproduce MIT code freely; the only obligation is the attribution notice. If you've never published a third-party-notices file, you're technically missing it — but enforcement on this point is essentially nil for typical apps.
Apache 2.0
Slightly more formal than MIT. Same permissive use, plus an explicit patent grant (Apache contributors grant you a patent license for their contributions), explicit attribution requirements, and a requirement to note significant changes. Use case where Apache matters more than MIT: anything where patent issues might arise (database engines, codecs, cryptographic primitives). Common in big-company OSS — Kubernetes, Spark, Cassandra, TensorFlow are all Apache.
BSD-2-Clause / BSD-3-Clause / ISC
Essentially equivalent to MIT with minor wording differences. 2-Clause is the simplest, 3-Clause adds a no-endorsement clause (you can't use the original authors' names to promote your derivative product without permission). ISC is a simplified BSD-2 variant. For practical purposes, treat all three like MIT.
0BSD / Unlicense / CC0
Public-domain-equivalent. No attribution required. Use freely. Rare in major OSS projects but increasingly used for individual utilities and configuration templates.
Weak copyleft (share library modifications)
LGPL-2.1 / LGPL-3.0
Lesser GPL. If you modify the LGPL'd library itself, you must share those modifications under LGPL. But your own code that links to (uses) the library can stay proprietary. Practical: dynamic linking is generally fine; static linking has caveats. LGPL is rare in pure-JS ecosystems (everything's effectively statically bundled), more common in C/C++ libraries.
MPL-2.0
Mozilla Public License. File-level copyleft: if you modify an MPL'd file, that specific file must be open-sourced under MPL. Files you add separately can be any license. Cleaner conceptually than LGPL for mixed codebases. Used by Firefox, Rust, several Servo crates.
EPL-2.0 / CDDL
Eclipse Public License + Common Development and Distribution License. Both file-level copyleft like MPL. EPL common in Java tooling (Eclipse IDE, Jetty); CDDL was Oracle's preferred license for old OpenJDK/OpenSolaris.
Strong copyleft (share derivative apps)
GPL-2.0 / GPL-3.0
If you distribute a binary derived from GPL'd code, you must distribute the source code of your entire derivative work under GPL. "Distribute" is key — internal use and SaaS-only deployment doesn't trigger the obligation. This is the "ASP loophole." GPL-3.0 adds: a patent grant, anti-tivoization (your hardware can't lock the user out of running modified versions), and explicit anti-DRM language.
AGPL-3.0
Closes the ASP loophole. If you operate a modified version of AGPL'd code as a network service, you must offer the source code to every user of that service. SaaS counts. This is the only common license where simply running an app triggers source-disclosure obligations. Notable AGPL projects in JS ecosystem: Grafana (relicensed 2024), Plausible self-hosted, Element Web, Ghost CMS.
Deep dive: What happens if your AI-built app uses AGPL code →Source-available (looks open, isn't)
SSPL (Server Side Public License)
Mongo's license post-2018. If you offer the SSPL'd software "as a service," you must also publish the source of all programs you use to run the service. Most cloud providers won't touch SSPL because compliance is essentially impossible. Not OSI-approved. Don't include SSPL code in a SaaS unless you've actually read the implications and decided it's fine.
BSL / BUSL (Business Source License)
Time-delayed open source. Code starts proprietary; after a change date (typically 3-4 years), it converts to a permissive license. Used by CockroachDB, MariaDB MaxScale, Sentry, HashiCorp Terraform (since August 2023). During the proprietary phase, restrictions vary by project — usually you can't offer the software as a competing service.
Commons Clause + permissive base
Permissive license (typically Apache 2.0) plus a rider banning commercial "selling" of the software. Used by Redis (until they switched), Elastic (before they switched), and several others. Not OSI-approved. Compliance turns on whether your use counts as "selling" the software, which is fact-specific.
What AI tools commonly reproduce, and what to watch for
- Snippets that look like Lodash, Ramda, date-fns helpers — almost always MIT or BSD. Safe to use, attribution recommended.
- Snippets that look like React internals — MIT. Same.
- Snippets that look like Apollo Server, Apollo Client — MIT. Same.
- Snippets that look like Three.js — MIT. Same.
- Snippets that look like Mermaid, jsxgraph, or visualization libraries — sometimes LGPL or AGPL. Check before bundling.
- Snippets that look like CMS templates — sometimes Ghost CMS (AGPL) or WordPress (GPL). If a chunk of CMS code shows up in your bundle and you can't identify the source, scan.
- Snippets that look like analytics dashboards — sometimes Grafana (AGPL since 2024). Audit.
License compatibility
Some licenses can be combined; some can't. Quick guide:
- Permissive (MIT, Apache, BSD) + anything → fine. Permissive code is compatible with everything.
- Permissive + GPL → fine, but the combined work must be GPL-licensed.
- MPL + GPL/LGPL → tricky historically, but MPL 2.0 explicitly added compatibility with GPL/LGPL.
- AGPL + GPL → fine, with attention to network-use obligations.
- Apache 2.0 + GPL-2.0 → NOT compatible (patent retaliation clauses conflict). GPL-3.0 fixed this; Apache 2.0 + GPL-3.0 is compatible.
- SSPL + anything proprietary → essentially impossible to comply with.
Practical guidance
- Most vibe-coded apps run on a 99% MIT/Apache/BSD dependency tree. Generate a license report with `npx license-checker --production` to confirm.
- If anything reports as AGPL, GPL, LGPL, MPL, SSPL, or "UNKNOWN" — investigate. Most often these are LGPL libraries used for visualization or CMS-adjacent functionality.
- Bundle-scan in addition to tree-scan. Tree-scanning catches packages you installed; bundle-scanning catches code your AI tool reproduced from a copyleft project without preserving the license header.
- If you're shipping commercial SaaS, the safe-list is: MIT, Apache 2.0, BSD, ISC, 0BSD, MPL 2.0 (with file-level attention), LGPL (with caveats). Everything else needs an explicit decision.
Common questions.
Do I have to publish a third-party-notices file?
Technically yes, for MIT/Apache/BSD code in your distributed bundle — those licenses require the attribution and license text to travel with redistributions. Practically, enforcement on this is essentially nil for typical web apps; you mostly see it enforced when a project gets acquisition diligence or community attention. Generate the file with `license-checker --production --json` and ship it on a `/licenses` page; it's cheap insurance.
What if a dependency has license "UNKNOWN"?
Investigate. Most often it's a small utility with a missing or non-standard LICENSE file. Reach out to the maintainer; if no response, replace with an alternative that has a clear license. Don't ship code with unknown license terms — at acquisition diligence, that's a red flag that delays deals.
Are GitHub repos automatically MIT?
No. A GitHub repo with no LICENSE file is default-copyrighted ("all rights reserved") — meaning you have no rights to use, copy, or distribute it, regardless of the fact that the code is public. Always check for an actual LICENSE file before depending on a repo.
Can my AI tool tell me a snippet's original license?
Not reliably. Most AI coding tools don't preserve provenance information from training data. GitHub Copilot has a setting to suppress suggestions matching public code, which sometimes helps. Cursor, Lovable, Bolt don't have equivalents as of 2026. Bundle-scanning is the practical detection mechanism.