The Foundation Nobody Owns
On the morning of 19 February 1998, the Auckland central business district lost power, and with it the country lost its internet. I had arrived in New Zealand at the end of 1996 and joined ICONZ, the nation's first commercial internet service provider. ICONZ ran Linux in production, and it carried much of New Zealand's government email and a large share of the country's internet traffic. When the grid failed, every other provider went dark and stayed dark. A colleague of mine got into his car and drove north to Whangārei to borrow a generator. For the better part of that day, ICONZ was the only working internet service provider in New Zealand.
Why us? Because we had built from source. We understood every layer of the machine, from the kernel upward, so when a layer broke we could reach in and fix it ourselves. There was no vendor to call, and we did not need one. That is the moat, and it is the reason I can write this series. No governance consultant can tell you they ran this substrate in production before the industry decided it mattered. I can.
So let me put a single claim to you, and I want you to hold it as a governance fact rather than a piece of history. Every artificial intelligence system you govern runs on a foundation no company owns.
Not "mostly". Not "much of it". The foundation. The operating systems under the training clusters, the network stacks moving the tensors, the compilers, the container runtimes, the language toolchains: the layer beneath your models is open-source software that no single firm holds title to. Your board can name the model vendor. It can name the cloud provider. It probably cannot name a single owner of the code that everything else stands on, because there is not one.
Look at what a single AI deployment actually rests on. The model runs inside a container, and the container runtime is open source. The container sits on Linux, which is open source. The traffic to and from it is encrypted by open-source libraries. The numbers are moved by open-source drivers and schedulers, compiled by open-source toolchains, and orchestrated by open-source frameworks. Peel the layers and almost every one of them is code that some community, rather than some supplier, is responsible for. The proprietary model at the top is the thin, visible tip of a very deep and very public stack.
Directors are used to a world of counterparties. Every serious dependency has a contract, a service level, and someone to escalate to at three in the morning. The substrate under your AI has none of that. To understand why, you have to go back to a time before anyone thought software could be sold at all.
Go back to 1955 and 1956
Two events, one year apart, set the pattern that still holds. Neither was an act of idealism. One was a meeting of engineers who were tired of doing the same work twice. The other was an antitrust settlement signed in a courtroom.
On 22 August 1955, seventeen representatives from the organisations that had ordered IBM's new 704 mainframe met at the RAND Corporation in Santa Monica, California. Frank Wagner from North American Aviation, Paul Armer from RAND, and Morton Bernstein stepped away from the room, crowded into a phone booth, and called colleagues across the country. By the end of the day they had the outline of an organisation. They called it SHARE, as a plain description of what they meant to do, not as an acronym. Within months, twenty-two installations had joined.
The problem SHARE solved sounds quaint until you see the shape of it. Every installation was independently writing the same utility routines: the same code to read a tape, print a line, sort a file. Members began exchanging programs by post, on punched cards and magnetic tape. In 1955, the idea that software might be a product sold separately from the hardware had not occurred to anyone. Software was something you wrote, and something you swapped, because writing it twice was a waste. The commons came first. The market came later.
[BOOK IMAGE: row 3 - IBM 704 at RAND 1955]
That habit of exchange was not a movement. It had no manifesto and no name for itself. It was simply how computing worked for its first decade and a half: universities, research laboratories, and corporate computing departments passing source code back and forth because the alternative was absurd. There was no ideology in it, only arithmetic. A routine written once and shared cost a fraction of the same routine written seventeen times over by seventeen teams who would never meet.
[BOOK IMAGE: row 4 - The early computing commons]
Then came the courtroom
In January 1956, AT&T and IBM each signed consent decrees with the United States Department of Justice. The AT&T decree settled an antitrust suit the government had opened in 1949. It confined AT&T to common carrier communications, it barred the company from the computer business, and it required AT&T to license its patents at reasonable royalties. IBM's decree carried its own licensing obligation, which helped keep competitors such as Control Data Corporation alive in the mainframe market.
Read that again with a governance eye. The state did not ask these firms to share. It compelled them. Intel's co-founder Gordon Moore would later call the 1956 decree one of the most important developments for the commercial semiconductor industry, because the patents it forced open seeded a whole field. Independent economic research on the decree reaches the same verdict: the compulsory licensing measurably increased the innovation that built on Bell Laboratories patents. The openness that followed was not generosity. It was the by-product of antitrust enforcement.
[BOOK IMAGE: row 6 - CDC 6500 and the consent decrees]
The part that shapes your AI
The decree's deepest mark landed thirteen years later, and it is the part of this story that matters most for anyone governing AI today.
Over the summer of 1969, while his wife and infant son were away, a Bell Labs researcher named Ken Thompson sat down at a little-used PDP-7, a minicomputer with only 8,192 eighteen-bit words of memory, and wrote the first version of what became Unix: a kernel, a shell, an editor, and an assembler, each built in roughly a week. Unix is the direct ancestor of Linux, of macOS, of Android, and of the operating systems running inside almost every AI training cluster on earth. It started on a cast-off machine as one man's summer project.
Here is where the 1956 decree reaches forward into the present. When Unix existed, AT&T's lawyers looked at the consent decree and concluded the company could not commercially exploit it. AT&T was a telephone company, forbidden from the computer business. So Unix went out under the only terms the decree allowed: distribution for educational purposes, with no support, no bug fixes, and no profit. AT&T charged only for the cost of the physical media plus a nominal fee.
Sit with the consequence. Because AT&T could not commercialise Unix, it could not control Unix. There was no corporate help desk, so users had to help each other. The code went to universities with the source open, because there was no business reason to close it. A generation of computer scientists learned the system by reading and modifying the actual source, then carried what they had learned into every corner of the industry. The gift economy of open source was not built by activists. It was built by a company legally prohibited from doing anything else.
[BOOK IMAGE: row 5 - Thompson at the PDP-7]
From a handful of early recipients, Unix moved outward, institution to institution, each site fixing what it needed and passing the fixes along. The system spread precisely because no one held the right to stop it.
[BOOK IMAGE: row 7 - Unix spreads institution to institution]
What the pattern actually is
Step back and the shape is clear. A meeting of engineers in 1955 who would not write the same routine twice. A courtroom in 1956 that forced two monopolies to license what they held. A researcher in 1969 handed a spare machine and a legal vacuum, producing a system no one was allowed to own. Openness here was never an ideology. It was the by-product of practical necessity and antitrust enforcement, and the foundation of modern computing was poured in that mould.
A wall did eventually go up. Over the years that followed, software crossed from shared infrastructure into a priced product, the commodity we buy and licence today. But that crossing happened on top of a foundation already laid open. The commodity layer is newer than the commons beneath it, and it rests on it.
[BOOK IMAGE: row 8 - From commons to commodity timeline]
Back to the machine in your organisation
This brings us to a problem most boards have never named.
The substrate beneath your AI is a commons created by antitrust, not a contract you can enforce against anyone. There is no vendor accountable for the foundation. There is no line in a supplier agreement that covers it. When a widely used open-source component fails, and such components do fail, there is no counterparty to hold to account, no service level to invoke, no one on the other end of the phone. At the deepest layer of your stack, you are depending on work that a monopoly was once compelled to give away, and that volunteers and institutions have maintained ever since, often invisibly and often unpaid.
That is not a reason to panic. It is a reason to look. The first act of governance is not control; it is location. You cannot govern what you have not located. Most boards can produce a register of their commercial software vendors within the hour. Ask the same board what open-source components sit under its AI systems, who maintains them, whether those maintainers are funded, and how a critical fix would actually reach production, and the room goes quiet. The quiet is the finding.
So make the quiet productive. Locating the foundation is not a research project; it is a governance instruction with an owner and a due date. Ask your architecture function for one artefact: a list of the open-source components sitting beneath each AI system the organisation depends on, from the model-serving layer down to the operating system and the cryptographic libraries. For each significant component, answer four questions. Who maintains it? Are those maintainers funded, or are they volunteers doing this in evenings and weekends? When a security fix is published, what is the path by which it reaches your production systems, and how long does that path take? And if that component stopped being maintained tomorrow, what would you actually do? None of this requires a licence negotiation or a vendor meeting. It requires someone to look and to write down what they find. More often than boards expect, the honest answer to the funding question is "we do not know", and the not-knowing is the exposure that governance exists to surface.
This has always been true of computing, but AI sharpens the stakes in a particular way. The systems now being placed at the centre of hiring, lending, triage, and safety decisions inherit the whole stack beneath them, unowned foundation and all. A board can commission a careful audit of a model's behaviour and still have no idea whether the cryptographic library protecting its data is maintained by a funded team or by one exhausted volunteer. Governance attention has gone to the visible layer, the model, precisely because it is the layer with a vendor and an invoice. The foundation gets less attention for the same reason it gets no contract: nobody is selling it to you.
The claim I am making, and I want to be plain that this is my argument and not a fact I am reporting, is that the AI governance question and the open-source governance question are the same question, one layer down. You do not get to answer the first while ignoring the second.
The open-source dimension is where this lands first, because the foundation is not an abstraction. It is named projects with named maintainers. The Linux kernel. OpenSSL and curl, which sit under a large share of the world's encrypted traffic. The GNU toolchain that compiles much of the rest. These are not products with account managers; they are commons with stewards, some funded, many not. The practical governance answer is provenance: a software bill of materials, the SBOM, that records what you actually run; attestation and signed build provenance that let you prove where a component came from; and an honest look at whether the people maintaining your dependencies can afford to keep doing it. Location, again, before control. Knowing what the foundation is, and knowing who holds it up.
And who holds it up, at the largest scale, is often the state. That is the sovereignty dimension, and it is older than it looks. The 1956 consent decrees were instruments of state power: a government compelled two dominant firms to open what the market would have kept closed, and Unix's sharing culture was the result. The same logic runs in the present. The European Union's Digital Markets Act, in force since 2023, designates seven platform companies as gatekeepers and compels them to interoperate. In April 2025 the European Commission issued its first non-compliance fines under it: five hundred million euros against Apple, and two hundred million euros against Meta. Sovereignty over the AI stack begins one layer below the model, at a substrate no single firm owns and no procurement contract governs; where the market will not produce openness, state power still has to compel it.
So I will leave you with the exercise rather than the answer. Pick one AI system you are accountable for and try to locate the foundation beneath it: name the open-source components, find out who maintains them, and trace how a critical fix would reach you. How far did you get before the room went quiet, and what did that silence tell you?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
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 linux@linux.co.nz. Free as in Theft: The Hidden History of Open Source Software (Te Pono Limited, 2026) traces the repeating cycle of openness, adoption, enclosure, and resistance, from the first shared source tapes of the 1950s to the AI licensing battles of the present.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
[1] Hamberger, A. "Free as in Theft: The Hidden History of Open Source Software." Te Pono Limited, 2026. ISBN 978-0-473-78455-3. (Primary source for all Chapter 1 and Preface facts: the SHARE founding, the 1956 consent decrees, Unix distribution, Ken Thompson and the PDP-7, and Gordon Moore's assessment.)
[2] European Commission. "Commission finds Apple and Meta in breach of the Digital Markets Act." 23 April 2025. https://digital-markets-act.ec.europa.eu/commission-finds-apple-and-meta-breach-digital-markets-act-2025-04-23_en
[3] Watzinger, M., Fackler, T. A., Nagler, M., and Schnitzer, M. "How Antitrust Enforcement Can Spur Innovation: Bell Labs and the 1956 Consent Decree." American Economic Journal: Economic Policy, 12(4), 328-359, 2020. https://ideas.repec.org/a/aea/aejpol/v12y2020i4p328-59.html