Open source software compliance: Developing a risk matrix

on Jul 6, 12 • by admin • with No Comments

In this article I will be discussing how you can use those factors to develop a risk matrix to assist you in assessing your overall risk...

Home » Open Source » Open source software compliance: Developing a risk matrix

In my last article, Open Source Software Compliance: How Well Are You Rating Risk?, we took a look at the key factors in determining risk associated with the use of Open Source Software (OSS). In this article I will be discussing how you can use those factors to develop a risk matrix to assist you in assessing your overall risk.

The key factors I covered in my last blog included were divided into two key areas; Product and Legal.


•  Product maturity
•  Product security
•  Product infrastructure and community
•  Support
•  Product type
•  Acquisition

Legal and compliance

•  License
•  Usage
•  Legal risk

When developing a matrix you will need to take into consideration how important each of these areas and separate factors are to your organization. For example, in organizations that are more legal-driven, issues like compliance and usage may represent a higher risk factor while engineering-driven organizations may be more concerned with development factors like product maturity, security and support.

Once you have decided which area is more important to your organization for assessing risk, then consider assigning a “weighting” to each factor, giving the higher risk factors a higher number and lower factors a lower number.

For each factor develop a set of categories to break the factor into manageable chunks. For example, create list of licenses by categories, such as “copyleft”, permissive, freeware, etc. For products, create categories by maturity (e.g5 years), etc.

Next you will want to assign specific risk values to the various categories in each factor. For example, in the License category “copyleft” licenses like the GPL and LGPL licenses may have a higher number, while permissive licenses like the BSD and MIT licenses may have a low number.

After you have created your “weighting” number by area, risk values by categories within each factor, then you will be able to combine the values to create an overall risk rating by product.

Finally, consider how this risk rating factors into your overall OSS policy with regards to usage. Does high risk mean that products are banned from use in your development, or does a high risk rating mean that you need to implement a more rigorous process for tracking usage, alerting management to the risk and ensuring compliance?

When you consider the overall direct costs savings of OSS in regards to licensing fees, the costs of managing the OSS may be more or less of a burden for your organization. OpenLogic specializes in helping you be more effective and efficient in managing, assessing risk, setting up policies and much more. We would be glad to help you sort out these issues and help your organization safely take advantage of OSS to save you money, and provide a platform for more innovation and faster time to market.

As always, I look forward to your comments. Are you assessing risk and managing the use of OSS in your organization? Are they any key factors I missed in my article? Let me know.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top