LWN: Comments on "Open source and the Cyber Resilience Act"

Enforced signed firmware?

pizza — Sun, 15 Jun 2025 22:11:06 +0000

> The requirement for signed firmware is basically to prevent your system being hacked in such a way that rebooting won't fix it.

The systems I am currently working on (in the automotive space) go well beyond that -- "secure boot" is the *only* way to boot, reinforced by numerous laws and regulations that (1) make it a literal felony to break those locks and (2) "strongly disincentivize" manufacturers from providing any mechanism that allows mere "owners" to modify (or even *view*) anything of substance.

Welcome to the future.

Enforced signed firmware?

kleptog — Sun, 15 Jun 2025 21:20:49 +0000

The requirement for signed firmware is basically to prevent your system being hacked in such a way that rebooting won't fix it. All they need to do is for unsigned firmware replacement to require some physical interaction and they're set.

It's basically like that for PCs. You can boot alternate firmware, it just requires physical interaction. As long as malware can't transparently insert itself into the boot process you're fine.

Enforced signed firmware?

pizza — Sun, 15 Jun 2025 12:24:36 +0000

> Is this going to be another excuse for companies to enforcing signed firmware

Abso-effing-lutely.

I wonder how this will play out with respect to right-to-repair rules. From what I can tell it effectively neuters any possibility of the latter with regards to firmware.

Enforced signed firmware?

milek7 — Sat, 14 Jun 2025 16:49:46 +0000

>and mechanisms to ensure code integrity, such as signed images, in their products

That sounds bad for firmware freedom. Is this going to be another excuse for companies to enforcing signed firmware (like FCC certification requirements)?

Sharing bug fixes...

daroc — Fri, 13 Jun 2025 18:06:16 +0000

No, there's no mutex. marcH was just joking.

Sharing bug fixes...

naesten — Fri, 13 Jun 2025 17:06:42 +0000

I'm sorry, I can't tell if that's a joke or not, is there really a mutex?

Whom to ask?

kleptog — Thu, 12 Jun 2025 15:33:50 +0000

In the very first draft just searching for "open-source" would have lead anyone to the recital:

> (10) In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. [...]

This is a fairly clear and straightforward statement. The intent was clear, though it was the only reference to open-source. Now, plenty of people pointed out that "commercial activity" could do with some clarification since we want open-source developers to eat too and not everything involving money is commercial. The draft attracted hundreds of amendments and unlike in some legal systems where there's a speaker who chooses which amendments get voted on, in the EP they vote on all of them. The result is many more recitals and clarifications which I think are real improvements. Possibly even overkill, but this is lawmaking by non-lawyers for you.

The "placed on the (single) market" is a term of art which is related directly to the authority the EU has to make regulations in the first place. I hope this whole process has given people a little better understanding as to what it means.

Whom to ask?

Wol — Thu, 12 Jun 2025 07:10:12 +0000

> so when questioning authority the _dumbest_ answer is most likely the correct one. Just put yourself in their shoes and think of the mistakes you'd make in their position.

The cleverest person is usually the person who can recognise they are out of their depth, and asks for help. Which is why women tend to make good GPs (as someone who interacts with the medical fraternity far too much ...)

Cheers,
Wol

Whom to ask?

farnz — Wed, 11 Jun 2025 17:06:16 +0000

It's a little hard to tell whether it was always supposed to not apply to hobbyist developers

Even the very first draft I can find consistently refers to "placing on the market", which is a term of art that would have excluded hobbyist developers, since a hobbyist, by definition, does not place anything on the market (at most, they offer gifts to interested parties).

I'd therefore expect that it was never intended to apply to hobbyists, and the clarification we've seen is because "placing on the market" is a term of art that most of us aren't familiar with.

This isn't helped by the CRA trying to carefully balance allowing companies to contribute - or even run - open source projects without opening themselves up to liability, while not wanting companies to be able to escape liability for security flaws in products they sell by open sourcing some, or all, of the code (or, indeed, using ancient versions of open source stuff that's full of known flaws).

