This week the Linux Foundation has unveiled the Self-Assessment Checklist (SAC) as part of the Open Compliance Program (OCP) announced earlier this year. If your organization is involved in working with open source software, you’ll want to take a closer look.
The Linux Foundation’s checklist is a set of best practices to ensure that your organization, or its suppliers, are complying with licensing requirements. The checklist covers several areas, such as compliance management, training, business processes, and more.
If you felt a little snooze coming on the minute you read the word “compliance,” relax. The SAC is relatively painless, and an effective short checklist to help shape policies to ensure that they’re meeting the requirements of the open source licenses in use.
The SAC is useful not only for organizations that modify and ship open source software, or contribute to open source projects, but also for any organization that consumes open source software. Which is to say, virtually all of them. Even if your organization doesn’t modify the open source that’s in use in any way, and doesn’t ship any software, the checklist is still useful to make sure that the vendors and projects you work with are in compliance.
The checklist is available from the Linux Foundation site, with a list of more than 100 guidelines to follow. The items are comprehensive but not overly detailed. The PDF weighs in at just 22 pages, and the idea is that it’s a starting point for organizations to help develop their own internal processes. For companies that are new to the open source community, or simply feel they’d like to have expert assistance in developing policies, the Linux Foundation is also offering several training options to help organizations come up to speed.
Where the Checklist Helps
Having worked for companies that work with open source, it’s nice to see a simple checklist that (one hopes) will be an industry standard. Companies that work with open source as part of their core competency or main mission will probably find that the checklist is already more or less part of their regular business practices. But organizations that are relatively new, may find that some of the practices are non-obvious.
For example, has your organization implemented a policy to allow a business unit or department to object to community contributions? While I’m not endorsing holding back contributions, it’s not atypical for companies to find that there’s not 100% consensus on contributing to open source projects — particularly those that might compete with other products. It’s much better to find out ahead of time than to jump into a project only to have another group within the company try to override contributions after a company has committed to working with a project.
Some organizations also start investing in projects without a long-term strategy that defines the level of contributions, the expected return, and an exit strategy if the contributions do not pay off or if another project replaces the original project. Again, this is something touched on in the SAC that may not be obvious to all organizations.
What I particularly like about the checklist is that it’s, well, a checklist. It’s not a long, overwrought document that makes your eyes bleed. It’s quick and simple to get through, and can help organizations start on their own policies.
Summary
Much of the document is common sense, but not everything is obvious for those who haven’t been involved in open source previously. It’s a good primer for what to expect, and how to meet the obligations needed to not only be compliant but also a good set of tips on how to be successful in contributing to open source. Organizations might also want to combine the use of the checklist with the Open Source Way handbook developed in large part by the Red Hat Community Architecture team.
The checklist is meant to be used in conjunction with the rest of the Linux Foundation’s compliance program, including automated tools to help verify compliance, standard for sharing licensing information in software packages, and compliance directory. The compliance directory is a directory for companies to add information on their compliance directors, so interested parties can get in touch with the right person quickly to discuss license compliance issues. (Often not a trivial thing at larger organizations.)
If you’re involved with an open source project, or an organization that uses it, it’s well worth checking out the checklist. Making it easy and relatively painless to ensure compliance means companies can spend more time developing and less time on policy, and that’s a good thing.
