Public Company Accounting Reform and Investor Protection Act

Compliance Journal

Subscribe to Compliance Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Compliance Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Compliance Journal Authors: Elizabeth White, Don MacVittie, Fouad Khalil, Jason Bloomberg, Pat Romanski

Related Topics: Ubuntu Linux Journal, Compliance Journal, OpenAjax Alliance News, Open Web Magazine, Open Source Journal, Open Cloud Collaboration, Open Source for Small Business

Article

Open Source Compliance: Getting Started Guide

What are the challenges faced when establishing a compliance program? What best practices exist?

Open Source Review Board

The Open Source Review Board (OSRB) is comprised of representatives from Engineering,  Legal and Open Source experts. The OSRB reviews requests for use, modification and distribution of Open Source software and determines approval. In addition, the OSRB serves as steering committee to define and manage your company's Open Source strategy.

Open Source Compliance Policy

The compliance policy typically covers usage, auditing and post-compliance activities such as meeting license obligations and distribution of Open Source software. Typical items that are mandated in a compliance policy include approval of OSRB for each Open Source software included in a product, ensuring that license obligations are fulfilled prior to customer receipt, mandatory source code audits, mandatory Legal review and the process and mechanics of distribution.

Open Source Compliance Process

The Open Source compliance process is the work flow through which a request to use an Open Source component goes through before receiving approval. Typically, it includes scanning code, identifying and resolving any flagged issues, Legal review and final decision.  As an example of  a  compliance process, you can review an article from HP entitled “FOSS Management Issues” available from www.fossbazaar.org/content/foss-management-issues.

Compliance Project Management Tool

Having a tool to manage your compliance project is a great plus. Some companies use their bug tracking tools that are already in place, other companies rely on professional project management tools. Whatever your preference is, you would want the tool to reflect the work flow of your compliance process, allowing you to move compliance tickets from one phase of the process to another, providing you with task and resources management, time tracking, email notifications, project statistic and reporting.

Open Source Inventory Management

It is critical to know for each product what Open Source software is included, version numbers, licensing information, compliance information, etc. Basically, you need to have a good inventory of all your Open Source assets, a central repository for Open Source software that has been approved for deployment. This inventory will come very handy for use by Engineering, Legal and OSRB.

Open Source Training

The goal of providing Open Source training to your employees is to ensure that they have a good  understanding of your company's Open Source policies, compliance practices, in addition to understanding some of the most common Open Source licenses. Some companies go one step further by mandating their engineers working with Open Source software to take the Open Source training and pass the evaluation.

Open Source Portals

Usually companies maintain two Open Source portals:

  • An internal portal that houses the Open Source policies, guidelines, documents, training, and hosts a forum for discussions, announcements, sharing experiences, and more, and
  • An external portal that is their window to the world and the Open Source community and a place to post all the source code of Open Source packages they use, in fulfillment of their license obligations with respect to distribution.

3rd Party Software Due Diligence

In is highly recommended that you also examine software supplied to you by third parties. If third party software includes Open Source software, you need to ensure that license obligations are satisfied since this is your responsibility as distributor of a product that includes Open Source software. You cannot just point at the supplier and tell the Open Source community that it is the responsibility of the supplier to meet their obligations.  Therefore, you must know what goes into all of the product’s software, including software provided by outside suppliers.

Who's Involved in Open Source Compliance?

Several departments are involved in ensuring Open Source compliance. This section presents a generic break down of the different departments and their roles in achieving Open Source compliance.

Teams involved in open source compliance

Legal

  • Advise on licensing conflicts
  • Participate in the OSRB reviews
  • Review and approve content of Open Source external portal

Engineering and Product Team

  • Submit OSRB requests to use Open Source software
  • Participate in the OSRB reviews
  • Respond promptly to questions asked by compliance team
  • Maintain a change log for all Open Source software that will be made publicly available
  • Prepare source code packages for distribution on the company's Open Source public portal
  • Integrate auditing and compliance as part of the software development process checkpoints
  • Take available Open Source training

Open Source Review Board

