Open Source Licenses to Avoid

Source-Available Licenses Disguised as Open Source

The biggest category of licenses to watch out for is source-available licenses that are marketed as open source but do not meet the Open Source Definition maintained by the Open Source Initiative (OSI). These licenses make source code visible and allow some uses, but they include restrictions that disqualify them from being genuinely open source. Using software under these licenses as if it were open source can create unexpected legal obligations.

Server Side Public License (SSPL)

MongoDB switched from the GNU AGPL to the SSPL in 2018. The SSPL requires that anyone who offers the software as a service must release the complete source code of the entire service stack, including all management, orchestration, monitoring, and supporting infrastructure. This goes far beyond what any OSI-approved license requires. The OSI reviewed the SSPL and declined to approve it as an open source license. Linux distributions including Fedora, Debian, and Gentoo have refused to include SSPL-licensed software in their repositories. If you are building a product that incorporates MongoDB or any other SSPL-licensed software, understand that the SSPL is not open source and its obligations are significantly more burdensome than the AGPL's.

Business Source License (BSL / BUSL)

The BSL was created by MariaDB Corporation and has been adopted by companies including HashiCorp (for Terraform, Vault, and other products), Sentry, CockroachDB, and others. BSL-licensed code allows most non-production uses but restricts production use, competitive use, or commercial use depending on the specific parameters set by the licensor. After a specified period (typically three to four years), the code converts to a genuine open source license like Apache 2.0 or GPL. The BSL is explicitly not an open source license, and its creators have never claimed otherwise. However, projects that switch from open source to BSL (as HashiCorp did with Terraform in 2023) frequently face community backlash, and in Terraform's case, the community forked the project as OpenTofu under a Linux Foundation umbrella.

Elastic License 2.0 (ELv2)

Elastic switched Elasticsearch and Kibana from Apache 2.0 to a dual license of SSPL and ELv2 in 2021. The Elastic License 2.0 prohibits providing the software as a managed service and prohibits circumventing any license key or access control functionality. While simpler and less onerous than the SSPL, ELv2 is not OSI-approved and is not open source. AWS responded by forking Elasticsearch as OpenSearch under the Apache 2.0 license. Elastic later re-added AGPL as a licensing option in 2024, but the Elastic License itself remains source-available, not open source.

Commons Clause

The Commons Clause is a license modifier, not a standalone license. It is added on top of an existing open source license (usually Apache 2.0) and adds a restriction prohibiting the sale of the software. Redis Labs (now Redis) applied the Commons Clause to several Redis modules in 2018 before eventually switching to a dual RSALv2/SSPL license. The problem with the Commons Clause is that it fundamentally contradicts the underlying open source license it is attached to. Adding a commercial use restriction to Apache 2.0 creates a license that is neither Apache 2.0 nor open source, despite appearing to be Apache 2.0 at first glance. This is confusing and has led to widespread misunderstanding about what rights users actually have.

Obsolete and Problematic Open Source Licenses

Even within the world of genuinely OSI-approved open source licenses, some create problems that make them poor choices for new projects.

Original BSD License (4-Clause)

The original BSD License included four clauses, the most problematic being the "advertising clause" that required all advertising materials mentioning the software to include a specific credit to the University of California, Berkeley. When dozens of BSD-licensed projects each required their own advertising credit, the resulting obligation became absurd: any product incorporating multiple BSD-licensed components would need a wall of credits in every advertisement. The University of California officially removed the advertising clause in 1999, and the 3-Clause and 2-Clause BSD licenses replaced the original. No new project should use the 4-Clause BSD. If you encounter code still under the 4-Clause version, be aware that the advertising obligation technically still applies to that code unless the copyright holder has explicitly removed it.

GNU Free Documentation License (GFDL)

The GFDL was designed for software documentation, not software, but it sometimes appears in codebases because documentation and code are often mixed together. The GFDL includes provisions for "invariant sections" that cannot be modified or removed, which creates compatibility problems with most other open source licenses. Wikipedia uses the GFDL (dual-licensed with Creative Commons), but for software documentation, the GFDL is unnecessarily complex. Use Creative Commons licenses for non-software content, or simply license your documentation under the same license as your code.

Artistic License 1.0

The Artistic License 1.0 was the original license for Perl. It is notoriously vague, with terms like "reasonable" appearing throughout without clear definition. A 2007 court ruling (Jacobsen v. Katzer) raised questions about whether the Artistic License 1.0's conditions were enforceable as license terms or merely covenants, which would limit the remedies available for violations. The Artistic License 2.0, released in 2006, is a complete rewrite that addressed the ambiguities. If you encounter Perl code under "the Artistic License" without a version number, it is likely the 1.0 version, and you should treat its terms with caution.

Creative Commons Licenses for Software

