Today’s article will shift direction from my last post to focus specifically on how customers may influence your open source software policy in respect to open source license compliance. The context of this article revolves around the distribution of open source mainly because distribution is the primary “trigger” for most license obligations.
I’ll separate the article into two sections: 1) Business to consumer [B2C] and 2) Business to Business [B2B]. Distinguishing the customer base is important for my discussion because the volume of sales, supply and demand channels, and buying process are very different.
B2C - Distribution and the consumer's impact on policy
A high percentage, if not all, of consumer products have open source embedded in them. Anyone who has bought a new smart phone, personal computer, video game system, flat screen TV, or automobile with an onboard infotainment/navigation system has most likely just purchased technology that is based on or includes, in part, open source software. The ideology behind open source software is that a consumer should have access to the [open source] code included in the product he buys. A tech-savvy consumer, curious about how the device works, might seek out the list of OSS used and the corresponding source code. If your policy is comprehensive in regards to compliance, this should have no impact. However, if such an OSS-licensing-savvy consumer uncovers open source distribution that is out of compliance with license obligations,1 you must take a serious look at where your policy failed.
The consumer demand for new technology and products that now rely on open source is outstanding. As one example, new mobile applications for smart phones show up by the hundreds, even thousands every day in app stores. We know that these apps use open source. We also know that mobile application developers are now being more proactive in their license compliance practices than in the past.
As consumers, we go to the mall and within about forty-five minutes have a new smart phone in our hands without giving the open source components we just acquired any second thought.
B2B is a very different market.
B2B - Distribution and the influence on open source software policy
B2B transactions that have a significantly higher price point than a fancy mobile device receive significantly more scrutiny than purchase of a new phone. Disclosure of the open source software components you distribute, and demonstration of license compliance, are now a top purchasing requirement. An open source policy that accounts for compliance will help cut through this new level of red tape in the sales cycle by delivering fairly real time information to prospects about the open source policy and distribution.
A software bill of materials is often required along the supply chain. The type and format of information included may vary from one vendor to another. SPDX, a Linux Foundation working group, was developed to lessen redundancy and standardize the way license and copyright information is communicated. SPDX helps bring a level of accountability, credibility, and efficiency to the supply chain when questions are raised between vendors about OSS usage and compliance. If SPDX is not yet part of your open source policy, you might benefit from taking a look sooner rather than later.
Acquiring new customers is always a good thing, but so is retaining existing ones. It might not be a brand new customer who asks about your company's distribution of open source. Because the open source compliance market has matured overall, the question could come up at the time of a contract renewal or cross sale. How quickly your company can respond and react is a reflection of the maturity of your OSS policy.
Due diligence for mergers and acquisitions includes increasingly probing questions about the use of open source in the target company. Besides the usual warranties, representations, and indemnities required for potential infringement, acquirers might request a bill of materials or a scan of all source code. Likewise, financing or distribution deals may also ask for this information. If your policy has not thoroughly tracked OSS in your organization, you may suffer a reduced bargaining position, or face mitigation requirements.
The different sizes of customer organizations, industries, and kinds of transactions you are involved with will have equally different requirements. Disclosure of a bill of materials might be good enough for one company; another company may require you to prove that you’ve completed a source code scan or open source audit. The next company may require you to prove your distribution is in full compliance. An actionable and effectively managed open source policy helps answer all of these questions for your customer.
All of these are real world examples of how the customer – whether a consumer or another business – can influence your open source policy. Proactively documenting known usage, scanning for open source to confirm you know what you have, and keeping the policy updated regularly are a long-term strategies for your company to engage