← The canon · AItopiaOrAImageddon?

Unix and Linux — capability from composable parts, and the open substrate

idea · Unix — Ken Thompson and Dennis M. Ritchie, with M. D. McIlroy, J. F. Ossanna and R. H. Canaday, Bell Telephone Laboratories, from 1969; Linux — Linus Torvalds, University of Helsinki, from 1991, under Richard Stallman's GNU General Public License (1989/1991) · 1991

A framing later work is built out of rather than argued about. Cited when the thing being watched descends from it and the descent explains its shape.

idea is right and proposals.md filed it correctly, but the entry carries two ideas rather than one and it is worth naming both up front, because a reading that cites the wrong half will cite it badly. The first is capability from small composable pieces — Unix's contribution, and, as section 2 argues, the premise every tool-using agent is built on. The second is a licence that makes forking cheaper than defecting — Linux's contribution, and the one the concentration lens actually needs. The house test for idea, set by shannon-chess-1950 and reused by dijkstra-1959 and minimax-alpha-beta, is that there is a mechanism in it you could implement. Both halves pass: a pipe is a system call, and the GPL is a document that produces a predictable behaviour in firms.

moment is the kind this superficially resembles, and it fails the house test. llama-weights-2023 fixed that definition as a date on which something visibly happened in public, and neither of this entry's dates qualifies. Unix in 1969 happened inside one building and was not announced for five years. Linus Torvalds' post of 25 August 1991 was read by a few hundred people on a Usenet group about a different operating system, and its author opened by saying the thing would not amount to much. Nothing was visible to any public on either date. What this entry records is not an event but a fifty-seven-year natural experiment in what happens after source is released, which is why it is filed as an idea and graded in section 3 as though it were a prediction.

The year is 1991, and the choice is contestable. The id spans 1969–1991 and build.py reads the first four-digit number in the field, so this file marks the canon's chart at 1991 rather than 1969. I take the later date because the claim the entry mainly exists to carry is a claim about what an open release produces, and the artefact that produced the answer is the kernel, not the system it imitated. A reader who thinks the entry is really about composition — a defensible reading — should mentally file it at 1969, and section 3 grades the 1974 and 1978 claims on their own dates regardless.

descends_from is [], and that is a statement about canon/ rather than about history. Unix descends from Multics, from CTSS, from the Dartmouth Time-Sharing System's communication files (which Ritchie names as a near-miss on pipes), and from the SDS 930 Berkeley system it borrowed fork from. None of those has an id here and none is in proposals.md, so inventing one is forbidden and they are named in prose instead. arpanet-1969 and tcp-ip-1983 are proposed and unwritten; both are siblings of this entry rather than ancestors — ARPA money and Bell Labs money were different money, and the network and the operating system met later. The descent that matters runs forward: llama-weights-2023 is on disk and its central argument is about open release, and the essay it grades in Claim 5 uses this entry's history as its own justification. I cannot record that edge, because that is another entry's file and this job does not write in it.

On access, stated because it bears on how much below was read at source. The two primary Unix documents are image-encoded PDFs, the wall dijkstra-1959 and minimax-alpha-beta both hit and recorded. This job got past it: the PDFs were fetched and read page-by-page as rendered images, so every Ritchie and Thompson quotation below is from the document itself, not from a secondary quoting it. That method should be reused. What it did not solve: bell-labs.com returned HTTP 410 and nokia.com returned 403, so Ritchie's own home page and the Bell Labs licence price lists were unreachable, and the 1978 Bell System Technical Journal Unix issue was not read at all.

What it is

The system that could not be sold

Unix was built by two people who had just lost their computer.

Bell Telephone Laboratories withdrew from the Multics project across 1968–69. Ritchie's own history — presented at Sydney in September 1979, reprinted in the AT&T Bell Laboratories Technical Journal 63(6) Part 2, October 1984 — describes what the withdrawal cost the people involved, and the sentence is the most important one in the entry:

> What we wanted to preserve was not just a good environment in which to do > programming, but a system around which a fellowship could form.

