Hacker News Reader

I'm going to disagree, I think. The problem isn't on the push side, it's on the pull side. People throwing random-quality code in github is fine. People deciding to amalgamate that into distributions and publish it is fine. The problem is that somewhere someone who is supposed to be held to some standard decided to pull that code in without looking at it, and that is the problem. NO WARRANTY is partially about legal issues, but not exclusively - if people share their code for free, they don't owe anyone anything. If you don't like that, you're free to offer them enough money to actually accept your standards.

I think a lot of people will disagree, which is cool and I'm fine with that but I do hope that this discussion can be had.

> The problem is that somewhere someone who is supposed to be held to some standard decided to pull that code in without looking at it

Why is it that there is no standard applied to those who publish code for distribution purposes? Why do we want that to be the case? Again, publishing to Github or some source repository is fine, that should never ever be restricted, but publishing with the express intent for others to use it? I don't get why we're trying to ensure that that's something that shouldn't at least imply the bare minimum of assurances.

> if people share their code for free, they don't owe anyone anything

My point is that they don't legally owe anyone anything but we should impose a moral standard in lieu of a legal one. If you are saying "here's this code, I've packaged it up and sent it out for distribution" I think it should be perfectly fine for us to say "did you do the bare minimum to make this code acceptable for others to use?".

I don't get why we say "you have no ethical obligations in open source", why do we do that? Who benefits? I get not having legal obligations, but once you're distributing code for use it seems absurd to say that you have no ethical obligations. You chose to do that, you chose to distribute it, you didn't have to do that.

And while I do think that the obligation exists regardless, I also feel that if we don't step it up here, these things are going to be forced on us. I'd rather we do it ourselves.

> but we should impose a moral standard in lieu of a legal one

I agree with you, but these moral obligations tend to get enshrined in law eventually (or quickly! See Covid)

They're gonna get enshrined into law eventually one way or the other. If we do it ourselves and we're effective at limiting the damage we cause we'll be able to maintain control over our own processes. If we don't it will be taken out of our hands.

> If we don't it will be taken out of our hands.

Which will take the code out of theirs. Disincentivize sharing, and sharing goes away.

> Disincentivize sharing, and sharing goes away.

And existing proprietary software companies will rejoice, as the barrier to entry in the software market will again be very high.

> Why is it that there is no standard applied to those who publish code for distribution purposes?

Because it's rude to make demands of someone who is doing you a favor.

Because a system that adds costs to profit-free work will collapse.

Because your "distribution" line-in-the-sand doesn't exist. I assume you're thinking of NPM or pypi, but ex. Debian doesn't ask people before including their packages, and ex. nixos pulls directly from those "non-distribution" channels.

> My point is that they don't legally owe anyone anything but we should impose a moral standard in lieu of a legal one. If you are saying "here's this code, I've packaged it up and sent it out for distribution" I think it should be perfectly fine for us to say "did you do the bare minimum to make this code acceptable for others to use?".

Okay; let's also make a moral standard of paying people when we derive value from their work. I think it should be perfectly fine for us to say "did you do the bare minimum to repay the person who gave you this code to use?".

> I don't get why we say "you have no ethical obligations in open source", why do we do that? Who benefits? I get not having legal obligations, but once you're distributing code for use it seems absurd to say that you have no ethical obligations.

We do that because we benefit. Making things easy for the people who are giving their work away for free helps foster an ecosystem where people keep giving stuff away for free.

> You chose to do that, you chose to distribute it, you didn't have to do that.

Yes, that's the point. We'd like people to keep giving things away even though they don't have to. If you try to impose costs on them for doing that, you'll alter the incentives so that they do the rational thing and stop giving stuff away, and/or start charging for it.

> Debian doesn't ask people before including their packages, and ex. nixos pulls directly from those "non-distribution" channels.

Then Debian (or NixOS) are publishing the code for distribution, and Debian (or NixOS) should be morally obligated to do the bare minimum to make the code acceptable for others to use.

