Open-source software is becoming the backbone of the software development industry, helping to spur innovation, reduce time to market and lower costs. According to Jim Zemlin, executive director of the Linux Foundation, almost every device or piece of software we use today contains some open-source code.

“There are hundreds and thousands of products and services that we all depend on every day that contain a vast amount of open-source software,” he said. “Whether it is every single Android device out there, whether it is an Apple iPhone, a Windows product, you name it, there are lots of open-source software in there.”

It is no longer a matter of whether an organization should take advantage of open-source software; it’s also a matter of understanding, handling and managing all the open-source software coming in.

“Just because open source is easy to grab off the Internet and it is so easy to integrate into your product, it is no excuse for not making sure it is secure,” said Dave McLoughlin, director of open-source auditing at Rogue Wave Software.

What to consider
Open source has become more popular over the past few years because of its ability to get organizations to market faster. According to Mahshad Koohgoli, CEO of Protecode, it is hard to survive in today’s software development world without the use of open source.

“Each software would not be possible without open source, without code reuse,” he said. “No organization can possibly create these highly functional, complex software on their own. Open source is the only way.”

But just because people use the term free and open source doesn’t necessarily mean that the software is free. “The ‘free’ in ‘free and open-source software’ refers to the free software movement, from which open source has sprung,” said the Open Source Initiative’s (OSI) board of directors. “ ‘Free’ here means ‘freedom,’ not price. Think of it as ‘the freedom to…’ or ‘liberty.’ ”

(Related: Why open-source software will eat the world)

The freedoms of free and open-source software include the ability to run the program; the ability to read, study and modify the code; the ability to make and redistribute copies; and the ability to distribute copies of modified versions, according to the OSI.

But the freedoms and benefits that open source enables, such as a lower total cost of ownership, higher quality and faster innovation, can also pose a risk to your company.

“Open source can be a veritable candy store of resources for developers, and also provide time and resource-saving shortcuts for organizations integrating and developing code. But it’s not a panacea,” said Bill Weinberg, senior director of open-source strategy at Black Duck.

For instance, if an organization doesn’t comply with the license associated with a particular chunk of open-source code, it risks being sued. If it doesn’t check the code it is using, it could potentially damage its services and systems. And if the organization doesn’t don’t know where the code came from in the first place, then it may not be aware of any incompatibility issues or any obligations that the license requires.

These risks can cause organizations to shy away from using open-source software, but if they know what they are dealing with, open-source doesn’t have to be an intimidating space. According Rogue Wave’s McLoughlin, there are three areas that organizations sometime forget to consider: compliance, security and support.

Open-source software comes with licenses that users are expected to comply with. If an organization doesn’t comply, then it can open itself up to legal liability, according to McLoughlin. Also, there are certain types of licenses that may back users into a corner, such as the GNU license that in some instances requires users to release their modified work under it and provide the source code.

But the point of a license isn’t necessarily to threaten an organization into compliance, according to Black Duck’s Weinberg. Open-source licenses are meant to protect someone’s unique property rights, and also guarantee the free and unencumbered distribution of the source code. “The originators of free and open-source software were trying to ensure that their works would be available to other users and communities and downstream inheritors without the code being sucked up by a proprietary interest and never being made available,” he said.

Proprietary licenses, for example, can limit a user’s permission to use the software, and they can sometimes contractually take away the rights users would have under copyright law, according to the OSI’s board of directors.

As the open-source community saw with major events like Heartbleed, open-source code can open your software to security vulnerabilities. Being aware of the security aspects are essential, and organizations need to be aware of any known security issues, according to McLoughlin. “Hopefully you are doing some type of static code analysis, some type of analysis of your code so that you understand if it opens you up to any security vulnerabilities, and then you have to track that code on an ongoing basis as new vulnerabilities are found in the future,” he said.

And then there is the question of support. Normally when you purchase a commercial product, the organization you buy it from provides some level of support, or you can purchase a support contract, according to McLoughlin. With open source, the question is where that support will come from. Organizations need to look at open-source code and understand whether or not they are going to be responsible for managing, fixing and supporting it internally; if they should outsource support to a third-party; or if the author of the code will be updating the code.

