On a fairly regular basis, organizations large and small get the urge to craft their own "open source" licenses. This desire arises and persists despite the existence of approximately one hundred OSI-approved licenses, plus over two thousand other self-styled Free and Open Source (FOSS) licenses (e.g., the Beerware License). These FOSS-ish licenses do not earn a place on the OSI list because they are either too similar to existing approved licenses or they violate one or more principles of the Open Source Definition and or the Free Software Definition.
This blog addresses the most common motives for writing one's own license and why you should resist the urge.
Why you might want to
Despite the plethora of free and open source licenses, many organizations feel the (ill-advised) need to craft their own.
Reasons organizations think they need a new license:
None of the OSI licenses fit their particular (special) requirements, e.g., the need to protect "rights and privileges", especially of certain non-profits, NGOs and regional governments
The desire to protect proprietary intellectual property from competitive use
Rejection of perceived-onerous language in popular OSI licenses around IP, patents and reciprocity
Organization lawyers insisting on using a unique license, for whatever reason
Given these motives, you'd think that organizations would simply employ proprietary licenses. Those same organizations often also want the advantages of collaborative community participation or just the cachet of publishing code as open source and/or they need their existing software portfolios to incorporate or interoperate with free and open source code.
Why creating yet another license is a bad idea
There are many excellent reasons to avoid rolling your own "open source" license.
Your organization will likely be the only one using it
Potential users will reject it because it is not in their catalog of approved licenses
It may not be compatible with other existing FOSS licenses, and you and your potential users will need a lawyer familiar with open source licensing to understand the particulars of interoperability
It may violate one or more of the ten OSI Open Source Principles, e.g., by being particular to your org's product or excluding certain types of applications
What to do instead
Organization-specific FOSS-ish licenses can persist for years in an organization, crafted by legal teams but never accepted by developers and partners.
Use an OSI approved license
The simplest solution is to eschew the urge and to employ an OSI license. Putting aside issues of taste and sensibility, it's worth pausing to consider the real gravity of perceived requirements for a unique license, and the actual level of risk in making code open source.
Add a preamble to an OSI license
If your divergence from the substance of an existing open source license is very well defined and constrained, you may be able to add a preamble that modifies that license without actually changing the language of the license.
The best-known example of this practice lies in the Linux COPYING file and the referenced Linux Syscall Note, forming a preamble to the GNU General Public License version 2 (GPLv2) that governs the Linux Kernel. In particular, the COPYING sets apart the Linux kernel system call interface, relieving applications and libraries using that interface from the requirement to also use GPL and observe its disclosure requirements. The result is that proprietary applications can deploy and run on a Linux-based system without concern for "GPL virality".
A preamble represents a decent compromise but is not actually a popular path to IP protection. The combination of new language imposed upon an existing license can prove as problematic as attempts to craft an entirely new license.
Use a proprietary license
If none of the alternatives listed in this article satisfy your licensing needs, perhaps what you really need is a proprietary software license. The flexibility and control you will obtain with a fully proprietary license may be more important than whatever cachet and community dynamics you might lose by not employing an open source license. And, proprietary licensed code can still interoperate with open source libraries and FOSS code under permissive licenses. Such combinations of open source proprietary code constitute the norm in both device and cloud-based software, and can support an Open Core architecture and accompanying business model.
Conclusion
In today's world of rapidly-changing application requirements and agile development, your organization can't afford downtime from licensing bottlenecks. Using existing, standard, pre-vetted software licenses lets you more easily leverage the vast universe of open source software components and limits the impact of licensing on delivery timelines.
The OSI is a very conservative organization and can take years to evaluate and approve a new license when and if a new one is truly merited. Whenever possible, it’s best to employ existing OSI-approved licenses or use a proprietary one.