Software licenses dictate the terms under which software can be used, modified, and distributed. Choosing the right license is a critical decision that can impact your project's adoption, legal obligations, and business model. In this comprehensive guide, we’ll explain the different types of software licenses—both open source and closed source. We’ll cover major open source licenses like MIT, Apache 2.0, GPL (v2 and v3), LGPL, BSD (2-clause and 3-clause), MPL, AGPL, and even touch on Creative Commons for creative works. We’ll also discuss closed-source licenses (proprietary EULAs, SaaS terms) and dual licensing models. Finally, we’ll help you understand how to choose the right license based on your goals, whether it’s maximizing adoption, protecting intellectual property, enabling community contributions, or avoiding legal risks.

Open Source Licenses

Open source licenses are those that comply with the Open Source Definition – they allow software to be freely used, modified, and shared. Open source doesn’t mean “no license” or public domain; it means the software is licensed with certain conditions that preserve user freedoms. Open source licenses generally fall into two categories:

  • Permissive licenses: These impose minimal restrictions. You can use the code in almost any way (including in proprietary projects) as long as you fulfill basic conditions like attribution​.
  • Copyleft licenses: These share-alike licenses require that if you redistribute the software (especially in modified form), you must release your derivative work under the same license​. In other words, you can “borrow my code, but if you share your version, it must remain open source too.” Copyleft licenses range from strong (GPL, AGPL) to weak (LGPL, MPL) in how far this requirement extends.

Let’s break down the major open source licenses one by one, explaining their terms in simple terms, their legal/commercial implications, and use-case suitability.

MIT License (MIT)

Type: Permissive open source license (very minimal restrictions).

Summary of Terms: The MIT License basically says, “Do whatever you want with this software, just include my copyright and license notice in any copy or distribution.” It grants broad rights to use, copy, modify, merge, publish, distribute, and sublicense the software, even as part of a proprietary (closed-source) product​. The only condition is preserving the original copyright notice and license text in copies or substantial portions of the software​. It also includes a clause that the software is provided “as is” without warranty, protecting the author from liability​.

Implications: MIT is one of the most popular and permissive licenses. It allows commercial use and proprietary relicensing, so long as attribution is given​. There’s no requirement to open-source your own code even if you use or modify MIT-licensed components. This makes it business-friendly – companies can integrate MIT code without fear of being forced to reveal their source. However, as the author, using MIT means you’re not retaining much control: others could even sell your code or incorporate it into closed software without contributing back (they just can’t remove your copyright notice).

Use Case & Examples: The MIT license is ideal if you want maximum adoption of your code/library and are not concerned about controlling how it’s used. It’s common for frontend frameworks, libraries, and tools (e.g. React, Ruby on Rails, jQuery, and many others) to use MIT. For a startup releasing a developer library or tool to build ecosystem and usage, MIT is often a safe choice. Developers know that MIT-licensed code can be integrated anywhere with minimal fuss. For instance, the Jenkins automation server’s code is MIT-licensed​, meaning anyone can use Jenkins or embed its code in other systems as long as they keep the MIT license notice. If your goal is to make your project as easy as possible to use or embed (even in closed-source products), MIT provides that freedom.

BSD Licenses (2-Clause and 3-Clause BSD)

Type: Permissive open source licenses (similar spirit to MIT).

Summary of Terms: BSD licenses come from the Berkeley Software Distribution. The two common variants are:

  • BSD 2-Clause (FreeBSD license) – This has two main clauses: (1) you must preserve the copyright notice in source code or binary redistributions, and (2) a disclaimer of warranty/liability. This is effectively as permissive as MIT (you can use/modify/redistribute freely, including in proprietary software, just keep the notice and don’t sue the author for damages).
  • BSD 3-Clause – This is the “New BSD License” or “Modified BSD License.” It has the same two clauses as above plus a third clause: “No endorsement”, meaning you cannot use the name of the original project or contributors to advertise or promote your derivative without permission. This prevents confusion or implied endorsement. (Older BSD had a 4th clause requiring acknowledging the software in ads, but that was removed due to being too burdensome.)

Implications: Both BSD variants are very permissive. Like MIT, they allow proprietary use of the code with virtually no obligations beyond attribution​. The 3-clause BSD’s extra condition is minor (it just keeps people from using your name to promote their product). There is no copyleft effect – you are not required to open source any modifications or combined work. Also, BSD licenses (like MIT) do not explicitly mention patents, although by using the code some implicit patent license may be inferred, it’s not as explicit as Apache’s clause. In practice, MIT and BSD are functionally very similar for most users.

