I think it could be both a user and an industry issue.

Lately I’ve been experimenting with treating many libraries as a starting point in some of my projects. Meaning I read and use the code, often removing things I don’t need.

So I fork and maintain my own lesser / crippled version (and hope authors don’t take this as passive aggressive criticism!). This helps me lower attack surface and better understand what’s going on.

This doesn’t work for everything obviously. I’m not forking an OS or database, so there are still lots of black boxes, but for some stuff for I’m liking this approach.

Now if another dev inherits my code I doubt they’ll see it my way. The industry wisdom points at simply assembling libraries and only writing your specific business logic. So what if you use a library to do one thing that just happens to do 100 other things (this having a much larger attack surface and bug potential)?

I don’t know yet if I’m being foolish or if I’ve stumbled on some ancient programmer wisdom I simply failed to grasp earlier. At least I’ll probably never run into a leftpad issue.

> So what if you use a library to do one thing that just happens to do 100 other things (this having a much larger attack surface and bug potential)?

I’ve wondered about this for a while, and one idea that’s crossed my mind is whether compiler stages could be introduced to do this. For example, you add a dependency, you use a few methods and structures. You compile it, the compiler goes through your code, looks at what traits, implementations, etc that you do and don’t use, it grabs just the code required to satisfy these, and proceeds as normal. At the end it spits out a little report for you telling you what specific things it included/excluded from your binary/library. Like tree-shaking in JS but better.

Maybe this already happens during dead-code-elimination passes, or during some other compiler step, maybe most of our libraries are far too interconnected/non-modular to be able to do this without ending up with the whole dependency anyway, maybe it’s computationally infeasible due to some result in Computer Science, I don’t know-and wouldn’t really know where to look to find out-but if it could be done, and if we could go even further to embed this metadata into the resulting binary itself, we’d at least have a provable way of saying “my application is safe from x because it does not include <vulnerable part of lib y>”.

I imagine to do this, you’d need to operate on source code-unless there’s some magic way to do it with precompiled binaries-and runtime dynamism would make things extra difficult, but it’s an interesting idea.

This is pretty normal for compiled languages like C, C++, and Rust; the linker will throw out functions and classes that aren't used. In Java it's a bit different, because the compiler doesn't know if some code is using reflection to talk to some other code, so it can't safely throw away stuff that isn't directly referenced. Even then, tools like ProGuard can help you trim out code you don't use, but I don't think they're used all that often outside of mobile.

But the log4j thing really isn't in the same class because it's not really "code that wasn't used". It's code that probably users didn't expect was there, and if they knew would probably not want used, but it's there, and the proper functioning of the library included that code path that allowed for JNDI interpolation. Whether or not that code is really "needed" is not something the compiler can really figure out, at least not without teaching the compiler that very very very specific thing (which would be madness). And even then, let's say you bizarrely wanted to be able to do things very much like what the log4j exploits do, there's no way the compiler (or even some kind of specific purpose-built code scanner) can know whether or not some string that might be supplied by a user in the future is going to trigger this JNDI interpolation code.

I've been thinking about this too. Most of my JVM projects use slf4j and logback, but the same concept applies as for log4j. I probably use less than 10% of the features provided.

I log strings at different logging levels, and want to be able to set the level globally at which log lines actually get emitted. My use of interpolation is dirt-simple: I just expect the logging framework to call ".toString()" on the things I pass. I log exceptions, and expect the framework to emit a stack trace in addition to the exception message. I log to stdout, and use pretty much the same log-line format for everything. I like the loggers to be named, and occasionally use the ability to change the log level on a per-logger basis.

I could build this set of features in... I dunno, a day? Sure, it would take me a lot longer to build the entirety of slf4j+logback, or log4j, but I don't need 90% of their features. So, yeah, I'll continue to just use slf4j+logback (hell, maybe I should use slf4j-simple); the idea of writing my own simple logging library doesn't really interest me all that much, even if it wouldn't be too hard to do so. But I'm still carrying around all this extra attack surface, and that's unfortunate.