no

> Because your "distribution" line-in-the-sand doesn't exist. I assume you're thinking of NPM or pypi, but ex. Debian doesn't ask people before including their packages, and ex. nixos pulls directly from those "non-distribution" channels.

Correct, I'm talking about publishing to a package index. The fact that the line is murky right now isn't important, that's exactly the sort of thing we should be clarifying and changing.

> Okay; let's also make a moral standard of paying people when we derive value from their work. I think it should be perfectly fine for us to say "did you do the bare minimum to repay the person who gave you this code to use?".

I don't think it's an "either/or" situation, the two are not exclusive. I would like to see more funding for open source software, but that doesn't solve the fundamental issue. It's also extremely hand-wavy. Do I pay you a monthly stipend to implement 2FA?

It also assumes that open source developers aren't getting "paid". They are. Github is free, PyPI is free. You are using services for free, that is a form of payment, or at least a social contract between various developers. So it should be reasonable then to negotiate that contract, eg: PyPI saying "if you use us as a distributor of your code, we need you to enable 2FA", which they now do.

> We do that because we benefit.

Who's we? Because a lot of people don't benefit. When there's a supply chain compromise because a developer used a weak password and no 2FA people are harmed.

> We'd like people to keep giving things away even though they don't have to. If you try to impose costs on them for doing that, you'll alter the incentives so that they do the rational thing and stop giving stuff away, and/or start charging for it.

Of course, and I'd like to keep those incentives as much as possible. I think there is a very happy medium here that isn't strictly "if I publish open source code for distribution I can do no wrong whatsoever, I have no obligations whatsoever". PyPI and other distributors now enforce that if your code gets to be very popular you must enable 2FA. That is a cost, but it's a very minimal cost targeted to a small group.

What I'm advocating for is that we standardize a set of responsibilities as an industry for those who distribute code. They can be very minimal and still have massive impact.

The alternative, in my opinion, is that we'll see increased regulation, because these problems aren't going away and they're going to get worse if we don't collectively try to improve.

> Why is it that there is no standard applied to those who publish code for distribution purposes?

What does "publish code for distribution purposes" mean? That sounds like all published code.

Does that mean that I can't put my own hobby code up in public? That's a sure-fire way to kill the community dead.

> You chose to do that, you chose to distribute it, you didn't have to do that.

I think the burden is more properly on the people who choose to download and use it, knowing what it is.

Do you demand that every screwmaker make aircraft-grade screws? Aircraft makers need screws and it would be very convenient to them to be able to go down to any hardware store and just buy whatever screw they want since they are all up to spec. No need to evaluate their suppliers since everybody is required to make things up to their demanding standards.

The problem with this is that not everybody needs expensive aircraft-grade screws. Most people only need hobbyist-grade screws, or construction-grade screws. The requirements depend on their usage and it is up to the consumer to correctly identify their requirements and use the appropriate product that is fit for purpose.

The problem with software today is the rampant, careless usage of hobbyist-grade dependencies in critical software. It is the fault of the entities including dependencies that are explicitly hobbyist-grade or inadequate for purpose that poses a problem. It should not be the responsibility of makers of hobbyist-grade screws to produce aircraft-grade screws because the aircraft makers want to go to Home Depot and pick out whatever screw is the cheapest.

The solution that matters today is holding the consumers of these endless software dependencies to task for the usage of substandard or even defective software components, whether open source or proprietary, like every other industry where you must use suppliers that are fit for purpose. To demand a change to the software that is explicitly marked as unfit for purpose is to solve the problem of a aircraft manufacturer using screws from Home Depot by making Home Depot required to only stock aircraft-grade screws while demanding they keep the prices the same.

I'm quite sure that screws are indeed something that, if made in a shoddy way, would have legal repercussions for those producing them. That's the norm - it's software that's weird for not having that. I would actually expect screws are even rated for specific work. Also, people sell screws, so the analogy really makes no sense.

