Open source software (OSS), like any other software, is protected by copyright and its usage is governed under a license. As such, it is important enterprises pay attention to considerations, such as how much freedom they need with regard to developing on the source code or whether they plan to monetize the software, before deciding which license to use.
According to Mike Knapper, partner at U.K.-based law firm Norton Rose, there are many different open source code bases serving a range of different purposes and operating under different license terms. The more commonly used ones are GNU General Public License (GPL), Apache and Perl, but Knapper pointed out that discussions should not revolve around which license to use but which one suits the company's or developer's purposes.
"The key thing that companies need to understand when using OSS is that the code is protected by copyright, just like any other software, and so a license is needed to use it," he explained. "It is crucial to understand what the terms of the OSS license."
Harish Pillay, global head of community architecture and leadership at Red Hat, also pointed out that there is a list of licenses approved by the Open Source Initiative (OSI) available online. The OSI is a non-profit organization which aims to educate and advocate the benefits of open source, and acts as a standards body with its OSI Approved License trademark and program.
ZDNet Asia spoke to Knapper, Pillay and other industry players who offered some pointers organizations should note when deciding which license to use for the various OSS they might deploy.
Freedom to innovate, distribute
Sachin Dabir, chairman of the OSS for innovation and collaboration special interest group (SIG) at the Singapore Computer Society (SCS), recommended that developers and companies building and releasing software under OSS licensing consider the extent of freedom they need to further innovate and distribute the software.
For example, they will need to figure out if the software license allows the source codes to be used in closed source projects, or whether the software can be sold commercially, Dabir explained.
GNU GPL license, for one, encourages the work and derivatives of the OSS to be kept under the same license and the source codes to be distributed along with it. It does not allow the source codes to be used in proprietary software projects, he noted.
Dabir also pointed out that the commercialization or monetization model for the software determines the type of license to use. This would mean identifying whether the software is meant to be shared within the open source community, or if it is closed and to be used for commercial purposes, he said.
Knapper added that while OSS licenses are, by nature, generally permissive, careful thought needs to be given before using "copyleft" licenses.
"These require the code that is derived from the original OSS code to, in turn, be made available for free to anyone under similar open source license terms. This can have serious impact on the commercial viability of the developed software," the lawyer said, pointing to GNU GPL as an example of a "copyleft" license.
Another consideration for "copyleft" licenses is that they allow more people to join in the creative process and encourage more to enter the development community, Dabir said.
"By making it mandatory to make all the derivative work under the same license, you are encouraging the larger community to work with you," he noted.
Pillay added that the GNU GPL is popular because it ensures the original source code survives, even after the original authors of the software are no longer participating in the development.
"The GPL also ensures that the knowledge in the code is never hidden and lost, [but can] be reinvented over and over again," he said.
Jeffrey Hammond, principal analyst at Forrester Research, suggested that the best option for companies "getting their OSS feet wet for the first time" is to start with well supported OSS projects such as Linux or JBoss, which vendors have committed to provide commercial support and extensive online forums to help those encountering problems or configuration issues with the OSS.
Having the right people
Hammond also called on companies to look at their internal resources to see if they have the right people in place to manage the intricacies of an open source environment.
"In the OSS world, you have to go out and find the right answer to questions, seek help, google error codes, find the right forum," the Forrester analyst said. "You also generally need more talented developers to work with. That's not the culture that all IT shops have."
Track software development
Knapper added that it is also important for companies to keep a log of all software development work done on the original open source codes. This includes charting what codes were used, their origins such as whether they were developed by an employee or contractor, as well as identifying the relevant license terms.
This is necessary because if the development team changes in the future or if the company plans to commercialize internal software, it can quickly understand and, if necessary, demonstrate to a future purchaser or licensee how the software was developed, and whether there is any risk associated with the use of open source codes in the software, he explained.