Getting Started with Open Source Licenses

With proprietary software, it's easy for a developer to know where he or she stands. Unless you or the company for which you're working owns the copyright to the code, it's off limits -- end of story. There's usually not even any temptation to use the code, because the source code is usually not available.

Moving into open source opens up a whole new world that can make things a lot easier. Suddenly, you're not constantly having to reinvent the wheel by writing code for processes where there's code already written and waiting at the ready. In some circumstances, you can even use open source code inside a proprietary project.

There are complications. Before you can go copying code willy-nilly into your projects, you need to make sure there aren't any compatibility issues between the license you're copying or relicensing from and the license that will be used for your project. You don't need to be an expert on each of the commonly used open source licenses approved by Open Source Initiative, which sets the standards for open source licensing -- you can look those up as the need arises (and if you have trouble with the legalese, you might want to consult an intellectual property expert).

You can also help yourself get started by understanding the two main classifications of open source licenses, which are "permissive" and "copyleft."

Permissive licenses: These days permissive licenses, such as Apache, MIT and BSD, are used by most open source projects developed for the enterprise, mainly because in most cases, code covered under a permissive license can be relicensed as proprietary. For this reason, most permissive licenses also don't require modifications to be made available upstream nor do they require making source code available. That would be akin to demanding that Coca-Cola reveal its secret ingredients.

Some restrictions do apply. Each license has its own terms and conditions, so before moving code from one permissive license to another, care must be taken to make sure that doing so doesn't break conditions established by either license. Also, nearly all licenses, whether permissive or copyleft, require attribution to be included in the code. Attribution generally lists things such as copyright information, and requirements for content and format varies from license to license. Requirements for attribution will be included under the licenses terms and conditions.

Some permissive licenses, usually classified by OSI as "non-reusable licenses," require that only the entire application can be used and place restrictions on modifications. Tread carefully around code covered under these licenses.

Copyleft licenses: Also called "reciprocal" licenses, copyleft licenses always stipulate that code, including modifications, be freely distributable, and that those rights be preserved down the line. In other words, once code is released under a copyleft license, it will remain under that license forever, including any of your own code you add and then distribute. In most cases, unless it's a project in which you own all copyrights, the code can't even be rereleased under another copyleft license. For example, a library file in Linux, which is licensed under version two of the GPL, can't be released under version three, as GPLv3 places restrictions on the code's use that aren't specified in GPLv2. Copyleft licenses also require that any changes or modification to the code be made available upstream.

Although code under a copyleft license can't be used in a project that will be released under a permissive license, the reverse is not always true. If a permissive license is "GPL compatable," meaning none of its conditions would violate the terms of the GPL, then code covered under that license can freely be used in projects licensed under the GPL and most other copyleft licenses. A complete list of GPL compatable licenses is available on the GNU website.

The differences in the restrictions between permissive and copyleft licenses can have some interesting consequences. In 2010, a group of developers for the productivity suite OpenOffice.org forked the project, which was released under a permissive license, and released it as LibreOffice under the GPL. Because the OpenOffice license was compatible with the GPL, any improvements made to OpenOffice could be freely used by LibreOffice developers if they wished, although GPL terms made improvements to LibreOffice off limits to OpenOffice developers. This gave the developers of LibreOffice a decided advantage.

Counter intuitively, if you or your company owns the copyrights to all of the code in a project and wish to offer both a free open source version as well as a proprietary paid version, there can be advantages to dual license using the GPL instead of a permissive license for the open source version. By doing so, you remove the option for competitors to piggyback on your work and use your code to create their own value added paid versions that competes with you.