I'm not suggesting that software developers be required to do anything if they're just writing code, and I'm not suggesting that they do things to some sort of extreme, as you seem to be implying, if they do distribute their code for use.

> explicitly hobbyist-grade or inadequate for purpose that poses a problem

Well, no, they're not explicitly hobbyist-grade. That would be fine if someone were just publishing code and saying "don't use this", but they are publishing code for distribution to package repositories. They don't have to do that, they could just leave it as open source code that isn't distributed, and note that it's not production quality explicitly as you suggest.

Perhaps a more appropriate analogy would be if you were making dinner. You go to the farmer's market and someone with a booth their says "I'm giving away some free fruit, here you go". You would hope that someone who set up a stand at the market would be giving you fruit that's edible. If you went home and ate it, and then you got sick because it didn't meet food quality standards, you would not be the one liable, the vendor would be. "But the vendor gave it away for free!" Yes, but other than software the person giving you something is in fact liable for its quality.

Anyway, analogies suck, I'm sure this misses plenty of important bits. Rather than argue about analogies, let's clarify the actual argument.

1. No one forces anyone to publish their code for distribution purposes

2. When you publish code with the intent for others to use it there should be an obligation to provide basic quality standards to avoid that code doing others harm

no.

Package repositories were never intended nor designed for anything other than hobbyist grade software. The have never offered any guarantees on the quality of their contents and in fact the vast majority of their contents are freely accepted without review and explicitly disclaim any fitness such as via Clause 15 of the GPLv3[1]:

"THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION."

If the quality of a package is not positively asserted, then it must be assumed to be hobbyist-grade regardless of how others wrongly treat it, how convenient it would be to assume it is not, or even if the quality is high but no explicit positive guarantee has been made to that effect. It is ultimately the responsibility of the users of a package to verify it is fit for purpose which demands either a positive, legally binding guarantee from the package creator or a assessment of the package itself (which would be easy if the quality is high, but no explicit guarantee was provided). To use a package while expecting guarantees on its function when it explicitly disclaims any guarantees is to use the package wrongly no matter how many others may do so and it is a problem with the user of the package, not the creator of the package who accurately advertised the quality of their package. It is the recognition of this fact and the usage of components that have actual guarantees about fitness for purpose that distinguish civil engineering from software development, not the quality of the underlying components; the quality of the underlying components follows naturally once liability is accepted and guarantees are required.

[1]: https://www.gnu.org/licenses/gpl-3.0.en.html

I'm not arguing, but the standard response (caveat emptor, basically):

> pull that code in without looking at it

Is no longer reasonable. The dependency chains are too vast to expect the end-user to be able to audit the whole thing.

There are a couple of options:

1) Don't use open-source code, and make sure that commercial code that you use doesn't have it.

2) Have some kind of "regulated middleman" auditors, or certification authorities, that can certify (and probably hash) "approved" open-source chains.

They both suck. I worked for a company that did #1. They hired a company (can't remember the name, but it started with "P") that scanned our entire codebase, looking for open source.

#2 is likely to result in either corruption, or "roadblocks," where we can't use new fixed libraries, because the chain hasn't been audited, yet.

It sounds like you want to get something for nothing. If you want software that meets some given standard, then someone has to invest the effort to make that happen. This isn't always expensive, but it's never free. So your options are indeed that if that should happen, then it has to be done by the author, an intermediate party, or the consumer. Trying to make the author pay when they're not getting anything out of it is a great way to kill FOSS outright. That's not to say that "open-source code" is some boogeyman that has to be kept away, it just means that you gotta pay someone to make it meet your standards. Heck, offer the original author a contract and you'll solve the problem for everyone, and other problems besides.

> It sounds like you want to get something for nothing.

Not exactly sure how you read that from what I wrote. Maybe you were replying to someone else?

#1 is definitely not free. My company paid a bundle for that audit; far more, than if they had simply licensed commercial software.

