The Python Software Foundation on European cybersecurity

Posted Apr 25, 2023 10:27 UTC (Tue) by jafd (subscriber, #129642)
Parent article: The Python Software Foundation on European cybersecurity

I can see that the comments are brimming with experts who say there is nothing to worry about, and how it's all simple, really.

I would like to have some simple answers then, using very few small words, to the following questions. I don't know the right answers, but I sure as hell know they don't start with "it depends".

1) I publish an open source thing with no expectation of profit whatsoever. A vendor picks it up without my knowledge or consent, puts it into smart fridges or whatnot, and later a hole is found in my thing. Who is going to be liable, the vendor or I? Can CRA hang it onto me as a "supplier"?

2) I publish an open source thing, and take donations. A vendor picks it up without my knowledge or consent, puts it into smart fridges, and later a hole is found in my thing. The donations, it's expressly stated, are there to support the development, but they don't imply any sort of contract with obligations. I don't know if the vendor has ever donated anything to me. Who is going to be liable? Can vendor successfully make me liable?

3) I run a software business. I publish parts or the entirety of what I produce as open source, free for anyone to use, but offer custom component development and support subject to a contract and hefty subscription fees. A business X picks up my software and uses it without my knowledge or consent. I don't have any kind of support contract with X. Later, X falls victim to a hole found to be in my software. Can they make me their "supplier" per CRA and successfully sue me/make me pay fines despite me not having received a single cent from them and being unaware of their existence until now?

For simplicity's sake, assume all parties are EU-based and thus squarely in CRA jurisdiction, with no buts or whatifs.

The Python Software Foundation on European cybersecurity

Posted Apr 25, 2023 16:57 UTC (Tue) by farnz (subscriber, #17727) [Link] (14 responses)

Not a lawyer, so you'll need legal advice if this really matters to you (just as you would with any law), but my understanding is as follows, based on the text of the directive:

No, you are not a supplier if you simply publish your thing as open-source, and a vendor picks it up; to become a supplier, you need a commercial relationship with the vendor, and you have nothing that can be construed as commercial.
Again, not a supplier - you aren't supplying anything in return for what the vendor gives you, and thus, while the donation relationship may be commercial, you're not supplying anything, and thus you're OK.
In this situation as described, you're not a supplier - you have no commercial relationship with X, and hence you're not a supplier.

It's case (3) that has the big gotchas lurking in the current draft; if you supply premium cakes for office parties as well as supporting your open source software, then as the CRA is currently drafted, it's not clear whether being a supplier of cake to X implies that you are liable to X if your software has a hole in it. Hence the PSF and ISC worries; they supply conferences (PSF) and support contracts (ISC), and do not want a situation where, because you bought a conference ticket or support for one product, they're on the hook to you for all the software they make available.

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).

The Python Software Foundation on European cybersecurity

Posted Apr 25, 2023 18:03 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> [...] and do not want a situation where, because you bought a conference ticket or support for one product, they're on the hook to you for all the software they make available.

Worse yet, once you're considered a "manufacturer" (via the conference/support contract/etc "commercial activity" backdoor) if your digital elements are "made available" in the EU (eg via a public web site) then you're now potentially on the hook to *everyone* who obtains those digital elements, not just the folks who actually paid you money.

The Python Software Foundation on European cybersecurity

Posted Apr 25, 2023 19:41 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

That, at least, is not supported by the current text - to be on the hook to someone, you have to be their supplier of the digital elements.

The only sense in which you're on the hook to "everyone" is that the CRA allows you to pass liability backwards along supply chains; if I supply you with a product including a paid copy of Red Hat Enterprise Linux, and you're affected by an RHEL flaw, then you can follow the supply chain backwards and pursue Red Hat, instead of pursing me, and if you do pursue me, I can pursue Red Hat.

But, without the supply chain to follow backwards, I can't pass liability to you, even if you are a "manufacturer". You have to be my supplier (either directly, or transitively) before I can pursue you. So, if you fall through the "commercial activity" loophole and become someone's supplier, you're not at risk from me unless they are my supplier (or my supplier's supplier ad-infinitum) of those digital elements.

This is still a huge problem for something foundational like Python, since there's a very high chance that any given use of Python in an end-product involves someone in the supply chain who's supplied by the PSF in this sense, but it's not as bad as you're suggesting. In particular, if you become my supplier, but I don't supply anyone else, your liability risk stops there.

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 12:29 UTC (Wed) by ballombe (subscriber, #9523) [Link] (2 responses)

... and RedHat could premptively declare RHEL unsuitable for the purpose you intend, so as not to be your supplier.

The Python Software Foundation on European cybersecurity

Posted Apr 26, 2023 12:38 UTC (Wed) by pizza (subscriber, #46) [Link]

> ... and RedHat could premptively declare RHEL unsuitable for the purpose you intend, so as not to be your supplier.

Wait, isn't that just another case of DISCLAIMING ALL WARRANTIES? I thought that's one of the things the CRA is supposed to be precluding?

(Or will "general purpose computing" become effectively illegal under this new regime?)

The Python Software Foundation on European cybersecurity

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

Red Hat can't do that, under the CRA - they have to refuse to supply me RHEL under commercial terms in order to not be my supplier.

Which leads to fun if we start thinking about Ubuntu, which is available from Canonical as both Open Source, and a commercial supported product; if I have Ubuntu, which variant do I have? Is Canonical my supplier (because I obtained Ubuntu from them under commercial terms), or not (because I picked it up as an Open Source gift)? Can I convert Canonical into a supplier when I realise I fouled up taking Ubuntu as Open Source? Can Canonical avoid supplying me somehow, while still getting revenue from me?

The Python Software Foundation on European cybersecurity

Posted Apr 25, 2023 22:16 UTC (Tue) by Wol (subscriber, #4433) [Link] (8 responses)

> 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.