You just built a plugin, a library, or a WordPress theme. Now the question: which license should you release it under? This is not a detail to leave to chance. The wrong license can block adoption, create legal conflicts, or make you lose control over your work. Here at Meteora Web, we've been there. We've released open source code, integrated third-party libraries, and advised clients on which path to take. This guide explains the real differences between MIT, GPL, Apache, and LGPL — no unnecessary legal jargon — and gives you a practical decision framework.
The problem: why a license is not a bureaucratic detail
Imagine you built a Laravel component that solves a common problem. You publish it on GitHub. Without a license, nobody can legally use it — copyright prevents any reproduction. With the wrong license (e.g., GPL), companies might avoid it because it forces them to open up their entire proprietary software. Or you choose MIT, and someone resells it without even crediting you. The license is the contract between you and anyone who uses your code. It defines what the user can do, what they must do, and what happens to your work.
We see it often: abandoned projects due to unclear licensing, lost forks, rejected contributions. Get to know the four most common licenses, their practical impact, and how to choose based on your goal.
The four licenses that matter
There are hundreds of open source licenses, but the real world revolves around four main ones. Everything else is a variation. Understand these, and you cover 90% of scenarios.
MIT — the free pass, almost no obligations
Permissive, short, clear. With the MIT license, anyone can copy, modify, distribute, sell your code, as long as they include the license text and copyright notice. No obligation to open source modifications.
When to use it? You want maximum adoption, the project is a utility library, a basic component. Famous examples: React (before the switch), jQuery, parts of Node.js.
Watch out: You have no control over how the code is used. A company can take it, lock it inside a proprietary product, and never contribute back.
MIT License
Copyright (c) [year] [fullname]
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.GPL (GNU General Public License) — strong copyleft
Requires distribution under the same license. If you distribute software that includes GPL code, the entire work must be distributed under GPL. This prevents the code from being absorbed into closed proprietary products. It is the license of the Linux kernel, WordPress, MySQL (before the fork).
When to use it? You want every improvement to remain open and not be "stolen" by closed projects. Ideal for frameworks or platforms where you want a community that shares everything.
Watch out: If you are a service provider (e.g., a WordPress theme), GPL can limit your business model because anyone can redistribute your creation. WordPress itself is GPL, but many premium themes use dual licensing to bypass that.
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[... long sections ...]
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified it.
b) The work must carry prominent notices stating that it is released under this License.
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.Apache 2.0 — permissive with extra protections
Similar to MIT but includes patent and contribution clauses. Apache 2.0 grants an explicit patent license from the author, protecting users from patent infringement lawsuits. It also requires maintaining attribution notices. This is the license of Android, Kubernetes, Apache HTTP Server.
When to use it? If your project has patent relevance (e.g., algorithms, methods) or if you work in corporate contexts that fear legal risks. Many large companies prefer Apache 2.0 precisely for the patent coverage.
Watch out: It is slightly longer than MIT, but the practical effect for a normal user is very similar. It does not require releasing modifications.
Apache License
Version 2.0, January 2004
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.LGPL (GNU Lesser General Public License) — copyleft only for the library
Allows linking the code to proprietary software without forcing the whole program to be open. Ideal for libraries. LGPL requires that modifications to the library itself stay LGPL, but users who link to the library (dynamically) are not forced to release their own code. Famous example: glibc, GTK.
When to use it? You are distributing a library you want to be used also in closed projects, but you want improvements to the library to come back to the community. It is a compromise between MIT and GPL.
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
... (similar to GPL but with additional sections allowing dynamic linking to non-GPL works) ...How to choose: a practical decision tree
There is no perfect license in absolute terms. There is the right one for your project. Ask yourself these questions:
- Main goal — maximum adoption? → MIT or Apache. Protection from closure? → GPL. Library to be integrated in mixed projects? → LGPL.
- Business model — do you want to sell commercial licenses? Then you need dual licensing (e.g., GPL + commercial). If you use MIT, anyone can resell your code for free.
- Community and contributions — GPL encourages sharing but may discourage corporate contributors. Apache 2.0 is more business-friendly.
- Patent risk — Apache 2.0 is the only one of the four that gives an explicit patent license. If your project concerns a patentable invention, choose Apache.
Scenario 1: you are creating a WordPress plugin
WordPress is GPLv2. If your plugin uses WordPress code (including hooks and core functions), you must release it under a GPL-compatible license. You can use GPL or MIT (MIT is compatible with GPL for linking? Actually the FSF says MIT is compatible, but common practice is to use GPL itself to avoid doubts. We recommend GPL for WordPress plugins because the community expects it and it simplifies distribution on WordPress.org.
Scenario 2: JavaScript library for the frontend
If it's a small utility you want everyone to use, MIT is the natural choice. If you want forks to stay open, GPL. But on npm most libraries are MIT, so stick with that for maximum adoption.
Scenario 3: theme or template for sale
If you sell themes, dual licensing is common: GPL for mandatory parts (if based on WordPress) and a commercial license to remove attributions or get support. We've seen many developers ignore GPL and put "All rights reserved", but if the theme includes WordPress functions, you are violating WordPress's license. Be careful.
Common mistakes we see in client projects
- “I don't put any license, it's mine” — Without a license, nobody can legally use your code. It's effectively closed.
- Copying a license from another project without understanding it — we've seen projects with GPL when they wanted MIT. Result: confused contributors.
- Ignoring compatibility — using GPL code in an Apache 2.0 project is only legal if the entire project becomes GPL. Always check license compatibility.
- Forgetting to include a LICENSE file — the license must be in the repository root. Many forget and the project is effectively not open source.
What to do now — concrete actions
- Analyze your project: is it a library, a full application, a plugin? Who will use it?
- Decide your goal (adoption vs control) and choose the license among MIT, Apache, GPL, LGPL using the scheme above.
- Download the official text from choosealicense.com or opensource.org and add it to the repository as a LICENSE file.
- Update the README with a line: “This project is licensed under the [license] — see the LICENSE file for details.”
- If you have legal doubts, consult a lawyer specialized in intellectual property. We are not lawyers, but these four licenses are standard and battle-tested.
At Meteora Web, we use different licenses depending on the project. For our internal tools we often prefer MIT because we want the community to adopt them without barriers. For WordPress plugins we release for clients, we choose GPL to remain compatible with the platform. The right choice starts with awareness: don't let the license happen to you — use it as a strategic tool. If you want to dive deeper into security for open source projects you manage, we wrote a guide on cybersecurity under attack that might interest you.
Sponsored Protocol
