EU Cyber Resilience Act: What does it mean for open source? | Hacker News Reader

EU Cyber Resilience Act: What does it mean for open source?

berthub.eu

151 pointsahubert99 comments

The new version of the CRA is quite an improvement, and most of discussions around the open source communities were about older versions that were quite concerning. There were a lot of scary discussions on the foundations mailing list and on various board of open source non-profit.

This article is a good step to explain what has changed.

(I was quite concerned as President of VideoLAN and involved in VLC and FFmpeg, since both projects would have been threatened by previous drafts)

So you might be able to turn this into your advantage. The zillion people embedding your great work will be on the hook if it turns out they haven't performed sufficient due diligence on ffmpeg. And who knows, you might get them to sponsor you to get security audits or documentation done. Could be their "ticket out of jail" one day!

Could be advantage, but probably will not.

Because OSS organizations just not created for this.

Next I will say about typical OSS org, not some daughter of commercial corporation like Apple, or Google, or Microsoft (or any other FAANG member, or how it called now).

So, exists huge number of just unregistered tiny OSS producers, who do it just for fun.

Some OSS producers become medium entities (mostly, non-profit), and some even large.

But they not intended to do this for money! This is just hobby, even when this hobby gives rock-star like popularity.

And as I looked on internal regulations of OSS, they usually avoid liability at any cost.

This is problem even in large commercial entities, but in non-profit this is just nightmare, nobody want to be responsible.

Fortunately for them, modern bureaucracy gives some methods to avoid DIRECT responsibility - they use Board of Directors; mimicry to Direct Democracy methods - conduct plebiscites on all important questions; and use all other tools of big businesses, to avoid direct decision making and responsibility.

Well, in past, when software was not really important, all these things was totally normal. But unfortunately, these large decentralized entities are uncontrollable, in sense, they could long time maintain way, on which they step when decentralized structure built, but for them impossible to reform this structure, to turn it to other way, to match changed environment.

And when I said, commercial entities have same issues, yes, they literally same, with just one difference - commercial usually made to make profit, but money is not just profit, they are equivalents of resources, mean, reserves, which CEO of commercial entity could direct to build new structure, matching changed environment. And in commercial, very popular form centralized, with powerful responsible CEO, who could after built new structure, fire members of old (this is just impossible in near all OSS projects, as they usually have distributed ownership).

Few words about daughters OSS entities of large commercial. Their difference, while they also like to play Democracy games, but all money still at hands of father entity, and these are extremely powerful levers.

When for some reason, daughter OSS entity become uncontrolled, or just father entity decided, that it will be cheaper to create new daughter entity than to reform old, they just create new daughter entity and make it structure as need.

This is really easy for them, because for commercial entities, just normal to have processes division (department), which just constantly modify internal regulations of entity, to match current CEO view. So as I hear, in modern entities, typical to rebuild structure every 1.5-2 years.

And I'm agree, for many people this could become opportunity. But I doubt, these people will become from currently established OSS entities. I think, all except commercial business daughters, will be newcomers, with new entities.

And yes, sure, will be transition from current state to a new one. And who knows, this could be like Y2K.

I was unaware of this act before reading this, but I kinda like it. My current employer wants to do the absolute minimum in securing the software they develop. However, it's used at in organizations working on national energy and communications infrastructure, so it's somewhat important for it to be secure.

Meanwhile, we're way behind on updating much of our infrastructure and hardly ever check whether any of the open source libraries we use are up-to-date, nor whether they're reliable. I really hope this legislation pushes companies like mine to improve their software development practices, because I'm scared of the future.

I am scared of the situation where the paperwork is done and the money is spent to do it, but it all stays on paper without any actual security improvements. Using your example: the internal auditor would write something like: "It was verified that the open source libraries that we use are of the latest compatible versions and do not have any crashes recorded in our system" without actually checking anything.

In other words, an array of mini-dieselgates.

Which sounds like an improvement over a total lack of regulations where these dieselgates would be legal.

Hardly. It might give people a totally unjustifiable sense of security

https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CONS...

Important bits (10c and around):

* Libraries/non-end products are fine, unless monetized.

* Employee contributions seem to be fine.

* Foundations seem to be fine.

* Non-core developers are fine

Seems like significantly better version.

What about non-monetized open source end products?

I know it's not cool on HN to say "did you even read TFA?" but seriously, read TFA!

