News Stay informed about the latest enterprise technology news and product updates.

Open source software requires governance, Burton warns

Harried developers are making use of open source components for SOA and proprietary applications, but management doesn't even know it is there, a Burton Group analyst warns.

Open source software (OSS) frequently flies under the radar in IT organizations, and if governance is not in place...

to identify it and manage legal licensing implications, it may crash and burn, Burton Group Inc. warns.

Uncontrolled use of software components can affect IT operations as well as development.
Joe Niski
Senior Analyst for Application Platform StrategiesBurton Group

Developers working on SOA and other software projects are making use of OSS components, and IT, QA and legal departments are ignoring the licensing ramifications at their peril, according to a new Burton report.

The growing popularity of the Java Development Kit from Sun Microsystems Inc., and the Eclipse IDE are resulting in a proliferation of OSS components in applications that organizations consider proprietary, according to the report's author, Joe Niski, senior analyst for application platform strategies for Burton. Legal problems arise because, while open source licenses are more liberal than traditional vendor licenses, they are still licenses. Terms and conditions that must be observed, the analyst explains in a 27-page report, "Open Source Management: Who Owns That Software?"

Unaware that there are open source Web services and other components in their applications, an organization may believe that its software is its sole property, only to find itself facing legal challenges because it includes OSS, Niski warns. The problem is OSS frequently slips into IT unnoticed.

"For example," Niski writes in his report, "many Java Platform, Enterprise Edition (Java EE) application servers incorporate lower-level components released by the Apache Software Foundation. Specialized distributions of the Linux operating system are embedded in all kinds of network and telecommunications devices. In other words, many enterprises that have not deliberately adopted or even considered OSS have likely purchased it, quietly bundled into commercial products, for essential pieces of their IT infrastructure."

A second way that OSS flies in under the radar is when in-house developers or business partners develop customer software, which Niski says is "likely use a number of open source components and tools."

Whatever way OSS gets into your organization, ignorance is not bliss, the Burton analyst warns. It can result in both legal problems and IT infrastructure chaos.

"The risks of violating open source software (OSS) licenses or becoming embroiled in an intellectual property (IP) dispute increase with the use of OSS," Niski writes. His report cites cases including one in 2002 where Progress Software Inc. was accused of General Public License (GPL) violations that cost the company "$10 million in lost development and marketing work."

More recently, in the fourth quarter of 2007, a number of companies including Verizon Communications Inc. were sued for violating the GPL related to BusyBox components included in their products, Niski notes.

The other problem with stealth OSS is one that will be familiar to most IT managers seeking to govern SOA.

"Uncontrolled use of software components can affect IT operations as well as development," Niski writes. "The more components with overlapping functionality an enterprise uses, the greater the risk of conflicts and incompatibilities. This is especially the case in Java EE when multiple applications must share an application server, and when the application server itself incorporates OSS components. Conflicts arise from using multiple components for a single purpose or from using multiple versions of the same component within a single runtime context."

For example, Niski writes that there can be problems in a Java EE application using multiple XML parsers or SOAP messaging libraries on the runtime classpath.

"If an application server employs a different version of libraries that are also bundled into applications deployed to that server—or different implementations of public interfaces than an application was built with—unexpected, hard-to-diagnose errors can occur," the Burton analyst warns.

These legal and QA problems are not unique to SOA, Niski said.

"I don't think there are any licensing or intellectual property concerns with open source that are unique to SOA environments," he said. "The usual challenges that I discuss in our report apply: understanding license implications, governing component usage, indemnification and support."

For more information
Open source software seeks SOA interoperability

Best practices of the SOA development lifecycle

His recommendations include establishing a governance program that makes use of open source management (OSM) tools that help check new and existing applications for OSS components. The tools, which should be incorporated into the software development lifecycle (SDLC), according to Niski, help organizations identify OSS components and understand the implications of their licenses.

The Burton report specifically covers tools from three companies, Black Duck Software Inc., Palamida Inc. and OpenLogic Inc. It notes that the tools have overlapping capabilities and based on the needs of the organization one or more of them may be needed.

Summarizing the basic strengths of the tools, the Burton report notes:

  • Black Duck offers the broadest support for legal and compliance issues;
  • Palamida enables managing OSS from a security and vulnerability perspective; in addition to governance;
  • OpenLogic provides certification, support, and indemnification services for the OSS packages that its tools manage.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.