Open Source Software License Example: MIT, GPL, and Apache Explained

If you are publishing code or building on someone else's project, studying an open source software license example is the fastest way to understand what you can and cannot do. Each open source software license example in this tutorial, from MIT to GPL-3.0, grants different rights and imposes different obligations, and picking the wrong one can force you to open source your commercial code or expose you to copyright claims. This guide walks you through the most common licenses step by step, though it is educational content rather than legal advice, so consult a qualified attorney for decisions specific to your project or business.

What Is an Open Source Software License?

An open source software license is a legal agreement that grants anyone the right to use, study, modify, and redistribute the source code of a software project, subject to specific conditions. Without a license, code published online remains under default copyright protection, which means nobody can legally copy, modify, or redistribute it even if it sits in a public repository.

The Open Source Initiative (OSI) maintains the formal Open Source Definition and has approved more than 100 licenses that meet its 10 criteria, including free redistribution, source code availability, and no discrimination against fields of use.

In practice, open source licenses fall into two families:

• Permissive licenses (MIT, Apache 2.0, BSD): let anyone do almost anything with the code, including using it in closed-source commercial products, as long as they preserve attribution.
• Copyleft licenses (GPL-3.0, LGPL-3.0, MPL 2.0): grant the same freedoms but require that derivative works be released under the same or a compatible license.

Understanding which family a license belongs to answers 80 percent of the compliance questions you will face.

Open Source Software License Examples Compared

Before looking at full license text, compare the six licenses you will encounter most often:

License	Type	Commercial Use	Must Share Modifications	Patent Grant	Typical Users
MIT	Permissive	Yes	No	No explicit grant	React, Rails, Node.js
Apache 2.0	Permissive	Yes	No	Yes (Section 3)	Kubernetes, Android
BSD 3-Clause	Permissive	Yes	No	No explicit grant	Go, Flask
MPL 2.0	Weak copyleft	Yes	Modified files only	Yes	Firefox
LGPL-3.0	Weak copyleft	Yes	Library changes only	Yes	FFmpeg (parts), Qt
GPL-3.0	Strong copyleft	Yes	Entire derivative work	Yes	Linux tools, WordPress (GPL-2.0)

The pattern to remember: permissive licenses ask for attribution, weak copyleft licenses ask you to share changes to the licensed files, and strong copyleft licenses ask you to share your entire combined work.

A Permissive Open Source Software License Example: The MIT License

The MIT License is the best starting example because it is short enough to read in one minute and covers the essentials every license addresses. Here is the complete text:

MIT License

Copyright (c) 2026 [Your Name or Company]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Three parts do all the work:

1. The grant: paragraph one gives everyone the right to use, copy, modify, sublicense, and sell the software.
2. The condition: paragraph two requires the copyright and permission notice to travel with all copies. This is the attribution requirement.
3. The disclaimer: the capitalized block eliminates warranties and liability, protecting the author if the software breaks something.

Apache 2.0 follows the same structure but adds an explicit patent license in Section 3 and a patent retaliation clause: if you sue a contributor for patent infringement over the software, your license terminates. Companies with patent portfolios often prefer Apache 2.0 for exactly this reason.

A Copyleft Open Source Software License Example: GPL-3.0

The GNU General Public License version 3 (GPL-3.0) is the canonical strong copyleft example. It runs about 5,600 words, so you should read the full text at gnu.org, but the obligations that matter in practice come from a few key sections:

• Section 4 and 5: you may distribute copies and modified versions, but you must license the entire work under GPL-3.0 and keep all notices intact.
• Section 6: if you distribute the software in object or executable form, you must also provide the corresponding source code.
• Section 10: downstream recipients automatically receive the same license, and you cannot impose further restrictions.

The practical consequence is often called the "viral" effect. If you incorporate GPL-3.0 code into your product and distribute that product, the whole product must generally be released under GPL-3.0. For example, a SaaS startup that bundles a GPL-3.0 charting library into its downloadable desktop app must publish the app's source code. Note that merely running GPL code on your own servers does not trigger this obligation; the related AGPL-3.0 license closes that gap by extending the source requirement to network use.

The Lesser GPL (LGPL-3.0) softens this for libraries: you can link to an LGPL library from proprietary code, but changes to the library itself must be shared. Mozilla Public License 2.0 works at file level, so only the specific MPL-licensed files you modify must be published.

How to Choose the Right Open Source License

Follow these steps to select a license for your own project:

1. Decide what you want others to be able to do. If you want maximum adoption, including inside closed-source commercial products, choose a permissive license. If you want every improvement shared back with the community, choose copyleft.
2. Check your dependencies. Your license must be compatible with the licenses of the code you build on. You cannot release a project under MIT if it incorporates GPL-3.0 code; the combined work must be GPL-3.0.
3. Consider patents. If your project touches patentable technology or you expect corporate contributors, prefer Apache 2.0 or GPL-3.0 over MIT, because both include explicit patent grants.
4. Check ecosystem norms. WordPress plugins must be GPL-compatible because WordPress itself is GPL-2.0. npm packages skew heavily toward MIT. Matching your ecosystem reduces friction for adopters.
5. Use choosealicense.com to confirm. GitHub's license picker summarizes permissions, conditions, and limitations for each OSI-approved license in plain language.

