zlacker

The CRA is not about liability or consumer compensation. The remedies for non-compliance are fines or removal of a product from the EU market. The forthcoming update of the Product Liability Directive, which will probably take a similar approach (exempting open source unless it is placed on the market, so as the article describes, developers of products that are placed on the market are responsible for the security of their products, including open source incorporated in said product) on the other hand is.

I only skimmed the OP and doubt it's intentionally confusing, but it is confusing because its prediction of doom is wacky. Manufacturers (eg developers of IoT devices, the insecurity of a major impetus for the legislation, apps, etc) will need to adopt modern development practices such as updating their dependencies when a vulnerability is known -- and that includes manufacturers that wrap a mostly open source codebase in a final product or monetise an open source codebase in various ways called out in the legislation.

Yes if a consumer is harmed by a completely open source thing not placed on the market, say something in Debian, they will not be able to sue the developers, and the developers aren't subject to fines etc under the CRA. That's the balance intended by the legislation (after lots of attempts to get it right), to not wreck incentives to develop open source, but to make product developers more responsible. In other words, the public policy is not exactly as you state it. :)

>>mlinks+(OP)
as i understand it, the problem with some of the previous drafts of the produt liability directive was that by making a commercial product open-source, you could become liable for how random people who weren't paying you used it

consider ghostscript, for example, which is open-source and a commercial product from artifex. the license terms are such that you generally only have to pay for it if you're embedding it in a printer, which many manufacturers do. but virtually every gnu/linux box has it installed without needing to pay for a license. suppose a security vulnerability in ghostscript (of which there have been a number) allows an attacker to own a million ubuntu machines and inject ransomware into thousands of companies in the eu who have no relationship with either the ubuntu company or with artifex

as i understand it, previous drafts of the product liability directive would have made artifex liable for damages in this situation, creating a strong incentive against making any commercial software open-source. do we know this cra avoids making artifex liable for fines? it seems that liability for fines would create the same kinds of incentives

has this been fixed?

as you likely know, i think a necessary and nearly sufficient step to solving the iot security problems is requiring the firmware to be open-source so that consumers can update it whether the manufacturer wants to or not

>>kragen+9d
Wish I could say for certain, but we'd need the final texts of the CRA and PLD, and EU lawyers, to say for sure. This is the sort of situation that the general aim of the EU policymakers seems to be to avoid what they'd see as loopholes, where a business is avoiding responsibility simply by making a product open source, and avoiding destroying open source. It's plausible, perhaps likely, that open source ghostscript would be exempt, but the one there's a transaction for (clearly being placed on the market -- that, rather than "commercial product" is the key concept) would surely not be. The same vulnerability might impact both, but the developer may only be responsible for the latter. It's possible under the CRA artifex could be considered (very late addition) the steward of the open source version, which was intended largely to cover (give some responsibility to) foundations, but without any real penalties -- but, we'll see.

I'm not surprised that's what you think. I'm doubtful anywhere close to sufficient, as much as I'd like that to be true. The focus of the CRA is of course to make the manufacturer be responsible, including for providing security updates for as long as the product is expected to be used (5 years or more typically). There probably is a weak recital suggesting manufacturers might make source code available to other undertakings so that they might provide security updates after the original manufactuerer's support period, but no enforcement of this, and explicitly not requiring open source. Seems like a potential area for future regulation to improve upon.

>>mlinks+0y
thank you very much!