Whom to ask?

raven667 — Wed, 11 Jun 2025 15:35:33 +0000

In late with a small axe to grind ;-) tldr; just because someone is an expert in one thing, or in a position of authority/leadership doesn't mean they have super-human intelligence or omniscience, no one knows everything and everyone makes mistakes, so when questioning authority the _dumbest_ answer is most likely the correct one. Just put yourself in their shoes and think of the mistakes you'd make in their position.

> It's a little hard to tell whether it was always supposed to not apply to hobbyist developers and they just made this more explicit, or they hadn't considered it at all

These laws appear to be written in good faith, unlike a lot of US law written by some industry group for private advantage sneaking a fast one past the other legislators, and the people who write them _aren't_ _any_ _smarter_ than anyone else, they may have specific experience and training in the law but they are not omniscient gods. Kind of like the tendency to anthropomorphize LLMs, even well-meaning savvy people tend toward an underlying assumption that legislators and people at top of government know vastly more than they do and are making some sort of 9-dimentional chess moves that we can barely understand or interpret without the help of a priesthood of media pundits, when the fact is they probably just didn't think of it. In this case the draft law was put together with what they knew and had experience in and they relied on good-faith feedback to, loudly, tell them all the detail they missed, all the effects they forgot when drafting. Does anyone really thing that a human person could mentally keep track of all the effects and second-order consequences of even a 5-10 page law, it takes teams of people and the public reviewing it form their subject-matter-expert perspective to find the bad feedback loops and holes to shave off the worst of the potential negative consequences when changing societies rules.

Whom to ask?

Wol — Tue, 10 Jun 2025 08:40:52 +0000

> You should remember that it's largely written by non-lawyers. Only a third of MEPs have legal training. For most English is a second language.

Bear in mind they also have a very good translation unit. Dunno about today, but you can thank my Granddad for its tradition of excellence. He was the head of the Directorate in the EC days, and the stories are legion about his ability as a linguist and his insistence on "getting it right". He retired months after Britain joined and it went from 9 to 12.

Cheers,
Wol

Big dependencies versus many dependencies

taladar — Tue, 10 Jun 2025 07:47:14 +0000

And to add to that, getting other people to do something tends to always be harder the more levels of indirection there are so good luck getting one of those big dependencies to maintain their internal relationships to the level you prefer.

Whom to ask?

iabervon — Mon, 09 Jun 2025 21:59:55 +0000

I think the issue is that people did look at the first draft [1] and don't realize that it's not what actually became law. It's less a question of understanding the text as of looking at the correct version.

[1] https://eur-lex.europa.eu/resource.html?uri=cellar:864f472b-34e9-11ed-9c68-01aa75ed71a1.0001.02/DOC_1&format=PDF

CRA paperwork for a fee impact on "hobbyist" status

paulj — Mon, 09 Jun 2025 09:58:17 +0000

In Ireland, consumer protection laws around food, intended to protect customers of commercial food vendors (restaurants, cafes, snack bars, etc.), have in the last few years been brought into play around soup kitchens for the homeless. In particular, volunteer organisations who were - as individuals collectively working together in ad-hoc groups - organising the cooking and delivery of soup and other food to homeless around Dublin were threatened with legal action by the council, and ones that continued have been forcibly shut down by Gardai.

This is all part of a thing where the council doesn't like there being these quite visible homeless aid operations on central streets in Dublin, and so they're using every law and bylaw they can to try stop it - street vending laws, food safety, etc. But there can very easily be unintended consequences to broad sweeping "consumer protection" laws that put significant burdens on every little person trying to do stuff. And it all contributes to a socio-economic environment that ever more favours large corporates - big enough to be able to amortise the cost of managing red-tape and bureacracy over a larger number of operational activities - over individuals and small businesses.

CRA paperwork for a fee impact on "hobbyist" status

farnz — Mon, 09 Jun 2025 09:28:01 +0000

