Unravel open source licenses

With various licenses governing open source software (OSS), organizations must ensure they better manage the source codes of these applications upon deployment, in order to stay within the licensing requirements.

According to Bryan Tan, director at Keystone Law, implementing open source software that adhere to different licenses can complicate matters for users as each license will carry different terms.

Notably, before the introduction of GPLv3 (General Public License version 3), a company developing on open source using different modules would have to check through the license terms for each module, Tan said in an e-mail interview.

"Further, there used to be some confusion over what a derivative use meant, so parties developing were not sure whether the use of libraries would be creating a derivative work. However, this has [since] been clarified," Tan explained.

You're much more likely to stumble and need to manage your proprietary software licenses that expire and require control of usage and copies--that is, there're real boundaries and restrictions compared to the open source ones.

Bruno Souza, Sun Microsystems

He added that some of this confusion were sorted out with projects such as Creative Commons, which depicts different licenses according to icons. Each icon outlines how the software can be distributed or used.

"This cuts down the variance," Tan said.

A Creative Commons license lets one use another's work without having to seek the permission of its creator or licensor, but the person using the work must do so in the manner permitted by the Creative Commons license.

Mark Lim, head of intellectual property, media and entertainment at law firm Tan Peng Chin, noted that, generally, using OSS on a day-to-day basis to support work processes, does not engender legal problems.

For example, if a company uses the OSS word processor, Open-Office Writer, documents the company produces with Open-Office Writer will not be subject to any open source obligation. Therefore, the company can use the word processing software for free without any legal complications, Lim said in an e-mail interview.

According to Bruno Souza, director of Sun Microsystems' worldwide open source initiative, issues associated with the various open source licenses will only affect companies that want to modify and redistribute the software--something that proprietary software only allows under heavily negotiated deals and contracts.

"Companies that are interested in doing this already have to deal with all kinds of complex licensing agreements, of which, open source is a much simpler model," Souza told ZDNet Asia in an e-mail.

Lim said a company planning to modify and redistribute open source code must carefully scrutinize terms outlined in the license. It must first determine if the license has a "copyleft" provision, and if so, the new software must be distributed with this provision.

Under copyleft licensing, companies can modify and reproduce the software but must also make their own modified versions of the software available under the same copyleft licensing model.

If there is no copyleft provision, it is necessary to distinguish between modifications--or add-ons to the original OSS source codes--and derived codes, which are resultant source codes created using all or part of the original source codes.

According to Lim, modifications and add-ons are usually not governed by the open source license. This means the company will have a separate copyright to the modification, and is not constrained on how it chooses to license this copyright. "In particular, it can choose to charge a price for it," he said.

Public distribution of derived works, however, would almost certainly be affected because the open source license does not grant the author of the derived work any copyright over the original source codes. Further, Lim added, any distribution of the original source codes must abide by the open source license that governs the original codes.

"It will therefore not be possible to commercialize the derived work without breaching the open source license," he said.

Legal bugs proprietary, too
Brian Prentice, research vice president of emerging trends and technologies at Gartner, highlighted that while legal issues are a factor in OSS, it does not mean they are not a consideration in proprietary software.

"The number of different open source licenses is certainly a factor to consider in an open source governance strategy," Prentice said in an e-mail. But, he added, any software use should involve a careful analysis of contract terms and conditions.

"In the case of proprietary software, this needs to be done on a case-by-case, vendor-by-vendor basis. At least in the case of open source, the license agreements are available through the Open Software Initiative (OSI) ," he said.

Furthermore, said Sun's Souza, open source is less restrictive than any proprietary license. "You're much more likely to stumble and need to manage your proprietary software licenses that expire and require control of usage and copies--that is, there're real boundaries and restrictions compared to the open source ones," he noted.

To ensure companies keep within the boundaries of the various licenses, Prentice urged businesses to have clear rules and regulations on how, and when, OSS is deployed across the organization.

"The pressing issue is not really navigating license conditions," Prentice said. "It's actually all the OSS code that's embedded in solutions, unbeknownst to the organization as a whole, because individual developers downloaded a project and embedded it in their work."

An organization should also make sure it is aware of its exposure to OSS code that has seeped into the organization, he said. Tools from companies such as Black Duck and Palamida, can help to identify such codes, he added.

Prentice said: "Finally, the IT organization as a whole should be aware, on an OSS project-by-project basis, what is allowed and isn't allowed based on the licensing."

Keystone's Tan advised companies to "keep reading those licenses". "If there is doubt over which license applies, then always seek clarification--or else don't use it," he said.

Specialized OSS team
According to Prentice, it is imperative organizations ensure they have OSS licensing competency in their organizations. But, the analyst noted, having a specialized OSS team to oversee this would require a huge commitment.

Instead, they should consider having OSS specialists within an existing sourcing team, or ensure that a basic level of understanding of OSS licensing exists across the team.

Souza said the decision to have a dedicated OSS team or not depends on the company's goals.

He explained that companies using OSS to run their infrastructure or to offer services to their customers, find that such software costs less, does not tie them to any vendor, and lets them adapt the software to their needs. "All this [comes] with very little legal risk because the mere usage of OSS does not carry any special compromise," he said. "Proprietary software licenses have much more complex usage licensing."

However, companies building on top of OSS--modifying, adapting, redistributing and contributing codes--have a more complex legal situation, and need to evaluate how exactly they plan to incorporate OSS into their development process, Souza noted.

"Even then, compared to the alternatives--negotiating a licensing contract with a vendor and incorporating a proprietary code base into your product--open source licensing is far simpler," he said.

He added that a company would do well to have specialized OSS teams, focused not on open source in general, but on products that are needed by the company.