An open source license is a copyright license that lets anyone use, study, change and share software, including for business, on terms that meet the Open Source Definition. Most fall into two families: permissive licenses, which mainly ask you to keep the notices, and copyleft licenses, which require you to share your changes under the same license.
This guide sorts the common licenses by what each one actually requires, using the license texts themselves, the Open Source Initiative (OSI) and the Free Software Foundation (FSF). It also counts how often each license appears on GitHub, our own count from 14 October 2026, and corrects several mistakes that are common in other explainers, including an earlier version of this page.
What is an open source license?
Software is protected by copyright the moment it is written. GitHub’s documentation puts the default plainly: “without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work” (GitHub Docs). A license is the written permission that changes that default.
A license counts as open source when it meets the OSI’s Open Source Definition, currently version 1.9, which was originally derived from the Debian Free Software Guidelines. Among its ten criteria:
- Free redistribution. Anyone may sell or give the software away, and the license may not demand a royalty for that sale.
- Source code. The program must include source code and allow distribution in source and compiled form.
- Derived works. The license must allow modifications and derived works under the same terms.
- No discrimination against fields of endeavor. For example, “it may not restrict the program from being used in a business”.
The OSI approves a license only after its review process, and sorts approved licenses into ten categories on its license list. MIT, Apache 2.0, the GPL, MPL 2.0 and EPL 2.0 sit in its “Popular / Strong Community” group. Each license also has a short identifier on the SPDX License List (version 3.29.0, 16 September 2026), such as MIT or Apache-2.0, which is how tools and files name licenses without ambiguity.
What about open source AI models?
Model weights do not fit neatly into software licenses, so the OSI published a separate Open Source AI Definition, version 1.0, on 28 October 2024. It requires the freedoms to use, study, modify and share the system. It also requires the complete code used to train and run it, and the model parameters under OSI-approved terms. For the training data, it asks for enough detail that a skilled person could build a substantially equivalent system, not the full dataset itself.
Types of open source licenses
Every open source license allows use, copying and changes. They differ on one question: what you must do when you pass the software, or your changed version of it, to someone else. The US Department of Defense’s open source FAQ puts it in three groups: “OSS licenses can be grouped into three main categories: Permissive, strongly protective, and weakly protective.” Two more groups sit at the edges: public-domain dedications, which ask for nothing, and network copyleft, which reaches users of a hosted service.
| Type | What you must do when you distribute | Examples |
|---|---|---|
| Public domain | Nothing | Unlicense, CC0 1.0 |
| Permissive | Keep the copyright and license notices | MIT, BSD, ISC, Apache 2.0 |
| Weak copyleft | Share changes to the licensed files or library, under the same license | MPL 2.0, EPL 2.0, LGPL |
| Strong copyleft | License the whole work under the same license, with source | GPL 2.0, GPL 3.0 |
| Network copyleft | As strong copyleft, and offer source to network users of a modified version | AGPL 3.0 |
Permissive licenses
A permissive license lets you do almost anything with the code, including shipping it inside a closed, paid product, as long as you keep the copyright and license notices. The FSF calls these lax licenses and notes that with non-copylefted software, a company can compile the program and distribute the executable as a proprietary product. MIT, the BSD licenses, ISC and Apache 2.0 are the common ones. Apache 2.0 adds an explicit patent license and a few more notice rules, covered below.
Copyleft licenses
Copyleft, in the FSF’s words, means making a program free and “requiring all modified and extended versions of the program to be free as well” (FSF). The difference between weak and strong copyleft is how far that requirement reaches. Mozilla’s MPL FAQ gives the clearest summary:
- MPL: “The copyleft applies to any files containing MPLed code.”
- LGPL: “The copyleft applies to any library based on LGPLed code.”
- GPL: “The copyleft applies to all software based on GPLed code.”
So with weak copyleft (MPL 2.0, EPL 2.0, LGPL) you share your changes to the licensed files or library, but your own separate code can stay under your terms. With strong copyleft (GPL), the whole program you distribute must be licensed under the GPL, with its source.
Network copyleft: the AGPL
The GPL’s duties start when you distribute the program. Running a changed copy on your own servers is not distribution, and the FSF’s GPL FAQ confirms that a company running a modified GPL program on a web site does not have to release its changes. The GNU Affero GPL (AGPL) closes that gap, but only for changed code. Section 13 says: “if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version”. Many explainers say the AGPL is triggered by any network use. The text says it is triggered by modifying the program.
Public-domain dedications
The Unlicense and CC0 1.0 try to give up copyright entirely. The Unlicense lets anyone use the software “for any purpose, commercial or non-commercial, and by any means”. CC0 says nothing about patents: its deed states that patent and trademark rights are not affected. For that reason the FSF does not recommend CC0 for software, while Creative Commons says CC0 is “GPL-compatible and acceptable for software”. A close relative is Zero-Clause BSD (0BSD), which the OSI notes “is an alteration of the ISC license” with the notice requirement removed.
What are the 4 types of software licenses?
We found no standards body that defines exactly four. The international standard for software entitlements, ISO/IEC 19770-3, defines a data format for describing license rights, not a list of license types. The four-way split most guides use is a reasonable summary, and you can build it from official sources:
- Public domain. Dedications such as the Unlicense and CC0, with no conditions.
- Permissive. Open source licenses that ask mainly for the notices: MIT, BSD, Apache 2.0.
- Copyleft. Open source licenses that require shared changes, which the DoD splits into weakly protective (LGPL, MPL) and strongly protective (GPL).
- Proprietary. In the DoD’s words, “Commercially-available software that is not open source software is typically called proprietary or closed source software.”
Two points keep the list honest. First, “commercial” is not a fifth type and is not the opposite of open source: the DoD says “nearly all OSS is ‘commercial computer software’ as defined in US law”. Second, a growing group does not fit any of the four: source-available licenses, where the code is public but use is restricted. The DoD notes there is no widely accepted name for it yet, and the OSI counts it as proprietary. It has its own section below.
Common open source licenses compared
The table lists what each license requires when you distribute the software. None of them restricts private use: you can change the code and run it in your own organization without sharing anything, except for the AGPL’s network rule on modified versions.
| License | Type | Main conditions when you distribute |
|---|---|---|
| MIT | Permissive | Keep the copyright and permission notice |
| Apache 2.0 | Permissive | Include the license, mark changed files, keep notices and the NOTICE file; patent license |
| BSD 3-Clause | Permissive | Keep the notice; do not use contributors’ names to endorse your product |
| BSD 2-Clause | Permissive | Keep the notice |
| ISC | Permissive | Keep the copyright and permission notice |
| MPL 2.0 | Weak copyleft (file) | Changed MPL files stay under MPL with source; patent license |
| EPL 2.0 | Weak copyleft (file) | Source of changed files under EPL; patent license |
| LGPL 2.1 / 3.0 | Weak copyleft (library) | Library changes under LGPL; let users modify and relink |
| GPL 2.0 | Strong copyleft | Whole work under GPL, source or a written offer for it |
| GPL 3.0 | Strong copyleft | Whole work under GPL with source; explicit patent license |
| AGPL 3.0 | Network copyleft | GPL 3.0 terms, plus source for network users of a modified version |
| Unlicense | Public domain | None |
| CC0 1.0 | Public domain | None; grants no patent rights |
List of common open source licenses
Here is what each common license says, in the license’s own words where the wording matters, with a screenshot of the steward’s page where we have one.
MIT License
The MIT License is the shortest of the common licenses. It lets anyone use, copy, modify, merge, publish, distribute, sublicense and sell the software, on one condition: “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” (OSI text). It has no copyleft and says nothing about patents.
Two naming points trip people up. The FSF calls it the Expat license and says the name “MIT License” is misleading, because MIT has used many licenses. And MIT’s own Technology Licensing Office says the license originated at MIT but no longer has a direct affiliation to the Institute.
You do not need anyone’s approval to use it. The OSI text is a template that starts with a copyright line you fill in. The release steps on MIT’s licensing office page, such as a software disclosure and confirming that sponsors agree, are for MIT’s own authors releasing MIT-owned code (MIT TLO).
Apache License 2.0
The Apache License 2.0 is dated January 2004. Version 1.1 was approved in 2000 and 1.0 was the original; 1.0 still had a BSD-style advertising clause. Version 2.0 is a permissive license with more detail than MIT:
- Patent license. Each contributor grants a perpetual, royalty-free patent license (section 3).
- Patent termination. If you sue claiming the work infringes a patent, your patent license under it ends on the date you file.
- Notices. When you redistribute, include the license, mark files you changed, keep the copyright, patent, trademark and attribution notices, and pass on the NOTICE file’s attributions (section 4).
- Your changes. You may license your own modifications under different terms.
- No trademark rights. Section 6 grants no permission to use the licensor’s trade names.
On compatibility, the FSF says Apache 2.0 is “compatible with version 3 of the GNU GPL” but not with GPL version 2, because of its patent termination and indemnification provisions. The FSF also recommends Apache 2.0 over other lax licenses for substantial programs, because of the patent termination clause.
BSD 3-Clause “New” or “Revised” License and BSD 2-Clause
The three main BSD licenses differ in clauses that have nothing to do with source code. None of them requires you to publish source.
- BSD 3-Clause (also called New or Modified BSD): keep the copyright notice in source and reproduce it in the documentation of binaries. Clause 3 adds: “Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.”
- BSD 2-Clause (Simplified or FreeBSD license): the same two notice clauses, without the endorsement clause.
- BSD 4-Clause (the original): adds an advertising clause, “All advertising materials mentioning features or use of this software must display the following acknowledgement”. SPDX records that “This license was rescinded by the author on 22 July 1999.”
The FSF says the advertising clause “does not render the software nonfree. But it does cause practical problems, including incompatibility with the GNU GPL”. The 3-Clause and 2-Clause versions are GPL-compatible.
ISC License
The ISC License gives permission to use the software for any purpose, with or without fee, provided the copyright notice and permission notice appear in all copies. It is OSI-approved and, per the FSF, GPL-compatible.
One correction worth making: ISC’s own best-known software is no longer under the ISC License. According to ISC, current versions of BIND 9 (except the -S Edition), Kea DHCP, ISC DHCP 4.4.0 and later, and Stork are under the Mozilla Public License 2.0. BIND 9 before 9.11.0b, ISC DHCP before 4.4.0 and Kea before 1.0.0 were released under the ISC License.
GNU General Public License (GPL 2.0 and GPL 3.0)
The two GNU General Public License versions you will meet are GPL 2.0 (June 1991) and GPL 3.0 (29 June 2007). Both are strong copyleft. If you distribute a work based on GPL code, the whole work must be licensed under the GPL, changed files must say they were changed, and recipients must get the source code. Under GPL 2.0 you can ship a written offer for the source, valid for at least three years, instead of the source itself.
Three things the GPL does not require, according to the FSF’s own FAQ:
- Releasing private changes. “You are free to make modifications and use them privately, without ever releasing them.” That applies to companies using a changed version internally.
- Staying non-commercial. You may sell GPL software, and except in one special situation the FAQ sets no limit on the price: “The right to sell copies is part of the definition of free software.” Buyers get the same GPL rights, including the source.
- Releasing code behind a web service. Running a modified GPL program on a server is not distribution. That is the gap the AGPL closes.
Patents differ by version. GPL 3.0 includes an explicit patent license from each contributor. GPL 2.0 has none in its text; the FSF says that in many countries distributing under GPL 2.0 gives recipients an implicit patent license.
The two versions are not compatible with each other: code under “GPL 2.0 only” cannot be combined with GPL 3.0 code, while code under “GPL 2.0 or later” can be used under GPL 3.0. That is why SPDX deprecated the bare identifier GPL-2.0 in favor of GPL-2.0-only and GPL-2.0-or-later.
GNU Lesser General Public License (LGPL)
The GNU Lesser General Public License is copyleft for the library and not for the program that uses it. LGPL 2.1 (February 1999) was the first version under this name, succeeding the Library GPL. LGPL 3.0 (29 June 2007) is written as GPL 3.0 plus extra permissions.
You can combine an LGPL library with your own program and distribute the result under terms of your choice, as long as those terms allow users to modify the library part and reverse engineer to debug those changes. Changes to the library itself stay under the LGPL. The FSF’s FAQ spells out linking. If you link statically, you must provide your application in object form so users can relink it with a modified library. If you link dynamically to a copy already on the user’s computer, you need not convey the library’s source.
GNU Affero General Public License (AGPL 3.0)
The GNU Affero GPL 3.0 (19 November 2007) is GPL 3.0 plus section 13. If you modify the program and let people use it over a network, you must offer them the source of your modified version. The FSF explains it in Why the Affero GPL: a modified program running on a server must let its users download the corresponding source. Unmodified copies are not affected by section 13.
The AGPL is not compatible with GPL 2.0 and not strictly compatible with GPL 3.0, but the FSF notes that separate AGPL and GPL 3.0 modules can be combined in one project.
Mozilla Public License 2.0 (MPL)
The Mozilla Public License 2.0 (OSI-approved January 2012) is file-level copyleft. Mozilla says it is designed to encourage contributors to share modifications, “while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions”. If you change an MPL file and distribute it, the file stays under MPL and its source must be available. New files that contain no MPL code are not covered, so an MPL library can sit inside a proprietary application.
MPL 2.0 includes a patent license from contributors and, through its “Secondary License” clause, can be combined with GPL 2.0, LGPL 2.1, AGPL 3.0 or later versions, unless the author marked the code “Incompatible With Secondary Licenses”. To apply it, add the Exhibit A header, or an SPDX-License-Identifier: MPL-2.0 line, to each source file.
Eclipse Public License 2.0 (EPL)
The Eclipse Public License 2.0 (OSI-approved August 2017) is also file-level weak copyleft. If you distribute the program in any form, you must make the source of your modified files available under the EPL. Separate files that only link to or subclass the program are not modified works. Contributors grant a patent license, and the license says it is intended to facilitate commercial use.
The Eclipse FAQ lists what changed from EPL 1.0. The unit of copyleft is now the file rather than the module. The choice-of-law clause is gone, and scripting languages are covered. An author can also name GPL 2.0 or later as a Secondary License for GPL compatibility; without that option, the FSF counts EPL 2.0 as GPL-incompatible. On history, Eclipse says “The EPL 1.0 was derived from CPL version 1.0.”
The Unlicense
The Unlicense dedicates the work to the public domain and adds a fallback license for places where that is not possible. The OSI approved it in June 2020 and lists it as “Special Purpose”; the FSF says it is GPL-compatible. CC0 1.0 does the same job for any kind of work and is covered under public-domain dedications above.
SIL Open Font License (OFL)
The SIL Open Font License 1.1 (26 February 2007) is for fonts, not programs. You can use, modify, bundle and redistribute the fonts, and documents you create with them are not covered by the license. Two rules are specific to it: “Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself.” Fonts may be bundled and sold with software if each copy contains the copyright notice and the license. And modified fonts may not use the original’s Reserved Font Names without written permission. The OSI lists it as “Special Purpose”.
Creative Commons licenses
Creative Commons licenses are built for creative works, and Creative Commons itself says: “We recommend against using Creative Commons licenses for software.” Its reason is that CC licenses have no terms on source code distribution and do not address patents.
Not every CC license is copyleft either. CC BY 4.0 has one condition, attribution, and no share-alike term, so it behaves like a permissive license. CC BY-SA 4.0 is the copyleft one: contributions must be shared under the same license, and Creative Commons says it is one-way compatible with GPL 3.0. The exception for software is CC0, covered above.
Which open source licenses are used most? Our GitHub count
Most explainers give license shares without a date or a method. Here is a count you can repeat. On 14 October 2026 we asked GitHub’s search API how many public repositories it classifies under each license, using its license: qualifier (GitHub Docs).
MIT leads by a wide margin: 22.05 million repositories, about five times Apache 2.0 (4.37 million) and six times GPL 3.0 (3.68 million). GPL 3.0 is used more than five times as often as GPL 2.0. The AGPL (516,364) is level with BSD 3-Clause (517,514).
| License | Public repositories, 14 Oct 2026 |
|---|---|
| MIT | 22,054,986 |
| Apache 2.0 | 4,368,127 |
| GPL 3.0 | 3,676,268 |
| GPL 2.0 | 660,207 |
| BSD 3-Clause | 517,514 |
| AGPL 3.0 | 516,364 |
| Unlicense | 445,387 |
| CC0 1.0 | 405,755 |
| MPL 2.0 | 176,628 |
| BSD 2-Clause | 170,491 |
| LGPL 3.0 | 125,593 |
| CC BY 4.0 | 117,215 |
| LGPL 2.1 | 80,009 |
| ISC | 71,765 |
| 0BSD | 68,523 |
| Boost Software License 1.0 | 52,862 |
| EPL 2.0 | 51,653 |
| WTFPL | 40,850 |
| SIL OFL 1.1 | 12,437 |
How to read it. GitHub detects a license with the Licensee tool, which compares a repository’s LICENSE file with a list of known licenses, so repositories with no license file, or one it cannot match, are not counted. Search leaves out forks unless you ask for them. Every repository counts once, whether it is a major project or a weekend experiment, so this measures how often developers choose a license, not how much important software uses it. We ran the count twice, a few minutes apart, and the totals moved by at most 0.001%; GitHub rejected a made-up license key, so each number is GitHub’s own figure for that license.
Can you use open source software for commercial purposes?
Yes. The Open Source Definition forbids licenses that restrict use in a business, and the OSI’s FAQ says: “All Open Source software can be used for commercial purpose; the Open Source Definition guarantees this.” It adds that you can even sell open source software.
The common mistake is treating “commercial” and “open source” as opposites. The FSF says: “Most commercial software is proprietary, but there is commercial free software, and there is noncommercial nonfree software.” The US Department of Defense goes further: its 2022 policy memo says open source software meets the definition of commercial computer software and must get equal consideration with proprietary commercial offerings. The real opposite of open source is proprietary, or closed source.
What the license controls is what you must do when you distribute:
- Using it internally, changed or not: no obligations under any common license, except the AGPL’s rule for modified versions offered to users over a network.
- Shipping it in a product under a permissive license: keep the notices (and, for Apache 2.0, mark changed files and pass on the NOTICE file).
- Shipping it under copyleft: provide the source for the copyleft part, which is the changed files (MPL, EPL), the library (LGPL) or the whole work (GPL).
- Running it as a service: nothing under the GPL; under the AGPL, offer source if you modified it.
For how this plays out in business software, see our guide to open source ERP.
Source-available licenses are not open source
Since 2018 several well-known projects have moved from open source licenses to source-available ones. The code stays public, but the license restricts use, usually by forbidding a competing hosted service. That clashes with the Open Source Definition’s ban on restricting fields of endeavor. The OSI describes proprietary licenses as “proprietary licenses (which includes source available)” (OSI board statement, January 2021).
- Server Side Public License (SSPL). MongoDB’s license, based on GPL 3.0. Its section 13 says that if you offer the program’s functionality to others as a service, you must release the source of your whole service. MongoDB submitted it to the OSI and later withdrew it; MongoDB’s own FAQ says SSPL-licensed MongoDB is not considered open source by the OSI. See our MongoDB review.
- Business Source License 1.1 (BUSL). Allows copying, changing and non-production use; production use needs a grant from the licensor. Each version converts to an open source Change License on its Change Date or four years after release, whichever comes first. The license text says it “is not an Open Source license”.
- Elastic License 2.0 (ELv2). Its key limit: you may not provide the software to others as a hosted or managed service.
- Redis Source Available License 2.0 (RSALv2). Forbids making the software’s functionality available to third parties as a service. Redis says RSALv2 and SSPL are not open source licenses.
- Functional Source License (FSL). Created by Sentry in November 2023. It forbids competing uses and converts to Apache 2.0 or MIT after two years.
Several of these moves were later partly reversed. Here is the record, from each company’s own announcements and license files:
| Date | What changed |
|---|---|
| 16 Oct 2018 | MongoDB moves Community Server from AGPL 3.0 to SSPL (still SSPL today) |
| 14 Jan 2021 | Elastic moves Elasticsearch and Kibana from Apache 2.0 to SSPL or the Elastic License |
| 10 Aug 2023 | HashiCorp moves future releases from MPL 2.0 to BUSL 1.1 |
| 20 Sep 2023 | Linux Foundation announces OpenTofu, an MPL 2.0 fork of Terraform |
| 20 Mar 2024 | Redis moves from BSD 3-Clause to RSALv2 or SSPL, from version 7.4 |
| 28 Mar 2024 | Linux Foundation announces Valkey, a BSD 3-Clause fork of Redis 7.2.4 |
| 29 Aug 2024 | Elastic adds AGPL 3.0 as a third option beside ELv2 and SSPL |
| 1 May 2025 | Redis 8 adds AGPL 3.0 as a third option beside RSALv2 and SSPL |
| 11 Mar 2026 | Terraform’s license file names IBM as licensor (IBM bought HashiCorp in 2025); still BUSL 1.1 |
The practical point: check the license of the exact version you use. Redis 7.2.4 and earlier are BSD 3-Clause, 7.4 is RSALv2 or SSPL, and 8.0 onward adds the AGPL option. Elasticsearch’s repository is now offered under AGPL 3.0, SSPL or ELv2.
Can you combine code under different licenses?
Two licenses are compatible when both allow you to combine the code into one larger work. It only matters when you combine and distribute; the FSF notes that simply shipping separate programs side by side on the same media is fine even when their licenses clash. The usual rules, from the FSF’s license list and the license stewards:
- Permissive into GPL: MIT (Expat), BSD 2-Clause, BSD 3-Clause, ISC and the Unlicense are all GPL-compatible. The original 4-Clause BSD is not.
- Apache 2.0 into GPL: compatible with GPL 3.0, not with GPL 2.0.
- GPL 2.0 with GPL 3.0: not compatible if the code is “GPL 2.0 only”; “GPL 2.0 or later” code can be used under GPL 3.0.
- MPL 2.0 with GPL: compatible through its Secondary License clause, unless the code is marked “Incompatible With Secondary Licenses”.
- EPL 2.0 with GPL: only when the author named GPL 2.0 or later as a Secondary License.
- AGPL 3.0 with GPL 3.0: separate modules can be combined in one project.
Compatibility is one-way. Permissive code can go into a GPL project, but GPL code cannot go into a project you intend to keep under a permissive or proprietary license.
How to apply an open source license to your project
You do not register or apply anywhere. You put the license in the code:
- Add the full license text in a file named LICENSE at the top of the repository. Apache recommends this, SPDX recommends it when you use short identifiers, and it is the file GitHub reads to detect your license.
- Fill in the copyright line where the license has one. The MIT text starts with “Copyright <YEAR> <COPYRIGHT HOLDER>”.
- Mark each source file with an SPDX identifier, which the SPDX specification says “should be placed at or near the top of the file in a comment”: for example SPDX-License-Identifier: MIT, or MIT OR Apache-2.0 for a dual license. Mozilla accepts this line in place of the MPL header; Apache also offers a short boilerplate header and a NOTICE file.
- Use current identifiers. SPDX says a deprecated identifier, “while remaining valid, should no longer be used”. Write GPL-2.0-only or GPL-2.0-or-later rather than GPL-2.0.
- Record what you reuse. List third-party components and their licenses, ideally in a software bill of materials; our SPDX vs CycloneDX guide compares the two common formats.
FAQs
Can open source software be used commercially?
Yes. The Open Source Definition forbids licenses that restrict use in a business, and the OSI says all open source software can be used commercially and even sold. A license controls what you must do when you distribute the software: keep the notices for permissive licenses, and also share source code for copyleft licenses.
What is the difference between permissive and copyleft licenses?
A permissive license, such as MIT, BSD or Apache 2.0, mainly asks you to keep the copyright and license notices, so the code can go into a closed product. A copyleft license, such as the GPL, requires that versions you distribute stay under the same license with their source code available.
What is the most common open source license?
The MIT License. On 14 October 2026, GitHub’s search counted 22.05 million public, non-fork repositories under MIT, about five times Apache 2.0 (4.37 million) and six times GPL 3.0 (3.68 million). The count only includes repositories whose license file GitHub recognizes.
What happens if code has no license?
Default copyright applies. GitHub’s documentation says that without a license, no one may reproduce, distribute or create derivative works from the code. Code that is public but unlicensed can be read, but it is not open source.
Does the AGPL apply to any software used over a network?
Only to modified versions. Section 13 of the AGPL says that if you modify the program, your modified version must offer its source to users who interact with it over a network. Unmodified copies are not affected by that section, and the ordinary GPL has no network rule at all.
Is source-available software open source?
No. Licenses such as the SSPL, the Business Source License, the Elastic License 2.0 and RSALv2 publish the code but restrict how it may be used, often by banning competing hosted services. The OSI counts source-available licenses as proprietary, and MongoDB, Redis and the BSL text itself say these licenses are not open source.
Which open source license should you choose?
Pick the license by what you want to require of the people who reuse your code:
- Maximum reuse, minimum conditions: MIT, BSD 2-Clause or ISC. Add BSD 3-Clause if you want to stop others using your name to endorse their products.
- The same, with clear patent terms: Apache 2.0. The FSF recommends it over other lax licenses for substantial programs, because of its patent termination clause.
- Changes to your files shared, while the code can still sit inside closed products: MPL 2.0 (per file) or the LGPL (for a library).
- Every distributed version kept open: GPL 3.0. If people will mainly use your software as a hosted service, the AGPL 3.0 extends that to network users of modified versions.
- Fonts: the SIL Open Font License. Documentation or data: a Creative Commons license, not for the code.
If you are reusing someone else’s code, the license on that code decides first: check that it is compatible with how you plan to distribute. And if a project’s license restricts hosted or competing use, treat it as source-available, not open source, whatever its marketing says.
How we researched this page (checked 14 October 2026). Every requirement described here comes from the license texts themselves: SPDX copies, apache.org, mozilla.org, eclipse.org, openfontlicense.org, unlicense.org and creativecommons.org. Definitions and compatibility come from the OSI and the FSF, and the commercial question from the US DoD open source FAQ and its 2022 memo. Relicensing dates come from each company’s own announcement and license files. The GitHub figures are our own count through GitHub’s search API, run twice on 14 October 2026. An earlier version of this page had six errors, now corrected. It treated open source and commercial licenses as opposites. It called the Apache Software Foundation the “Advanced System Format”. It said the BSD licenses differ over source code. It listed CC BY as copyleft, said the MIT License has no restrictions, and presented MIT’s internal release steps as the way anyone gets an MIT license.
References
- Open Source Initiative: The Open Source Definition, version 1.9
- Open Source Initiative: OSI Approved Licenses
- Open Source Initiative: Frequently Asked Questions
- Open Source Initiative: The SSPL is Not an Open Source License (19 January 2021)
- Open Source Initiative: The Open Source AI Definition 1.0 (28 October 2024)
- Free Software Foundation: Various Licenses and Comments about Them
- Free Software Foundation: What is Copyleft?
- GNU Project: Categories of free and nonfree software
- Free Software Foundation: Frequently Asked Questions about the GNU Licenses
- GNU Project: Why the Affero GPL
- SPDX License List, version 3.29.0 (16 September 2026)
- SPDX: MIT License text
- SPDX: BSD 2-Clause License text
- SPDX: BSD 3-Clause License text
- SPDX: BSD 4-Clause (original) License text
- SPDX: ISC License text
- SPDX: GNU General Public License v2.0 only
- SPDX: GNU General Public License v3.0 only
- SPDX: GNU Lesser General Public License v2.1 only
- SPDX: GNU Lesser General Public License v3.0 only
- SPDX: GNU Affero General Public License v3.0 only
- SPDX Specification 2.3.1, Annex: Using SPDX short identifiers in source files
- Apache Software Foundation: Apache License, Version 2.0 (January 2004)
- Apache Software Foundation: Licenses
- Mozilla: Mozilla Public License 2.0
- Mozilla: MPL 2.0 FAQ
- Eclipse Foundation: Eclipse Public License 2.0
- Eclipse Foundation: EPL 2.0 FAQ
- Eclipse Foundation: EPL 1.0 FAQ
- SIL: Open Font License 1.1 official text
- SIL: OFL FAQ
- The Unlicense
- Creative Commons: CC0 1.0 Universal deed
- Creative Commons: Frequently Asked Questions
- Creative Commons: Attribution 4.0 International deed
- Creative Commons: Attribution-ShareAlike 4.0 International deed
- Open Source Initiative: The MIT License
- MIT Technology Licensing Office: Software and Open Source Protection
- Internet Systems Consortium: Software Licenses
- GitHub Docs: Searching for repositories
- GitHub Docs: Licensing a repository
- US DoD CIO: Open Source Software FAQ (October 2021, archived copy)
- US DoD CIO: Software Development and Open Source Software memo (24 January 2022, archived copy)
- MongoDB: MongoDB Issues New Server Side Public License (16 October 2018)
- MongoDB: Server Side Public License FAQ
- MariaDB: Business Source License 1.1 (archived copy, October 2026)
- Elastic: Elastic License 2.0
- Elastic: Licensing change (14 January 2021)
- Elastic: Elasticsearch is Open Source. Again! (29 August 2024)
- Functional Source License
- Redis: Licenses
- Redis: Redis adopts dual source-available licensing (20 March 2024)
- Redis: AGPLv3 (1 May 2025)
- HashiCorp: HashiCorp adopts Business Source License (10 August 2023, archived copy)
- HashiCorp Terraform: LICENSE file
- Linux Foundation: Announcing OpenTofu (20 September 2023)
- Linux Foundation: Valkey announcement (28 March 2024)
Using Google Search? Add erp-information.com as a preferred source.