Software Licensing Featured Articles

Open-Source Code Carries Licensing Risks

By Tara Seals, TMCnet Contributor

Open-source software was once considered the arena of software engineering experimentation and Internet-for-all advocates, offering free, customizable and flexible applications for a range of consumer and business purposes. Increasingly though, open-source has gone mainstream—and is upsetting the apple cart when it comes to software licensing practices.

“Rather than handling objections about ‘free software,’ I now find myself having to justify a non-open-source solution I may recommend to my prospects and customers,” said Miles Kehoe, founder of New Idea Engineering, in a recent column. “Customers are not interested just because it’s free — mergers and acquisitions in the commercial space have obsoleted so many products that open-source is often the safe solution now.”

Unlike traditional, paid licensing, the open-source rules generally boil down to this: if you use an open-source tool, you must provide attribution to the original developer project in the code and documentation. But there’s a down side: licensing complexities can extend beyond this simple baseline, into the realm of the internecine and confusing.

At the core of the issue is the fact that software is often distributed using different terms for different iterations. Take GPL, the GNU Project, which uses two different licenses: GPL v3.0, and the Lesser GPL license. 

“For example, under GPL, all of the code you write that uses GPL v3.0 code must be distributed under the GPL license,” Kehoe noted. “The lesser LGPL license is a bit less restrictive — for example, you can link in other LGPL projects with your product without the requirement to LGPL your code. [But] what happens if you also use an Apache licensed library in your code? Developer beware!”

That’s because the licensing terms can make it difficult or impossible to combine code under a different style license, and taking open-source code and customizing it for a specific purpose often carries strings with it. GPL for instance requires that any software used in conjunction with the GPL code be released under GPL.

“While many of the license terms seem to have the largest impact on products written for sale or for public distribution, don’t think you’re off the hook,” Kehoe said. “Some of the license terms require that, if you modify any of the open-source code, you have to submit the changes back for inclusion into the public code. If you’ve created a proprietary algorithm to spot stock market moves, you want to be darn sure you don’t develop under such a license, or your proprietary algorithm goes public.”

Mixing and matching open-source code may then lead to issues when it comes to intellectual property rights issues related to rights and ownership, by publically exposing code from other developers.

Therefore, open-source considerations should also make their way into the mix when mulling buying software from a vendor. If a vendor uses open source in the creation of its code, customers need to know what license that software uses and whether the vendor has conducted a legal review of the product, specifically with respect to the software licenses in use.

Not every open-source project has such restrictive terms—Apache, for example, allows derivative works without the requirement to contribute changes back to the project. But the bottom line is that it’s better to be safe than sorry.

“If you are going to use open source in your application, spend some time with a lawyer who knows and understands software and open source software licenses,” Kehoe said.