Open Source Licensing Explained: MIT, GPL, Apache, and What They Mean

What Is Open Source Licensing and Why Does It Matter?

When a developer or organization releases software as "open source," they are making the source code publicly available and granting users certain rights to use, study, modify, and distribute it. But simply making code publicly available does not give others any legal right to do anything with it—under copyright law, the default is that all rights are reserved by the copyright holder. An open source license is the legal instrument through which copyright holders grant those rights, and the specific terms of the license determine exactly what users may and may not do.

Open source licensing matters enormously in the modern software ecosystem because virtually all software today is built on layers of open source components. Web frameworks, programming languages, operating systems, databases, and cloud infrastructure are overwhelmingly composed of open source code. Every organization that uses, modifies, or distributes software—which is to say nearly every organization of any kind—needs to understand the licenses governing the components it relies on, because violating those licenses can expose the organization to copyright infringement liability, trigger obligations to release proprietary code, and create reputational damage.

The open source licensing landscape can appear bewilderingly complex: the Open Source Initiative has approved more than a hundred different licenses, and software projects may be governed by different licenses for different components. However, a relatively small number of licenses account for the vast majority of open source code, and understanding the key distinctions among them—particularly the difference between permissive and copyleft licenses—provides a solid foundation for navigating the landscape.

Permissive Licenses: The MIT and BSD Families

Permissive licenses are the most liberal category of open source licenses. They grant users broad rights to use, modify, and distribute the software with very few conditions. The quintessential permissive license is the MIT License, which is one of the shortest and most widely used open source licenses in existence. The MIT License grants permission to any person obtaining a copy of the software to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software, with only two conditions: the copyright notice and the license text must be included in all copies or substantial portions of the software.

The practical consequence of the MIT License's minimal conditions is that software under it can be incorporated into proprietary products without requiring the resulting product to be open source. A company can take MIT-licensed code, modify it, incorporate it into a commercial product, and sell that product without releasing any source code and without paying royalties. The only obligation is to preserve the attribution—the copyright notice—in the distributed software. This makes MIT-licensed code extremely attractive to commercial developers and is a major reason why many widely used libraries and frameworks use the MIT License.

The BSD License family is closely related to the MIT License. The original BSD License (sometimes called the four-clause BSD License) included a controversial advertising clause that required acknowledgment of the original software in any advertising materials—a requirement that the Free Software Foundation declared to be incompatible with the GPL. The three-clause BSD License ("BSD-3-Clause" or "New BSD License") removed the advertising requirement but retained a non-endorsement clause prohibiting use of the copyright holder's name to endorse derived products. The two-clause BSD License ("BSD-2-Clause" or "Simplified BSD License") is effectively equivalent to the MIT License. Today, when developers refer to a "BSD license," they usually mean one of these later versions.

Strong Copyleft: The GPL Family

In sharp contrast to permissive licenses, copyleft licenses use copyright law to ensure that the freedoms they grant are preserved in all subsequent distributions of the software. The core idea, associated with free software pioneer Richard Stallman and the Free Software Foundation, is that software distributed with the freedom to be used, studied, and modified should carry with it the obligation to pass those same freedoms on to all recipients of derived works. The mechanism for enforcing this is the requirement that any derivative work or software distributed together with GPL-licensed components must itself be distributed under the GPL—meaning the source code must be made available under the same license terms.

The GNU General Public License (GPL), now in its third version (GPLv3), is the most famous copyleft license and one of the most widely used open source licenses overall. Its key provision—often called the "copyleft" or "share-alike" provision—requires that any work that is a modification of or is derived from GPL-licensed software, and that is distributed to others, must be distributed under the GPL with source code available. This provision effectively prevents developers from incorporating GPL code into a proprietary product without either releasing that product under the GPL or obtaining a separate commercial license from the copyright holder (when the copyright holder offers dual licensing).

The "viral" nature of the GPL—the fact that it can spread to encompass derivative works—has significant implications for software development. Businesses that are building proprietary software must carefully audit their dependencies to ensure they do not inadvertently incorporate GPL-licensed components in ways that would trigger the obligation to release their own source code. GPL compliance has been the subject of significant litigation, most notably cases brought by the Software Freedom Conservancy and individual copyright holders against companies that distributed embedded Linux systems without making source code available as required by the GPL.

Weak Copyleft: LGPL and MPL

Between the fully permissive licenses and the strong copyleft of the GPL lie a family of "weak copyleft" or "file-level copyleft" licenses that seek a middle ground. The GNU Lesser General Public License (LGPL), originally designed to allow free software libraries to be used by proprietary applications without triggering full GPL obligations, is the most important of these. The LGPL allows an application to link to an LGPL-licensed library without requiring the application to be licensed under the LGPL, as long as certain conditions are met: the user must be able to replace the library with a modified version, and the source code of the library itself (not the application) must be available under the LGPL.