They asked management for a machine to build it on. Repeatedly, through 1969, and were refused: "The proposal was rejected, and rumor soon had it that W. O. Baker (then vice-president of Research) had reacted to it with the comment 'Bell Laboratories just doesn't do business this way!'" Ritchie's retrospective verdict on his own request is unusually honest — "we were asking the Labs to spend too much money on too few people with too vague a plan."

So Thompson found a cast-off. He had written a game, Space Travel, that cost about $75 of CPU time per play on the Labs' GE 635 and controlled badly; he moved it to "a little-used PDP-7 computer with an excellent display processor," and the operating system followed the game onto the machine. Unix exists because a research group was denied a budget and had a toy to run. Ritchie's own framing: "Unix was born in 1969 not 1974."

The first published description is Ritchie and Thompson, "The UNIX Time-Sharing System," Communications of the ACM 17(7), July 1974, pp. 365–375. Its numbers are worth carrying because the ratio to anything current is the whole point:

> Perhaps the most important achievement of UNIX is to demonstrate that a > powerful operating system for interactive use need not be expensive either in > equipment or in human effort: UNIX can run on hardware costing as little as > $40,000, and less than two man years were spent on the main system software.

The system occupied 42K bytes on a machine with 144K of core. There were about 40 installations. The paper's statistics section reports 72 users, 14 maximum simultaneous users, "about one crash every other day," and a background process idling on a million-digit approximation to e. The authors' stated hope was that "the users of UNIX will find that the most important characteristics of the system are its simplicity, elegance, and ease of use."

Section 8 of that paper — "Perspective" — is where the design is explained, and it gives two causes, neither of them a philosophy:

> Second there have always been fairly severe size constraints on the system and > its software. … the size constraint has encouraged not only economy but a > certain elegance of design. This may be a thinly disguised version of the > "salvation through suffering" philosophy, but in our case it worked.

> Third, nearly from the start, the system was able to, and did, maintain itself. > … Since all source programs were always available and easily modified on-line, > we were willing to revise and rewrite the system and its software when new > ideas were invented, discovered, or suggested by others.

That second passage is a statement of the open-source mechanism, published in 1974, thirteen years before anyone had a phrase for it, and offered as an engineering cause rather than a value. And the paper's summary of its own success is a sentence that should be read next to every architecture announcement the readings meet: "The success of UNIX lies not so much in new inventions but rather in the full exploitation of a carefully selected set of fertile ideas."

Pipes, and a failure of imagination

The composition idea did not arrive with the system. Doug McIlroy proposed it and had to keep proposing it. Ritchie's account:

> Pipes appeared in Unix in 1972, well after the PDP-11 version of the system was > in operation, at the suggestion (or perhaps insistence) of M. D. McIlroy, a > long-time advocate of the non-hierarchical control flow that characterizes > coroutines.

> The idea, explained one afternoon on a blackboard, intrigued us but failed to > ignite any immediate action. … What a failure of imagination!

> Some time later, thanks to McIlroy's persistence, pipes were finally installed > in the operating system (a relatively simple job), and a new notation was > introduced.

Dating caveat: Ritchie's paper says 1972; the manual record and most secondary accounts put pipes in the Third Edition, February 1973. I could not resolve the discrepancy and both are recorded.

Ritchie's own explanation of why the pipeline mattered is more precise than the slogan it became:

> The genius of the Unix pipeline is precisely that it is constructed from the > very same commands used constantly in simplex fashion. The mental leap needed > to see this possibility and to invent the notation is large indeed.

The 1974 paper documents the result — ls | pr -2 | opr — and coins the word: "A program such as pr which copies its standard input to its standard output (with processing) is called a filter." The doctrine was written down four years later by McIlroy, in the foreword to the Bell System Technical Journal's Unix issue (57(6), 1978), in the form everyone quotes: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface." That foreword was not read at source for this entry; the wording is consistent across every secondary that reproduces it, and it is carried at one remove.

Why the source went out at all — which was not generosity

The single most misunderstood fact in this entry is why Bell Labs shipped Unix source to universities for the cost of the tape.

