Fifteen Months Behind the Manufacturer
Between 2005 and 2007 I sold Novell's Enterprise Linux to organisations across New Zealand and Australia, including Public Trust New Zealand, Centrelink Australia and Telstra Australia. What I was actually selling was rarely the software itself. The code underneath was already free, already community-maintained, already something those clients could have downloaded without paying Novell a cent. What they paid for was Novell standing behind it: a number to call, a patch commitment, someone who would take responsibility if a piece of that stack broke at three in the morning. Underneath that contract sat a kernel, a compiler and a dozen libraries that no Novell employee had written and that Novell did not own in any sense a lawyer would recognise. I never had a clean name for the line between the company taking that responsibility and the community that had actually written the code beneath it, and neither, as far as I know, did anyone drafting a support contract in that era. Twenty years later, a regulator has finally drawn it, in binding law, and put a date on each side.
On 11 September 2026, the European Union's Cyber Resilience Act switched on a reporting clock for manufacturers of any product with digital elements sold into the EU market, which in practice means almost anything with a chip and a network connection. The European Union Agency for Cybersecurity, ENISA, brought its Single Reporting Platform online the same day to receive the notifications: 24 hours to flag an actively exploited vulnerability, 72 hours for a fuller notification with an initial assessment, and 14 days for a final report once a fix exists.[1] It is a single portal that routes each notification to the relevant national incident-response team, which then shares it with counterparts across the bloc.[2] A manufacturer that misses that clock is not managing a paperwork inconvenience. The reporting duty is the leading edge of an enforcement regime, and it is the part of the Act that started first.
Open-source software stewards do not join that clock until 11 December 2027. That gap is the fifteen months in this article's title, and it exists because the Regulation, for the first time in binding statute anywhere, gives that word a legal meaning. A steward, in the Act's own construction, is a foundation, non-profit or company that keeps a widely used piece of free or open-source software alive on a sustained basis without selling it commercially.[3] From December 2027 a steward's duties are lighter than a manufacturer's: document a cybersecurity policy that promotes secure development and vulnerability handling, cooperate with market surveillance authorities, and report only where the steward is actually involved in developing the product in question.[2][3][5] A foundation that maintains a widely used compression library, for instance, and has no visibility into which commercial products downstream have bundled it, would not be expected to chase every one of them down; a foundation that packages, distributes and actively supports that same library inside a named product would sit closer to the manufacturer's own position. On this reading, the line moves with the actual relationship, not with the maintainer's non-profit status alone.
This series has been circling a version of this question since its earliest episodes: who is accountable for code that everybody uses and nobody, in the ordinary commercial sense, owns. Earlier episodes have watched that question get answered by a market transaction, by a consortium's governance structure, by a licence's own text. This is the first time it has been answered by a government, in a statute with a fine attached, and the government's answer runs directly through the series' own long-standing argument rather than around it.
Fifteen months describes a reporting deadline, not a holiday from the rest of the law. On the same date stewards start reporting, manufacturers face their own next deadline: the Act's main cybersecurity requirements, secure-by-design obligations and the rest of its core substance, come into force for them too.[3] The steward deferral is specific to the reporting duty. It is not a general pass, and reading it as one misstates what the Regulation actually does.
I did a version of this attestation work myself, later, in a different register. Between 2002 and 2019 I led NZISM and NIST control attestation engagements at MBIE, Air New Zealand, ACC, IRD and DIA: named parties putting their signature to evidence that a system met a defined security posture, on a schedule. Every one of those engagements assumed a boundary around what the vendor was answerable for and what sat upstream, in code nobody in the room had written. Drawing that boundary was always a negotiation rather than a formula. A client wanted to know, in plain terms, where their own accountability stopped and a supplier's began, and the honest answer usually involved a paragraph of qualification rather than a clean line. The Cyber Resilience Act has now drawn a version of that same boundary into law, for a much larger population of vendors than I ever attested for, and it has done what none of those engagements could: put a specific date on each side of it, rather than a paragraph of qualification.
The maintenance pipeline a steward's future duty will attach to is already running at a volume worth naming. On 14 September 2026, seven stable Linux kernels, 7.2.6, 6.18.52, 6.12.110, 6.6.157, 6.1.188, 5.15.221 and 5.10.270, were released together, carrying more than 9,000 backported patches between them, more than 1,800 in 7.2.6 alone. Greg Kroah-Hartman, who maintains the stable tree, said the batch may set a record.[4] The oldest branch in that release, 5.10, reaches the end of its supported life this December, which means seven parallel lines of the same kernel were still being kept current, on the same day, by a maintenance community that carries none of the reporting duty a manufacturer now carries for shipping any one of them. Nobody organised that number to make a point about the Cyber Resilience Act. It is simply what the bazaar's ordinary maintenance load looks like the same month a government tried to put a line around who is responsible for it.
Twenty-eight years ago, Eric Raymond gave this series its organising image: a cathedral's controlled hierarchy against a bazaar's plural, argumentative review. He was describing a development practice, one visible in exactly the kind of parallel, overlapping patch queues that produced that 14 September release. Brussels has just done something Raymond never attempted, which is to describe the same distinction as a matter of enforceable law: who reports what, on what clock, and who does not. The bazaar did not change. What changed is that an institution with the power to fine a manufacturer wrote down, on paper, where the bazaar's edge actually sits, and conceded, without saying so in those words, that a foundation keeping a library alive on donated time is not the same kind of thing as a company selling a support contract on top of it.
No government has yet done the equivalent for a model's weights, so far as the public record shows. Neither the United States nor the United Kingdom has, at the time of writing, created a comparable reduced-duty category in their own product-cybersecurity regimes, which is worth stating plainly as a gap in what has been checked rather than as proof that no such category exists anywhere. When a frontier AI lab publishes a model under an open licence and a different company fine-tunes and ships it inside a commercial product, nobody has had to answer, in law, whether the lab, the fine-tuner, both or neither carries a manufacturer's reporting duty. A compiled kernel is at least a fixed artefact: two people reading the same source line reach the same conclusion about what it does. A model's weights are not fixed in that way, and the same weights can behave differently depending on how they are prompted, which is exactly the property that will make drawing this line harder than it was for Brussels. The Cyber Resilience Act shows that a government can write the manufacturer/steward boundary down for compiled code that people can point to, read and fork. Whether any regulator manages the harder version of the same question is the next chapter this series will be watching for, not one it can report today.
The open-source dimension of this story is not confined to the Regulation's own text. Germany's Sovereign Tech Agency already puts public money directly into the hands of maintainers who keep widely used but commercially invisible libraries running, without first asking them to become a company or a manufacturer of anything.[6] It funds the maintenance, not the product built on top of it, which is the same distinction the Cyber Resilience Act now regulates rather than funds. The Cyber Resilience Act approaches the same reality from the other direction, as a regulator rather than a funder, but the recognition underneath is the same: keeping code alive and selling a product built on it are different undertakings, and treating them identically protects neither one. That recognition travels wherever a government depends on software it did not commission and cannot simply order into existence.
It travels furthest in defence procurement, where the manufacturer/steward split has operated informally for years without anyone writing it down. Boeing and Lockheed Martin ship classified and mission systems built on Linux and BSD-derived components neither company wrote, and it is the prime contractor, not the kernel community upstream, that a defence ministry holds to account when something in that stack fails. Allied procurement standards have assumed that split in practice for as long as those systems have existed, through contract terms rather than statute. What the Cyber Resilience Act changes is precedent, not practice: a regulator has now shown the manufacturer/steward line can be drawn in enforceable law instead of a contract's fine print, which matters anywhere a state depends on code it neither commissioned nor can fine into existence. The open question is not whether that dependency exists. It is who ends up named as accountable for it.
I spent two years at Novell selling manufacturer-grade support on top of code the Linux Foundation, not Novell, was the actual caretaker of. The law now draws almost exactly that line. Was there ever a moment with a client, at Public Trust, Centrelink or Telstra, when you had to tell them plainly which part of what they had bought you could stand behind, and which part you could not? What did that conversation sound like?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by morethan 30 years of professional experience in architecture, security, andtechnology leadership in New Zealand. I write as director of Te PonoLimited; the views are personal and do not represent the position of anyclient, any government agency, or the New Zealand government. My commentaryon legislation and policy is analytical, drawing on publicly availablesources and my professional expertise in architecture, security, and AIgovernance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at andreas@thehambergerreport.com. A Concise History of Linux chronicles the operating system that changed the world, and the lessons it holds for the AI era.
This article was produced with AI assistance under my direction. Research,drafting and images pass through a pipeline I built and govern: automatedgates for source verification, forbidden language and political neutrality,and my own review before anything is published. The tools include Claude,Gemini and Openart. The frameworks, arguments and editorial judgements aremine and are the same discipline I apply to the AI systems I audit forclients. AI accelerated the work; the thinking, and the responsibility forit, are mine.
[1] ENISA. "The CRA Single Reporting Platform Is Launched." 11 September 2026. https://www.enisa.europa.eu/news/the-cra-single-reporting-platform-is-launched
[2] European Commission. "Cyber Resilience Act - Reporting Obligations." Shaping Europe's Digital Future. 2026. https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
[3] Goodwin Law. "Preparing for the EU Cyber Resilience Act: Key Reporting Obligations From 11 September 2026." September 2026. https://www.goodwinlaw.com/en/insights/publications/2026/09/alerts-lifesciences-technology-preparing-for-eu-cyber-resilience-act
[4] LWN.net. "More Than 9,000 Patches Total in the Seven Stable Kernels for Monday." 14 September 2026. https://lwn.net/Articles/1093985/
[5] Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 24(3), full text mirror. Accessed 2026. https://www.cyberresilienceact.eu/regulation.html
[6] Sovereign Tech Agency. "Sovereign Tech Fund." 2026. https://www.sovereign.tech/programs/fund