I am not a supplier(softwaremaxims.com)
softwaremaxims.com
I am not a supplier
https://www.softwaremaxims.com/blog/not-a-supplier
31 comments
As I said in a sibling comment[1]:
Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.
[1] https://news.ycombinator.com/item?id=34205659
Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.
[1] https://news.ycombinator.com/item?id=34205659
> Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false.
Of course you, or anyone, is entitled to ask anything of anyone, just as they are entitled to ignore or engage with you. There are no legal ramifications either way.
The article only makes sense if the requester _expects_ the maintainers to donate time and resources. In 15 years, I've not run into any manager/exec/dev that hits a transitive dependency issue in open source and then expects the maintainers to drop things to fix it. Everyone knows you either fork, patch or pay.
Obv. there will be maintainers who experience people expecting free work. The article is long-winded in saying: read the license, no warranty, if you want to pay, let's talk more.
Of course you, or anyone, is entitled to ask anything of anyone, just as they are entitled to ignore or engage with you. There are no legal ramifications either way.
The article only makes sense if the requester _expects_ the maintainers to donate time and resources. In 15 years, I've not run into any manager/exec/dev that hits a transitive dependency issue in open source and then expects the maintainers to drop things to fix it. Everyone knows you either fork, patch or pay.
Obv. there will be maintainers who experience people expecting free work. The article is long-winded in saying: read the license, no warranty, if you want to pay, let's talk more.
I mean. Talk to the SLSA framework and the growing mind share it has then.
Also all the thought leadership post out there.
"Log4j has to release better patch" and "how could they write this when obviously wrong" or "how could it stays this way so long" are regular problems.
Ask any open source maintainer. There is a reason we burn out so much.
Or talk of people describing leftpad or the anti Russian patches as "malicious actors".
I get where you come from, but the reality of the environment out there is that this behaviour is everywhere.
Also all the thought leadership post out there.
"Log4j has to release better patch" and "how could they write this when obviously wrong" or "how could it stays this way so long" are regular problems.
Ask any open source maintainer. There is a reason we burn out so much.
Or talk of people describing leftpad or the anti Russian patches as "malicious actors".
I get where you come from, but the reality of the environment out there is that this behaviour is everywhere.
Umm. I’d say that the Russian-disk-erasing changes are definitely malware.
Software that deliberately deletes the user’s data for no reason related to its immediate purpose, when the user in no way expects that to happen, is malware, open-source or not. And deploying it is an attack. Those are completely orthogonal. (Surely if I put an open-source Metasploit shell on your laptop you’ll have every reason to complain.) The Russian-desktop-file-creating changes are much milder but still on the PUA spectrum, somewhere around the ad-toolbar checkbox in the installer. (Better because not ads, worse because no checkbox.)
Should we object to an open-source maintainer abruptly making their program into malware? In court, per the license terms, no. In general? Probably. At least I can’t find a logical justification to simultaneously object to the Stylish sellout[1] and not object to the surprise anti-Russian changes. (Browser-extension distribution terms of service notwithstanding—I’m sure the NPM terms of service prohibit malware distribution somewhere.)
(Let’s agree not to talk about this as warfare, because acts of war by private, non-military actors—from countries other than those directly participating in the conflict—against a population that is certain to include civilian targets to an extent serving no direct military purpose... I could see that, but obviously it’s a huge can of worms, and besides that’s not the argument the “protestware” authors made.)
Should we object to an open-source maintainer sabotaging their own software, like in the left-pad case? Presumably we shouldn’t to them just giving up or abandoning their website, so this becomes a bit trickier. I still lean towards “yes”. If I am a jerk, I don’t cease being one even if I stick a note with MAY SCREAM OBSCENITIES AT YOU FOR NO REASON on my forehead, at all, let alone in a world where most people walk around with those. But I can imagine being convinced otherwise.
(I want such a note now.)
[1] https://robertheaton.com/2018/08/16/stylish-is-back-and-you-...
Software that deliberately deletes the user’s data for no reason related to its immediate purpose, when the user in no way expects that to happen, is malware, open-source or not. And deploying it is an attack. Those are completely orthogonal. (Surely if I put an open-source Metasploit shell on your laptop you’ll have every reason to complain.) The Russian-desktop-file-creating changes are much milder but still on the PUA spectrum, somewhere around the ad-toolbar checkbox in the installer. (Better because not ads, worse because no checkbox.)
Should we object to an open-source maintainer abruptly making their program into malware? In court, per the license terms, no. In general? Probably. At least I can’t find a logical justification to simultaneously object to the Stylish sellout[1] and not object to the surprise anti-Russian changes. (Browser-extension distribution terms of service notwithstanding—I’m sure the NPM terms of service prohibit malware distribution somewhere.)
(Let’s agree not to talk about this as warfare, because acts of war by private, non-military actors—from countries other than those directly participating in the conflict—against a population that is certain to include civilian targets to an extent serving no direct military purpose... I could see that, but obviously it’s a huge can of worms, and besides that’s not the argument the “protestware” authors made.)
Should we object to an open-source maintainer sabotaging their own software, like in the left-pad case? Presumably we shouldn’t to them just giving up or abandoning their website, so this becomes a bit trickier. I still lean towards “yes”. If I am a jerk, I don’t cease being one even if I stick a note with MAY SCREAM OBSCENITIES AT YOU FOR NO REASON on my forehead, at all, let alone in a world where most people walk around with those. But I can imagine being convinced otherwise.
(I want such a note now.)
[1] https://robertheaton.com/2018/08/16/stylish-is-back-and-you-...
Using other terms than “software supply chain security”—for example, “open-source ecosystem security”—could benefit status quo, even if (or especially if?) the recipient of the language is internal management.
In the first case the problem is “I have subpar suppliers with poor security and I need to work around that”, in the latter case it’s “I build upon works that were voluntarily made available, often by craftspeople with limited resources”.
It’s not a secret that words we use have associated baggage that colours our understanding of an issue even on unconscious level. Different connotations of the latter call for different, more humane attitude and perhaps provide an incentive to contribute, sponsor or donate—and vice-versa, using terminology from a world with transactional relationships to level with business types may in fact gradually infect our own outlook.
Sure, a different language might sound less familiar to them, but perhaps there is a good reason for that—the dynamics are different, so the feeling of familiarity is false anyway.
In the first case the problem is “I have subpar suppliers with poor security and I need to work around that”, in the latter case it’s “I build upon works that were voluntarily made available, often by craftspeople with limited resources”.
It’s not a secret that words we use have associated baggage that colours our understanding of an issue even on unconscious level. Different connotations of the latter call for different, more humane attitude and perhaps provide an incentive to contribute, sponsor or donate—and vice-versa, using terminology from a world with transactional relationships to level with business types may in fact gradually infect our own outlook.
Sure, a different language might sound less familiar to them, but perhaps there is a good reason for that—the dynamics are different, so the feeling of familiarity is false anyway.
But "software supply chain security" also encompasses proprietary dependencies. A game dev using a third-party engine still has to care about the security of that engine. Likewise for proprietary plugins to various programs. Likewise for all proprietary software used by the company (MS Office, etc). They're all part of that company's "software supply chain", even though they're not open-source.
So you seem to be making an argument in favour of applying the phrase “supply chain” to OSS just as you would apply it to proprietary dependencies you build upon, because it’s a framing that helps your business (even if it harms the OSS ecosystem, which is a point of mine you didn’t argue against).
But I don’t think it would help the business either, since it’s a false abstraction.
A supplier is expected to be holding themselves to certain standards—including literally, by way of ISO 31000 and similar. Your suppliers’ compliance with, say, risk management practices is what your risk management practices build upon: this is why you have procedures for choosing your suppliers.
Furthermore, there’s an important reason for transaction relationship and contracts in some form or shape to exist—of course, ultimately you are responsible to your customers; but if something really bad happens, it is quite handy to be able to legally demonstrate that (1) you have done your work picking a reliable partner (if they actually comply with certain standards, they at least must have managed to convince relevant auditors—and are probably liable to them for lying) and (2) there is a paper trail that codifies your relationship with that partner, who may not have upheld their part of the deal.
(Naturally, your compliance with risk management standards, having relevant contracts signed with your suppliers, etc. plays an important role in downstream partners’ willingness to work with you as a supplier: it’s turtles all the way down.)
With OSS, no one owes you anything and your business is the final supplier in the chain; and if there’s no chain in any meaningful sense, the phrase is actively misleading to business decision makers.
But I don’t think it would help the business either, since it’s a false abstraction.
A supplier is expected to be holding themselves to certain standards—including literally, by way of ISO 31000 and similar. Your suppliers’ compliance with, say, risk management practices is what your risk management practices build upon: this is why you have procedures for choosing your suppliers.
Furthermore, there’s an important reason for transaction relationship and contracts in some form or shape to exist—of course, ultimately you are responsible to your customers; but if something really bad happens, it is quite handy to be able to legally demonstrate that (1) you have done your work picking a reliable partner (if they actually comply with certain standards, they at least must have managed to convince relevant auditors—and are probably liable to them for lying) and (2) there is a paper trail that codifies your relationship with that partner, who may not have upheld their part of the deal.
(Naturally, your compliance with risk management standards, having relevant contracts signed with your suppliers, etc. plays an important role in downstream partners’ willingness to work with you as a supplier: it’s turtles all the way down.)
With OSS, no one owes you anything and your business is the final supplier in the chain; and if there’s no chain in any meaningful sense, the phrase is actively misleading to business decision makers.
> The 90% case for me, when I bring up this term in a software security discussion, is that I’m trying to impress upon an engineering manager that if they choose to use software that they didn’t write, that THEY own it from a security perspective.
Using the terms software supply chain security to point out that no supplier exist to work with or blame, seems fair enough.
Using the terms software supply chain security to point out that no supplier exist to work with or blame, seems fair enough.
If a good acronym is what we need, why not Outsourced For Free, or OFF-ware? ;)
You are a huge part of the problem the author is trying to articulate. Re read the authors last paragraph. Your answer are your bs security monitoring tools. Let me guess, the chart is all red and riddled with exemptions? Nice work.
> will evoke specific concepts in the people I work with
So you're aware the FOSS developers are not suppliers but feel comfortable to explain it to management in a way that clearly makes them responsible so they're able to understand what exactly? That their developers outsourced the hard to implement libraries to unpaid volunteers and only handle the mostly trivial business logic?
The term was most definitely coined to offload responsibility in big enterprise. The uncomfortable reality is that productivity would take a nosedive without using these FOSS libraries/tools, but nobody wants to admit that this comes with risks (even though they're way smaller then implementing it yourself, probably). I'd agree that it's a complicated issue, but maybe using terms management is comfortable with isn't a good idea either if their meaning didn't actually apply at all.
So you're aware the FOSS developers are not suppliers but feel comfortable to explain it to management in a way that clearly makes them responsible so they're able to understand what exactly? That their developers outsourced the hard to implement libraries to unpaid volunteers and only handle the mostly trivial business logic?
The term was most definitely coined to offload responsibility in big enterprise. The uncomfortable reality is that productivity would take a nosedive without using these FOSS libraries/tools, but nobody wants to admit that this comes with risks (even though they're way smaller then implementing it yourself, probably). I'd agree that it's a complicated issue, but maybe using terms management is comfortable with isn't a good idea either if their meaning didn't actually apply at all.
Agree completely with the author.
Even in the situations where there is a supplier-buyer relationship there is the maxim of caveat emptor, subject to terms of an explicit commercial contract.
It is 100% the responsibility of the user of a library or FOSS artefact to do their due diligence before adding it as a dependency in their project.
It is bonkers to demand the developer of an open source library to dance to my tune just because I am using their library gratis. It is open source! Create a pull request, fix the bug (or add the enhancement), compile, test and write to the devs with your solution, if you really care. People sitting on their pedestal and whining solves nothing (for themselves or the community).
I am just thankful there are so many people who work for providing high quality FOSS software. Donate (or support those projects in other ways) if you are able to do so. Don't just be an entitled jerk.
Even in the situations where there is a supplier-buyer relationship there is the maxim of caveat emptor, subject to terms of an explicit commercial contract.
It is 100% the responsibility of the user of a library or FOSS artefact to do their due diligence before adding it as a dependency in their project.
It is bonkers to demand the developer of an open source library to dance to my tune just because I am using their library gratis. It is open source! Create a pull request, fix the bug (or add the enhancement), compile, test and write to the devs with your solution, if you really care. People sitting on their pedestal and whining solves nothing (for themselves or the community).
I am just thankful there are so many people who work for providing high quality FOSS software. Donate (or support those projects in other ways) if you are able to do so. Don't just be an entitled jerk.
The problem everyone who cares is wrestling with is that software teams in practice do no diligence at all.
I agree. What used to be called Build vs. Buy decision usually involved a calculation of costs. There are lifetime costs involved in both choices. If a dev team chose to use a FOSS library/product (pr even a commercial 3rd party library), that analysis isnt complete without an assessment of practices needed for maintaining it over the entire lifecycle of the product they are building.
On the oft cited example of the FOSS developer who decided to delete their library/introduce a deliberate bug, the teams that were impacted had missed the step of validating and testing every minor version in their integration test environment.
They should have also checked in the sources of all their dependencies to ensure a reproducible reliable build. If it was a commercial 3rd party library, it was quite common some decades ago for the customer to pay additional to secure the source code in software escrow, to protect against the smaller supplier shutting down/going out of business. FOSS gave a better alternative by sharing sourcecode freely so that this mechanism of paid software escrow becomes redundant and the user can directly use the source for any purpose they see fit.
Failing to adopt these basics and complaining about what an independent developer should/shouldn't do sounds lazy.
Fundamentally, this boils down to trust in the underlying assets and degradation of serious engineering practices. There are no easy shortcuts.
On the oft cited example of the FOSS developer who decided to delete their library/introduce a deliberate bug, the teams that were impacted had missed the step of validating and testing every minor version in their integration test environment.
They should have also checked in the sources of all their dependencies to ensure a reproducible reliable build. If it was a commercial 3rd party library, it was quite common some decades ago for the customer to pay additional to secure the source code in software escrow, to protect against the smaller supplier shutting down/going out of business. FOSS gave a better alternative by sharing sourcecode freely so that this mechanism of paid software escrow becomes redundant and the user can directly use the source for any purpose they see fit.
Failing to adopt these basics and complaining about what an independent developer should/shouldn't do sounds lazy.
Fundamentally, this boils down to trust in the underlying assets and degradation of serious engineering practices. There are no easy shortcuts.
As a maintainer of open source libraries, the steps I've been asked to take to secure the supply chain are:
* Signing releases (requested by linux distributions)
* Signing commits (actually I don't think anyone actually asked me to do that)
* Authenticating myself with a physical security key. (requested by PyPI)
I found these things easy to automate and they seemed worthwhile to do, and so I don't resent doing them. My sense is that these things are being gradually built in to tools and will become the default without any effort on the part of library maintainers.
So hopefully you'll allow me to sneak in another point! Open source licences create relationships that in political theory would be called anarchism. In software anarchy, anyone's allowed to do anything (or not do anything) they like with their copy of the code. Software is what economists call a non-rivalrous good (ie, multiple people can enjoy it without affecting each other). Anarchy works well with non-rivalrous goods. In contrast, businesses are built around rivalrous goods (ie if you have it, I can't have it), and in this world anarchy doesn't work, and you have to view things through contracts and money.
I think I'll stop there :-)
* Signing releases (requested by linux distributions)
* Signing commits (actually I don't think anyone actually asked me to do that)
* Authenticating myself with a physical security key. (requested by PyPI)
I found these things easy to automate and they seemed worthwhile to do, and so I don't resent doing them. My sense is that these things are being gradually built in to tools and will become the default without any effort on the part of library maintainers.
So hopefully you'll allow me to sneak in another point! Open source licences create relationships that in political theory would be called anarchism. In software anarchy, anyone's allowed to do anything (or not do anything) they like with their copy of the code. Software is what economists call a non-rivalrous good (ie, multiple people can enjoy it without affecting each other). Anarchy works well with non-rivalrous goods. In contrast, businesses are built around rivalrous goods (ie if you have it, I can't have it), and in this world anarchy doesn't work, and you have to view things through contracts and money.
I think I'll stop there :-)
> Authenticating myself with a physical security key. (requested by PyPI)
Is that only for some packages? I publish a few obscure ones (not widely used) and get away with just a password.
Is that only for some packages? I publish a few obscure ones (not widely used) and get away with just a password.
Top 1% get them for free and have to use them from my undrstanding: https://portswigger.net/daily-swig/pypi-repo-to-distribute-4...
What if the maintainers just say no?
Well, PyPI would be in a very bad place, because they can't force them to say "yes". But they've backed themselves into a corner by punishing people for making software that becomes popular. :/
As I recall it's mandatory.
I can see the package indexes becoming much more involved in supply chain issues. A bit like the app stores, where a considerable amount of vetting goes on.
I can see the package indexes becoming much more involved in supply chain issues. A bit like the app stores, where a considerable amount of vetting goes on.
That's an interesting idea!
A "vetted" package index that charges subscription and splits the revenue with package maintainers. In return, maintainers agree to jump through all the extra hoops and index maintainers do extra verification (but still no warranty except that the standard procedure is followed).
The same package can then be uploaded to the normal index (as it is now), but without these extra steps, and no vetting.
A "vetted" package index that charges subscription and splits the revenue with package maintainers. In return, maintainers agree to jump through all the extra hoops and index maintainers do extra verification (but still no warranty except that the standard procedure is followed).
The same package can then be uploaded to the normal index (as it is now), but without these extra steps, and no vetting.
Interesting point indeed. It remembers me the Raymond’s “The Cathedral and the Bazaar” book.
As a consultant my work is ro take care of the software I produce and use.
I agree with the term "anarchy" as long as other people don't take my human rights away.
Some months ago after recoiling in horror from a vulnerability in rust I arrived at the grim realization that the "supply chain attack" problem is intractable in impure languages. When a transitive dependency can do anything it will inevitably do something. I don't expect to convert everyone (or anyone) to object capabilities and purity, but I do hope the experiences of the past year have put the fear of God into developers. We should aspire to build systems where a suddenly malicious or busted dependency can't knock over the whole tower.
Author here.
You do realise that the main source of dangerous vulnerability is low level infrastructure that do not come from these package managers ? The purity and capabilities sadly solve nothing when the source of the problem is the fact that NTP, OpenSSL, OpenSSH, the BGP daemon, the libc you run on, etc are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ?
Like i love capabilities and i would love to have more, but the basic problem here is that the low level that you totally depend on for the capabilities to work cannot even be funded to work.
Hell you do realise that Autoconf has not had a maintainer since 2012? If it was pwned and had injected backdoor in your software since then, we would have noone to fix it.
You do realise that the main source of dangerous vulnerability is low level infrastructure that do not come from these package managers ? The purity and capabilities sadly solve nothing when the source of the problem is the fact that NTP, OpenSSL, OpenSSH, the BGP daemon, the libc you run on, etc are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ?
Like i love capabilities and i would love to have more, but the basic problem here is that the low level that you totally depend on for the capabilities to work cannot even be funded to work.
Hell you do realise that Autoconf has not had a maintainer since 2012? If it was pwned and had injected backdoor in your software since then, we would have noone to fix it.
nonsense.
autoconf didn't have a core developer. But it had many distro package managers.
there's nobody adding code/fixing bugs, but there are plenty people reading and looking at diffs before packaging it in distros.
then the js libs have neither core maintainers nor anybody at npm corp that cares about security or reading anything.
the top comment is correct to care about those before system libraries.
autoconf didn't have a core developer. But it had many distro package managers.
there's nobody adding code/fixing bugs, but there are plenty people reading and looking at diffs before packaging it in distros.
then the js libs have neither core maintainers nor anybody at npm corp that cares about security or reading anything.
the top comment is correct to care about those before system libraries.
I don't agree. When there's a problem in OpenSSL, OpenSSH, or libc, nearly every company with an online presence has as freak-out and rushes to patch.
When there's a vulnerability or malware found in a python or npm package, 75% of the tech world does a quick audit (or not), shrugs, and goes on with their day.
When there's a vulnerability or malware found in a python or npm package, 75% of the tech world does a quick audit (or not), shrugs, and goes on with their day.
Why the weak words? "reading", "looking" is not "understanding".
IANADev, but surely if they were going as deep as understanding patches they'd practically be a project maintainer rather than a package maintainer. Expecting package maintainers to have even reviewed diffs seems like high expectations. I wouldn't expect them to do more than the actual packaging.
Weak words seem appropriate.
I've hacked together a couple of packages for personal use but didn't even go so far at to look what language the code was in. I'm assuming a lot of packages from ppa-s are produced in an automated way with no code review, and depending on your distro that might also be true of some principal libraries.
Weak words seem appropriate.
I've hacked together a couple of packages for personal use but didn't even go so far at to look what language the code was in. I'm assuming a lot of packages from ppa-s are produced in an automated way with no code review, and depending on your distro that might also be true of some principal libraries.
> NTP, OpenSSL, OpenSSH, the BGP daemon, the libc ... by people that can barely pay for their food
I think those used to be national or telco lab projects in 60s-80s. The values created are hard to exploit and to capitalize. Perhaps it's a policy problem.
I think those used to be national or telco lab projects in 60s-80s. The values created are hard to exploit and to capitalize. Perhaps it's a policy problem.
OpenSSL was at various times prior to 2014 maintained by a gamer guild, and by nobody.
Yeah, I think that's the most viable solution to this problem. The US federal govt should fund software projects that are widely used. It's good for our national security, and it facilitates economic growth.
This could either be grants to maintainers, grants to software nonprofits like linux foundation, or some kind of national software lab that employs people to maintain and audit open source software (or ideally, all of the above)
This could either be grants to maintainers, grants to software nonprofits like linux foundation, or some kind of national software lab that employs people to maintain and audit open source software (or ideally, all of the above)
They would not pay non-USA citizens, and the NSA would be asking for backdoors.
> when the source of the problem is the fact that NTP, OpenSSL, OpenSSH, the BGP daemon, the libc you run on, etc are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ?
My take: I suspect that (perhaps a majority) of us here have a distant and abstract understanding of long-term poverty (eg:hunger on the table for years at a stretch). I'd offer that even the memory of real poverty doesn't equate with presently living in a long state of active poverty.
Translating across that gap is hard.
note: I'm not socially critiquing HN here. I am opining that survivor bias may be in play, however.
My take: I suspect that (perhaps a majority) of us here have a distant and abstract understanding of long-term poverty (eg:hunger on the table for years at a stretch). I'd offer that even the memory of real poverty doesn't equate with presently living in a long state of active poverty.
Translating across that gap is hard.
note: I'm not socially critiquing HN here. I am opining that survivor bias may be in play, however.
> are all maintained and "fixed" and evolved by people that can barely pay for their food, even less for basic tests ?
I suspect many people working on OSS are getting paid, if not handsomely, then enough to survive.
I suspect many people working on OSS are getting paid, if not handsomely, then enough to survive.
I advise you to go read the Road and Bridges report i linked in the blogpost.
As of today, the reality is not at all. As I mentioned elsewhere there are zero maintainer of autoconf since 2012, even less one well paid.
Log4j devs took unpaid time off to fix it.
OpenSSL dev lived for years with less than 10k per year.
As of today, the reality is not at all. As I mentioned elsewhere there are zero maintainer of autoconf since 2012, even less one well paid.
Log4j devs took unpaid time off to fix it.
OpenSSL dev lived for years with less than 10k per year.
> there are zero maintainer of autoconf since 2012,
Paul's work doesn't count?
Paul's work doesn't count?
I would be surprised if they even get a thank you per 1,000 users.
Its not intractable. You just need to take the concept of a software supply chain seriously.
E.G, every version of every dependency you use (either directly or transitivly) needs to be audited and approved by a trusted supplier. This isn't nearly as bad as it sounds. You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. Maybe a second organization to cover people who don't trust the first.
The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure but no commercial interest in keeping their work proprietary. Since that infrastructure all runs the same software as the rest of industry, we all benefit.
E.G, every version of every dependency you use (either directly or transitivly) needs to be audited and approved by a trusted supplier. This isn't nearly as bad as it sounds. You only need 1 trusted organization across the entire industry to certify a baseline of trusted software. Maybe a second organization to cover people who don't trust the first.
The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure but no commercial interest in keeping their work proprietary. Since that infrastructure all runs the same software as the rest of industry, we all benefit.
> The NSA, some other part of US cyber command, or a comparable agency from a different government are all natural choices; as they have a vested interest in protecting critical domestic infrastructure
NSA is not a natural choice, since they are an active threat that has a history of abusing trust in their defensive mandate to insert vulnerabilities into systems in pursuit of their offensive mission.
NSA is not a natural choice, since they are an active threat that has a history of abusing trust in their defensive mandate to insert vulnerabilities into systems in pursuit of their offensive mission.
Then you can decide for your org to not trust them and perhaps use a different certifier. i would welcome them offering such a service instead of having none.
Trust like this is transitive, so I would not trust any organization that placed such blind faith in the NSA.
I hope your brave new world includes a requirement for orgs to disclose their software auditor, so my org can avoid trusting orgs like yours.
I hope your brave new world includes a requirement for orgs to disclose their software auditor, so my org can avoid trusting orgs like yours.
> You only need 1 trusted organization across the entire industry to certify a baseline of trusted software.
So it's not just bad, but impossible. Got it.
More to the point, software "auditing" does not work reliably against deliberately malicious code written by competent actors, never has, and never will. It's too easy to slip in subtle back doors that reviewers won't notice, and at the same time too hard to keep up with the review workload.
So it's not just bad, but impossible. Got it.
More to the point, software "auditing" does not work reliably against deliberately malicious code written by competent actors, never has, and never will. It's too easy to slip in subtle back doors that reviewers won't notice, and at the same time too hard to keep up with the review workload.
> The NSA, […has] a vested interest in protecting critical domestic infrastructure
One of the biggest cluster of cyber attacks ever, WannaCry, is attributed to NSA directly. They developed and sat on the exploit for 5 years, until it leaked, because even the NSA can be compromised. Government lives in a “we need good guys to have the biggest guns” Cold War-like mindset and are terrible role models for championing cyber security.
Auditing in general is primarily used as a tool to shift liability, or “ass-covering”, and sell a false sense of security by abusing information asymmetry. That said, there’s nothing wrong with auditing when deployed within a more informed and aligned incentive structure.
One of the biggest cluster of cyber attacks ever, WannaCry, is attributed to NSA directly. They developed and sat on the exploit for 5 years, until it leaked, because even the NSA can be compromised. Government lives in a “we need good guys to have the biggest guns” Cold War-like mindset and are terrible role models for championing cyber security.
Auditing in general is primarily used as a tool to shift liability, or “ass-covering”, and sell a false sense of security by abusing information asymmetry. That said, there’s nothing wrong with auditing when deployed within a more informed and aligned incentive structure.
I would suggest the Debian Project and similar distributions as a fairly good scaffold on which to build such a system. All it needs is a notarisation mechanism, so certify that a person has had eyes on the code and says that it is ok. Plus, I'd trust them more than the US government. Though there's no harm in having multiple bodies all certify a code-base.
> The NSA
Seriously? As soon as the NSA certifies a piece of code it'll be dropped like a hot potato by everyone outside of the US, and probably by a large percentage of the people inside it.
If such a body exists, which seems like a reasonable idea, it has to be nongovernmental and not controlled by large corporations either.
Seriously? As soon as the NSA certifies a piece of code it'll be dropped like a hot potato by everyone outside of the US, and probably by a large percentage of the people inside it.
If such a body exists, which seems like a reasonable idea, it has to be nongovernmental and not controlled by large corporations either.
This doesn’t make sense. The NSA has certified lots of crypto protocols that we use.
These days it seems those protocols are used in spite of NSA involvement. See what happened with Speck in the Linux kernel. https://lwn.net/Articles/761992/
Those also presumably have been checked, verified, and certified by many other governments, institutions, and independent mathematicians.
I'm not against the NSA, FSB, 3PLA, GCHQ or any other letter based agency certifying things. I'm saying they can't become the main official certifying body for FOSS because it simply won't be accepted by the FOSS community or by other world governments.
I'm not against the NSA, FSB, 3PLA, GCHQ or any other letter based agency certifying things. I'm saying they can't become the main official certifying body for FOSS because it simply won't be accepted by the FOSS community or by other world governments.
And if you has to be Russian or China government certified, all this protocols are out of question.
Software exists outside of USA.
I mean, I'm in Canada, friendly as it gets, and still - is NSA certifying a piece of software a good thing, from my perspective? From my company's perspective? From my Canadian sovereign government's perspective? There may be second order effects at play here.
I mean, I'm in Canada, friendly as it gets, and still - is NSA certifying a piece of software a good thing, from my perspective? From my company's perspective? From my Canadian sovereign government's perspective? There may be second order effects at play here.
NIST in consultations with various US public and private actors (including NSA) already determine the cryptographic algorithms that are used to run the internet. Canada is still very friendly with the US - the countries that have literally been bombed by the US - continue to use these algorithms.
Governments across the world have large gaps in their understanding of software and its relation to the world.
Governments across the world have large gaps in their understanding of software and its relation to the world.
You would be right if we were all running properly engineered hardware and software, but software engineering stopped being a subcategory of engineering 30+ years ago.
Software engineers are all blacksmiths, and software products equates to artisan made weapons. A food poisoning traced to a chef's knife from a workshop affects all users of the knife, but the impact is often localized to the shop and lessons learned are shared less as a scientific theory but more or less as an epic(see how "postmortems" are requested or written).
I predict that software supply chain concept will start working when software become a field of engineering, as in a single bit of error stops being the direct cause of a catastrophic failure(e.g. a web server bootloop), parts become replaceable(e.g. universal SATA host driver compiled against musl libc running just fine with glibc or proprietary Unix libc), so on and forth, maybe once anyone will be able to code or AI would start taking over us, or something - but at this moment where everyone touching software must be all manager-architect-manufacturer-user that knows where to put a chalk mark, even the idea of software "components" only barely work.
Software engineers are all blacksmiths, and software products equates to artisan made weapons. A food poisoning traced to a chef's knife from a workshop affects all users of the knife, but the impact is often localized to the shop and lessons learned are shared less as a scientific theory but more or less as an epic(see how "postmortems" are requested or written).
I predict that software supply chain concept will start working when software become a field of engineering, as in a single bit of error stops being the direct cause of a catastrophic failure(e.g. a web server bootloop), parts become replaceable(e.g. universal SATA host driver compiled against musl libc running just fine with glibc or proprietary Unix libc), so on and forth, maybe once anyone will be able to code or AI would start taking over us, or something - but at this moment where everyone touching software must be all manager-architect-manufacturer-user that knows where to put a chalk mark, even the idea of software "components" only barely work.
Ok, even if we could all agree on a single trusted auditor, that would still put us in a very bad position. You would be limited to only use that baseline trusted set of software, which I guarantee won’t be sufficient for all the things you need as software grows and develops.
> to certify a baseline of trusted software.
check how it works with FIPS for USA government. Out of date and you can't use a regular distribution because it doesn't use it, because it's expensive to get certified.
check how it works with FIPS for USA government. Out of date and you can't use a regular distribution because it doesn't use it, because it's expensive to get certified.
the current fragility of the "software supply chain" stems from package managers and their perverse economic incentives, and this is just as true for "pure languages". Vendoring and auditing dependencies greatly reduces the attack surface area.
Can you elaborate on the incentives of package managers? The problem I see with Rust is that it's just really easy to add dependebcies in a way that is difficult in C++.
I don't follow your point about purity. A dependency in a side-effect free language can't suddenly open a socket or access the file system. The attack surface is much smaller.
I don't follow your point about purity. A dependency in a side-effect free language can't suddenly open a socket or access the file system. The attack surface is much smaller.
Rust : Cargo :: Haskell : Hackage . It's extremely easy to add dependencies and that problem is independent of purity.
As an example of an "impure language" with security in the form you envision, Deno allows you to specify access controls on a per-script or per-dependency basis. You can specify imports that prevent dependencies from opening sockets or writing files or reading files.
Many years ago npm inc treated download and package counts as KPI. They pushed back against sensible measures like code signing, instead centralizing the ecosystem and encouraging cross-dependencies within their registry. A more security-oriented package manager would have focused on code signing and vendoring strategies.
As an example of an "impure language" with security in the form you envision, Deno allows you to specify access controls on a per-script or per-dependency basis. You can specify imports that prevent dependencies from opening sockets or writing files or reading files.
Many years ago npm inc treated download and package counts as KPI. They pushed back against sensible measures like code signing, instead centralizing the ecosystem and encouraging cross-dependencies within their registry. A more security-oriented package manager would have focused on code signing and vendoring strategies.
Haskell is largely pure. There's nothing in place to stop a dependency from putting unsafePerformIO on blast. If a dependency can only do pure functional computation then the worst things it can do are like (1+1=4) or diverge.
From your description it sounds like Deno is using object capabilities -- that's a great step forward.
> Many years ago npm inc treated download and package counts as KPI.
That's bonkers. I had no idea.
From your description it sounds like Deno is using object capabilities -- that's a great step forward.
> Many years ago npm inc treated download and package counts as KPI.
That's bonkers. I had no idea.
> There's nothing in place to stop a dependency from putting unsafePerformIO on blast.
import safe MyDependency
I believe GP misspoke; to my knowledge Deno does not allow you to set permissions on dependencies. It's not using object capabilities as far as I'm aware. I wish it were!
https://github.com/denoland/deno/issues/171
https://github.com/denoland/deno/issues/171
> A dependency in a side-effect free language can't suddenly open a socket or access the file system.
A dependency can exploit your system deliberately, not just with side effects. If you're not strictly pinning all of your dependency versions, one malicious update that makes it to the package manager can ruin your whole world.
Our package managers operate entirely on trust. Nobody is guaranteed to be checking to make sure some random package's maintainer isn't submitting malicious updates.
As a community we're all lazy and basically hope that somebody else is invested enough to check everyone else's work. In the case of OpenSSL, we've found that some projects become so complex that almost nobody does for long periods of time.
A dependency can exploit your system deliberately, not just with side effects. If you're not strictly pinning all of your dependency versions, one malicious update that makes it to the package manager can ruin your whole world.
Our package managers operate entirely on trust. Nobody is guaranteed to be checking to make sure some random package's maintainer isn't submitting malicious updates.
As a community we're all lazy and basically hope that somebody else is invested enough to check everyone else's work. In the case of OpenSSL, we've found that some projects become so complex that almost nobody does for long periods of time.
I think the thing that makes it more tractable in pure languages is that you at least get the chance to control the dependency's inputs and inspect all of its outputs, so it's theoretically possible to limit what it can do to you (depending on how you are using those outputs). I'm not saying it's usually practical, but it's at least conceivable. And there should be at least a few cases where it's actually practical.
In an impure language, it can do any random thing to any random part of the whole system and you won't even get the chance to know what it is doing.
Are there any truly pure package management systems out there, though?
Haskell has Safe Haskell, which more or less guarantees that the actual Haskell code compiled through the normal path is pure (but not that the code is total, and total under resource constraints, which you also need). The build system itself is not pure, though, so you have no guarantee that a dependency's build scripts don't put Evil Things into your program outside of the actual language framework.
Any others?
In an impure language, it can do any random thing to any random part of the whole system and you won't even get the chance to know what it is doing.
Are there any truly pure package management systems out there, though?
Haskell has Safe Haskell, which more or less guarantees that the actual Haskell code compiled through the normal path is pure (but not that the code is total, and total under resource constraints, which you also need). The build system itself is not pure, though, so you have no guarantee that a dependency's build scripts don't put Evil Things into your program outside of the actual language framework.
Any others?
It sounds like Safe Haskell might be getting deprecated soon [0]; it sounds like it isn't used much in practice...
[0]: https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
[0]: https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
> not just with side effects
I think you're using "side effects" in a colloquial sense while I'm using it in a PL sense.
Pure code is deterministic, operating only on its params. Impure code—code with side effects—is something that depends on state outside of its parameters.
I think you're using "side effects" in a colloquial sense while I'm using it in a PL sense.
Pure code is deterministic, operating only on its params. Impure code—code with side effects—is something that depends on state outside of its parameters.
> Our package managers operate entirely on trust
Cannot agree with this oversimplification.
Exists community. Yes, every human have his own motives, but many live in countries with effective law enforcement, and many people obey Western Values.
Also important, software is a chain with many parts, some parts of one chain could make really large disruptions, some are less significant.
So overall, real formula includes trust, humanity values, laws, government effectiveness and inertia of this chain.
Cannot agree with this oversimplification.
Exists community. Yes, every human have his own motives, but many live in countries with effective law enforcement, and many people obey Western Values.
Also important, software is a chain with many parts, some parts of one chain could make really large disruptions, some are less significant.
So overall, real formula includes trust, humanity values, laws, government effectiveness and inertia of this chain.
Functional purity is the wrong abstraction to ask for, and doesn't protect you as such (consider a Haskell library that, very purely, asks to write to ~/.bashrc).
Sandboxing modules is what you want, and that can be done with impure languages too. Sure, pure functional programming might make it easier, but as others pointed out, Safe Haskell and friends are very very far from mainstream.
Meanwhile, Firefox compiles some C/C++ dependencies into wasm, and runs them in sandboxes.
Sandboxing modules is what you want, and that can be done with impure languages too. Sure, pure functional programming might make it easier, but as others pointed out, Safe Haskell and friends are very very far from mainstream.
Meanwhile, Firefox compiles some C/C++ dependencies into wasm, and runs them in sandboxes.
Can you give some examples of such a pure language? Haskell is definitely not it, since you can always call unsafePerformIO anywhere to do anything. I would guess Idris has something similar, but maybe I'm wrong.
Also, if a dependency actually needs IO (either a networking library, or a DB library, or just for logging purposes), the guarantees you're talking about again go out the window.
And, moving to the more extreme scale, you can never be 100% sure that some dependency hasn't found a way to trick the compiler or runtime system into doing something it's not supposed to be possible to do, even if it consists of (ostensibly) pure code only.
Also, if a dependency actually needs IO (either a networking library, or a DB library, or just for logging purposes), the guarantees you're talking about again go out the window.
And, moving to the more extreme scale, you can never be 100% sure that some dependency hasn't found a way to trick the compiler or runtime system into doing something it's not supposed to be possible to do, even if it consists of (ostensibly) pure code only.
> Can you give some examples of such a pure language?
BPF and eBPF, though this feels unsatisfying.
BPF and eBPF, though this feels unsatisfying.
Hence why I check in vendor dependencies. It is wild to me that people pull fresh their dependencies on builds, trusting patch versions that really should have been major versions.
Vendoring is an option, but if you place some trust in your registry a lockfile is totally fine.
One analogy I've used a few times, with the suits:
Supported software is a purebred dog that you paid an American Kennel Club-registered dog breeder thousands of dollars for. You got pedigreed papers, a warranty against early development of problems such as hip dysplasia, and bragging rights about all the blue ribbons in your dog's family tree. But in the end, there is no guarantee that the dog will actually work out well as your family pet.
FOSS is a mutt that you got for free from the American Humane Society. The AHS promised that it's spay/neutered, up-to-date on its shots, and that their under-resourced veterinarian didn't notice any major problems in a real quick once-over. The mutt may actually have a better chance of working out as your family pet. But if you expect a purebred warranty, for a free mutt from the AHS, then people who know anything about dogs may start wondering about you.
Supported software is a purebred dog that you paid an American Kennel Club-registered dog breeder thousands of dollars for. You got pedigreed papers, a warranty against early development of problems such as hip dysplasia, and bragging rights about all the blue ribbons in your dog's family tree. But in the end, there is no guarantee that the dog will actually work out well as your family pet.
FOSS is a mutt that you got for free from the American Humane Society. The AHS promised that it's spay/neutered, up-to-date on its shots, and that their under-resourced veterinarian didn't notice any major problems in a real quick once-over. The mutt may actually have a better chance of working out as your family pet. But if you expect a purebred warranty, for a free mutt from the AHS, then people who know anything about dogs may start wondering about you.
My (least) favorite instance of this is in the response to the Log4j vulnerability. Evidently some companies tasked people with ensuring that ""all of their suppliers"" had patched the issue and were in compliance. This lead to random open source projects, many of which could not possibly be vulnerable, being inundated with form letters demanding that the project meet ABC Corp's new security requirements. Most maintainers told them to kick dirt, but it was truly bizarre seeing people think they were in any position to make demands over a project that they aren't paying for.
Makes me wonder who the hell is in a position to write such a letter, and how the hell they got to that position obviously being clueless about security and their relationship with open-source projects like that.
Plenty of people in the world simply comply with handed down corporate directives rather than start discussions internally.
Often it's scenarios like their unqualified boss who is the ceo's uncle's son may throw a fit somebody is challenging them.
Or there's some checklist nazis in charge.
Often it's scenarios like their unqualified boss who is the ceo's uncle's son may throw a fit somebody is challenging them.
Or there's some checklist nazis in charge.
I like the position of this author and think it's quite correct, but FWIW the logical conclusion if we pull the lever all the way over to this line of thinking is that in the modern era, the FOSS ecosystem has failed as a business model and companies will be better off developing their cores in-house (with all the opacity and lock-in that implies), and the pendulum swings again.
Fortunately, we need not pull the lever all the way in that direction. As with so many aspects of the open source ecosystem, the real most valuable element is trust.
Fortunately, we need not pull the lever all the way in that direction. As with so many aspects of the open source ecosystem, the real most valuable element is trust.
Author here.
The difference is that FOSS is not a business model. It is far closer to infrastructure, which is usually supported by other means than business models. Things like community structures for common goods (regularly called government but not always).
There is a different problem here, which I have chosen to not talk about here, but that is the problem of funding profitable software products. We simply... do not do that. We do not have the tools for that. But that is a different rant.
The difference is that FOSS is not a business model. It is far closer to infrastructure, which is usually supported by other means than business models. Things like community structures for common goods (regularly called government but not always).
There is a different problem here, which I have chosen to not talk about here, but that is the problem of funding profitable software products. We simply... do not do that. We do not have the tools for that. But that is a different rant.
> The difference is that FOSS is not a business model
FOSS can be part of a business model, but only if there are contracting parties who agree on the mutual obligations. If someone simply develops open source software and this is used by arbitrary people, essential prerequisites are missing for a contract to come into being. Instead, there are no obligations to the developer.
FOSS can be part of a business model, but only if there are contracting parties who agree on the mutual obligations. If someone simply develops open source software and this is used by arbitrary people, essential prerequisites are missing for a contract to come into being. Instead, there are no obligations to the developer.
"FOSS is infrastructure" and "FOSS maintainers are not suppliers" seem pretty at odds. It can't be both "infrastructure" and akin to a couch you dump in the trash (as in the example in your comment below).
FOSS as infrastructure doesn't mean every piece of FOSS is. And infrastructure can be incidental. While we're using analogies tortured beyond all meaning, a goat path in the forest is infrastructure if I ride my bicycle on it to get somewhere, but the goat herder was just herding their goats. If you want to rely on something (code, forest path, whatever), you should probably take steps to ensure the longevity and security of that thing, especially if you depend on it to make money. If I really need my goat/bicycle path, I could do path maintenance on it or try to get the government to do it, but complaining that I'm late for work because the goat herder didn't clear a fallen tree that their goats can jump over but I can't bike around is both foolish and obnoxious.
I'm more concerned about the goat herder intentionally dropping a tree on the path because he's having a bad day and wants it to be your problem too.
Perhaps it's a distinction without a difference. But if it happens a lot, you'd stop using that path.
Perhaps it's a distinction without a difference. But if it happens a lot, you'd stop using that path.
the road in front of your door are not a business model ;)
I am curious… what percentage of FOSS work for the most critical systems is done by people working for free verse people on a company payroll? I feel like most big FOSS projects have corporate sponsors.
Most big FOSS projects do have corporate sponsors, but what about their dependencies? And the dependencies of the dependencies? Eventually you end up with a situation like what you have with OpenSSL or NTP, where an obscure but important component is owned by someone who has a day job and can't properly look after it.
Nearly none for the really critical components. Even the one with sponsors do not make that much.
Typical example. Last year was the first time the curl project could pay for their website hosting vs the author paying it from his own pocket.
Curl.
Typical example. Last year was the first time the curl project could pay for their website hosting vs the author paying it from his own pocket.
Curl.
Agreed. What I'm thinking of specifically is the leftpad attack vector, where a trusted actor suddenly went malicious and broke the software many people were lying upon who didn't realize they were relying upon it (and weren't really in a position to be aware of the issues the author had encountered).
If that happens too much, corporations re-evaluate rush and costs and start developing things in isolation and in-house. But I expect leftpad will be a rare event.
If that happens too much, corporations re-evaluate rush and costs and start developing things in isolation and in-house. But I expect leftpad will be a rare event.
I would note that the trusted actor did not went malicious. He did exactly what he was entitled to.
If we follow the rules, the people that went malicious are all the trusted users and package repository that broke his intent. He was totally in the limits of his rights and the social contract of the licencing for FOSS.
The fact we present these maintainers as "going malicious" is exactly what i am ranting against in this post.
If we follow the rules, the people that went malicious are all the trusted users and package repository that broke his intent. He was totally in the limits of his rights and the social contract of the licencing for FOSS.
The fact we present these maintainers as "going malicious" is exactly what i am ranting against in this post.
If those are the rules, then the risk is too high for corporations to trust strangers, they shall have to stop using FOSS, the ecosystem collapses (because nobody can build on an untrustable system), and the FOSS experiment fails (in the sense we're back in the bad old days of closed software and while people can develop with FOSS, no same user would trust it for use). If my company has to be responsible for every line of code, we may as well own them.
I'd argue that he very much did break the social contract. Not the letter of the actual contract, but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively. That's the social contract that's the lifeblood of the movement, and if it breaks in the general case, the movement dies.
(There's a lot of things people can do that they're perfectly entitled to that would destroy ecosystems because they shatter expectations. Linus could sneak a very clever backdoor into Linux [hypothetically, perhaps not without collusion with multiple actors and a lot of prep work], and he wouldn't break the license but he would severely injure the project's reputation).
I'd argue that he very much did break the social contract. Not the letter of the actual contract, but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively. That's the social contract that's the lifeblood of the movement, and if it breaks in the general case, the movement dies.
(There's a lot of things people can do that they're perfectly entitled to that would destroy ecosystems because they shatter expectations. Linus could sneak a very clever backdoor into Linux [hypothetically, perhaps not without collusion with multiple actors and a lot of prep work], and he wouldn't break the license but he would severely injure the project's reputation).
> If those are the rules, then the risk is too high for corporations to trust strangers, they shall have to stop using FOSS, the ecosystem collapses (because nobody can build on an untrustable system), and the FOSS experiment fails (in the sense we're back in the bad old days of closed software and while people can develop with FOSS, no same user would trust it for use).
Well, yes.
There must always be someone you can drag onto the carpet (i.e., sue if it fails or goes rogue). Proprietary software gave you that, at least at the enterprise level. When Microsoft, IBM, et al. sold you software they were staking their professional reputation on that software and the associated support.
So yes, let's go back to proprietary -- when developers got paid and businesses got some assurance from the vendor that their stack wouldn't go rogue on them.
Well, yes.
There must always be someone you can drag onto the carpet (i.e., sue if it fails or goes rogue). Proprietary software gave you that, at least at the enterprise level. When Microsoft, IBM, et al. sold you software they were staking their professional reputation on that software and the associated support.
So yes, let's go back to proprietary -- when developers got paid and businesses got some assurance from the vendor that their stack wouldn't go rogue on them.
> If my company has to be responsible for every line of code, we may as well own them.
Good luck with that… your company has the skills to reimplement node?
> but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively
It's generally assumed they are in it to get screwed actively… but often that isn't the case.
> Linus could sneak a very clever backdoor into Linux
You are aware of a difference between writing a malware and deleting a project you own right?
Good luck with that… your company has the skills to reimplement node?
> but it's generally assumed FOSS developers aren't in it to screw consumers of their offerings actively
It's generally assumed they are in it to get screwed actively… but often that isn't the case.
> Linus could sneak a very clever backdoor into Linux
You are aware of a difference between writing a malware and deleting a project you own right?
> You are aware of a difference between writing a malware and deleting a project you own right?
You are quite correct; the npm ecosystem may be a special cade since it has been built on a huge amount of trust-assumption, and the real issue there was that trust model, not FOSS in general. Still, in that ecosystem, unpublishing a module unilaterally that so many systems relied upon was, at besst, negligent (morally not legally), showing a disregard for the concerns of those outside the fight with npm operators. In that context, the unpublish was more malicious than an adherence to the old "user beware" rule. Indeed, it would be hard for Linus to unpublish Linux, given the distributed nature of its hosting; unpublishing leftpad looks more like taking advantage of a mis-design in npm's package model to screw over thousands of third-parties.
You are quite correct; the npm ecosystem may be a special cade since it has been built on a huge amount of trust-assumption, and the real issue there was that trust model, not FOSS in general. Still, in that ecosystem, unpublishing a module unilaterally that so many systems relied upon was, at besst, negligent (morally not legally), showing a disregard for the concerns of those outside the fight with npm operators. In that context, the unpublish was more malicious than an adherence to the old "user beware" rule. Indeed, it would be hard for Linus to unpublish Linux, given the distributed nature of its hosting; unpublishing leftpad looks more like taking advantage of a mis-design in npm's package model to screw over thousands of third-parties.
The negligent part is relying on npm. If you want reliability then pay for it. Corporations crying about morality is just a smokescreen for them to avoid paying.
Most users of npm aren't corporations. They are individual developers or small operations taking advantage of a very clever ecosystem for distributed package management.
The leftpad stunt hurt everyone in that ecosystem. It was dropping a stink bomb at a party because the host had offended him, but everyone in the room got to suffer the consequences.
The leftpad stunt hurt everyone in that ecosystem. It was dropping a stink bomb at a party because the host had offended him, but everyone in the room got to suffer the consequences.
This software is provided 'as is'.
Noone built it as trust-assumption
We all chose to trust because it allows us to look at ourselves in the mirror every morning and forget the free work we are exploiting. The problem is us. Not npm.
Noone built it as trust-assumption
We all chose to trust because it allows us to look at ourselves in the mirror every morning and forget the free work we are exploiting. The problem is us. Not npm.
We chose to trust because it lets us all do more cool and useful things faster. All of us.
That's good! It's also necessary to operate at this scale, where any of us (not just corporations, but every hacker using a package manager) can operate with some minimum level of expectation that while packages might break from time to time, the breakage isn't malicious and everyone's incentives are aligned to minimize it and correct issues as quickly as found. Imagine what the ecosystem would look like if we couldn't make that assumption? The legal warranty allows for, say, Debian to start sneaking keyboard harvesters into the binary blobs that they publish alongside the source... What would happen to Debian users if they did? What would happen to the entire GNU/Linux desktop ecosystem if every package manager chose to do that?
If that trust were to break at scale (i.e. if stunts like leftpad's removal breaking everyone became common, or FOSS developers were to begin doing even more malicious things that the "as-is" legal providing technically allows)... We'd all do fewer cool and useful things, and companies with money would do more of them out of sight.
I don't think that's an improvement over what we have now.
So yes, the buck has always stopped with the last mile developer putting other people's software together into a solution. That is a necessary requirement to have an open source ecosystem at all in a legal environment that demands that blame be assignable somewhere. But if we all start acting like that legal constraint is the only behavioral constraint that matters, we don't actually get to have an open source ecosystem.
That's good! It's also necessary to operate at this scale, where any of us (not just corporations, but every hacker using a package manager) can operate with some minimum level of expectation that while packages might break from time to time, the breakage isn't malicious and everyone's incentives are aligned to minimize it and correct issues as quickly as found. Imagine what the ecosystem would look like if we couldn't make that assumption? The legal warranty allows for, say, Debian to start sneaking keyboard harvesters into the binary blobs that they publish alongside the source... What would happen to Debian users if they did? What would happen to the entire GNU/Linux desktop ecosystem if every package manager chose to do that?
If that trust were to break at scale (i.e. if stunts like leftpad's removal breaking everyone became common, or FOSS developers were to begin doing even more malicious things that the "as-is" legal providing technically allows)... We'd all do fewer cool and useful things, and companies with money would do more of them out of sight.
I don't think that's an improvement over what we have now.
So yes, the buck has always stopped with the last mile developer putting other people's software together into a solution. That is a necessary requirement to have an open source ecosystem at all in a legal environment that demands that blame be assignable somewhere. But if we all start acting like that legal constraint is the only behavioral constraint that matters, we don't actually get to have an open source ecosystem.
> We chose to trust because it lets us all do more cool and useful things faster. All of us.
Which is why I only use licenses from FSF: I want cool stuff I can use… I don't want my cool stuff to be used in cool stuff I can't use, or is used against me.
Anyway not inserting malware is not the same as "this is no longer maintained so I remove it to not be bugged about issues"
Which is why I only use licenses from FSF: I want cool stuff I can use… I don't want my cool stuff to be used in cool stuff I can't use, or is used against me.
Anyway not inserting malware is not the same as "this is no longer maintained so I remove it to not be bugged about issues"
It kind of did, as proven by subscriptions, SaaS and digital stores as means to be paid.
Which only works for products, not component libraries.
Which only works for products, not component libraries.
And yet that is the rules of the contract.
This software is provided 'as is'
This software is provided 'as is'
he just deleted his package, where he screw them?
Because the npm ecosystem pulls package dependencies automatically, deleting leftpad kicked a necessary brick out of the foundation of some hundred (thousand?) libraries, breaking all of them.
You could consider this a weakness in npm's design... Most package managers don't have the decentralization of authority that npm does. But if it is weakness in the design, it's a weakness that the leftpad author chose to exploit.
You could consider this a weakness in npm's design... Most package managers don't have the decentralization of authority that npm does. But if it is weakness in the design, it's a weakness that the leftpad author chose to exploit.
I don't know know, company told him fuck off, he deleted his package but more them company required.
I don't see how this position means FOSS would fail as a business model. It's not like anyone would be saying "we won't ever provide these guarantees." It's instead "if you just want to use my software without paying, go for it. But if you want any supply chain guarantees, then pay me for them."
Agreed; "as a business model" was a bad phrasing. I meant to say "as an alternative to the traditional closed-source business model."
If the FOSS ecosystem can't be safely built upon, companies have to build their own. If they have to build their own, they'll want to own it.
If the FOSS ecosystem can't be safely built upon, companies have to build their own. If they have to build their own, they'll want to own it.
Most of the most valuable software in the world (iOS, Play Services, Google Workspace, all the Nvidia libs enabling the AI revolution, Windows, Excel, GitHub, etc) is proprietary. It's easy to see the huge successes of f/oss and forget that it's only the tip of the value iceberg.
k8s and such tip the scales a bit, but there is still 10x more value locked up in proprietary software than with us software freedom zealots.
I will continue to release every piece of code I write into the public domain. I recognize however that the majority of people making valuable software do not share my ideology about the illegitimacy of the fiction that is "intellectual property".
k8s and such tip the scales a bit, but there is still 10x more value locked up in proprietary software than with us software freedom zealots.
I will continue to release every piece of code I write into the public domain. I recognize however that the majority of people making valuable software do not share my ideology about the illegitimacy of the fiction that is "intellectual property".
I strongly disagree. FOSS software is king when it comes to value provided (but not, obviously, revenue generated). All of those things you list incorporate free software (e.g., MIT licensed software, public domain software) or at a minimum rely on servers servers and infrastructure that do.
5 of the 7 things you listed would not exist in any recognizable form without having been built on top of open source software.
Doesn’t paid support to middlemen mitigate this problem? If Bigcorp pays Red Hat, Red Hat should fix the software and work with upstream to do so, thus making the fix Red Hat’s problem. Red Hat knows how to work with upstream to get fixes merged long-term.
Seems better we keep pretending it's ok. Let big stupid business build big stupid generally pointless stuff and hope they contribute back to the foundational open source stuff before they go out of business.
I don’t follow the author’s logic at all. Just because you don’t have a business relationship with the end user doesn’t make you not a supplier. If you make software available to others to use, you are supplying the software to them. You are therefore very clearly a supplier. Pretending words don’t have any meaning doesn’t help to resolve the problem.
The fact that you don’t have a business relationship changes the nature of your obligations to others - they are voluntary - and that in fact is at the heart of why software supply-chain is a problem. You have much more control over suppliers that you do have a business relationship with. As a community we have grown accustomed to moving at a pace that would not be supportable were it not for a network of volunteers around the globe maintaining and developing all manner of software and making it available as open source. It would be an enormous cost and reduce velocity significantly were that not the case, so I’m very greatful that they do this. During my career I have also made some small open source contributions myself. But that doesn’t make those people not suppliers.
The fact that you don’t have a business relationship changes the nature of your obligations to others - they are voluntary - and that in fact is at the heart of why software supply-chain is a problem. You have much more control over suppliers that you do have a business relationship with. As a community we have grown accustomed to moving at a pace that would not be supportable were it not for a network of volunteers around the globe maintaining and developing all manner of software and making it available as open source. It would be an enormous cost and reduce velocity significantly were that not the case, so I’m very greatful that they do this. During my career I have also made some small open source contributions myself. But that doesn’t make those people not suppliers.
I wanted to say that the title is being a bit too slick in using “supplier” instead of “member of your supply chain”, but then I realized while that’s true, it’s not really the point.
The point, as I read it, is that the your relationship's with an open-source maintainer as their downstream is very much unlike your relationship with any of your suppliers (or other suppliers, if you want to insist), because you haven’t negotiated a business relationship with them (and they may not necessarily even want one in the traditional sense). Thus it is, in fact, unhelpful to refer to them as “suppliers” in order to draw an analogy with your normal suppliers, because they can and will tell you to go take a hike if you treat them like one of those. And given the nature of open-source software and the amount of business leverage you have over them (none, if you go about it the way most commercial consumers of open-source code do), it’s not unreasonable of them to do so. (Distro maintainers, for example, need a very special set of social skills for handling ornery upstreams, even though they both receive more understanding for their demands, being volunteers themselves, and do actually have some leverage in the form of being the main form of getting your software in front of users.)
(This is the part where I disagree with the article: the important part is not that, legally, the usual license terms mean they can refuse to provide support; it’s that, socially, it’s not unreasonable of them to do so. Google and Facebook also have license terms like that, but people do argue it’s still bad of them.)
Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.
You’re free to disagree with any of this, to be clear, it’s just that you’ve said the article is only playing word games, while on my reading it does seem to have a point, as above.
The point, as I read it, is that the your relationship's with an open-source maintainer as their downstream is very much unlike your relationship with any of your suppliers (or other suppliers, if you want to insist), because you haven’t negotiated a business relationship with them (and they may not necessarily even want one in the traditional sense). Thus it is, in fact, unhelpful to refer to them as “suppliers” in order to draw an analogy with your normal suppliers, because they can and will tell you to go take a hike if you treat them like one of those. And given the nature of open-source software and the amount of business leverage you have over them (none, if you go about it the way most commercial consumers of open-source code do), it’s not unreasonable of them to do so. (Distro maintainers, for example, need a very special set of social skills for handling ornery upstreams, even though they both receive more understanding for their demands, being volunteers themselves, and do actually have some leverage in the form of being the main form of getting your software in front of users.)
(This is the part where I disagree with the article: the important part is not that, legally, the usual license terms mean they can refuse to provide support; it’s that, socially, it’s not unreasonable of them to do so. Google and Facebook also have license terms like that, but people do argue it’s still bad of them.)
Perhaps looking into the analogy the term “software supply chain” is intended to evoke is more helpful. One possibility, which is what most engineering users of it (among others) intend, is, indeed, that your open-source dependencies are your liability the same way as your traditional supply chain is, and that’s true. Another, which is what the article objects to, is that you are therefore entitled to ask anything of them, and that’s false. Given that the liability and the entitlement are two equally important and mutually supporting sides of the standard supplier relationship, there is reason to dislike the an analogy that is only correct in half of its implications.
You’re free to disagree with any of this, to be clear, it’s just that you’ve said the article is only playing word games, while on my reading it does seem to have a point, as above.
> the your relationship's with an open-source maintainer as their downstream is very much unlike your relationship with any of your suppliers
Hum... It's almost equal. For a start, you can demand anything that you have negotiated on, and can kick sand or try to pay outside if you want something else.
That's the point he author wants to talk about, but I don't think he has a good grasp of supplier - consumer relations.
Hum... It's almost equal. For a start, you can demand anything that you have negotiated on, and can kick sand or try to pay outside if you want something else.
That's the point he author wants to talk about, but I don't think he has a good grasp of supplier - consumer relations.
Huh. OK, that’s fair.
I guess a more precise phrasing would be: the relationship is indeed almost the same as far as the rules of engagement are concerned, but the default starting point is very different: with a conventional supplier you don’t (get to) start using their product in yours until after basic terms have been negotiated, almost necessarily including some kind of right to have the supplier fix their stuff if it’s broken in an obviously stupid way.
Open-source things, though, individual devs can and do just pick off the floor. (Not necessarily good from a security standpoint, but hinder that process too much and work slows down to an extent most businesses won’t be able to afford, much like with installing outside software.) Which means that if you find some in your codebase and treat the author as you would any baseline supplier[1], just because there’s no way you wouldn’t negotiated the corresponding terms, you rightly get called an arsehole. This pattern of problematic behaviour predates the “software supply chain” meme, I think, but the fact that the meme seems to justify it in the minds of some people is a reason to dislike this analogy. Even if, as I said before, the other, liability half of it is entirely true.
[1] https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir..., https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644#c8, and I’m sure I’ve seen more of those
I guess a more precise phrasing would be: the relationship is indeed almost the same as far as the rules of engagement are concerned, but the default starting point is very different: with a conventional supplier you don’t (get to) start using their product in yours until after basic terms have been negotiated, almost necessarily including some kind of right to have the supplier fix their stuff if it’s broken in an obviously stupid way.
Open-source things, though, individual devs can and do just pick off the floor. (Not necessarily good from a security standpoint, but hinder that process too much and work slows down to an extent most businesses won’t be able to afford, much like with installing outside software.) Which means that if you find some in your codebase and treat the author as you would any baseline supplier[1], just because there’s no way you wouldn’t negotiated the corresponding terms, you rightly get called an arsehole. This pattern of problematic behaviour predates the “software supply chain” meme, I think, but the fact that the meme seems to justify it in the minds of some people is a reason to dislike this analogy. Even if, as I said before, the other, liability half of it is entirely true.
[1] https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir..., https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644#c8, and I’m sure I’ve seen more of those
What do you expect from FOSS "suppliers"?
> What do you expect from FOSS "suppliers"?
That if it breaks I get to keep both pieces. Or I can fix it if I’m able.
What I don’t expect is for them to intentionally break things and/or just pull the rug out from underneath everyone because “they’re well within their rights”. Sometimes being a dick is just being a dick.
Too many people seem to think they have some right to make money by giving away their labor for free because people take them up on their offer of free labor. Don’t want to work for free then don’t work for free. Don’t want the richest corporations in the world using your software without contributing back then don’t offer it to them under a license where they can do this. Easy peasy.
That if it breaks I get to keep both pieces. Or I can fix it if I’m able.
What I don’t expect is for them to intentionally break things and/or just pull the rug out from underneath everyone because “they’re well within their rights”. Sometimes being a dick is just being a dick.
Too many people seem to think they have some right to make money by giving away their labor for free because people take them up on their offer of free labor. Don’t want to work for free then don’t work for free. Don’t want the richest corporations in the world using your software without contributing back then don’t offer it to them under a license where they can do this. Easy peasy.
> Too many people seem to think they have some right to make money by giving away their labor for free because people take them up on their offer of free labor.
Can you point to some specific examples?
Can you point to some specific examples?
Pretty much every article saying the FLOSS model is broken because someone builds a tool, releases it under a permissive license and isn’t sharing in the bounty of what the users create on top of it.
Like TFA.
Like TFA.
TFA does not say the FLOSS model is broken.
I completely agree with the primary point of the author, which i summarize as: don't ask me to meet your companies arbitrary requirements for code when we don't have a business relationship. Completely fair. However I don't think that is what software supply chain security is about.
When you look at something like SLSA (slsa.dev) it's more about internal build systems. You are pulling code and dependencies from somewhere, that is cool. Now that it is in your environment how do you validate it matches what the upstream provider has? How do you secure your build environment? How do you prevent the outputs of builds, stored internally, from being tampered with? The most popular strategy to date has been "hope" as in "hope is not a plan".
Where it sucks for OSS maintainers is you have companies coming in and continuing to try and apply hope internally and send prodding emails upstream to not rely on hope. That's bad and is not something worth OSS maintainers dealing with. Unless, you know, the company is offering money to do so.
When you look at something like SLSA (slsa.dev) it's more about internal build systems. You are pulling code and dependencies from somewhere, that is cool. Now that it is in your environment how do you validate it matches what the upstream provider has? How do you secure your build environment? How do you prevent the outputs of builds, stored internally, from being tampered with? The most popular strategy to date has been "hope" as in "hope is not a plan".
Where it sucks for OSS maintainers is you have companies coming in and continuing to try and apply hope internally and send prodding emails upstream to not rely on hope. That's bad and is not something worth OSS maintainers dealing with. Unless, you know, the company is offering money to do so.
So I went to check SLSA
Version Controlled: On the maintainer side
Verified History: On the maintainer side
Retained Indefinitely: Can be both
Two Person Reviewed: On the maintainer side
Scripted Build: On the maintainer side, could be both but not the current model
Build Service: Both i suppose
Build as code: On the maintainer side
Ephemeral env: User side
Isolated: Both
Parameterless: Both
Hermetic: Both but mostly maintainer
Reproducible: Maintainer side
Available: Could be discussed but maintainer
Authenticated: Maintainer
Service Generated: Both
Non-Falsifiable: both
Dependencies complete: Both
Security: Maintainer side
Access: Not applicable
Superusers: Both
Thank you for reading through it and summarizing. I disagree with your conclusion however.
It's not possible for someone to completely trace upstream dependencies in a SLSA compliant manner. No company can sanely expect that. What can be done is to say "we have some code from outside. How can we attribute it to upstream and make sure it has not been altered?" You can use signatures from the maintainers, version it, even reference a git commit. I don't think that anything additional from maintainers should be required, it's on the company to figure out how best to do so.
It's not possible for someone to completely trace upstream dependencies in a SLSA compliant manner. No company can sanely expect that. What can be done is to say "we have some code from outside. How can we attribute it to upstream and make sure it has not been altered?" You can use signatures from the maintainers, version it, even reference a git commit. I don't think that anything additional from maintainers should be required, it's on the company to figure out how best to do so.
I understand your point. But that is explicitly not the point the SLSA are making, nor any of the thought leadership on this.
The reality of opensource are totally absent in these discussions. Noone say the things you just said.
I understand why you think it should be obvious and how it is done, but that is simply not the reality out there.
The reality of opensource are totally absent in these discussions. Noone say the things you just said.
I understand why you think it should be obvious and how it is done, but that is simply not the reality out there.
As the founder of OpenFaaS, the author doesn't know how true this rings - given all the myriad enterprise users of the community edition/OSS code. Even with smaller projects like K3sup, where I've seen defence contractors have k3sup references in their codebases and issue comments, go on to ask for changes, yet publicly stating they've never used it.
We did pivot the business model in ~ 2019 to open core, and I've tried to apply that to future endeavours like inlets, with the latest "actuated" - self-hosted CI in microVMs - it's a SaaS, with no open source components.
The common retort from users is "when we're in production, we'll pay for support / sponsor the project" - this literally never happens.
I applaud the author for laying it out how it is - there is no business relationship, open source maintainers are not suppliers, but if you want us to become your suppliers, have procurement reach out. Because we may well be able to offer you a relationship that would be mutually beneficial.
We did pivot the business model in ~ 2019 to open core, and I've tried to apply that to future endeavours like inlets, with the latest "actuated" - self-hosted CI in microVMs - it's a SaaS, with no open source components.
The common retort from users is "when we're in production, we'll pay for support / sponsor the project" - this literally never happens.
I applaud the author for laying it out how it is - there is no business relationship, open source maintainers are not suppliers, but if you want us to become your suppliers, have procurement reach out. Because we may well be able to offer you a relationship that would be mutually beneficial.
Do You really want make money with OpenFaaS?
NPM needs a msg displayed in bold on every command that says “these packages may vanish at any time and may not even be what you’re expecting”. I think package managers presenting all packages as equally supported and vetted is part of the problem.
There is an unseen alignment of incentives. The typical FOSS dev community wants its project to be taken seriously. They anticipate competition with other FOSS projects which are commercially backed in many cases.
And "So-and-so Corp. couldn't do it without us" often proves a high standard of being taken seriously.
Examples of that (I think I saw a few earlier today) are all over the place, even here on HN.
The messaging idea is interesting but I wonder how wording like "may vanish at any time" would play into these software community goals of gaining qualitative legitimacy in the face of de facto intra-FOSS-world competition. It seems like a more creative method might be ideal.
But this is mostly true if commercial adoption is seen as a goal, and many projects make it clear that they 1) don't gaf about that and 2) are ready to negotiate a higher standard if the negotiated outcome suits their yet-to-be-communicated needs.
That's also not a very inviting model and it perpetuates a sort of harsh dichotomy around the issue of reliability and support in those cases.
It's really unfortunate because this dichotomy also makes FOSS seem less reliable from the business perspective on the outside, which isn't necessarily desired either.
And "So-and-so Corp. couldn't do it without us" often proves a high standard of being taken seriously.
Examples of that (I think I saw a few earlier today) are all over the place, even here on HN.
The messaging idea is interesting but I wonder how wording like "may vanish at any time" would play into these software community goals of gaining qualitative legitimacy in the face of de facto intra-FOSS-world competition. It seems like a more creative method might be ideal.
But this is mostly true if commercial adoption is seen as a goal, and many projects make it clear that they 1) don't gaf about that and 2) are ready to negotiate a higher standard if the negotiated outcome suits their yet-to-be-communicated needs.
That's also not a very inviting model and it perpetuates a sort of harsh dichotomy around the issue of reliability and support in those cases.
It's really unfortunate because this dichotomy also makes FOSS seem less reliable from the business perspective on the outside, which isn't necessarily desired either.
And the maintainer may change what the functions do randomly for any reason including they found it funny.
Most places I know that did node shit pulled their dependencies from an in-house Artifactory instance. Means no exotic libs -- or upgrades -- until you can get the new library or latest version vetted, at least in principle.
Remove node_modules from .gitignore (and make git handle doing that more
graceful!)
> So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code.
This got a genuine LOL from me. Bravo.
I'm going to repeat my principle on the software supply chain issue: the responsibility for software security and other maintenance rests on those who deploy it. Deployments are the loci of harm from bad software, not projects. Secondarily, the weight of that responsibility should depend on the level of harm resulting and the level of benefit its owner receives. Whatever rules and conventions emerge from this fiasco, it needs to allow people to write software for fun, and even deploy it for fun as long as the damage is contained. And the people paying for maintenance need to be the ones making money from it.
This got a genuine LOL from me. Bravo.
I'm going to repeat my principle on the software supply chain issue: the responsibility for software security and other maintenance rests on those who deploy it. Deployments are the loci of harm from bad software, not projects. Secondarily, the weight of that responsibility should depend on the level of harm resulting and the level of benefit its owner receives. Whatever rules and conventions emerge from this fiasco, it needs to allow people to write software for fun, and even deploy it for fun as long as the damage is contained. And the people paying for maintenance need to be the ones making money from it.
Yeah I always found it pretty funny how easily we add libraries at work. We do a lot of code review and ensure near-100% line coverage, and yet we don't hold libraries to any standard at all. You can just add libraries and nobody will bat an eyelash. I've peeked into the source code of many of these libraries to find that they're often questionably architected, untested, or otherwise just not up to the standard to which we hold our own code.
Author here.
Yeah a friend quipped that when i explained to them i was writing this post, and i asked them if i could shamelessly steal it and use it. They agreed. So i ran away with it.
Yeah a friend quipped that when i explained to them i was writing this post, and i asked them if i could shamelessly steal it and use it. They agreed. So i ran away with it.
It is a nice quip, but is it true?
I think Free code is quite unlike garbage, in that most Free software devs do somewhat hope their code will be useful or enjoyable to somebody, right?
Garbage is explicitly refuse, you don’t expect anyone will find it useful at all. The raccoons are a nuisance — we actually go to great lengths in some cases to make sure they can’t check out the garbage! People sifting through your garbage are probably up to no good.
I think is hard to make an analogy between Free software and a physical thing because most physical things are finite and can’t be copied for free.
Maybe Free software is more like a dance — you do your dance to for yourself, and to impress your friends maybe (or maybe as exercise, or some other motivation). You don’t mind if someone copies your dance. You might even help your friends learn it. But you clearly have no obligation to help strangers learn it, and no responsibility if they get hurt trying to do it.
I think Free code is quite unlike garbage, in that most Free software devs do somewhat hope their code will be useful or enjoyable to somebody, right?
Garbage is explicitly refuse, you don’t expect anyone will find it useful at all. The raccoons are a nuisance — we actually go to great lengths in some cases to make sure they can’t check out the garbage! People sifting through your garbage are probably up to no good.
I think is hard to make an analogy between Free software and a physical thing because most physical things are finite and can’t be copied for free.
Maybe Free software is more like a dance — you do your dance to for yourself, and to impress your friends maybe (or maybe as exercise, or some other motivation). You don’t mind if someone copies your dance. You might even help your friends learn it. But you clearly have no obligation to help strangers learn it, and no responsibility if they get hurt trying to do it.
[deleted]
Reminds me of this quote:
> "There’s no free lunch in this world unless you’re willing to run around to different dumpsters to get it."
-Stay SaaSy
> "There’s no free lunch in this world unless you’re willing to run around to different dumpsters to get it."
-Stay SaaSy
It's good they included the running around. It's easy to forget that you're not only eating garbage, you're working really hard for it.
[deleted]
Where ever possible if I use an open source lib in a product I download it and store it locally (inside corp) for build servers to grab or bundle it in with the code in the product repo.
There is zero reason why the build process needs to access any external domain.
And if there is a new lib version or a problem/bug (depending on severity) then the product is retested with the new version before going out the door.
Of course, I dont have to do web front end. That stuff just seems wrong
There is zero reason why the build process needs to access any external domain.
And if there is a new lib version or a problem/bug (depending on severity) then the product is retested with the new version before going out the door.
Of course, I dont have to do web front end. That stuff just seems wrong
Kudos to the author, really needed to be said. I really liked the bolts and “screwed” play on words. Great article.
As members of the tech community, we need to be careful of overwork and manipulation. I hold in high regard the numerous developers that maintain the libraries and packages that make my work possible. Unpaid labor is a huge problem in FOSS, people need to get paid.
Get paid, don’t work for free.
As members of the tech community, we need to be careful of overwork and manipulation. I hold in high regard the numerous developers that maintain the libraries and packages that make my work possible. Unpaid labor is a huge problem in FOSS, people need to get paid.
Get paid, don’t work for free.
I'm disagree with author, but must say, he talking about really important things.
Yes, in freedom world, one have freedoms and rights, to choose irresponsibility, coding just for fun, etc.
But right solution here, not to just think all same level of responsibility (or irresponsibility) but to consider right to irresponsibility, and just avoid to use code/data from irresponsible authors, if important.
So I think, nearest time will appear some responsible's list (or irresponsible, read more).
This is not easy, but, unfortunately, ALL MODERN WORLD built on reuse of ready made pieces of knowledge and technology. Share of reused pieces is huge. So we MUST make some database (accurate and actual), from which people could get info if some piece of software (data) is supported, or find supported alternatives.
Who will pay for such database is hard question, from my exp, looks like this will slowly evolve from local (private) initiatives, to once country level or EU/OON wide db(s).
Because, with current unknown state, risks extremely high. And other people also have rights and freedoms, and many of them making significant free contribution to overall wealth, so it is not honest to leave them without support at all.
Yes, in freedom world, one have freedoms and rights, to choose irresponsibility, coding just for fun, etc.
But right solution here, not to just think all same level of responsibility (or irresponsibility) but to consider right to irresponsibility, and just avoid to use code/data from irresponsible authors, if important.
So I think, nearest time will appear some responsible's list (or irresponsible, read more).
This is not easy, but, unfortunately, ALL MODERN WORLD built on reuse of ready made pieces of knowledge and technology. Share of reused pieces is huge. So we MUST make some database (accurate and actual), from which people could get info if some piece of software (data) is supported, or find supported alternatives.
Who will pay for such database is hard question, from my exp, looks like this will slowly evolve from local (private) initiatives, to once country level or EU/OON wide db(s).
Because, with current unknown state, risks extremely high. And other people also have rights and freedoms, and many of them making significant free contribution to overall wealth, so it is not honest to leave them without support at all.
It's a very correct article. But here is a question: I run a software company and we're ready to pay for the FOSS we use in our product. Is there a convenient standard way to pay all the 50+ maintainers without having to spend years drafting individual contracts with each of them from a clean slate?
I did mention it was hard to do isn't it.
The other comment is right, vut tidelift is limited. There are foundations that cover whole ecosystems that may be of use.
Other than that, no not really. It is infrastructure we have not built because it is easier to not pay than to think about it
The other comment is right, vut tidelift is limited. There are foundations that cover whole ecosystems that may be of use.
Other than that, no not really. It is infrastructure we have not built because it is easier to not pay than to think about it
Depending on the FOSS you use, yes. Eg, https://tidelift.com/ .
Is it more convenient to find commercial/proprietary vendors instead?
Or to use warranty-less software and pay for your own staff to track changes and be ready to maintain the software yourself?
Is it more convenient to find commercial/proprietary vendors instead?
Or to use warranty-less software and pay for your own staff to track changes and be ready to maintain the software yourself?
An interesting thought I had - maybe part of the problem is that certain project maintainers should not be packaging their software and simply release licensed source.
For example, if I make neat-thing library and give it an MIT license, maybe I should not necessarily care about publishing it to a package registry (or in extreme cases, even versioning it).
Let someone else become the supplier and productize it / support it / semantically version it. This sort of reminds me of how Linux distros operate (minus maybe the versioning part?).
In this case authors can minimize their sight line to work only directly with those packaging their software instead of a million different companies. And even in that case, they can easily tell the supplier they can submit a patch or fork it.
Presumably, the supplier/packager would be more of an organized entity and capable of creating a business model and having contracts with companies on one hand and authors on the other.
This is an interesting idea to me. I think if every author moved to source dumping instead it would greatly change the dynamic. If I want to use it, I have to package it myself or pay some third party to do it. That is fair, not crazy onerous in at least some cases, and gets me - as a consumer of that code - closer to it and more responsible for its use.
The supplier is then the first contact for security issues since they are delivering the software. They can fix it directly, upstream a patch, or try to convince the author to fix it.
The most successful suppliers will be the ones that submit the most patches because authors will find them easier to work with.
So my wild theory here is, if you have a super popular package, continue publishing the source and just totally stop publishing the artifact and see what happens. If it forks, I still see your package as being the upstream that everyone follows since it's actively being worked on. It will create an interesting situation where the delivery is split from the development.
For example, if I make neat-thing library and give it an MIT license, maybe I should not necessarily care about publishing it to a package registry (or in extreme cases, even versioning it).
Let someone else become the supplier and productize it / support it / semantically version it. This sort of reminds me of how Linux distros operate (minus maybe the versioning part?).
In this case authors can minimize their sight line to work only directly with those packaging their software instead of a million different companies. And even in that case, they can easily tell the supplier they can submit a patch or fork it.
Presumably, the supplier/packager would be more of an organized entity and capable of creating a business model and having contracts with companies on one hand and authors on the other.
This is an interesting idea to me. I think if every author moved to source dumping instead it would greatly change the dynamic. If I want to use it, I have to package it myself or pay some third party to do it. That is fair, not crazy onerous in at least some cases, and gets me - as a consumer of that code - closer to it and more responsible for its use.
The supplier is then the first contact for security issues since they are delivering the software. They can fix it directly, upstream a patch, or try to convince the author to fix it.
The most successful suppliers will be the ones that submit the most patches because authors will find them easier to work with.
So my wild theory here is, if you have a super popular package, continue publishing the source and just totally stop publishing the artifact and see what happens. If it forks, I still see your package as being the upstream that everyone follows since it's actively being worked on. It will create an interesting situation where the delivery is split from the development.
The reality has not shown that though. There are a lot of packaging mechanisms and all of them have even more problems getting paid.
I don't understand, this paperwork machine should be the inflection point we need to finally pay open source maintainers: want supply chain security ? Pay $Xk per year per form you want me to fill. Multiply this by every company and no open source maintainer that wants to go full time should need another day job.
What if I don't want to do full time open source ? Simple, pass these "form-filling" responsibilities to another friendly open source maintainer. No need to change licenses, ownership, etc.
What if I don't want to do full time open source ? Simple, pass these "form-filling" responsibilities to another friendly open source maintainer. No need to change licenses, ownership, etc.
"everyone depends on their particular bolt, and we are all screwed."
I love clever puns.
I love clever puns.
« provenance » would be a more accurate name than « supply », as it englobes both software that’s actually supplied, and software available « as is » that’s being picked up.
"you are a raccoon digging through dumpsters for free code" sounds like a great metaphor for inexperienced people using Copilot.
TL;DR:
> The fact you made your product depend on it is your responsibility. Not mine.
Yup.
> The fact you made your product depend on it is your responsibility. Not mine.
Yup.
This is one of those important articles that Will have me thinking years down the line. This article is howling into the void for change. Can we change now? Please??
Successful open source providers need to morph themselves into vendors, that is clear. The process needs to be low friction for all parties (subscription model). The article hints that the success of that transformation to vendor is governed by the supplyee being able to continuously drive change/quality requests down to the supplier to get what they need out of the code.
At first blush, I think: "to a package manager, attach: a credit card/subscription system, ticket tracker/change request system and the supplier's email/contact info". A system like that would mean, if you are a big megacorp, whenever one of your devs adds a package to their dependencies, and that package is from someone that wants to form a supplier relationship, the subscription request is automatically submitted to the accounting department for approval. Upon approval, money flows, and yucky details like seats and corporate rates can be negotiated by the accountants or legal. That would be an amazing improvement over the "labor of love" buy-me-a-coffee model we have today.
I think the grumbling begins in such a system where a package was free/unencumbered and it suddenly become a paid one. Kind of feels like a rugpull especially for supplyees that ARE poor and ARE only raccoons rummaging through trash. Perhaps there are rules of how to appropriately rugpull that need to be in-effect.
What I do not glean from the article is how money would necessarily transform an OSS developer into a supplier. Maybe the developer is an amateur supplier and will never get their shit together enough to truly meet the needs of the suppliee. Maybe they are a solo developer and die and leave the supplyee hanging.
The license and copyright I think necessarily need to preserve the AS-IS nature of the software itself due to the power imbalance between supplier and supplyee. But then how do we handle issues of negligence and impropriety on the part of a supplier?
In my mind it comes down to copyright. There has to be a socially acceptable weakening of copyright when a supplier turns bad or goes missing. Some arbiter (the package manager itself) can sever the subscription and give the supplier's copyright away so that it can find a new home.
Such a system ultimately becomes corrupt and the suppliers will get screwed out of their labor though. I can't see how such a system can be made to work in the long term and AS-IS is the best we can do. Le sigh.
Successful open source providers need to morph themselves into vendors, that is clear. The process needs to be low friction for all parties (subscription model). The article hints that the success of that transformation to vendor is governed by the supplyee being able to continuously drive change/quality requests down to the supplier to get what they need out of the code.
At first blush, I think: "to a package manager, attach: a credit card/subscription system, ticket tracker/change request system and the supplier's email/contact info". A system like that would mean, if you are a big megacorp, whenever one of your devs adds a package to their dependencies, and that package is from someone that wants to form a supplier relationship, the subscription request is automatically submitted to the accounting department for approval. Upon approval, money flows, and yucky details like seats and corporate rates can be negotiated by the accountants or legal. That would be an amazing improvement over the "labor of love" buy-me-a-coffee model we have today.
I think the grumbling begins in such a system where a package was free/unencumbered and it suddenly become a paid one. Kind of feels like a rugpull especially for supplyees that ARE poor and ARE only raccoons rummaging through trash. Perhaps there are rules of how to appropriately rugpull that need to be in-effect.
What I do not glean from the article is how money would necessarily transform an OSS developer into a supplier. Maybe the developer is an amateur supplier and will never get their shit together enough to truly meet the needs of the suppliee. Maybe they are a solo developer and die and leave the supplyee hanging.
The license and copyright I think necessarily need to preserve the AS-IS nature of the software itself due to the power imbalance between supplier and supplyee. But then how do we handle issues of negligence and impropriety on the part of a supplier?
In my mind it comes down to copyright. There has to be a socially acceptable weakening of copyright when a supplier turns bad or goes missing. Some arbiter (the package manager itself) can sever the subscription and give the supplier's copyright away so that it can find a new home.
Such a system ultimately becomes corrupt and the suppliers will get screwed out of their labor though. I can't see how such a system can be made to work in the long term and AS-IS is the best we can do. Le sigh.
I sponsor OSS software I depend on and you should too!
That's great but unfortunately you're the minority. 0.004% of users ends up giving something in my OSS project
Needed saying. Chapeau!
and I am not a rapper
Hard to believe this even needed to be said, yet the FOSS entitlement continues unabated to this day. The post a few days ago from the developer of curl was pointed example of how bad this has become.
https://daniel.haxx.se/blog/2022/12/30/an-m1-for-curl/
Perhaps something that's needed is suppliers you can pay to provide a warranty for open source, who share revenue with the relevant projects (with a corporate structure that guarantees this, some flavor of B corp). So I pay Foo, Foo pays Daniel, and Foo stays on top of curl's releases & makes sure that Daniel is getting the support he needs (putting out bounties or buying him a MacBook if he isn't) and that malicious code hasn't slipped into circulation.
I'm just spitballing, I'm skeptical this would work, but if it were attempted, something critical would be it being a partnership and not that the supplier becomes the boss of the open source projects.
I'm just spitballing, I'm skeptical this would work, but if it were attempted, something critical would be it being a partnership and not that the supplier becomes the boss of the open source projects.
This is basically what Tidelift does.
I personally think that the solution is more in line of something like https://sovereigntechfund.de/, where taxes pay for support of what is fundamentally infrastructure
I personally think that the solution is more in line of something like https://sovereigntechfund.de/, where taxes pay for support of what is fundamentally infrastructure
Ideally we'd have something like quadratic funding[0] as the means of choosing where to spend that fund, so that we get optimal contributions from private funds as well. In general, software should be treated like a public resource, since the marginal cost of distribution is ~0, and restricting distribution frequently requires a lot of effort.
[0]:https://vitalik.ca/general/2019/12/07/quadratic.html
[0]:https://vitalik.ca/general/2019/12/07/quadratic.html
While support contracts with RedHat/SuSE/etc do not go as far as take full liability, it is essentially their business model to take money from corps and funnel it into maintenance
That sounds more or less like Red Hat (I suppose now IBM). I don't entirely know the ecosystem, but I believe they give some money to the Keycloak project (which my company uses). I'm sure they sponsor others, but I assume the main contribution is developers - if you look at commits on the average project github, there's a good chance Red Hat will be well represented, and for core Linux components, they'll probably be at the top. Intel will also have a significant presence. Sun was big on this back in the day as well.
Warranty on software? I’m trying to say something profound but I keep uncontrollably laughing.
Probably gonna be unpopular but I feel like I got the opposite message: Apple is using FOSS in a completely normal, completely legal way. But some people in the comments were upset that Apple wasn’t voluntarily donating to the project. That feels like entitlement.
https://twitter.com/AppleSupport/status/1461330383425970180
> Thanks for contacting us. To get help with this issue, please reach out to Curl: https://curl.se/gethelp.html
The original tweet was deleted. If this were a bug report related to the system distribution of curl on M1 macOS (apple's proprietary platform), it seems somewhat entitled that Apple would pass the support burden to the curl author without providing resources to debug on their proprietary platform
> Thanks for contacting us. To get help with this issue, please reach out to Curl: https://curl.se/gethelp.html
The original tweet was deleted. If this were a bug report related to the system distribution of curl on M1 macOS (apple's proprietary platform), it seems somewhat entitled that Apple would pass the support burden to the curl author without providing resources to debug on their proprietary platform
The original tweet can be seen at https://web.archive.org/web/20211119123038/https://twitter.c...
It's hard to tell, but it sounds like the user had a question about how to use the `-E` flag.
Directing them to https://curl.se/gethelp.html seems... reasonable? The first link on that URL is to the curl-users mailing list, which seems like a reasonable venue for such a question.
It's hard to tell, but it sounds like the user had a question about how to use the `-E` flag.
Directing them to https://curl.se/gethelp.html seems... reasonable? The first link on that URL is to the curl-users mailing list, which seems like a reasonable venue for such a question.
If I publish a program to run on a Mac, Apple should give me resources for debugging issues?
If Apple includes your program as part of the software it sells along with the Mac, then Apple should be sending you well-tested pull requests for any problems its users find, not just giving you debugging resources.
Or fork the project and fix it themselves. I expect the software included in Windows as default to work correctly. I don't see any reason why that wouldn't apply to all products I buy like that.
If Apple is distributing free and open source software as part of the base operating system, certainly they should be taking on some of the support burden. This would be a different story if Apple wasn't shipping curl directly.
But isn’t there always a kind of quid pro quo in free software? It’s not as if Apple refuses to participate in the free software ecosystem. Doesn’t Apple also publish some important open source software?
Sure, Apple ships curl, and maybe doesn’t support it (are you sure? Don’t they build and test it from source on their own servers? Isn’t that a form of support?).
But Apple also ships and supports WebKit, which - as the original basis for Chromium - has arguably had a bigger impact on the world than curl has. And I suspect that Apple also contributed to some of the standards that curl relies on. Of course, Apple built WebKit as a fork of KHTML… but if memory serves, they didn’t have to make the fork open source.
I’m not trying to defend Apple in any way, I just think that the conversation can be a bit more sophisticated than just “big company ships free software and gives nothing back”. Apple has shipped some really cool open source software in the past, and I think it’s disingenuous to suggest that they owe something to every package that they ship. That is not really in the spirit of free software.
Sure, Apple ships curl, and maybe doesn’t support it (are you sure? Don’t they build and test it from source on their own servers? Isn’t that a form of support?).
But Apple also ships and supports WebKit, which - as the original basis for Chromium - has arguably had a bigger impact on the world than curl has. And I suspect that Apple also contributed to some of the standards that curl relies on. Of course, Apple built WebKit as a fork of KHTML… but if memory serves, they didn’t have to make the fork open source.
I’m not trying to defend Apple in any way, I just think that the conversation can be a bit more sophisticated than just “big company ships free software and gives nothing back”. Apple has shipped some really cool open source software in the past, and I think it’s disingenuous to suggest that they owe something to every package that they ship. That is not really in the spirit of free software.
LLVM is also pretty significant and they’ve supported that heavily.
Ah. I accept that argument. I feel that Apple is still acting perfectly legally and perhaps the solution is for developers to be clear about their expectations by way of licensing. But that’s often hard to do once the license ship has sailed and then your program becomes included in something like MacOS.
The gist of what rubs me the wrong way is that Apple is following curl’s license precisely and people are still unhappy.
The gist of what rubs me the wrong way is that Apple is following curl’s license precisely and people are still unhappy.
As a human being, it can be very useful to separate out “moral” behavior from “legal” behavior. Even if Apple or John Smith acts perfectly legally, that doesn’t mean they’re acting in a kind or good or well-intentioned or fair way. The law - no matter how comprehensive - can never legislate kindness. In fact, if you are sophisticated about it, you can be a world-class Greatest Of All Time A—-hole while still technically complying with every law in your jurisdiction.
> The gist of what rubs me the wrong way is that Apple is following curl’s license precisely and people are still unhappy.
I view Apple's behavior the same as I do people who leave their shopping carts loose in the parking lot instead of returning them to the corrals. Sure, they aren't legally required to provide any form of support to curl, but they would anyway if they had any decency.
I view Apple's behavior the same as I do people who leave their shopping carts loose in the parking lot instead of returning them to the corrals. Sure, they aren't legally required to provide any form of support to curl, but they would anyway if they had any decency.
There's plenty of room for being a dick without breaking a law.
what's legality got to do with decent society?
Yeah, they're the richest computer company in the world. It would be cool if they were more generous. That's all.
Isn't offering hardware donations for devs the opposite of entitlement?
[deleted]
tl;dr
I really like your blog theme though so I cut+pasted it into my own blog but there's some kind of css issue. I msg'd you details. Take a look when you can, hopefully soon, I have a big post going live tomorrow.
I really like your blog theme though so I cut+pasted it into my own blog but there's some kind of css issue. I msg'd you details. Take a look when you can, hopefully soon, I have a big post going live tomorrow.
Author here
Where did you message me ? I know i have all kind of problems with it but never had time to deal with it :D
Also the TL;DR is the title :)
Where did you message me ? I know i have all kind of problems with it but never had time to deal with it :D
Also the TL;DR is the title :)
lol I think they were giving a tl;dr by giving an analog to someone ripping off your css and expecting help from you. It's an example of how people who use your freely available software for their project behave. They come along, as you say, like a "raccoon digging through dumpsters for free code." But then they think they're entitled to think of you as a supplier and that you should provide support. That was the joke in "I have a big blog post going live tomorrow."
LOL this was my favorite comment
[deleted]
“I am not a supplier,” they say, while supplying things.
I agree with the fundamental points here. Expecting things like they describe out of open source volunteers is absurd.
But screaming “I am not a supplier” in this context is like yelling “I am not a driver” while driving a car.
I agree with the fundamental points here. Expecting things like they describe out of open source volunteers is absurd.
But screaming “I am not a supplier” in this context is like yelling “I am not a driver” while driving a car.
Author here. As pointed out in the end, in a different paraphrase.
If you take the sofa i left on the side of the curb to bring it home, i am not your supplier.
You found something for free in my trash. That does not make me your supplier. Me being your supplier mean we have a relationship that does not exist here.
If you take the sofa i left on the side of the curb to bring it home, i am not your supplier.
You found something for free in my trash. That does not make me your supplier. Me being your supplier mean we have a relationship that does not exist here.
The title of your article is “I am not a supplier,” not “I am not your supplier.”
And yes, you literally are a supplier if you are putting things out there for free, with no strings and no support, and others are taking them.
(The article is very nice otherwise and I agree with your points, just not the language)
And yes, you literally are a supplier if you are putting things out there for free, with no strings and no support, and others are taking them.
(The article is very nice otherwise and I agree with your points, just not the language)
Once again, if i leave my sofa on the curb, i am not a supplier. It may happen that someone pick it out. That does not change the fact i am not a supplier of sofas.
And yet, you keep coming into the new sofa owner’s house and fixing rips and adding embellishments…
I mean, the analogy sucks. But it’s worth considering that you’re doing more than just putting it into the ether.
I mean, the analogy sucks. But it’s worth considering that you’re doing more than just putting it into the ether.
No you come back for more improved sofas. Original sofa owner doesn’t even have to know who took it.
Analogy doesn’t suck, looking through “I’m entitled” lenses distorts the picture for you.
Analogy doesn’t suck, looking through “I’m entitled” lenses distorts the picture for you.
Sure. But few go whining back to the original coder when the code is abandoned.
It’s when the code is maintained, bugs are fixed, releases are put together, etc. that people start acting entitled.
A better analogy would be someone who opens a sofa depo, starts giving away “as-is” sofas, then starts building new sofas and improving them. Some people take those sofas and use them in rental homes. Then it turns out that someone planted listening devices in some of the sofas, so the landlords start showing up at the depo and asking questions about supply chain security…
It’s when the code is maintained, bugs are fixed, releases are put together, etc. that people start acting entitled.
A better analogy would be someone who opens a sofa depo, starts giving away “as-is” sofas, then starts building new sofas and improving them. Some people take those sofas and use them in rental homes. Then it turns out that someone planted listening devices in some of the sofas, so the landlords start showing up at the depo and asking questions about supply chain security…
> If you take the sofa i left on the side of the curb to bring it home, i am not your supplier.
Yes, you are. That you do so completely passively doesn't erase the fact that you are supplying something and that some kind of a relationship exists.
The law(s) generally also recognize it like that, and the license you are quoting does so as well ('_provided_ "AS IS"').
Sure, your relationship can be a completely passive non-business no-strings relationship, but the relationship is still there.
Yes, you are. That you do so completely passively doesn't erase the fact that you are supplying something and that some kind of a relationship exists.
The law(s) generally also recognize it like that, and the license you are quoting does so as well ('_provided_ "AS IS"').
Sure, your relationship can be a completely passive non-business no-strings relationship, but the relationship is still there.
More to the point, if you leave free sofas in a place where there is ~always one for someone to take if they want, you are a supplier.
To run with your analogy: It's like offering a near complete strange a lift because you're headed close to where they're headed. Then they start calling you asking for rides. And you say "I am not your driver."
See, it works perfectly fine.
See, it works perfectly fine.
Sure if the author had said “I’m not your supplier” rather than “I’m not a supplier.” Big difference.
No, not really, it's basically incidental, and actually points to the fact that, pertinently, the word "supplier" has a strong connotation of referring to a business relationship.
When a cop pulls you over, “I’m not your driver” is true, but “I’m not a driver” is false. I’d call the difference a lot more than “incidental”.
Yes, a completely different word, in a now conpletely divorced and radically different context, doesn't work exactly the same as the original word we are discussing. Well done.
In your new example, the phrase "your driver" does not refer to a business relationship, so I guess saying "I'm not your driver" to someone because you don't want to ferry them around is now also poor use of language? Just stop dude.
In your new example, the phrase "your driver" does not refer to a business relationship, so I guess saying "I'm not your driver" to someone because you don't want to ferry them around is now also poor use of language? Just stop dude.
The better analogy for “supplier” would be “chauffeur”, while the analogue for “driver” would be “developer”.
If you use those replacements in the analogy, then the analogy will work much better.
If you use those replacements in the analogy, then the analogy will work much better.
> But screaming “I am not a supplier” in this context is like yelling “I am not a driver” while driving a car.
Except driving is active. You must take acts to drive, it is a continuous commitment. There’s an expectation that if you’re on the highway driving someone they won’t jump out the window and let you crash. Ideally even they’ll get you where you wanna go.
Sharing some software for free is passive. You can share something and walk away. They can even die and the software is still shared. It’s a single action. Push publish, walk away. There may be an expectation of continued support, but it’s based on historic behavior not on actual commitments.
Entering a business relationship is active, and there should be an expectation of support (based on contracts of course).
Except driving is active. You must take acts to drive, it is a continuous commitment. There’s an expectation that if you’re on the highway driving someone they won’t jump out the window and let you crash. Ideally even they’ll get you where you wanna go.
Sharing some software for free is passive. You can share something and walk away. They can even die and the software is still shared. It’s a single action. Push publish, walk away. There may be an expectation of continued support, but it’s based on historic behavior not on actual commitments.
Entering a business relationship is active, and there should be an expectation of support (based on contracts of course).
> Sharing some software for free is passive.
Selecting a specific open source license and issuing releases and bug fixes is pretty far from “passive.”
Passive would be not putting the code software online and not inviting others to use it.
Selecting a specific open source license and issuing releases and bug fixes is pretty far from “passive.”
Passive would be not putting the code software online and not inviting others to use it.
> Selecting a specific open source license
Its a one-time action. Its "set and forget". That's pretty passive. Yes, you took a direct action, but its not an ongoing action.
> issuing releases and bug fixes
Again, after each fix, you're done. And to the original point, you're never committing to anything.
To repeat my original point, a maintainer could die and the software would still be shared, and the companies that use it would have the exact same relationship they had prior.
Its a one-time action. Its "set and forget". That's pretty passive. Yes, you took a direct action, but its not an ongoing action.
> issuing releases and bug fixes
Again, after each fix, you're done. And to the original point, you're never committing to anything.
To repeat my original point, a maintainer could die and the software would still be shared, and the companies that use it would have the exact same relationship they had prior.
It's pretty clear from the article that the author defines supplier as being in a business relationship, using "supply chain" as the context.
Why even go the route of narrowly defining the term just to say “I’m not that”? It just makes the argument literally untrue even though the underlying points are correct and important.
Okay, let's look at it from a different perspective.
What obligation do I, a person developing FOSS in my free time without compensation, have to a consumer of that software (and especially to a consumer who is likely making money in part due to their use of the software I wrote)?
What obligation do I, a person developing FOSS in my free time without compensation, have to a consumer of that software (and especially to a consumer who is likely making money in part due to their use of the software I wrote)?
Absolutely nothing. They have no obligations at all, just like any supplier who provides something as-is. And I agree with the author of the post that it's wrong and unjust for people to think otherwise.
But so what? That does not change the fact that a person developing FOSS supplies something—in fact in most cases they supply a ton of value.
But so what? That does not change the fact that a person developing FOSS supplies something—in fact in most cases they supply a ton of value.
For an analogy, if one of inputs of your business uses trash of others (e.g. for recycling), then the people throwing out this trash are effectively your suppliers and the ones you must consider in your supply chain, because no matter if you have a business relationship with them or not, they do matter in your supply chain, so you have to treat them (and risks related to them) the same as all other suppliers.
Your supply chain involves everything you use and rely upon, no matter if its provided by a business relationship, taken out of the ground, provided by the government, made in-house, or found in outer space.
Your supply chain involves everything you use and rely upon, no matter if its provided by a business relationship, taken out of the ground, provided by the government, made in-house, or found in outer space.
Hizonner(2)
no its not. its saying i am not an uber driver to the pretentious guy entering his car on wallstreet.
That's a fallacy. Assuming that an open source developer is a "supplier" just because there are users is a hasty generalization. Important elements are missing for it to actually be a customer-supplier relationship. From a legal perspective, for example, the contractual intent is missing.
I am completely with you on this. It feels like it’s just tricky semantics.
The point of supply chain management is to manage the inputs to production. Analysing this process using tools from other industries is, at least, a defensible approach. It doesn’t, in itself, imply any obligation on the suppliers. It’s just a way of thinking about the world.
If you write code and make the conscious decision to assign a liberal license and build it and test it and update it and make it available, it’s really hard for me to accept that you are not a supplier of that code. Your license specifically excludes any obligation to users of your software. But the whole essay just felt like semantic tricks to protest against the idea that software can be modelled as if it is some kind of industrial process.
The point of supply chain management is to manage the inputs to production. Analysing this process using tools from other industries is, at least, a defensible approach. It doesn’t, in itself, imply any obligation on the suppliers. It’s just a way of thinking about the world.
If you write code and make the conscious decision to assign a liberal license and build it and test it and update it and make it available, it’s really hard for me to accept that you are not a supplier of that code. Your license specifically excludes any obligation to users of your software. But the whole essay just felt like semantic tricks to protest against the idea that software can be modelled as if it is some kind of industrial process.
If you want me to treat my hobby projects seriously, where is the money to pay for the time for me to treat them seriously?
Supply chain management is not about telling you what to do, it’s about properly understanding the things one depends on to build one’s product.
Like I said, your (presumed) license specifically excludes any obligation to users of your software. I’ve written free software and proprietary software, and one thing I’ve learned is that the world is full of entitled jerks. Entitlement has zero meaningful intersection with software supply chain management.
Like I said, your (presumed) license specifically excludes any obligation to users of your software. I’ve written free software and proprietary software, and one thing I’ve learned is that the world is full of entitled jerks. Entitlement has zero meaningful intersection with software supply chain management.
I make cad drawings of some product, release them with permissive licence on Internet. Some company or you comes and copies them and starts making the product? Am I the supplier of the design? Do you have right to ask for changes?
By most reasonable understandings I would say no. We have no relation at all.
By most reasonable understandings I would say no. We have no relation at all.
> I make cad drawings of some product, release them with permissive licence on Internet
This is not right analogy, cad drawings are not the code. It is relatively easy and near instant, to change license (for cad drawings), and prohibit make materialized copies without written permission.
But I must admit, in freedom world, You have rights and freedoms, to be irresponsible, we just need to figure out, how this could co-exist with real life issues, like supply chain safety.
This is not right analogy, cad drawings are not the code. It is relatively easy and near instant, to change license (for cad drawings), and prohibit make materialized copies without written permission.
But I must admit, in freedom world, You have rights and freedoms, to be irresponsible, we just need to figure out, how this could co-exist with real life issues, like supply chain safety.
I am not a driver, while creating free car blueprints that car manufacturers use to build cars?
It's fine not to be a supplier! I'm usually not. But in that case, why publish your code so that people will think you are a supplier? Better to publish it as a gist, a notebook, or some other way of sharing example code, not as a package where people who want to reuse code without adopting it will expect to find such things.
But i did write in big, capital letter that i am not a supplier in the licence, in the repo.
See the last sentence.
See the last sentence.
I don't know where you publish your code. You did imply at some point that you're not just talking about yourself, though:
> We are volunteers, writing code and putting it online under these Licences. And yes, we put it online for people to use them. But we do not get anything from it.
Some people publish their code on npm or as crates or whatever. These packaging systems are designed to allow people to download and use your code without reading it.
Worse, they can end up using the code indirectly, without reading it. Do you think they see your repo or the README or the license?
So what I'm saying is that if you take no responsibility (which I support), you should stop doing that (if you are), because it confuses your message. Although there's no money involved, these packaging systems encourage consumer-like behavior.
> We are volunteers, writing code and putting it online under these Licences. And yes, we put it online for people to use them. But we do not get anything from it.
Some people publish their code on npm or as crates or whatever. These packaging systems are designed to allow people to download and use your code without reading it.
Worse, they can end up using the code indirectly, without reading it. Do you think they see your repo or the README or the license?
So what I'm saying is that if you take no responsibility (which I support), you should stop doing that (if you are), because it confuses your message. Although there's no money involved, these packaging systems encourage consumer-like behavior.
And handicap all the sensible users who are willing to take responsibility for using those libraries? (in hobby projects, or otherwise)
Sounds to me like a perversion of the intent of FOSS infrastructure.
Sounds to me like a perversion of the intent of FOSS infrastructure.
More users, more problems. People who just use your code without maintaining it don't benefit you. Often, FOSS infrastructure is part of the problem.
> why publish your code so that people will think you are a supplier?
Because I was taught that sharing is a moral good. Are you suggesting that anyone who shares their source online is obligated to also provide free support to any and all users?
Because I was taught that sharing is a moral good. Are you suggesting that anyone who shares their source online is obligated to also provide free support to any and all users?
The only obligation I think you have is to avoid misleading people by sending mixed messages. If the code is really provided without support, it's not enough to just say that in the license. You also want to make sure that the way you present your code to strangers online doesn't encourage them to think of it as a supported product. For example, creating a slick website with a marketing message about how great your software is (so try it now) would undermine the message that it's just provided as-is and any bugs it has are yours to fix.
Similarly, publishing your code in a store-like repository so people download and use it without reading it, or even knowing that it's a dependency, encourages people to treat it like a hidden part of a product.
Similarly, publishing your code in a store-like repository so people download and use it without reading it, or even knowing that it's a dependency, encourages people to treat it like a hidden part of a product.
Why is there not explicit payments in the store... Like why not design it so that supplier can set any price for their code and this is automatically deducted from the buyer that is downloader?
Or is not actually a store?
Or is not actually a store?
Because it's open source, payments are optional. Yes, including by big companies. Even those who want to "give back" have lots of options, such as "paying it forward" by making something else.
There are people who give away software, support it (at least making security patches), and are fine with other people relying on it. If that's you then publishing it as a package makes sense.
But a lot of us are not really prepared to do that with the software we write, and we should be wary of the implicit promises we make with how we publish it. Publishing example code or a notebook is safer since no library is going to add a dependency on that code.
There are people who give away software, support it (at least making security patches), and are fine with other people relying on it. If that's you then publishing it as a package makes sense.
But a lot of us are not really prepared to do that with the software we write, and we should be wary of the implicit promises we make with how we publish it. Publishing example code or a notebook is safer since no library is going to add a dependency on that code.
When I say “software supply chain security”, I am reducing a complex concept to jargon, and am using terms that will evoke specific concepts in the people I work with. I’m not really talking to you; I’m talking to my leaders who are extremely business savvy but may not have the software development chops to understand how code we didn’t write got mixed in with code that we did write.
I am NOT implying nor assuming that the original creator or maintainer of said software has any obligation to me.
The 90% case for me, when I bring up this term in a software security discussion, is that I’m trying to impress upon an engineering manager that if they choose to use software that they didn’t write, that THEY own it from a security perspective. Depending on risk we might discuss monitoring for notifications of vulnerabilities in the code, or we might discuss first-party or third-party security code reviews, and/or forking depending on the security support level of the maintainer, and/or contributing back security patches that we develop in house. Or I might try to convince them not to take the dependency and write the code they need themselves. Or I might propose mitigations like isolation. Or all of the above. “Software we use but didn’t write ourselves” just doesn’t look professional or compelling in reports and documents and doesn’t lend itself to being reduced to an acronym like SSCS.
As a security engineer, I depend a lot on the goodwill of folks like you who write and maintain open source software, and I most definitely do not take your work for granted.
Best regards and Happy New Year!