The fact any company is using software written by hobbyists is bananas. Even if the hobbyist has written it in a professional capacity, at the end of the day, it’s still a hobbyist project, maintained by someone on their free time, most of the time not looking for compensation, and usually heavily opinionated on how it should work. They have little to no incentive other than it could be seen as a resume piece, which then once they’ve done something more significant, begins to rot.
I’ve used GitHub for a long long time like a lot of us here. Originally it was great to find interesting projects, but as time goes on I find this less and less a good resource? Now joining communities where sharing and discussing software are way more fruitful. More interesting software is making its way out of GitHub. Now GitHub is a way for “employee of company” to quickly get a task done.
People are talking about licenses also: no one cares about your license. You don’t even know how much of your code ends up in other projects as copy-paste chunks or refactors. As it’s been shown in the thread people ignore licenses. Many of us also don’t have the knowledge or money to spare to fight invalid usage.
Self-host your projects if you want to share. No-host if otherwise. Use email for communication (it’s way more personal and practically zero barrier of entry!).
The fact any company is using software written by hobbyists is bananas.
No, this is fine. IMHO, the core of the problem is that software companies use software written by hobbyist AND expect commercial-software level of support for free. This is where I sometimes feel the world is taking crazy pills…
You’ll have to explain why it’s fine, just as I should explain in more detail why it’s not - I can see why everyone, myself included, starts with this sentiment. Let’s not start this here, but I’d like to just plant a little seed into people’s minds to question the why it’s fine.
IMHO, this is like public domain. When Disney takes public domain work (Hamlet) and use and remix it commercially. (The lion king) They create wealth, jobs and improve culture without hurting anybody. (again, in my opinion, some people with different political beliefs might disagree)
Same goes for these hobbyist, their code is Hamlet, they just deliberately chose to put it in the public domain¹ while they’re alive, for people to take and remix and make technology better. So I’m totally fine with companies doing so, it saves cost and they can focus their money on other things which also delivers value to their customers, while creating jobs and wealth.
As I was saying, I think the line is crossed when they asked/required/push-for these hobbyist to work for free.
¹. Minus some requirements like attribution in case of the MIT license and in some case Share-Alike in case of the GPL.
Is William Shakespear’s Hamlet actually comparable here? Is it a hobbyist work? Did William apply changes to Hamlet given by others? Did William change Hamlet because of what others said? Was Hamlet giving him any income in any form? How many Hamlets are there in the software world? Are companies augmenting their services with this free software or just exploiting it? I’m sure there are a lot more questions than answers.
I’m fine with companies doing it too, but it doesn’t dismiss the fact they probably shouldn’t for their own sake (again, it’s bananas). If code is Internet-accessible, it’s public, and there’s really not much you can do. Copilot is going to really drive this home in the coming years…
It’s also a bad comparison because I’m pretty sure Shakespeare made money off of Hamlet and all his other plays. Writing and producing plays were likely his main occupation and source of income.
When Disney takes public domain work (Hamlet) and use and remix it commercially. (The lion king) They create wealth, jobs and improve culture without hurting anybody. (again, in my opinion, some people with different political beliefs might disagree)
I think it’s a bit of a strawman to make this comparison with software, since media copyright is really different and very nuanced. Flipping this argument on its head, you could say that every single piece of copyrighted media is just a remix of $SHAKESPEARE || $THE_BIBLE || $FAIRY_TALE (in fact, the Lion King is two of these!). Nothing Disney has ever made, except of course the ones that were actually adaptations of fairy tales, can really be claimed as a “remix” of an earlier story, because so much of the narrative around the story has changed that it is its own work. And I know this doesn’t count for much, but it’s pretty clear that the writers of this story were not intending to commercialize an otherwise public-domain work to make money or claim it as their own. Software, in contrast, is a little easier to understand because you can clearly see when someone is using your code or not. It’s just not that black and white when you’re dealing with intellectual property, as we’ve seen when IP laws came back to bite Google in the ass after releasing Android with a Java-like API.
I do agree with you, though. When you put something out into the world as open-source software, with a permissive license, you are essentially not responsible for its longevity or supporting it at all. That’s why most of us choose this license, we’re not obligated to the demands of any other entity using this software that we wrote. If that’s OK with you as a company, you use this software at your own risk. Otherwise, fork it and maintain a better version, or use something else.
I also think this is a valid point of view. Just making something public doesn’t make it a part of any “supply chains”. In fact, mostly it’s right there in the license (“comes as is”, “no warranty” etc), but you also touched on that as well.
But how does your self-hosted code differ from that Tokio, Rails, Angular or whatever else?
If we look at, say, libc - I rely on my linux distributor. It’s still not an explicit “contract”, as linked in the original article. And the “software supply chain” metaphor works almost well - they actually pull the source from wherever (well, usually they also host the software development boards etc), and make their own builds, and make commitments to maintain the packages for X months or years. With things like Angular, it’s relatively close, it’s similar - you can see their maintenance and release schedule and can be fairly “certain” that Angular 14 will be maintained until December 2023. Some other widely used software? Not so much.
But Google is not a hobbyist, and Len is. What about a million things in between? I would just say, as soon as I npm install or cargo add in a “professional” project, I am my own maintainer for all of that, including Google’s Angular. Only if I explicitly buy something from a company can I say I have a supply chain.
So the point you make is self-hosting would be nice, but not everybody has the skills, time, ability or similar for it. They just want to share some cool hacks. And even if you push all that on github, who cares? Lock down your issues board or ignore it, and keep hacking.
Right, reality is a gradient - there’ll for sure be people “in the middle”, and actually I find those projects in a very sweet place. Being open source but professionally owned by a small team or an individual rocks so much. To me this is where GitHub thrives, for these types of projects.
Honestly, this just sounds like “old man yells at cloud”.
There’s nothing inherently wrong with depending on something that’s not made in a commercial capacity. You seem to be conflating something not being commercial with it being somehow bad or problematic.
What is wrong is doing so blindly, without looking into the state of your dependencies, what the impact might be of changes to the dependency (e.g. the maintainer goes missing), and crucially using something without ever supporting the project in some capacity.
Honestly, this just sounds like “old man yells at cloud”.
I’m interested to hear why you think that! I think there is something inherently wrong otherwise this wouldn’t really be a discussion… It’s easy for me to say you’re simply dismissing what I’ve written with this line and that honestly “you don’t really give a “, but being charitable I think that’s the last thing you mean. 🙂
conflating something not being commercial with it being somehow bad
Sure you could interpret it this way, but all I’m saying is it seems to be a problem when using hobbyist software for commercial purposes. Really nothing more. Deconstructing this could probably be put into a long written piece. I invite you to re-read what I’ve written (across all comments in this thread) from a different perspective.
I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. I should be allowed to decide if something I wrote is “done”.
One way to do it is to pick a license that’s considered radioactive by FAANG and their wanna-bees. Just stick AGPLv3 into that COPYING.md file, no one will bother you again.
I believe that that’s a gross oversimplification. The author is digging more into the series of obligations that functions as links in a supply chain, and contrasting that with what actually happens in open source software dependencies.
How about “the author thinks that since companies don’t use much software packaged by distros, that means due diligence work they do of vetting and approving code doesn’t count”?
No, I think it’s more that they still think it’s not a “chain”. If you’re doing the software, and the due diligence for libraries used, you’re not a chain, you’re still the responsible party. Of course that this work counts - you have to do it, because it’s on you, not on the a hobbyist author of some small library that you vetted and used.
What if you research the Debian project and the policies they use to vet software, cut releases, and the steps they take to ensure that only qualified and trusted developers have the ability to upload packages, then you decide to trust software in Debian because you trust their process, how is that not a chain of trust from one set of policies and decisions to another? You’re recognizing that you don’t have the time and resources to vet each individual package, so you delegate to another organization who does. Sounds like a chain to me.
A package repository might deem your software “critical”, adding requirements to publishing updates that you might not want to or be able to comply with.
Then don’t publish your package to that repository. No one is forcing you to publish there. That repository is a (free) service that is provided to the community by its maintainers and they have the right to enforce what gets published there and how. If you disagree with the conditions it’s simple–just don’t use it.
This assumes that you need to intentionally publish something to a repository though. This doesn’t hold true for multiple language ecosystems. Python allows you to pull and build git repos. Go doesn’t give you any choice either.
So you can’t decide to truly opt-out of this. The only option would be to never publish the code in the first place.
The community and/or the people running the ecosystem. Not having an explicit package repository doesn’t mean there is a lack of ways to deem projects ciritcal.
If you’re providing my package through your package repository, you get to act as a gatekeeper/maintainer.
When I publish my go code on my own domain, who would (and how) implement that same role?
I think of ‘deeming critical’ as only existing within that package repository. Two competing repositories could have different ideas and commitments. What they try to convey seems to be a promise to the users of the repository & package combo - use us, we vetted things and commit to keep them running (something something analogy between rolling releases and distros maintaining LTS releases).
You still cannot disable pull requests on a GitHub repository.
This is a pretty easy problem to solve by not using GitHub.
Google even wanted to disallow anonymous individuals from maintaining critical software and wanted to police the identities of others.
I’m no fan of Google, but it’s their right to only use open-source software whose maintainers have publicly-verifiable identities, just as its their right to take open-source software maintained by anonymous people and fork it and maintain it themselves if they really care about this but still want to use the software.
You still cannot disable pull requests on a GitHub repository.
Yes you can, though it’s clunky and also disables issues and comments.
It’s under “moderation options” in settings. You can set it so that pull requests are disable for people who aren’t explicitly added to the repo as collaborators. The catch is you can only disable it for 6 months at a time, so you have to have something or someone reset it before the 6-month mark to keep PRs disabled.
I mean, obviously nuisance is in the eye of the beholder, but that feels pretty hyperbolic to me. At work I manage about half a dozen public repos where we don’t want outside pull requests. I spend a total of about ten minutes a year to manage these settings. I regularly waste more time than that in a single day just waiting for people to show up late to meetings.
It would be neat to be able to mark a package as “for entertainment/educational purposes only” or something so people know not to depend on it. Right now, a package is a package, and there’s not a definitive way to know whether any given library you depend on is being supported by a whole company or just some random person in a Nebraska basement. There have been various attempts to fix this issue, namely by using highly permissive open-source licenses like MIT, but when every package manager on earth defaults to that license, only the very legally-minded are probably ever going to change it.
GitHub does know about your license, so it would be a pretty awesome feature to have features (or at least sane defaults) tailored to the license you chose for your project. For example, a project using a “source-available” license would not allow pull requests, and downloads/usage would essentially be at your own risk. Either way, I think it would be helpful to be able to mark your project as open, but not “contributable”. However, I suspect GitHub won’t be doing this anytime soon, as I feel like private repositories suit this purpose as well, and would only benefit a few of us folks who enjoy developing in the open so we can share experiments.
We both know it’s probably morally good for you to build off my work, and
redistribute it as far as it can go, humans have been doing this since
before we figured out fire. Plagiarism is a lie we tell ourselves to try to
constrain and suppress entropy.
I don’t think I will ever get over how many people are okay with plagiarism. I know this case is a lot less serious (she’s inviting people to plagiarize her), but still.
Either you copy intentionally from a few sources, or you copy subconsciously from thousands of sources.
That’s not what plagiarism means. It’s plagiarism to pass someone else’s work off as your own. Being inspired by something isn’t plagiarism, nor is using someone else’s work but attributing them, or even NOT attributing them but making it obvious to everyone it’s not your creation either. Though that’s still gross. But it’s not morally reprehensible.
I’m pretty sure it’s just conflating plagiarism and piracy - as long as you cite where you “stole” the code from and don’t claim to have written it yourself, then it’s not plagiarism.
There’s a lot of implicit cultural bias here. For long periods in Imperial Chinese history, it was considered extremely bad manners to claim authorship and a lot of things were published with pseudonyms. Rome had some similar periods. In Europe the notion of ‘moral rights’ (not part of US federal copyright law) appeared to codify a consensus that (if I remember correctly) came around the renaissance that authorship was important, emerging largely as a result of the patronage model for funding creative works (if you claim authorship of someone else’s work then you may get money from someone who wants to patronise them, so you are effectively stealing).
That doesn’t make plagiarism universally bad, absent of cultural context. It does mean that we’ve built a lot of other social structures that mean that plagiarism has negative consequences.
In Europe the notion of ‘moral rights’ (not part of US federal copyright law) appeared to codify a consensus that (if I remember correctly) came around the renaissance that authorship was important, emerging largely as a result of the patronage model for funding creative works (if you claim authorship of someone else’s work then you may get money from someone who wants to patronise them, so you are effectively stealing).
It’s a bit more complicated than that. Rabbinical Judaism, from an early era, was agonizingly thorough in giving attribution, and there are accusations of plagiarism in third century Greek texts (Heraclids 92).
Okay, I’ll assume you’re asking in good faith. To understand where you’re coming from, here’s a hypothetical:
Sometime goes to your blog, copies your posts, and host it on their blog. When it goes viral in your favorite communities, they take all the credit, they get all the good will, they get all the thanks. They never once mention you, or the fact they copied from you.
Is that wrong for them to do? Can they do that and still be “good Christian”?
Oh, so you’re talking about like an actively lying kind of plagarism. Which is lying. Which is morally wrong. I think I see where you’re coming from now.
Pretty much! Though now you got me curious, too. What would be an example of plagiarism you’d not consider morally wrong? It’s possible that my definition of plagiarism is much more narrow than other people’s, so things people would consider “acceptable plagiarism” would be things i would consider “not plagiarism”.
I mean, classroom plagiarism is things like reading a lot of articles, not writing down what all of them were, writing up a summary of everything you learned in your own words from your own memory, failing to include one of the sources. Teachers consider this “plagarism”
Which I dislike. I try to be a person of good moral character, and as an individual being called a thief in the opening remarks is not… nice.
Maybe someone between trying hard and evil will use it because they didn’t notice, or if they did the moral ambiguity of stealing another person’s labor appeals to them. But I can’t ignore this paper tiger I’ve built up around the way we permit others the use of our work.
I agree with the HN comments stating that this was mean to do – the lack of any implied or express disclaimer against use in both the blog post and README file meant that people were taken by surprise by the license.
Plenty of projects are published with prose warnings of “you can look, but don’t use”. This one should have been. And the license is a great template to use on those projects, too. (Although I’d maybe add in a patent grant.)
It would be neat to be able to mark a package as “for entertainment/educational purposes only” or something so people know not to depend on it.
There is a way. It’s called a license. And about 100% of them explicitly tell users not to depend on it: “THIS SOFTWARE IS PROVIDED AS IS AND ANY WARRANTIES ARE DISCLAIMED.”
There is another way, less formal, called a version number. As long as it’s 0.*, it’s clearly experimental.
The only thing about people though, they’re are going to ignore any and all warnings if the software is de-facto useful to them.
We’re solving the wrong problem here. The problem is not that users don’t know there’s no guaranteed support. And it’s not even in that users still do ask for (or demand) support when things break. The problem is that maintainers for some unfathomable reasons feel obliged to provide it. And then complain about being treated unfairly.
I used to be sympathetic to that (being an on and off maintainer myself), but not anymore. If you license your software “as is, no warranties”, do have the guts to ignore support requests and only react on things you’re personally interested in. But if you want your project to behave like a product then be clear what you want in return: money, name recognition, employment, etc.
Almost all off-the-shelf commercial software has that same all-caps AS-IS disclaimer. Even in a one-off negotiation with a vendor their liability will be strictly limited to a relatively minuscule amount.
And they happily ignore support requests they aren’t interested in, whenever they can (usually it’s trivial, since support agreement also limit the liability as much as they can).
Yeah, I agree with you 100%. The license states very clearly that I don’t have to give a shit about anyone else when I release software, it’s my own personal responsibility or will to help out that is doing all the work here.
But, as maintainers, we both know that:
Nobody reads the license. Otherwise that South Park episode wouldn’t have been nearly as funny.
Not everyone follows semantic versioning, or even knows how to follow semantic versioning properly.
It’s kinda the same argument for GitHub surfacing the license in the UI rather than just making users look for a LICENSE.txt at the root of the repo. The license text was always there, but the fact that it’s in the UI now means it’s easier to spot and overall is easier to recognize dependencies that are on different licenses. I’m also not really thinking about this from a company’s perspective, more of a startup/hobbyist who is exploring the world of programming and is trying to ascertain what packages they should depend on. To me, a company has a whole team of people inspecting these packages and unless you’re not paying attention, it’s pretty easy to spot packages made by a company vs a “hobbyist”.
Not perfect, but I use: https://www.repostatus.org/ to tag my work as WIP. It’s a fine distinction but probably some of it should be tagged as Concept, to distinguish the repositories that I intend to be used from those that I never expect.
I think this taxonomy is still missing the key component of how much shit are the maintainers giving to this. Is this a one-person-occasional-weekends kind of thing, or is there a company/community behind it, or something in between?
Somewhat authoritative information on this would at least help when making the decision of including a dependency. I try to use the GitHub pulse tab as a proxy, but it’s far from ideal.
“In actual supply chains, money is changing hands.” This is a very 20+21st century idea. There were a lot of supply chains in the 18th and 19th century (and to some extent today) where the supply just came from mother earth (timber on public lands needing consent, fishing, whaling, buffalo hunting, trapping, rubber, etc). In the whaling and timber cases those ‘free’ items went on until they got used up and/or protected.
The issue is that the concept of ownership that eventually descended upon the native peoples (with war, violence, murder, resettlement, and reeducation) eventually became the systems that the author is attempting to rectify with the ‘free’ nature of free software. I think the experiences of native peoples to colonization is directly relevant to the feeling of a hobby project becoming a lynchpin for a massive industry, ie the native tending of productive lands that produced such abundance across America. An abundance that was quickly sucked dry by the delusion of manifest destiny.
Because transportation facilities were poor, local wood shortages sometimes arose near the larger towns, and these occasionally led to restrictions on cutting. But most people felt, in the words of Gifford Pinchot, that “the thing to do with the forest was to get rid of it.”
“license.txt” is your friend here. And if you don’t want pull requests, release on gitlab or some other hosted git site that doesn’t focus on discoverability.
In security audits and legal speak they talk about “chain of custody” to refer to this thing of exchanging responsibility. A supply chain is maybe less accurate but it still captures what people want to communicate fairly well.. At the risk of sounding like a broken record; we need a way to quantify risk and measure how much we can trust dependencies. As a bonus any such solution would allow us to pay developers of free software for their work.
I don’t think that’s what they are talking about it.
The way I read it, the point of the article is that there is no supply chain because there is no chain. You write source code? You are the supplier. You added random packages from random internet websites? Still your responsibility. Even if that random library you added is a Microsoft package and they provide “guarantees” that it’ll be there for 3 years - if you don’t have an explicit contract, you’re “it”. No chain.
You bought hosted monitoring and a widget library and built it in your software? You, the monitoring company, and the widget supplier are all in the supplier chain.
See? Contract - chain. No contract - no chain. The fact that we all rely on npm and crates.io and maven central without explicit contracts just means that we accept the risk of those things going away.
But you want to quantify the risk of trusting dependencies, right? Let’s give it a try.
Option one: self-host. Add the library sources in your project, or at least in a git repo in your company. Whatever guarantees you can provide yourself are your guarantees.
Option two, use public repositories, e.g. github - you’re still it. They might provide “guarantees” but they have no obligations. Just like Heroku recently said something about not allowing free instances any more (or some such), what’s to stop Microsoft to revoke free accounts on Github?
Option 3: sign a contract with Microsoft for a paid GitHub account. Now we’re talking. Now we’re in business. You can host stuff there and you can count on contract guarantees (however many nines, LTS schedules, whatever).
My point is that the article talks not about how we cannot rely on “supply chains” - we can do that already with a contract. They (the author) are not part of that chain, and if you are doing ANY risk analysis, you have to start with “I am pulling software from publicly available but privately owned random internet websites”. What you say is you want to quantify the risks of, say, Microsoft stopping free github access. I think that may help a little, but not much. The person publishing the code can still just delete it at any time.
The chain is there it is just not explicit. Where did your data come from? where does it go? Access control is a thing..
You added random packages from random internet websites? Still your responsibility.
Sure, you’ve taken on that responsibility. However you can pin this dependency (and many companies do pin their dependencies and drift out of sync with the upstream since they don’t want to be auditing every feature that they don’t need or use).
See? Contract - chain. No contract - no chain.
Sure. Now what is a contract? Because the way I see it the legitimacy of the contract is derived from the legitimacy of the courts that will be enforcing it. I don’t see why we cannot build legitimacy around free software where we keep track of cryptographic commitments. Enforcement would of course be some kind of decentralized “cancel culture” that we see running rampant these days through social media.
But you want to quantify the risk of trusting dependencies, right? Let’s give it a try.
The options you name are nonsensical fwict. You assume you are alone whereas there is no chain of custody when there is only one individual / organization involved. The whole point is that we have a symmetric problem here. Everyone needs to assess their dependencies and that work can be meaningful to others.
When someone reviews some code and gives me a cryptographic commitment with their assessment then that has meaning with relation to the trust this individual has built in their reputation.
Look at the darknet drug dealers; when a vendor has built up trust they get more orders, now if they get too many orders at any one point then the amount they have in hand may be worth more than the ongoing profit from their good reputation. This is why we call the scenario where the dealer dissappears with the money a “retirement attack” … the dealer throws their reputation away to take the money without fulfilling orders. This means that the customers are not well enough coordinated to decide if they can put money on the table, in order to be secure the customers would both need an accurate assessment of the worth of the reputation as well as a general idea of how “hot” the dealer is at the moment (how many outstanding orders).
… we can do that already with a contract.
No. We cannot. This is the whole issue of our current economic system. We cannot motivate contributions to the commons with a centrally coordinated system unless the participants can motivate the coordinator with a sufficiently realistic threat. Currently this is not the case (or we would see a lot of government money going into free software).
The “we” I am talking about is the free software community. We have all sorts of package repositories but no contract.. and we will not have a contract because the people who make free software shouldn’t need to ask for permission to write some code (or use someone’s elses code).
I want to quantify the risk of using a certain version of a software (that anyone can contribute to) and reward the people who make contributions that are perceived as legitimate by other participants in the coordination of the versioning of that software (sorry for the mouthful). This will require a bit of a shift in foundations but it should lead to more wholesome incentives in the software industry.
I don’t want to dispute your points, but I still think we’re talking past each other. You’re saying that there is an implicit supply chain, and I’m not. But i think we’re talking about different points here - you’re taking about a company implicitly relying on an inherently unstable structure, technically and otherwise, to achieve their business goals.
And the point the article is making (and I largely agree with), is that that is fundamentally not a supply chain. It’s not a good analogy. If the said company paid GitHub to host the software and the developer to develop it, then you have a logistic supply chain (in the usual sense of the word). You can make plans around it and budget with it. And in the plans, they rely on their supply chain to fulfill stuff for them. Yes, things can still go wrong, but you can build in some redundancies, alone or with those partners, but generally your fulfillment plan depends on theirs.
If you pick up open source software on their own tedhough, and relied on the developer not pulling the software and GitHub not kicking them if the platform or whatever, then there is no chain. Your fulfillment is on you alone. And you can still build redundancies, and things like you mentioned, like pinning dependencies, are that, but you’re not planning on a random hobbyist developer to be delivering on time, or pulling left-pad from npm or anything; you’re in charge and you need to secure that.
I think that’s the point of the article, at least.
Yeah I see, fwiw I also had the feeling that we were talking past each other but the intersection of what we are talking about is this nebulous concept of responsibility and how it relates to FOSS. I agree that when it comes to physical resources such as servers and their uptime then we are firmly in the world of contracts and companies but as soon as you start talking about the software itself and development of it then we get more into the domain that I was trying to verbalise. Risk, responsibility and money go hand in hand in hand.
A software supply chain is a system and I think of systems as something within which between its connected components there’s a flow of material, money, energy, information or a mix of all. (Not a unique thought of mine, I read it somewhere and it stuck with me). As such, here is my disagreement with the author:
If a microchip vendor enters an agreement and fails to uphold it, the vendor’s customers have recourse. If an open source maintainer leaves a project unmaintained for whatever reason, that’s not the maintainer’s fault, and the companies that relied on their work are the ones who get to solve their problems in the future
I view the abandonment of an open source project, for whatever reason, the same way as for example a supplier of goods defaulting. No recourse there also. There’s a risk in every decision and sometimes it materializes. And recourse is small consolation if I cannot ship the product.
I totally sympathize with the feelings triggered by effort dehumanization and the frustration, but the truth is that sometimes you’re stuck with the equipment long after the original supplier (and sometimes subsequent maintainers) stopped supporting it. Such equipment can be anything from a washer from 1970 that still operates to a piece of software that is left unmaintained because the author does not feel like it any more.
If I can put it in a diagram that shows the flow of information in my system, then it is in the chain. If it was built externally, or I take it from an external repo, this is my supply chain and I need to secure it. I, not the supplier necessarily.
If I can put it in a diagram that shows the flow of information in my system, then it is in the chain. If it was built externally, or I take it from an external repo, this is my supply chain and I need to secure it. I, not the supplier necessarily.
I think this is the entire point. If you need to secure it, it’s not a chain. It’s still just one node - you. And yes, things in your supply chain can default or dissapear, but this is a regular business risk and you can, e.g. insure yourself against it, or have a redundancy with a different contract.
If you have a washer from the nineties, that’s still not a chain - you’re still alone. I think that was the point of the article. We should not rely on external parties to manage our “chain” unless we make it so by contract.
I feel that, with the safety goals and guarantees of Rust, it’s going to be finally possible to move away from “All warranties are disclaimed” and towards a “Professional responsibility” model where we, as software writers, are finally confident enough in our work to say that yes, it is fit for a particular purpose.
I’m struggling to see how Rust enters into this. Rust code can still have buggy business logic or solve the wrong problem or lack critical features or inadvertently violate regulations when used. For me, at least, the question of whether I volunteer to let people sue me if my code is wrong is about those kinds of things, not really about things like memory safety or concurrency bugs.
I like that the Rust ecosystem tends to be focused on correctness, but the license text is not really about software quality, but about not getting sued by a random user for whatever reason. Professional responsibility should come with a paid support contract.
The biggest problem with professional responsibility is that to guarantee fitness for a particular purpose, one needs to specify exactly what that purpose is. With non-embedded software products, there is simply no way to declare any guarantees without opening up possibilities to accuse you for things completely out of your control.
Even in fields where products are marketed for specific purposes, not everything is that simple. If you are marketing drops for runny nose and they fail to help anyone with their runny nose, or people get nasal mucosa burns instead, then sure, you are liable. But off-label use of medications is widespread and hardly any of drug manufacturers are willing to accept liability for it. Some certainly will say “and rightfully so”, and I can’t really blame them.
If you are shipping a box, it’s possible to make some guarantees, like “if you connect it to a 110-220V/50-60Hz power grid, it will not explode”. It’s also possible to guarantee that certain inputs will always produce certain outputs and specify the range of acceptable inputs.
But with code, there’s always a possibility that someone will run it on a DeathStation 9000 and blame you rather than their insane environment, because developers of the insane environment put in necessary disclaimers and you didn’t. ;)
So, professional responsibility should not only come with a paid contract, there should also be an exhaustive lists of usage conditions when that responsibility applies.
Really? Why do you think Rust will make such a bug difference?
We’ve had Ada/SPARK since the 1980s, and many other systems for proving correctness of programs, many of which have been used successfully to create safety-critical software for decades.
Rust is great for writing memory-safe native code without a garbage collector… but I don’t see why that would suddenly cause software writers to be “confident enough in our work to say that yes, it is fit for a particular purpose” if they weren’t already.
Absolutely not in this case. The author is specifically talking about “unpaid hobbyists” who are publishing “weekend hacks” “so that other hobbyists can use and learn from it”, and who “otherwise want to be left the hell alone”.
There is no professional responsibility if you are publishing a hack that you wrote for your own amusement, and you don’t have a contract with a customer, and you aren’t being paid. Even if the hack is written in Rust.
If we want a professional responsibility model, we’d need to be actual professionals.
As of right now, there is no credentialing system in place at all for software developers. I was a physics student who enjoyed tinkering a little too much, maybe someone else graduated from a bootcamp, someone else took a community college course, whatever. In order for software developers to be able to sign off on work as being fit for purpose, someone else needs to be able to sign off on us.
And frankly, as a community I don’t think we want that. Sure, it would be nice to have some sort of filter sometimes, especially in hiring and in evaluating dependencies, but on the other hand the absolute wild west nature of software is most of the fun.
The keyword here.
The fact any company is using software written by hobbyists is bananas. Even if the hobbyist has written it in a professional capacity, at the end of the day, it’s still a hobbyist project, maintained by someone on their free time, most of the time not looking for compensation, and usually heavily opinionated on how it should work. They have little to no incentive other than it could be seen as a resume piece, which then once they’ve done something more significant, begins to rot.
I’ve used GitHub for a long long time like a lot of us here. Originally it was great to find interesting projects, but as time goes on I find this less and less a good resource? Now joining communities where sharing and discussing software are way more fruitful. More interesting software is making its way out of GitHub. Now GitHub is a way for “employee of company” to quickly get a task done.
People are talking about licenses also: no one cares about your license. You don’t even know how much of your code ends up in other projects as copy-paste chunks or refactors. As it’s been shown in the thread people ignore licenses. Many of us also don’t have the knowledge or money to spare to fight invalid usage.
Self-host your projects if you want to share. No-host if otherwise. Use email for communication (it’s way more personal and practically zero barrier of entry!).
FWIW, my self-hosting solution: https://len.falken.directory/code.xml
No, this is fine. IMHO, the core of the problem is that software companies use software written by hobbyist AND expect commercial-software level of support for free. This is where I sometimes feel the world is taking crazy pills…
You’ll have to explain why it’s fine, just as I should explain in more detail why it’s not - I can see why everyone, myself included, starts with this sentiment. Let’s not start this here, but I’d like to just plant a little seed into people’s minds to question the why it’s fine.
IMHO, this is like public domain. When Disney takes public domain work (Hamlet) and use and remix it commercially. (The lion king) They create wealth, jobs and improve culture without hurting anybody. (again, in my opinion, some people with different political beliefs might disagree)
Same goes for these hobbyist, their code is Hamlet, they just deliberately chose to put it in the public domain¹ while they’re alive, for people to take and remix and make technology better. So I’m totally fine with companies doing so, it saves cost and they can focus their money on other things which also delivers value to their customers, while creating jobs and wealth.
As I was saying, I think the line is crossed when they asked/required/push-for these hobbyist to work for free.
¹. Minus some requirements like attribution in case of the MIT license and in some case Share-Alike in case of the GPL.
Is William Shakespear’s Hamlet actually comparable here? Is it a hobbyist work? Did William apply changes to Hamlet given by others? Did William change Hamlet because of what others said? Was Hamlet giving him any income in any form? How many Hamlets are there in the software world? Are companies augmenting their services with this free software or just exploiting it? I’m sure there are a lot more questions than answers.
I’m fine with companies doing it too, but it doesn’t dismiss the fact they probably shouldn’t for their own sake (again, it’s bananas). If code is Internet-accessible, it’s public, and there’s really not much you can do. Copilot is going to really drive this home in the coming years…
P.S. Thank you for the dialog 🙂
It’s also a bad comparison because I’m pretty sure Shakespeare made money off of Hamlet and all his other plays. Writing and producing plays were likely his main occupation and source of income.
I think it’s a bit of a strawman to make this comparison with software, since media copyright is really different and very nuanced. Flipping this argument on its head, you could say that every single piece of copyrighted media is just a remix of
$SHAKESPEARE || $THE_BIBLE || $FAIRY_TALE(in fact, the Lion King is two of these!). Nothing Disney has ever made, except of course the ones that were actually adaptations of fairy tales, can really be claimed as a “remix” of an earlier story, because so much of the narrative around the story has changed that it is its own work. And I know this doesn’t count for much, but it’s pretty clear that the writers of this story were not intending to commercialize an otherwise public-domain work to make money or claim it as their own. Software, in contrast, is a little easier to understand because you can clearly see when someone is using your code or not. It’s just not that black and white when you’re dealing with intellectual property, as we’ve seen when IP laws came back to bite Google in the ass after releasing Android with a Java-like API.I do agree with you, though. When you put something out into the world as open-source software, with a permissive license, you are essentially not responsible for its longevity or supporting it at all. That’s why most of us choose this license, we’re not obligated to the demands of any other entity using this software that we wrote. If that’s OK with you as a company, you use this software at your own risk. Otherwise, fork it and maintain a better version, or use something else.
I also think this is a valid point of view. Just making something public doesn’t make it a part of any “supply chains”. In fact, mostly it’s right there in the license (“comes as is”, “no warranty” etc), but you also touched on that as well.
But how does your self-hosted code differ from that
Tokio,Rails,Angularor whatever else?If we look at, say,
libc- I rely on my linux distributor. It’s still not an explicit “contract”, as linked in the original article. And the “software supply chain” metaphor works almost well - they actually pull the source from wherever (well, usually they also host the software development boards etc), and make their own builds, and make commitments to maintain the packages for X months or years. With things like Angular, it’s relatively close, it’s similar - you can see their maintenance and release schedule and can be fairly “certain” that Angular 14 will be maintained until December 2023. Some other widely used software? Not so much.But Google is not a hobbyist, and Len is. What about a million things in between? I would just say, as soon as I
npm installorcargo addin a “professional” project, I am my own maintainer for all of that, including Google’s Angular. Only if I explicitly buy something from a company can I say I have a supply chain.So the point you make is self-hosting would be nice, but not everybody has the skills, time, ability or similar for it. They just want to share some cool hacks. And even if you push all that on github, who cares? Lock down your issues board or ignore it, and keep hacking.
Right, reality is a gradient - there’ll for sure be people “in the middle”, and actually I find those projects in a very sweet place. Being open source but professionally owned by a small team or an individual rocks so much. To me this is where GitHub thrives, for these types of projects.
Honestly, this just sounds like “old man yells at cloud”.
There’s nothing inherently wrong with depending on something that’s not made in a commercial capacity. You seem to be conflating something not being commercial with it being somehow bad or problematic.
What is wrong is doing so blindly, without looking into the state of your dependencies, what the impact might be of changes to the dependency (e.g. the maintainer goes missing), and crucially using something without ever supporting the project in some capacity.
I’m interested to hear why you think that! I think there is something inherently wrong otherwise this wouldn’t really be a discussion… It’s easy for me to say you’re simply dismissing what I’ve written with this line and that honestly “you don’t really give a “, but being charitable I think that’s the last thing you mean. 🙂
Sure you could interpret it this way, but all I’m saying is it seems to be a problem when using hobbyist software for commercial purposes. Really nothing more. Deconstructing this could probably be put into a long written piece. I invite you to re-read what I’ve written (across all comments in this thread) from a different perspective.
One way to do it is to pick a license that’s considered radioactive by FAANG and their wanna-bees. Just stick AGPLv3 into that COPYING.md file, no one will bother you again.
Tldr: the author would like the term “supply chain” to only apply to commercial transactions.
I believe that that’s a gross oversimplification. The author is digging more into the series of obligations that functions as links in a supply chain, and contrasting that with what actually happens in open source software dependencies.
How about “the author thinks that since companies don’t use much software packaged by distros, that means due diligence work they do of vetting and approving code doesn’t count”?
No, I think it’s more that they still think it’s not a “chain”. If you’re doing the software, and the due diligence for libraries used, you’re not a chain, you’re still the responsible party. Of course that this work counts - you have to do it, because it’s on you, not on the a hobbyist author of some small library that you vetted and used.
What if you research the Debian project and the policies they use to vet software, cut releases, and the steps they take to ensure that only qualified and trusted developers have the ability to upload packages, then you decide to trust software in Debian because you trust their process, how is that not a chain of trust from one set of policies and decisions to another? You’re recognizing that you don’t have the time and resources to vet each individual package, so you delegate to another organization who does. Sounds like a chain to me.
I agree with almost all of this, just not:
Then don’t publish your package to that repository. No one is forcing you to publish there. That repository is a (free) service that is provided to the community by its maintainers and they have the right to enforce what gets published there and how. If you disagree with the conditions it’s simple–just don’t use it.
This assumes that you need to intentionally publish something to a repository though. This doesn’t hold true for multiple language ecosystems. Python allows you to pull and build git repos. Go doesn’t give you any choice either.
So you can’t decide to truly opt-out of this. The only option would be to never publish the code in the first place.
If there is no package repository, who is then deeming your software critical?
There is nothing to opt-out of, since code hosting != (managed) package repository.
The community and/or the people running the ecosystem. Not having an explicit package repository doesn’t mean there is a lack of ways to deem projects ciritcal.
If you’re providing my package through your package repository, you get to act as a gatekeeper/maintainer.
When I publish my go code on my own domain, who would (and how) implement that same role?
I think of ‘deeming critical’ as only existing within that package repository. Two competing repositories could have different ideas and commitments. What they try to convey seems to be a promise to the users of the repository & package combo - use us, we vetted things and commit to keep them running (something something analogy between rolling releases and distros maintaining LTS releases).
This is a pretty easy problem to solve by not using GitHub.
I’m no fan of Google, but it’s their right to only use open-source software whose maintainers have publicly-verifiable identities, just as its their right to take open-source software maintained by anonymous people and fork it and maintain it themselves if they really care about this but still want to use the software.
Actually Google is moving in the direction the author wants: have a more formal agreement for the “supply chain” of the software they use.
The author is free to not enter that agreement and stay a hobbyist. And then Google won’t use their software. Everybody happy?
Yes you can, though it’s clunky and also disables issues and comments.
It’s under “moderation options” in settings. You can set it so that pull requests are disable for people who aren’t explicitly added to the repo as collaborators. The catch is you can only disable it for 6 months at a time, so you have to have something or someone reset it before the 6-month mark to keep PRs disabled.
That’s so much of a nuisance that it’s effectively the same as not being able to do so.
I mean, obviously nuisance is in the eye of the beholder, but that feels pretty hyperbolic to me. At work I manage about half a dozen public repos where we don’t want outside pull requests. I spend a total of about ten minutes a year to manage these settings. I regularly waste more time than that in a single day just waiting for people to show up late to meetings.
It would be neat to be able to mark a package as “for entertainment/educational purposes only” or something so people know not to depend on it. Right now, a package is a package, and there’s not a definitive way to know whether any given library you depend on is being supported by a whole company or just some random person in a Nebraska basement. There have been various attempts to fix this issue, namely by using highly permissive open-source licenses like MIT, but when every package manager on earth defaults to that license, only the very legally-minded are probably ever going to change it.
GitHub does know about your license, so it would be a pretty awesome feature to have features (or at least sane defaults) tailored to the license you chose for your project. For example, a project using a “source-available” license would not allow pull requests, and downloads/usage would essentially be at your own risk. Either way, I think it would be helpful to be able to mark your project as open, but not “contributable”. However, I suspect GitHub won’t be doing this anytime soon, as I feel like private repositories suit this purpose as well, and would only benefit a few of us folks who enjoy developing in the open so we can share experiments.
Someone tried to make a “you can’t use this” license for their go packages:
Unsurprisingly, many, many projects were caught using it.
not exactly the same, but a similar idea for a “hostile” license. this one is more open to the idea that people WILL use it, despite the license.
I don’t think I will ever get over how many people are okay with plagiarism. I know this case is a lot less serious (she’s inviting people to plagiarize her), but still.
There is only plagiarism. Either you copy intentionally from a few sources, or you copy subconsciously from thousands of sources.
No one creates anything novel, everything we create is just “what if X but Y” and “what if I combined X and Y”.
Sadly, in our current system of copyright this is hard to represent, but that’s why e.g. the GPL is so useful.
That’s not what plagiarism means. It’s plagiarism to pass someone else’s work off as your own. Being inspired by something isn’t plagiarism, nor is using someone else’s work but attributing them, or even NOT attributing them but making it obvious to everyone it’s not your creation either. Though that’s still gross. But it’s not morally reprehensible.
I’m pretty sure it’s just conflating plagiarism and piracy - as long as you cite where you “stole” the code from and don’t claim to have written it yourself, then it’s not plagiarism.
I’m curious why you have a problem with it?
Are you really curious why someone would find plagiarism morally wrong, or do you already know and are trying to start a discussion?
There’s a lot of implicit cultural bias here. For long periods in Imperial Chinese history, it was considered extremely bad manners to claim authorship and a lot of things were published with pseudonyms. Rome had some similar periods. In Europe the notion of ‘moral rights’ (not part of US federal copyright law) appeared to codify a consensus that (if I remember correctly) came around the renaissance that authorship was important, emerging largely as a result of the patronage model for funding creative works (if you claim authorship of someone else’s work then you may get money from someone who wants to patronise them, so you are effectively stealing).
That doesn’t make plagiarism universally bad, absent of cultural context. It does mean that we’ve built a lot of other social structures that mean that plagiarism has negative consequences.
It’s a bit more complicated than that. Rabbinical Judaism, from an early era, was agonizingly thorough in giving attribution, and there are accusations of plagiarism in third century Greek texts (Heraclids 92).
Genuinely curious. Especially now that you’ve raised the stakes to morally wrong
Okay, I’ll assume you’re asking in good faith. To understand where you’re coming from, here’s a hypothetical:
Sometime goes to your blog, copies your posts, and host it on their blog. When it goes viral in your favorite communities, they take all the credit, they get all the good will, they get all the thanks. They never once mention you, or the fact they copied from you.
Is that wrong for them to do? Can they do that and still be “good Christian”?
Oh, so you’re talking about like an actively lying kind of plagarism. Which is lying. Which is morally wrong. I think I see where you’re coming from now.
Pretty much! Though now you got me curious, too. What would be an example of plagiarism you’d not consider morally wrong? It’s possible that my definition of plagiarism is much more narrow than other people’s, so things people would consider “acceptable plagiarism” would be things i would consider “not plagiarism”.
I mean, classroom plagiarism is things like reading a lot of articles, not writing down what all of them were, writing up a summary of everything you learned in your own words from your own memory, failing to include one of the sources. Teachers consider this “plagarism”
Yeah I’d consider the teachers wrong in that case. Maybe poor sourcing skills but not plagiarism.
Which I dislike. I try to be a person of good moral character, and as an individual being called a thief in the opening remarks is not… nice.
Maybe someone between trying hard and evil will use it because they didn’t notice, or if they did the moral ambiguity of stealing another person’s labor appeals to them. But I can’t ignore this paper tiger I’ve built up around the way we permit others the use of our work.
I agree with the HN comments stating that this was mean to do – the lack of any implied or express disclaimer against use in both the blog post and README file meant that people were taken by surprise by the license.
Plenty of projects are published with prose warnings of “you can look, but don’t use”. This one should have been. And the license is a great template to use on those projects, too. (Although I’d maybe add in a patent grant.)
There is a way. It’s called a license. And about 100% of them explicitly tell users not to depend on it: “THIS SOFTWARE IS PROVIDED AS IS AND ANY WARRANTIES ARE DISCLAIMED.”
There is another way, less formal, called a version number. As long as it’s 0.*, it’s clearly experimental.
The only thing about people though, they’re are going to ignore any and all warnings if the software is de-facto useful to them.
We’re solving the wrong problem here. The problem is not that users don’t know there’s no guaranteed support. And it’s not even in that users still do ask for (or demand) support when things break. The problem is that maintainers for some unfathomable reasons feel obliged to provide it. And then complain about being treated unfairly.
I used to be sympathetic to that (being an on and off maintainer myself), but not anymore. If you license your software “as is, no warranties”, do have the guts to ignore support requests and only react on things you’re personally interested in. But if you want your project to behave like a product then be clear what you want in return: money, name recognition, employment, etc.
Almost all off-the-shelf commercial software has that same all-caps AS-IS disclaimer. Even in a one-off negotiation with a vendor their liability will be strictly limited to a relatively minuscule amount.
And they happily ignore support requests they aren’t interested in, whenever they can (usually it’s trivial, since support agreement also limit the liability as much as they can).
Exactly my point. Putting some marker or legal language on a package doesn’t change how it is used.
A thousand times this.
Yeah, I agree with you 100%. The license states very clearly that I don’t have to give a shit about anyone else when I release software, it’s my own personal responsibility or will to help out that is doing all the work here.
But, as maintainers, we both know that:
It’s kinda the same argument for GitHub surfacing the license in the UI rather than just making users look for a
LICENSE.txtat the root of the repo. The license text was always there, but the fact that it’s in the UI now means it’s easier to spot and overall is easier to recognize dependencies that are on different licenses. I’m also not really thinking about this from a company’s perspective, more of a startup/hobbyist who is exploring the world of programming and is trying to ascertain what packages they should depend on. To me, a company has a whole team of people inspecting these packages and unless you’re not paying attention, it’s pretty easy to spot packages made by a company vs a “hobbyist”.Not perfect, but I use: https://www.repostatus.org/ to tag my work as WIP. It’s a fine distinction but probably some of it should be tagged as Concept, to distinguish the repositories that I intend to be used from those that I never expect.
I think this taxonomy is still missing the key component of how much shit are the maintainers giving to this. Is this a one-person-occasional-weekends kind of thing, or is there a company/community behind it, or something in between?
Somewhat authoritative information on this would at least help when making the decision of including a dependency. I try to use the GitHub pulse tab as a proxy, but it’s far from ideal.
“In actual supply chains, money is changing hands.” This is a very 20+21st century idea. There were a lot of supply chains in the 18th and 19th century (and to some extent today) where the supply just came from mother earth (timber on public lands needing consent, fishing, whaling, buffalo hunting, trapping, rubber, etc). In the whaling and timber cases those ‘free’ items went on until they got used up and/or protected.
The issue is that the concept of ownership that eventually descended upon the native peoples (with war, violence, murder, resettlement, and reeducation) eventually became the systems that the author is attempting to rectify with the ‘free’ nature of free software. I think the experiences of native peoples to colonization is directly relevant to the feeling of a hobby project becoming a lynchpin for a massive industry, ie the native tending of productive lands that produced such abundance across America. An abundance that was quickly sucked dry by the delusion of manifest destiny.
Github as native forest, commerce as colonists: https://foresthistory.org/research-explore/us-forest-service-history/u-s-forest-service-publications/general-publications/highlights-in-the-history-of-forest-conservation/table-of-contents/in-colonial-days-1607-1782/
“license.txt” is your friend here. And if you don’t want pull requests, release on gitlab or some other hosted git site that doesn’t focus on discoverability.
In security audits and legal speak they talk about “chain of custody” to refer to this thing of exchanging responsibility. A supply chain is maybe less accurate but it still captures what people want to communicate fairly well.. At the risk of sounding like a broken record; we need a way to quantify risk and measure how much we can trust dependencies. As a bonus any such solution would allow us to pay developers of free software for their work.
I don’t think that’s what they are talking about it.
The way I read it, the point of the article is that there is no supply chain because there is no chain. You write source code? You are the supplier. You added random packages from random internet websites? Still your responsibility. Even if that random library you added is a Microsoft package and they provide “guarantees” that it’ll be there for 3 years - if you don’t have an explicit contract, you’re “it”. No chain.
You bought hosted monitoring and a widget library and built it in your software? You, the monitoring company, and the widget supplier are all in the supplier chain.
See? Contract - chain. No contract - no chain. The fact that we all rely on npm and crates.io and maven central without explicit contracts just means that we accept the risk of those things going away.
But you want to quantify the risk of trusting dependencies, right? Let’s give it a try.
Option one: self-host. Add the library sources in your project, or at least in a git repo in your company. Whatever guarantees you can provide yourself are your guarantees.
Option two, use public repositories, e.g. github - you’re still it. They might provide “guarantees” but they have no obligations. Just like Heroku recently said something about not allowing free instances any more (or some such), what’s to stop Microsoft to revoke free accounts on Github?
Option 3: sign a contract with Microsoft for a paid GitHub account. Now we’re talking. Now we’re in business. You can host stuff there and you can count on contract guarantees (however many nines, LTS schedules, whatever).
My point is that the article talks not about how we cannot rely on “supply chains” - we can do that already with a contract. They (the author) are not part of that chain, and if you are doing ANY risk analysis, you have to start with “I am pulling software from publicly available but privately owned random internet websites”. What you say is you want to quantify the risks of, say, Microsoft stopping free github access. I think that may help a little, but not much. The person publishing the code can still just delete it at any time.
The chain is there it is just not explicit. Where did your data come from? where does it go? Access control is a thing..
Sure, you’ve taken on that responsibility. However you can pin this dependency (and many companies do pin their dependencies and drift out of sync with the upstream since they don’t want to be auditing every feature that they don’t need or use).
Sure. Now what is a contract? Because the way I see it the legitimacy of the contract is derived from the legitimacy of the courts that will be enforcing it. I don’t see why we cannot build legitimacy around free software where we keep track of cryptographic commitments. Enforcement would of course be some kind of decentralized “cancel culture” that we see running rampant these days through social media.
The options you name are nonsensical fwict. You assume you are alone whereas there is no chain of custody when there is only one individual / organization involved. The whole point is that we have a symmetric problem here. Everyone needs to assess their dependencies and that work can be meaningful to others.
When someone reviews some code and gives me a cryptographic commitment with their assessment then that has meaning with relation to the trust this individual has built in their reputation.
Look at the darknet drug dealers; when a vendor has built up trust they get more orders, now if they get too many orders at any one point then the amount they have in hand may be worth more than the ongoing profit from their good reputation. This is why we call the scenario where the dealer dissappears with the money a “retirement attack” … the dealer throws their reputation away to take the money without fulfilling orders. This means that the customers are not well enough coordinated to decide if they can put money on the table, in order to be secure the customers would both need an accurate assessment of the worth of the reputation as well as a general idea of how “hot” the dealer is at the moment (how many outstanding orders).
No. We cannot. This is the whole issue of our current economic system. We cannot motivate contributions to the commons with a centrally coordinated system unless the participants can motivate the coordinator with a sufficiently realistic threat. Currently this is not the case (or we would see a lot of government money going into free software).
The “we” I am talking about is the free software community. We have all sorts of package repositories but no contract.. and we will not have a contract because the people who make free software shouldn’t need to ask for permission to write some code (or use someone’s elses code).
I want to quantify the risk of using a certain version of a software (that anyone can contribute to) and reward the people who make contributions that are perceived as legitimate by other participants in the coordination of the versioning of that software (sorry for the mouthful). This will require a bit of a shift in foundations but it should lead to more wholesome incentives in the software industry.
I don’t want to dispute your points, but I still think we’re talking past each other. You’re saying that there is an implicit supply chain, and I’m not. But i think we’re talking about different points here - you’re taking about a company implicitly relying on an inherently unstable structure, technically and otherwise, to achieve their business goals.
And the point the article is making (and I largely agree with), is that that is fundamentally not a supply chain. It’s not a good analogy. If the said company paid GitHub to host the software and the developer to develop it, then you have a logistic supply chain (in the usual sense of the word). You can make plans around it and budget with it. And in the plans, they rely on their supply chain to fulfill stuff for them. Yes, things can still go wrong, but you can build in some redundancies, alone or with those partners, but generally your fulfillment plan depends on theirs.
If you pick up open source software on their own tedhough, and relied on the developer not pulling the software and GitHub not kicking them if the platform or whatever, then there is no chain. Your fulfillment is on you alone. And you can still build redundancies, and things like you mentioned, like pinning dependencies, are that, but you’re not planning on a random hobbyist developer to be delivering on time, or pulling left-pad from npm or anything; you’re in charge and you need to secure that.
I think that’s the point of the article, at least.
Yeah I see, fwiw I also had the feeling that we were talking past each other but the intersection of what we are talking about is this nebulous concept of responsibility and how it relates to FOSS. I agree that when it comes to physical resources such as servers and their uptime then we are firmly in the world of contracts and companies but as soon as you start talking about the software itself and development of it then we get more into the domain that I was trying to verbalise. Risk, responsibility and money go hand in hand in hand.
The emperor does not, in fact, wear clothing.
Trying to quantify risks needs to come an amount of “For $x, we can eliminate a risk that has about a %y annual chance of costing us $z.”
The current question is different. “How much will it cost to meet the absolute minimum of new federal regulations?”
A software supply chain is a system and I think of systems as something within which between its connected components there’s a flow of material, money, energy, information or a mix of all. (Not a unique thought of mine, I read it somewhere and it stuck with me). As such, here is my disagreement with the author:
I view the abandonment of an open source project, for whatever reason, the same way as for example a supplier of goods defaulting. No recourse there also. There’s a risk in every decision and sometimes it materializes. And recourse is small consolation if I cannot ship the product.
I totally sympathize with the feelings triggered by effort dehumanization and the frustration, but the truth is that sometimes you’re stuck with the equipment long after the original supplier (and sometimes subsequent maintainers) stopped supporting it. Such equipment can be anything from a washer from 1970 that still operates to a piece of software that is left unmaintained because the author does not feel like it any more.
If I can put it in a diagram that shows the flow of information in my system, then it is in the chain. If it was built externally, or I take it from an external repo, this is my supply chain and I need to secure it. I, not the supplier necessarily.
I think this is the entire point. If you need to secure it, it’s not a chain. It’s still just one node - you. And yes, things in your supply chain can default or dissapear, but this is a regular business risk and you can, e.g. insure yourself against it, or have a redundancy with a different contract.
If you have a washer from the nineties, that’s still not a chain - you’re still alone. I think that was the point of the article. We should not rely on external parties to manage our “chain” unless we make it so by contract.
I feel that, with the safety goals and guarantees of Rust, it’s going to be finally possible to move away from “All warranties are disclaimed” and towards a “Professional responsibility” model where we, as software writers, are finally confident enough in our work to say that yes, it is fit for a particular purpose.
I’m struggling to see how Rust enters into this. Rust code can still have buggy business logic or solve the wrong problem or lack critical features or inadvertently violate regulations when used. For me, at least, the question of whether I volunteer to let people sue me if my code is wrong is about those kinds of things, not really about things like memory safety or concurrency bugs.
I like that the Rust ecosystem tends to be focused on correctness, but the license text is not really about software quality, but about not getting sued by a random user for whatever reason. Professional responsibility should come with a paid support contract.
The biggest problem with professional responsibility is that to guarantee fitness for a particular purpose, one needs to specify exactly what that purpose is. With non-embedded software products, there is simply no way to declare any guarantees without opening up possibilities to accuse you for things completely out of your control.
Even in fields where products are marketed for specific purposes, not everything is that simple. If you are marketing drops for runny nose and they fail to help anyone with their runny nose, or people get nasal mucosa burns instead, then sure, you are liable. But off-label use of medications is widespread and hardly any of drug manufacturers are willing to accept liability for it. Some certainly will say “and rightfully so”, and I can’t really blame them.
If you are shipping a box, it’s possible to make some guarantees, like “if you connect it to a 110-220V/50-60Hz power grid, it will not explode”. It’s also possible to guarantee that certain inputs will always produce certain outputs and specify the range of acceptable inputs.
But with code, there’s always a possibility that someone will run it on a DeathStation 9000 and blame you rather than their insane environment, because developers of the insane environment put in necessary disclaimers and you didn’t. ;)
So, professional responsibility should not only come with a paid contract, there should also be an exhaustive lists of usage conditions when that responsibility applies.
Really? Why do you think Rust will make such a bug difference?
We’ve had Ada/SPARK since the 1980s, and many other systems for proving correctness of programs, many of which have been used successfully to create safety-critical software for decades.
Rust is great for writing memory-safe native code without a garbage collector… but I don’t see why that would suddenly cause software writers to be “confident enough in our work to say that yes, it is fit for a particular purpose” if they weren’t already.
Absolutely not in this case. The author is specifically talking about “unpaid hobbyists” who are publishing “weekend hacks” “so that other hobbyists can use and learn from it”, and who “otherwise want to be left the hell alone”.
There is no professional responsibility if you are publishing a hack that you wrote for your own amusement, and you don’t have a contract with a customer, and you aren’t being paid. Even if the hack is written in Rust.
I love Rust, but Rust is only an improvement over systems languages such as C++.
The guarantees provided by Rust are still far from what can achieved by, say, Dafny or F*.
ADA’s SPARK and other formally verified proof systems have a way better chance of this than vanilla Rust.
If we want a professional responsibility model, we’d need to be actual professionals.
As of right now, there is no credentialing system in place at all for software developers. I was a physics student who enjoyed tinkering a little too much, maybe someone else graduated from a bootcamp, someone else took a community college course, whatever. In order for software developers to be able to sign off on work as being fit for purpose, someone else needs to be able to sign off on us.
And frankly, as a community I don’t think we want that. Sure, it would be nice to have some sort of filter sometimes, especially in hiring and in evaluating dependencies, but on the other hand the absolute wild west nature of software is most of the fun.