Creative Commons licenses (CC BY, CC BY-SA, CC BY-NC, etc.) were designed for creative works like images, music, text, and educational materials. Creative Commons itself explicitly advises against using CC licenses for software. The licenses do not address software-specific concerns like source code access, patent rights, or linking behavior. Using a CC license for software creates ambiguity about what rights users actually have and can lead to compatibility problems with every standard open source license. Use CC licenses for documentation, artwork, and non-code assets. Use a proper open source license for code.

Licenses That Create Compatibility Headaches

Some licenses are perfectly valid and well-intentioned but create problems because they are incompatible with widely used licenses, or because their terms are unusual enough to require special handling.

WTFPL (Do What The F*** You Want To Public License)

The WTFPL is an ultra-permissive license that essentially places code in the public domain. The problem is not what it permits but rather its legal robustness. It is only two clauses long, does not include a warranty disclaimer, and its informal language raises questions about whether it would hold up in court in all jurisdictions. The Free Software Foundation considers the WTFPL compatible with the GPL but notes that it fails to disclaim warranty, which could expose the author to liability. For the same intent, the Unlicense or the MIT-0 (MIT No Attribution) license provides the same permissiveness with stronger legal language. Some corporate legal departments explicitly reject WTFPL-licensed dependencies because they consider its legal standing uncertain.

JSON License

The JSON License is the MIT License with one additional sentence: "The Software shall be used for Good, not Evil." This clause, while whimsical, creates a genuine legal problem. The restriction on use "for Evil" is a field-of-use restriction that violates the Open Source Definition (which requires that the license not restrict the field of endeavor). It is also subjective and unenforceable in any meaningful way. Despite this, the JSON.org reference implementation is distributed under this license, which has caused multiple large organizations (IBM, Google, and the Debian project among others) to either seek exceptions or replace JSON.org code with alternative implementations. Douglas Crockford, the license's author, has stated that the "evil" clause was a joke, but its legal effect is real regardless of intent.

QPL (Q Public License)

The QPL was the original license for Qt before Trolltech relicensed it under the GPL and LGPL. The QPL is incompatible with the GPL, which means QPL code cannot be combined with GPL code. Since very few modern projects use the QPL, encountering it is uncommon, but it serves as a reminder that not all OSI-approved licenses are compatible with each other.

CPAL (Common Public Attribution License)

The CPAL requires that any deployment of the software display attribution in the user interface, not just in the source code or documentation. This "badgeware" requirement means that if you modify and deploy CPAL-licensed software, you must display the original author's attribution in your application's user interface. For many use cases, this is an unacceptable imposition on product design. While OSI-approved, the CPAL's attribution requirement is unusual and creates problems that most other open source licenses do not.

Custom and Vanity Licenses

Some projects use custom licenses written by the project author rather than a standard, well-known license. This is almost always a bad idea, for both the author and the users.

Custom licenses have not been reviewed by lawyers with expertise in open source licensing. They often contain ambiguous terms, missing provisions (like warranty disclaimers), or unintended consequences. Users and companies cannot quickly assess the obligations of a custom license the way they can for MIT, Apache 2.0, or GPL, which means legal teams must review the license text individually, and many will simply reject the dependency rather than spend the time.

Custom licenses also create compatibility uncertainty. Standard licenses have well-understood compatibility relationships: MIT is compatible with GPL, Apache 2.0 is compatible with GPL v3, and so on. A custom license has no established compatibility analysis, so anyone who wants to combine custom-licensed code with code under a standard license must perform their own legal analysis.

If you want to release code and the standard licenses do not meet your needs, consider whether your needs might be better served by a dual-licensing arrangement, a standard license plus a Contributor License Agreement, or simply choosing the closest standard license and accepting its trade-offs. The practical costs of using a non-standard license almost always outweigh the theoretical benefits of a custom one.

How to Evaluate an Unfamiliar License

When you encounter a license you do not recognize, ask these questions before adopting the code:

Is it OSI-approved? Check the OSI's license list at opensource.org. If the license is not on the list, it may not be open source regardless of how it is marketed. Non-OSI licenses are not necessarily bad, but they require more careful evaluation.

Does it restrict fields of use? Any license that restricts how the software can be used (non-commercial clauses, "no evil" clauses, industry-specific restrictions) is not open source by the OSI definition and may create problems for your use case.

Is it compatible with your other dependencies? Even if the license is legitimate, it may be incompatible with licenses already in your dependency tree. Check compatibility before adopting.

Does your organization's legal team accept it? Many companies maintain approved license lists. Check yours before adding a dependency under an unusual license. Adding a dependency is easy; removing one because legal rejected it months later is expensive.

Is the project actively maintained? A project under a problematic license that is actively maintained can potentially relicense in the future. An abandoned project under a problematic license will keep that license forever, and you will be stuck with its terms as long as you use the code.