The OSRB team drives and coordinates all Open Source activities. Below we focus only on the compliance related activities.

  • Drive the Open Source compliance process
  • Perform due diligence on suppliers’ use of Open Source
  • Perform code inspections to assure inclusion of Open Source copyright notices, change logs, and the like in source code comments
  • Perform design reviews with Engineering
  • Compile list of obligations for all Open Source software used in the product and pass it to appropriate departments for fulfillment
  • Verify fulfillment of obligations
  • Offer Open Source training to engineers
  • Create content for the internal and external Open Source portals
  • Handle compliance inquiries

Documentation Team

  • Produce Open Source license file and notices that will be placed in the product

Supply Chain

  • Mandate 3rd party software providers to disclose Open Source software in what being delivered.

IT

  • Support and maintain compliance infrastructure: servers, tools, mailing lists and portals.
  • Develop tools that help with compliance activities such as linkage analysis.

Establishing Compliance Best Practices

This section presents on compliance best practices that fall under six major categories. Each of the categories represents a step in a typical compliance process.

  1. Scanning the source code,
  2. Identifying and resolving issues,
  3. Performing architecture review,
  4. Performing linkage analysis,
  5. Performing legal review, and
  6. Making the final decision.

Sample Compliance Process

Scanning Code

The first step in the compliance process is usually scanning the source code, also sometimes called auditing the source code.  Below are some common practices in this area:

  • Scan everything: Proprietary code, 3rd party software and even Open Source software since your team might have introduced modifications triggering the need for additional due diligence and additional obligations to fulfill.
  • Scan early and often: It is advisable to scan as early in the development process and as often as possible to identify new packages entering your build.
  • Scan newer versions of previously approved packages. In the event that a previously approved packaged was modified, it is recommended to rescan it to ensure that any code added to it does not have a conflicting license and to ensure that there are no additional obligations to meet.

Source Code Scanning Tools

There are several commercial and Open Source tools that offer the capabilities of scanning source code for potential open source issues.

Identification and Resolution of Flagged Issues

After scanning the source code, the scanning tool generates a report that includes a “Build of Material”, an inventory of all the files in the source code package and their discovered licenses, in addition to flagging any possible licensing issues found while pinpointing the offending code. What happens next?

  • Inspect and resolve each file or snippet flagged by the scanning tool.
  • Identify if your engineers made any code modifications. Ideally, you shouldn't rely on engineers to remember if they made code changes. You should rely on your build tools to be able to identify code changes, who made them and when.
  • When in doubt with the scan results, discuss with Engineering.
  • If a GPL (or other) violation is found, you should report to Engineering and request correction. It is highly recommended that you re-scan the code after resolving the violation to ensure compliance.
  • In preparation of Legal review, it is recommended to attach to the compliance ticket all licensing information (COPYING, README, LICENSE files, etc.) related to the Open Source software in question.

Architecture Review

The architecture review is an analysis of the interaction between the Open Source code and your proprietary code. Typically the architecture review is performed by examining an architectural diagram that identifies:

  • Components that are Open Source (used “as is” or modified)
  • Components that are proprietary,
  • Components dependencies,
  • Communication protocols,
  • Linkages (dynamic and static),
  • Components that live in kernel space vs. user space
  • Shared header files

The result of the architecture review is an analysis of the licensing obligations that may extend from the Open Source components to the proprietary components.

Linkage Analysis

The purpose of the linkage analysis is to find potentially problematic code combinations at the dynamic link level, such as dynamically linking a GPL library to proprietary source code component. The common practices in this area include:

  • Performing dynamic linkage analysis for each package in the build.
  • If a linkage conflict was identified, report to it Engineering to resolve.
  • Re-do the linkage analysis on the updated source code to verify that the code changes introduced by Engineering resolved the linkage issue.

As for static linkages, usually companies have policies that govern the use of static linkages since it combines proprietary work with Open Source libraries into one binary. These linkages cases are discussed and resolved on a case-by-case basis.

Legal Review

