|< Day Day Up >|| |
Whether you’re writing code for commercial sale as a shrink-wrapped application or as part of a consulting contract, you need to think about software licenses. The license is the piece of paper (or, more likely these days, the text file) that governs the users’ rights to use the software. There are a wide variety of licenses that you can use, and it’s worth understanding some of the basic differences.
By default, your code is protected by copyright. For all practical purposes, this means that you own the code and you can dictate the terms under which others can (or cannot) use it. If you wish to give up ownership completely, you can do so by placing the code in the public domain. You can do so by including a simple statement when you distribute the source code, perhaps in a comment:
// The author of this code dedicates any and all copyright interest // in this code to the public domain. I make this dedication for the // benefit of the public at large and to the detriment of my heirs // and successors. I intend this dedication to be an overt act of // relinquishment in perpetuity of all present and future rights // to this code under copyright law.
Placing code in the public domain is the most extreme action you can take with regard to your copyright; you’re essentially nullifying the copyright completely. For less extreme actions, which allow you to retain some rights while granting others some rights, you’ll need to use a software license to spell out your desires.
Once you put code in the public domain, that’s it. Anyone can take your code, alter it, use it as is, include it in another product, or profit from it, without crediting or compensating you.
Open-source licenses are a class of licenses designed to encourage sharing computer software. Many popular and successful computer applications these days are distributed under an open-source license, including the Linux operating system and the Apache Web server. If you’re interested in making your code freely available, an open-source license may be ideal for you.
Although there is some debate over what “open source” means (and whether it’s the same as “free software” or something different), the Open Source Initiative (OSI) offers a reasonably authoritative definition at www.opensource.org/docs/definition.php. The OSI offers these general characteristics of open-source licenses:
Free redistribution of software
Distribution with source code
Permission for derived works under the same license
Distributing modified code or patch files allowed
No discrimination against persons or groups
No discrimination against fields of endeavor
No additional licenses required
No forced bundling
No attempt to restrict other software
No special technology required by the license
A wide variety of licenses conform with these guidelines. As of this writing, the OSI has certified nearly 50 different licenses as being conformant with its concept of open source. I’ll introduce a few of the better known of these licenses here: the GNU General Public License, the BSD License, and the Mozilla Public License. If you visit the OSI website, you’ll find links to many other open-source licenses to choose from.
Open-source licensing has been a topic of much debate and more than a few flame wars. In particular, the Free Software Foundation (FSF), the originators of the GPL, often seem to be at odds with everyone else over philosophical differences. A visit to the FSF website (www.gnu.org) will give you all the licensing philosophy you could ever want to read. Microsoft, too, has had many critical things to say about open-source licensing. I’m going to concentrate on the practical aspects of the various licenses as I understand them, and try to avoid the philosophy.
An interesting sidelight to open-source licenses is the Creative Commons project (http://creativecommons.org), which is crafting analogous licenses for creative works. You may want to look into these licenses for manuals or other nonsoftware artifacts.
The GPL is the best-known (perhaps notorious would be a better word) open-source license. You’ll find the authoritative version online at www.gnu.org/copyleft/gpl.html. The GPL allows you to distribute copies of the source code and application that you receive, under certain conditions. The condition that troubles some people is section 2b of the license:
You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
This clause makes the GPL an infectious (or viral) license. For example, if you find a graph control that you like, and it’s licensed under the GPL and you use this control in your own application, then you must likewise license your application under the GPL. This means that your own application is subject to all of the requirements of the GPL, including the requirement to make your source code available.
The GPL includes copyright as a sort of fallback provision. Section 5 of the GPL reads:
You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
In other words, when you license code under the GPL, you’re explicitly not placing the code in the public domain. Instead, you’re setting out conditions under which users may redistribute your work, including explicitly the condition that they accept the GPL.
The GPL limits the people who receive your source code, not you. If you like, you can still use other licenses. For example, you could release the first version of your application under the GPL, and the second version under a proprietary license. You can even license some users of the first version under a different license. For example, you might offer a license that includes support and custom modifications but does not include the right to redistribute the custom modifications to paying customers. What you cannot do with the GPL is remove the rights of anyone who received the code under the GPL license. In the scenarios I’ve outlined here, people who get version 1 under the GPL can continue to redistribute it, and works based on it, as long as they like (and as long as they remain in compliance with the GPL terms themselves).
BSD originally stood for Berkeley Source Distribution, the version of Unix that included the first version of this license (the license has since been modified somewhat). Unlike the GPL, which contains several pages of legalese, the BSD license has just two essential clauses (preceded by an assertion of copyright and followed by a disclaimer of warranty). Here’s the version used by the FreeBSD variant of the operating system (www.freebsd.org/copyright/freebsdlicense.html):
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
There are continued debates over whether the BSD license is freer than the GPL. On the one hand, it allows users of the software much more latitude than the GPL. On the other, it allows them to take from the community without giving back. Microsoft, for example, is known to have incorporated BSD-licensed networking code into Windows. As long as it includes the appropriate legalese, this is perfectly legal, and it has no obligation to reveal the source code of Windows. Unlike the GPL, the BSD license is not viral.
The Mozilla Public License was developed by the open-source Mozilla web browser project. You’ll find it (and various related documents) at www.mozilla.org/MPL/. The MPL is even more complex and loaded with legalese than the GPL, apparently because Netscape’s lawyers had a hand in crafting it. To get an idea of what this means, consider part of the source code licensing terms from the MPL:
2.1. The Initial Developer Grant.
The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims:
(a) under intellectual property rights (other than patent or trademark) Licensable by Initial Developer to use, reproduce, modify, display, perform, sublicense and distribute the Original Code (or portions thereof) with or without Modifications, and/or as part of a Larger Work; and
(b) under Patents Claims infringed by the making, using or selling of Original Code, to make, have made, use, practice, sell, and offer for sale, and/or otherwise dispose of the Original Code (or portions thereof).
(c) the licenses granted in this Section 2.1(a) and (b) are effective on the date Initial Developer first distributes Original Code under the terms of this License.
(d) Notwithstanding Section 2.1(b) above, no patent license is granted: 1) for code that You delete from the Original Code; 2) separate from the Original Code; or 3) for infringements caused by: i) the modification of the Original Code or ii) the combination of the Original Code with other software or devices.
While the GPL is written so that the average developer can understand it, the MPL is clearly written by and for lawyers. Despite this complexity, the MPL is largely compatible with the GPL; it grants nearly the same rights under the same conditions. However, there’s one major difference between the two. The GPL forbids combining GPL code with proprietary code in a larger work. The MPL expressly allows this. The MPL thus occupies a sort of middle ground between the GPL and BSD licenses.
Shared source is Microsoft’s answer to open source. As such, it is not currently a very popular licensing model, but it’s one that you should know about as you consider the spectrum of available licenses for your code. You can learn more at www.microsoft.com/resources/sharedsource/default.mspx, where you’ll also find some polemics about why the GPL is bad for the software industry.
Under various licenses that it groups into the Shared Source Initiative, Microsoft has opened up selected portions of its source code to nonemployees without giving up copyright and other protections. Instead, it has granted specific rights for different programs. For example, in some programs licensees can use the source code only for reference and debugging. In others, they have the right to modify the code and distribute the results (this is how Windows CE is licensed to embedded manufacturers, for example).
Microsoft does not generally make the text of its shared-source licenses available to non-licensees. An exception is the license for the shared-source implementation of the Common Language Infrastructure, which you can read at http://msdn.microsoft.com/msdn-files/027/001/901/ShSourceCLIbetaLicense.htm.
Most developers will probably want to ship their applications using a proprietary license. This is a license that specifies the rights of the user to use the software but that normally does not grant any source code or redistribution rights.
Unlike open-source licenses, proprietary licenses do not have any central repository. This can make it tough to find one to use with your software. I know of three general approaches you can use when crafting a license to use with your product.
Perhaps the safest alternative is to hire a lawyer to write the license for you. Assuming you find a lawyer with a working knowledge of the software industry (which may be tough, depending on where in the country you’re located), this should get you a solid, usable license ideally fitted to your needs. It’s also undeniably going to be the most expensive alternative, and the expense may be unmanageable depending on the size of your operation.
Another way to develop your own proprietary license is to find a software package that you admire and commandeer its license, changing the company name to your own. While inexpensive, this is a risky strategy; depending on the license, there may be some terms that don’t apply to your product, or other things besides the company name (such as the state whose laws apply) that you should change.
Finally, you can split the difference and go the legal self-help-route. One good book is Web & Software Development: A Legal Guide, by attorney Stephen Fishman (Nolo Press, 2002). In addition to a chapter on licenses, this book includes much other information of use to the small developer, including the basics of copyright, trade secrets, and patents, employment agreements, and domain name issues. You can order a copy of either the printed book or an e-book version from Nolo’s website, www.nolo.com.
There’s no way I can give you a one-size-fits-all license agreement to use with your software. But here are some areas that are often covered in a proprietary license:
A notice that the software is licensed rather than sold, and instructions for returning it if the user does not agree.
A notice that you retain title in the software and all of your intellectual property rights.
The rights the users are granted, including how many computers they may use the software with simultaneously and how many backup copies they can make.
The term of the rights, whether perpetual or limited to a term of years.
A list of things users cannot do. Typically this includes decompilation, reverse-engineering, sublicensing, renting, or leasing the software.
A limited warranty. Normally this translates to the absolute least warranty allowed by law, with the only remedy being a new copy of the software.
Termination provisions. Normally users are required to destroy all copies if they break the license.
A notice of which state any legal action will be taken in. You always want this to be your home state; the expenses of pursuing legal action in another state can be substantial.
Be sure you understand which rights your license is granting to your customers.
|< Day Day Up >|| |