In my last post, I discussed where we came from and where we are now in regards to knowledge and understanding of open source software and licenses. I talked about how, not too long ago, there seemed to be a fair amount of denial when it came to the use of open source software in the enterprise.  Today, open source software has garnered enough attention that the term "open source" is found far outside the software world. Yet, misconceptions and misunderstandings prevail. Why? How did we get here? And how do we get to the point where there is accurate and consistent knowledge around FOSS? More specifically, how do we get to a point where FOSS use in the enterprise incorporates a thorough and appropriate understanding that backs a FOSS policy that is tailored to the realities and practicalities of that particular business?

At the Linux Foundation Collaboration Summit in San Francisco in mid-April, I gave a talk titled, "FOSS Knowledge: A little does NOT always go a long way." The title was supposed to be a bit eye-catching; the subject-matter, hopefully thought-provoking. I've attended my share of open source software-related events and often the topics covered in the legal or business tracks relate to trends, information, tools, and best practices for the use of open source software, particularly in regards to license compliance - basically what one needs to do. But I'm finding that it is ever-more critical to look at knowledge: the understanding, awareness, and education around open source software and licenses.

What is an open source software (OSS) bill of materials (BOM)? In the simplest terms, it is a list of the OSS components used in an application. But, it can actually be much more. Most OSS BOMs will, at a minimum, also contain the licensing information associated with each OSS component.

Open source audits are never as simple as they seem. You have successfully tackled your first open source audit and you are probably asking yourself what to do to help with future audits. The answer is: preparation.  The steps you take before you start the auditing process will make the project that much more successful. To help with future audits, let's look at a few tips and tricks you can use before you begin an audit:

As an open source auditor at Openlogic I have had my fair share of challenges when conducting a source code audit. Tackling your first few audits can seem cumbersome and intimidating; from identifying different open source package versions to being given incorrect information from developers. To help with these issues consider the following.