I’ve seen so many hot takes from developers about “Software Supply Chain” implying that corporations are demanding things from them. Have any maintainers had negative interactions with companies demanding things or are the demands inferred from the term “software supply chain”? Most of my experience at a company building on open source has been that “we need to secure the software supply chain” means “we need to reason about our dependency upgrades and have repeatable builds rather than roll forward automatically or accidentally to every single dependency’s new release”. I haven’t yet understood what new burden this puts on maintainers, other than a feeling of being cogs in a wheel because of the term that was chosen.
The demands are laundered through the community. If the perception and expectation is they do the work then companies don’t actually have to call them up on the phone.
I utilize open source software at work on the teams I manage. As far as the developers of that software I regard the relationship not as supplier but more like occasional collaborators. They have no obligation to me. I have no obligation to them. I do have an obligation to my company which means that I need to evaluate the software I’m using for fitness and I need to recognize that I’m taking on a maintenance burden for that software by choosing to use it.
If I have an issue with the software then I have a few options:
I can fix it myself and optionally provide them the fix. They are under no obligation to take the fix. I may have to keep an internal fork if I go this route and if maintaining the fork over time becomes too costly I may want to reconsider my approach.
I can ask nicely if they would be willing to fix the issue or I can offer to pay them to fix the issue. They are under no obligation to do so. If they don’t want or don’t have capacity to fix it then I may want to reconsider my approach.
I can find a different piece of software to solve my problem. This may involve writing my own if nothing else exists. If this proves problematic I may wish to reconsider my approach.
If you use open source libraries or software in your product then the above 3 options are the full extent of your relationship with the authors of that software. You can wine about it, or you can be grateful that there is so much software out there that you don’t need to write because of this system, and not complain if you occasionally you have to write a little more code than you were expecting. If you didn’t do your due diligence on the software and that bit you later then you failed your company but the software project didn’t. That’s on you.
I will note that there are certainly projects out there that have engaged in malicious activity in the past and we can rightly condemn those projects as malicious but you get paid by your company to weed those projects out. It’s a part of the job and if you can’t do it then you should probably find someone who can to do it for you.
If you use open source libraries or software in your product then the above 3 options are the full extent of your relationship with the authors of that software.
That’s true from a strictly legalistic perspective, but I think one of the strengths of the ecosystem (which is being eroded by a lot of corporate participants) is the community part of F/OSS community. Communities have social contracts in addition to laws and those are often more important for their functioning. For example, I am more willing to take a patch for a feature that I don’t care about (and so will add maintenance costs) from someone who has shown that they are a positive contributor to the community, whether that’s writing docs, helping other people use the project, packaging it, submitting code, or filing detailed and helpful bug reports.
I agree. The community aspect is important. It helps as someone who works at a small/medium sized company to recognize that my first option is the best one for my company and I should work to ensure that the PR is acceptable and that I as well as my company is regarded as a positive community contributor. It’s hard to maintain a fork long term so things go much better for me if I’m regarded positively by the project.
But I’ve certainly run into occasions where the project was just overwhelmed and I had to wait months for my PR fix to get attention. In those cases I didn’t complain to the project or rant over twitter about how irresponsible they were. I maintained a local fork with my fix and waited patiently for my PR to get the attention it needed. Always remembering that if the local fork became too much of a maintenance burden that I could look for other ways to solve my problem.
I think it hurts community when a working engineer or company doesn’t realize that the community is one of give and take and that neither party is under any obligation to escalate your particular issue to the top of their pile. If you aren’t up for participating in a way that recognizes that then you can rightly expect to at best be ignored or worst become a pariah.
I’ve gotten a few emails over the years from folks who insist that I assembled a software package for them, and that I now need to tell them what was in the package. My reply depends heavily on the details of the request. The most common theme is probably regulatory compliance.
Company: “I received value from something you posted for free with no warranty, so you have an obligation to make sure I keep receiving value.”
Programmer: “No, I don’t. I have no relationship with you.”
It’s rather like how in feudal societies, if the peasants gave the lord five loaves of bread on a special occasion one year, the lord would show up again the next year demanding them as his annual due. If companies want support, they should pay for it. Of course they don’t want to in general, and would prefer to browbeat people into treating them as a feudal lord, but the health of our society demands that they, collectively, be put in their place.
There are some more subtle cases. In particular, often the company is willing to pay but the developer doesn’t have time. Sometimes in this case the company pays someone else to do the work and the developer doesn’t then want to take the patches. Sometimes the company wants to pay but has procurement processes that make it hard to pay the original developer in a way that they can accept (GitHub sponsorship can sometimes help here).
I never said that they did, but it leaves downstream in the position of being forced to either:
Maintain a private fork
Try to run a public fork
Live without the feature
All of these can be expensive. When you are in a situation where one or both parties in an exchange are unable to get what they want, you will have friction. Fault is not implied in either party.
That doesn’t seem particularly subtle. If I were selling the software and entering into contracts, I might well say, “No, I don’t want to do business with you.” How is this different?
Just because you’re a volunteer does not mean you’re not a supplier.
We have this friend Lisa who helps my family with grocery shopping
(we’re blind). Last week she randomly showed up at our door and gave us
a couple grocery items for free. They’re things we always have trouble
finding due to … supply chain issues, post covid. She saw them at a
store, bought them, and gave them to us gratis.
Now that’s basically what free software is all about. It’s a gift, in a
gift culture. The free software license typically describes what the
recipient may do with that gift.
To use my analogy above, making demands of free software developers
would be like me demanding that Lisa come over to my house and cook the
free food she bought us. Lisa owes us absolutely nothing whatsoever.
You want work done by free software developers? You can ask nicely.
You can offer to do the work yourself and contribute it to them. In
both cases, they are well within their rights to say no, because they
owe you nothing. You should not make demands unless you are in a
contractual relationship that permits such things.
On the other hand, there are demands made of us all through the social
contract. If you want to put constraints on free software, this is the
language that might get more traction. If you want to encourage free
software developers to observe certain practices, use the language of
community and social contract, not the capitalistic language of
suppliers and customers. Language and the way a thing is framed really
can matter. I absolutely loathe the term “human resources”. People
aren’t timber forests or oil wells or gold mines. Free software
developers are people, not suppliers.
making demands of free software developers would be like me demanding that Lisa come over to my house and cook the free food she bought us
This. Only, unfortunately, the mentality of many people has changed. The gratitude, that a developer makes open source software for free in his spare time, gives way more and more to a universal attitude of entitlement, and many users even seem to have the mistaken attitude that the developer even has to be grateful to them for using his software.
It’s not an accidental change, it’s a direct result of large projects being maintained by companies, who have some sort of business model around it. This creates the expectation that there will be regular updates, prompt security fixes, good docs, etc. This in turn makes people think that software grows on trees.
There is also a flipside to it: certain software is ostensibly open source (e.g. chromium), but in actuality it’s an oligopoly/monopoly that people are pretty much forced to use or rely upon. This in turn puts an enormous responsibility on those projects to actually do a good job, or they are basically squandering that mandate. They can hide behind the “it’s open source” fig leaf easily, when they absolutely shouldn’t.
Volunteer developers tend to get the worst of both: they are also subject to upstream changes, but don’t have the resources to provide similar maintenance downstream. It also doesn’t help that most people don’t think about why a volunteer dev is working on a particular project:
as a learning experience
as a social club
as a loss leader for job opportunities
as a platform for delivering services
So you actually need to understand a fair amount about a project to know how to approach it.
Case in point, I had an exchange with a Chrome GPU dev who flippantly responded to a request with a dismissal that showed they had no idea what I was even talking about (misidentifying a 2009 feature as the latest and greatest tech). This person’s work will define what the entire web ecosystem will be able to do GPU-wise for the next decade at least. You should in fact give them an earful for that.
Ugh, this unlocked a relevant memory. I now recall asking Android developers why they did not reuse existing standard libraries like Cairo or Pixman when writing their graphics subsystem; their excuse at the time was bullshit and it was later revealed that Google ordered them to rewrite everything to avoid GPL (slides 36, 51). (Yes, I know Cairo/Pixman are MIT-licensed, but do they?) I also asked them whether they had armored their latest GPU-exporting API (“Native Client”, I think) against buffer-reuse attacks which exfiltrate data from GPUs, and their response was similar to the one that you describe. By avoiding software in the commons, Google made their product slower and less secure.
The worst part is that there’s nearly no way to contribute labor to make it better. I spent a few months working on Chromium OS and all I improved was one small chunk of graphics testing.
I don’t think you intended offense. I see you referred to Oss devs as “him” I know OSS devs that go by “her” and “they” and I don’t want to quietly erase their work. Can you use singular they in the future?
Now that’s basically what free software is all about. It’s a gift, in a gift culture. The free software license typically describes what the recipient may do with that gift.
It’s kinda weird if you think about it. If you were to explain to a lay person that companies make a living by sticking together many “free gifts” and sell the result as a product, they might declare you mad.
Nothing else in the world works this way, AFAIK. I think this is also why we’re still struggling to make sense of the weird distributions of power and wealth surrounding FOSS, because there’s no analogue that fits well enough to adopt wholesale. You could say FOSS is an economic anomaly of sorts.
Many fields work somewhat like this, it’s just that usually the costs are different. Electronics is full of handy designs written down and distributed for free. Chemical engineering is full of handy reactions written down and distributed for free. Writing fiction is full of handy tropes written down and distributed for free. Creating and using these sorts of things are usually managed by copyrights and patents, and those are the cases where the patent system usually kinda sorta works like it’s supposed to. Lots of trivial BS gets patented, but it also does a halfway decent job of making sure that the people who put 8 or 9 figures into developing something can then get paid for it reliably.
The thing about software is that the cost to using/distributing/copying it is tiny, while in all those other fields you generally need to either physically buy and assemble components to use the design, or put in significant amounts of work massaging it into your own design, or both. So you have the fixed costs of designing and building A Thing, and then the variable costs of actually manufacturing and distributing it, and for software the variable costs are miniscule because it’s just copying around bytes. So while designing and building software is just as much work as designing and building anything else, actually “manufacturing” and transporting it is so, so cheap that you might as well give it away. Even companies routinely give away fairly large amounts of storage and bandwidth, as seen by the free tiers of Cloudflare, Github, and all sorts of other things. On the flip side there’s a number of open source hardware projects of one kind or another that happily give away schematics for free, but also just straight-up sell manufactured parts as well. Sure I could manufacture my own Pinebook Pro mainboard from the designs if I really wanted to, but it would be a metric shitload of work to just find and get all the parts, let alone assemble it. In comparison, I can download and build the firmware for said board in about three minutes.
There’s other things that go into this. Anyone can write software of arbitrarily high quality by sitting down with some relatively cheap tools and getting to work. I don’t think there will ever be a gift economy in, say, 100 ton mining trucks, because while many people can forge and weld steel in their garages, most of those hobbyists don’t have the space or tools to build machines the size of a house. I don’t think there will ever be a (large) gift economy in hand-made woodworking art either, ‘cause those things basically can’t be replicated efficiently – once you start scaling up production it ceases to be hand-made, so there’s no economy of scale to take advantage of. In comparison, I would need very, very little physical infrastructure to sit down and write the next curl or sqlite or ninja.
This is changing! I can go to Shapeways or some other 3D printing design repo and, indeed, stick together many “free gifts” and sell the result as a product. And, frankly, there are already plenty of companies that sell products that they don’t manufacture, they just do the “value add” of things like retail distribution, customer support, etc so that the manufacturer doesn’t have to.
So yeah. There’s nothing fundamentally different about software compared to any other artifact made by humans. The difference is all in the costs to different parts of the process of building and distributing it.
Electronics is full of handy designs written down and distributed for free. Chemical engineering is full of handy reactions written down and distributed for free. Writing fiction is full of handy tropes written down and distributed for free.
I’d argue our equivalent to such things is algorithms and design patterns, rather than ready-to-reuse code. These are covered by software patents (ugh) and sometimes copyright, as well. The “copy and reuse” in writing is perhaps more like fairy tales and such that get repeated verbatim and tweaked here and there. But there the origins are lost in the mist of time, such that there’s no one clear author and if there was, they’d be long deceased by now anyway.
The key difference is that reactions and circuit designs need no ongoing maintenance to remain useful.
Chemical reactions also make a very poor analogy because simply knowing a reaction is just the beginning of the beginning of the process. Development of equipment for conducting that reaction at a commercially viable scale is a whole different problem.
The key difference is that reactions and circuit designs need no ongoing maintenance to remain useful.
That’s why I equated them to algorithms and design patterns, which don’t need any maintenance either. They’re a high-level description of how to do things, without actually implementing the thing in a concrete language.
Actually I think you’re a little wrong that nothing works anything like this. The NGO sector works at least something like this.
It’s not that uncommon - especially in some non-western cultures, especially historically- for exchanges of gifts to result in loosely defined reciprocal relationships. Similarly, the trope in business circles is that in Japan contracts are much more flexible than in the west.
I do agree that this is something very odd in our current culture, and definitely a sign that our culture needs to change.
It is worth noting that that anomaly is not an accident. The Free Software Foundation and associated parties were enacting their ideology from the start, part of which was economic in nature. That history gets forgotten a lot today, because frankly the people who felt most strongly about it weren’t good at communicating those ideals, but it was there from the outset.
That’s a great point. I wonder how things would’ve been different if they had foreseen the current situation, and if FOSS would have become as popular as it has if they had chosen a different approach.
I mean, if you think about it, the ability to run almost any OS you like and still be able to work practically is a huge luxury. Twenty years ago, using Linux as a daily driver was like pulling teeth because there was just so much software you couldn’t run and file formats you couldn’t open. Mostly it was the web that made this possible though, the very thing that makes FOSS a paper tiger (excepting AGPL, but that’s not very popular).
If you had told people like RMS “in 40 years you will be able to run any software you like, which you can mostly inspect and modify as you wish, but you’ll mostly be using it as a viewscreen into other people’s computers running closed-off software you cannot even inspect”, I wonder how they’d respond.
Fascinating question. I don’t claim to know but it’s interesting to think about. My own take-away is mostly that the fight continues, a lot of ground has been won but there’s a lot yet to do.
I bet you’d be pissed if she gave you something that had a safety recall on it. From that point on, I think you’d be on notice that you can’t rely on her not to do that, and take appropriate steps to guard against that.
The article is arguing that it does mean that. It offers several arguments. You are just stating the opposite without addressing any of those arguments. What do you think your comment accomplishes?
That’s not an assumption, but a stipulation about the word ‘supplier’ as it is used in the article. The entire point is that there are legal consequences to the relationship that they describe as ‘being a supplier’.
You seem to just be bluntly applying a dictionary definition of the word ‘supplier’. But the dictionary definition of the word is irrelevant here.
You can redefine any word to mean anything. Sure, under the author’s made up definition they’re not a supplier. Under the definition used by speakers of English in general, and especially people who talk about software supply chains, the author is a supplier.
Having clarified all of this about the word “supplier” has achieved nothing. The question is what kind of obligations, formal, informal, and legal, a person has if they make software available to other people, and what obligations the receivers have, in their capacity as both end users and as onward suppliers.
You may be a volunteer, and even a supplier, but you may be free to ignore any requests from those that you supply. Not because you’re volunteer, that’s irrelevant. Because you have no legal relationship with the people using your software.
We can argue either way, but whatever you call oss maintainers, they ain’t getting paid to have the responsibilities that the “software supply chain” discourse kinda pins on them.
Ok but your comment is way more insightful than the whole article. That said, I think the analogy is helpful: if you receive a defective product that you’ve paid for, or is supplied for for a particular purpose, your remedy is against the one who supplied it to you, not the remoter parts of the supply chain.
We need to take seriously that our incoming supply chains are primarily made of software received for free and with no warranty of fitness for purpose. That doesn’t imply oss maintainers should be more responsible - it implies that their users need to take responsibility for how they source their input software, in the same way as people shopping for responsibly sourced foods.
At the same time, it helps us to think about what kind of non contractual obligations a supplier of goods or software might have. For example, even if you’re selling hammers, you probably should be held responsible if you knowingly supply hammers contaminated with anthrax. If you put out hammers with their component clearly and correctly described, and it is well known that there are limitations to the hammer head that will make it scuff things (say), is the hammer supplier responsible or the user for economic loss from hammer scuffs?
In the OSS context, knowingly distributing malware seems off, for example, but not obviously something that users should be able to assume won’t happen. Or what about open source software that is for a specific purpose regardless of what the licence says? If I distribute an oss software library known to run on specific medical hardware, and advertise that, and the software does something bad, can I completely disclaim any responsibility for foreseeable physical harm occasioned by using an affected device? And does the person who supplied the device to the end user have any responsibility? Are indemnity clauses in the licenses effective?
I think these are all worthy questions, and point to the final supplier of software being responsible for auditing their supply chain, and choosing to use software that can be patched to use patched libraries, and be able to rebuild their whole set of dependencies from source, or accept the consequences of being dependent on third party builds.
Incidentally, Amazon does have the ability to build all their OSS dependencies from source, and I assume that the big monorepo companies (Facebook, Google) have that ability. As an aside - if you don’t have that ability but you think you have a monorepo, I think you’re just a FAANG fanboy playing dress up.
you probably should be held responsible if you knowingly supply hammers contaminated with anthrax.
Let’s remove the knowingly and change selling to giving away hammers for free. That’s a much more accurate analogy for OSS maintainers, and in that case, I don’t think the hammer giver is responsible for anything in anyway whatsoever.
If I distribute an oss software library known to run on specific medical hardware, and advertise that, and the software does something bad, can I completely disclaim any responsibility for foreseeable physical harm occasioned by using an affected device?
Legally? Yes, 1000%. Why the everliving fuck did a manufacturer of medical devices put software in it that they didn’t fully audited? It doesn’t matter that I wrote the buggy code, I didn’t make a promise to patients that the device would work.
Now, ethically, that is shaky, specially the advertising bit. But honestly, do you see this happening, ever? Non-experts writing code for critical domains and advertising it and making money of it? I can’t think of s single example.
And to be clear, by critical I mean actually critical. Medicine, nuclear power, etc. Doesn’t matter how big your web SaaS is, if people don’t die when it fails, it ain’t critical.
Every time OSS maintainers bring up the fact that big corporations leech of their free work, people start whatabouting that maintainers have responsibilities too. It’s a valid conversation, but feels like when people say “What about Palestine?” when Jews are talking about antisemitism[^1]. Yeah, that’s fucked up, but it’s a different conversation, that has potentially nothing to do with the current one (lots of Jews disapprove of Israel’s government), and smells like an attempt at victim blaming.
[^1]: know I’m violating Goodwin’s law here, but it’s the best analogy that comes to mind.
Ok what if you’re giving away anthrax contaminated hammers recklessly - ie you could know if you did a normal level of diligence for a hammer supplier? Does that seem like something that should be free of liability?
I found a bunch of hammers in an abandoned lot, took them home, and put them in my front yard with a sign saying “free hammers”.
There is no normal level of due diligence that can be expected of me. I’m not a supplier of anything. I’m just giving away shit for free. Hell, I’m probably dying of anthrax myself, if you wanna push the analogy.
Flippancy aside, though: there absolutely are OSS maintainers that might fall more in the “actually somehow a supplier, even if the product is free” side of things, but:
They are the exception, not the rule
There is still can’t be no legal obligation or liability to them from people that use their stuff for free.
I’ll give you that maybe, MAYBE, if you can PROVE malicious intent, and if the maintainer in question derives significant monetary and/or societal benefits from the software they maintain, and if the damage caused was significant, then MAYBE it would be valid to assign them legal liability.
But that never happened, ever, in the history of ever. And is still whataboutism, because that’s not the situation anyone is talking about (other than you). The article is not philosophizing about what set of rules should govern all possible relationships between OSS maintainers and the users of the software they maintain (which would be pointless, by the way: to much variance for a general case to exist). It’s talking about the here and now of how the majority of these relationships is happening.
But they’re not volunteers either. A volunteer is someone who forms an explicit relationship with an organization to provide effort and resources for the organization’s ends. A programmer who puts code online that an organization picks up and uses is not a volunteer for that organization.
All these words attempt to imply the existence of a relationship that does not exist.
Words are complex and have complex meanings, and the more common they are, the more meanings they have. It’s honestly mind boggling when people assume that a common word has one, and only one, narrow and exact definition.
Merriam-Webster seems to think your definition of volunteer is way to narrow, by the way (some irrelevant parts omitted for brevity):
: a person who voluntarily undertakes or expresses a willingness to undertake a service: such as
[…]
b (1): one who renders a service or takes part in a transaction while having no legal concern or interest
I mean, the comment you are replying to has less legs to stand on than a snake, but your argument is almost worse.
Not everyone giving away something for free is a volunteer.
On the other hand a true volunteer (i.e. a person who works for an organization without being paid) is usually not allowed to give the products of this company (i.e. which includes his work) away for free.
Volunteer for what exactly? Just saying ‘volunteer’ doesn’t give anyone the obligation to do whatever you think they should do. Dictionary definition:
a person who freely offers to take part in an enterprise or undertake a task.
(New Oxford American Dictionary)
A person who publishes free software online can be said to be a volunteer for the enterprise or task of publishing free software. They cannot be said to be volunteering for the task of providing ongoing support and maintenance to any specific user for said software. Especially given that the software license clearly delineates that fact.
When you throw around words that try to place obligations on others, perhaps you should consider the words carefully.
Suppliers usually have contractual relationships with their customers. Just because someone uses open source software doesn’t mean there is a contractual relationship; e.g. GPL states “You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.” A user can therefore acquire and use an open source application or library without concluding a contract.
Acceptance of the offer to conclude the open source license agreement thus generally only occurs when the user wishes to make use of the special powers arising from an open source license. In the vast majority of cases, acceptance of the agreement is “implied”, i.e. by conclusive action. However, this does not impose any obligations on the developer, neither a delivery obligation nor a maintenance obligation, and certainly not an obligation for a certain functionality or quality. This is not what is meant by supplier or supply chain.
I wonder how far we can take the AS-IS disclaimer. Let’s say the manufacturer of some popular thermostat brand has an MIT-licensed dependency. One day the author is in a bad mood, so she decided to install a backdoor into her package which causes all thermostats to malfunction during an ice storm, freezing thousands to death. Of course, the thermostat company will be responsible for their negligence, but can the ill-intended author be held accountable for her murder?
Your scenario is highly ambiguous and liberal with definitions. I’m not a lawyer, but let me play one on TV. ;)
The code contains a backdoor — a piece of logic that allows an unauthorized person to take control of the device (over the Internet or otherwise). The developer puts one in hope that a thermostat manufacturer uses it, waits for an ice storm, then connects to vulnerable thermostats to cause them to malfunction. In that case, the developer is guilty of unlawful access and, if people die as a result, for homicide (but whether it’s going to be classified as murder is debatable and likely depends on many things[1]).
The code contains logic bomb — a piece of code that causes thermostats to malfunction under specific conditions.
If it’s possible to prove the intent, then the developer is quite likely to held liable, although exact charges will vary between jurisdictions. Something like this leaves little room for interpretation:
if (hardware.device_class = "thermostat") and (environment.temperature < 0) then
set_temperature(NaN);
end
The code contains a deliberate flaw that will cause it malfunction when it’s used in ACME T1000 thermostats, but doesn’t contain enough evidence that it was deliberate or it appears in a wide range of conditions. I doubt there’s a way to held the developer liable in that case, and that’s likely what a smart attacker would do.
[1] In common law countries, there’s a distinction between murder and manslaughter. Civil law countries have similar distinctions — not all acts that cause people to die are equally culpable. I doubt that breaking a central heating pipe would be classified as murder even if people freeze to death, for example.
I’ve recently had some discussions with a lawyers on a similar topic. For software, at least in the US and Europe, the case law (or statute law in countries that don’t have a common law tradition) seems to indicate that a disclaimer of liability can be pretty much total. That’s largely irrelevant for your example because the intent would mean that this would typically be prosecuted is under computer misuse legislation, not product liability law. The place that this gets fun is in open source hardware because you typically can’t disclaim liability for physical goods. The lawyers that I’ve spoken to believe that open source hardware counts as free blueprints and so the liability for accidental flaws falls on the company that manufactures them and assembles them into products (they are required to pass validation and regulations and must explicitly have a contract indemnifying them if they want their suppliers to take liability) but there’s as-yet very little law (case or statute) around open source hardware.
Honestly, it’s interesting to me to see the discussion of “is this a supply chain” or “is this volunteerism?” I think software is an ecology, and there are various webs of relationships, from actual supply chains (formed via contracts) to extractives (used by taking value from something where you have minimal relationship to the originating source) to farmed resources (and just like actual farming, there are various levels of farming that work or don’t, and how resource intensive they are or aren’t). Just like viewing the “food chain” had to evolve into the “food web,” I think we need to move beyond linear views in terms of the way we compose and use software; likewise, just like ecosystems, we need to be better supportive of how and why we consume the things we do.
Similarly, just like we’ve had to admit that certain farming practices are too intensive for local soil, we also need to reflect on how and why we use the software we do, and at what cost. I’m not saying one side or the other is correct, but what I am saying is viewing it as one or the other is just one perspective to a complex interdependence chain and we risk collapse if we don’t understand the ways in which we are interacting with the systems we depend upon.
I sort of want to flesh this out more, but it does seem to me that we’ve been bumping up into this in multiple ways lately: from collapse (developer removes their packages for various reasons) to decay (developers don’t want to interact in certain ways) to monocultures (one giant developer takes over an ecosystem and things mainly run their way) to vulnerability (all the various ways in which we don’t actually understand what we’re running). Addressing this will be interesting, and will likely lead to the similar sorts of discourse as we’ve been seeing, since it is unlikely that we will actually figure out ways of sustaining things properly.
Software consumers develop their own software on bare hardware. Selling software isn’t even a thing yet, and distributing software is a huge pain.
Companies start selling software on physical media, creating a foundation from which consumers can start, giving those building on top of other software a huge advantage over those who develop their own entire stack. The physical media itself sets an absolute minimum cost of the software from any company which wants to stay in business, and development is expensive expert labour, so companies can charge lots.
The Internet happens, making data distribution very nearly zero cost.
People start giving software away, including the source code, because it doesn’t cost them anything significant to put it online.
Consumers eagerly start using the FOSS, for a bunch of reasons like it being gratis, being able to take over if the original maintainer stops, being able to fix things themselves faster and cheaper than the traditional software companies could, and so on.
Consumers want to have their free cake and eat it too, expecting the same level of service from a project maintained by a single person as they received from ACME International at extortionate prices back in the olden days.
Too simple a timeline, but it does feel like companies just haven’t understood what they’re dealing with when communicating with FOSS maintainers.
The author’s distinction between “supply” and “provide” cannot survive outside the context of the license. Nor do I think it useful since “provider” is already being used to describe commercial relationships.
Security people seem to be using that phrase the most in software contexts. They need something that describes to non-technical audiences in one phrase the threat model in situations like the malware in node-ipc. Appreciated that “supply chain” is probably the wrong one because it implies a commercial relationship. What’s a better one?
Tbh it seems to imply a commercial relationship only to a vocal minority. I think you can’t avoid that some people will go to the ends of the earth to argue that it’s the wrong word.
Well said, and I couldn’t agree more. If I were writing this essay I would tie it to my own political views, but I think if anything it’s more powerful as a simple practical position like this. There is a core argument against “software supply chain” ideas that surely people from all over the free software and open source communities can agree on, even if we arrive at it for different reasons, and this essay is that core.
I’ve seen so many hot takes from developers about “Software Supply Chain” implying that corporations are demanding things from them. Have any maintainers had negative interactions with companies demanding things or are the demands inferred from the term “software supply chain”? Most of my experience at a company building on open source has been that “we need to secure the software supply chain” means “we need to reason about our dependency upgrades and have repeatable builds rather than roll forward automatically or accidentally to every single dependency’s new release”. I haven’t yet understood what new burden this puts on maintainers, other than a feeling of being cogs in a wheel because of the term that was chosen.
The demands are laundered through the community. If the perception and expectation is they do the work then companies don’t actually have to call them up on the phone.
Not about supply chain but you can get the vibe here https://mikemcquaid.com/entitlement-in-open-source/
It happens on a regular basis. Here’s log4j: https://dev.to/yawaramin/the-human-toll-of-log4j-maintenance-35ap
I occasionally get emails from companies that don’t maintain separate lists of open-source things they use and vendors they have paid contracts with.
But most of the really “demanding” stuff I’ve seen has not been of corporate origin.
I utilize open source software at work on the teams I manage. As far as the developers of that software I regard the relationship not as supplier but more like occasional collaborators. They have no obligation to me. I have no obligation to them. I do have an obligation to my company which means that I need to evaluate the software I’m using for fitness and I need to recognize that I’m taking on a maintenance burden for that software by choosing to use it.
If I have an issue with the software then I have a few options:
I can fix it myself and optionally provide them the fix. They are under no obligation to take the fix. I may have to keep an internal fork if I go this route and if maintaining the fork over time becomes too costly I may want to reconsider my approach.
I can ask nicely if they would be willing to fix the issue or I can offer to pay them to fix the issue. They are under no obligation to do so. If they don’t want or don’t have capacity to fix it then I may want to reconsider my approach.
I can find a different piece of software to solve my problem. This may involve writing my own if nothing else exists. If this proves problematic I may wish to reconsider my approach.
If you use open source libraries or software in your product then the above 3 options are the full extent of your relationship with the authors of that software. You can wine about it, or you can be grateful that there is so much software out there that you don’t need to write because of this system, and not complain if you occasionally you have to write a little more code than you were expecting. If you didn’t do your due diligence on the software and that bit you later then you failed your company but the software project didn’t. That’s on you.
I will note that there are certainly projects out there that have engaged in malicious activity in the past and we can rightly condemn those projects as malicious but you get paid by your company to weed those projects out. It’s a part of the job and if you can’t do it then you should probably find someone who can to do it for you.
That’s true from a strictly legalistic perspective, but I think one of the strengths of the ecosystem (which is being eroded by a lot of corporate participants) is the community part of F/OSS community. Communities have social contracts in addition to laws and those are often more important for their functioning. For example, I am more willing to take a patch for a feature that I don’t care about (and so will add maintenance costs) from someone who has shown that they are a positive contributor to the community, whether that’s writing docs, helping other people use the project, packaging it, submitting code, or filing detailed and helpful bug reports.
I agree. The community aspect is important. It helps as someone who works at a small/medium sized company to recognize that my first option is the best one for my company and I should work to ensure that the PR is acceptable and that I as well as my company is regarded as a positive community contributor. It’s hard to maintain a fork long term so things go much better for me if I’m regarded positively by the project.
But I’ve certainly run into occasions where the project was just overwhelmed and I had to wait months for my PR fix to get attention. In those cases I didn’t complain to the project or rant over twitter about how irresponsible they were. I maintained a local fork with my fix and waited patiently for my PR to get the attention it needed. Always remembering that if the local fork became too much of a maintenance burden that I could look for other ways to solve my problem.
I think it hurts community when a working engineer or company doesn’t realize that the community is one of give and take and that neither party is under any obligation to escalate your particular issue to the top of their pile. If you aren’t up for participating in a way that recognizes that then you can rightly expect to at best be ignored or worst become a pariah.
Very much agreed about the importance of the community aspect, thank you both for weighing in with this.
I’ve gotten a few emails over the years from folks who insist that I assembled a software package for them, and that I now need to tell them what was in the package. My reply depends heavily on the details of the request. The most common theme is probably regulatory compliance.
This ongoing dispute seems to consist of:
Company: “I received value from something you posted for free with no warranty, so you have an obligation to make sure I keep receiving value.”
Programmer: “No, I don’t. I have no relationship with you.”
It’s rather like how in feudal societies, if the peasants gave the lord five loaves of bread on a special occasion one year, the lord would show up again the next year demanding them as his annual due. If companies want support, they should pay for it. Of course they don’t want to in general, and would prefer to browbeat people into treating them as a feudal lord, but the health of our society demands that they, collectively, be put in their place.
There are some more subtle cases. In particular, often the company is willing to pay but the developer doesn’t have time. Sometimes in this case the company pays someone else to do the work and the developer doesn’t then want to take the patches. Sometimes the company wants to pay but has procurement processes that make it hard to pay the original developer in a way that they can accept (GitHub sponsorship can sometimes help here).
They don’t have any obligation to take patches.
I never said that they did, but it leaves downstream in the position of being forced to either:
All of these can be expensive. When you are in a situation where one or both parties in an exchange are unable to get what they want, you will have friction. Fault is not implied in either party.
The expense was always there, it was just being borne by others. Now it’s being borne by the user.
That doesn’t seem particularly subtle. If I were selling the software and entering into contracts, I might well say, “No, I don’t want to do business with you.” How is this different?
Money quote:
Just because you’re a volunteer does not mean you’re not a supplier.
We have this friend Lisa who helps my family with grocery shopping (we’re blind). Last week she randomly showed up at our door and gave us a couple grocery items for free. They’re things we always have trouble finding due to … supply chain issues, post covid. She saw them at a store, bought them, and gave them to us gratis.
Now that’s basically what free software is all about. It’s a gift, in a gift culture. The free software license typically describes what the recipient may do with that gift.
To use my analogy above, making demands of free software developers would be like me demanding that Lisa come over to my house and cook the free food she bought us. Lisa owes us absolutely nothing whatsoever.
You want work done by free software developers? You can ask nicely. You can offer to do the work yourself and contribute it to them. In both cases, they are well within their rights to say no, because they owe you nothing. You should not make demands unless you are in a contractual relationship that permits such things.
On the other hand, there are demands made of us all through the social contract. If you want to put constraints on free software, this is the language that might get more traction. If you want to encourage free software developers to observe certain practices, use the language of community and social contract, not the capitalistic language of suppliers and customers. Language and the way a thing is framed really can matter. I absolutely loathe the term “human resources”. People aren’t timber forests or oil wells or gold mines. Free software developers are people, not suppliers.
This. Only, unfortunately, the mentality of many people has changed. The gratitude, that a developer makes open source software for free in his spare time, gives way more and more to a universal attitude of entitlement, and many users even seem to have the mistaken attitude that the developer even has to be grateful to them for using his software.
It’s not an accidental change, it’s a direct result of large projects being maintained by companies, who have some sort of business model around it. This creates the expectation that there will be regular updates, prompt security fixes, good docs, etc. This in turn makes people think that software grows on trees.
There is also a flipside to it: certain software is ostensibly open source (e.g. chromium), but in actuality it’s an oligopoly/monopoly that people are pretty much forced to use or rely upon. This in turn puts an enormous responsibility on those projects to actually do a good job, or they are basically squandering that mandate. They can hide behind the “it’s open source” fig leaf easily, when they absolutely shouldn’t.
Volunteer developers tend to get the worst of both: they are also subject to upstream changes, but don’t have the resources to provide similar maintenance downstream. It also doesn’t help that most people don’t think about why a volunteer dev is working on a particular project:
So you actually need to understand a fair amount about a project to know how to approach it.
Case in point, I had an exchange with a Chrome GPU dev who flippantly responded to a request with a dismissal that showed they had no idea what I was even talking about (misidentifying a 2009 feature as the latest and greatest tech). This person’s work will define what the entire web ecosystem will be able to do GPU-wise for the next decade at least. You should in fact give them an earful for that.
Ugh, this unlocked a relevant memory. I now recall asking Android developers why they did not reuse existing standard libraries like Cairo or Pixman when writing their graphics subsystem; their excuse at the time was bullshit and it was later revealed that Google ordered them to rewrite everything to avoid GPL (slides 36, 51). (Yes, I know Cairo/Pixman are MIT-licensed, but do they?) I also asked them whether they had armored their latest GPU-exporting API (“Native Client”, I think) against buffer-reuse attacks which exfiltrate data from GPUs, and their response was similar to the one that you describe. By avoiding software in the commons, Google made their product slower and less secure.
The worst part is that there’s nearly no way to contribute labor to make it better. I spent a few months working on Chromium OS and all I improved was one small chunk of graphics testing.
I don’t think you intended offense. I see you referred to Oss devs as “him” I know OSS devs that go by “her” and “they” and I don’t want to quietly erase their work. Can you use singular they in the future?
It’s kinda weird if you think about it. If you were to explain to a lay person that companies make a living by sticking together many “free gifts” and sell the result as a product, they might declare you mad.
Nothing else in the world works this way, AFAIK. I think this is also why we’re still struggling to make sense of the weird distributions of power and wealth surrounding FOSS, because there’s no analogue that fits well enough to adopt wholesale. You could say FOSS is an economic anomaly of sorts.
Many fields work somewhat like this, it’s just that usually the costs are different. Electronics is full of handy designs written down and distributed for free. Chemical engineering is full of handy reactions written down and distributed for free. Writing fiction is full of handy tropes written down and distributed for free. Creating and using these sorts of things are usually managed by copyrights and patents, and those are the cases where the patent system usually kinda sorta works like it’s supposed to. Lots of trivial BS gets patented, but it also does a halfway decent job of making sure that the people who put 8 or 9 figures into developing something can then get paid for it reliably.
The thing about software is that the cost to using/distributing/copying it is tiny, while in all those other fields you generally need to either physically buy and assemble components to use the design, or put in significant amounts of work massaging it into your own design, or both. So you have the fixed costs of designing and building A Thing, and then the variable costs of actually manufacturing and distributing it, and for software the variable costs are miniscule because it’s just copying around bytes. So while designing and building software is just as much work as designing and building anything else, actually “manufacturing” and transporting it is so, so cheap that you might as well give it away. Even companies routinely give away fairly large amounts of storage and bandwidth, as seen by the free tiers of Cloudflare, Github, and all sorts of other things. On the flip side there’s a number of open source hardware projects of one kind or another that happily give away schematics for free, but also just straight-up sell manufactured parts as well. Sure I could manufacture my own Pinebook Pro mainboard from the designs if I really wanted to, but it would be a metric shitload of work to just find and get all the parts, let alone assemble it. In comparison, I can download and build the firmware for said board in about three minutes.
There’s other things that go into this. Anyone can write software of arbitrarily high quality by sitting down with some relatively cheap tools and getting to work. I don’t think there will ever be a gift economy in, say, 100 ton mining trucks, because while many people can forge and weld steel in their garages, most of those hobbyists don’t have the space or tools to build machines the size of a house. I don’t think there will ever be a (large) gift economy in hand-made woodworking art either, ‘cause those things basically can’t be replicated efficiently – once you start scaling up production it ceases to be hand-made, so there’s no economy of scale to take advantage of. In comparison, I would need very, very little physical infrastructure to sit down and write the next curl or sqlite or ninja.
This is changing! I can go to Shapeways or some other 3D printing design repo and, indeed, stick together many “free gifts” and sell the result as a product. And, frankly, there are already plenty of companies that sell products that they don’t manufacture, they just do the “value add” of things like retail distribution, customer support, etc so that the manufacturer doesn’t have to.
So yeah. There’s nothing fundamentally different about software compared to any other artifact made by humans. The difference is all in the costs to different parts of the process of building and distributing it.
I’d argue our equivalent to such things is algorithms and design patterns, rather than ready-to-reuse code. These are covered by software patents (ugh) and sometimes copyright, as well. The “copy and reuse” in writing is perhaps more like fairy tales and such that get repeated verbatim and tweaked here and there. But there the origins are lost in the mist of time, such that there’s no one clear author and if there was, they’d be long deceased by now anyway.
The key difference is that reactions and circuit designs need no ongoing maintenance to remain useful.
Chemical reactions also make a very poor analogy because simply knowing a reaction is just the beginning of the beginning of the process. Development of equipment for conducting that reaction at a commercially viable scale is a whole different problem.
That’s why I equated them to algorithms and design patterns, which don’t need any maintenance either. They’re a high-level description of how to do things, without actually implementing the thing in a concrete language.
Actually I think you’re a little wrong that nothing works anything like this. The NGO sector works at least something like this.
It’s not that uncommon - especially in some non-western cultures, especially historically- for exchanges of gifts to result in loosely defined reciprocal relationships. Similarly, the trope in business circles is that in Japan contracts are much more flexible than in the west.
I do agree that this is something very odd in our current culture, and definitely a sign that our culture needs to change.
It is worth noting that that anomaly is not an accident. The Free Software Foundation and associated parties were enacting their ideology from the start, part of which was economic in nature. That history gets forgotten a lot today, because frankly the people who felt most strongly about it weren’t good at communicating those ideals, but it was there from the outset.
That’s a great point. I wonder how things would’ve been different if they had foreseen the current situation, and if FOSS would have become as popular as it has if they had chosen a different approach.
I mean, if you think about it, the ability to run almost any OS you like and still be able to work practically is a huge luxury. Twenty years ago, using Linux as a daily driver was like pulling teeth because there was just so much software you couldn’t run and file formats you couldn’t open. Mostly it was the web that made this possible though, the very thing that makes FOSS a paper tiger (excepting AGPL, but that’s not very popular).
If you had told people like RMS “in 40 years you will be able to run any software you like, which you can mostly inspect and modify as you wish, but you’ll mostly be using it as a viewscreen into other people’s computers running closed-off software you cannot even inspect”, I wonder how they’d respond.
Fascinating question. I don’t claim to know but it’s interesting to think about. My own take-away is mostly that the fight continues, a lot of ground has been won but there’s a lot yet to do.
I bet you’d be pissed if she gave you something that had a safety recall on it. From that point on, I think you’d be on notice that you can’t rely on her not to do that, and take appropriate steps to guard against that.
The article is arguing that it does mean that. It offers several arguments. You are just stating the opposite without addressing any of those arguments. What do you think your comment accomplishes?
I don’t think it argues any such thing, it just rests on the assumption that supply requires a relationship.
That’s not an assumption, but a stipulation about the word ‘supplier’ as it is used in the article. The entire point is that there are legal consequences to the relationship that they describe as ‘being a supplier’.
You seem to just be bluntly applying a dictionary definition of the word ‘supplier’. But the dictionary definition of the word is irrelevant here.
You can redefine any word to mean anything. Sure, under the author’s made up definition they’re not a supplier. Under the definition used by speakers of English in general, and especially people who talk about software supply chains, the author is a supplier.
Having clarified all of this about the word “supplier” has achieved nothing. The question is what kind of obligations, formal, informal, and legal, a person has if they make software available to other people, and what obligations the receivers have, in their capacity as both end users and as onward suppliers.
Which is irrelevant to the discussion.
That’s exactly what they are arguing they are not and you’re still just contradicting without engaging any of their arguments.
Yes, and that is exactly what they are addressing and you aren’t.
You may be a volunteer, and even a supplier, but you may be free to ignore any requests from those that you supply. Not because you’re volunteer, that’s irrelevant. Because you have no legal relationship with the people using your software.
That’s playing semantics a bit too much.
We can argue either way, but whatever you call oss maintainers, they ain’t getting paid to have the responsibilities that the “software supply chain” discourse kinda pins on them.
Ok but your comment is way more insightful than the whole article. That said, I think the analogy is helpful: if you receive a defective product that you’ve paid for, or is supplied for for a particular purpose, your remedy is against the one who supplied it to you, not the remoter parts of the supply chain.
We need to take seriously that our incoming supply chains are primarily made of software received for free and with no warranty of fitness for purpose. That doesn’t imply oss maintainers should be more responsible - it implies that their users need to take responsibility for how they source their input software, in the same way as people shopping for responsibly sourced foods.
At the same time, it helps us to think about what kind of non contractual obligations a supplier of goods or software might have. For example, even if you’re selling hammers, you probably should be held responsible if you knowingly supply hammers contaminated with anthrax. If you put out hammers with their component clearly and correctly described, and it is well known that there are limitations to the hammer head that will make it scuff things (say), is the hammer supplier responsible or the user for economic loss from hammer scuffs?
In the OSS context, knowingly distributing malware seems off, for example, but not obviously something that users should be able to assume won’t happen. Or what about open source software that is for a specific purpose regardless of what the licence says? If I distribute an oss software library known to run on specific medical hardware, and advertise that, and the software does something bad, can I completely disclaim any responsibility for foreseeable physical harm occasioned by using an affected device? And does the person who supplied the device to the end user have any responsibility? Are indemnity clauses in the licenses effective?
I think these are all worthy questions, and point to the final supplier of software being responsible for auditing their supply chain, and choosing to use software that can be patched to use patched libraries, and be able to rebuild their whole set of dependencies from source, or accept the consequences of being dependent on third party builds.
Incidentally, Amazon does have the ability to build all their OSS dependencies from source, and I assume that the big monorepo companies (Facebook, Google) have that ability. As an aside - if you don’t have that ability but you think you have a monorepo, I think you’re just a FAANG fanboy playing dress up.
Let’s remove the knowingly and change selling to giving away hammers for free. That’s a much more accurate analogy for OSS maintainers, and in that case, I don’t think the hammer giver is responsible for anything in anyway whatsoever.
Legally? Yes, 1000%. Why the everliving fuck did a manufacturer of medical devices put software in it that they didn’t fully audited? It doesn’t matter that I wrote the buggy code, I didn’t make a promise to patients that the device would work.
Now, ethically, that is shaky, specially the advertising bit. But honestly, do you see this happening, ever? Non-experts writing code for critical domains and advertising it and making money of it? I can’t think of s single example.
And to be clear, by critical I mean actually critical. Medicine, nuclear power, etc. Doesn’t matter how big your web SaaS is, if people don’t die when it fails, it ain’t critical.
Every time OSS maintainers bring up the fact that big corporations leech of their free work, people start whatabouting that maintainers have responsibilities too. It’s a valid conversation, but feels like when people say “What about Palestine?” when Jews are talking about antisemitism[^1]. Yeah, that’s fucked up, but it’s a different conversation, that has potentially nothing to do with the current one (lots of Jews disapprove of Israel’s government), and smells like an attempt at victim blaming.
[^1]: know I’m violating Goodwin’s law here, but it’s the best analogy that comes to mind.
Ok what if you’re giving away anthrax contaminated hammers recklessly - ie you could know if you did a normal level of diligence for a hammer supplier? Does that seem like something that should be free of liability?
I found a bunch of hammers in an abandoned lot, took them home, and put them in my front yard with a sign saying “free hammers”.
There is no normal level of due diligence that can be expected of me. I’m not a supplier of anything. I’m just giving away shit for free. Hell, I’m probably dying of anthrax myself, if you wanna push the analogy.
Flippancy aside, though: there absolutely are OSS maintainers that might fall more in the “actually somehow a supplier, even if the product is free” side of things, but:
I’ll give you that maybe, MAYBE, if you can PROVE malicious intent, and if the maintainer in question derives significant monetary and/or societal benefits from the software they maintain, and if the damage caused was significant, then MAYBE it would be valid to assign them legal liability.
But that never happened, ever, in the history of ever. And is still whataboutism, because that’s not the situation anyone is talking about (other than you). The article is not philosophizing about what set of rules should govern all possible relationships between OSS maintainers and the users of the software they maintain (which would be pointless, by the way: to much variance for a general case to exist). It’s talking about the here and now of how the majority of these relationships is happening.
But they’re not volunteers either. A volunteer is someone who forms an explicit relationship with an organization to provide effort and resources for the organization’s ends. A programmer who puts code online that an organization picks up and uses is not a volunteer for that organization.
All these words attempt to imply the existence of a relationship that does not exist.
Words are complex and have complex meanings, and the more common they are, the more meanings they have. It’s honestly mind boggling when people assume that a common word has one, and only one, narrow and exact definition.
Merriam-Webster seems to think your definition of volunteer is way to narrow, by the way (some irrelevant parts omitted for brevity):
I mean, the comment you are replying to has less legs to stand on than a snake, but your argument is almost worse.
No, if you’re giving away code for free you’re a volunteer.
Not everyone giving away something for free is a volunteer.
On the other hand a true volunteer (i.e. a person who works for an organization without being paid) is usually not allowed to give the products of this company (i.e. which includes his work) away for free.
Volunteer for what exactly? Just saying ‘volunteer’ doesn’t give anyone the obligation to do whatever you think they should do. Dictionary definition:
(New Oxford American Dictionary)
A person who publishes free software online can be said to be a volunteer for the enterprise or task of publishing free software. They cannot be said to be volunteering for the task of providing ongoing support and maintenance to any specific user for said software. Especially given that the software license clearly delineates that fact.
When you throw around words that try to place obligations on others, perhaps you should consider the words carefully.
Suppliers usually have contractual relationships with their customers. Just because someone uses open source software doesn’t mean there is a contractual relationship; e.g. GPL states “You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.” A user can therefore acquire and use an open source application or library without concluding a contract.
Acceptance of the offer to conclude the open source license agreement thus generally only occurs when the user wishes to make use of the special powers arising from an open source license. In the vast majority of cases, acceptance of the agreement is “implied”, i.e. by conclusive action. However, this does not impose any obligations on the developer, neither a delivery obligation nor a maintenance obligation, and certainly not an obligation for a certain functionality or quality. This is not what is meant by supplier or supply chain.
I wonder how far we can take the AS-IS disclaimer. Let’s say the manufacturer of some popular thermostat brand has an MIT-licensed dependency. One day the author is in a bad mood, so she decided to install a backdoor into her package which causes all thermostats to malfunction during an ice storm, freezing thousands to death. Of course, the thermostat company will be responsible for their negligence, but can the ill-intended author be held accountable for her murder?
Your scenario is highly ambiguous and liberal with definitions. I’m not a lawyer, but let me play one on TV. ;)
The code contains a backdoor — a piece of logic that allows an unauthorized person to take control of the device (over the Internet or otherwise). The developer puts one in hope that a thermostat manufacturer uses it, waits for an ice storm, then connects to vulnerable thermostats to cause them to malfunction. In that case, the developer is guilty of unlawful access and, if people die as a result, for homicide (but whether it’s going to be classified as murder is debatable and likely depends on many things[1]).
The code contains logic bomb — a piece of code that causes thermostats to malfunction under specific conditions.
If it’s possible to prove the intent, then the developer is quite likely to held liable, although exact charges will vary between jurisdictions. Something like this leaves little room for interpretation:
[1] In common law countries, there’s a distinction between murder and manslaughter. Civil law countries have similar distinctions — not all acts that cause people to die are equally culpable. I doubt that breaking a central heating pipe would be classified as murder even if people freeze to death, for example.
I’ve recently had some discussions with a lawyers on a similar topic. For software, at least in the US and Europe, the case law (or statute law in countries that don’t have a common law tradition) seems to indicate that a disclaimer of liability can be pretty much total. That’s largely irrelevant for your example because the intent would mean that this would typically be prosecuted is under computer misuse legislation, not product liability law. The place that this gets fun is in open source hardware because you typically can’t disclaim liability for physical goods. The lawyers that I’ve spoken to believe that open source hardware counts as free blueprints and so the liability for accidental flaws falls on the company that manufactures them and assembles them into products (they are required to pass validation and regulations and must explicitly have a contract indemnifying them if they want their suppliers to take liability) but there’s as-yet very little law (case or statute) around open source hardware.
Honestly, it’s interesting to me to see the discussion of “is this a supply chain” or “is this volunteerism?” I think software is an ecology, and there are various webs of relationships, from actual supply chains (formed via contracts) to extractives (used by taking value from something where you have minimal relationship to the originating source) to farmed resources (and just like actual farming, there are various levels of farming that work or don’t, and how resource intensive they are or aren’t). Just like viewing the “food chain” had to evolve into the “food web,” I think we need to move beyond linear views in terms of the way we compose and use software; likewise, just like ecosystems, we need to be better supportive of how and why we consume the things we do.
Similarly, just like we’ve had to admit that certain farming practices are too intensive for local soil, we also need to reflect on how and why we use the software we do, and at what cost. I’m not saying one side or the other is correct, but what I am saying is viewing it as one or the other is just one perspective to a complex interdependence chain and we risk collapse if we don’t understand the ways in which we are interacting with the systems we depend upon.
I sort of want to flesh this out more, but it does seem to me that we’ve been bumping up into this in multiple ways lately: from collapse (developer removes their packages for various reasons) to decay (developers don’t want to interact in certain ways) to monocultures (one giant developer takes over an ecosystem and things mainly run their way) to vulnerability (all the various ways in which we don’t actually understand what we’re running). Addressing this will be interesting, and will likely lead to the similar sorts of discourse as we’ve been seeing, since it is unlikely that we will actually figure out ways of sustaining things properly.
It’s a natural consequence of our weird timeline:
Too simple a timeline, but it does feel like companies just haven’t understood what they’re dealing with when communicating with FOSS maintainers.
The author’s distinction between “supply” and “provide” cannot survive outside the context of the license. Nor do I think it useful since “provider” is already being used to describe commercial relationships.
Security people seem to be using that phrase the most in software contexts. They need something that describes to non-technical audiences in one phrase the threat model in situations like the malware in node-ipc. Appreciated that “supply chain” is probably the wrong one because it implies a commercial relationship. What’s a better one?
Publisher.
Tbh it seems to imply a commercial relationship only to a vocal minority. I think you can’t avoid that some people will go to the ends of the earth to argue that it’s the wrong word.
Well said, and I couldn’t agree more. If I were writing this essay I would tie it to my own political views, but I think if anything it’s more powerful as a simple practical position like this. There is a core argument against “software supply chain” ideas that surely people from all over the free software and open source communities can agree on, even if we arrive at it for different reasons, and this essay is that core.