Exactly. If you want to be useful, help refine the “monetization” definitions. Don’t try to kill the whole legislation.

The Register appears to have bought into the FUD being spewed by a bunch of people being paid a lot of money to run “non-profits”.

The main risk I see is that every web host using Apache or Nginx will be required to handle certification on their own.

Businesses like Litesspeed can sell their product as a certified one and sell that as a feature.

But isn't this normal?

If I am distributing a product based on Linux, it is my job to ensure that I use Linux in a secure way, to the extent required by contracts between me and my customers, and by local regulations. I can either take on this work myself, or pay IBM RedHat or SUSE or whoever else to take on some of the responsibility.

How else would this work?

There is a difference between due diligence and required certification.

Using a "standard" kernel, keeping it up to date, etc. is due diligence but WAY cheaper and easier to do then any form of certification.

Software certification especially wrt. to security is and always has been a mostly a scam.

It also is a _major_ driving factor(1) for insecure software not getting fixed. Because it's "certified" but the security fix is not. (1: in certain industries)

Due diligence is relative to the industry. I agree that having a reasonably up to date and boring kernel, and keeping updated, is the best we can do now. But there’s something defective in the industry, if there wasn’t, then we could apply industry standards to produce a fully understood and certified device that is actually known to be free of defects.

> certified device that is actually known to be free of defects

we can't even do that reliably for very well understood mass production processes of "simple" physical goods ( Which is why you make systems which in presence of defects still yield acceptable results.). The goal you are listing is not something which can be reached through laws like this _at all_!!!.

Outside of clear negligence and potentially hurting FOSS it will not lead to a major increase in security in it's current form and can easily have the opposite effect too due to companies "hiding there code" to avoid problems when people find issues and potentially use all kinds of questionable means to try to prevent people from doing independent security research on their products.

If past experiences around e.g. government projects with similar requirements are anything to go by certification is not in any way a reliable form of security, especially for mass products.

In my experience the overlap between competent security researchers and people doing the certification for most (not all) for-hire security review companies is rather small.

For example the amount of peace makers which can be hacked even through such medical devices have extreme strict certification requirements far beyond what can be applied to most software is still pretty high.

I have seen cases of really big (and supposedly competent) software consulting companies certifying something as secure which most 3 semester or so bachelor students could have told you is clearly not secure.

Don't get me wrong, there is a problem with negligence and having a law/regulation which reduces that is by itself a good thing.

But the issues the software industries has are much more deep rooted then such negligence (else we wouldn't also see such issues en-mass in cases where no such negligence was done). You could even say they are fundamentally rooted in human nature and society ;-)

Worse if such a regulation is not done well it might more lead to a game of shifting blame then people actually trying to fix things.

> This seems sort of reasonable. If you charge for tech support, you have a business. I’m all for not making it harder for people who are actually just sharing their hobby projects, but a project that makes money isn’t a hobby anymore.

With the current writing it might be that a distributor different from the commercial entity might be liable for vulnerabilities and reporting.

https://blog.sonatype.com/eu-cyber-resilience-act-good-for-s...

Furthermore, as the author of the Sonatype piece told me last fall, it also goes beyond the upstream project and any distributor. In the case of a lot of vulnerabilities, the fixes have existed in the upstream for maybe a year or more. But they're still in downstream code that has never been updated.

I'm always impressed at how little European regulators seem to understand tech (and at how little they want a healthy tech sector to grow in Europe, preferring American and Chinese alternatives).

To me it sounds like the "software is delivered as is" clause would nullify that.

But there are huge problems with "as is" clauses, and in the US anyway, they aren't always enforceable. If I sell a doohicky that I know is likely to kill people, slapping an "as-is" clause on it probably won't keep me out of jail.

In the case of OSS libraries and open-source distributors, there's no sale happening.

What I see emerging is a dual license system where you can buy a supported version that's compliant with whatever European law or get the one hosted on an American mirror (where thankfully European law doesn't apply).

> In the case of OSS libraries and open-source distributors, there's no sale happening.

True. I should have said "distribute". But the point holds.

Until the great EU firewall happens.

Thanks to current US politics, whatever gets developed over there might not be as widely embraced as in the heyday of all good friends over here, global economy.

Would this create a way for FOSS projects to charge SaaS companies for monetized use of software by offering a compliant version?

Could be an unintended side benefit given that as it stands FOSS is basically free labor for SaaS with the latter delivering a user experience that is significantly less open and free than the old closed source paradigm FOSS intended to replace.

FOSS + SaaS = less freedom than old closed source.

SaaS by itself is a total disaster on that front.

Why are there no reminders here about the difference between open source and free (= libre) software ?

It's specifically an important feature of libre software that others are free to resell or to make money from support of your own software : this is seen as a good thing because distribution (and support) are not free for the distributor (though I guess much less relevant in a world with widespread high speed Internet and peer to peer distribution software ?) (and supporter).

>Why are there no reminders here about the difference between open source and free (= libre) software

Because there isn't.

Well, there is a difference. Open source software includes certain things that may not be included in libre software, such as access to source code, customer participation in development, etc.

