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.
If it is a money thing then it probably has more to do setting up "standards" and "compliance" requirements that you must me to use FOSS software in the government. Then federal contractors and other big FOSS organizations repackage their existing solution as "Government ISO-MITRE, PCI, Whatever-BS-Acronym-we-can-come-up-with" compliant and charge a premium over something they already sale.
I don't think this will hurt FOSS, at the end of the day FOSS is nothing more than someone saying "here's something I wrote or whatever." and sharing it, anything that tries to make more than that isn't talking about FOSS anymore.
For that reason I agree with the conclusion of the person above, things don't happen in capitalist societies without someone getting paid for it.
Yeah? Someone paid you to post this?
/s
The reality is, the greatest vulnerability here isn't in government-procured software that uses OSS libraries directly. The DoD's own critical custom applications are largely as secure as secure gets. The much bigger problem is in proprietary software, like the Atlassian suite, that uses OSS libraries in its own supply chain.
In fact, the DoD has had mandates from the highest level for years to use FOSS everywhere it is available, and to require all new contractors to open source anything they create for government use that isn't classified. The only reason something like the Atlassian suite is still used is a combination of institutional inertia and the lack of comparably feature-complete FOSS alternatives (the vast majority of this kind of space going to SaaS companies that don't allow you to self-host).
However just saying that all legislation is some scam without evidence doesn't make sense.
For example, and I don't know the exact name, but the health care transparency act where pricing for treatments or whatever must be published. Who is that helping if you follow the money?
Edit: I should have been more clear but ulterior motive to benefit large companies who sell software, or something that harms OSS.
Where things go wrong is when money becomes involved, because then the system rewards making the wealthiest people happy, not the largest number. That's an ulterior motive.
> Many forms of Government have been tried, and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed it has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.
> Where things go wrong is when money becomes involved, because then the system rewards making the wealthiest people happy, not the largest number. That's an ulterior motive.
Holy shit this is a terrible idea. I can’t think of a better way to discourage people from using open source than to punish organizations for “not making meaningful contributions” to it. As a heavy open source user, contributor, and author, I’m begging you to stay the fuck away from regulating users. That’s the fastest way to destroy open source.
It's not like closed source software is magically immune to vulnerabilities
For example, if your proprietary software has a bug, you call the developer and demand they come into your office and fix it under warranty.
Doesn’t work that way for some dependency downloaded from GitHub.
https://www.vmware.com/solutions/industry/government/warrant...
Warranties aren’t common in B2C or cheap boxed software. A few hundred or a few thousand dollars is not worth anyone’s time to negotiate special terms. In big dollar B2B or B2G, software isn’t usually as-is. Contracts are negotiated that specify what will be delivered, and what remediations exist if those deliveries fall short. If you spend 7 or 8 digits on software, you can easily get a warranty.
> your sole remedy will be that VMware shall, at its option,
> make a U.S. Person on U.S. soil available to provide technical support (in the case of non-conformity to the aforementioned Section (b)) or refund the license or service fees you paid
> VMware receives prompt written notice of the non-conformity following delivery (in the case of Software
So,
If the product isn't accessible: they'll write down the way it isn't. Period.
If the product doesn't do what it says it does, and you notice it quickly after purchase: Either 1. they provide technical support, OR 2. they refund your purchase price. And it's VMware who decides.
If the product doesn't do what it says it does, but you don't know until later: You're still screwed.
There is no guarantee of performance or suitability for purpose here. There is no guarantee of fixing anything. At worst, "you weren't prompt". At best, yes you get your money back. On the average, maybe you're given a phone number to call, and that person will ask if you've rebooted your computer.
This is actually still really bad for risk management; you have no guarantees that anything will keep working, just that after several months of running your platform on this stack, you might get refunded the purchase price. (Which leaves open the question, does that invalidate your software license, and do you now have to emergency migrate to a different stack?)
So, what you said earlier really isn't true:
> For example, if your proprietary software has a bug, you call the developer and demand they come into your office and fix it under warranty.
Also, your earlier
> Doesn’t work that way for some dependency downloaded from GitHub.
The above is true for every single open source dependency you download from Github! You'll be refunded your $0 purchase price, immediately!
Some warranties are implied, as well, and you won't find them written down anywhere.
See this article for several further citations:
https://corporate.findlaw.com/litigation-disputes/performanc...
(This is why FOSS licenses almost universally disclaim both warranty and liability for damages, rather than ignoring the issue. Refunding the purchase price is not the worst that can happen.)
Usually in very large software purchases, fixing problems is often much cheaper than undoing a purchase.
While technically, you may be able to legally refund a $10,000,000 software purchase in lieu of buying a plane ticket for a developer, in practice, that's not really an option anyone takes.
I think if you want to argue damages is a common contract clause in the software industry, it's only fair I ask you to name examples. Because it really isn't common.
Seems a bit contradictory to the license terms. Gonna be a trick to get legislation to enforce something that isn’t in established contractual language.
Edit: on the positive incentive approach, getting double-funded with discretionary budget for every FOSS developer they hire might be a viable strategy.
how is that even possible
Did you mean <100%?
That part confused me too - I believe it's meant to be sarcastic. There's a kind of humor that I often don't get until further reflection, which is a way of saying things that are so overboard and absurd that the speaker cannot possibly believe what they're saying. Or rather, the speaker is saying the opposite of what they mean, in order to make their point. Might be a cultural thing.
This kind of humor is even harder to recognize these days, when people honestly do believe the absurd things that they're saying.
To me, it reads as a bald-faced attempt to discourage public sector entities from using OSS solutions, when in fact there are perfectly good and definitely >100% secure proprietary offerings that cost a reasonable amount when purchased from the sorts of vendors that pay lobbyists to "help" senators write OSS bills.
Do you honestly think Rob fucking Portman woke up one day with strong opinions about FOSS?
Make no mistake: this is a thinly veiled late-stage attempt to displace the growing dominance of OSS-based solutions to the sorts of problems that the government and military used to pay 8 and 9 figures a year to EDS to solve.
An actual, good-faith bill that seeks to address these issues would attempt to incentivize/punish orgs that use FOSS without making meaningful contributions to it.