Monthly Columns
 

Choosing A Software License

Copyright © 1999 Licia

For the developer of free software one of the most important tasks in preparing a public release of their work is the selection of the proper license. All too often however, this seems to be done randomly and sometimes without having even read the license selected. This is a shame as it may place your code under restrictions you do not wish, or it may allow things you do not want. Before selecting any particular license it is a good idea to define what you wish to do with the software's license and then read the available licenses carefully before choosing one. You never know what surprises may lay hidden in the 'fine print'.

While there are a tremendous range of pre-developed licenses in the world, and numerous options besides, I would like to discuss three specific licenses, and two alternatives. I, like every other human in the world, am biased by my own preferences, and will discuss these beginning with my favorite and progressing to my least favorite.

The BSD Style License

The BSL is a very simple, easy to read and understand license. It expresses in clear language, the important concepts :

  • This is copyrighted material and I own it.
  • This material is free.
  • You can use it however you want, including selling it for a profit, as long as you include a credit to me, and do not claim you wrote it.
  • Whatever happens to you because of this material is your own responsibility and I'm not liable. There are no warranties, guarantees, or refunds.

This license covers all the basics that most open source developers wish to cover and places no serious restrictions on people who may wish to use your material. It does not attempt to dictate what licensing they must apply to their modifications or to the software they have integrated with it. For example; if they link their program against your library, it does not require their program to use any specific licensing terms. With this license you support and encourage free software without risking people not using it because your license contaminates their own work and development.

The BSL's small size has the benefit of adding little to the size of your material resulting in a smaller distribution, and it's simple clarity leaves no room for misunderstanding. Additionally, this license will tend to make your software more acceptable to possible government, educational, and corporate users for whom licensing is a matter of critical importance.

The BSL is used by many people for many things. Prime examples include the three top quality free operating systems, FreeBSD, NetBSD, and OpenBSD, as well as the Apache web server. These highly educated and experienced development teams use this license specifically because it achieves their true open source goal best.

The Artistic License

The Artistic License has much in common with the BSL. It is fairly short, clearly written, and places no undue restrictions on the user. The primary differences are that it includes a definitions section to accommodate it's somewhat more complex terms, prohibits selling the actual material and has requirements for any redistribution.

If a particular distribution is covered by the Artistic License, then it may be copied, modified, distributed in virtually any shape or form, and you may charge for media, distribution costs, etc, but you may not charge for the product itself. This is not onerous, as it places no restriction on amounts that may be charged, and places no restrictions on value added charges.

The key differences from the BSL mainly regard how the license approaches redistribution of the package, requiring the original versions to be included in distributions of modified versions. It places no real restrictions as to licensing requirements of those modifications, and seems designed simply to ensure a uniform availability of the covered material. This is good in that everyone who gets a copy also receives your original and unmodified work. It's bad in that it increases the size of a distribution, possibly significantly.

Overall, this is a good license. If you need to ensure availability of your material on a uniform basis (such as Java does) then you will probably find this license to your tastes. It is well written, and the language is somewhat more elegant than that contained in the BSL, but it does target a different set of needs, and places more restrictions on the use of your work.

The best example of a distribution using this license is the PERL programming language for which it was created.

The GNU Public License

The GPL is a well known license and is used by many people. This is a large and detailed license which was created by the Free Software Foundation, in accordance with their stated mission and goals.

This license like the others, releases your software for the free use of others, however it also places certain restrictions on that use. If someone wishes to distribute their work based on or integrated with your own work, the GPL requires that they place their own software under the GPL.

It is possible to sell copies of software that has been placed under the GPL, however the full source for that software must be provided, including any value added modifications which must be licensed under the GPL.

Examples of software under this license include Linux, gcc, The Gimp, and KDE

Public Domain

One alternative to choosing any specific license for your software, is to release it into the public domain. This is a serious step, and should be considered carefully.

Placing your work into the public domain is NOT the same as any of the above licenses. It is a complete surrender of any and all rights you have to the work. Any person out there can then legally do whatever they want with the code, including selling it, renaming it, claiming they own it, etc. This is a serious step and should not be taken without great consideration and research into the ramifications.

Writing Your Own License

Writing your own license can be very simple, or very difficult. It takes as much skill and effort to write a good license as it does to develop a good program. You need to specify exactly what you want in regards to your software, using language as clear and accurate as possible.

Here is an example of a license written in a few minutes. It's a usable license but lacks the simplicity of the BSL, and the elegance of the Artistic License. The main use of this license, is to demonstrate the sections common to most software licenses.

  • The Preamble : Usually contains commentary about the purpose of the license, philosophy, etc. This should be kept short if possible, and many licenses actually disregard this section. This is also a good place to comment on the copyright and license for the license itself.
  • Definitions : Mostly used in longer, more detailed licenses, where the author is wishing to be very exact or trying to close loopholes.
  • Terms : This is where the substance of the license is located. Here you list what rights you grant the user, what restrictions they are bound by, conditions that must be met, and penalties for violating the license.
  • Warranty : This is where the usual disclaimers are put. Usually in free software, there is no warranty granted, and no liability accepted. This is usually used to specify the old Latin advice 'Caveat Emptor' or perhaps more accurately, 'Caveat Utilitor' but somewhat more verbosely.
  • Copyright : This is separate from a license, and actually has very little to do with licensing. Copyright is a statement of ownership regarding the rights of a piece (intellectual property assertion), but has for some reason become synonymous in software with the license. You may specify the copyright inside the license if you wish, but you should make it clear that the copyright refers to your work and not to the license, which itself is copyrighted. An example would be to phrase it such as : "MyWidget is copyright (c), 1998 by Foo Inc."

Licia licia@o-o.org