Under the 1956 consent decree settling the government's antitrust case, the Bell System was confined to "common carrier communications services" and required to license its patents at nominal fees. AT&T was legally barred from the computer business. Unix therefore could not be made into a product. Bell Labs shipped it, with source, for the cost of media — and a generation of computer science departments learned operating systems by reading the actual code, most famously through John Lions' Commentary on UNIX 6th Edition (1976), which printed the kernel source with annotations.

This was an artefact of antitrust law, not of philosophy, and the entry is worth less if that is blurred. It also cuts against the folk version in the other direction: Unix was never cheap for anyone with money. Educational licences ran roughly $100–$400; commercial source licences ran about $20,000 for the Sixth Edition from 1977, about $43,000 for System V with $16,000 per additional CPU, and rose towards six figures. The best short statement of the correction, from an LWN comment thread of 9 March 2020: "Unix was neither free nor cheap until BSD 4.3 or later." The openness was a price discrimination imposed by a court, aimed at people with no budget, and it worked because the people with no budget were students.

The closing, and what the closing caused

Then the decree stopped applying, and every subsequent event in this entry is a licensing event rather than a technical one.

A source was closed in 1979 to protect a trade secret; twelve years later that decision had produced, at two removes, the free kernel that displaced the product it was protecting. That chain is documented at every link and it is the most transferable thing in this file.

The kernel that disclaimed itself

The post is dated 25 August 1991, 20:57:08 GMT, to comp.os.minix, under the subject "What would you like to see most in minix?":

> I'm doing a (free) operating system (just a hobby, won't be big and > professional like gnu) for 386(486) AT clones. This has been brewing since > April, and is starting to get ready. … I've currently ported bash(1.08) and > gcc(1.40), and things seem to work. This implies that I'll get something > practical within a few months…

Version 0.01 went to an FTP server on 17 September 1991. Its release notes, read at source on kernel.org, describe it as "a free minix-like kernel for i386(+) based AT-machines" and "not a mature product," and carry a licence Torvalds wrote himself:

> This kernel is (C) 1991 Linus Torvalds, but all or part of it may be > redistributed provided you do the following: > - Full source must be available (and free), if not with the distribution then > at least on asking for it. > - Copyright notices must be intact. … > - You may not distibute this for a fee, not even "handling" costs.

The third clause was replaced within months. Version 0.12 carried the GNU General Public License version 2 instead; sources date the switch to January 1992 with the GPL "in effect as of 1 February 1992" and the discrepancy is recorded rather than resolved. Torvalds' own account of why, given in a May 2016 interview:

> I decided that rather than just change my license by editing it again, I should > just use an existing one. … Part of it was also because I felt that the > availability of gcc was very important to the project, so picking the GPLv2 as > a homage to gcc was appropriate.

And, on the clause he dropped: "And clearly allowing the commercial side has been a very good thing for everybody." The licence Linux adopted was Richard Stallman's, from the project Stallman had announced on 27 September 1983 with the words "Free Unix!" and the promise to "write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it." By 1991 GNU had the compiler, the shell, the editor and the libraries, and no kernel. The system Stallman specified was completed by a student who said in his first sentence that he was not doing anything as serious as GNU.

What the incumbent thought, on the record

Where it had got to by this reading, 19 August 2026

Why a reading would cite it

Not for nostalgia, and not to say that open source is good. The occasions are specific, and the first is the reason the owner named this entry.

1. When the distribute-versus-centralise axis is stated as a dichotomy. On 17 August 2026 this project recorded David Sacks replying to Dario Amodei: "Dario Amodei believes frontier AI is too powerful to distribute; we believe it is too powerful to centralize." That is the concentration lens in one line, and both men are assuming the two are opposites. This entry is the case where both happened at once. The substrate was distributed completely — the source is free, the licence is irrevocable, anyone can fork it, and 84% of the world's servers run it. And over the same period the industry concentrated harder than any before it: three clouds, one dominant chip vendor, and on 17 August 2026 a single outage at one company took down the world's source control, its CI and a large share of its code assistance in one event. Distributing the artefact did not distribute the power, because the power moved to the layer above it — to scale, to distribution, and to the machines the free thing runs on. A reading that meets either man's claim can say, with sixty years of evidence, that openness at the substrate is compatible with extreme concentration above it, and that arguing about the licence is not the same as arguing about the market.

