Sales and Marketing Training

Open Source Licenses Explained: What Each Type Actually Allows

You can ship a marketing stack without ever opening a LICENSE file. A contractor drops a GitHub repo into the CMS. A designer grabs a photo. An engineer vendors a JavaScript package. Someone on the AI team downloads model weights because the README said open. Then counsel asks whether you can put that code inside a paid SaaS product, and the honest answer is that nobody read the grant.

Copyright is the default. Software, docs, photos, and model cards are all-rights-reserved until a license says otherwise. An EULA is a contract that usually takes rights away. An open-source license is a copyright grant that gives rights back, with conditions. Mix the wrong grant into WordPress, a hosted app, or a proprietary API, and you do not get a friendly warning. You get an obligation to publish source, drop a patent claim, or stop distributing the combined work.

This is a field guide to 22 identifiers you will actually see in GitHub sidebars, npm, PyPI, and Creative Commons deeds. The names are SPDX short codes, the same strings license scanners and SPDX-License-Identifier: headers use so humans and tools mean the same text. It is not legal advice. It is the map marketers and product teams need before they treat open as a synonym for unrestricted.

Four Families, Not 22 One-Offs

OSS and FOSS are not one license. They are a family of grants that all publish source and allow reuse, then split on what you must give back. Three stewards set the vocabulary, and they are not interchangeable. The Open Source Initiative maintains a definition and an approval list. The GNU Project’s Free Software Foundation scores the four freedoms (run, study, share, improve) plus copyleft and GPL compatibility. Creative Commons licenses copyright in content. It does not write software licenses, and it says so in public.

Once you can see the family, the 22 texts stop looking like trivia:

  • Permissive: use, modify, and ship inside proprietary products. Keep notices. Usually no copyleft.
  • Weak copyleft: the library or file stays under the same license. The larger application can often stay closed if you follow linking or file-level rules.
  • Strong copyleft: a combined work you distribute must come with corresponding source under the same license. The Affero variant also treats network use as the trigger.
  • Public-domain equivalent: the author tries to waive copyright, or writes a license so short it asks for nothing, including attribution.
  • Creative Commons: built for articles, images, video, and data. Not a substitute for a software license.

Two other details decide most real arguments. First, a patent grant is either written into the license or silent. Silent does not mean you have a patent license. Second, GNU licenses are not one identifier. SPDX requires a version plus only versus or later because that fork is how Linux and WordPress ended up in different worlds.

Permissive Licenses

These are the default for libraries you want other people to embed. Commercial use, modification, distribution, and private use are all allowed. Conditions are notices, and sometimes a patent clause or a do not pretend you wrote this rule.

  • Apache License 2.0 (Apache-2.0): The Apache Software Foundation’s 2004 license, and the corporate-friendly permissive default. You get an explicit patent grant from contributors, and that grant terminates if you sue over the work. Keep the license text, mark modified files, preserve NOTICE if upstream ships one, and do not treat the name as a trademark grant. It is compatible with GPL-3.0 but not GPL-2.0-only, which is why you cannot drop Apache-only code into the Linux kernel. Kubernetes, Swift, and ASF projects use it when they want a patent grant without copyleft.
  • Artistic License 2.0 (Artistic-2.0): The Perl Foundation’s 2006 rewrite of Artistic 1.0, which the FSF considered too vague to recommend. Version 2.0 is OSI-approved, FSF-free, and GPL-compatible through a relicensing option in section 4(c)(ii). You must keep the Standard Version distinguishable: give changes back, or rename and document diffs, or offer source under the original or another no-fee-source license. There is an explicit patent grant. Perl 5 itself is still Artistic 1.0 or GPL. Outside Perl modules, this is not a general-purpose default.
  • Boost Software License 1.0 (Boost-1.0): SPDX lists this as BSL-1.0, dated 17 August 2003, written for the Boost C++ libraries. Permissive and GPL-compatible. The distinctive rule: the copyright and license statement must travel with source copies, but not with machine-executable object code a compiler emitted. That is why native libraries like it. Catch2 and the Digital Mars D compiler are other listed users. Still patent-silent.
  • BSD 2-Clause (BSD): The Simplified or FreeBSD form. Same idea as 3-clause with the endorsement clause removed, so it sits next to MIT and ISC in practice. Homebrew is a well-known user. Still no patent grant. Use it when you want BSD wording and MIT-level brevity.
  • BSD 3-Clause (BSD): The New or Revised Berkeley license. Keep copyright, conditions, and disclaimer in source and in binary documentation, and do not use names to endorse derived products without permission. It is GPL-compatible. Don’t treat the BSD license as a single text. The original four-clause advertising requirement is a different, GPL-incompatible identifier. Flutter and LevelDB are typical 3-clause projects. Pick it when you want MIT-like reuse with a no-endorsement clause.
  • Fair License (Fair): OSI-approved and almost unused. The operative text is two sentences: keep this instrument with the works so users see it, and the works are without warranty. No patent grant, no FSF listing in the usual GNU software catalog, no reason to pick it over MIT or Apache. It is here because SPDX lists it and scanners will show the id.
  • ISC License (ISC): Internet Systems Consortium’s ultra-short permissive text, also associated with OpenBSD. Functionally MIT or BSD-2. Keep the copyright and permission notice. The historical and versus and/or wording was a real dispute. Current ISC text uses and/or. Node’s semver package and other small tools ship it. Fine for tiny libraries. Not a reason to avoid Apache on a larger product that needs a patent grant.
  • MIT License (MIT): The short permissive grant GitHub, npm, and most JavaScript packages treat as the default. Keep the copyright and permission notice in copies and substantial portions. There is no explicit patent grant, which is why the Free Software Foundation still prefers Apache for substantial programs. The FSF also warns that MIT License is ambiguous because MIT has shipped more than one text. The template everyone actually pastes is the Expat variant, not the older X11 name clause. Babel, Rails, .NET, and React (since version 16) publish under it.
  • zlib License (Zlib): The grant that ships with the zlib compression library. You may use it freely, including in proprietary products, if you do not misrepresent the origin, you mark altered source as altered, and you do not strip the notice from source distributions. Acknowledgment in a product is appreciated, not required. GPL-compatible, patent-silent, and the ancestor of a lot of native codec licensing. The state changes rule is about honesty, not Apache-style file banners.

