Soft Skills & Ecosystem Deep Dive · 7 of 12

Open Source & Licensing — Read Before You npm install

Almost every modern app stands on a tower of open-source libraries. The license attached to each one is a contract: what you're allowed to do with it, what you must give back, and what you must disclose. Most are friendly; a few will reshape your business model. This is not legal advice — but knowing the families avoids surprises.

MITApache 2.0GPL / AGPLBSL / SSPLSBOMOSI
← Back to Soft Skills & Ecosystem
The Families

What Each License Actually Means

LicenseFamilyPractical meaning
MITPermissiveUse, modify, ship — keep the copyright notice. Almost no obligations.
BSD (2-/3-clause)PermissiveLike MIT; 3-clause adds "no endorsement" clause.
Apache 2.0Permissive + patent grantSame as MIT plus an explicit patent license. Required by some corporate legal teams.
ISCPermissiveFunctionally equivalent to MIT.
LGPLWeak copyleftLinking is OK; if you modify the LGPL'd code itself, those changes go back.
MPL 2.0File-level copyleftChanges to MPL-licensed files must be open-sourced; surrounding code stays yours.
GPL v2 / v3Strong copyleftIf you distribute software incorporating it, the whole thing must be GPL too.
AGPL v3Network copyleftEven running it as a network service triggers the obligation. SaaS-killer for most companies.
BSL / SSPLSource-available, not OSI-approvedFree for most uses; restricted for cloud-vendor competitors. Used by Elastic, MongoDB, HashiCorp, Sentry.
Creative CommonsContent licensesFor docs, images, datasets — not source code.
Unlicense / CC0 / WTFPLPublic-domain dedication"Do whatever." Some corporate legal teams won't accept these — they prefer explicit grants.
Compliance

What You Actually Need to Do

  • Bundle the LICENSE file. All permissive licenses require the original notice ship with binaries. NOTICES file in your release.
  • Generate an SBOM. Software Bill of Materials — list every dep + version + license. cyclonedx, syft, or your build tool.
  • Scan in CI. FOSSA, Snyk, Dependency-Track, license-checker — fail builds on disallowed licenses.
  • Maintain an allowlist. Define what your shop accepts (typically MIT/BSD/Apache/ISC; LGPL with caveats; case-by-case for copyleft).
  • Preserve attribution in About screens for distributed apps (mobile, desktop, browser extensions).
  • Re-licensing & CLAs. If you accept community PRs, decide upfront whether you require a CLA or DCO.
The 2020s Plot

The Re-licensing Wave

A growing list of OSS projects have pivoted from permissive licenses to source-available ones (BSL, SSPL, ELv2) — Elastic in 2021, MongoDB earlier, HashiCorp's Terraform in 2023, Sentry, Akka. The trigger is usually "AWS / GCP is selling our software as a managed service without contributing back." Each pivot has triggered an OSS fork (OpenSearch, OpenTofu, Valkey).

  • If you depend on it, know the license you adopted vs the current one.
  • If you build a product around it, watch for the fork — the OSS branch may diverge in features.
  • "Source-available" ≠ open source by OSI definition. Don't conflate.
Tradeoffs

Pitfalls

  • "It's on GitHub, so it's free." No — check the LICENSE file. No license = all rights reserved.
  • Transitive licenses. Your direct dep is MIT; its dep is GPL; you may still inherit obligations.
  • Static vs dynamic linking matters for LGPL — get legal review for distributed binaries.
  • "Free for non-commercial." That's not OSS; treat it as proprietary with a license fee.
  • Forks may not match upstream license. Verify the fork's license, not just the original's.
  • Get legal involved early for any non-permissive choice in a commercial product.
Continue

Other Soft Skills & Ecosystem Topics

← Debugging Mindset Documentation → Community Sites → Portfolio → ↑ Back to Soft Skills & Ecosystem