The Linux Foundation’s Open Compliance Program published its compliance self-assessment checklist on November 1 right on schedule. My blog last month, Self-Assessment Checklist: A Measuring Stick for Open Compliance Efforts | The Linux Foundation, described the organization and goals of the checklist. Over 500 company downloads at Self-Assessment Compliance Checklist | The Linux Foundation later, initial feedback has been gratifyingly positive. I’d like to share with you some observations based on comments received so far.
People recognize that the checklist is not an end in itself, but a compilation of recommended compliance practices to guide and inform process improvement efforts. Any improvement guide depends on assessing what compliance steps have already been implemented. To paraphrase software process expert Watts Humphrey, who sadly passed away recently, if you need directions and don’t know where you’re at, a roadmap can’t help you. So the checklist can help you figure out how far you’ve come on compliance and where you need to go. It can stimulate discussion within an organization about the adequacy of current compliance practices. A consensus can then emerge about the additional steps to take and the individuals or teams that should perform particular compliance actions. As with any self-assessment, it helps to have an expert facilitate group discussions and keep the groups focused on what matters most. (I’m available!)
Many downloaders were intrigued by the checklist’s prospective use for assessing their suppliers’ compliance practices. People understood there’s neither a single assessment question nor a composite score that can tell them the adequacy of a particular supplier’s practices. Companies can use the checklist to get on the same wavelength with a supplier about compliance practices needed to identify all FOSS in their deliverables and to meet all license obligations. As part of ongoing supplier relationship management activities, a company identifies specific process improvements a supplier must implement and sets target completion dates over a period of months, if necessary. So far, I’ve taken part in several excellent conference calls with supply chain teams about the checklist’s use in supplier management. I’ll make a standing offer to engage your supply chain folks in a similar call, also, to advance their understanding of supply chain compliance practices. Just drop me an email. I’m available, as well, to work intensively with your suppliers on FOSS compliance.
Some downloaders commented on the length of the checklist and wondered if there was a subset of items that could be used. When compiling the checklist, we aimed for comprehensive guidance, because a compliance program must achieve 100% license compliance. The comment that “the devil is in the details” certainly applies. All compliance failure modes must be identified and prevented. But it’s also true that the core of a compliance program consists of three elements: FOSS identification; review and approval of planned FOSS use; and satisfaction of license obligations. In the checklist document, those three elements consume just four pages total. The rest of the checklist focuses attention on supporting practices that enable achievement of the three core elements, e.g. use of tools, training, audits, and so on.
Other downloaders lamented the fact that following the checklist doesn’t guarantee freedom from compliance issues. True enough. There are limits to the utility of any checklist. But following a solid compliance process improves your chances of recognizing the FOSS that’s present, determining its provenance, and complying with license obligations. Others noted that the checklist doesn’t help directly with a key compliance question some companies face: whether a particular software architecture can incorporate GPL’ed software without exposing company-proprietary software to copyleft effect. True again. No community authority exists that can render such decisions; there are just a lot of educated opinions. Determining the appropriateness of a software design must fall to a company’s software experts, in concert with its managers and lawyers, who collectively decide what FOSS use to approve, in context and with awareness the company must meet its license obligations. But the checklist helps ensure that such decisions are made in the appropriate forum by skilled individuals with the proper training, resources, and information at hand.
Please take a close look at the checklist and start putting it to use. And let me know how I can help with compliance efforts, either your own company’s or your suppliers’. Just drop a note confidentially to me at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
Additional Resources on Compliance from The Linux Foundation
In addition to the compliance self-assessment checklist, the Linux Foundation makes additional resources available to help organizations and individuals with their compliance initiatives:
- Professional and Comprehensive Compliance Training: Practical on-site training focused on the operational aspects of implementing a compliance program
- Compliance Publications: Freely downloadable white papers
- Open Compliance Directory and Rapid Alert System: A facility to help connect community members with compliance concerns to corporate compliance officers
- Compliance Tools: Open source tools to make compliance tasks easier
- The Software Package Data Exchange™ Specification: A standard format for a bill of material communicating the components, licenses and copyrights associated with a software package
- FOSSBazaar: An open community of technology and industry leaders who are collaborating to accelerate adoption of free and open source software in the enterprise