2. When an open-weights release is scored as decisive in either direction. The occasion recurs constantly — Qwen past three billion downloads against Meta's 227 million and Google's 418 million on the Hugging Face report of 14 August 2026, DeepSeek's V4-Pro, the workloads the Wall Street Journal reported on 18 August 2026 moving onto cheaper open models. The split verdict this entry supplies is neither side's talking point: openness won the substrate and lost the rents. Linux runs essentially all of the infrastructure; the largest pure-play open-source company ever, Red Hat, was worth $3.4bn of annual revenue when IBM paid $34bn for it in 2019, which is a rounding error against what was earned on top of the free layer over the same decades. If open weights follow this path, the prediction is not that the open labs win or lose — it is that the open model becomes the default substrate and the margin moves somewhere else, most likely to whoever owns the inference capacity and the distribution. The 16 August 2026 acquisition of OpenRouter by Stripe for over $7bn is that mechanism showing up early: the layer that made models interchangeable was worth buying precisely because the models were becoming interchangeable.

3. When someone reaches for the Linux analogy directly. They do, at the highest level. Zuckerberg's Open Source AI Is the Path Forward, 23 July 2024, rests on it explicitly — "the major tech companies of the day each invested heavily in developing their own closed source versions of Unix"; "Today, Linux is the industry standard foundation for both cloud computing and the operating systems that run most mobile devices"; "If we were the only company using Llama, this ecosystem wouldn't develop and we'd fare no better than the closed variants of Unix." The historical claims in that passage are broadly accurate. What the analogy omits is in section 4, and a reading meeting it should supply the omissions rather than accept or reject the frame. llama-weights-2023 grades that essay's own forecast and this file does not re-grade it.

4. When the geography of the open thing is the story. The system was written in New Jersey under an American antitrust decree and its kernel in Helsinki, and in June 2026 the fastest computer on earth is Chinese hardware running a Chinese Linux distribution. That is the same shape as the download tables this project recorded on 15 August 2026. An open artefact accrues to whoever invests in using it, and no policy instrument in the country of origin can change that afterwards — which is the fact under every export-control argument aimed at weights.

5. When the supply chain of an open artefact is at issue. See section 3 on xz. The transferable finding for AI is that an open artefact's danger is not mainly that bad actors can use it — it is that the pipeline producing it is maintained by a small number of under-resourced people, and that a patient attacker can become one of them. Applied to models, the exposure is the checkpoint, the tokenizer, the fine-tuning dataset and the package that loads them, and the base rate for how long such a compromise can survive review is in this file rather than in any AI paper.

6. When "the community" is credited for an open project. 84.3% of Linux commits are from paid corporate employees; more than half of patches flow through maintainers at five companies. Any claim that an open ecosystem is decentralised should be checked against who signs the paycheques of the people with commit rights. For open weights the analogous question — who can afford to retrain rather than merely download — has an even harsher answer.

The honest limit of the citation, stated so it cannot be quietly exceeded. This entry is not evidence that open weights are safe, dangerous, winning or losing. It is a single, very long-running case with confounds this file names: the openness was mandated by a court, the winner was picked partly by a lawsuit, and the artefact in question is qualitatively unlike a model. It is admissible for the structure of the open/closed question — which layer openness settles, which it does not, and where the money goes afterwards — and inadmissible as a forecast. A reading that uses it to predict who wins is using it wrongly.

What it got right, and what it got wrong

idea does not require this section. It is written in full because the entry's entire working life is as a thing people over-claim from, and because six of the claims around it are gradeable with dates on both ends.

Claim 1 — Ritchie and Thompson: "less than two man years were spent on the main system software," and the important characteristics are "simplicity, elegance, and ease of use." Made July 1974. Standing. Right, and then inverted by its own descendants.