Yes I generally use a similar strategy of avoiding dependencies and writing my own small library that does what I need. I also appreciate learning exactly what’s going on.

> Now if another dev inherits my code I doubt they’ll see it my way. . . . I don’t know yet if I’m being foolish or if I’ve stumbled on some ancient programmer wisdom

I have the same fear here. Lately I’ve been trying to keep a similar api to popular libraries so it would be easy to swap in the real library if ever needed.

But yes “at least I’ll probably never run into a leftpad issue.”

This cultural expectation follows naturally from the nature of software. Software (especially of the networked variety) isn't something you can just deploy and be done. It has to be maintained to continue running over time as the ecosystem changes. The cost of this maintenance is lowest when amortized across the largest set of users, hence the success of open source software, and the desire to avoid forks. The people who are most qualified to maintain software are the original creators, so that is the path of least resistance.

Of course no one is obligated to maintain anything, open source maintainers abandon stuff all the time without any repercussions beyond passive internet rage.

Yep. The puppy analogy falls apart when you've given the same puppy to 10,000 people. All of them could pay the vet bill separately, but we instinctively recoil from that as being horribly inefficient (and personally inconvenient) when it's possible for just the one puppy-giver to pay it.

> Why is the responsibility for changing the package anyone but theirs, the people using it; now that they're decided they have stricter requirements for that need?

It isn't. Every open source consumer is ultimately responsible for the use of the code. That's baked into every open source license I'm aware of. Even the "share and enjoy" mantra is a tongue-in-cheek reference to a rhyme that ends with recommending what porcine orifices you can put your head on if you don't like the software.

... But there's more to be gained by the original authors, in glory and internet points, by publishing a fix for the problem than in washing their hands of the whole affair. Some people want their code correct as a point of professional pride alone.

> Even the "share and enjoy" mantra is a tongue-in-cheek reference to a rhyme

I don't know of any rhyme, but I always assumed that this was a reference to the Hitchhiker's Guide and Sirius Cybernetics Corporation. Which, yes, does involve a pig: https://www.goodreads.com/quotes/95859-share-and-enjoy-is-th...

Sirus Cybernetics Corporation was best known for having created Marvin, the depressed android, and doors with cheerful personalities:

> “All the doors in this spaceship have a cheerful and sunny disposition. It is their pleasure to open for you, and their satisfaction to close again with the knowledge of a job well done.”

So yes, "Share and enjoy" was originally deeply drenched in irony, and it functioned as a warning to proceed at the user's own risk.

It's not just internet points, it's what makes the whole thing practically viable.

If you don't give any guarantees beside "it's a hobby project", you can't expect anyone else to use your software beyond hobby projects either.

> If you don't give any guarantees beside "it's a hobby project", you can't expect anyone else to use your software beyond hobby projects either.

I am happy to provide consulting services and support guarantees through my LLC, and have done so in the past.

Non-paying users who ask nicely might get fixes. Or they might not! Unfortunately, those fixes might also arrive a year or two after they stopped caring, I'm sad to say.

But a project which doesn't bring me any revenue, and which doesn't function as valuable advertising, is only going to receive support when I have the time and the inclination.

Realistically, commerical adoption is only interesting to me if there's some upside for me. This isn't to say that companies should never use my libraries or tools. Just that if they want timely support, they should be prepared to either pay me, or use the "Fork" button.

Or it's the opposite. I've had people base their business operations on my clearly marked hobby project. And then they started being nasty when I stopped updating it.

> If you don't give any guarantees beside "it's a hobby project", you can't expect anyone else to use your software beyond hobby projects either.

Can't speak for log4j, but I don't expect anyone to use my SW beyond hobby projects. If they do, I expect them to be responsible for how they use it.

> If you don't give any guarantees beside "it's a hobby project", you can't expect anyone else to use your software beyond hobby projects either.

That's a good thing. The companies shouldn't be expecting free code and free support. If they want something for a commercial product, pay for a commercial library with a support contract.