Weak Copyleft

These licenses insist that their files or libraries stay open, without automatically forcing the entire surrounding application under the same terms. Teams often get surprised by the details of linking, files, and secondary licenses.

  • Common Development and Distribution License 1.1 (CDDL): Sun’s MPL-derived file-level copyleft, later stewarded by Oracle. Version 1.0 is the OSI-listed text. 1.1 adds Oracle as steward and a patent-infringement termination clause. Covered source stays CDDL. Larger works and executables can use other terms. The FSF’s standing warning still matters: a GPL module and a CDDL module cannot legally be linked. That is the ZFS-on-Linux split. GlassFish historically dual-licensed CDDL and GPL. Stay in this family only if you already live in it.
  • Eclipse Public License 2.0 (EPL): The Eclipse Foundation’s 2017 weak copyleft, used across Eclipse IDE tooling, hawkBit, and openHAB. Source stays EPL. Binaries may use other licenses that preserve source rights. Contributors grant patents, and a patent lawsuit against the Program terminates that grant. Commercial distributors indemnify other contributors. GPL compatibility exists only if the initial contributor names GPL-2.0-or-later as a Secondary License in Exhibit A. Without that exhibit, FSF still treats EPL as GPL-incompatible. The secondary list is narrower than MPL’s.
  • GNU Lesser General Public License v2.1 (LGPL): February 1999, successor to the Library GPL. The library and works based on the library stay under LGPL. A work that uses the Library may link under other terms if you meet the relink and source conditions, which is why proprietary applications can ship against glibc. Static linking is still a combined work. You may relicense a copy under GPL-2. The FSF treats LGPL as a special case, not the default for new GNU libraries. Compatible with both GPL-2 and GPL-3.
  • GNU Lesser General Public License v3.0 (LGPL): 29 June 2007, written as additional permissions on top of GPL-3.0. Same library pattern, plus GPL-3’s patent grant and, in some User Product cases, installation information so users can relink. It is not compatible with a GPL-2.0-only tree. Choose this when you want LGPL linking rules aligned with GPL-3, not when you need to live inside the Linux kernel license.
  • Mozilla Public License 2.0 (MPL): Mozilla’s January 2012 file-level copyleft. Modified MPL files stay MPL, and you must offer source for those files. A Larger Work may be proprietary. It includes an explicit patent grant, which terminates if you sue. By default MPL-2.0 is compatible with GPL, LGPL, and AGPL as secondary licenses. Exhibit B opts out of that, and those files are not GPL-compatible. Firefox-style projects (Servo, Syncthing) use it when they want reciprocity on their files without infecting the rest of the app.

Strong Copyleft