You did not make your library available on the market with a CE mark; you sold a CE-marked version to your low-batch toy manufacturer, for integration into that toy only (and your lawyer worked with you on the contract of sale to ensure that this version has restrictions that protect you).

At that point, I can demand a security fix for the toy. I can't demand a security fix for other uses of the library; the CRA doesn't extend that far. If the toy is not exploitable, no liability for a fix. If the toy is exploitable, and you fix the toy use case, but not the more general case, no liability for a fix.

The fact that it's also been put in a huge number of phones is irrelevant to legal liability - they got the open source version, and liability ends with the entity that placed your library on the market (possibly Google, possibly the ODMs, possibly even the retailers), and they've got to find a way to negotiate with you that works for you as well as for them. And that applies even if their version is bit-for-bit identical to the CE marked version; it's the provenance that matters for liability, not the code itself.

Whom to ask?

Cyberax — Mon, 09 Jun 2025 08:15:37 +0000

Sidenote: European bureaucracy is awesome. The laws are usually well-structured, easy to read, and pretty exhaustive.

If you want another great example, check these documents that outline the repairability scoring criteria: https://susproc.jrc.ec.europa.eu/product-bureau/product-g...

Whom to ask?

kleptog — Mon, 09 Jun 2025 08:07:06 +0000

People can also just read the law itself [1]. The article says it would put you to sleep but it's not that bad. Perhaps a bit verbose.

You should remember that it's largely written by non-lawyers. Only a third of MEPs have legal training. For most English is a second language. They're not going to be making complicated phrases which difficult meanings. There are a few terms of art like "putting on the market" but by and large it means what it says in plain English.

There's actually a running debate about whether it's a problem having laws written by non-lawyers. Some countries like NL require it to be written by people with specific training and it leads to compact and concise though tricky to read laws. I think the EU approach isn't too bad, especially since the specific tekst isn't important, as long the intent is clear.

[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847

Propaganda?

Jyx — Mon, 09 Jun 2025 07:11:58 +0000

Thank you for sharing your thoughts about our panel discussion (I arranged it and was also the moderator). I wanted to clarify that while we did share topics in advance to ensure everyone was prepared, there was no script involved. As the moderator, it was important to me that the conversation flowed naturally. We actually never had time for a sync call before the live event, which is usually good practice, but fortunately for me, all of the panelists have lots of experience and are great speakers, so I had just to kick things off and then it was almost self going. I appreciate your feedback on this topic. // Joakim

Whom to ask?

iabervon — Mon, 09 Jun 2025 07:07:41 +0000

What I heard was that the first draft of the CRA didn't really address the case of hobbyist F/OSS developers, and sounded bad, but the feedback led to explicit statements in the next draft that it didn't assign them any responsibilities. It's a little hard to tell whether it was always supposed to not apply to hobbyist developers and they just made this more explicit, or they hadn't considered it at all, or they had wanted to have it assign responsibilities to all developers until the got the feedback, but I remember the people who were initially worried about it being pleased by the changes that were made to the text before it was passed.

So another reason to ask for a quote from the law is that they may actually have a quote from what didn't end up becoming the law, and be glad to find out that their concerns were actually addressed since they last looked into it.

CRA paperwork for a fee impact on "hobbyist" status

marcH — Sat, 07 Jun 2025 14:18:38 +0000

> A vulnerability is discovered in this library. Google Android security team, security teams of 500 ODM manufacturers and 10 million security-conscious owners of headsets all come filling my inbox and demanding a security fix.

Whatever the law says, that seems extreme and unrealistic.

- Google is likely to just go and fix the vulnerability itself to preserve the value of its brand.
- ODMs are more likely to first pressure the "bigger" fish with whom they already have a business relationship and contacts there, and who has more manpower and is more likely to get things done one way or the other.
- Good luck finding 10 million "security-conscious" users and good luck finding end users technical enough to understand the vulnerability is who is to blame. You could receive some email, granted. But not from 10 million people.

PS: do ODMs have a security team? ;-)