Reviewing code is (should be) significant less work than reimplementing it yourself, if you were able to do it in the first place.

> If I give you a puppy, and it gets sick, should the vet bill me?

> If I gave you a car, and the wheels fall off two years later, is that my problem?

So in Western culture there's this notion that a gift creates no further obligations. The recipient should just be happy he got what he got and not expect anything more. As if to say, at least you didn't get nothing, you can still get nothing, you want nothing?

I would say with the puppy if it gets sick and the recipient can't afford it, you should accept paying the bill. Before it was the "giftee's" puppy, it was your puppy for some small amount of time after you got it and before you gave it. Surely when you gave me a puppy you expected me to be able to keep it alive, right? And as for the car, it's not right to give someone a car whose maintenance they can't afford. The puppy and the car are two excellent examples of gifts that cannot be given without forming a relationship between the giver and the receiver.

On the other hand a gift you can give and split and that's it is food or money. Just handing money to a beggar, he might ask for more, and you can walk.

In some African cultures it's more like, if you do me a favor, do me another favor, and then we're true blue and you can rely on me to help you in return, but never in a tit-for-tat manner. It's in the book Debt: The First 5000 Years.

The software library in question wasn’t gifted. It was made open/available for re-use from a library.

The person who chose to put it into _their_ code took ownership of its ongoing maintenance in their instance of its usage (presumably because they felt that would be less work than entirely diy).

There is no puppy here.

It's prudent to decline a gift if one doesn't really have the circumstance to accept it responsibly. As in the case of a puppy. Or an offered position. (Eg. if someone shows up at your doorstep and gifts you a military rank and accepting that would make people to expect you to go and lead them in battle.)

But a car is not a liability. They can sell it. It won't "go bad like a puppy" if it just sits in a garage.

A car is a liability. And it does go bad if it sits in the garage, the tires, the battery dies...Plus the space it takes up. Maybe if you didn't have that car in your garage you could do something interesting with that garage, like form Hewlett-Packard or Apple? I expect there wasn't a car in those garages. So it takes up space, about the same as what you need to house someone, and if you want to sell it you I suppose have to drive it...no I guess you're right in that regard, you can show it to people until you sell it. But it's better to regift it, so you're not responsible for harm that could come from bad condition, in fact come to think if there's no trust it might itself be a regift. Yeah, it's a liability.

Worst case scenario, you can throw the car away. You had no car before receiving it as a gift, you'll be not worse off if you throw it away. The dog is a little worse because you may become attached and in general, you can't really treat animals like objects in our society.

Throw the car away how? What type of garbage do you put it with, recycling or compost?

You can get it towed to a junkyard and they will even pay you a little bit for it, probably enough to at least pay for the towing costs. Otherwise, I’m sure you can arrange something with your council.

Is that true? I would expect that most junkyards would charge you both for towing and scrapping the car.