The claim about the artefact was true and remains checkable: 42K bytes, two person-years, about 40 installations. The claim about what would matter has held in one sense and been comprehensively defeated in another. The interface survived: the file abstraction, the process model, fork/exec, the shell and the pipe are all still there, in a kernel now spanning tens of millions of lines maintained by eleven thousand people at eighteen hundred organisations. The simplicity did not. A system whose authors credited its size constraint for its elegance became one of the largest artefacts ever built. That is not hypocrisy; it is what happens when an interface is good enough to survive a million-fold change in the thing behind it, and it is the most useful precedent in this file for anyone asking whether a current abstraction will last.

Claim 2 — McIlroy: "Write programs that do one thing and do it well. Write programs to work together." Made 1978. Due continuously. Right where it is now most load-bearing; abandoned everywhere it is most visible.

Graded honestly, the doctrine lost the argument in the places anyone looks. The browser, the phone OS, the IDE, systemd, and every serious machine-learning framework are large integrated systems, not small cooperating filters. Anyone grading by market share would call this wrong.

And it is the operating premise of everything the readings currently cover. An agent that calls tools is a shell script with a language model where the shell used to be: small single-purpose programs, a universal interchange format, output of one becoming input of the next, composition decided at run time rather than compile time. The 2026-08-19 reading's protein-design item is exactly this shape — a model "orchestrated open-source design and folding tools" and the wet-lab step ran at two other companies. Nobody argues for the Unix philosophy any more; they rebuilt it, in JSON, and called it tool use. The grade is that the idea lost as a style and won as an architecture, and a reading that meets an agent framework can say what its ancestor is.

Claim 3 — Stallman: "Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU." Made 27 September 1983. Due open-ended. Right about everything except the part he thought was the point.

The userland shipped and won: gcc, bash, glibc, coreutils are on essentially every Linux system alive, and Torvalds picked GPLv2 as "a homage to gcc." The kernel never shipped. GNU Hurd has been under development for thirty-five years and has never been a released production kernel. The system Stallman specified was completed in 1991 by someone whose announcement disclaimed being "big and professional like gnu."

The useful grade is not that he was slow. It is that the licence outlived the software and the plan. Everything Stallman actually built is replaceable and some of it has been replaced; the GPL is the part that could not be routed around, and it is why Ballmer's complaint in 2001 was about the licence rather than the code. A reading weighing an AI release should note that no model licence in circulation has that property — the reciprocity clause, the thing that makes taking without giving back legally impossible — and that its absence is a choice.

Claim 4 — Torvalds: "just a hobby, won't be big and professional like gnu." Made 25 August 1991. Due within a decade. The cleanest under-claim in this canon, and self-graded by its author ever since.

By any measure the sentence is wrong by orders of magnitude. It is included because it is the base rate's other tail. This project's prediction entries exist to measure how wrong AI forecasting runs, and they are dominated by over-claims; the record also contains the case where the person closest to the work, with the most information, under-called it completely. Torvalds has never tried to spin it — he quotes it against himself. Both tails are wide, and a reading that treats scepticism as automatically the calibrated position is choosing a side, not calibrating.

Claim 5 — Tanenbaum: "LINUX is obsolete." Posted to comp.os.minix, 29 January 1992. Due continuously. Wrong on the outcome, defensible on the architecture, and self-graded by the author in a way that differs from the outside view — which is the point.

The claim: "LINUX is a monolithic style system. This is a giant step back into the 1970s… To me, writing a monolithic system in 1991 is a truly poor idea."

Wrong on the outcome, comprehensively. The monolithic kernel took the supercomputers, the servers, the cloud and the phones.

Not wrong in the way it is usually mocked. Tanenbaum's argument was about reliability and portability, not popularity, and in May 2006 he restated it rather than retracting: "MINIX 3 and my research generally is NOT about microkernels. It is about building highly reliable, self-healing, operating systems," with his own success criterion — "I will consider the job finished when no manufacturer anywhere makes a PC with a reset button."

