The following post was originally published here by Black Duck Software…

The term compliance is used more and more in business. Some job titles even include the term: VP of Compliance, Compliance Officer, Compliance Manager. Usually these roles have focused on the legal and operational requirements imposed by external groups like licensors and regulatory agencies.

While abiding by such external requirements is the cost of you doing business, you give up control of your business or product development by only following the requirements of others and not establishing your own policies and complying with them.

Limited Scope

Let’s look at how the term “compliance” has been used to limit the scope of open source governance…

Open source compliance has been narrowly interpreted to mean that one must abide by the open source author’s license terms. Indeed, that will always be a requirement, but consider that an open source author’s work is replacing the work of one of your own software engineers.

If the only hurdle to cross before using open source is to be compliant with the author’s license terms, that is like saying you fully trust all the code developed by one of your software engineers if and only if your management meets its legal requirements during the hiring and employment of that engineer!

A Question of Trust?

While that seems preposterous, in practice, you probably impose many more requirements on the work product of your own engineers than on the work product of open source authors. Is it your intention to trust open source authors more than your own employees? The assumptions you might be making are:

(a) every open source project is staffed by many more development, testing, and maintenance engineers than your company can deploy to solve the same problem, and

(b) those engineers know and have fixed all security vulnerabilities.

However, www.openhub.com shows that might be true for some open source projects, but not all. Therefore, unless your product teams perform the appropriate due diligence, they won’t know whether their assumptions are valid.

Open source management best practices require organizations to know the open source in their code in order to reduce risks, tighten policies, and monitor and audit for compliance and policy violations. Automating identification of all open source in use allows development and license teams to quickly gain visibility into any known open source security vulnerabilities as well as compliance issues, define and enforce open source use and risk policies, and continuously monitor for newly disclosed vulnerabilities.

David Znidarsic is the founder and president of Stairstep Consulting, where he provides intellectual property consultation services ranging from IP forensics, M&A diligence, information security management, open source usage management, and license management. Learn more about David and Stairstep Consulting at www.stairstepconsulting.com.