The Open Source Definition was actually derived from the Debian Free Software Guidelines (DFSG); those original guidelines are still maintained and used by the widely-used and influential Debian project. Thus, the Debian guidelines are nearly identical to the Open Source Definition, yet Debian tends to use the term “Free Software” in its materials.
In addition, the debian-legal mailing list discusses licensing issues in great depth, in an effort to evaluate licenses based on the freedoms they grant or do not grant. The DFSG and Software License FAQ states that “The DFSG is not a contract. This means that if you think you’ve found a loophole in the DFSG then you don’t quite understand how this works. The DFSG is a potentially imperfect attempt to express what free software means to Debian.”
The DFSG and Software License FAQ also defines three additional “tests” used on the debian-legal mailing list to help them evaluate whether or not a license is “Free” (as in freedom). These tests aren’t the final word,
but because they’re described as scenarios, they are sometimes easier for people to understand (and I quote the Debian FAQ here):
The Desert Island test. Imagine a castaway on a desert island with a solar-powered computer. This would make it impossible to fulfill any requirement to make changes publicly available or to send patches to some particular place. This holds even if such requirements are only upon request, as the castaway might be able to receive messages but be unable to send them. To be Free, software must be modifiable by this unfortunate castaway, who must also be able to legally share modifications with friends on the island.
1.
The Dissident test. Consider a dissident in a totalitarian state who wishes to share a modified bit of software with fellow dissidents, but does not wish to reveal the identity of the modifier, or directly reveal the modifications themselves, or even possession of the program, to the government. Any requirement for sending source modifications to anyone other than the recipient of the modified binary - in fact any forced distribution at all, beyond giving source to those who receive a copy of the binary - would put the dissident in danger. For Debian to consider software Free it must not require any such excess distribution.
2.
The Tentacles of Evil test. Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non-Free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying Free software in order to maintain its monopoly and extend its evil empire. The license cannot allow even the author to take away the required freedoms!
3.
And there are practical issues that arise too:
GPL compatibility is very desirable. The GPL is by far the most popular OSS/FS license. Thus, an OSS/FS license that isn’t compatible with the GPL causes many practical problems, because the vast amount of GPL software can’t be combined with it. Indeed, if a specification cannot be implemented by software released under the GPL, it essentially discriminates against OSS/FS business models in
general because so much OSS/FS is released under the GPL. Choosing a GPL-compatible license (such as the BSD-new, MIT/X, LGPL, or GPL license) is often the safest course. See my paper for more information on why selecting a GPL-compatible license is important for OSS/FS projects.
1.
Having many OSS/FS licenses (”license proliferation”) is undesirable. Bruce Perens’ article “The Open Source Definition” explained back in 1999 that “Do not write a new license if it is possible to use one of [small set of common licenses listed in the paper]. The propagation of many different and incompatible licenses works to the detriment of Open Source software because fragments of one program cannot be used in another program with an incompatible license.” New licenses also make it hard for customers and developers to understand what their requirements are. More recently, there have been increasingly active steps to discourage creating new OSS/FS licenses (which are typically
corporate vanity licenses), instead of using one of a small set of licenses that are already in wide use. For more information, see comments by Danese Cooper (Intel and secretary/treasurer for the Open Source Initiative (OSI)) and Chris DiBona (Google), as well as the article “HP exec calls for fewer open-source licenses” by Robert McMillan (ComputerWorld, August 6, 2004).
2.
Choice-of-law and choice-of-venue requirements are very undesirable. Many developers strongly object to licenses that specify that the licensee must agree to be judged by the laws of a specific jurisdiction and/or be judged at a specific location. This was a key problem, for example, for the older Python licenses. The problem is that choice-of-law and choice-of-venue requirements create
superfluous incompatibilities with any other licenses with choice-of-law and/or choice-of-venue restrictions (which would, in practice, always be different from each other). A goal of OSS/FS licenses is to allow software to be combined and modified in new, innovative ways, and such statements
interfere with that goal. 3.
Advertizing clauses are very undesirable. Some old licenses, like the old BSD license, required that credit be given to developers in certain ways, e.g., whenever a product is advertized. When there’s only one developer, that doesn’t sound too bad. But imagine what happens as more developers get involved -- suddenly each advertisement has to individually list (say) 20,000 people! These kinds of licenses don’t scale well as more people become involved, and major OSS/FS projects can involve large
numbers of developers. Crediting developers in the source code is very common practice, of course, but that’s not the same thing.
4.
A technical discussion examining the freedom of a license might compare the license against the Free Software Definition (all four freedoms), the Open Source Definition (every point) and/or the Debian Free Software Guidelines, and the tests (scenarios) above, as well as considering practical concerns like the ones above. An example of such analysis is Mark Shewmaker’s August 2004 examination of the Microsoft Royalty Free Sender ID Patent License.