And the independent grade differs from the self-grade in an unexpected direction — it is kinder. In November 2017 it emerged that MINIX 3 runs inside the Intel Management Engine, on essentially every Intel CPU sold for a decade, which prompted Tanenbaum's open letter to Intel's chief executive: the courtesy he says he was owed was to be told "that MINIX was now probably the most widely used operating system in the world on x86 computers." Both men's kernels shipped at planetary scale; one is the thing everybody runs and the other is the thing running underneath it, invisible and unauditable. The 1992 debate was scored on the wrong axis by both sides and by everyone since, and a reading that meets an architecture argument — dense against sparse, monolith against microservice, one big model against a scaffold of small ones — should note how badly the loudest version of this one predicted where each design would end up.

Claim 6 — Raymond: "Given enough eyeballs, all bugs are shallow." Formulated 1997, published in The Cathedral and the Bazaar. Due continuously. Refuted in the strong form, and the refutation is the most transferable item in this file.

Heartbleed (April 2014) sat in OpenSSL — a library securing a large share of the web — for about two years, maintained by a couple of people. The usual defence is that the law is about reviewers, not users, and that OpenSSL had millions of the second and almost none of the first. That defence is correct and it concedes the interesting half: openness supplies the opportunity to review and nothing else, and opportunity without funded attention is not a security property.

xz-utils (CVE-2024-3094, March 2024) refutes even the repaired version. An identity operating as "Jia Tan" spent roughly two to three years making legitimate contributions to a compression library, while sockpuppet accounts — "Jigar Kumar," "krygorin4545," "misoeater91" — ran a pressure campaign against the exhausted volunteer maintainer, until "Jia Tan" was granted maintainer rights and shipped a backdoor giving whoever held one Ed448 private key remote code execution over SSH on much of the internet. CVSS 10.0. It was caught by one Microsoft engineer, Andres Freund, investigating why SSH logins on a development machine were using slightly too much CPU. Red Hat, SUSE and Debian reverted; Canonical rebuilt every binary and delayed an LTS beta by a week.

Grade it exactly: the eyeballs did not find it; one pair of eyes found it by accident, after the attacker had already become one of the reviewers. For a project meeting claims about open models, the lesson transfers with almost no adjustment. The threat model for an open artefact is not only misuse by downloaders. It is patient compromise of the small, tired, unpaid pipeline that produces the artefact everyone trusts — and in the AI stack that pipeline is the model hub, the loader library, the fine-tuning dataset and the serving engine, several of which have exactly one busy maintainer. This project's own record already contains the shape: the 2026-08-14 reading carried an attempted supply-chain attack on a live open-source project, and the 18-19 August readings carried a frontier lab hardening its research environments after its own agents breached a model hub.

Claim 7 — Microsoft, internally: "OSS poses a direct, short-term revenue and platform threat to Microsoft — particularly in server space." August 1998. Due within a decade. Right on the diagnosis, wrong on everything that followed from it.

The threat assessment was accurate and early: Linux did take the server. The strategic conclusion — that this had to be fought, and the public posture that followed it, including the 2001 "cancer" line — was abandoned by the same company, which joined the Linux Foundation at the top membership tier in 2016, ships a Linux distribution, and employed the engineer who found the xz backdoor. A large incumbent's public assessment of an open technology was reversed completely inside eighteen years, by the incumbent, without any of the underlying facts changing. A reading grading any lab's current position on open weights — in either direction — should hold this next to it, alongside the reversals llama-weights-2023 documents on its own subject. Positions on openness are the least durable thing anyone in this industry says.

Commonly misused as

limit owns this section and this entry is an idea, but this is the entry's most valuable half, because it is the historical case both sides of the open-weights argument reach for and neither has read carefully.

Misused as: "open source always wins, therefore open weights will win." It won one layer. It won the substrate — kernels, compilers, databases, container runtimes, and now the training and serving frameworks — and lost the desktop, the phone experience, the application layer, and effectively all of the profit. If the analogy holds for AI, the prediction it supports is that open weights become the default commodity input and the money sits above them, which is a claim about the shape of the industry, not a win for the open side. Anyone citing this file to say the open labs will beat the closed labs is citing it for the opposite of what it shows.