Open source can be different from "free as in beer" but certainly not different other than as a philosophical/marketing thing from "free as in freedom" as the FSF uses the libre term.

I may generally prefer permissive licenses but I certainly don't see how the GPL, for example, doesn't enable access to source code--though it may sometimes discourage participation in development.

I think "libre" means something different to me. All OSS is libre, but not all libre software is open source. For instance, freeware distributed solely in binary form is libre.

But nobody taught me this definition. Not sure where I got it. So I could very well be wrong.

> For instance, freeware distributed solely in binary form is libre.

Nope. That's free as in free beer.

free/libre software / open source software is free as in free speech (and often as in free beer but not always)

some people use the French/Spanish word libre in English to avoid this exact confusion caused by the world free having both meanings.

free software and open source software are defined by the FSF and the OSI, respectively, but the definition are equivalent and designate the same set of software, essentially.

Thanks for the correction. We sure could use a term for such software, though.

I haven’t seen “freeware” used to describe Free software. Or, shareware seems like a pretty close idea to what you are describing?

Why is this relevant in this context? The question is which entity should be liable for abiding by this regulation, and the clear intention is that the answer is the one that Stallman himself would agree with: responsibility should sit entirely with whoever is distributing the software and making money off of it.

That's not a fundamental feature of open source, or a fundamental restriction of free software. E.g the GPL is approved by OSI, and the MIT license is approved by the FSF.

The distinction is really much more about philosophical objectives and marketing than it is about anything material.

Because Libre software is included under the umbrella of Open Source. If I'm writing an article about car regulations, I don't need to specifically mention cars with leather interiors unless the regulation treats them differently.

I guess companies that run mirrors, for example distro repos, would fall under that definition too. What about donations and not-for-profit orgs?

This is a good question. I’d hope that just hosting a free repo wouldn’t confer responsibility.

Another thing I’m wondering about is academic code. Hypothetically the code I wrote for my thesis is available online and I was paid to write it, I guess, or at least it is part of the research I was given a stipend to do. (Happily, it has nothing to do with security!).

Nobody is making any money off it. Hypothetically it could be seen as something that is there to add (very marginal!) value to my resume or to the university by showing off research chops… I dunno. If we had a law like this in the US, I wonder if it could stay up. I guess universities would end up with an additional CYA administrative step before posting code, and a big disclaimer in all their licenses.

The problem is it's not a suply chain in the classical sense.

If you directly or indirectly (support contracts) sell some software sure it should apply, but the regulation isn't well defined (in it's draft state) and includes much more.

A lot of FOSS is based around the idea:

- provide software components as FOSS on a as is-basis, components you do not sell directly or indirectly but plan to use, or used, or planed to use until things changed etc.

- the consumer of the software (other programmers/companies) are expected to do _their own_ risk assessment, reviews etc. IF they decide to use the software (but only if, i.e. not needed for prototyping)

- if they use the software (hopefully) you get feedback from their review and assessment leading to bug fixes and improvements

- in some cases projects are evaluated by enough other parties that not everyone needs to do their risk assessment

- you don't make profit from the release, but you do get feedback which could safe cost and do get publicity and trust, so it has a commercial benefit so it's commercial in a certain way

Now you probably can already spot the problem, in many cases companies do _not_ do their do due diligence in reviewing software and blindly assume "someone" did it.

So an regulating which requires you to have made sure that someone did due diligence for all software you include in a product, including SaaS(!) is reasonable IMHO.

But because the regulation is based on the concepts/ideas of a physical supply chain it is instead requiring anyone which is publishing software components (instead of using them) to do the due diligence if it's commercial. But due to OSS leading to feedback, publicity and trust _ANY_ OSS done by a company can be classified as "commercial", even if it's a tech demo explicitly not meant to be used in production or a early pre-pre-pre release version.

Another problem is the definition of what I called due diligence but to comment on that I had to read the draft again.

So IMHO the problem is not the regulation by itself, it might even make OSS better, but the exact formulation which either show a deep missing understanding of software development or bribed politicians, probably a bit of both. Ah I mean lobby influence politicians, it's practically the same, but not legally so better clarify that.

EDIT: I.e. a lot of OSS software is more like sharing (potential prototype) technical blue prints in an informal shared development/research agreements then it is selling "parts" in a supply chain.

The data sheets for an electronic part will usually have some example applications included, I wonder what the legal framework around those is.

Almost all datasheets have an explicit "as-is" disclaimer. It is in the manufacturer's best interest to ensure their accuracy, but the reader is assumed to be a skilled professional who would be able to spot any mistakes.

The example applications included in them are usually vague enough that implementing them isn't trivial. It'd be very hard to view them as anything more than pseudocode, with similar expectations of functionality.

Data sheets tend to also be (at least subtle) wrong all the time, at least that is what I have heard many times by now from people working with electric hardware/supply chains.

> a project that makes money isn’t a hobby anymore

It all depends. There are plenty of people who have hobbies and engage in some sort of low-level commerce in order to fund them. They aren't intending to profit by them (and don't), but are looking to reduce their loss.