(Granted, nowadays, due to the supply chain issues and component shortages, people will pay an arm and a leg for a car that even barely runs, so there's that.)

They won't tow it for you. But they will usually pay for your car if it's in any reasonable condition, though not a lot. Maybe it's different in different countries

You can still sell the parts years and years later. No garage necessary. No driver's license required. If someone gives you a car unless it's a total junk you can easily convert it to money, and the time pressure is completely different compared to a pet.

The moment you accept the pet you have to think about everything in your future for years. You accept a car? Okay, you might not even see it, maybe you just get a paper and a key fob and an address. And you don't have to do anything for years. Nothing happens morally.

The examples are a bit one sided.

If I give you covid, is that my responsibility?

If I give you a piece of software with a backdoor in it, is that my problem?

In reality, all actions carry various kinds of responsibilities. And well designed backdoors looks exactly like oversights, so the difference isn't all that clear cut in pratice.

I mean, it depends?

If you give me covid, and you did so intentionally or negligently (as in, you knew you had it and yet did not isolate or at least tell me you have it so I can decide not to meet with you), then yes, that absolutely is your responsibility. But if you contracted covid from a trip to the grocery store, were asymptomatic, had no idea you had it, and I got it from you, I certainly wouldn't hold you responsible.

The software-with-backdoor bit is similar. Did you put the backdoor there, and then give me the software with the intent to later use the backdoor against me? That may not be your "problem", but it's certainly your responsibility. Or did a contributor sneak a backdoor into the software, but, despite your best efforts, you missed it? I'd be upset, and might trust your technical judgment less, but I would hold the contributor responsible, not you.

> In reality, all actions carry various kinds of responsibilities.

Yeah. Going back to the covid example, I could imagine an intermediate situation where you didn't know you were infected, but for the past months you'd been engaging in all sorts of risky behaviors: not getting vaccinated, no social distancing, no masking in crowded indoor places, hanging out with unvaccinated people in close quarters, etc., then I'm probably not going to react as severely as if you deliberately gave it to me, or knew you had it and didn't warn me, but I'm certainly not going to hold you blameless either.

So... this is essentially a cultural question, so I think the best way to look at it is empirically.

Not exactly your question, but there's an anthropological pattern whereby gift exchange between individuals of disparate class or power (eg peasant & lord) automatically create a tradition. If a boss gives his employees a turkey for christmas, christmas turkeys become a permanent expectation. If a lord give his king 20 camels for spring equinox, this can easily escalate into a permanent tax.

I know a former software developer who is very open about going to therapy. He once commented on this fact, saying that he knew someone who also talked openly about therapy, and that he never would have gone if they hadn't known this person. Essentially he's hoping to be 'that guy' for somebody else.

Computer science, to people who are picking college degrees, seems like a safe, sterile environment of pure logic. But the only jobs are in software development, which is organic as hell. It's messy, it often smells, sometimes it rots. And sometimes it's just scary. A lot of people seem to be in denial about this for a long time.

Software is full of social capital and emotions, and we often try to conceal both behind a mask of objective thought. I can tell you ten logical reasons we shouldn't write the code this way but the real problem is that I think your solution is going to leave me stressed out of my comfort zone and/or missing life events because I either can't trust that you'll clean up your own mess, or that the business won't let you because you can't do it fast or robust enough. So I'm gonna argue with you about getting anywhere near that cliff edge, but we're not going to talk about the proverbial agoraphobia because that's too hard.

And if my logical, objective, sterile reasons for saying 'no' are deflected, odds are very good I'm going to acquiesce instead of actually agree, and I'll be secretly stressed, possibly grumpy, possibly even ready with an 'I told you so.' All while we're trying to keep hard things 'professional'.

Your solution is nerve wracking. This one is not. We should use this one, because we have better things to stress about. You're goddamned right we're going to trade a little more stress for you now for less stress for the entire company three months from now. It's a fair trade.

Did you respond to the wrong comment? Not sure where you're going with this comment.

???

Must be a sibling comment. Shoot.

> In this instance people have been using this Java package for years I gather without problems. Why is the responsibility for changing the package anyone but theirs, the people using it; now that they're decided they have stricter requirements for that need?

Because for a long time, libraries have been advertised as building blocks that you can quickly integrate into your own application without having to understand in detail how the library works. This assumption has been pretty crucial in the cost/benefits calculation for using libraries vs writing functionality yourself.

Now that internet security is becoming an ever more serious topic, this assumption might be less and less viable to hold. We've walked back on it to an extend already with the current best practice of "you don't have to understand how it works, but at least update frequently".

However, it might as well happen that this is not enough to keep security issues from happening. Things are already moving in a direction where it's absolutely expected that a developer understands and takes responsibility for every line of code that is included in their prodiuct, whether they wrote it themself or not. But if that happens, it will fundamentally change the way we deal with libraries and how software ecosystems work.

Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.

> now that they're decided they have stricter requirements for that need?

I think what made the log4j vulnerability so dangerous wasn't the ability to load arbitrary code via JNDI on it's own (even though that was certainly a horribly overengeneered and dangerous feature). The main vulnerability was that log4j was accepting substitution patterns in the "parameters" section of a logging command, the main purpose of which is to accept untrusted input. There has been at least one other CVE which exploits this without needing JNDI at all.

"Don't trust user input" hass been a fundamental rule of security for a long time, and it was reasonable to assume the log4j authors were aware of it. So the current situation is not that requirements have suddenly became stricter, it's simply that log4j broke a fundamental assumption about its API.

(I'm also pretty sure that while the JNDI thing was an unfortunate feature and was "working as intended", the "substitutions in untrusted input" part was likely a honest bug and never intended like that)

""Don't trust user input" hass been a fundamental rule of security for a long time, and it was reasonable to assume the log4j authors were aware of it. So the current situation is not that requirements have suddenly became stricter, it's simply that log4j broke a fundamental assumption about its API."

Once you see it this way, the whole "open source is broken" debate goes out the window. It was just a bug. A bad one, but not anything that hasn't happened before and won't happen again, open source or not.

"Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead."

Free software devs have to smugly repeat "no guarantees about anything" in the same way that non-free software development has to do it: Otherwise all software development would be mostly dead.

>Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.

I don't think they have to smugly reply, it's included in the licence[1] of the software that folks chose to use. See sections 7 and 8

1: https://logging.apache.org/log4j/2.x/license.html

There is social context to licenses.

My employment contract states that I am an at-will employee, so my boss could technically fire me because they didn't like my haircut. If they were to _actually_ do this, I would certainly be slighted by this, probably post about it publicly and forewarn others against working for them, although they would not have violated the letter of the contract nor my understanding of its literal meaning.

> There is social context to licenses.

What is the social context in terms of open source software and licences?

> so my boss could technically fire me because they didn't like my haircut. If they were to _actually_ do this, I would certainly be slighted by this

If we translate this to the log4j scenario: log4j says there is no support or warranty provided in their licence, however if they _actually_ do not provide support or warrant, you would be slighted by this.

To me this does not sound fair at all. Your boss at least pays you for your time as part of your contract. What do the log4j developers get for their time? Absolutely nothing. Yet it is expected they should provide support even when the licence says they won't? That's just comes off as entitled.

Drew DeVault has blog post that covers this better than I can: https://drewdevault.com/2021/06/14/Provided-as-is-without-wa...

Right, and I disagree with that post in this sense: there is a social expectation of fitness for a purpose that cannot be disclaimed with a license.

Many projects under licenses providing no warranty are nevertheless of high quality and well-maintained. Making the category in question precise is difficult, but it includes log4j. Projects by organizations such as Apache and eminent individuals like Bellard or Valsorda fall in this category. There is therefore an expectation that if you are such a project, yet unwilling to hold yourself to that standard of quality, you should make it clear for your users. Using a license with a no-warranty clause does not achieve it because it is not a distinguishing factor. The license, of course, protects from legal liability and so on, but no one is talking about legal matters here -- only about whether we should be collectively unhappy with the log4j maintainers.

The reason for this unhappiness would not be that they aren't willing to donate more of their time, but that their stewardship of the project is poor. Vulnerabilities are found in FOSS all the time; this instance was special because the misfeature in question was an egregious inclusion in the first place. It appears to be not a case of lack of time for review, but a lack of sense to say, "no, interpreting strings after formatting is insane and will never be part of this library." Obviously, they are entitled to include whatever code they want in their project, but some code is incompatible with it being useful -- if they do not aim to clear that bar, they should make it clear, because others in their position do.

I would say that something like opening your README with "this is not a serious project, you should not use this in prod" would be reasonable. This warning needs to be front and center and explicit, not merely sating "we are unpaid volunteers" or similar. There is precedent for this. Yes, some ignore such warnings and complain -- as long as this verbiage creates a useful distinction, such people are wrong and we should ridicule them. This warning would stand in contrast with the great many projects which aim to be fit for a purpose in practice, such as Postgres, Linux, Blender, etc. Obviously, such projects are usually better funded than log4j -- making it clear that you're not funded well enough to dedicate much time to the project an important part of this warning's content.

To continue the workplace analogy, I would be the unreasonable one to complain if the company specifically warned that they were significantly more trigger-happy that the normal company hiring at-will.

There is no such context. The licence specifies clearly and completely the terms of use. You cannot handwave an unwritten "social context" into existence, that adds and obligation to the creators that their licence explicitly refused to accept. What you get, of course, is the actual source code.

It's understandable that you would assume such a spurious obligation, human history is full of references to such obligations, up until the age of Big Data, which is when we realized that most of these assumptions were false. It's been a painful time for all of us.

In fact, the actual obligation is yours, if you decided to use this logging library. Seems there was a severe vulnerability in the code. It also seems that the people who responsibly forked the code, ran their own security audit, discovered the vulnerability and then patched decided not to make their contributions known to the general community of users of the software. They, if they exist, seem to be acting as if no obligations exist with respect to the code they acquired.

Speaking of assumptions, your proposed actions regarding your employment assume that your boss was obligated to tell you the reason your contract was terminated. Again, no such obligation exists. They can't fire you out of disgust for your Satanism, or because of your Innuit heritage, or because there are ambiguities regarding your gender. Luckily for them, at-will employees can be terminated, well, at-will, so there is no need for them to specify that it was not, in fact, because of your quite stylish haircut. Your public postings might in fact earn you a letter from the legal department, since you have no way of knowing the real reason was that you downloaded logging code on to mission critical servers, and lacked either the inclination or capacity to verify this internet code, and then when asked about your decision to do this thing, you quoted an imaginary "social context," an unwritten, unknown construct, that in this case silently tacks on the term "users of this library will receive free, unpaid support in perpetuity" that functioned exactly like Adam Keynes "invisible hand," that is, some rationalization to absolve you of the responsibility for explaining problematic aspects of the mental model used in your decision making. This was a vast surprise to the administrators of your company, who, understandably, know very little about logging libraries, which is why they hired someone to provide the required functionality.

This is what happens as things move more into mainstream from a few technical users using this as intended in sort of a small walled garden so to speak and then as it grows you get non technical users and bad actors. Look how smtp started, open for anyone where open relays were expected, to what we have today - still a large spam problem, compromised accounts with security on top of it. There are lots of rewrites and different smtp programs as things like smail and sendmail were replaced by exim, postfix and qmail (qmail which is free software, but really unmaintained and could be anyone's problem if they wanted).

I'd argue if there is an application that being built on libraries with out a full understanding of keeping them maintained over the years you will get a massive cluster fuck with code rot. These are things that are learned with experience, as a dev starts they take short cuts and learn from the mistakes. It is not a bad system when you are learning from your mistakes. There are simple solutions like using an operating system that is maintained. Log4j and java packages exist for example in operating systems that get security updates - and continue to do so for the life of the operating system.

Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons.

> Log4j and java packages exist for example in operating systems that get security updates - and continue to do so for the life of the operating system.

But how does an updated OS help if the packages themselves are not updated?

> But how does an updated OS help if the packages themselves are not updated?

Package maintainers apply patches and roll a new package version (e.g., +deb11u1).

At some point the package maintainers themselves may not want to babysit things anymore and deprecate the package. But most packaging systems that I'm aware of have mechanisms for applying patches.

In many cases even if the software itself is still maintained, the package maintainers may only apply a specific patch to ensure maximum compatibility.

It's why many of us prefer 'slow moving' distros with "old" packages: minimal change for a given version and then only when 'necessary'.

> Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons.

I very much hope not.

I would greatly prefer to see some certification bodies arise that can vet libraries for exploits like this and give a certificate of some sort saying "This library is safe to use".

Of course, that requires them to have some extremely good exploit-finders.

It's also a competitive problem.

Log4j commoditized log formatting, appending, and rolling for Java. If all my competitors use it and I don't, then I'm behind them in the market. I spent engineering resources creating my own, and add another layer to the NIH snowball which will eventually start rolling all on its own if I don't constantly invest a small amount of my limited attention into stopping it.

I only win if my competitors don't get away with it. Whole empires have been built in the time between log4j being 'production ready' and the discovery of this RCE bug. I'm reasonably sure that the majority of software companies that have ever existed, existed during this period, and any of them who used Java got away with it, and trillions of dollars to go with 'it'.

> However, it might as well happen that this is not enough to keep security issues from happening. Things are already moving in a direction where it's absolutely expected that a developer understands and takes responsibility for every line of code that is included in their prodiuct, whether they wrote it themself or not. But if that happens, it will fundamentally change the way we deal with libraries and how software ecosystems work.

That's one of the differences between coders and engineers.

Coders just import libraries to avoid re-inventing the wheel. Engineers consider each import as a dependency they'll have to maintain, buy support for or replace. Log4j just highlighted this difference, with some knowing exactly what to patch and others franctically trying to determine if one of the thousands of dependencies they imported into their app actually used it.

> Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.

There's a simple alternative: hire the devs.

I have zero sympathy for the library users who got burned by this security defect. It's fine to use free software for critical systems, but only as long as you have developers who can maintain it internally or a paid support contract with a vendor who can do that for you. Those options cost money. If you fail to account for that in your software bill of materials then you deserve the consequences.

Back a few decades ago, companies (at least ones I worked at) did not often use open source libraries in products. Sometimes you'd go through months of lawyer meetings to get some special case approved, but that was rare. So when you needed a library you couldn't write internally, you'd buy it from a vendor. That came with maintenance and a support contract.

As a developer that was a bit of a pain since you had to get purchase approval instead of just adding a dependency to a build file.

But, I'm feeling that is actually the better model the industry should go back to. It meant that developing libraries was actually a viable business. Today companies just leech off the open source everything, externalizing all their costs and dumping the maintenance burden on unpaid volunteers.

"As a developer that was a bit of a pain since you had to get purchase approval instead of just adding a dependency to a build file."

How much of a pain was it when the vendor refused to fix your bug because it, or you, weren't important enough? When the vendor went out of business, or was bought by a company uninterested in the product you were using?

Oh, and when you consider writing a library internally, keep in mind that patents are a thing.

"It meant that developing libraries was actually a viable business."

Yeah, I remember that. I remember when there were a million billion little companies producing C++ libraries. Then C++ started to get really popular, and those companies' customers went from a small group of experts to a large group of, uh, non-experts. Then they discovered that support was hard and all went out of business.

I really wonder what would have happened it HP hadn't open-sourced the STL...

How do you 'leech' off of something intended to be used for the common good? That perspective just doesn't make sense.

> Because for a long time, libraries have been advertised as building blocks that you can quickly integrate into your own application without having to understand in detail how the library works.

Libraries in general have been advertised this way, but it's not true for any given library, unless the library maintainers make that claim. In fact, it's quite common for people to release libraries with the exact opposite claim: They are not liable for anything that goes wrong, and they don't promise any support.

It is a bit offensive to have expectations from someone when the person makes it unambiguous how their SW can be used, and where their responsibility lies.

Now yes, it is true that many major, popular open source libraries do make a show of their libraries being reliable, and do provide support. And those that do tend to have more adoption. But even a number of those do say "Hey, we're putting in this effort, but are not promising bad things won't happen."

> Yes, free software devs can smugly repeat their stance of "it's a gift so don't complain, no guarantees about anything" - but if everyone took this serious, no one could use free software for anything critical, so the free software movement would be mostly dead.

This is transforming a continuum into a fairly worthless binary scenario. You're not going to have every library say "We won't provide support" just as you won't have every library say "We'll follow best security practices" - so why bring it up? It's trivial to show the latter would have likely killed the free SW movement too.

The reality is a continuum. And that is how the free software movement succeeds.