By David A. Wheeler, The Linux Foundation
It’s important to distinguish the term “source” (any source of a good or service) from the term “vendor” (a source who is paid and has a contractual relationship), especially when discussing software. Here’s why.
Thomas Depierre’s 2022 blog post “I am not a supplier” has touched a nerve among many throughout the open source software (OSS) community, because it points to a real problem. Many organizations use OSS without paying for it or having any kind of contractual agreement/relationship with the OSS project, yet demand that OSS maintainers provide endless free help for them (such as creating code improvements or filling in compliance forms on their behalf).
A stunning example is when Daniel Stenberg (leader of the curl project) received an email demanding a formal and detailed Log4Shell/log4j security response. The requestor was not his customer, yet demanded free work.
Daniel Appelquist’s “When software isn’t a “supply” suggests that “we should consider adopting a slightly different nomenclature in some contexts. The term software dependency chain might be more appropriately used when the context is the general open source developer community. Or we, as an industry, need to explain very clearly to open source developers what we mean, and don’t mean, by software supply chain.” I agree with him that the terminology needs clarification. Here’s my proposal for how to clarify things.
First, the terms “software supply chain” and “cyber supply chain” have been widely used for many years as including OSS. Many recent works discuss protecting OSS supply chains, including a taxonomy by Ladisa et al, SLSA, S2C2F, and blog posts. It doesn’t make sense to “protect OSS supply chains” if there are no supply chains. Trying to change the meaning of “software (or cyber) supply chain” now would be almost certainly unsuccessful, and it would certainly be confusing. So let’s not focus on those terms.
Instead, I think the real problem is with the term “supplier”. So I recommend that people stop using the ambiguous term “supplier” and instead:
- Use the term “vendor” to refer to an entity who supplies a good or service (such as software), is provided payment (money or otherwise), and has some sort of contractual relationship (explicit or implied).
- Use the term “source” to refer to any source of a good or service (such as software), whether or not payments or contracts exist.
All vendors are sources, but not all sources are vendors. Failing to distinguish between these two situations is causing many problems.
Given these definitions, the underlying cause of this disconnect is easy to explain: OSS projects are sources but typically not vendors, and organizations sometimes don’t understand the difference. If an organization wants those additional vendor services, those organizations should be prepared to do it themselves or pay for them (e.g., by offering to pay someone to act as a vendor for that OSS). Daniel Stenberg’s response is exactly the kind of response I’d expect; if a company wants a special service done for them (such as code changes, evaluation reports, or warranties), the company should be prepared to pay for the service.
Typical OSS licenses are quite clear, the software is provided for free and as-is, and no warranty comes for free with the software. If a warranty is desired, that’s fine, but that’s a separate negotiation – it’s unreasonable to demand work without payment. There are many vendors who provide support and other services for OSS. An OSS project could even itself act as a vendor (though that specific kind of direct paid support is rare; typically the vendor is separate or a specific maintainer). In short, when there’s payment & a contract with a specific customer, it’s clearer what the customer can demand and not demand. Differentiating the term vendor from source would reduce confusion, by helping users realize that sometimes they may need to do something themselves, contribute, or pay.
Distinguishing these terms could also help resolve the challenge of sustainably resourcing OSS projects. Many OSS projects are well supported, but some aren’t. One reason some OSS projects don’t have adequate resources is that some organizations think that “getting the current version of the software for free” implies that “we’ll also get, for free, any improvements and answers we demand”. That doesn’t even make sense, once stated clearly. Many OSS projects provide much more than software, including efforts to answer questions, fix defects, provide rapid vulnerability response, and add functionality – and that’s great! However, users must acknowledge that OSS project maintainers have their own goals and do not need to do more than they are willing to do when users aren’t paying for the service.
Economists are often confused by OSS. I think part of the problem is that they confuse physical goods with intellectual works. A physical good requires resources to make each copy, but making a digital copy of an intellectual work (such as software) is basically free. What’s costly to the OSS maintainers isn’t making copies; what’s costly is providing further service.
Earlier versions of this article used the term “supplier” instead of “source” as the general term. Many were fine with using the term “supplier” as the general term. However, others felt the term “supplier” was easily confused with “vendor”. Thomas Depierre’s 2022 blog post objects to the word “supplier” in its title. SafeCode says the term “supplier” is synonymous with “vendor”, and when discussing OSS it ends up using long circumlocutions like “sourced from repositories of Open Source Software (OSS).” This EU document takes pains to not use the term “supplier” as the OSS project. It’s helpful to have a single word for a common situation, and after discussion with others the best general word I could find is “source”. This has other analogies; a lake may be referred to as a “water source” and could be considered as part of a “water supply chain” – but a lake is not normally termed a “water supplier” or “water vendor”. The term “source” could perhaps be confused with “source code” but in practice it doesn’t seem confusing.
The Open Source Security Foundation (OpenSSF) is all about improving the security of OSS. But note that the OpenSSF is not about making unpaid demands on OSS projects. The OpenSSF has performed security audits, proposed fixes, provided free MFA hardware tokens, provided free classes, provided tools (like the OpenSSF Scorecard and OpenSSF Best Practices Badge) to help projects evaluate their security posture, and so on. Sometimes we pay people to do the work, sometimes the people doing the work are volunteers from organizations who pay them, and sometimes the people doing the work are unpaid volunteers. Demanding that OSS projects act as vendors, when they’re sources but not vendors, doesn’t help anyone.
How can you help? A small step would be clearly distinguishing vendors and sources in things you write (and encouraging dictionaries to do so). Another step would be identifying cases where your organization needs an OSS project to do something, and offering to provide resources to help do that work (contribute code or documentation, donate time, pay existing maintainers to do the work, and so on). One approach is to pay the project or specific project maintainers. You can also work with the many OSS foundations (e.g., as an organizational member or just getting involved) to help address and resolve issues that cross-cut across many OSS projects. If many do a little, it adds up to a lot.
About the Author
Dr. David A. Wheeler is an expert on developing secure software and on open source software (OSS) development. He wrote the book “Secure Programming HOWTO” on how to develop secure software, and his work on countering malicious tools (“Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)”) is widely cited. He is the Director of Open Source Supply Chain Security at the Linux Foundation, and teaches graduate courses in developing secure software at George Mason University (GMU). You can reach David at: <dwheeler at linuxfoundation dot org>