CRA paperwork for a fee impact on "hobbyist" status

dottedmag — Sat, 07 Jun 2025 11:23:09 +0000

Thanks, now I know what to look for — the term "making available on the market" is a crucial one.

CRA paperwork for a fee impact on "hobbyist" status

Wol — Sat, 07 Jun 2025 10:57:41 +0000

> A local manufacturer of low-batch toys comes to me and asks me for a CE mark paperwork so that they can include this library into their new toy. they expect to produce 100 devices, and the the devices will play a fixed set of .mp3 files. We agree that the probability of the security issue in this device is low, and they pay me, say, €500 euro for CE mark paperwork for library version 1.0.

Regardless of the meaning of "on the market", you SOLD one hundred copies of your widget, with 100 marks (one per toy), to the toy manufacturer.

Those are the only marks you have to worry about. As farnz said, despite the bits being the same, Google's widgets do not have your mark, and are therefore "not your problem".

Cheers,
Wol

CRA paperwork for a fee impact on "hobbyist" status

johill — Sat, 07 Jun 2025 10:29:19 +0000

Not really well-versed with this, but for all I've seen it is, as usual, the color of bits that matters, even if they're the same bits.

You'd never issue a CE mark to the general public to use for free for arbitrary purposes, that'd be silly. It's not even clear that you'd be _allowed_ to, as an "open-source software steward":

Given that the light-touch and tailor-made regulatory regime does not subject those acting as open-source software stewards to the same obligations as those acting as manufacturers under this Regulation, they should not be permitted to affix the CE marking to the products with digital elements whose development they support.

Although I guess the argument is that once you provided the mark, then you're no longer just an "open-source software steward" but actually on the hook.

If you just post code:

The sole act of hosting products with digital elements on open repositories, including through package managers or on collaboration platforms, does not in itself constitute the making available on the market of a product with digital elements.

And if you aren't making it available on the market it doesn't need/have a CE Mark.

Now, that's not good for your local widget manufacturer, since they don't want to be on the hook for your software. So you have a contract with them and make available to them separately, as part of the contractual relationship, the same software bits with a different color. Now you're making it available on the market and need the CE mark, which implies maintenance, but that was the whole point of the contract. So the CE mark you issue in this case is for the specific integration into the local widget manufacturer's toy and part of your contractual relationship with them. It extends - to some extent - to their customers though, although they'd probably have a hard time figuring our your component is in there and, if they do, finding a way to repair it. Not your problem, though if they do get to all that then you might have to provide some security fixes that are actually applicable to this particular product.

As for Google doing whatever they do:

When integrating components sourced from third parties in products with digital elements during the design and development phase, manufacturers should, in order to ensure that the products are designed, developed and produced in accordance with the essential cybersecurity requirements set out in this Regulation, exercise due diligence with regard to those components, including free and open-source software components that have not been made available on the market.

They only got the bits via your open source repository, which was never "made available on the market" (see above.) Now they're on the hook. Maybe they will send you email anyway, but there's /dev/null.

Now you could ask is all of that plausible?

The question I guess will come down to whether you can be both an "open-source software steward" and a "manufacturer", even when the text says

(13) ‘manufacturer’ means a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge;
(14) ‘open-source software steward’ means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products;

Worst case, you'd need a different legal person (company) to be the manufacturer, how it manufactures the thing is not all that interesting, so maybe it just pulls it from your personal (natural person) repository as the sole "manufacturing" step.

Anyway, that's just what I think, but given the level of discussion etc. I find it highly implausible that such a setup is or was intended to be prohibited.

CRA paperwork for a fee impact on "hobbyist" status

dottedmag — Fri, 06 Jun 2025 23:13:14 +0000

If you don't think it's not terrible, consider the following situation.

I am a mantainer of a small C library that parses ID3v1 tags (real case).

