Establishing Compliance Best Practices

The following compliance best practices fall under six major categories. Each of the categories represents a step in a typical compliance process.


1. Scanning Code. The first step in the compliance process is usually scanning the source code, also sometimes called auditing the source code. Some common practices in this area include:

• Scanning everything—proprietary code, third-party software and even open-source software, because your team might have introduced modifications triggering the need for additional due diligence and additional obligations to fulfill.

• Scan early and often—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, you should rescan it to ensure that any code added to it does not have a conflicting license and that there are no additional obligations to meet.


2. 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 and pinpointing the offending code. Here’s what should happen next:

• Inspect and resolve each file or snippet flagged by the scanning tool.

• Identify whether 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 of the scan results, discuss it with Engineering.

• If a GPL (or other) violation is found, you should report to Engineering and request a correction. Rescan the code after resolving the violation to ensure compliance.

• In preparation for legal review, attach to the compliance ticket all licensing information (COPYING, README, LICENSE files and so on) related to the open-source software in question.


3. 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 the following:

• Open-source components (used as is or modified).

• Proprietary components.

• Components’ dependencies.

• Communication protocols.

• Linkages (dynamic and static).

• Components that live in kernel space vs. userspace.

• 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.


4. 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 is identified, report to it Engineering to resolve.

• Redo 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, because it combines proprietary work with open-source libraries into one binary. These linkage cases are discussed and resolved on a case-by-case basis.

The difference between static and dynamic linking to highlight the importance of identifying how open-source license obligations can extend from the open-source components (libraries, in this example) to your proprietary code through the linking method.


5. 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 OSRB members.

• Flag any licensing conflict and reassign 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)


6. Final Review. The final review is usually an OSRB faceto- 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.

Source of Information : Linux Journal 185 September 2009