Open-source policies
Developers who scour the Internet looking for open-source software shouldn’t have to consider things like security, support and compliance every time they want to look for a piece of code. Organizations should have open-source policies in place that answer those questions.

“An open-source policy captures the considerations around adoption of open-source software (OSS) in an organization. The policy ensures that the benefits of OSS are maximized, while OSS adoption risks at legal, operational and business levels are managed,” said Protecode’s Koohgoli.

Each open-source policy should be tailored to an organization’s culture and objectives, but there are some key factors they should consider incorporating.

“The key is not to approach compliance with the aim of ‘What can I get away with,’ but rather ‘How can I meet the expectations of the developers who gave me this software,’ ” said the OSI board of directors.

According to Black Duck’s Weinberg, open-source policies should include what licenses are permitted or blacklisted, the context of how a license is used (for instance GPL is okay for Linux kernel code, but not applications), who is going to take ownership of particular OSS components, and under which licenses will the company publish its own open-source code.

In addition, Rogue Wave’s McLoughlin said that policies should talk about how the organization is going to acquire open-source software, how the code is going to be tracked, how the organization is going to support open-source software and the community, and how the open-source software is going to be checked for compliance.

After building a policy, organizations also need to figure out how they are going to enforce it. According to Koohgoli, an open-source review board is often put in place who is responsible for getting input from the software life-cycle teams, making sure software satisfies the license requirements before it is released, and educating their developers on the policies.

Linux’s self-assessment open-source compliance checklist
Linux’s Zemlin recommended organizations take a self-assessment checklist to understand whether or not they are in compliance. “We recommend that there be a set of processes for reviewing the code you’re using, making sure you understand what all of it is and what requirements for each of the different components are, and then being able to make the process of complying very simple,” he said.

According to Linux, the checklist should include:

  • Discover and disclosure: identifying open-source licenses
  • Review and approval: evaluating how the open-source software will be used and distributed
  • Obligation satisfaction: complying to the open-source license requirements
  • Community contributions: how the organization is going to review and approval contributions internally and externally
  • Policy: encouraging the use of open-source software and protecting business needs
  • Adequate compliance staffing: having the appropriate skills and resources necessary to comply
  • Adaption of business processes: how open-source compliance is going to fit into other business practices
  • Training: the company has been trained and understands how to comply
  • Compliance-process management: establishing, maintaining and enhancing an open-source compliance policy
  • OSS inventory/recordkeeping: tracking open-source content and compliance
  • Automation/tool support: how tools are going to help the organization comply
  • Verification: assuring that the company and employees are able to adequately meet OSS requirements
  • Process adherence audits: determining if the organization is on the right track with its compliance program.

According to Zemlin, it really isn’t any harder to comply with open-source licenses than it is to comply with a proprietary license. “We think with just a little bit of training, organizations will be confident to use open-source software and will get the benefit of billions of dollars worth of software and innovation that comes with it,” he said.

But according to Black Duck’s Weinberg, compliance would be easy if it was just one piece of code and one license. “We know organizations that are using thousands upon thousands of open-source software components, and in that case compliance and governance can be quite complex,” he said.

Weinberg added that the terms found in licenses can be confusing, and even if an organization thinks it understands the terms, its lawyers might have a different opinion or disposition, so compliance shouldn’t be left to any one part of the company. He recommended organizations adopt a cross-disciplinary purview and an open-source licensing board made up of engineering management, legal management and upper management.

Types of open-source licenses
There are thousands and thousands of open-source licenses. The Open Source Initiative recognizes approximately 60 of them, but that leaves about 2,000 self-styled and completely original open-source licenses, according to Black Duck’s Weinberg.

These licenses can fall into two basic categories: permissive and restrictive.

Permissive licenses are ones that require minimal obligations from a company, such as attribution requirements, according to Protecode’s Koohgoli. “For instance, all you have to do is make sure your product that uses the open-source code is shipped with a notice that says [the] product uses this open-source software,” he said. “The attribution comes in different forms, and they have to maintain the code or include the original lines of attribution on the top their software.”

