TL;DR
SimPL 2.0 and MS-RL are robust, vetted copyleft licenses short enough to fit on a single page —the share-alike equivalents of MIT and BSD— yet most developers have never heard of them.
Many developers choose to release their software under a copyleft (share-alike) license, to ensure that any software building upon it must also be shared openly on similar terms, thus actively contributing to the digital commons.
However, the most well-known options for copyleft licenses, such as the GNU General Public License (GPL) or the Mozilla Public License (MPL), tend to be relatively long and complex documents. This can make their use less appealing, as both users and maintainers of free software (who are normally not legal experts) may feel uncertain whether they fully understand what they’re agreeing to.
This is in stark contrast to the permissive side of open source, where short and readable licenses like MIT, BSD, and ISC have flourished alongside longer and more detailed ones like Apache or Artistic.
The remarkable popularity of the MIT license, as well as the rapid dissemination of the Creative Commons licenses, clearly indicate that there is appetite for straightforward, legible agreements whose conciseness and clarity provide confidence to both licensors and licensees.
That appetite is equally present among developers who prefer share-alike terms, but it is underserved by current well-known copyleft licenses. This doesn’t have to be the case, as shown below.
A few proposals for concise, readable copyleft licenses have been put forth, but they tend to lack institutional recognition (from the OSI, FSF, and in many cases even an SPDX identifier) and have generally not achieved broad adoption. A notable example is Kyle E. Mitchell’s Parity Public License, among others like Round Robin, Patches Back, Maximaleft and Libre Source.
Two licenses, however, stand out from this set:
SimPL was originally drafted by Robert W. Gomulkiewicz, an intellectual property law scholar from the University of Washington School of Law, and published in a 2005 paper in the Houston Law Review.
Its own text describes it as a plain-language implementation of GPL 2.0. That makes it an interesting option for projects that want reciprocity without having to adopt a complex, lengthy copyleft license.
What makes SimPL especially notable among lightweight copyleft licenses
is that it has been formally approved by the OSI.
It also has an SPDX identifier (SimPL-2.0),
and even an entry at tl;drLegal.
Given that SimPL was written with the explicit goal of matching the terms of GPL 2.0, it complies by design with the FSF’s criteria for free software licenses, and is therefore likely GPL-compatible — though the FSF has not yet declared that explicitly.
The Microsoft Reciprocal License (MS-RL) was introduced by Microsoft in 2007, as part of the set of licenses it submitted for OSI review. In the corresponding discussion on the OSI license list, Microsoft explicitly stated that it sought to draft a license that was “simple, short, and easy-to-understand”.
Like the SimPL 2.0, MS-RL is approved by the OSI,
has a registered SPDX identifier (MS-RL)
and an entry at tl;drLegal.
Interestingly (especially in contrast to the SimPL), the MS-RL has been explicitly approved as a free license by the FSF, though it notes that it is not GPL-compatible.
Here are both licenses in full, showing how they easily fit on a single page of text:
Simple Public License (SimPL) 2.0The SimPL applies to the software's source and object code and comes with any rights that I have in it (other than trademarks). You agree to the SimPL by copying, distributing, or making a derivative work of the software. You get the royalty free right to:
If you distribute the software or a Derived Work, you must give back to the community by:
There are some things that you must shoulder:
The SimPL continues perpetually, except that your license rights end automatically if:
|
Microsoft Reciprocal License (Ms-RL)This license governs use of the accompanying software. If you use the software, you accept this license. If you do not accept the license, do not use the software.
|
While this is not legal advice, it is worth pointing out that the SimPL may have some advantages over the MS-RL; specifically:
The relevance of points 4 and 5 is naturally subjective, and for some people the preference may even be inverted, so feel free to ignore them. Points 2 and 3, while being arguably somewhat minor, are nevertheless valid arguments in favor of the SimPL.
The distinction from Point 1, regarding copyleft scope, is perhaps the most important factor for someone making a choice between the two: MS-RL differs from SimPL in that its reciprocity (share-alike) requirements apply only to individual files of the derivative work (clause 3.A), i.e. only those that contain code from the covered software, as opposed to the derivative work as a whole.
This makes MS-RL closer in effect to file-level copyleft licenses like the MPL — an arrangement sometimes called “weak copyleft”, as it protects against “proprietization” of the licensed software, but does not prevent it from being incorporated into a larger proprietary system, e.g. as a library included into end-user programs.
Conversely, the SimPL is more akin to the full reciprocity associated with the GPL, whereas only projects that are fully licensed under similarly open terms can incorporate software under the SimPL. These are often called “strong copyleft” (or, sometimes pejoratively, “viral”) licenses.
Still, both options further the goals of the copyleft principle —i.e. ensuring that the free software ecosystem remains open and growing— so either of them can be used to promote simple, approachable copyleft licensing, depending on the individual preferences.
If you want a short, readable copyleft license, SimPL 2.0 is a great choice: it is institutionally recognized, ecosystem-ready, shorter than the alternatives, and explicitly designed to be the plain-language equivalent of the GPL.
If you specifically prefer file-level copyleft (where only the files containing your code need to be shared back, rather than the project as a whole), MS-RL is a solid runner-up that fulfills the same goal of simple, approachable licensing.
If you’re convinced and want to start using these licenses in your projects,
you can do it as usual, by placing the full license text in a root-level file,
using any of the standard license filenames
— e.g. LICENSE, LICENSE.md, LICENSE.txt, COPYING.txt, etc.
You’ll probably also want to use the corresponding SPDX identifier (SimPL-2.0 or MS-RL)
in metadata or package manifest files like package.json, Cargo.toml, or pyproject.toml.
Finally, it can be helpful to mention the licensing choice explicitly in the README, especially since that can contribute to popularizing these licenses, by making them more visible and thus leading more people to learn about them.