Distribute a combined work, and the corresponding source has to travel with it under the same license. Hosting the software as a network service is a different question, which is why the Affero variant exists and why some vendors later wrote licenses the Open Source Initiative has not approved.

  • GNU Affero General Public License v3.0 (AGPL): 19 November 2007. GPL-3, plus section 13: if users interact with your modified version over a network, you must offer corresponding source from a network server at no charge. That is the SaaS loophole closer. Grafana, Mastodon, and Nextcloud Server are current examples. MongoDB Community Server used AGPLv3 until 16 October 2018, then moved to the Server Side Public License. SSPL is based on GPL-3 but is not OSI-approved, and its extra clause reaches management UI, APIs, monitoring, backup, and hosting, not just the program’s corresponding source. If you need an OSI license for hosted software, AGPL is the one. SSPL is a different bet.
  • GNU General Public License v2.0 (GPL): June 1991, still the license of the Linux kernel as GPL-2.0-only plus the Linux-syscall-note. WordPress is GPLv2 or later. That one phrase is why a WordPress plugin can accept inbound GPL-3-compatible code and the kernel cannot. Copyleft triggers on distribution of a work based on the Program, not on mere network use. There is no Apache-style patent grant. Section 7 is the patent-trap you may not distribute clause. Apache-2.0 is incompatible with GPL-2.0-only. Discourse, Jellyfin, and OBS Studio are typical application users. WordPress.org’s plugin directory requires GPL-compatible licensing, and strongly recommends GPLv2 or later, for all code, data, and images in the hosted plugin.
  • GNU General Public License v3.0 (GPL): 29 June 2007. Strong copyleft plus an explicit patent grant, anti-circumvention waiver, and installation information for User Products (the anti-Tivoization rule). Compatible with Apache-2.0. Not compatible with GPL-2.0-only. Ansible, uBlock Origin, and a large share of GNU userland use it. The GNU GPL family still does not let you drop the program into a proprietary binary and close the result. Always write -only or -or-later in SPDX. The bare GPL-3.0 identifier is treated as only.

Public Domain Equivalents

These try to put the work as close to no copyright conditions as the law allows. They do not grant patents. They are a poor fit when you need the Apache patent language, and a good fit for samples, data, and snippets.

  • BSD Zero Clause License (BSD): ISC with the notice requirement removed. OSI-approved, FSF-free with caveats, used by toybox. You are not required to keep copyright or license text, which is the point, and also the risk. The FSF warns that if those notices disappear, later users cannot safely rely on the grant. Prefer it for snippets when you truly want zero conditions, and keep the notices anyway.
  • Creative Commons Zero 1.0 (CC0): A waiver of copyright to the maximum the law allows, plus a fallback public-domain-style license where the waiver fails. The deed is explicit: patent and trademark rights are not affected. Creative Commons and the FSF both treat CC0 as acceptable for software and GPL-compatible. SPDX does not mark it OSI-approved. WordPress theme review treats CC0 as suitable for images. Use it when you want the lawyered public-domain tool, not when you need a patent grant.
  • The Unlicense (Unlicense): A public-domain dedication plus a backup lax license, published at unlicense.org and offered in GitHub’s license chooser. OSI-approved and GPL-compatible. The opening line is the point: “This is free and unencumbered software released into the public domain.” Dedications are jurisdiction-fragile, which is why the fallback exists and why some projects pick CC0 instead. No patent grant. kakoune and several small libraries use it.

Creative Commons Is for Content

Creative Commons is the right tool for the article, the diagram, the podcast, and the dataset. It is the wrong tool for the plugin. Version 4.0 of the suite shipped in November 2013 as international licenses, replacing the older country-ported 3.0 texts. None of them license patents. None of them require corresponding source. WordPress.org’s plugin and theme directories have treated CC licenses as incompatible with GPL since a 2012 core policy note.

We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available.

Creative Commons FAQ
  • CC Attribution 4.0 (CC-BY): Reuse, including commercially, if you give attribution, link the license, say whether you changed the work, and do not add extra legal or technical restrictions. That is the correct grant for a photo, an explainer, or a government dataset you want quoted. It is not a substitute for MIT on a JavaScript library.
  • CC Attribution-ShareAlike 4.0 (CC-BY-SA): Attribution plus share-alike. Adaptations must go out under BY-SA or a later/compatible BY-SA license. Wikipedia and Wikimedia content live here. ShareAlike is copyleft for creative works. It is not GPL copyleft, and it does not make a plugin directory safe. There is a one-way compatibility story between BY-SA 4.0 and GPL-3 for mixed content-into-code edge cases. That is not a reason to license application source as CC-BY-SA.

What Each License Actually Allows