Misused as: proof that open beats closed on quality. The mechanism was licensing and contingency, not merit, and the counterfactual is on the record from the winner. USL sued BSDI and the University of California in 1992; the case was settled in 1994 after the judge doubted the plaintiff's intellectual property; and the free Unix that already existed spent those two years under a legal cloud while contributors drifted to the kernel that did not. Torvalds, to Meta magazine in 1993: "If 386BSD had been available when I started on Linux, Linux would probably never had happened." The most-deployed piece of software in history exists because a competitor was in litigation. Any argument that the better open artefact wins has to explain that sentence, and the same caution applies to reading the current open-weights league table as a pure quality ranking.

Misused as: "open weights are the Linux of AI." Four disanalogies, each of which changes the conclusion:

Misused as: "Unix/Linux was free, and free is why it won." Unix was not free. Commercial licences went from $20,000 to six figures. It reached universities cheaply because a 1956 antitrust decree made it unsellable, and it stopped reaching them the moment the decree lapsed. The correct summary is that a regulator accidentally created the conditions for an ecosystem, then removed them, and the ecosystem regrew outside the firm — which is a much stranger story than "free won," and a much more relevant one to anybody drafting AI policy.

Misused as: evidence that openness prevents concentration. This is the misuse the concentration lens will actually meet, and it is the one worth policing hardest. Every layer of the AI boom's physical substrate is open — Linux, CUDA's host stack, PyTorch, vLLM — and the industry sitting on it is among the most concentrated in economic history. Openness at layer N constrains nobody at layer N+1. Gödel is this canon's standing example of a result carried into arguments it cannot support; this is the same move with a licence instead of a theorem.

Misused as: "the community maintains it." 84.3% corporate commits; over half of patches through maintainers at five companies; Android developed on internal branches since March 2025 and published only on release. An open licence is compatible with a closed development process, and "open" said without saying which of licence, process, data or governance is meant will mislead every time.

Misused as: an argument for open weights from security. The eyeballs claim is graded in section 3 and it does not survive xz. Openness enables review; it does not perform it. Anyone citing this entry for the safety of open weights is citing a case where the most widely reviewed codebase on earth carried a deliberately planted backdoor into three major distributions and was saved by one engineer's curiosity about half a second of latency.

Sources

Read directly, at source. The two Unix primaries are image-encoded PDFs; both were fetched and read page by page as rendered images, and every quotation from them is from the document.

Verified through search summaries and secondary sources, named because specific claims rest on them:

Attempted and failed, recorded so nothing above silently depends on it: bell-labs.com/usr/dmr/www/hist.html returned HTTP 410 Gone; nokia.com/bell-labs/…/hist.pdf and …/licenses.html returned HTTP 403; www.catb.org presented a certificate for unrelated hostnames and could not be fetched; gnu.org/gnu/initial-announcement.en.html returned HTTP 429 and the 1983 announcement is quoted from search reproductions rather than from the FSF's own page; the TOP500 June 2026 operating-system-family table returned navigation without data.

Project context read while writing: README.md, LENSES.md, canon/proposals.md, canon/llama-weights-2023.md, canon/minimax-alpha-beta.md, and the digests of 15, 17, 18 and 19 August 2026. The live occasions named in section 2 — the Sacks/Amodei exchange of 17 August, the OpenRouter acquisition of 16 August, the GitHub outage of 17 August, the Hugging Face download report of 14–15 August, the workload-migration reporting of 18 August, and the protein-design item of 18 August — are all from those digests and rest on the primary sources those readings cited, not on this file.

On the boundary. This file reads other entries in canon/ and names arpanet-1969 and tcp-ip-1983 as proposed-but-unwritten ids without inventing them into the header; descends_from is empty and the prose says why. It grades Microsoft, Meta and Google in both directions and grades no current AI lab at all — every claim graded in section 3 is dated, the most recent of them from 1998, and the 2026 material appears as record rather than verdict. llama-weights-2023 already grades the 2024 Zuckerberg forecast and this file defers to it rather than scoring the same claim twice. It deposits nothing in history/, writes no digest, touches no other entry's file, places no needle, score or landmark position, and does not run build.py.