Software developers routinely use open-source components to boost productivity and improve the quality of their code. The problem for enterprises is that companies using open source must properly manage it and comply with its licensing, as with any third-party code.
That becomes difficult to do when corporate leaders do not know their computer systems are running open-source code. Even licensing compliance becomes an unwieldy threat when the coders themselves have a lackadaisical attitude toward copyrights and licensing requirements.
If you think your company’s computer system is insulated from open source because contracts you use or government compliance standards exclude it, think again. Open source is pervasive in both proprietary and open software. Good and bad code is found in both software models.
The question is not, “Does my company use it?” Instead, ask what you’re going to do to manage it and comply with license requirements.
“Many enterprises view open source as code that is free to copy. I think that open source has become so pervasive and so accepted that some of the safeguards — and some of them are pretty important — have just been discarded,” Matt Assay, vice president of corporate strategy and marketing at MongoDB, told LinuxInsider.
The software industry today has a thin line separating pure proprietary from pure open source. There is a vast gray area in between, where chunks of open-source code are embedded. Commercial software companies do not always divulge that code. Independent coders often freely borrow from open-source libraries without attaching licensing notifications.
One problem is that the GitHub generation does not seem to care as much about code vetting as did coders in earlier years. In the time span from 2007 to 2010, open source became very popular. Enterprises tried to manage it, according to MongoDB’s Assay.
“My sense is that developers do not really look at licenses anymore. They are not even looking at which license is applied and does it comply. I think these are issues that attorneys look at, though. I do not think the developers are thinking a lot about the licenses anymore,” he said.
This reaction to licensing compliance may have resulted in part from more permissive Apache-style licensing in the past few years. The industry used to be a bit too focused on all of the license controls. It may swung too much in the other direction with respect to open source code, Assay suggested.
This changing attitude toward open-source compliance and awareness has a clear impact on research and development for enterprises. It stems in part from a difference in developmental models, suggested Rick Howard, chief security officer of Palo Alto Networks.
“Commercial organizations do not open up their code base for review. The open-source model gives the impression that many eyes could review the code at any given time. It keeps everybody honest, in theory. In practice, some of these code bases are huge, and not many people — except those directly involved in the project — ever look at it,” he told LinuxInsider.
Open-source applications and open-source code in proprietary programs power enterprise operations. Thus, R&D has a major stake in managing open-source code, noted Barry Shteiman, director of security strategy at Imperva.
“Open source code is a huge part of what runs the software industry today. Most companies use open source in one way or another, either as libraries to cut development time — for example, not having to ‘solve’ a problem that has already been solved by others — or take advantage of the power of thousands of developers tinkering under the hood of their software,” he told LinuxInsider.
A Clean Sweep Affair
Managing open-source code in the enterprise takes a willingness and a process. Typically, one or both are easily swept under the corporate rug.
“I think most enterprises have all sorts of open-source code running through their programs. I think some are even embedded. I think either they don’t know about it, or they know about it but do not understand the ramifications of what the license may be doing or what the license may be requiring,” Assay said.
The Secret in the Sauce
It may not be uncommon for corporate officials to ignore open-source usage. One large financial enterprise used open source throughout its computer system even though it had an agreement with the software developer not to use open-source code.
“The big secret was that everyone there was using it. They were using open source with all sorts of varying licenses. No one was controlling it,” Assay said.
It’s not that every financial institution is overlooking open-source use in its software. It is more likely that it is just too hard to manage the literally billions of lines of code out there, he said.
The overriding issue is really one of comprehension. Managing the use of open source in the enterprise involves several distinct steps. There is a selection process. There is a scanning step. There is an approval process, noted Phil Granof, executive vice president and chief marketing officer for Black Duck Software.
“Open source has been in the process of defining itself for decades now. It has been defining its role in the enterprise more recently. It has been a long road in getting people to understand what that role is and how it can be better utilized,” he told LinuxInsider.
Perhaps the biggest part of the process is recognizing that managing open-source use and license compliance is a logistics issue. The industry is just beginning to understand the magnitude of the challenge and the reward. However, enterprises need help in achieving this, according to Granof.
“Open source presents a collision of quality and quantity. There is a huge assortment. Somehow, you want to bring it into your company. It is a logistics issue,” he said.
License Compliance Depends
Dealing with compliance and licensing issues depends on a couple of things. The factors include recognizing how open source adds to the value chain and how it is currently in that value chain, explained Granof.
The process also includes assessing the dichotomy between proprietary and open-source software, along with the old notion that never the two shall meet. How to deal with the answers depends on whether the company already has an open source policy in place, he said.
If there already is a policy in place, managing compliance generally is easier. Compliance has a sort of pre-filter. Without that kind of policy in place, compliance gets much tougher. Then, the solution requires automation and scanning of the software the company has installed, explained Granof.
“In general, whenever we do a scan, more than 99 percent of the time, we find open-source code. On average, about 90 percent of the time, companies are unaware they had it in there,” he said.
Then it comes down to what is the level of security risk and what is the level of operational risk. Also to be considered is what are the vulnerabilities associated with the found open-source coding.
“That is not really a manual effort. That has to be done in an automated way. There are just too many lines of code,” said Granof.
Managing open-source code and complying with its licensing are essential. Embedding vulnerable third-party components, whether open source or commercial, is a common security challenge for technology companies, according to Marc Maiffret, chief technology officer of BeyondTrust.
“This is because most companies do not have a good process around how they handle third-party code that gets included in their products. This third-party code can, of course, have vulnerabilities, and a proper process needs to be in place to continue to keep that shared code up to date for any security fixes,” he told LinuxInsider.
Open source code is not inherently a bad thing. There is no cause for greater concern over the security of open versus closed source, Maiffret noted. Rather, the concern should focus on the proper auditing and security of code in general.
“People tend to think of this as an open source problem because it is more common for people to use third-party open source code within their product. But there are plenty of insecure third-party closed source components that companies will leverage and equally do a bad job at keeping them up to date,” said Maiffret.
Poorly trained developers write both closed and open-source code. Enterprises need to look at each product or component on its own, he cautioned.
“There is just as much bad commercial code being written as open source and vice versa,” Maiffret said.
Open source has become shorthand for free and good quality software, noted MongoDB’s Assay. So, users are not thinking about licenses, risks, or obligations to the community.
The looseness involving the widespread use of open source and lack of attention to licensing requirements is ingrained into software coders today. They grew out of an age when coders have been trained in a world of open source, according to Black Duck’s Granof.
“When you bring in coders to your company, you want the brightest and the best. They are going to be using open source. That is where the brightest and the best are right now,” he maintained.
The Inevitable Option
For enterprises, it is not a matter of deciding when or if they should adopt open source. It is a matter of whether you already have it, suggested Granof.
Is it merely a matter of how fast you want to be able to understand what is in your software and prepare for things like Heartbleed? Or simply be hygienic and compliant as an organization as the licenses demand?
“It is that pervasive in enterprise,” Granof said.
Control or Fail
Enterprises need to recognize that open source poses a conundrum over access to the best software at a business-advantageous price, said Assay.
“So they have to make a choice. Do I innovate and use open source in a less controlled fashion?” he wondered. “Or do I try to heavily control it and risk being left behind and have my company or firm not compete as well?”