A local manufacturer of low-batch toys comes to me and asks me for a CE mark paperwork so that they can include this library into their new toy. they expect to produce 100 devices, and the the devices will play a fixed set of .mp3 files. We agree that the probability of the security issue in this device is low, and they pay me, say, €500 euro for CE mark paperwork for library version 1.0.

All is fine.

But at the same time Google engineer incorporates the same version 1.0 of my library into Android, marks it as "covered by CE mark by manufacturer" and ships it to all the ODMs, who produce 1 billion of headsets.

A vulnerability is discovered in this library. Google Android security team, security teams of 500 ODM manufacturers and 10 million security-conscious owners of headsets all come filling my inbox and demanding a security fix.

It might be a trivial security fix, but even handling all this amount of incoming email will bankrupt me, and I guess I also have to answer it all?

Still not terrible? Any open source maintainer taking any amount of money is on the hook to support the whole world, and basically can be held at the gunpoint by any large manufacturer who can threaten to incorporate the code into their product.

The alternatives are: 1) never take a cent of money; 2) tell first potential customer to boot the bill for supporting the whole world.

Am I incorrect somewhere?

Whom to ask?

johill — Fri, 06 Jun 2025 20:54:43 +0000

"Omar Ennaji is a Legal and Policy Officer in the Unit for the Digital Transformation of the Industry, European Commission."

"Mr Benjamin Bögel is Head of Sector for Product Security and Certification Policy at the European Commission."

Whom to ask?

pbonzini — Fri, 06 Jun 2025 20:47:54 +0000

I think it's more likely to be members of the European Parliament than the Commission (which in national government terms would be the ministries/secretaries)? I remember seeing a MEP (and former engineer at Red Hat) present at FOSDEM about app stores.

Whom to ask?

daroc — Fri, 06 Jun 2025 17:33:48 +0000

That's a good idea; I'll add it to our list of topics.

Big dependencies versus many dependencies

farnz — Fri, 06 Jun 2025 16:54:41 +0000

The problem is that what looks from the outside like "one big dependency" is often internally "100 small dependencies sharing a repo and a single point of contact", with worse accountability issues than if it actually were 100 small dependencies, since you have the "everyone thinks somebody else is responsible for that module, but nobody will take responsibility".

As a result, "all other things" are not equal; the larger a dependency is, the more likely it is to be hiding subcontracting from you, with the resulting pain around too many layers of subcontracting.

There's an irreducible complexity here; each component part of the system needs maintaining. If you have 100 small dependencies, each of which contains one component part, then you have 100 relationships to maintain. If you have 10 bigger dependencies, then you see 10 relationships to maintain, but those 10 may well be simply managing 10 relationships themselves (and not maintaining anything), leaving you dependent on 110 relationships going well (the 10 you maintain, plus the 100 hidden sub-contractors).

If you're aware that this is what's happening, that can work better than directly managing 100 relationships; if you believe that you're reliant on 10 relationships, but there's actually 100 hidden relationships, that's where things can go horrifically wrong (since the 10 you think you're reliant on have reasons to lie about the relationships they're maintaining with their sub-contractors, in order to keep you happy).

CRA paperwork for a fee impact on "hobbyist" status

Wol — Fri, 06 Jun 2025 16:37:49 +0000

I think I see what you're getting it - because you've attached your CE to your software you're thinking like physical goods where the CE / Kite / whatever mark is a physical stamp. And because a copy of your software is an exact copy, is the mark copied too?

No! It's just like copying a physical good. If you copy someone else's physical good, and you copy their trademark/other marks too, then that's fraud. There's nothing stopping you copying their goods (well, there may be), but pretending they made that copy when they didn't is a serious offence. There's nothing stopping someone copying your software, but likewise copying your marks as well is a serious offence. The marks are only legal when they're attached to the original article, AND NOT UNAUTHORISED COPIES.