Use Case & Examples: BSD licenses are often used in system libraries and academic or corporate releases where maximum reuse is desired. For instance, parts of BSD Unix operating systems are under BSD license (hence Microsoft could use TCP/IP stack code from BSD in Windows long ago). Many C libraries or components use BSD. If you’re releasing code and want it to be as usable as possible with minimal strings attached (like MIT) but perhaps prefer the wording or the no-endorsement clause of BSD, it’s a fine choice. A startup might choose BSD for an open-source component if they’re comfortable with others possibly commercializing the code. Practically, there’s little difference from MIT – in fact, MIT is sometimes described as a simplified BSD license. Both are GPL-compatible (they can be included in GPL projects without conflict)​.

Apache License 2.0

Type: Permissive open source license, but with some additional protections compared to MIT/BSD.

Summary of Terms: The Apache License 2.0 also allows you to use, modify, and distribute the software freely, including for commercial purposes​. Like MIT, it does not require derivative works to be open source (no copyleft on combined works)​. However, it has extra conditions:

  • You must include a copy of the Apache 2.0 license in any redistribution (source or binary) and give recipients a notice of any modifications you made (e.g. in the file headers or a NOTICE file)​.
  • It provides an explicit patent license from contributors to users. That is, contributors grant a royalty-free patent license for any patents they own that read on their contributions​. If a user of the software files a patent lawsuit against the project for patent infringement, they lose the patent rights granted by the license​. This clause protects both contributors and users from patent litigation related to the code.
  • It has a provision that you cannot use the names of the project or contributors to promote your derivative products without permission (similar to the BSD “no endorsement” clause).

Implications: Apache 2.0 is also very permissive for commercial use – you can include Apache-licensed code in proprietary software. The major advantages over MIT are the explicit patent grant and the requirement to document your changes. The patent clause is important in industries with patent concerns: it assures users that they have rights to any patented technology in the code​, and deters patent trolls. Many companies prefer Apache 2.0 for this reason. The requirement to state changes and include a NOTICE file ensures credit and transparency for significant use of the code.

Use Case & Examples: Use Apache 2.0 if you want permissive use but also want to safeguard against patent risks or ensure attribution. The license is famously used by the Apache Software Foundation for projects like Apache HTTP Server, Hadoop, Kafka, etc., and by many other big projects (for example, Android kernel parts, Kubernetes, and numerous Google open source projects are under Apache 2.0). If you’re open-sourcing a project and anticipate corporate adoption or contributions, Apache 2.0’s protections can encourage companies to participate (they get patent safety). From a startup perspective, if you have technology in a space with potential patent minefields (say, codecs, algorithms), Apache 2.0 offers your users clarity that you’re granting necessary patent rights. It’s a bit more effort for users to comply (they need to keep LICENSE/NOTICE files intact), but that’s a small trade-off for the added legal robustness​.

GNU General Public License (GPL v2 & v3)

Type: Copyleft open source license (strong copyleft). GPL comes in version 2 and version 3, which have some differences, but both enforce that the software (and any derivative works) remain under the GPL if distributed.

Philosophy: The GPL was created to ensure software freedom is preserved. The idea is “You can use and modify my code freely, but if you distribute changes or something that incorporates my code, you must also share your source code under the same GPL license.” This prevents someone from taking GPL code and making a proprietary product out of it; any improvements must be open as well​.

GPLv2 (1991): Under GPL version 2, if you distribute a binary or modified version of GPL’d code, you must provide the source code to recipients under GPL as well​. You also can’t impose additional restrictions beyond the GPL terms. However, GPLv2 didn’t address certain issues like patent guarantees or using GPL software over a network (see AGPL for that) or “tivoization” (where a device uses GPL software but locks it down so users can’t run modified versions).

GPLv3 (2007): GPLv3 builds on v2 and addresses those gaps. Key updates in GPLv3:

  • It explicitly includes a patent license from contributors to users (similar to Apache’s idea) to protect against patent litigation​.
  • It has anti-“tivoization” provisions: if a device is distributed with GPLv3 software, you cannot lock it with hardware keys to prevent modified versions from running. In other words, users must be able to run modified GPL software on devices they own.
  • It is more compatible with other licenses and allows certain additional permissions or exceptions. It also explicitly forbids using GPLv3-covered code in DRM (digital rights management) systems to prevent blocking user modifications.
  • GPLv3 is not automatically compatible with GPLv2 unless the GPLv2 code had an “or later version” clause. (So some projects stuck on v2 cannot mix with v3 code without re-licensing.)

Implications: Using GPL code in your project has a big implication: if you distribute your software (e.g., sell it or even give to users) and it includes or is derived from GPL code, you must release your whole combined source under GPL as well. This is why GPL is sometimes called “viral” (though enthusiasts prefer “protective”) – it “infects” the larger work with copyleft. For example, if you statically link a GPLv2 library into your application, your application would need to be GPL too when distributed. This ensures the community gets improvements back, but it deters companies from mixing GPL code into proprietary products (since that would force them to open source their product, which they may not want).

It’s important to note GPL does allow commercial use – you can sell GPL software or services around it. But you can’t turn it closed-source. Anyone who receives the binary can request the source. Also, anyone can redistribute your GPL software (either free or for a fee) as long as they maintain the license.