Good that the backtracked on a lot of the CRAp (which would have meant the end of OSS in Europe, talk about destroying the world with the wrong swift movement of a pen!) BUT I'm still angry:

1. This adds barriers to sell OSS software, which helps solidify existing markets and prevents new competitors from stepping up

2. This won't change anything except forcing projects to waste money in legal BS, when the responsibility should be uniquely on the commercial entities USING and providing a service (and therefore making money) with the OSS software

3. This is only the first step, I'm sure they'll keep adding rules

4. I'm thinking they may have been heavy handed in the first draft just so that people would think at the end "oh, phew! the regulators didn't kill ALL OSS software in Europe, great!" without thinking why do we need this regulation or how it improves ANYTHING

Will it actually improve security? I don't think so.

If someone is paying for commercial support they likely already have security updates and, once vulnerabilities are known by the maintainers, the news spread.

The security problem with OSS is not that things are not communicated promptly, but that it's hard to make money with OSS so there is no staff working on security.

This would have not saved us from eg. OpenSSL vulnerabilities and it will be even harder to $NextOSSOrg to start charging for their product and improve their security.

> This adds barriers to sell OSS software, which helps solidify existing markets and prevents new competitors from stepping up

All commercial software is included, I don't see how (commercial) OSS is somehow special. Did you read the article?

"which helps solidify existing markets and prevents new competitors from stepping up"

So exactly like any other regulation.

I like the author's analogy and I'm pretty sure this country has regulations around selling food, but there isn't much of market consolidation. People open and own small restaurants and it's not only chains and franchises all around. People even start new banks and get licenses and the product is quite good. And there are things that are more regulated than opening a bank. I suspect that the CRA is not on a level of operating a bank and somewhat more lax than operating a restaurant.

> it's hard to make money with OSS so there is no staff working on security.

Sooo.... Because of that you should be exempt even though you're expecting to sell that software?

How does this make sense?

Sell OSS software? The way OSS makes money is: hosting the service (good luck) or providing paid support (does not scale, unless u scale the number of your devs too).

> 2. This won't change anything except forcing projects to waste money in legal BS, when the responsibility should be uniquely on the commercial entities USING and providing a service (and therefore making money) with the OSS software

First of all, most of the software companies do SaaS, meaning they also provide the service. And then, even if they don't, the users will just hand down the paperwork to the companies developing the software. Because those know what was put in, security and components, and want to have this in legal writing.

Secondly, imagine your average IoT seller. They should not be liable for their bad product because they don't run it themselves? "The user" is liable? In most cases the "user" can't even do anything about their insecure device.

I think developers are rightly responsible here. It's pretty comparable to other industries where the products have to be safe when getting sold, think pharma, food, toys, cars, etcpp.

> Will it actually improve security? I don't think so.

Think B2C. It will improve things there, and massively so. Software in B2B was already somewhat regulated via audits and certifications.

The last time I've checked the draft, it looked like MySQL project would be responsible if a security bug occurs and responsible to do certification, because they provide paid support. But Amazon could just host MySQL without spending anything on dev or certification of MySQL codebase (because MySQL would be forced to do certification because they do make money with their code by providing the paid support).

It appears that targeted exceptions have been added for specific situations lobbied by current FOSS and commercial stakeholders. Hopefully there will be an ongoing process to address the need for new exclusions, as the vast scope of the CRA becomes clear to societies eaten by software.

New OSS governance and runtime binary attestation (aka DRM) layers are being defined by the CRA, e.g. only specific attested binaries from open-source trees that follow specific development practices would be allowed to run in critical systems:

  Open-source software stewards shall put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product.

  … Open-source software stewards shall cooperate with the market surveillance authorities, at their request, with a view to mitigating the cybersecurity risks posed by a product with digital elements qualifying as free and open-source software.

  … security attestation programmes should be conceived in such a way that … third-parties, such as manufacturers that integrate such products into their own products, users, or European and national public administrations [can initiate or finance an attestation].

Legal liability and certification for commercial sale of binaries built from FOSS software will alter business models and incentives for FOSS development.

Dec 2023, "What comes after open source? Bruce Perens is working on it" (174 comments), https://news.ycombinator.com/item?id=38783500

> New OSS governance and runtime binary attestation (aka DRM) layers are being defined by the CRA, e.g. only specific attested binaries from open-source trees that follow specific development practices would be allowed to run in critical systems