(Just because a copy is unauthorised, doesn't necessarily mean it's illegal. Just that the owner of the original didn't give you permission to make exact copies. And it doesn't fall foul of the GPL because you haven't lost any of your copyright rights, or your FSF freedoms. And the GPL obliges you to remove marks if so required.)

Cheers,
Wol

CRA paperwork for a fee impact on "hobbyist" status

farnz — Fri, 06 Jun 2025 16:28:18 +0000

Like I said, there's nuance here.

You're not on the hook for "all the future secure updates"; there's a timeout after you've been paid for a version, after which you're not liable, and you're not liable for updates to versions that you never "placed on the market" (a term of art, here).

Additionally, everyone demanding updates from you can only demand updates that apply to the component as integrated into your paying customer's product. You are entirely entitled to refuse to supply a security update that's not relevant to your paying customer's product, and you're entirely entitled to refuse to supply it in a form other than that needed to integrate with your paying customer's product.

However, if your paying customer doesn't care about an issue in your component, but their customers do care, you are liable for the issue, even though your paying customer isn't demanding an update - and this is transitive, so if your paying customer's product is a component, and I integrate that component into my product, my customers can demand a fix to your component from you directly, not just from me, or from your paying customer.

It's not terrible - it's setting up the same situation as exists for physical goods today; you are liable to everyone for issues with your component as integrated by your paying customer (and only if your customer's integration is done to an acceptable standard), but not for issues with your component when it's separated from your paying customer's product and used with something else.

And note that your fix to a security issue does not have to be acceptable to users who aren't paying; for example, if your paying customer's product only ever communicates over Unix sockets with your component, a fix to a security bug might be as simple as "completely remove IP support in this version". If that breaks my use case, well, that's my problem, because you fixed the security flaw that matters to the paying customer's product.

CRA paperwork for a fee impact on "hobbyist" status

Wol — Fri, 06 Jun 2025 16:26:56 +0000

And this is EXACTLY what all the fuss was about with FLOSS when the CRA was first mooted.

To the point that the law explicitly forbids you from saying "not my problem" if you didn't yourself pay for it.

So yes, you're spot on. A CE cannot exist without a contract explicitly saying who is liable for what.

Cheers,
Wol

Whom to ask?

hailfinger — Fri, 06 Jun 2025 16:24:40 +0000

Ask the European Commission. (Yes, really. They attend a lot of F/OSS events and are willing to answer questions.)

The European Commission was at FOSDEM 2023, 2024 and 2025, participated in panel discussions, held excellent talks and answered questions from the audience. Those talks had FOSDEM attendees as target audience, and the speakers excelled at presenting the topics at hand in a way that could be easily understood by a technical audience.

If you're interested in the interaction between CRA, PLD and F/OSS, I highly recommend listening to the recordings of the various FOSDEM CRA talks in 2023 (some of those statements may be outdated), 2024 and 2025. A really good starting point is https://archive.fosdem.org/2024/schedule/event/fosdem-202... . Please make sure to listen to the video and not just read the slides, the interesting content is what is being said.

IMHO the CRA is a really well-written law which goes to great lengths to shield hobbyist F/OSS developers from responsibilities and instead places those obligations on the companies earning money with code they didn't write. I think that's entirely fair. Oh, and the law also is pretty easy to read and understand, so each time someone tells you "CRA is bad for open source / consumers / whatever", you can challenge people to back up that claim with a quote from the law. So far, in personal discussions I have watched all of those fearmongering claims collapse.

@daroc maybe LWN.net can cover the FOSDEM CRA talks. They might be interesting and relevant for the LWN.net audience even if those talks are a few months old.

Sharing bug fixes...

marcH — Fri, 06 Jun 2025 15:55:56 +0000

Sorry, I replied to this comment without trying (and failing) to take its mutex first :-)

Sharing bug fixes...

marcH — Fri, 06 Jun 2025 15:51:27 +0000

This is big! Big enough to require a small correction in the article IHMO.

CRA paperwork for a fee impact on "hobbyist" status

nim-nim — Fri, 06 Jun 2025 15:42:54 +0000

If they’ve structured the CRA correctly the CE mark attaches to a product (a code + a maintenance contract, and the mark requires some minimal level and length of support). And the same code, bit for bit identical, can exist without the maintenance contract and is not eligible to the CE mark.

And you can copy the non-CE code (provided the code licence allows it) and make it a CE product by taking up the maintenance obligations yourself (why you would want to do that instead of paying the original author is up to you).

So no you should not be liable to someone that has not signed a support contract with you. If he has signed this contract, and the contract says CE, you can not redefine your maintenance obligations lower than what the CE system requires.

Whom to ask?

dottedmag — Fri, 06 Jun 2025 15:22:05 +0000

The discussion in comments is so confusing. Is there any entity that a hobbyist open-source developer could get a help with all this rigmarole?

CRA paperwork for a fee impact on "hobbyist" status

dottedmag — Fri, 06 Jun 2025 15:20:10 +0000

So, unlike what Wol said above if I ever get 1 cent of money from anybody I'm on the hook for all the future secure updates even if I'm paid by a single client? And it will disincentivise all the possible clients for paying to begin with because everyone else except the first one will get be able to demand updates from me for free?

That's terrible.

Sharing bug fixes...

nim-nim — Fri, 06 Jun 2025 15:12:17 +0000

Well of course that depends on the legal definition of who is maintaining what.

However not passing the fix upstream is akin to a legal admission *you* are maintaining (and liable) for your own fork. And are liable for any problematic rebasing (you can not both deny an upstream is maintaining something, and disclaim your responsibility when merging the changes done by this upstream).

CRA paperwork for a fee impact on "hobbyist" status

farnz — Fri, 06 Jun 2025 15:08:13 +0000

This gets complicated fast, but no, issuing a CE mark means that you accept legal liability for the quality of the product or component you've so marked, no matter who's using it, or who it's sold to.

With that said, there's nuance here. A CE mark is not a guarantee that it's up to standard for all possible uses someone might put it to, in all possible cases; rather, it's a promise that, within the scope of use that you could reasonably be expected to predict, it's up to standard. If you're selling a completed end-user product, then you're liable for all end-user type uses; if it's a component part, then you're liable for its quality when it's used for the purpose it's intended for, and integrated with reasonable care and attention to detail.

So, for example, my car's fuel filter is CE marked, and the manufacturer is liable for problems with the fuel filter being sub-standard, as long as it's been installed properly in a diesel-fuelled engine. It's a component part, so they're not liable for problems that occur if I misuse it to (say) filter cooking oil, instead of diesel, since that's using it for a purpose it wasn't intended for, nor are they responsible if I don't tighten it to spec, since that's a failure to integrate it with reasonable care and attention to detail. They are liable if I install it to specification, and because of a design or manufacturing flaw, it breaks apart and damages the engine it's attached to; however, even though it's integrated into my car, they're not liable for faults in other parts of the car unless I can show that they were caused by a fault in the fuel filter.

The CRA extends this line of thinking to digital goods; if your product is a completed product, then you're liable (to the world) for basic cybersecurity in your product. If it's a component, you're liable for flaws in the component when integrated correctly, but not (e.g.) for flaws caused by errors integrating it into the final product.

Ugh, another avenue for emotional blackmail...

nim-nim — Fri, 06 Jun 2025 15:00:00 +0000

> Counterpoint, if you are overly focused on the number of dependencies you are in denial about the fact that large dependencies have areas that bit-rot just as much and are just as unmaintained,

> And if you think you can just avoid using a dependency altogether and implement it yourself then you are in denial about the fact that the same is true about your own code.

That’s not the point. Delegation reduces accountability. Reduced accountability reduces quality. That’s true in all domains not just IT, that’s why tenders for big projects forbid subcontracting bellow a certain level (usually, after painful failures).

And you can fail with one level of subcontracting just like you can fail with a handful of dependencies, and you can succeed with 10 levels of subcontracting just like you can succeed with hundreds of dependencies. However on average, all other things being equal, and humans being human and prone to pass the shit-can, you’re almost certain to be in deep trouble if you abuse the delegation amount.