Hírolvasó

Számos kritikus folyamat csak biometrikus azonosítással indítható majd, lesz olyan, ami csak időkorláttal.

Komoly engedménnyel venné elejét az Apple annak, hogy az uniós szabályozók gigantikus bírsággal büntessék.

Befutottak az idei első és második negyedévre vonatkozó mobilpiaci statisztikák.

The work described in Theo de Raadt's post (see our previous article) continues:

• pinsyscalls(2) has been committed.
• syscall(2) has been removed from -current:

  Read more…

Konstantin Ryabitsev has announced that the movement of kernel mailing lists away from the venerable vger.kernel.org system is nearly complete:

Over the past few months we've migrated all of the vger.kernel.org mailing lists, with the exception of the Big One (linux-kernel, aka LKML). This list alone is responsible for about 80% of all vger mailing list traffic, so we left it for the last.

This Thursday, December 14, at 11AM Pacific (19:00 UTC), we will switch the MX record for vger to point to the new location (subspace.kernel.org), which will complete the mailing list migration from the legacy vger server to the new infrastructure.

The story of Canonical's takeover of the LXD container manager, and the subsequent creation of the Incus fork, has been simmering for a while. Now Incus developer Stéphane Graber reports that Canonical has changed the license and contribution terms for LXD:

Per the commit message performing the re-licensing, all further contributions will be under the AGPLv3 license and all contributions from Canonical employees have been re-licensed to AGPLv3.

However, Canonical does not own the copyright on any contribution from non-employees, such as the many changes they have imported from Incus over the past few months. Those therefore remain under the Apache2 license that they were contributed under.

As a result, Canonical cannot release LXD under the AGPLv3 license and likely never will be able to. LXD is now under a weird mix of Apache2 and AGPLv3 with no clear metadata indicating what file or what part of each file is under one license or the other.

He also notes that this change will put an end to the flow of patches — in either direction — between the two projects.

So-called "immutable" Linux distributions have been in development for some time, but (unless you count Chrome OS) haven't gained much traction. Project Bluefin, is a heavily customized set of Fedora Silverblue images coming from the Universal Blue community; they are designed to deliver a reliable Linux desktop that's as easy to use as a Chromebook but more customizable. Bluefin's mission is to change up the desktop experience and attract a new generation of open-source contributors with a "cloud-native" take on developing and delivering the operating system.

Security updates have been issued by Debian (libreoffice and webkit2gtk), Fedora (java-1.8.0-openjdk and seamonkey), Oracle (apr, edk2, kernel, and squid:4), Red Hat (postgresql:12, tracker-miners, and webkit2gtk3), SUSE (curl, go1.20, go1.21, hplip, openvswitch, opera, squid, and xerces-c), and Ubuntu (binutils, ghostscript, libreoffice, linux, linux-aws, linux-aws-5.15, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gke, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-kvm, linux-nvidia, linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4, linux-bluefield, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-kvm, linux-xilinx-zynqmp, postfixadmin, python3.11, and webkit2gtk).

Ez brutál gyors.

A végponti titkosítással együtt élesedett az üzenetek szerkesztésének lehetősége.

A kínaiak 5G-s mobilhálózati berendezéseket gyártanának Európában 2025-től.

A bíróság szerint a monopol helyzetben lévő keresőóriás versenyellenes gyakorlatokkal él.

A Facebook eközben egyre kevésbé népszerű a körükben, az Instagram stagnál.

James Bottomley writes that open-source developers are increasingly likely to be held liable for flaws in their code and suggests a solution:

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 Rust project makes incremental releases every six weeks, a fact that makes it easy to overlook some of the interesting changes coming to the language, such as new ABIs, better debugger support, asynchronous traits, and support for C strings. The end of the year provides an opportunity to look back over the past several months of updates, and to look forward to what to expect in 2024.

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

The 6.7-rc5 kernel prepatch is out for testing.

Nothing looks particularly scary, which is good, because if it had been, I wouldn't have had the capacity to deal with it last week.

Let's hope it stays that way even as I am getting better. Because the holidays are almost upon us, and I'm woefully underprepared.

Greg Kroah-Hartman has announced the release of the 6.6.6 and 6.1.67 stable kernels. Both contain a single reversion of the "wifi: cfg80211: fix CQM for non-range use" patch.

Security updates have been issued by Debian (chromium), Fedora (bluez, chromium, and curl), Red Hat (apr), Slackware (libxml2), and Ubuntu (squid3 and tar).