On September 25, 2007 Dana Blankenhorn wrote a blog in which he examined whether or not code audits are necessary. The inferences made throughout the blog invited a thoughtful and serious response.

Dana states, "With the FUD train having left the Linux OS station, vendors are now focusing on Linux applications, warning that careful, expensive auditing and licensing is necessary before you deploy anything."

In this statement, does "deploy" mean using an application internally, or does it mean selling a final software product that may include code taken from sources with disparate licensing terms? It's important to differentiate. There are three basic use types for open source software during which the governance imposed by licensing kicks in: Use, modification and distribution.

Dana also states, "Vendors like Palamida are always happy to turn your worries about code licenses into their profits, through expensive audits which identify just who wrote what and what the deal is. But to what extent are the concerns real?"

The first inaccuracy in this comment is that Palamida's technology does much more for organizations than point out who wrote the open source code. It would also be interesting to know what the contextual basis is for saying that auditing is "expensive"? Expensive as opposed to...

A code audit has a wide cost range depending on the size of the code base, projects, timeline for completion, etc. Comparative factors for organizations that choose to perform audits include: the cost of litigation, loss of IP, and rework of vulnerabilities or unlicensed code that prevents software from making the time-to-market deadline. Taking these into account, most organizations find that the cost of an audit or implementing an ongoing process is preferable to the losses they would otherwise incur.

Palamida offers valuable services to customers by helping them audit and manage their use of open source software and understand liabilities and restrictions for use, distribution and modification, which may exist within such code.

Consider a Fortune 1000 enterprise. Their software products bring in revenue to the organization that would greatly exceed the cost of an audit many times over. Not being able to ship that product at all, having to rework it, or discard card it if a rework cannot be found, would be a substantial loss to the company. For customers who want to circumvent issues related to the development process, an audit is a critical necessity, not an "expensive" folly.

An issue that the blog did not address is the identification of open source vulnerabilities -- an important part of what Palamida's technology provides. Clearly, the first step is to identify what you have in your code base to start with. If you didn't know that you had zlib , you wouldn't know if it contained a remotely exploitable vulnerability (and we are using zlib merely as an example here).

Granted, open source issues get patched very quickly by their excellent project communities, but if you didn't know you had a specific piece of open source, you wouldn't know it was vulnerable, therefore, you wouldn't look for a patch in the first place. In addition, you may know that you have specific open source components in your code base, but you may not have been aware of any associated vulnerabilities.

Financial, government and healthcare institutions along with companies interested in protecting their software assets are all types of organizations that use and develop software, both for internal and external use. Regardless of whether ot not the software is for sale, it should not contain security issues.

Open source is not less secure than commercial software, it is as secure, however you wish to interpret that. According to our research, it gets patched much faster, but it does not come with auto-update mechanisms or email alerts for its users. Unless you're searching for patches, you aren't fixing the holes. If you are wondering if there really are holes, or if possibly this is another FUD conspiracy, you can visit the National Vulnerability Database and scan through the hundreds of CVEs. Palamida's technology automatically identifies vulnerable code and tells organizations where, down to the exact paragraph, that code resides and what the precise vulnerability is. From there, it can be remediated.

The blog infers that open source licensing management isn't real (that it's all FUD) or even necessary, and that is somewhat like saying that an organization shouldn't worry about Sarbox compliance until the government comes "knockin". Developers do not have to comply with Sarbox individually, but their companies do. Their CIOs, lawyers, Engineering Managers, CEOs, VPs, etc., are all held accountable for regulations and for what goes into the code base. It stands to reason that they would require a full inventory of code base components.

The concerns are also real to the extent that software companies create or modify open source software products to be distributed or sold and that are based on or use code from other open source software products. Since this is the heart of the open source development model, the extent of the concerns is potentially large.

Finally, the question of whether an organization should audit or not should revolve around the unique risk profile of the organization itself. If you're one person and you are doing wholly original work, then you wouldn't need a professional audit. If, however, you have a large development team whose members contribute independently to your final product or who are geographically distributed, outsourced or who contribute continually before and after each engineering build without real-time administrative review, you need an audit. The burden of responsibility falls upon the user of open source to accept and comply with the terms of its license. Therefore, the user needs to manage the scope of use, the type of use, and overall compliance to the terms of use within the license.

Who needs to audit their use of open source software, and who needs to verify compliance with associated licenses? Anyone who intentionally or inadvertently uses open source and third party components. Failing to adhere to the license terms and/or remediate open source vulnerabilities does a lot more toward harming the future acceptance and viability of open source than ensuring that it is being utilized in a safe, responsible manner.

--Ernest Park
--Kevin Howard, Legal Research Associate