Then there are restrictive licenses, typically called “copyleft” licenses, which generally allow you to use software for any purpose (but with various types of restrictiveness). The idea of restrictive licenses is to put a set of terms that restrict how the open-source code is distributed so that users can’t put it under any set of terms they want, according to Rogue Wave’s McLoughlin. “Some licenses very specifically say you can use this code, it is free, you can modify it, you can use it any way you want, you can put it in a commercial product, etc. But you can’t change the license, and any work that you create with this product, diverted work, any modifications that you made to it, have to be under this original license,” he said. The idea is to keep open-source software open source so that it isn’t closed-sourced by a commercial vendor in the future, he explained.

The most common licenses include the GNU General Public License, MIT License, and Apache License.

Some of the less common (but more interesting) licenses include Beerware—which allows a user to use the software how they like, but if they ever come across the author they are recommended to buy them a beer; Do What the F*** you want Public License (WTFPL)—which means basically what it says; and the VoidSpace license—which states the author is not responsible for damages that may occur.

The Software Package Data Exchange
The Linux Foundation created the Software Package Data Exchange (SPDX) specification to provide a bill of materials about license information and components included in open-source code.

“Our philosophy here is we want to make the sharing of software not only in the development process, but in the consumption and redistribution of that software as simple and plain as possible,” said Linux’s Zemlin.

The SPDX was designed to provide organizations a way to see how open-source software relates to other open-source code, what versions of software were used in open-source code, the license and version of that license the software belongs to, and if there are any vulnerabilities that need to be addressed. Zemlin said the specification is still in a mid-adoption phase, but as more open-source software is used throughout almost every aspect of IT, it will become the standard way for sharing open-source data.

“SPDX has great potential to act as a common interchange format for licensing information on open-source software,” said the OSI board of directors. “It is still a work in progress, with the latest version of the specification just released [in May].”

The SPDX specification process operates similar to an open-source community. Developers, distributors and providers can contribute SPDX files for their open-source projects.

Tools to help you comply
When given a choice to code or worry about compliance, developers will choose to code, according to Black Duck’s Weinberg. Having to manually ensure compliance can be a daunting task and potentially take several hours every week. Tools can help automate the process of compliance, but it’s important to keep in mind that they can’t guarantee compliance.

“Tools themselves cannot ensure compliance, but they can aid organizations in understanding how they are using open source (and other software), and what the organizations need to do to remain in compliance with open-source licenses,” said the OSI board of directors.

A good set of scanning tools is important to help organizations understand exactly how much open-source code they are using in their product and if the code contains any licenses that are incompatible with one another. “If you have an organization that 100% tracks everything that comes into their organization, they still miss open source and open-source licenses because fundamentally open source uses open source,” said Rogue Wave’s McLoughlin.

Scanning tools can also help users understand what version the code is at and what license is enforced for that code so that they can tie it into their policies and products for compliance, according to Weinberg.

Then, you need some way to track the open-source code, according to McLoughlin. Tools can provide inventory tracking of open source to manage the approval process. “If you are letting your developers just bring open source into your products, and you are not tracking them, then you are not putting a process in place that lets you know if there are known vulnerabilities that could affect you from the beginning,” he said.

In addition, static code analysis tools can help find bugs and ensure code quality.

Lastly, the Linux Foundation recommends a linguistic review tool that can look for any comments about the source code or future products.

“Even if you are not that concerned about your own code, you should be concerned about any code that you acquire,” said McLoughlin. “There is practically no software company that’s acquired technology that doesn’t want to know and have a comprehensive list of open source and licenses in the technology that they are acquiring.”

A breakdown of the typical software portfolio
Protecode recently released an infographic highlighting the importance of understanding the open-source content in a code portfolio. According to Koohgoli, many organizations worry about accidentally including copyleft licenses in their code—for instance the GNU Public License (GPL).

“Inclusion of GPL code in a company portfolio can force the company to open their entire codebase to the public, which could be commercially undesirable,” he said.

According to the infographic, which was made up of consolidated findings from an audit of more than a million software files belonging to more than a hundred technology companies, GPL code exists in almost all the portfolios.

The infographic also stressed the importance of providing header information in proprietary files, which a majority of small portfolios don’t include.

“Many organizations do not include their own copyright information on their software, making the task of determining [their] own IP against third-party and OSS content more difficult,” Koohgoli said.

In addition, Protecode found that open-source software containing security vulnerabilities were found in most portfolios.