The Python Software Foundation on European cybersecurity

Posted Apr 25, 2023 22:16 UTC (Tue) by Wol (subscriber, #4433)
In reply to: The Python Software Foundation on European cybersecurity by farnz
Parent article: The Python Software Foundation on European cybersecurity

> This is a challenging one to draft well, since you don't want a loophole that lets a company avoid being the supplier of software if they include it in a bundle pack - for example, if I sell you a PC with pre-installed Ubuntu, and you use that PC with the pre-installed OS as part of a digital signage system, the intent of the CRA is that I am your supplier for Ubuntu, and it's up to me to manage that risk; but if the regulation is drafted badly, I could get away with only supplying (for CRA liability purposes) the PC and its firmware, but not Ubuntu).

Given the huge number of conglomerates where different parts of a business do different things (one just has to look at Sony's schizophrenia about whether they are a film company, a music company, or a games console company), you simply have to define it based on individual transactions.

If you "offer for sale" a product, and somebody buys it, then you are the supplier. If your bundle pack says it includes Ubuntu, then you are the supplier of Ubuntu. If the offer makes no mention of Ubuntu, and it just happens to be in the bundle as supplied (NOT as advertised), then you're not the supplier. But the customer may well get upset that the package is "not as advertised". Where this COULD get muddy is (as with my laptop) the situation where the supplier says "with or without Ubuntu" and it makes no difference to the price. I think there it is quite clearly a freebie thrown in, and the laptop supplier should not be considered the software supplier.

In other words, to be a supplier, imho you should have "offered for sale" the product, and taken some consideration in return for it. That clearly EXcludes "take it or leave it" freebies. And by basing the definition of "supplier" on the *product*, you avoid any argument as to whether someone is a supplier when there is a complex relationship between customer and supplier.

Cheers,
Wol

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 8:12 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (7 responses)

Nah, most of the manufacturers of “smart” devices do not want you to know what pile of software they run, they won’t mention or advertise it, but you definitely want them to be liable for the result. Also sometimes software is given or even forced on customers because the generous donator monetises something else (data, clicks, whatever) without any care for the security of users carpet bombed with badware.

Designing legal exemptions a lot of crooks won’t transform instanteanously into massive loopholes is hard.

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 9:44 UTC (Wed) by farnz (subscriber, #17727) [Link] (6 responses)

Worse than that, if you define it in terms of transactions, I can just sell you the licence library, and "give away" the rest of my software pile. So I'm liable for bugs in the licence system, but not for bugs in the rest of the software I offer, because the only thing I've actually sold is the licence system. The fact that the rest of the software is useless without the licence library is beside the point - it's not part of a transaction, you can download it freely.

Underlying this is that the per-transaction cost of distributing digital assets is near-zero; you might be asked to pay as much as $0.20 per gigabyte for data transfer if you choose an expensive option, but it's possible to drive that down below $0.01 per gigabyte if you're transferring enough data. For a size context, the Debian archive (all of Debian) is 125 GB for sources, plus 612 GB for the largest architecture, while a complete Android system image for a Google Pixel 7 Pro is under 3 GB.

Given this pricing, it's reasonable for someone distributing software to give most of it away "for free", without including it in a transaction; the goal of the CRA, however, is to ensure that software is covered by the same sorts of rules on quality and liability for faults as physical goods are. Which leads to tension, because software's a place where the low incremental cost of another unit means that it's easier to disguise a software transaction as a gift (and gifts have lower standards for quality in physical goods).

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 11:27 UTC (Wed) by Wol (subscriber, #4433) [Link] (5 responses)

> The fact that the rest of the software is useless without the licence library is beside the point - it's not part of a transaction, you can download it freely.

If you have to buy the licence library to use the software, then they're one "good". They're not "fit for purpose" without each other. Yes writing stuff that people can't try to find loopholes in is hard to impossible. But "Did you pay (cash, consideration, whatever) for the right/ability to use the software? Oh - you had to pay for the licence library, right? It's ONE transaction!" is hard to dodge.

Cheers,
Wol

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 11:49 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

That implies that everyone who sells software that runs on an OS has combined the OS and the software into a single good, and is on the hook not just for their software package, but also the whole OS. After all, you can't run the software without the OS, so you must buy the OS to use the software, which means it's one "good", not two, even though you buy the OS separately from another company.

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 12:14 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Did I say it's hard to impossible?

But they've presumably solved that with things like car radios, Ford aren't liable for aftermarket replacement radios. Even though those radios are clearly designed only to work in cars.

(In that case, it's two separate transactions, with consideration going in two directions. In the library example, it's the same supplier and you have to buy the licence to activate the software. One payment, one supplier.)

Cheers,
Wol

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 15:07 UTC (Wed) by farnz (subscriber, #17727) [Link]

The solution with aftermarket radios is standard interfaces, and an obligation to meet those interfaces whenever you sell a component - if a car uses a non-standard wiring setup, then it's on the car maker to document how you go from the non-standard version to the standard versions.

We could go for that solution with computing, where all APIs and ABIs must be standardised, and you must specify how to convert your internal stuff to the standard stuff, but that's got its own costs that we'd prefer not to pay; the only reason it works for in-car entertainment is that the interface was well-understood for a good 20 years before we insisted it be standardised, whereas if you look at ABIs from 20 years ago, we've changed all sorts of things.

And in the library example, it's also two suppliers - one payment to DodgySoft Limited to buy the core library that makes everything else work, with the software you need coming from DodgySoft Research for free. Two different sources, legally speaking, and DodgySoft Limited is only on the hook for the core library, not the bits you got from DodgySoft Research - even though the bits you want are from DodgySoft Research, and you're only buying the tiny core from DodgySoft Limited because without it, you can't use the bits from DodgySoft Research.

Fundamentally, we have two conflicting goals to reconcile:

Don't kill the Open Source goose - it should be possible to give away software for people to use for any purpose without incurring liability, since we've observed that good things happen when individuals can supply small drive-by improvements to code they care about.
Make the entire supply chain of any commercial product liable for the security flaws contained in the parts they supply. The goal here is that I'm only ultimately liable for my parts of the product, and my suppliers are responsible for the things I use.

The conflict is that we don't want to make people gifting code as Open Source liable, but we do want all commercial users of that code to have liability that they have to deal with somehow - whether through support contracts, insurance, or just being good at avoiding security issues. In turn, this means that we need to be careful to avoid loopholes that let you disguise commercial supply of code as an Open Source gift.

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 12:32 UTC (Wed) by geert (subscriber, #98403) [Link]

This reminds me of the excuses that were used before when bundling an OS (in particular MS Windows) with a PC: without an OS, the PC is non-functional, and "the EU forbids selling non-functional PCs".
And CD players could still be sold without CDs? And CDs without CD players...

The Python Software Foundation on European cybersecurity

Posted May 2, 2023 18:59 UTC (Tue) by immibis (subscriber, #105511) [Link]

One should note that law is to be interpreted by a judge, and a good law should not be written precisely to the smallest detail, but should give enough guidance that everyone knows what to expect, including judges, while also making it obvious and punishable when someone tries to exploit a loophole.

For example, the GDPR does not precisely define what is considered consent. If the GDPR had said that clicking on "I agree" constituted consent, website operators would require you to click on "I agree" before viewing the site. Since the introduction of the GDPR, it was ruled that a shortcut "I agree" button does not constitute consent unless there is an equally prominent shortcut "I disagree" button.