#2 would require some kind of paid “middlemen.” The biggest problem would be that the money would not go to the authors, but to the auditors, instead.

> Is no longer reasonable. The dependency chains are too vast to expect the end-user to be able to audit the whole thing.

The end user shouldn't have to audit the whole thing. The software that includes the dependencies should audit their dependencies.

If that burden is unworkable (and in a lot of cases, it is), that's a sign that the software needs to shed a lot of the dependencies.

>> pull that code in without looking at it

> Is no longer reasonable. The dependency chains are too vast to expect the end-user to be able to audit the whole thing.

Each open source project is different. For example I'm using:

Racket: Only the main distribution that is created by the development team and a few packages, and ver few additional packages, like 1 or 2 for viewing the assembler version of the compiled functions.

Python: Also only the official distribution, NumPy and perhaps 1 or 2 more packages. The batteries are included, so it's not necessary to download too much.

LaTeX: As many packages as I can add, my coworkers hate me. Each package has a different author and chains to more and more packages. But I'm using MiKTeX and I thrust the maintainer whoever he is [1]

[1] I had to google the name of the maintainer. He is Christian Schenk, I was convinced his name was Michael or something like that.

I think the first step should be making a conceptual separation between developers and distributors, even when they are just different roles of the same person. A developer can share code with other developers, but once you start sharing the code to a wide audience, you are acting as a distributor.

Consumer protection laws tend to expect that consumer products should be safe by default. Products intended for professionals and businesses often have fewer requirements, but they should also be safe with reasonable precautions. Someone in the supply chain must take responsibility for that.

As is common in legal matters, this is more about intentions and reasonable expectations than exact definitions. GitHub can probably avoid responsibility by arguing that it's just a platform that allows developers to share their code. If you are hosting a popular package repository for some programming language, you must take some responsibility as the distributor, even if your users can be reasonably expected to be sophisticated. And if you are hosting a package repository for a consumer OS, you should probably take consumer protection laws into account.

> It is absurd that anyone can anonymously provide open source code, with no assurances whatsoever, and that can end up in critical software.

While you're welcome your position and your ideas on how to solve these problems, I believe that the logic you're applying punishes the provider and not the consumer. Nobody is forcing anyone to use OSS without auditing every damn line, if that's their requirement.

Telling people that share their hard work with strangers for free that they have an ethical responsibility to accept vague "obligations" - as defined by lobbyists and politicians - is not an idea with wings.

Nobody is telling them to share their work and distribute it to others as a package. As I said, I don't think there should be any restrictions on anyone to publish code.

I don't know what your background or interest in this issue is, but I'm glad that the overwhelming majority of people do not find this perspective to be reasonable or compelling.

In the meantime, if you don't like the MIT license, don't use software published under it.

Licensing is completely irrelevant to this discussion.

I don't entirely agree with you (nor do I totally disagree), but I wish this comment was not so heavily downvoted. This is a good perspective worth discussion. Importantly, this is also how a lot of people outside the industry will see it.

> Modern civic engineers went without any significant regulation, and then that changed

There is no analogy. The only reason why other engineering disciplines are not adopting software practices is because the other engineering fields are not easy to iterate. You build a bridge. And then you could maybe get some funding to improve one part of it a decade afterwards. Because it is too expensive and cumbersome to do it.

When IoT, AI, nanomachines, 3D printing proliferate, you will see how that will change. Devices and buildings will be possible to iterate, and they will have versions that get incremented as they are improved.

...

As for obligations, the existing law already covers it. From GDPR to payments compliance, everything is there. And a lot of the best practices are invented and standardized by Open Source, actually.

...

What Open Source still lacks is the mindset to approach end-users and consumers and be able to get them on board. Open Source needs to take the route of 'no backwards compatible changes', and even 'add, never deprecate' (like JSON project) along with the habit of hiding complexity from end users and making things easy.

Then we can create a truly Open Source world in which there will be infinite new possibilities.