The OSI maintains a list of licenses that they feel meet the Open Source Definition. It is possible for any project to write their own license, but this is discouraged. By choosing an existing license, a software developer guarantees users and developers that their rights are protected by a recognized, scrutinized, community-approved license.
There are two major groupings of OSS licenses that have been approved by the OSI. The first group are licenses which require all derivatives to be released Open Source. The 'GNU Public License' (GPL)[5] is the best known example. The second group are licenses that enable you to generally do whatever you like with the code as long as '[you do not] advertise this Package as a product of your own'. The Perl Artistic License[6], the BSD License[7], and the Lesser GNU Public License (LGPL)[8] are examples of this category.
The GPL-style license provides the strongest protection to your software: it ensures that every derivative of your code will be Open Source. This concept, invented by the Free Software Foundation (FSF)[9], is referred to as copyleft[10]. A drawback with copyleft is that many projects don't want to limit how their code is used, so they choose licenses with fewer restrictions.
Another approach is to explicitly release your project into the public domain, which allows anyone to do anything with it. Many federal agencies require that software developed internally be released this way. BLAST[11], one of the most-used bioinformatics tools, is an example.
For more information on issues related to OSS including approved licenses, business plans and arguments for and against OSS, we encourage you to visit the OSI website[3]. For an introduction to the more philosophical aspects of the OSS movement, visit the FSF website[9]. Both the OSI and the FSF have discussions of the pros and cons of the various OSS licenses[12,13], and now some sites are exploring the legal aspects of OSS [14].