One thing with the EU Cyber Resilience Act is that manufacturers and Open Source projects are enforced to be more open about the cyber security of their platforms. Manufacturers are supposed to publish all CVEs in their products publicly - not only in their own code, but also in all dependencies (commercial and open source).
For many, publishing a CVE for a security issue is just part of the normal process. Reports come in from research, users or other parties and are processed, verified and published when proved correct. For others, it may feel hurtful, like a personal failure, so CVEs are not filed. In worst case, security issues are fixed without public comments. This way, users may not update their platforms and are exposed to cyber criminals.
We need to make sure that an open vulnerability handling process is a benefit for everyone and that we change the climate to make an open process in an open ecosystem a good thing. What do you think?
What would you tell the legislators in Europe who are devising the wave of new regulations related to the digital agenda? If you are attending #FOSDEM next week you can actually tell them directly in the EU Policy Devroom, which OSI is pleased to be co-organising. Full details at https://md.softwarefreedom.net/FOSDEM24
[swe] EU Cyber Resilience Act är på gång och vi har fått tillgång till den nya versionen efter förra årets förhandlingar mellan komissionen, parlamentet och rådet. På torsdag kör vi Dataföreningen ett gratis lunchseminarie där vi diskuterar CRA - senaste uppdateringarna, vad säger Open Source-grupperna och vad gäller för tillverkare av digitala produkter?
Auf dem #Brussels Cybersecurity Summit der belgischen Ratspräsidentschaft hat unsere Präsidentin Claudia Plattner über die europäische Cybersicherheitsstrategie gesprochen. 🇧🇪 🇪🇺
Ihre zentralen Botschaften:
💡 Wir müssen europäisch zusammenarbeiten!
💡 Wir müssen mit Blick auf den Cyber Resilience Act jetzt einen Markt für sichere Produkte schaffen!
„Globale Probleme können nicht allein auf nationaler Ebene gelöst werden. Gerade angesichts großer Gesetzesvorhaben wie #NIS2 und dem #CRA ist eine Bündelung der Kräfte notwendig“, so Claudia Plattner.
Buongiorno da Pornhub che a causa della age-verification law che costringe i cittadini di alcuni stati negli USA a caricare le proprie ID card, per protesta ha bloccato l'accesso a tutti. E poi vediamo anche cosa succede in Italia, con il Dipartimento per la Trasformazione Digitale pronto a lanciare IT Wallet.
In intro un ricordo e un omaggio al professor Nicklaus Wirth, inventore di Pascal e Oberon, che ci ha lasciati il primo gennaio.
I wholeheartedly recommend reading Bert’s summary if you want to know what’s up with #CRA and #FOSS, in particular if you previously read articles about unintended consequences for #opensource. Kept me busy this year. Signing off, have a good one 🎆
Even if you’re a developer with legal leanings like me, you probably haven’t given much thought to the warranty disclaimer and the liability disclaimer that appears in almost every Open Source licence (see sections 14 and 15 of GPLv3). This post is designed to help you understand what they are, why they’re there and why we might need stronger defences in future thanks to a changing legal landscape.
History: Why no Warranty or Liability
It seems obvious that when considered in terms of what downstream gets from Open Source that an open ended obligation on behalf of upstream to fix your problems isn’t one of them because it wouldn’t be sustainable. Effectively the no warranty clause is notice that since you’re getting the code for free it comes with absolutely no obligations on developers: if it breaks, you get to fix it. This is why no warranty clauses have been present since the history of Open Source (and Free Software: GPLv1 included this). There’s also a historical commercial reason for this as well. Before the explosion of Open Source business models in the last decade, the Free Software Foundation (FSF) considered paid support for otherwise unsupported no warranty Open Source software to be the standard business model for making money on Open Source. Based on this, Cygnus Support (later Cygnus Solutions – Earliest web archive capture 1997) was started in 1989 with a business model of providing paid support and bespoke development for the compiler and toolchain.
Before 2000 most public opinion (when it thought about Open Source at all) was happy with this, because Open Source was seen by and large as the uncommercialized offerings of random groups of hackers. Even the largest Open Source project, the Linux kernel, was seen as the scrappy volunteer upstart challenging both Microsoft and the proprietary UNIXs for control of the Data Centre. On the back of this, distributions (Red Hat, SUSE, etc.) arose to commericallize support offerings around Linux to further its competition with UNIX and Windows and push it to win the war for the Data Centre (and later the Cloud).
The Rise of The Foundations: Public Perception Changes
The heyday explosion of volunteer Open Source happened in the first decade of the new Millennium. But volunteer Open Source also became a victim of this success: the more it penetrated industry, the greater control of the end product industry wanted. And, whenever there’s a Business Need, something always arises to fulfill it: the Foundation Model for exerting influence in exchange for cash. The model is fairly simple: interested parties form a foundation (or more likely go to a Foundation forming entity like the Linux Foundation). They get seats on the governing board, usually in proportion to their annual expenditure on the foundation and the foundation sets up a notionally independent Technical Oversight Body staffed by developers which is still somewhat beholden to the board and its financial interests. The net result is rising commercial franchise in Open Source.
The point of the above isn’t to say whether this commercial influence is good or bad, it’s to say that the rise of the Foundations have changed the public perception of Open Source. No longer is Open Source seen as the home of scrappy volunteers battling for technological innovation against entrenched commercial interests, now Open Source is seen as one more development tool of the tech industry. This change in attitude is pretty profound because now when a problem is found in Open Source, the public has no real hesitation in assuming the tech industry in general should be responsible; the perception that the no warranty clause protects innocent individual developers is supplanted by the perception that it’s simply one more tool big tech deploys to evade liability for the problems it creates. Some Open Source developers have inadvertently supported this notion by publicly demanding to be paid for working on their projects, often in the name of sustainability. Again, none of this is necessarily wrong but it furthers the public perception that Open Source developers are participating in a commercial not a volunteer enterprise.
Liability via Fiduciary Duty: The Bitcoin Case
An ongoing case in the UK courts (BL-2021-000313) between Tulip Trading and various bitcoin developers centers around the disputed ownership of about US$4bn in bitcoin. Essentially Tulip contends that it lost access to the bitcoins due to a computer hack but says that the bitcoin developers have a fiduciary duty to it to alter the blockchain code to recover its lost bitcoins. The unusual feature of this case is that Tulip sued the developers of the bitcoin code not the operators of the bitcoin network. (it’s rather like the Bank losing your money and then you trying to sue the Mint for recovery). The reason for this is that all the operators (the miners) use the same code base for the same blockchain and thus could rightly claim that it’s technologically impossible for them to recover the lost bitcoin, because that would necessitate a change to the fundamental blockchain code which only the developers control. The suit was initially lost by Tulip on the grounds of the no liability disclaimer, but reinstated by the UK appeal court which showed considerable interest in the idea that developers could pick up fiduciary liability in some cases, even though the suit may eventually get dismissed on the grounds that Tulip can’t prove it ever owned the US$4bn in bitcoins in the first place.
Why does all this matter? Well, even if this case resolves successfully, thanks to the appeal court ruling, the door is still open to others with less shady claims that they’ve suffered an injury due to some coding issue that gives developers fiduciary liability to them. The no warranty disclaimer is already judged not to be sufficient to prevent this, so the cracks are starting to appear in it as a defence against all liability claims.
The EU Cyber Resilience Act: Legally Piercing No Warranty Clauses
The EU Cyber Resilience Act (CRA) at its heart provides a fiduciary duty of care on all “digital components” incorporated into products or software offered on the EU market to adhere to prescribed cybersecurity requirements and an obligation to provide duty of care for these requirements over the whole lifecycle of such products or software. Essentially this is developer liability, notwithstanding any no warranty clauses, writ large. To be fair, there is currently a carve out for “noncommercial” Open Source but, as I pointed out above, most Open Source today is commercial and wouldn’t actually benefit from this. I’m not proposing to give a detailed analysis (many people have already done this and your favourite search engine will turn up dozens without even trying) I just want to note that this is a legislative act designed to pierce the no warranty clauses Open Source has relied on for so long.
EU CRA Politics: Why is this Popular?
Politicians don’t set out to effectively override licensing terms and contract law unless there’s a significant popularity upside and, if you actually canvas the general public, there is: People are tired of endless cybersecurity breaches compromising their private information, or even their bank accounts, and want someone to be held responsible. Making corporations pay for breaches that damage individuals is enormously popular (and not just in the EU). After all big Tech profits enormously from this, so big Tech should pay for the clean up when things go wrong.
Unfortunately, self serving arguments that this will place undue burdens on Foundations funded by starving corporations rather undermine the same arguments on behalf of individual developers. To the public at large such arguments merely serve to reinforce the idea that big Tech has been getting away with too much for too long. Trying to separate individual developer Open Source from corporate Open Source is too subtle a concept to introduce now, particularly when we, and the general public, have bought into the idea that they’re the same thing for so long.
So what should we do about this?
It’s clear that even if a massive (and expensive) lobbying effort succeeds in blunting the effect of the CRA on Open Source this time around, there will always be a next time because of the public desire for accountability for and their safety guarantees in cybersecurity practices. It is also clear that individual developer Open Source has to make common cause with commercial Open Source to solve this issue. Even though individuals hate being seen as synonymous with corporations, one of the true distinctions between Open Source and Free Software has always been the ability to make common cause over smaller goals rather than bigger philosophies and aspirations; so this is definitely a goal we can make a common cause over. This common cause means the eventual solution must apply to individual and commercial Open Source equally. And, since we’ve already lost the perception war, it will have to be something more legally based.
Indemnification: the Legal solution to Developer Liability
Indemnification means one party, in particular circumstances, agreeing to be on the hook for the legal responsibilities of another party. This is actually a well known way not of avoiding liability but transferring it to where it belongs. As such, it’s easily sellable in the court of public opinion: we’re not looking to avoid liability, merely trying to make sure it lands on those who are making all the money from the code.
The best mechanism for transmitting this is obviously the Licence and, ironically, a licence already exists with developer indemnity clauses: Apache-2 (clause 9). Unfortunately, the Apache-2 clause only attaches to an entity offering support for a fee, which doesn’t quite cover the intention of the CRA, which is for anyone offering a product in the EU market (whether free or for sale) should be responsible for its cybersecurity lifecycle, whether they offer support or not. However, it does provide a roadmap for what such a clause would look like:
If you choose to offer this work in whole or part as a component or product in a jurisdiction requiring lifecycle duty of care you agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your actions in such a jurisdiction.
Probably the wording would need some tweaking by an actual lawyer, but you get the idea.
Applying Indemnity to existing Licences
Obviously for a new project, the above clause can simply be added to the licence but for any existing project, since the clause is compatible with the standard no-warranty statements, it can be added after the fact without interfering with the existing operation of the licence or needing buy in from current copyright holders (there is an argument that this would represent an additional restriction within the meaning of GPL, but I addressed that here). This makes it very easy to add by anyone offering, for instance, a download over Github or Gitlab that could be incorporated by someone into a product in the EU.
Conclusion
Thanks to public perception, the issue of developer liability isn’t going to go away and lobbying will not forestall the issue forever, so a robust indemnity defence needs to be incorporated into Open Source licences so that Liability is seen to be accepted where it can best be served (by the people or corporation utilizing the code).
This doesn't mean we won't have a major step in security requirements coming from users and devs, raising their expectations.
In #QGIS project, we already see a lot more messages to forward vulnerabilities.
I am still unsure if open source with open core model will be concerned though.
I've updated my blog post on the worries about open source and the EU Cyber Resilience Act to reflect that the agreed upon #CRA text appears to be a lot better for open source and free software. But we still await the final details, when I get those I'll do another writeup.
#EU#CyberSecurity#CRA#CyberResillience#IoT: "The EU co-legislators are set to reach a political agreement on the Cyber Resilience Act, with the main major hurdle left to solve around the power of national authorities to restrict access to reported vulnerabilities.
The Cyber Resilience Act is a legislative proposal to introduce security requirements for the manufacturers of connected devices. The file is at the final stage of the legislative process with the EU Commission, Parliament and Council hashing out the final dispositions in so-called trilogues.
The main EU institutions are set to formalise an agreement at a political trilogue on Thursday (30 November), but most aspects of the file have already been settled at the technical level, according to an internal document dated 24 November and seen by Euractiv.
At the same time, the thorny aspect of vulnerability and incident reporting remains the main open political question."
EU Commission pitches double reporting of open security loopholes in cybersecurity law #CRA
// “The manufacturers shall notify any actively exploited vulnerability contained in the product with digital elements that they become aware of to [the CSIRTs designated as coordinators pursuant to Article 12(1) of Directive (EU) 2022/2555 and ENISA],” reads the text.
Various versions of the new EU Cyber Resilience Act (#CRA) contain difficult attempts to partially/perhaps/sometimes regulate open source and open source foundations. In this reasonably brief article I argue for a different solution: https://berthub.eu/articles/posts/eu-cra-best-open-source-security/
"#OSGeo is committed to supporting the projects in our care and we look forward to working with our community to meet this challenge.
OSGeo will participate in the upcoming EU #OpenSource Policy Summit 2024, asking @IvanSanchez to attend on our behalf.