Comparison of Software Licenses
******This document is under development*******
People who have been around Open Software tend to develop very strong opinions about licenses. Beginners don't worry about them as much since they are more concerned with finishing the task at hand and don't understand the long term implications of choosing software with one license over another (it is doubtful that there many people who understand the nuances of licensing that don't have strong opinions on the matter).
Over the years a number of licenses have gained prominence as they give software authors the type of control over their creations that most developers desire. It is still common to find software that has no copyright visible or contains a unique license developer by the author. The last can be quite annoying to distributors of software (both on-line and people who create CDs) as many of these licenses contain common mistakes which make the software difficult to distribute.
What follows is a list of common Free (Open) software licenses and some good and bad points of each. Only the points in the license relevant to the discussion are shown. Also, many points are listed under the heading "GOOD/BAD". These are points that can be either good or bad, depending on your point of view.
- The GNU General Public License (GPL).
SUMMARY: source code must be made available; software may be sold; derived works must use the same license
GOOD: There is good reason this is the most used license for Free (Open) software. It does a good job of protecting the rights of software developers and the availability of source code guarantees that users won't have to worry about losing support in the future.
GOOD/BAD: Software released using the GPL cannot be incorporated into commercial software. Whether this is actually a bad thing depends on your point of view. People developing commercial software often feel frustrated when there is a solution available that can't be used because of conflicts in licensing. Of course, there is nothing stopping them from contacting the author and seeing if they can buy a version using a different license. Most people who release software using the GPL do not consider these restrictions bad, because it allows others to use and improve the software while it prevents (for all practical purposes) others from making money off of their hard work without their permission.
- Artistic License
- BSD style license.
SUMMARY: Binaries and source code must contain the license; advertising must acknowledge the developers listed in the license
GOOD/BAD: Companies that want an executable to be generally available (possibly for free) without releasing the source code often like this license. A good example is a company that wants to release a driver for a graphics card. Open Source advocates would prefer that the company release hardware specifications anyway. If the development of drivers for XFree86 is indicative, the best drivers are those written with source available. Companies are only making their products look bad by releasing proprietary drivers that are slow and buggy. They can also save development costs by letting others develop the driver for them.
GOOD/BAD: Anyone may take the source, modify it, and release the result without releasing the changes. Whether you think this is good or bad is a personal preference.
Some common mistakes in self-written licenses:
- Either not allowing, or restricting for-profit sale of the software.
This makes it difficult to distribute the software on CD. People often
make the mistake of using terms that are not well defined, such as 'reasonable cost'.
It is better to simply use one of the licenses mentioned above as they accomplish
the same thing without resorting to such phrases.
For example, by allowing anyone to distribute the software, the GPL keeps the
costs down by the usual market forces. If someone is selling a CD with a high
profit margin it won't be long before competitors enter the market and sell
for a lower price.
Note: the Artistic License does use the term `Reasonable copying fee', but qualifies the term in an attempt to make it less vague.
- Not allowing distribution of modified versions of the software. This hinders distribution of the software by certain groups. For example, since Debian distributes compiled software, it is often necessary to modify the source to get it to compile or to make it comply with the FSSTND. But by doing this, we are then not allowed to distribute it.
- Requiring that all changes to the software be reported to the author. While it is
a good idea to report changes/improvements to the author so they can be more widely
distributed, making it a requirement can cause problems. How many people know
where they will be in 5 years?
Simply change it to 'Any changes to the software should be reported to the author'.
Most people will.
This clause is usually included to prevent branch projects from developing. History has shown that, as long as development on the original code doesn't stall, branches will only succeed if some other force drives the split.
- Stating that the software is public domain, but then adding constraints (such as not allowing sale for profit). Either something is public domain or it isn't - there is no middle ground. Such licenses are meaningless and it is likely that the extra conditions would not be upheld in court.