Live data from Hacker News

'Securing Open Source Software Act' introduced to US Senate

hsgac.senate.gov

61–70 of 187 posts

Re: 'Securing Open Source Software Act' introduced to US Senate

#61

Earlier quoted context omitted.

Additionally, “The legislation also requires CISA to hire professionals with experience developing open source software to ensure that government and the community work hand-in-hand and are prepared to address incidents like the Log4j vulnerability.” So we should definitely expect at least some minute changes to the open source economy, itself.

This is the worst part. "Experience developing open source software" is both entirely vague and specific at the same time, likely conjuring up an image of some developer with green boxes on a GitHub repo or something, which is terrible. This is going to force the creation of some sort of silly criteria for what constitutes that experience, of which suits in federal agencies, and the political pressure and politicians…

> "Experience developing open source software" is both entirely vague and specific at the same time

Good. CISA is better equipped to be refining those specific requirements than Congress.

Re: 'Securing Open Source Software Act' introduced to US Senate

#62
post #53

Earlier quoted context omitted.

> 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.

Of course, which is why I think viewing this as a push for proprietary software is not a fair assessment. Increasing your company's development costs is not a way to make more profit. 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, t…

Respectfully, you have a too-reasonable hunch of how decisions are made at the executive level, and because of that, you're reaching an incorrect conclusion.

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.

Re: 'Securing Open Source Software Act' introduced to US Senate

#63

Earlier quoted context omitted.

Of course, which is why I think viewing this as a push for proprietary software is not a fair assessment. Increasing your company's development costs is not a way to make more profit. 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, t…

Respectfully, you have a too-reasonable hunch of how decisions are made at the executive level, and because of that, you're reaching an incorrect conclusion. 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, ma…

[deleted]

Re: 'Securing Open Source Software Act' introduced to US Senate

#64

FWIW, while this specific act may not be enforcing significant regulation, software developers need to understand that there's a ticking clock. Modern civic engineers went without any significant regulation, and then that changed. Software is young, it's in the phase where people aren't dying too often for the public to care. But breaches are leading to massive privacy problems, real wars and conflicts are increasing…

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…

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.

Re: 'Securing Open Source Software Act' introduced to US Senate

#65
post #2

So will they help fund the projects now, or will they just express their opinions on how your unpaid work should be done?

There is this little nugget: “The legislation also requires CISA to hire professionals with experience developing open source software to ensure that government and the community work hand-in-hand and are prepared to address incidents like the Log4j vulnerability.”

Unless it specifies who this just means they'll throw a few billion to Teksystems, CGI or whoever and then say that it was a failure like HealthCare.gov

Re: 'Securing Open Source Software Act' introduced to US Senate

#66
post #32

Seems like they are taking the right approach. Instead of trying to regulate OSS, they're funding CISA to help make it more secure.

What will the CISA actually do?

Lol.. they'll pay contractors from big companies to come in and tell them why they shouldn't use open source.

Re: 'Securing Open Source Software Act' introduced to US Senate

#68
It seems most commenters want to interpret this as a threat, or as a way to discourage use of FOSS by government. I don't think it is either one. The US government isn't a monolith, it's thousands of semi-independent fiefdoms all doing different things, and some know what they are doing and others have horrible security practices. This seems to be one of several efforts to fix that.

Looks to me like it will wind up making more money available for developers, mainly outside government, to audit and improve important free software that the feds are currently using. Unfortunately because of the way that government contracts work, companies that are already experienced at doing government contracts might wind up with the bulk of the money. But it isn't going to make things worse and might actually make things better.

Re: 'Securing Open Source Software Act' introduced to US Senate

#70
post #29

Why limit it to open source? You wouldn't let an engineer build a bridge with car-sized holes just because the blueprint is not open.

There are different questions that should be asked when choosing open source software vs proprietary software.

If you're using proprietary software, you might ask things like, "what's your SLA?", "can we review the source code?", or "how much is a license?"

If you're using open source software you might ask things like "is the project maintained?", "who developed it?", or "do we have anyone on payroll who knows how thing works?"

So yeah, it makes sense to treat them differently, at least in some respects.

Post reply on HN