The world of open source licensing can get pretty complex for the uninitiated. Similar products can be using different licenses and thus, can have different implications around its usage. However, at the heart of the various open source licenses are two concerns -
- Specifying the rights of the users to use and modify the software
- Detailing how the modified works of the software can be distributed
Before, we go into discussion of some of the most popular open source licenses; there are three basic license templates which drive the subsequent definitions:
- Copyright License - This is as we understand in everyday usage, is designed to restrict the use of the particular product unless authorized in some manner. Typical example include most of the commercial software like Windows etc
- Copyleft License - This is an exact opposite of Copyright - in the sense that Copyleft promotes active use of the product by others with no restrictions on sharing and modifying; but with the condition that any modifications to the product are also distributed under the same license.
- Non-Copyleft License - This is very similar to the Copyleft license except for the condition where the users can modify the software and re-distribute under any license of their own choice.
Let us start with the dominant copyleft licenses. The most common license here is the GPL (GNU General Public License). According to Black Duck Software tracking of FOSS Licenses, GPL under all its variations account for nearly 64% of the market share. The most commonly accepted form is GPL2 with close to 48% market share.
The origins of GPL are closely rooted in the Copyleft principle, thus all derivative products need to be compulsorily GPLed. This makes GPL as a complex license to interpret. For example, you download a product with license under GPL, make certain changes to it like may be adding new modules and would like to re-distribute it. Sure, you can do that but all of your changes / additions to the earlier product now needs to follow the same license i.e. GPL. The philosophy behind GPL is to keep Open Source software ‘Open’.
- You can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself.
- The rule-of-thumb states that if GPL source is required for a program to compile, the program must be under the GPL. Linking statically to a GPL library requires a program to be under the GPL.
- The GPL requires that any patents associated with GPLed software must be licensed for everyone's free use.
- Simply aggregating software together, as when multiple programs are put on one disk, does not count as including GPLed programs in non-GPLed programs.
- Output of a program does not count as a derivative work. This enables the gcc compiler to be used in commercial environments without legal problems.
- Since the Linux kernel is under the GPL, any code statically linked with the Linux kernel must be GPLed. This requirement can be circumvented by dynamically linking loadable kernel modules. This permits companies to distribute binary drivers, but often has the disadvantage that they will only work for particular versions of the Linux kernel.
The last point above required that anything that statically links to GPL, must also be GPLed. However, this made the implementation of Proprietary applications on Linux difficult and was partly the driver behind the origins of the LGPL (Lesser GPL) license. LGPL differs from the GPL in that it allows the linking of software licensed under it to non-GPL software. Originally designed for use with programming libraries, the LGPL is also a popular choice for dual-licensed software by commercial companies.
Another recent extension of GPL is the GNU Affero General Public License (AGPL). AGPL extends the condition for source code provision for even the Softwares which are offered 'As a Service' using cloud computing.
At the other end of the spectrum are the Non-Copyleft licenses with complete freedom around the licensing for derived works. The most common form of this kind is the BSD-style licenses. Per BSD site, a BSD style license is a good choice for long duration research or other projects that need a development environment that:
- Has near zero cost
- Will evolve over a long period of time
- Permits anyone to retain the option of commercializing final results with minimal legal issues.
Somewhere in-between these two ends lie the other licenses; one of the most popular being the Apache 2.0 license. In fact Google has chosen Apache 2.0 as the default for all the software it open-sources. Although Apache 2.0 is permissive like BSD, but (unlike BSD) actually happens to mention the rights under copyright law and gives a license under those rights.
Over a period of time, with the increase in the number of open source licenses, multiple efforts have been made to standardize the various licenses by introducing specific buckets for the same. Open Source Initiative has come out with the following categories:
- Licenses that are popular and widely used or with strong communities (9)
- Special purpose licenses (3)
- Licenses that are redundant with more popular licenses (9)
- Non-reusable licenses (24)
- Other/Miscellaneous licenses (5)
The discussion around the above groups and their constituents is available here
With the increasing acceptance of Open Source in the Enterprise business community, it is imperative that we have better awareness around the various Open Sources licenses and more importantly, the knowledge to make an informed decision in choosing a particular license when needed.
References:
0 comments:
Post a Comment