I don't buy it. More like, log4j was an actual real big issue for government agencies because they use rely on tons of open source projects and haven't previously done much to make sure that that supply chain is robust. This would help to change that.
Federal contractors don't need to sell proprietary software to make money -- they make more money selling FOSS software.
tech companies in general are making billions using FOSS.
The point of this is that you can't treat proprietary software dependencies the same way you treat FOSS. Community FOSS projects just don't have the same development process and governance model that proprietary software does. And so, the assessment of these projects is necessarily different.
The primary factor driving the decision making process is not cost but risk.
Many fail to remember the lengths to which companies like Microsoft, Oracle, Sun and others went to create FUD around the adoption of OSS in the public sector. It involved lobbyists, marketing campaigns and a whole certifications industry.
When a CIO selects a technology, they aren't just weighing its merits and price tag; they are actively looking to leave a glowing legacy while actively doing everything they can to avoid being humiliated if the technology fails. See, the CIO knows that, as far as their board of directors is concerns, it's not the software that failed but the executive.
That's why enterprise support packages exist; it's an insurance policy and a promise that if something goes terribly wrong at 2am, someone is going to pick up the phone when you call.
Companies with expensive tools have an obvious interest in convincing their best customers that the competition in inherently risky.
It is not in the interest of 'proprietary' software vendors to fearmonger about OSS libraries. They too use OSS libraries just like everyone else does today.
It isn't 1995 anymore where a proprietary piece of software can run on a full stack of code written by the people who work locked away in a single building at one company. Everyone is using open source dependencies. There is nobody left that would benefit by demonizing open source libraries.
Honestly I’m embarrassed at how revelatory this line is.
The problem is that they don't need to do this. In the open source community we're doing a great job all by ourselves. I've written open source libraries and platforms, I've also written proprietary software that uses open source. Log4j, Heartbleed, half of NPM etc weren't the work of Oracle lobbyists, they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained.
I'd actually go further and say you overestimate the power of lobbying and underestimate the possibility of lobbyist's having a point. The primary argument these firms made against relying on OSS was that it's often just a bunch of random people with no incentive to do the un-fun work like security audits or patch backports. There's nobody who takes responsibility for things. That's true and is pretty much the core of Red Hat's business model so it's not like anyone can really dispute this.
The software industry does need new approaches to how we use open source stuff, IMO. Sandboxing of libraries would go a long way. But we can't just pretend there's no problem here and it's all the work of shadowy corporations, it's naive ideological stuff.
uhh rewriting history much? the reason the entire world uses openssl is because it operates correctly.
The judgement here is diluted by exaggerating the worst moments of an otherwise profoundly performant ecosystem. btw- I turned my outward facing servers off for three days for Heartbleed, so .. how to balance a serious development, with the growth of billions of devices working correctly each day for years to get here.
In a previous life I did work on internal proprietary C/C++ code bases and yes, there were ridiculous technical debts, bugs, and missed opportunities right along with correct code, insights reduced to code, and solving hard problems well.
except that a lot of proprietary software doesn't has anything like that either
there is nothing in common proprietary dev practices which would have e.g. prevented log4j
the main difference is that you can hold someone financially responsible in one case and not in the other (but in turn you can always fix any problem yourself, good luck fixing any proprietary software after it's support runs out).
The federal government has rules regarding the acquisition of software products, and they have various governance and risk management requirements for various scenarios. Many of these were designed with proprietary software in mind.
The point of this bill is to update some of those requirements to make sense with the way OSS works.
The root comment suggested that somehow this was a smear on FOSS, intended to sell more proprietary software. However, this doesn’t hold up, because FOSS components are widely used by all of the big proprietary software vendors in this space too.
I'm doubtful that anything short of requiring thorough security/pen testing on everything in the dependency tree would have prevented log4shell. And if that is the goal here, who is going to pay for that? Most open source projects don't have that kind of funding.
With reasonable prioritization, we can probably do a lot to reduce the threat long before we get near everything.
> who is going to pay for that?
Well, this bill does seem to involve hiring FOSS devs, maybe that's partly what they'd do?
FOSS usually does not have warrantees, SLAs, or developers in particular locations with particular credentials. The government has processes that they must follow for paying contractors, so “just pay them” is not something that can easily be done last minute, (and sometimes, not at all without a literal act of Congress.) Also the financial and obligatory relationship between them and the developer is much different, and must be managed differently.
Really, it is very important for people doing technology projects at the government to understand the difference between calling up the developer of Windows and calling up the developer of Git. Those are two very different relationships.
Finding out that you have a problem when you don't have a support contract and then looking around for someone to work on the thing is not the same thing as having a support contract, although in some cases it can be a sufficient substitute and it's certainly cheaper in the best case (like any other form of skipping insurance).
Depending on context, providing the "support contract" internally is also an option.
It’s also not reasonable to require the government to just get 10,000 support contracts just to implement a single application.
What makes the most sense is what they’re doing here:
1. come up with a strategy for managing these risks
2. Collectively work with OSS developers instead of treating every one of the governments 10 bazillion projects like it needs a separate support contract for a component that is shared
I disagreed that things are all that different "if you have a support contract."
> It’s also not reasonable to require the government to just get 10,000 support contracts just to implement a single application.
I agree, but I'm not sure that's relevant? If a single support contract is sufficient for proprietary software - making them responsible for addressing (incl. possibly working around) issues in any dependency - why is that not also viable for FOSS software?
I don't disagree that what they're doing here seems likely to be a good idea, I just think you were initially selling "pay for support for the software you rely on as a big organization" a little short in its general applicability; indeed, this probably be viewed as providing that service internally.