The Mozilla Public License (MPL), used for Mozilla's Firefox browser and other projects, is another widely used weak copyleft license. The MPL operates at the file level: modifications to MPL-licensed files must be released under the MPL, but an application that merely incorporates or links to MPL-licensed files can keep its own code proprietary. This file-level copyleft makes the MPL more permissive in practice than the LGPL for many use cases, while still ensuring that improvements to the MPL-licensed components themselves are shared back with the community.

The Eclipse Public License (EPL) and the Common Development and Distribution License (CDDL) are additional weak copyleft licenses used by major projects in the Java and Unix ecosystems respectively. These licenses share the general pattern of requiring that modifications to the licensed files be returned to the community while permitting broader integration with proprietary code. Understanding exactly how these licenses work in your specific use case—whether you are linking dynamically, statically, or combining files in other ways—requires careful reading of the license text and, often, legal advice.

The Apache License 2.0: Permissive with Patent Protection

The Apache License 2.0 is a permissive license similar in its general permissions to the MIT License—it allows use, modification, and distribution in both open source and proprietary contexts with minimal requirements—but it includes several additional provisions that make it more appropriate for large enterprise software projects. Most notably, the Apache License 2.0 includes an explicit patent license: each contributor to the project grants users a perpetual, worldwide, royalty-free license to any patent claims necessarily infringed by their contribution. This patent grant provides users with protection against patent infringement claims from contributors, a safeguard that the MIT License does not explicitly address.

The Apache License also includes a patent termination clause: if a contributor or user initiates patent litigation claiming that any part of the Apache-licensed software infringes a patent, their patent license under the Apache License automatically terminates. This provision is designed to deter patent aggression by project contributors or users who might otherwise use software they received under the Apache License while simultaneously asserting patent claims against other users of the same software. For organizations that face significant patent litigation risk, the Apache License 2.0's explicit patent provisions make it preferable to the MIT License for governing contributions to major software projects.

The compatibility between the Apache License 2.0 and the GPL is a nuanced subject. The Free Software Foundation has declared the Apache License 2.0 to be a free software license compatible with GPLv3 but not with GPLv2. This means that Apache-licensed code can be incorporated into GPLv3 projects, but developers must be careful about combining Apache 2.0 code with GPLv2-only software. Understanding license compatibility is essential when building systems that combine components under multiple licenses, as incompatible licenses can create legal problems even when all the individual components are open source.

The GNU Affero GPL: Addressing the SaaS Loophole

The GNU Affero General Public License (AGPL) was created to address a significant gap in the GPL's copyleft coverage that became apparent with the rise of software-as-a-service (SaaS) delivery models. The GPL requires that modifications to GPL-licensed software be shared when the software is distributed to others, but it does not consider running software as a service—where users interact with the software over a network without receiving a copy—to be "distribution." This means a company can take GPL-licensed software, modify it significantly, run it as a cloud service accessed by millions of users, and never be required to share those modifications under the GPL.

The AGPL closes this loophole by adding a network use provision: if you run modified AGPL-licensed software as a publicly accessible network service, you must make the corresponding source code available to users of that service. This makes the AGPL particularly relevant in the cloud computing era, where much software is delivered as a service rather than being distributed. Projects that choose the AGPL are expressing a commitment to keeping their software open even when deployed as a service, and they use the AGPL to prevent companies from building proprietary cloud services on top of their code without contributing back modifications.

The AGPL has been adopted by a number of significant open source projects that are primarily used in server or SaaS contexts, including MongoDB (which later moved to its own Server Side Public License), Nextcloud, and various other database and server software projects. The AGPL is sometimes described as the "GPL with the network use clause," and its use has grown as more software moves to cloud delivery models. Organizations that consume AGPL-licensed software in their SaaS offerings need to be aware of the network use provision and plan accordingly.

Choosing a License and Practical Compliance

Choosing the right license for a new open source project depends on the goals and philosophy of the project creators. Developers who want maximum adoption—including by commercial users—often choose the MIT or Apache 2.0 license. Those who want to ensure that improvements to their software are shared back with the community typically choose the GPL or AGPL. Projects seeking a middle ground often choose the LGPL or MPL. The choice of license can significantly affect who uses the software, how it is integrated into other systems, and how the project interacts with the broader open source ecosystem.

For organizations that consume open source software—which is virtually every organization—license compliance requires maintaining an accurate software bill of materials (SBOM): a list of all open source components used, their versions, and their licenses. This inventory must be kept current as dependencies change, and it must be reviewed to identify any licensing obligations that arise. Permissive licenses typically require only preservation of copyright notices; strong copyleft licenses may require distributing source code; and the specific details of compliance depend on how the software is used, modified, and distributed.

Organizations that discover they are out of compliance with an open source license—for example, that they have distributed GPL-licensed software without providing corresponding source code—should address the issue promptly. In many cases, the copyright holders are more interested in achieving compliance than in pursuing litigation, and they may be willing to work with organizations that come forward in good faith. Open source legal compliance programs at organizations like the Linux Foundation and the Software Freedom Conservancy provide resources and guidance for organizations seeking to build effective compliance programs. For complex licensing questions, consulting with an attorney who specializes in intellectual property and open source licensing is advisable.