For most independent developers and startups, the decision reduces to MIT for simplicity, Apache 2.0 for patent protection, or GPL-3.0 for enforced sharing.

How to Apply an Open Source License to Your Project

Applying a license correctly takes about five minutes:

1. Create a LICENSE file in the root of your repository containing the full, unmodified license text. GitHub detects standard texts automatically and displays the license on your repository page.
2. Fill in the copyright line. Replace the year and name placeholders, for example "Copyright (c) 2026 Acme Software Ltd". Do not edit any other wording; modified license text creates a nonstandard license that lawyers must review from scratch.
3. Add a license field to your package metadata, such as "license": "MIT" in package.json or the license classifier in pyproject.toml, using the standard SPDX identifier.
4. Add per-file headers for Apache 2.0 and GPL projects. Both licenses recommend a short notice block at the top of each source file identifying the license and copyright holder.
5. Document third-party licenses. If you bundle dependencies, include their license notices, typically in a NOTICE or THIRD-PARTY-LICENSES file. Apache 2.0 Section 4(d) makes carrying the NOTICE file mandatory.

If your project accepts outside contributions, consider a Contributor License Agreement (CLA) or the simpler Developer Certificate of Origin (DCO) so you retain the ability to relicense or enforce the license later.

Complying With Open Source Licenses in Your Own Product

Most businesses interact with open source licenses as consumers rather than authors, and this is where violations happen. Build a basic compliance routine:

• Inventory your dependencies. Tools like license-checker for npm, pip-licenses for Python, or platforms like FOSSA and Snyk generate a license report from your dependency tree.
• Flag copyleft licenses. GPL and AGPL dependencies in a distributed or network-facing product need a deliberate decision, not an accidental npm install.
• Preserve attribution. Ship the required copyright notices, typically in an "open source licenses" screen or file. Mobile apps commonly expose this in a settings menu.
• Watch license changes. Projects sometimes switch licenses between versions, as Elasticsearch did when moving from Apache 2.0 to SSPL in 2021, and as HashiCorp did with the Business Source License in 2023. Pinning a version pins its license.

Enforcement is real. German courts have repeatedly upheld the GPL since the 2004 Welte v. Sitecom decision, and in the US, Jacobsen v. Katzer (2008) confirmed that violating open source license conditions is copyright infringement, not merely breach of contract.

Open Source Licenses vs EULAs, Terms, and Privacy Policies

An open source license governs the code itself, but it does not cover everything a software product needs. Keep these documents distinct:

• EULA: proprietary software uses an End User License Agreement to restrict what users may do, which is the opposite posture of an open source grant. If you sell a commercial app built on open source components, you can still ship your own EULA for the proprietary parts, provided it does not restrict rights the open source licenses guarantee.
• Terms of service: govern the use of your hosted service or website, independent of how the underlying code is licensed.
• Privacy policy: required by laws like the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) whenever your application collects personal data. Open sourcing your code does not exempt you; if your app processes EU users' data, GDPR Article 13 disclosure duties apply regardless of the code license. A privacy policy generator can produce a compliant policy that reflects the analytics and third-party services your application actually uses.

Teams often discover during a compliance review that their open source stack quietly added trackers or third-party calls they never disclosed. An automated scanning platform like TermsBox can detect those services on your site and keep your disclosures aligned with what your software actually does.

Frequently Asked Questions

What is the most common open source software license?

The MIT License is the most widely used open source license, applied to millions of projects on GitHub including React and Node.js. It is popular because it is short, permissive, and allows commercial use with only an attribution requirement.

Can I use open source software in a commercial product?

Yes, most open source licenses including MIT, Apache 2.0, and BSD explicitly permit commercial use. Copyleft licenses like GPL-3.0 also allow commercial use, but they require you to release your derivative work's source code under the same license.

What happens if I violate an open source license?

License violations are treated as copyright infringement, which can lead to injunctions, damages, and forced compliance. Organizations like the Software Freedom Conservancy actively enforce the GPL, and courts in the US and Germany have upheld open source licenses as enforceable contracts.

Do I need a lawyer to apply an open source license to my project?

No, for most projects you can apply a standard license like MIT or Apache 2.0 by adding the unmodified license text to a LICENSE file in your repository. Consult a lawyer if you plan to dual-license, mix incompatible licenses, or build a commercial product on GPL code.

What is the difference between an open source license and a EULA?

An open source license grants users broad rights to use, modify, and redistribute source code, while an End User License Agreement (EULA) typically restricts usage of proprietary software. A EULA usually prohibits copying and reverse engineering, which open source licenses explicitly permit.

Can I change the license of my open source project later?

You can relicense future versions if you own the copyright to all the code, but you cannot retroactively revoke rights already granted for released versions. If your project has outside contributors, you need their permission or a Contributor License Agreement to change the license.