The best practices of the legal review include:

  • Review the report generated by the scanning tool attached to the compliance ticket
  • Review the license information provided in the compliance ticket
  • Review comments left in the compliance ticket by engineers and members of the OSRB
  • Flag any licensing conflict and re-assign compliance ticket to Engineering to rework code if needed
  • Contact the Open Source project when licensing information is not clear, not available, or the code is licensed under more than one license with unclear terms/conditions
  • Decide on incoming and outgoing license(s)

Final Review

The final review is usually an OSRB face-to-face meeting during which Open Source software packages are approved or denied usage. A good practice is to record the minutes of the meeting and the summary of the discussions leading to the decisions of approval or denial. This information can become very useful when you receive compliance inquiries. For approved Open Source packages, the OSRB would then compile the list of obligations and pass it to appropriate departments for fulfillment.

Responding to Compliance Inquiries

This section presents guidelines to observe when dealing with compliance inquires. These guidelines aim to maintain a positive and collaborative attitude with the requester of compliance information while investigating the allegation and ensuring proper handling in case of license violation.

Responding to compliance inquiries

Do not ignore Open Source compliance inquiries

Several companies received negative publicity and/or got sued because they either ignored requests to provide Open Source compliance information, did not know how to handle compliance inquires, lacked or had a poor compliance program, or simply refused to cooperate thinking it is not enforceable. By now, we know that none of these approaches is fruitful and beneficial to any of the parties involved. Therefore, as a general rule, companies should not ignore Open Source compliance inquiries. Instead, they should acknowledge the receipt of the inquiry, inform the reported that they will be looking into it and provide a certain date on when to expect a follow up.

Understand the reporter and the inquiry

It is recommended to understand who is the reporter, their motivation and verify if their accusation is accurate or even current. Furthermore, not every reporter understands licenses fully and sometimes there may be mistakes in their submissions. Therefore, you need to make sure that you fully understand the inquiry and that you have all the necessary information to isolate the problem and investigate it internally. If that's not the case, you can ask the reporter to be specific and provide you with the details you are missing to start your investigation.

Work collaboratively with the reporter

It is recommended to keep an open a dialog with the reporter. As a company that maintains rigid compliance practices, highlighting your Open Source compliance program and practices shows good faith efforts toward compliance. It is also advisable to send updates of your internal investigation when they are available.

Investigate and report results to reporter

After concluding the internal investigation (within an acceptable time limit) through the review of the  compliance due diligence completed for the specific software component (or product) in question, you need to inform the reporter with the results.

If a violation was found:

If indeed there is a license violation as reported, it is your responsibility to resolve the issue with the reporter, while being collaborative and showing good will. You need to understand the obligations under the applicable license and show how you will meet the obligations and how soon.

Conclusion

This article provided an overview of Open Source compliance, the challenges faced when establishing a compliance program, industry practices and recommendations on how to deal with compliance inquiries. Open Source compliance is an essential part of the development process. It is recommended to start with a simple, lightweight compliance process and  practices, learn and adjust as you proceed. You can look at common practices for inspiration but it is most likely that you will make adjustments to fit your specific company's needs. If you use Open Source software in your product(s) and you don't have a solid Open Source compliance program, then you should consider this article as a call to action.

Smart companies have strong Open Source compliance programs.

References

More Stories By Ibrahim Haddad

Ibrahim Haddad is a member of the management team at The Linux Foundation responsible for technical, legal and compliance projects and initiatives. Prior to that, he ran the Open Source Office at Palm, the Open Source Technology Group at Motorola, and Global Telecommunications Initiatives at The Open Source Development Labs. Ibrahim started his career as a member of the research team at Ericsson Research focusing on advanced research for system architecture of 3G wireless IP networks and on the adoption of open source software in telecom. Ibrahim graduated from Concordia University (Montréal, Canada) with a Ph.D. in Computer Science. He is a Contributing Editor to the Linux Journal. Ibrahim is fluent in Arabic, English and French. He can be reached via http://www.IbrahimHaddad.com.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
kweins 01/14/10 03:22:36 PM EST

There is another free open source scanning tool (OSS Discovery by OpenLogic) that you can use to identify open source in your products or applications. You can download at www.openlogic.com.