GPLv2 vs GPLv3 Adoption: Many older projects (Linux kernel, MySQL, etc.) use GPLv2. The Linux kernel famously stayed GPLv2-only, whereas many GNU Project tools (GCC, Bash, etc.) moved to GPLv3. For most end-users, both v2 and v3 enforce the share-alike requirement; the differences matter more to manufacturers (v3’s anti-lockdown stance) and in patent-heavy industries (v3’s patent clause).

Use Case & Examples: Choose GPL if you want to ensure that all modifications and extensions of your code remain open source. This is common for end-user applications or frameworks where open collaboration is the goal and you don’t want proprietary forks. For instance, WordPress is GPL-licensed, which forces plugins or derivatives to also be GPL (WordPress’s developers chose GPL to align with the philosophy of sharing). Linux is GPLv2, ensuring that any modified kernel distributed (e.g., by an Android phone maker) must have source released. If you’re a startup building software that you want to give to users but also want to prevent a competitor from taking it private, GPL is a powerful tool. Keep in mind, though, that GPL licensing can reduce adoption by companies — e.g., a library under GPL will likely not be used in a closed-source app. So GPL is suitable if your priority is maintaining open-source purity and user freedom over maximum corporate adoption.

Caution: If you use GPL code within your project, you must adhere to its terms. For example, if you incorporate a GPL component into your software and plan to distribute it to customers, you’ll need to open source your whole software under GPL. This is a legal obligation, not just a preference. Many companies carefully avoid GPL components in proprietary products to avoid this contagion. However, using GPL code internally (without distribution) is fine – the license obligations trigger upon distribution. (Services have a loophole here, which AGPL addresses next.)

GNU Lesser General Public License (LGPL)

Type: Weak Copyleft open source license, primarily for libraries. The “Lesser” GPL is more permissive than GPL in that it allows linking to the library in non-GPL software under certain conditions.

Summary of Terms: LGPL is like GPL with an exception: if an application links to an LGPL-licensed library, the application itself does not have to be GPL. It can remain proprietary or under any license. However, if you modify the LGPL-covered library itself, you must release those modifications under LGPL​. Also, you must allow the end user to relink your application with a modified version of the LGPL library (to preserve the freedom to improve the library). In practice, this usually means you should use dynamic linking or provide object files for relinking if you static link.

0In simpler terms: using an LGPL library does not infect your whole program, as long as the library remains a separate component that can be updated independently. The freedom is focused on the library – any changes to the library must be shared, but your own code can remain closed. LGPL v3 is framed as GPLv3 plus additional permissions for linking.

Implications: LGPL is great for allowing broad use of a library without forcing everything it touches to be open. Many companies are comfortable using LGPL libraries in their products, whereas they would avoid a GPL library. The trade-off for the library author is that a company could improve or fix the library and not necessarily share it — except if they modify the library itself, in which case they must contribute back those changes under LGPL​. If they only use it as-is, they don’t need to reveal their own source. LGPL is often seen as a compromise between GPL and permissive: it guarantees the core library stays free and improvable by the community, but doesn’t scare away proprietary software developers from using it​.

Use Case & Examples: LGPL is commonly used for software libraries and frameworks. For example, GLibc (the GNU C Library) is LGPL – which is crucial, because it allows proprietary software on Linux to use the C runtime without being forced open source. Many Linux libraries (GTK, etc.) are LGPL for the same reason. Qt (a GUI framework) was historically available under LGPL, allowing closed-source applications to use it, which greatly expanded its adoption in commercial software. If you’re a developer of a library and you want others (including companies) to use it freely but you’d like to ensure any improvements to the library itself come back to the community, LGPL is a suitable choice. Startups building an SDK or library might choose LGPL to get widespread usage but still prevent someone from taking the library, tweaking it, and releasing a proprietary improved version without contributing changes back.

One caveat: compliance with LGPL when static linking can be a bit complex (providing relink mechanism), so some avoid LGPL in favor of even simpler MIT/Apache. Still, it strikes a balance. Think of LGPL as saying: “You can use my engine in your car, even a commercial car, but if you improve the engine, you must share those improvements. Your car’s design can remain proprietary.”

Mozilla Public License (MPL 2.0)

Type: Weak Copyleft open source license (file-level copyleft).

Summary of Terms: The MPL (version 2.0) was created by Mozilla for their projects (like Firefox). It has a copyleft mechanism that is file-based: any file in the codebase that is MPL-licensed and that you modify or extend, must be released under MPL when you distribute your software​. However, you can combine MPL files with your own proprietary files in a larger project. In that case, you only need to open source the MPL-licensed parts (and any of your modifications to them), not your entire codebase. The copyleft does not cross file boundaries. This means MPL is more permissive than GPL: it’s compatible with being included in proprietary projects, as long as the MPL-licensed components remain open and separable.

The MPL also includes a patent grant similar to other mo