That doesn't seem like what the CRA stipulates. I think it's more about manual attestation in its most traditional meaning, i.e, an organization attests that X software is secure.

> That doesn't seem like what the CRA stipulates. I think it's more about manual attestation in its most traditional meaning, i.e, an organization attests that X software is secure.

CRA can require EU-wide recall of "products with digital elements" which are found to be non-compliant by national market surveillance. While we may analogize this requirement to the recall of slow-moving physical products with rare market withdrawal, software developers and attackers iterate more quickly.

Centralized software distribution like mobile app stores would have the ability to implement a kill switch (recall) on non-compliant products. Products which depend on centralized cloud services could have binaries verified before they are allowed to connect to an API. This would give regulators the tools to rapidly implement software "recalls".

  (58) … significant cybersecurity risk or pose a risk to the health or safety of persons … market surveillance authorities should take measures to require the economic operator to ensure that the product no longer presents that risk, to recall it or to withdraw it …

  (60) … market surveillance authorities should be able to carry out joint activities with other authorities, with a view to verifying compliance and identifying cybersecurity risks of products with digital elements. 

  (61) Simultaneous coordinated control actions (‘sweeps') are specific enforcement actions by market surveillance authorities that can further enhance product security.

So what would you propose for recalling physical products that have insecure software that can cause physical trouble? What framework would have sufficed?

Kill switches based on attested binary identity exist and can be deployed at scale. So they can and likely will be used to comply with regulatory decisions. What remains to be seen is how those regulatory decisions will be made for complex software supply chains.

In part, open-source software arose in response to opaque software.

Can opaque regulation equally govern open and opaque software?

Should open software have open (i.e. continuously evolving in public, not point-in-time negotiated) regulation that can keep up with open development and security research? Much will depend on the operational practices and transparency of national institutions tasked to implement EU CRA.

This regulation is so shitty. I'm quite sure that it is supported by big actors in the end, because the end goal is to ensure to have a regulatory barrier that will avoid small actors to be able to strive in the software field.

Also, to avoid "dangerous" not yet professional amateurs having a chance against big editors.

This was the first question on my mind as well. How will this affect the one-man webshop owner or software developer? Seems only big established firms will be able to conform to this?

This question was asked a lot when GDPR came around, and it's essentially an implication that the regulator will act in bad faith.

Courts and regulators, particularily European ones, understand when there's a "will" to follow the law. It's one of the differences between "rules-based" and "principles-based" regulations.

https://news.ycombinator.com/item?id=17100541

I don’t understand? So you should only in principle audit your Wordpress blog?

Read the comment I linked. It's about the regulation being enforced with its principles in mind, not robotically through its strict interpretation.

Questions:

- If you run a commercial kitchen on your own (or, let's say, with a staff of 2-3 people), can you ignore the food safety regulations? The fire regulations?

- If you run a one-man plumbing company, can you ignore safety regulations? Water regulations? Sewage regulations?

etc.

Why is it than when it comes to "commercial software" it is inevitably "oh my god these laws are so hard, why should I as one-man company be forced to comply with them". Because that is literally your job.

In kitchens as in plumbings:

- There are rules, and clear established practices that allow you to follow these rules. In software the rabbit hole goes so deep that your average developer cannot even be aware of all the risks.

- You do not have to rely on millions of lines of code you have no control on.

As a simple example, if you are using network communications, you are probably using OpenSSL, GnuTLS or one of the few other TLS implementations. All of them have regular security issues, and simply selling support on an Open Source software you built using one of them will make you liable for these issues. There is no choice: you need TLS, and you're not going to implement it yourself. What are you supposed to do?

The fact that a solo developer selling 100€/month of support is treated the same way than a billion dollar company demonstrates the complete insanity of this act.

> The fact that a solo developer selling 100€/month of support is treated the same way than a billion dollar company demonstrates the complete insanity of this act.

But they're not treated the same way. Both by the law itself and the standards courts and regulatory agencies use throught Europe.

The text of this act treat them the same way unless I'm missing something (feel free to point me the text saying otherwise). A sane legal text would put in place thresholds with different levels of expectations and liability depending on the size of the company, who you are selling to (companies or individuals) and its revenues, respecting the principle of proportionality.

The principle of proportionality is a mandate of courts and regulatory agencies too. You're implying that they would act in bad faith by putting all their might on small/one-person businesses, while it's just not the case with EU bodies.

Most regulations work like that. For example, just because you are cooking in a food truck does not exempt you from basic hygiene requirements. Also CRA will not put you into hot water because of a vulnerability in your dependencies. You may get in trouble if you refuse to provide a security update during the lifetime of your software product.

For some reason I can't seem to open the text right now, but from my previous reading I remember a smaller variant of annex V for small businesses. So the solo dev is not treated the same.

As I read it, and with the caveat that the exact requirements are not yet determined: You will need a SBOM stating you use openssl, and how you plan to update openssl if it contains security bugs.

Update: found it, paragraph 46a: In relation to small and micro enterprises, in order to ensure proportionality, it is appropriate to alleviate administrative costs without [...]

Bad software won't give you food poisoning.

Regulations can make sense for software that could cause physical harm - like the software in an implanted medical device - but most software doesn't fall in that category. The CRA is about "security" not about "physical harm" - they are two different things. Regulations for the latter would likely receive less pushback.

Hacking risk leads to recall of 500,000 pacemakers due to patient death fears https://www.theguardian.com/technology/2017/aug/31/hacking-r...

Your distinction is without meaning

> Hacking risk leads to recall of 500,000 pacemakers due to patient death fears

A recall was issued therefore there is already regulatory oversight where it counts. The CRA is at best redundant and at worst a prime example of regulatory capture [1].

[1] https://en.wikipedia.org/wiki/Regulatory_capture

> A recall was issued therefore there is already regulatory oversight where it counts.

Just because a recall was issued doesn't imply that there's a regulatory oversight. And even that oversight exists in that particular case doesn't mean it is applicable to other areas.

What it does mean is that you're weak attempt to paint software being exempt because it "doesn't lead to food poisoning" is weak and uninformed at best.

> The CRA is at best redundant

It's not

> at worst a prime example of regulatory capture

Again, it's not.

Just because you engage in FUDing, doesn't make your words true.

Attacking my words as "weak", "FUD", or "uninformed" is arguing in bad faith. I gave a good faith effort to counter your points rather than simply labeling them "weak" or "uninformed".

There was no effort behind countering my words.

First you tried to pretend that software is somehow different because it "doesn't do any physical harm".

I addressed that directly with a very specific example of physical harm.

(Besides, there are many more concerns beyond just physical harm, and my example of food poisoning was just an example that you must follow safety regulations even if you're a "one-person" company)

So your next counter-claim was a non-sequitur that "since it was recalled it means that there are regulations" which doesn't make sense even logically, which I addressed as well.

And the rest is just unsubstantiated claims that the law is redundant at best and bad at worst which is pure FUD.

How's that for good faith argument?

With this, I remove myself from this discussion. Adieu.

It means you will get treated differently whether you operate a one man show or a global conglomerate.

Follow best practices and demonstrate that you care goes a long way (that has been demonstrated time and time again in courts throughout the union).

Also it differentiates between what kind of product you are building (see the annexes).

Most of the requirements (look them up) are best software dev practices unless you are in one of the specific "critical" categories of products.

Then, to be honest I don't really care that you are a one person (commercial) shop when my car gets steered off the road because of a preventable security hole.

And then there’s the real world issue of Abmahn-Factories in Germany.

Unless you sell critical products as described in Annex III[1] the requirements to fulfill CRA are quite harmless. It's mostly stuff you should be doing anyway like a risk assessment and documentation. An additionally requirement is to provide a conformity assessment, which you can do yourself for non critical software, and you must report vulnerabilities within 24 hours.

Not too bad really.

[1] https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...

The light is quite large and and vague.

Ya so if some kid whose 16 is messing around on his computer figures out some cool app starts publishing it and then bam the incumbents can smack him down.

The regulations are designed to deepen the software moat, and security theater, and I say this as an InfoSec professional.

This is nonsense, because non-commercial activities are exempt from the CRAs requirements.

Yes and regulation will ensure non-commercial activities stay that way. I write open source code because I love building software tools and there aren't a whole lot of opportunities to commercialize my work. I'd love it if an opportunity ever came along one day to get rich building a tool, that I could pounce on, in which case I'd love to know that I wouldn't immediately get jumped and mobbed by regulators.

"Yes, I would like to sell commercial software, but bear no responsibility for the software I'm selling".

If you cook for your friends, but then decide to open a commercial kitchen, do you think you will be exempt fromfood safety regulations?

I'm not exactly building bridges or x-ray machines, or putting food in anyone's mouth. Right now I'm building programs that generate text, and it isn't even real text like in a book that could potentially fall off a shelf and injure someone, we're talking about digital words on a computer that no one except nerds used to care about and anyone is still free to ignore, except normies won't if see an opportunity to rentseek the harmless builders doing it.

Too much ranting, too little sense. Are you sure you haven't generated it with your generator? ;)

You're trying to carve out an exception for you yourself specifically because you assume that your special case is too special.

1. Laws don't usually work that way

2. There are innumerable cases when "innocuous" software is used as an attack vector precisely because "we don't do nothing why would we keep our software secure"

3. In EU you're safe until you really screw up. More discussion in this thread: https://news.ycombinator.com/item?id=38819780

If the same kid decides to throw a party, train their cooking abilities and everyone ends up on hospital due to some stuff they cooked, they will have lots of fun talking to police officers.

> critical products

IANAL but Annex III Class 1.2 states: "Standalone and embedded browsers" which would implicate every electron app. Class 1.5 states: "Products with digital elements with the function of virtual private network (VPN)" is so vague it could apply to video game chat messages.

The problem with regulations like this is they're so vague and will be selectively enforced. They won't affect Big Corp but will affect small business and solo developers.

In my experience with the GDPR it's selectively enforced on large companies and not small mom and pop shops unless they are handling unusually sensitive data. The legal system can only handle a couple of cases at a time, spending that on small shops with inconsequential signal effects isn't their MO.

With Electron you are not developing an embedded browser, it is a dependency of your product which means you are responsible to keep this dependency secure and up-to-date.

I don't follow how rules for software with VPN functions could apply to a video game chat, but as with all laws intend and interpretation matters. Successfully convincing a judge that your game chat is a Class I critical product is unlikely.

I also don't think that the CRA is too vague. Rules that are too specific will just be circumvented. Enforcement works like any other market rule. You can sell all sorts of non-compliant products in the EU but if you are found out you pay a fine. It won't be any different with the CRA.

Yeah this could be terrible unless there's very specific exceptions for sub 1mil revenue players.

Lots of big players are already providing shit software to millions of customers especially through government contracts because they've hired armies of legal and sales teams, squashing the little guy in the process.

If just providing some small web service built on top of open source now requires hiring a huge legal team, well goodbye to any entrepreneurship.

I know this because i've seen big players win contracts over actually talented people 9 of 10 times because they can play this regulation game, and i've seen small companies burn 100s of thousands in consultancy fees over GDPR that made zero difference for their Wordpress setup that a talented coder could have used 10 hours to fix.

That said the intentions are good, but for some reason EU thinks small players should have the same extreme measures as Facebook, Google, ie the actual reasons this regulation was made in the first place. Bizarre.

In fact, I'm even wondering if this legislation is not a legal trojan horse in some way.

Look at everything that is included (VPN, OS, anything related to security,...). This regulation forces to have full declaration of the identity of the editor/manufacturer and more. Any other product that is not under the control of the authority will be illegal.

> under article 10(4a), integrators are obliged to share any vulnerabilities they have found in a component with the (open source) manufacturer, including any patches they might have developed

That's good to know about as a security consultancy.

Whenever we found an issue in software made by a third-party vendor, we already recommend reporting it and offer to do it for them (unpaid time on our part, but it gets both the finder and our company publicity, and when leaving it up to the customer then it might not happen which is also bad for everyone else), but now we can say it's required and not just a recommendation. And if there is patching on the customer's part, we get to check the fix if they give it to us for reporting, which in turn makes them more secure.

For us, the situation doesn't really change, but for the tech industry as a whole I see only upsides (at least of this part) :)

Very good explanation and very encouraging

> The Debian statement appears to be based on an earlier version of the CRA.

> It for example says “Knowing whether software is commercial or not isn’t feasible, neither in Debian nor in most free software projects”. Under the CRA there is no need to figure that out for Debian.

> “Having to get legal advice before giving a gift to society will discourage many developers” - the final version of the CRA is clear that if you are giving a gift, the CRA does not apply to you anyhow. There is now a very clear statement on that (see above).

I'm glad that the concerns of the open source community were clearly heard and incorporated into the CRA. Experts were listened to and being involved in this regulation helped making it better.

As the author states "regulations are never fun" bjt this is as good as it gets.

I'm an optimist and hope that this will somewhat dampen the voices on the internet and (unfortunately) on HN that claim the EU is only filled with near evil idiots acting to destroy European industry.

I guess we will see how it goes next time (admittedly my hope is small).

> The state of computing security is dire, and governments around the world have rightly decided things can’t go on like this.

What is this? Software is more secure then ever.

Some people obviously prefer the old days when security problems were hidden within proprietary code so the only people who knew about them were the ones who found the exploit.

Like that won't still be possible?

You must not have looked at sbom files recently. Software complexity is exploding due to the easy availability of libraries for just about anything. It is not uncommon to find dependency trees eith several thousand items for a relatively small piece of software. Adding a new dependency maintained by one person on the Internet seems to evoke little more than a passing thought.

Related. I thought there were others, can anyone find them?

Open source liability is coming - https://news.ycombinator.com/item?id=38808163 - Dec 2023 (218 comments)

Debian Statement on the Cyber Resilience Act - https://news.ycombinator.com/item?id=38787005 - Dec 2023 (144 comments)

Can open source be saved from the EU's Cyber Resilience Act? - https://news.ycombinator.com/item?id=37880476 - Oct 2023 (12 comments)

European Cyber Resilience Act [Discussion] - https://news.ycombinator.com/item?id=37580247 - Sept 2023 (4 comments)

Am I right in thinking that if you were a small indie OSS developer that offers commercial support or similar "services", all these regulations will now apply to you?

While I get they new draft has changed it so if you are non profit or accepting donations it doesn't apply (I think?) The biggest problem is that isn't a great model for OSS anyway.

A much better model imo is charging for a "pro" version with support included and maybe some extra features.

This regulation is likely to totally kill the viability of that model if you need to do expensive security audits.

It applies to you in the sense that your services are covered by the CRA. Your projects themselves probably don't unless you have an open-core model where you have a commercialised 'supported' version, in which case you're not responsible for all users, but you are on the hook for the commercial users.

In a way, I don't think it's that much at odds, if someone comes up with a great open source project but not to 'give away' as a present or in a classic FOSS style, but instead as some sort of funnel to get paying customers (which includes pure support), you're already doing it commercial, and even without the CRA you'd probably be on the hook for doing it right anyway.

This is Big Tech only: only them will have the amount of resources to fit the requirement of such act.

The only way for small actors is to move to... super small and simple tech... and they better be sure small tech<->big tech interop is hardcore regulated too or they will be zapped.

Yep, forget about those grotesquely and absurdely massive and complex web engines...

And now I am thinking about the hardware... they better come extra clean.

> This is Big Tech only: only them will have the amount of resources to fit the requirement of such act.

I haven't read the actual legalize in the final version. Which kind of responsibility is putting unbearable burden on the average web developer who slaps together few input fields and makes a nice CSS job?

Add: Auditing all the million dependencies in node_modules comes to mind, but maybe it's a good incentive to not.

For "juicy" web sites, 10% is coding (and better _really_ think about FPGA/assembly), 90% actively protecting it... "web developer" is only a sub-skill of the actual "job".

Not to mention, in this very case the "whole perimeter" does include the client program (the OS is tied to the hardware), aka a Big Tech web browser. And since this is not small tech (which would be noscript/basic (x)html), this will de facto exclude anything which is not Big Tech for most "legal" projects which wants some ultra heavy and fancy "web". Because near 100% of the project managers out there won't even take the risk anymore with such act.

Yep, those who are not Big Tech better be ready to REALLY, and I mean REALLY get close to metal and use REALLY small and lean tech, and namely to do NOT use Big Tech open source web software (blink|geeko/webkit+SDK).

This is weird because that will kill economically any attempts at Big Tech alternatives, ALL OF THEM.

Big Tech is BILLIONS OF $ OF CASH WITH THE BACKUP FROM INVESTMENT FUNDS WORTH TENS OF THOUSANDS OF BILLIONS OF $: THERE IS NO FG&* ECONOMIC COMPETITION OR ANYTHING, WORLDWIDE AND THEY GET EU WIDE LAWS ONLY FOR THEM???

The first thing is to get ultra hardcore regulation on small tech<->big tech interop, and I really mean _small_ and _lean_ tech (the second you have Big Tech web engine or a massive SDK with an ultra complex language, you are done for).

Not to mention, EVERYBODY KNOWS COMPUTER SECURITY IS A FANTASY: IT DOES NOT EXIST, IT IS ONLY A PROCESS, NOT A DELIVERABLE WARANTY. And as far as I know, metrics to know if the "process" was good enough do not exists, and in such complex system it is just BS.

I've got to say, I like how people have started paying attention to these laws, actually reading them, and them write measured takes based in reality, and not in the hallucinations by the industry that is usually very much oppposed to any kind of regulation.

Other good takes in recent regulations:

- Unraveling the EU Digital Markets Act https://ia.net/topics/unraveling-the-digital-markets-act

- The truth about the EU AI Act and foundation models, or why you should not rely on ChatGPT summaries for important texts https://softwarecrisis.dev/letters/the-truth-about-the-eu-ac...

There is a lot of talk about who this regulation is supposed to cover, but not a lot about what it actually requires if it covers you. The best I could find after a couple quick searches was that you're supposed to provide information about the security mechanisms used and regular security updates over the lifetime of the product. Is there anything else? This doesnt sound terribly hard to comply with at first glance.

One example from the BSA (Business Software Alliance) statement on an earlier draft of CRA, https://www.bsa.org/files/policy-filings/11012022eucra.pdf

   The CRA requires manufacturers to ensure vulnerabilities are handled effectively for the expected product lifetime or 5 years, whichever is shorter.

I guess you can read the text. EU legalize is quite approachable most of the time and as a practitioner of the domain the regulation applies to, it should not be that hard to get the gist.

This is described in Annex IV, V and VI [1]. You must do a conformity assessment and provide a declaration of conformity. For non-critical software you can do the assessment yourself see the first five points in Annex VI. The only thing that maybe requires a bit of effort is that you must write some technical documentation including a cybersecurity risk assessment during the assessment if you have not already done so. For critical software the process is of course a bit more involved because it requires certification by a "notified body".

[1] https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-...

> “(10) This Regulation applies to economic operators only in relation to products with digital elements made available on the market, hence supplied for distribution or use on the Union market in the course of a commercial activity.”

So if you wanted to release an open source product, but try to monetize it in some way by providing extra services on top of it (i.e. backup / sync across devices service), this totally applies?

What if the open source product is used as a marketing asset of a commercial product but otherwise is not commercial by itself?

Boy, I hope the new version is better.

If we don't want poor regulation, we had better regulate ourselves first.

Bonus: regulating ourselves might fund Open Source. [1]

[1]: https://gavinhoward.com/2023/11/how-to-fund-foss-save-it-fro...

Yes an improvement but that’s not hard to improve on terrible. This is more wasted money, time and effort from the EU. The same people that made internet browsing miserable with cookie blah and the same people that don’t understand data or AI but will bring our garbage regulation about that too. Huge sigh!

Well, this article opened me some insights.

What I see, in any way, CRA will open new page in history of OSS.

Now OSS will divide to two parts - software for fun (may be for education, arts and science, read more), and serious software with liability.

I'm pretty sure, for example, ISP and big tech using OSS and contributing to OSS will become much stricter in what they allow in PR's, and in what they use as dependencies.

For about education, EU policies for toddlers/teenagers are stricter than for adults, so, possible appear of restricted teen versions of smartphones software, and one of restrictions could be only liable software.

Also, some business entities will be prohibited to use software which avoid liability, so, most current OSS could become prohibited (because many dependencies are not liable).

It's now hard to predict exact, but I'm sure, will be restrictions in air/space and in transportation; manufacturing involving dangerous substances and dangerous environments; may be restrictions in HoReCa businesses.

Science/arts usually have exceptions for many restrictions, they allowed to free use copyrighted or prohibited for public/commercial/wide usage things, like Nazi symbols, but only while "enough to explain idea", or "enough data for research", nothing more.

For about author question "who will be Open-source software stewards?"

That's easy. From juridical point, all software without liable owner except mentioned science/arts, will be prohibited in all businesses working at restricted markets.

For listed above, could add (cellular) communication companies, energy (electric or gas) companies, water pipes, and other infrastructure critical, medical, emergency services.

And from Democratic experience, ANYBODY could become steward, just need to claim responsibility and may be conduct some bureaucracy procedures to prove ability to be liable.

From this my conclusion, if NOBODY will claim to be steward for some software, it will automatically become prohibited for mentioned businesses.

Even reading thru all the new law to cross check it with existing products is alot of work for micro companies. We already felt it with GDPR, and this seems much worse in that regard.

I have mixed feelings about CRA, but I am satisfied with FOSS protections. I wish it could allow for more commercialization though,not just donating.

As for commercial work, it's good to have a lighter regime for small, low risk products, but it's still alot of head scratching and uncertainty on our part. Also ditto for independent HR and payroll systems, as they aren't low risk. I wonder if their VPN/VM setups they always included work towards security of the app? Again, more work figuring that out.

> alot of work for micro companies. We already felt it with GDPR

No. No, you haven't. GDPR was literally a non-issue for micro companies, because all micro companies had to do with GDPR is not gather data they didn't need.

Same here: all you'll need to do is to do due diligence you already should have been doing to begin with

I dunno, the second-ever GDPR enforcement action was against a kebab shop: https://www.enforcementtracker.com/

Lots of tiny businesses on that list too. Also a bunch of local governments, weirdly.

Feels like if we’re at kebab shop levels of granularity for 88 pages of rules governing the entire planet, “a lot of work” is unavoidable, no?

>I dunno, the second-ever GDPR enforcement action was against a kebab shop: https://www.enforcementtracker.com/

I wish people would actually read the links they post.

That "poor kebab shop" was fined for this:

--- start quote ---

CCTV was unlawfully used. Sufficient information about the video surveillance was missing. In addition, the storage period of 14 days was too long and therefore against the principle of data minimization. Addendum: Fine has been reduced to EUR 1500 by court,

--- end quote ---

GDPR is there only because of the data storage. Illegal CCTV is covered by different laws that, in a twist that should surprise no one, you shouldn't break even if you are a kebab shop.

The actual first business listed there is a "betting place", and it was fined for illegal use of CCTV, too.

> Also a bunch of local governments, weirdly.

It's not weird. It's how laws are supposed to work: governments are not exempt from them.

I wonder if there was ever any instance when regulating something has brought in more of that thing. Anybody has an example?

Driving cars is regulated now. We have more than ever.

Street markets also known as bazaars.

Restaurants, food trucks, consumer electronics, medical devices, clothing, products chain delivery,...

> bazaars

Here in Eastern Europe we are having fewer and fewer of those during the last 30 years. My favorite cheese maker closed her small shop and started selling direct from home since local authorities started demanding test and workshop inspections (bribes really). She's planning to switch to selling the milk directly to one of those big name supermarket diary processors soon. Less money but fewer headaches.

I have an impression that regulations related to that kind of stuff usually have exemptions for those exact cases -- small operators, direct to customer or self-consumed produce, etc, etc. As a fellow enjoyer of bribe-infested jurisdictions I get the point zo. In my country the balance between more regulation/less bribability tends to tip towards less bribability for those exact reasons.

Given that around me, they keep going, how much of it is caused by regulations, and how much of it is caused by major supermarket chains being deployed all over the place?

Around me, meaning DACH countries, Iberian Penisula and some Mediterranean countries.

They're connected, of course: regulation favours incumbents, big players who can afford the cost and headache of compliance. Small players and startups are slowly pushed out, they never grow to become strong, competition thins out and then people complain and wonder where are the little guys and ask for more regulation against the big hypermarkets to solve the problem regulation created in the first place.

The mind boggles.

Financial markets/stock markets are pretty regulated. From what I hear there is quite a bit of stocks being traded. Trading even seems to increase over the years.

> Financial markets

There is only one of those in my whole country. Not much competition there if I'd ever want to do an IPO.

All that regulation sure made a lot of stock exchanges pop up...

IPOs are way way down since Sarbanes Oxley.

https://www.jstor.org/stable/43303857

The gloablized world and the abundance it has is driven by laws and regulations.

Even the fact that you have abundant clean water and good food that you can enjoy in your electrified and heated house and you can order an overnight delivery for hundreds of things that will just fit and/or work in your house is the direct result of thousands of regulations.

I thought it was the direct result of millions of entrepreneurs and businesses willing to put up with onerous regulation to still offer me all those goods and services I enjoy.

By definition regulation adds restrictions and obligations making their life a little (or a lot) harder and closing down the ones who'd rather focus on making stuff than deal with bureaucratic rules.

Still waiting for an example of a regulation which directly resulted in more of the thing it regulated.

Why care. Shoot for Mars. Attacks. Shoot from the hip ask questions later. #righttobarearmalite

Reply on news.ycombinator.com