Scan this table when a dependency’s SPDX id shows up in a lockfile or a screenshot tool’s footer. Silent under patents means the license does not grant one. File copyleft means modified files stay open. Network means offering the program as a service is the trigger.

SPDX idFamilyCopyleftPatent grantTypical use
MITPermissiveNoneSilentLibraries, JS, SDKs
Apache-2.0PermissiveNoneExplicitCorporate / cloud code
BSD-3-ClausePermissiveNoneSilentBSD-heritage projects
BSD-2-ClausePermissiveNoneSilentSimplified BSD / FreeBSD
ISCPermissiveNoneSilentTiny MIT-equivalent grants
Boost-1.0 (BSL-1.0)PermissiveNoneSilentC++ libs, binaries
ZlibPermissiveNoneSilentCompression / native codecs
FairPermissiveNoneSilentRare; prefer MIT
Artistic-2.0Permissive (artistic)NoneExplicitPerl modules
LGPL-2.1Weak copyleftLibrary linkingSilentglibc-style libraries
LGPL-3.0Weak copyleftLibrary linkingExplicitLGPL aligned with GPL-3
MPL-2.0Weak copyleftFileExplicitFirefox-style file reciprocity
CDDL-1.1Weak copyleftFileExplicitOpenSolaris / Java EE lineage
EPL-2.0Weak copyleftModule / sourceExplicitEclipse tooling
GPL-2.0Strong copyleftWhole work on distributionSilentLinux, WordPress
GPL-3.0Strong copyleftWhole work on distributionExplicitGNU apps, GPL-3 projects
AGPL-3.0Strong copyleftWhole work + networkExplicitHosted apps you will not let others close
CC0-1.0Public-domain equivalentNoneNot grantedData, samples, PD-like code
0BSDPublic-domain equivalentNoneSilentSnippets, zero conditions
UnlicensePublic-domain equivalentNoneSilentPD dedication + fallback
CC-BY-4.0Creative CommonsNoneNot licensedArticles, images, datasets
CC-BY-SA-4.0Creative CommonsShareAlike (content)Not licensedWiki / OER text

The pairs that actually break builds are few, and they repeat. Apache-2.0 plus GPL-3.0 is fine. Apache-2.0 plus GPL-2.0-only is not. GPL-2.0-only plus GPL-3.0 is not, unless the inbound license is or later. MPL-2.0 plus GPL is fine unless Exhibit B. EPL-2.0 plus GPL needs Exhibit A. CDDL plus GPL is the ZFS problem. CC-BY and CC-BY-SA do not get a plugin onto WordPress.org. CC0 plus GPL does.

How to Read a LICENSE File Before You Ship

You do not need to become a licensing analyst. You need a repeatable pass over every inbound repo, plugin, font, photo, and model card.

  1. Read the SPDX id, not the README adjective. Open, free, and available on GitHub are not grants. Apache-2.0 is. If the file says GPL with no version, stop and find the version and the or later sentence.
  2. Match the family to the product shape. A WordPress plugin or theme going to wordpress.org must be GPL-compatible. A hosted SaaS product that vendors AGPL code inherits a source offer for network users. A native SDK you want inside a client’s closed app wants MIT, BSD, ISC, Boost, or Apache.
  3. Look for a patent sentence. If you are combining this with a product that has a patent portfolio, silent licenses (MIT, BSD, CC) are a counsel conversation, not a footnote. Apache-2.0, GPL-3, MPL, and EPL write the grant down.
  4. Keep the notices the license named. MIT wants the copyright block. Apache wants LICENSE plus NOTICE. zlib wants origin and this was changed. Boost wants the text in source, not in the compiled object. CC-BY wants attribution and a link to the deed.
  5. Do not launder content licenses through a plugin zip. A CC-BY photo inside a GPL plugin is a different work with its own conditions. A CC-BY-SA text you rewrote into product copy may have to ship ShareAlike. Neither is a software license for the PHP.
  6. Treat model and weight licenses as their own documents. Many open weights files add field-of-use limits, revenue caps, or acceptable-use clauses that OSI licenses do not have. SPDX on the training code does not license the weights.

If the inbound id is MIT, Apache-2.0, or BSD, you can usually ship. If it is GPL-2.0-or-later and you are on WordPress, you are in the intended ecosystem. If it is AGPL-3.0 and you host the modified program, budget for a public source offer. If it is CC-BY or CC-BY-SA, credit the author and keep it off the plugin directory’s idea of the plugin. If it is SSPL, a source-available commercial license, or anything with a field-of-use rider, you have left this chart.

Disclaimer: I’m not an attorney, and this isn’t legal advice.

Related Articles