Loading
Open-Source Compliance
A discussion of open-source compliance, the challenges faced when establishing a compliance program, an overview of best practices and recommendations on how to deal with compliance inquiries.
Several departments are involved in ensuring open-source compliance (Figure 3). Here's a generic breakdown of the different departments and their roles in achieving open-source compliance:
Figure 3. Teams Involved in Ensuring Open-Source Compliance
Legal: advises on licensing conflicts, participates in OSRB reviews, and reviews and approves content of the open-source external portal.
Engineering and product team: submits OSRB requests to use open-source software, participates in the OSRB reviews, responds promptly to questions asked by the compliance team, maintains a change log for all open-source software that will be made publicly available, prepares source code packages for distribution on the company's open-source public portal, integrates auditing and compliance as part of the software development process checkpoints, and takes available open-source training.
OSRB team: drives and coordinates all open-source activities, including driving the open-source compliance process; performs due diligence on suppliers' use of open source; performs code inspections to ensure inclusion of open-source copyright notices, change logs and the like in source code comments; performs design reviews with the engineering team; compiles a list of obligations for all open-source software used in the product and passes it to appropriate departments for fulfillment; verifies fulfillment of obligations; offers open-source training to engineers; creates content for the internal and external open-source portals; and handles compliance inquiries.
Documentation team: produces open-source license file and notices that will be placed in the product.
Supply chain: mandates third-party software providers to disclose open-source software used in what is being delivered.
IT: supports and maintains compliance infrastructure, including servers, tools, mailing lists and portals; and develops tools that help with compliance activities, such as linkage analysis.
The following compliance best practices fall under six major categories. Each of the categories represents a step in a typical compliance process (Figure 4).
Figure 4. A Generic Open-Source 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 (Figure 5). 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.
Figure 5 illustrates 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.
Figure 5. Static vs. Dynamic Linking
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 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.
______________________
White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Trying to Tame the Tablet
- Tech Tip: Really Simple HTTP Server with Python
- enterprise
1 min 57 sec ago - not living upto the mobile revolution
2 hours 53 min ago - Deceptive Advertising and
3 hours 28 min ago - Let\'s declare that you have
3 hours 29 min ago - Alterations in Contest Due
3 hours 30 min ago - At a numbers mindset, your
3 hours 32 min ago - Do not get Just Almost any
3 hours 35 min ago - A fantastic rule-of-thumb to
3 hours 36 min ago - Keren mastah..
Penting,
4 hours 34 min ago - mini tablet compare
5 hours 53 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.
Developer Poll
Comments
i think more people should
i think more people should read this article so that even they can be aware of all these techniques and tricks.
more article on compliance
very good article. open source compliance should be part of the development process and it is often neglected until incidents happen. More articles on this topic would be appreciated.