Open Source and Procurement: How to Manage Software in your Supply Chain

| | by

When Olliance first developed the Open Source Maturity model, we originally had seven disciplines that were primarily internally focused.  However, it quickly became apparent that we needed to expand the maturity model and look beyond an organization’s internal software development processes, so we added Supply Chain Management as the eighth discipline.

Managing the introduction of the open source software (OSS) you receive from your suppliers is vital.  Unknown OSS introduced in your supply chain can subject your company to operational risk.   And, if you embed your supplier’s code into your products and redistribute it or deploy it in customer facing applications, it can possibly subject you to legal risks. I’ve blogged before about the need for IP transparency up and down the supply chain and how initiatives like SPDX can help.  I’ve also blogged and how companies need to know more than just what is in their partner’s code.  You should review your suppliers’ OSS governance programs in the same way you would review their software development and quality processes.

8-keys-supply-chainHow companies manage OSS in their supply chain varies widely.  Going upstream in the supply chain, some companies simply require that their suppliers report OSS incorporated into their deliveries.  Other companies require warranties / representations / indemnification from their suppliers.  Companies who are more mature in their processes will actually check if the suppliers have the resources to effectively indemnify then against IP issues.  But an agreement to indemnify is not worth much if your partner does not have the revenue to cover your damages, so in this case, insurance policies are an option.

Including your procurement professionals in OSS governance is not as difficult as you may think.  Specifically including them in the policy itself and implementing some lightweight processes is all you need.  The best practices we recommend are:

  • Demand IP transparency from your suppliers.  Ask what OSS has been included in distributions, including project name, version and license.
  • Ask your suppliers what your obligations are under those licenses.  This is especially important if you redistribute it.
  • Getting information does not help much if you don’t do anything with it.  Require that the governance processes you have implemented in your own development organization also apply to your vendors.  For instance, this may include sending the OSS information from your suppliers to your OSRB for approval.  If you won’t let your developers use a particular piece of OSS, why would you let your suppliers?
  • Ask your suppliers about their own OSS governance programs.  Ensure that their lack of OSS governance isn’t exposing you to risk.
  • For risky suppliers, demand indemnification, or that they implement OSS governance (or both).
  • If you are a supplier, provide a compliance package or cookbook for your customers.  Include any source they need to distribute, any license or text files they need to include in their distros and a very clear set of instructions on what their obligations are under the licenses you give them.

It feels like ages ago, but back in October of 2010, I participated in a Black Duck webinar with Mark Radcliffe and Karen Copenhaver regarding the Android Supply Chain.  In that Webinar, Karen said something that has stuck with me ever since.  Her quote was: “There is no downstream defense for upstream violations.”

Simply put, it means every vendor in the supply chain is responsible for compliance.  When questions of compliance come up, you can’t simply punt the requests upstream to your suppliers and say “you deal with it.”   Subsequently, if you are a good supplier, you will easily enable your customers to be compliant.   Since this can get complex, the best way to ensure all this occurs is with governance, policy and process.

Note:  This blog entry is one in a series of articles regarding effective management of OSS.   It is based upon the Olliance Open Source Maturity Model which covers eight key management disciplines ranging from “Open Source Discovery” to “Executive Oversight”.




Tags: , , , , , , , , , , , , , ,

No comments yet.

Leave a Reply