# open-source.sgit.ai — every page, one file Site version: v0.2.2. Generated from the HTML by admin/build/gen_markdown.py. Canonical host: https://open-source.sgit.ai/ — every section below is one page of the site. This file exists so an agent that cannot follow links still gets the whole site. All content CC BY 4.0 unless noted. ============================================================================== PAGE: /index.html (markdown twin: /index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/index.html* > Open source as a strategy rather than a charity — by Dinis Cruz, founder of the sgit.ai network, MyFeeds.ai and The Cyber Boardroom, and former OWASP Board member. Guidance for founders on owning the code or opening it; the position with its counter-cases; the licences actually in force; and a history checked against its sources, including six corrections to the story most sites tell. --- Open source · sovereignty · survivability · the economics # Open source is a strategy. It is not a charity. Most sites arguing for open source argue that it is generous. This one does not. **The power of open source is not for the community, it is not because it is nice for others, and it is not to give back** — it is that technology stops being the moat, that you become free to delete your own code, and that sovereignty becomes possible at all. And the accurate history supports that far better than the romantic one does. By [**Dinis Cruz**](about/index.md) — founder of [sgit.ai](https://sgit.ai) and [sgraph.ai](https://sgraph.ai), [MyFeeds.ai](https://investor.myfeeds.ai/), [RiskMandate.ai](https://riskmandate.ai), [VoiceDebrief.ai](https://voicedebrief.ai) and [The Cyber Boardroom](https://thecyberboardroom.com); former OWASP Board member. This is the strategy those companies run on. [↗ LinkedIn](https://www.linkedin.com/in/diniscruz) [For founders: owning the code, or opening it →](founders/index.md)[Read the position →](views/index.md)[Run the stress test on a vendor →](survivability/stress-test.md) ## For founders: owning the code, or opening it Every solo founder who ships something that works arrives at the same fear: a bigger, better-resourced company takes the code and there is nothing left. Notes from a strategy session with an early-stage SaaS founder — the walk-through that answers it, and what it changes about how you build. ### [What copying you would actually cost them](founders/index.md#cost) *The answer* An established company holding a full copy of your code still has to decide, fund, staff, deploy and own it forever. **Optimistic: three months to reach where you already are. Realistic: closer to a year.** Which turns the fear into the pitch: *"You can take it. It will cost you that. Or you can pay me, and have it next week."* ### [Instinct versus leverage](founders/index.md#issues) *Four things that surface* The shop-front reflex, the keys in the repo, prototype code asked to behave like a product, and the collaboration that is not a commitment — each an instinct that made sense once, with the counter-argument that reverses it now. ### [Eight steps, in order](founders/index.md#route) *The practical route* Four you do while the repo is still private, one point of no return, and three habits that run alongside from this week. Plus the three things to settle before you publish: the licence is a commercial decision, trade marks come first, and where the cost argument stops holding. ### [A week of this, counted](founders/index.md#week) *The discipline* Releases tagged, untrue claims removed, support channels live. The handover from prototype to product is invisible from the outside unless you count it — and publishing the count means you cannot quietly skip a week. ## Not free. Free*dom*. Two sentences carry the whole site. The first is the unfashionable one; the second is the one that makes it land. > "the power of open source is not for the community, it is not because it is nice for others, and it is not to give back." > "open source is not free, somebody is always paying for it. What you get from open source is freedom, that is different… We play the game of empowering the user and being the reputable source of trust. **We are selling trust.**" Everything else here is a consequence of those two. If open source is a gift, then its funding problem is a moral failure and the answer is to shame people into paying. If it is a strategy, the funding problem is an *externality* — and externalities are fixed by structure and by market forces, not by virtue. [cURL is the case that settles it →](funding/curl.md) ## The position, the practice, and the history Three things a site about open source should be able to show: what it thinks, what it actually ships and under which licence, and whether the history it leans on is true. This one does all three, and says where each comes from. | What | Where it comes from | What this site does | |---|---|---| | **The position** | **The author's own writing** — 56 catalogued concepts, 24 of them original arguments rather than restatements | [Argues them, and names the counter-case each time](views/index.md) | | **The practice** | **The licence files** — three licences across three layers of a real, shipping estate | [Publishes the licences, and the reasoning behind each](practice/index.md) | | **The history** | **Researched from primary sources** for this site — 1955 to 2026, every number carrying its source, date and caveat | [Leads with six corrections to the standard story](history/index.md) | The division of labour is deliberate: **the argument comes from experience, the ground under it comes from research** — and the research turned out to support the argument better than the version everybody repeats. [The numbers, and the ones this site declines to publish →](history/numbers.md) ## Six things the standard history gets wrong These lead, rather than a timeline, because everyone has a timeline and almost nobody publishes these. Each one is checkable, and each one points the same way: the model wins on **economics and structure**, not on virtue and not on eyeballs. ### [Unix circulated because it was illegal to sell it](history/index.md#unix) *1955–1982* The 1956 AT&T consent decree barred Bell Labs from any business but common-carrier communications. Unix shipped for media and postage as a **compliance artefact**. The decree lifted in 1982 and AT&T commercialised System V immediately. ### [BSD lost to litigation risk, not to its licence](history/index.md#bsd) *1992–1994* USL v. BSDi clouded free Unix during exactly the window Linux needed. The settlement removed **three files out of eighteen thousand**. The claim was nearly empty; the two years of uncertainty were decisive. ### [Netscape's source release was a six-year near-failure](history/index.md#netscape) *1998–2004* The code was so degraded the team threw it away and rewrote. **Firefox 1.0 did not ship until November 2004**, by which time IE had won. The founding case study of the movement is a cautionary tale. ### [Eric Raymond did not coin "open source"](history/index.md#peterson) *Feb 1998* **Christine Peterson** did — and deliberately had someone with more credibility as a Linux programmer introduce it, so that it would spread. Sources disagree on the exact day; they do not disagree on who. ### ["Given enough eyeballs" is not a security property](history/index.md#eyeballs) *2014, 2024* Heartbleed survived two years in the most security-critical library on the internet. **xz was engineered by the maintainer to survive review** — and was caught by one engineer benchmarking SSH latency, not by a security review. ### [Two of the four relicensings reversed](history/index.md#reversals) *2018–2025* Elastic added AGPLv3 in August 2024; Redis 8 shipped AGPLv3 in May 2025. That does not weaken the survivability argument — **it sharpens it**. The same single-holder standing that let them leave let them come back. ## Survivability is not a property of the licence file Buyers read licence files. Licence files are the *weakest* of the structural protections, and 2018–2024 is the proof. > "Survivable is not a property of the licence file. **It is a property of the copyright and trademark structure.**" The mechanism, which is what makes it a finding rather than an opinion: *"Every catalogued relicensing between 2018 and 2024 followed the same legal pattern: a single corporate copyright holder, having aggregated contributor copyright via a CLA, exercised the right to change terms going forward. Distributed-copyright projects could not be moved the same way, because no single party had standing."* And the kicker — **HashiCorp went BUSL, IBM acquired it, and the licence stayed.** Acquisition entrenches the closure; it does not reverse it. ### [Why the licence is the weakest protection](survivability/index.md) *The argument* PostgreSQL is the control case — no company owns it, so no company can relicense it, and it is now the most-used database. OpenSolaris is the counter-case. The licence was not the problem; the copyright holder was. ### [The Change-of-Control Stress Test](survivability/stress-test.md) *The tool* Four legs — copyright, trademark, schema licence, named fork capacity — every one answerable from public artefacts, with no cooperation from the vendor. **Run it here, on any project, and keep the result.** ### [We run it on our own estate, in public](survivability/self-audit.md) *The self-audit* A test its author will not apply to themselves is marketing. The four legs run against the sgit estate, the verdict published, and what each leg would take to change — including the one that is not in any project's own gift. ## The positions, with their counter-cases attached A page that only states one side reads as advocacy. Every argument here carries the strongest objection to it — and where the author's own position moved between one dated document and the next, both dates are published rather than tidied into one. ### [Sovereignty requires open source](views/sovereignty.md) *Four steps* You are one SLA away from losing access; the schemas matter as much as the code; and whichever government has jurisdiction over the company that controls the code controls everyone downstream. Necessary, but not sufficient — and the site stays careful about that. ### [Open core, or packaging?](views/open-core.md) *Position moved* 18 June: *"There should be nothing proprietary."* 17 July: *"customers only have a subset of the code that exists in the main repo."* Five weeks apart, and the July document names the tension itself. Here is the one-question test that settles which one it is. ### [Somebody has to be the villagers](views/villagers.md) *The market* Maintaining the non-functional requirements as a market, and the ability to read and repair code somebody else wrote as an appreciating asset — published with both of its own counter-arguments, including the sharp one: a firm paid to maintain has no incentive to say the thing should be retired. ### [Agents, and the junior pipeline](agents/index.md) *Two dates* March: the density of learning per hour increases. July: the gains shifted work from juniors to seniors, at exactly the moment the maintenance need is growing. Both on the record, and what would settle it. ### [Three funding answers, and how they fit](funding/index.md) *A position* Labelling, a maintainer platform, sovereignty bounties. Three proposals for three different failures — information, transaction, substitution — compared for the first time, with a position on which is the precondition and which is the mechanism. ### [The position in full](views/index.md) *All of it* Technology is not the moat. Lock-in relocates to quality and certification. Lock-in degrades your own architecture. Open source frees you to cannibalise your own code. And the moat is a rate, not a wall: a competitor who forks today gets your position, not your velocity. ## Anyone can hold a position. Showing the licence file is different This is the page that makes the rest credible: the licences actually in force across a shipping estate, and the reasoning behind each of them. ### [Apache-2.0 on the code, CC BY 4.0 on everything written](practice/index.md) *Three licences* Code is Apache-2.0, where the patent grant matters. Around 1,100 working documents and the published essays at `docs.diniscruz.ai` carry CC BY 4.0, where attribution carries provenance — settled on 6 September 2026, after the published-articles repository was found to say CC0. Two licences, three layers, and what each is for. ### [Why Apache-2.0 rather than MIT](practice/apache-vs-mit.md) *The choice* The entire estate rests on that choice. The patent grant, the defensive termination clause, the NOTICE file — and the cost, which is that Apache-2.0 is the heavier licence to comply with. ### [Publish the source next to the render](practice/publish-the-source.md) *A mechanism* Every page available as markdown at the same path with the extension swapped, and the links inside the markdown pointing at markdown — **which is how this site is built**. Plus the radical version: publish the evidence, the provenance, and every prompt. ## Agents are a primary audience of this site, so traversal is a build requirement An agent-access report run against this estate found the failure precisely: *"many agents can only fetch URLs that a search engine has already returned to them… **A link listed inside a fetched document did not count as having been seen.** It can read the map and cannot walk it."* A site about open source that agents cannot traverse would fail in exactly the way its own author had already diagnosed — so the mitigation is built in. | The rung | What this site ships | What it fixes | |---|---|---| | **The markdown twin** | **Every page**, same path, extension swapped — and links inside the markdown point at markdown | An agent never parses HTML, and never leaves the markdown surface once it arrives | | **`llms.txt`** | **Self-sufficient** — it states the thesis rather than linking to it | A bare link list is the failure mode when links inside a document do not count as seen | | **`llms-full.txt`** | **Every page in one file** | Removes link-following from the problem entirely | | **Getting indexed** | **In progress** — the site is new | The rung that takes time rather than engineering. [On the build order →](roadmap/index.md) | Read this page as [markdown](index.md), take the whole site as [llms-full.txt](llms-full.txt), or start from [llms.txt](llms.txt). The generator is [published with the rest of the build tooling](admin/index.md), because a site making this argument should show the mechanism. ## What's next The build order is published with its open questions visible, because a position that hides what it has not yet settled is advertising. Three items lead. ### [An SBOM of the estate, and a licence audit in CI](roadmap/index.md#supply-chain) *Next* The site argues that companies should declare their supply chain. The estate's own declaration is the first item on the build order — roughly a day's work, and it converts the labelling argument from a proposal into a demonstration. ### [The agent-era licensing arguments](agents/index.md#unwritten) *Four theses* Licence compliance at machine speed, provenance of AI-generated code, training-data licensing, and what CC BY means for machine reuse. Each follows from material already published; each is named, and next to be written. ### [Seven questions still open, one decided](roadmap/index.md#open) *Open questions* Is the customer subset open core or packaging? Do agents help or harm sustainability? Is "open source AI" coherent without training data? Several are decisions for the project rather than research for the site — listed so the decisions can be seen being made. ### [What is built, and what is next, in order](roadmap/index.md) *The build order* Every section's state, seven items in sequence, and where this site stops and a sibling site in the network begins. ## Who is writing this **Dinis Cruz** — founder of The Cyber Boardroom, MyFeeds.ai, RiskMandate.ai, VoiceDebrief.ai and the sgit.ai network (commercialised through sgraph.ai); former OWASP Board member and organiser of the OWASP Summits; creator of the O2 Platform and of the OSBot, MGraph-DB, Issues-FS and sgit families of open-source tools. This site is the strategy those companies run on, written from the experience of running it: everything they ship is open source, and so are their investor materials. The estate is run through [its own stress test](survivability/self-audit.md), result published. [About the author, and interests declared →](about/index.md)[↗ LinkedIn](https://www.linkedin.com/in/diniscruz)[↗ Investor materials, published in the open](https://investor.myfeeds.ai/) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /founders/index.html (markdown twin: /founders/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/founders/index.html* > Field notes from a strategy session with a solo founder: what copying your code would actually cost an incumbent, four instincts and their counter-arguments, the explorer–villager–town-planner frame, eight steps in order, what to settle before you publish, and what a week of building in the open looks like when it is counted. --- # Owning the code, or opening it Every solo founder who ships something that works arrives at the same fear: **a bigger, better-resourced company takes the idea and there is nothing left.** These are the notes from a strategy session with an early-stage SaaS founder who had arrived at exactly that point — the walk-through that answers it, and what it changes about how you build. > **The question on the table.***"A larger company in my market could take this code, drop it into their own system, hand it to their users, and I would have nothing left. A well-funded incumbent has already shipped something adjacent. What exactly stops them?"* That is where most solo founders start, and it is the right question. The answer is not a principle. It is a walk through what would actually happen. ## Part one · What copying you would actually cost them The useful response is to walk the scenario through rather than argue the principle. An established company of a few hundred people, holding a full copy of the code, still has to do all of the following before a single user touches it. **Each step is a place the plan stalls.** | # | What they have to do | What it costs them | |---|---|---| | **01** | **Decide to do it at all.** Somebody senior has to sponsor a project that is not currently on the roadmap. | stall risk | | **02** | **Fund it.** Budget has to come off something else that is already committed. | + weeks | | **03** | **Find someone to run it.** If they already had that person in-house, they would have built it themselves. The obvious hire is the person who already did. | + weeks | | **04** | **Pull developers off other work.** Or recruit. Either way something else stops. | + months | | **05** | **Deploy it into their estate.** Security review, integration with the intranet, internal marketing to get their own users onto it. | £5k–£20k+ | | **06** | **Own it forever.** Once their users depend on it, they carry support, maintenance and every future feature, with nobody who understands the product. | permanent cost | **Optimistic: three months to reach where you already are. Realistic: closer to a year.** Which turns the fear into the pitch: > "You can take it. It will cost you that. Or you can pay me, and have it next week." Price the licence below their internal build cost and the buy decision makes itself. And there is a second trap for them on top: **taking a competitor's code hands that competitor control of their roadmap.** Every fix and every new feature either comes from you, or gets maintained by them in perpetuity. ## Part two · Four things that surfaced The cost argument answers the question that was asked. These are the four things underneath it that came up once the fear was priced — each an instinct that made sense once, and the counter-argument that reverses it now. | The instinct | The counter-argument | |---|---| | **The shop-front reflex.** Owning the code feels like owning the shop. That instinct is normal for anyone who cannot build the thing themselves, and it made sense when competitors were slow. | The instinct now produces bad decisions. **Open-sourced work gets cloned far less often than founders fear**, because the hard part is execution and staying with it, not access to the source. | | **"I can't open it, there are keys in there."** The stated reason for keeping the repo private is the wrong reason. The exposure already exists in a private repo. It is just unobserved, and it bites later. | Give yourself the problem so you are forced to solve it. **Public pressure produces the practice** of not putting secrets there in the first place, and catching them fast when they appear. | | **Prototype code, product expectations.** What ships first is custom-build work carrying prehistoric experiments from the exploration phase. It gets asked to behave like a product it was never rebuilt to be. | Do a clean pass. **Extract what you want, rebuild it in a new repo — identical functionality and no new features.** This used to be prohibitively expensive. It is not now. | | **A collaboration is not a commitment.** Early technical partnerships are easy to enter and easy to drift out of. A promising conversation is not a working relationship, and waiting to find out which one you have costs weeks you cannot get back. | Keep looking regardless. **Alignment matters more than raw skill**, because experienced developers can be set in their own way of working, and the right collaborator is usually already somewhere in your network. Talking to several people at once is prudence, not disloyalty. | ## Part three · Explorer, villager, town planner Simon Wardley's evolution model is the spine of the technical argument. Each stage is a different job with different standards, and **the common mistake in AI-assisted building is treating all three as one.** The pattern itself belongs to [wardley-maps.sgit.ai](https://wardley-maps.sgit.ai); what matters here is the moment between the first two. ### Explorer *Stage one* Genesis and custom build. Try things, fail fast, keep what works. Engineering discipline is deliberately light — that is the point of the stage, not a failing of it. ### The handover *The moment that matters* Custom build passing to villagers. Clean rebuild, structure, tests, no secrets. **The bar goes up because other people are about to read it.** ### Villager → product *Stage three* Stable feature set, real SLAs, separate environments. Users start depending on it, so change slows deliberately. This is the same frame that produces [the maintenance market this site argues for](../views/villagers.md): somebody has to be the villagers, and the founder's first job after the prototype works is to become one for their own code. ## Part four · The practical route, in order Eight steps. The first four happen while the repo is still private and nothing is exposed; the fifth is the point of no return; the last three are habits that run alongside, starting this week. ### Do now, while the repo is private — nothing exposed yet 01 ### Create a fresh GitHub repository from the web interface Use a naming convention you can repeat, such as `project__component`. Set it private for the first version. **Select the licence at creation, not later.** 02 ### Connect your coding agent to that repository A terminal-based agent with repo access, not a chat window. Then point it at the existing project folder. 03 ### Run the conversion pass New session, one job: produce an open-source-ready version of the current code. **Same functionality, same behaviour, cleaned structure, no secrets, no dead experiments.** 04 ### Hand the cleaned folder back to your build platform as a new project This also opens the door to hosting elsewhere later. **No build platform should be a permanent dependency.** ### Only after licence and IP are settled — the point of no return 05 ### Invite one trusted reviewer to the private repo Reviewer first, then their team, then it goes public. **A good reviewer will refuse access to your live environment**: the point is to make you capable, not to make them a dependency. ### Running alongside, from this week — habits 06 ### Start measuring profitability now Small problems solved while they are small. **Unit economics before the user count grows.** 07 ### Use a voice model to interview yourself Two uses: a founder journal capturing what has actually been achieved, and a feedback method where beta users are interviewed by the model and send back the report. 08 ### Publish the story as it happens The decision, the fears, what gets learned. Marketing that carries the brand without being a sales pitch, because **at this stage the founder is the story.** ## Worth settling before you publish > **The licence is a commercial decision, not a technical one.** A permissive licence is simple and frictionless, and it gives away any claim on what others build with your work. A copyleft licence with a contributor agreement and a separate commercial licence keeps the option of a revenue share, and obliges resellers to stay current. **Decide which you want before the repo exists, because the licence is chosen at creation.**[Why this estate chose Apache-2.0 →](../practice/apache-vs-mit.md) > > **Trade marks and IP advice come first.** Everything up to the clean rebuild is safe while the repo is private. Inviting the first outside reviewer is the point of no return — which is also why [the trademark is one of the two things that actually decides survivability](../survivability/index.md), and the licence file is not. > > **The cost argument has a limit.** It holds well against a large organisation with no product team, where every step is a place the plan stalls. It holds far less well against a funded competitor that already has the team, the budget and the market. **Slowness is the moat, so it only protects you from slow competitors.** Against a fast one, [the moat is your velocity](../views/index.md#rate-not-wall) — a competitor who forks today gets your position, not your rate. ## Part five · What your past self would have called success Before the fear of being copied, there was a set of things that would have counted as winning. They are worth writing down, because they are all closer than the fear makes them feel. 1,000 site visits in the first months 1 first paying customer, converted Shipped live product with real users on it 100 paying users, target by year end ## Part six · What a week of this looks like, counted The handover from prototype to product is invisible from the outside unless you count it. A week of this work produces almost no new features and a great deal of the following. **Publishing the count is itself the discipline**, because you cannot quietly skip a week when the row has to be filled in. | Counted each week | What it is evidence of | |---|---| | **Releases tagged** | Versioned, dated, reversible. | | **Untrue claims removed** | Site audited against the working product. | | **Support channels live** | Where a user can reach a human. | ### Four habits that produce those numbers ### Audit the site against the product *Habit* Every claim that cannot be demonstrated comes down before the repo opens. *"Instantly"*, *"every time"* and *"your credits never expire"* are the usual casualties. ### Quote the cost as a ceiling *Habit* Show the price before the run, not after. A job can come in under the quote. It should never come in over it. ### Ask for keys at run time, store nothing *Habit* The data stays in the user's own environment. This is also the answer to every compliance question you will be asked later. ### Make the tests prove the claim *Habit* If the demo on your home page is not the real workflow, the build should fail rather than ship. ## The point of building in the open > Be the new generation of artist — the one who controls the master, not the one who was successful and never saw the money. Which is [the argument of this whole site](../views/index.md) at the scale of one founder: the code is not the moat, the execution is; opening it costs you far less than the fear says and buys you a pitch, a discipline and a story; and what you keep — the trademark, the velocity, the relationship with the people who pay — is what was ever worth keeping. > **Provenance.** Prepared from a recording of the strategy call, transcribed and edited in Audio Genius, and first published as an infographic. Released under a Creative Commons CC BY licence. **Attribution: Dinis Cruz and Kate Curtis-Evans.** Details of the founder's product are theirs to tell; the reasoning is published here because it applies to every solo founder asking the question at the top of this page. ## Where to go next ### [Run the stress test on a vendor](../survivability/stress-test.md) *The tool* Before you depend on somebody else's open source: four questions, all answerable from public artefacts, about who could change the terms and what would stop them. ### [Why Apache-2.0 rather than MIT](../practice/apache-vs-mit.md) *The licence* The patent grant, the defensive termination clause, the NOTICE file — and the cost, which is that Apache-2.0 is the heavier licence to comply with. ### [Publish the source next to the render](../practice/publish-the-source.md) *The mechanism* Step eight, done properly: every page of this site is also its own markdown, so what is published is the source and not only the rendering of it. [← Front page](../index.md)[The position →](../views/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /views/index.html (markdown twin: /views/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/views/index.html* > Technology is not the moat; lock-in relocates to quality, certification and maintainability; lock-in degrades your own architecture; and open source frees you to cannibalise your own code. The full position, each argument with its counter-case attached. --- # The position Most arguments for open source are arguments about generosity. This is not one. The claim here is narrower, harder, and more useful to anyone actually deciding: **open source is a strategy that wins on economics and structure**, and the reasons it wins have almost nothing to do with whether anyone contributes back. > "the power of open source is not for the community, it is not because it is nice for others, and it is not to give back." That sentence is deliberately unfashionable. It is also the load-bearing one, because everything downstream depends on which framing you accept. If open source is a gift, its funding crisis is a moral failure and the remedy is to shame people into paying. If it is a strategy, the funding crisis is an **externality** — and externalities are corrected by structure and market forces, never by virtue. [cURL is where that stops being theory](../funding/curl.md). ## 1. Not free. Freedom — and somebody is always paying > "open source is not free, somebody is always paying for it. What you get from open source is freedom, that is different… We play the game of empowering the user and being the reputable source of trust. **We are selling trust.**" The second half of that is the part people skip. If the code is free and the freedom is the product, then what remains to sell is *trust* — being the reputable source, the party who knows the thing, the one you call when it breaks at 3am. That is a real commercial position and it is not a weaker one than owning the copyright. And the first half is measurable rather than rhetorical: > "It is not free to take a piece of open source and run it in your environment, because somebody is always paying for people… They will not fully understand it, and the more time they spend, the more it costs." > **The counter-case.** This framing is comfortable for a vendor and uncomfortable for a maintainer. A solo maintainer of a package with a million downloads is "always paying" in the sense that *they* pay and nobody else does. The argument describes the cost honestly and then locates the remedy in market design rather than obligation — which is right, and which is also very convenient for the people who currently benefit. [The funding page takes that objection seriously →](../funding/index.md) ## 2. Technology is not the moat, and pretending otherwise is expensive > "it allows for the removal of the idea that technology is the moat, more and more technology and software is not the moat, technology gets recreated, gets customised." This is now close to a consensus view among people who have watched a competitor rebuild their differentiator in a quarter. What is *not* consensus is where the moat goes instead, and the answer here is specific rather than vague: > "the lock-in is not on the technology, the lock-in is in **the quality and the services and the new versions and the maintainability and the certification of versions**." Note what that list has in common. Every item is something you have to keep being good at. None of them can be acquired once and held. That is the difference between a moat that decays into rent extraction and one that requires you to stay useful — which is why the same document is blunt about the alternative: > "As soon as you move into rent extraction, you lose sight of it: you are playing the game of making it less expensive to keep you than to leave, and then they leave with pain. I do not want us to fall into that." ## 3. The moat is a rate, not a wall The obvious objection to publishing everything is that a competitor takes it. The answer is the sharpest formulation the author has given: > "A competitor who forks our code today gets our position as of today. **They do not get our velocity.**" / "The code is open source. The execution is not forkable." And the related claim, which is more contestable: > "Anyone competing closed-source can copy and re-implement and leverage the LLM capabilities, but they will not have the users and the adoption." > **Where this is weakest.** "They do not get our velocity" is true right up until they do. It is an empirical claim about a specific team at a specific moment, dressed as a structural one. A fork by a party with more engineers than you is exactly the scenario where it fails — and the honest version of the argument is that *velocity is a defensible moat only while you actually have more of it*. That is a reason to keep shipping, not a licence to relax. ## 4. Lock-in degrades your own architecture This is the most unusual argument on the site, because it makes the case against lock-in on *engineering* grounds rather than ethical ones: > "you introduce attrition, and by introducing attrition you create much worse architectures, because there is a lot of simplicity when you do not have copyrights, licensing, and restrictions." Anyone who has watched a codebase grow a licensing boundary knows the shape of this. The boundary is never where the engineering wants it. Modules get split to keep something proprietary, interfaces get widened to avoid exposing an internal, a clean refactor gets vetoed because it would move code across the line. The licence stops being a legal artefact and starts being an architectural constraint — and it is a constraint chosen for reasons that have nothing to do with the system. ## 5. Open source frees you to delete your own code > "it makes you more motivated, and with less false sense of ownership, to cannibalise your own code or remove code you had, because it is open source, the code does not particularly have value" Short, original, and true. Sunk-cost attachment to code is partly an ownership illusion, and open sourcing dissolves some of it: the code is out there, it is not going anywhere, anyone who wants the old version has it. What is left is the question of whether it should still be in your tree — which is the only question that was ever worth asking. ## 6. It is the right strategy even with zero contributions > "even if there are no contributions, no external people submitting code and patches, and there is a lot of AI slop now, with even open-source repos not accepting submissions because of the mess… open source is still the right strategy" > "even with zero contributions, being open dramatically simplifies the tech stack… If you are the creator and maintainer of the core technology, the core ideas, the core standards, there is crazy value, and that is where we want to play." This is the position at its most consistent, and it is what makes the rest coherent: if you never expected contributions, then the collapse of the contribution model is not an argument against you. It is also the position's largest cost, and the site states it as one rather than hiding it. > **The tension, named.** A project that expects no contributions has less to say about running one — governance, review, codes of conduct, DCO-versus-CLA *in practice*. And the [survivability argument turns on exactly that distinction](../survivability/index.md). It is why that argument is shipped as a test answerable from public artefacts rather than as advice about community, and why [the community question is on the open list](../roadmap/index.md#community). ## 7. Burden of proof sits with the sceptic > "I am yet to see evidence that open source is a deterrent to the business. All the evidence is that it is only a problem when companies shoot themselves in the foot." Stated that way it is a challenge rather than a proof, and it should be read as one. The [success stories](../history/stories.md) are the evidence offered; [the relicensing wave](../history/index.md#reversals) is the strongest evidence against, and the site's answer to it is [structural rather than dismissive](../survivability/index.md) — those companies did not fail because they were open, they moved because a single copyright holder could. ## 8. The rising tide, and its unresolved version > "you want to build a model where the better your competitors are, the better you become, and open source is the key element of that strategy." Applied to hyperscalers, the author argues this both ways *in one document* and leaves it open — *"you want the hyperscalers to adopt and embrace these technologies, because they open up the market"* against *"Hyperscalers could commoditise it. Their embrace opens the market but could also absorb it."* Left unresolved here too, deliberately. It is a genuine open question about scale, not a rhetorical balance: the same adoption that creates your market can eat it, and which one happens depends on facts not yet in evidence. [It is on the open-questions list →](../roadmap/index.md#open) ## The arguments that carry their own pages ### [Sovereignty requires open source](sovereignty.md) *Four steps* One SLA away from losing access, schemas that matter as much as code, and jurisdiction as the thing you actually lose. Necessary, but not sufficient. ### [Open core, or packaging?](open-core.md) *Position moved* "There should be nothing proprietary" and "customers only have a subset" — five weeks apart. The test that settles which one this is. ### [Somebody has to be the villagers](villagers.md) *The market* Maintaining the non-functional requirements as a market, and both of its counter-arguments — including the one that says some of this should be retired rather than hardened. ### [Survivability is not a licence property](../survivability/index.md) *The best idea* It is a property of the copyright and trademark structure — and the evidence is every relicensing between 2018 and 2024. [← Front page](../index.md)[Sovereignty →](sovereignty.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /views/sovereignty.html (markdown twin: /views/sovereignty.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/views/sovereignty.html* > A four-step argument: open source is the only structure under which independence is possible; the data schemas matter as much as the code; without ownership you are one SLA away from losing access; and company nationality is not sovereignty, because acquisitions move it. --- # Sovereignty requires open source Four steps, each one a claim you can disagree with separately. The argument is tight and it is **not** a claim that open source guarantees sovereignty — the site is careful about that distinction throughout, and the fourth step is where it connects to [the survivability argument](../survivability/index.md) and becomes the same argument at a different scale. ## Step 1 — Only open source makes independence possible at all > "it is only when the code is open source that there is a possibility and the ability to have independence and sovereignty. Because **if you suddenly get cut off from the service, at least you have a chance**. That is why you have to have open source in order to have sovereignty." Note the modesty of "at least you have a chance". The claim is about *possibility*, not outcome. Having the source does not mean you can run it, maintain it, or afford the people who could — it means the option exists rather than not existing. Every stronger version of this claim is wrong, and the author does not make one. ## Step 2 — The schemas matter as much as the code, and access is not control > "**the data schemas are as important as the code.** Sometimes you say the data is open, you have access to the data, but you do not have access to the code or the schemas. And by access I mean you need to be able to **control** it, to **own** it." This is the original move in the argument and the one most often missed. "Data portability" regimes generally guarantee that you can *get* your data — as an export, in a format the vendor chose, with a structure documented to whatever degree the vendor found convenient. That is access. It is not control. A schema you did not define and cannot change is a dependency exactly as binding as a binary you cannot recompile, and it is the one nobody audits. The practical consequence is a question worth asking any vendor: *is the schema separately licensed, and under what?* It is the third leg of [the stress test](../survivability/stress-test.md) for precisely this reason. ## Step 3 — Without ownership you are one SLA away from losing access > "without owning it you are dependent on service-level agreements, so **you are one SLA away from losing access**. And… whichever government has jurisdiction and control over the company that controls the code controls the other countries. It is literally that simple." The second sentence is the one that has stopped being abstract. Jurisdiction over a supplier is jurisdiction over everyone downstream of that supplier, and this is now a live procurement consideration rather than a thought experiment. The argument does not require any particular geopolitical view to work — it only requires that jurisdictions can act, which is not in dispute. ## Step 4 — Company nationality is not sovereignty > "who owns a company is already very fuzzy… especially with acquisitions you lose control. **A European company gets acquired by a US company and the sovereignty moves, you lose it.**" > **This step is the survivability argument.** "A European company gets acquired and the sovereignty moves" and "a single copyright holder gets acquired and the licence changes" are the same mechanism at two scales — one about a country, one about a project. Saying so makes both stronger, and it is why the [stress test's four legs](../survivability/stress-test.md) are the practical form of a sovereignty question. **Buying from a company incorporated in your jurisdiction protects you exactly until someone buys the company.** ## The standard objection, and the answer The reflexive objection to any of this is that it will stifle innovation. The answer given is not a defence of open source so much as a reframing of what is actually being protected: > "I do not buy that this will stifle innovation, because the work is there. It is a question of whether there is a **rent-extraction process** happening, which is what proprietary software provides." The work — the engineering, the invention, the people — does not disappear when the rent does. What disappears is the rent. Whether that reduces the incentive to do the work is the real question, and it is an empirical one that this argument asserts rather than settles. ## Where this argument is weak | The objection | How much it lands | |---|---| | **Open source is necessary but nowhere near sufficient.** Having the source of a system you cannot operate, on infrastructure you do not own, with no one on staff who can read it, is sovereignty on paper only. | **It lands fully** — and the author concedes it. This is why [the villagers argument](villagers.md) exists: the capacity to read and repair is the part that actually has to be bought, and nobody is currently funding it. [Sovereignty bounties are the proposed answer →](../funding/index.md#bounties) | | **The exit is theoretical unless someone has walked it.** "You have the source" is not a migration plan, and no organisation has budget for one they might never use. | **It lands**, and it is the strongest single idea on this site's response list — [fund the substitution side, not the supply side](../funding/index.md#bounties). Nobody currently does. | | **Sovereignty arguments are often protectionism with better vocabulary.** | **Sometimes true, and worth watching for.** The test is whether the argument would accept a foreign-owned open-source stack over a domestic proprietary one. This one would — the criterion is structural, not national, which is exactly what step 4 says. | | **Open source has its own single points of failure.** A commons maintained by seven volunteers is not obviously more sovereign than a vendor with a support contract. | **It lands hard**, and [cURL is the case in point](../funding/curl.md). The answer is not that the commons is safe; it is that its failure mode is visible and fixable by anyone, where a vendor's is neither. | [← The position](index.md)[Open core, or packaging? →](open-core.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /views/open-core.html (markdown twin: /views/open-core.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/views/open-core.html* > 18 June: there should be nothing proprietary. 17 July: customers only have a subset of the code that exists in the main repo. Five weeks apart, and the July document names the tension itself. Here is the one-question test that settles which one it actually is. --- # Open core, or packaging? The author's position on this moved between two dated documents, five weeks apart, and both are published here rather than tidied into one — because a site that shows its view moving as commercial pressure arrived is worth more than one that only publishes the settled version, and because **the July document names the tension itself**, which is the interesting part. Then the test that settles it. ## 18 June — nothing proprietary > "my line is that everything the company does, the code, the logic, the functionality, and the schemas, is open source. **There should be nothing proprietary.** You never have the temptation of the bait model, where some of the best features are locked behind proprietary stuff, **because the community always sees through it**." With a single, clearly-drawn boundary: > "The moment you have closed repos is the moment you do customisations for the customer, the moment you hit customer data… that becomes the natural place for proprietary, non-public information, because at that point **it is the customer's data and their strategy**." That is a coherent position with a defensible line: the boundary is the customer, not the feature set. Nothing that would be useful to a second customer is withheld from the first. ## 17 July — a subset of the main repo > "more and more we want situations where the **customers only have a subset of the code that exists in the main repo**, because of security, because of maintainability, because of complexity." And then, in the same document's own tensions table: > "Open source versus the customer subset \| A fuller main repo than the customer receives sits uneasily with a pure open-source claim; **this is open-core, and worth saying so plainly.**" > **Why this is worth publishing.** The July brief did not have to catch itself. It did, in its own words, in a table it wrote for the purpose — and then the position was never reconciled. That is a more useful artefact than a resolved statement would have been, because it shows the boundary moving under commercial pressure in real time, which is exactly what [2018–2024 demonstrated at industry scale](../history/index.md#reversals). ## The test that settles it There is a real reconciliation available, and it turns on a distinction the June brief did not need to make. From 4 June, the subset is framed as **subtraction, not withholding**: > "a company might only need 10% of them. So we create a version with only 10% of the features. It has **much less attack surface**, it is much cheaper to run" — "customisation is not only addition; it is subtraction… less attack surface… cheaper to run… maintainable." That is a genuinely different thing from open core, and the difference is testable in one question: > **Does the customer build contain anything the public repo does not?** > > **No** → it is **packaging**. A smaller build of public code, shipped for security and operability reasons. Every line the customer runs is public. Nothing is being held back; something is being left out. > > **Yes** → it is **open core**. And per the July brief's own instruction: *say so plainly*. The test is deliberately blunt because the failure mode is gradual. Open core rarely arrives as a decision; it arrives as a series of individually reasonable exceptions, each one made under revenue pressure, each one moving the boundary toward the vendor. A binary test applied at each release is the only thing that catches that, and it is the same discipline [the stress test](../survivability/stress-test.md) applies to a vendor from outside. ## Both sides of open core, fairly | The case for | The case against | |---|---| | It is the only model that has repeatedly funded large-scale development **without rent extraction on the core**. The core stays genuinely open, genuinely forkable, genuinely usable by people who will never pay — and somebody pays the engineers. | The boundary **always moves toward the vendor under revenue pressure**. That is not cynicism; it is what 2018–2024 recorded. The mechanism is the same every time, and no company has ever announced in advance that it intended to move the line. | | **VS Code is the strongest live example done well** — MIT core, and an ecosystem that is real. It is difficult to argue that the world would be better off if it had not been built this way. | And it is the strongest example of the cost: a proprietary shipped binary, a licence-restricted marketplace, and **most of its very large user base does not know it is running proprietary software**. Executed smoothly enough that the boundary is invisible, which is precisely the problem. | ## Where this leaves the position Unresolved, and marked as such. The June statement and the July statement are both on the record; the test above is the site's proposal for settling it, and applying it is a decision for the project rather than for this page. [The self-audit is where that decision will have to be made in public](../survivability/self-audit.md), because the same question — *what does the customer actually get, and how does it differ from what is published* — is leg one of a stress test we are running on ourselves. > **Related, and next.** Whether the reconciliation holds in practice is best read against [why each of the estate's projects was open-sourced](../roadmap/index.md#interview) — six published projects, and retrospectives on the build order. [← Sovereignty](sovereignty.md)[Somebody has to be the villagers →](villagers.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /views/villagers.html (markdown twin: /views/villagers.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/views/villagers.html* > Maintaining the non-functional requirements — version control, reliability, resilience, security, backups, consistency, explainability, documentation — as a market, and the ability to read and repair code somebody else wrote as an appreciating scarce asset. Published with both of its own counter-arguments. --- # Somebody has to be the villagers The name comes from Wardley's Pioneers–Settlers–Town Planners pattern, which [wardley-maps.sgit.ai owns as a technique](https://wardley-maps.sgit.ai). What this page owns is the market argument built on top of it: **maintaining the non-functional requirements is a business**, the skill it requires is becoming scarce, and the mechanism that used to produce that skill is being taken apart at the moment demand for it is rising. ## The market, stated plainly > "the sweet spot is to find the economic value where it's cheaper for these companies to pay a third party to maintain what I call the **non-functional requirements**, which fundamentally is the whole version control, reliability, resilience, security, backups, consistency, explainability, and documentation." And the reason that market exists at all: > "**none of the people who are doing it know how, and they don't want to**, because they are focusing on the domain." That second quote is the whole business case in one line. The people building the applications are not bad at NFRs through carelessness; they are correctly allocating their attention to the domain, which is the thing only they can do. The NFRs are real work that somebody has to do and nobody wants to do — which is the classic shape of a service market, and it is why it is *villagers* rather than pioneers: this is the settlement work, not the exploration. The demand side is expanding fast, and for a specific reason: > "this market is going to grow exponentially because **every single team, every single department, every single function, even professionals, are going to create tons and tons of apps**." Explorers are now everybody. Every one of those applications will need version control it does not have, backups nobody configured, and a security posture no one reviewed — and each one was built by someone who solved a real problem and has no interest whatsoever in any of that. ## The appreciating asset > "The scarce asset in this market is **the ability to read and repair code somebody else wrote**." — "**Demand for a specific skill is rising sharply while the mechanism that produces that skill is being dismantled**, and firms with established engineers hold an asset that is appreciating rather than depreciating." The mechanism being dismantled is the junior pipeline, and that is [where this argument meets the other place the author's position moved](../agents/index.md#pipeline): in March the position was that the learning path was restructured rather than eliminated and the density of learning per hour *increases*; by July it was that apparent gains shifted work from juniors to seniors rather than removing it, and the pipeline is being disrupted at exactly the moment the maintenance need is growing. Both are on the record. Both are published. The July version is what this page's market claim rests on — which means **if March turns out to be right, this argument weakens considerably**, and that is worth saying out loud. ## The two counter-arguments — which the author raised himself These are not objections collected from critics. They are in the original brief's own honest-tensions table, and leaving them in is what makes the rest of the page trustworthy. > **1. The scarce-asset argument versus how long it lasts.** > > > "Tooling for reading and repairing unfamiliar code is improving quickly, and **the advantage may be a window rather than a moat**." > > This is the objection that most threatens the business model, and it is a genuinely open empirical question. If code comprehension is one of the things agents get reliably good at, then "can read somebody else's code" stops being scarce quite fast, and the appreciating asset depreciates on a schedule nobody can currently forecast. The honest position is that the window is real and its width is unknown. > **2. Maintaining what should not have been built.** > > > "Some of these applications should be retired rather than hardened, and **a firm paid to maintain has no incentive to say so**." > > This is the sharper objection and it is a structural conflict of interest, not a risk of bad behaviour. A maintenance business is paid per thing maintained. The advice "delete this" is the one recommendation that costs the adviser money every time it is right. Nothing in the business model corrects for it, and any honest version of this service has to say what it does about that — a question this page raises and does not answer. ## A note on the numbers > **Deliberately absent.** The original brief carries a market-size statistic and several figures attributed as *"reported"* and *"is cited as finding"* — and it flags, itself, that *"much of what circulates is vendor commentary recycling a smaller set of underlying studies."* They are not reproduced here. The direction of the argument does not depend on them, and [this site's position is that you do not publish a number you cannot source](../history/numbers.md) — a standard it holds others to, so it does not get an exemption. ## Where this sits in the network Wardley's Pioneers–Settlers–Town Planners pattern belongs to [wardley-maps.sgit.ai](https://wardley-maps.sgit.ai), which owns the mapping technique and the pattern itself. This page owns the NFR-market argument built on it. One canonical copy each, cross-linked — the split is deliberate, and it is the same discipline applied to [standards.sgit.ai](https://standards.sgit.ai) for SPDX (they own the machinery, this site owns [the argument about running it continuously](../agents/index.md#compliance)). [← Open core, or packaging?](open-core.md)[Survivability →](../survivability/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /survivability/index.html (markdown twin: /survivability/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/survivability/index.html* > Every catalogued relicensing between 2018 and 2024 followed the same legal pattern: a single corporate copyright holder, having aggregated contributor copyright via a CLA, exercised the right to change terms going forward. Distributed-copyright projects could not be moved the same way. --- # Survivability is not a property of the licence file This is the best original idea on the site, and the most immediately useful, because it tells a buyer to stop reading the thing everyone reads and start reading the two things almost nobody does. > "Survivable is not a property of the licence file. **It is a property of the copyright and trademark structure.**" ## The mechanism — which is what makes this a finding, not an opinion > "An OSI licence is irrevocable for code already published, but the copyright holder may ship the next version under different terms. **Every catalogued relicensing between 2018 and 2024 followed the same legal pattern: a single corporate copyright holder, having aggregated contributor copyright via a CLA, exercised the right to change terms going forward. Distributed-copyright projects could not be moved the same way, because no single party had standing.**" Read that carefully, because both halves matter and the first half is what people get wrong. **The licence you already have cannot be taken away.** That is real, and it is the thing the licence file genuinely guarantees. What the licence file does *not* tell you is anything at all about who can decide the terms of the *next* release — and for anyone who intends to keep using a dependency rather than freezing it at a version, that is the only question that matters. Whoever holds the copyright decides. So the buyer's question is not "what licence is this?" It is **"who could change it, and what would stop them?"** ## Why the CLA is the mechanism A Contributor Licence Agreement that assigns copyright — or grants a licence broad enough to relicense under — aggregates into one entity the standing that would otherwise be distributed across every contributor. That aggregation is usually presented as administrative hygiene, and it genuinely does solve real problems (provenance, the ability to defend the project, the ability to fix a licensing mistake). It also creates, as a side effect, **the single party capable of moving the project**. A DCO — a sign-off attesting you had the right to contribute, with no assignment — does not. Under inbound=outbound, contributors licensed their work to the project under the project's licence, and nobody acquired the standing to change it for everyone. That is the whole difference, and it is visible in a repository from outside. > **This is not an argument that CLAs are bad.** It is an argument that a CLA is a *load-bearing structural fact* that a buyer should price, and that "we use a CLA" and "we could relicense" are the same sentence. [Leg one of the stress test asks for it →](stress-test.md) ## Acquisition entrenches the closure — it does not reverse it > "**HashiCorp went BUSL, IBM acquired it, and the licence stayed.**" This is the kicker, and it disposes of the most common hope. The optimistic story is that a relicensing is a phase — a cash-strapped company under pressure, and a bigger, more comfortable owner will revert it. It did not happen. Terraform went BUSL in August 2023; IBM's acquisition of HashiCorp closed on 27 February 2025; the licence stayed. **Acquisition changes who holds the standing, not whether the standing exists.** Where the structure permits closure, closure survives ownership changes in both directions. ## The control case and the counter-case | | PostgreSQL — the control case | OpenSolaris — the counter-case | |---|---|---| | **Copyright structure** | **Distributed.** No company owns it | **Sun retained it**, with governance to match | | **Could it be relicensed?** | **No party has standing** to do it | **Yes** — and the licence was deliberately chosen to be GPL-incompatible | | **What happened** | Survived the entire relicensing wave untouched. Now **the most-used database** — 55.6% of developers | **Killed by Oracle after the acquisition.** The community forked to illumos | | **The lesson** | **The licence was not the problem; the copyright holder was.** OpenSolaris was under an OSI-approved licence the whole time. Being open source did not save it, because being open source was never the property that decides this. | | And note the second half of the OpenSolaris story, because it is the point of [leg four](stress-test.md#leg4): **illumos survives.** Fork capacity mattered, and it mattered because a named party with the ability to run it actually existed. "The community would fork it" is not a plan; illumos was. ## The update that sharpens the argument Two of the four relicensings partially reversed after the original argument was written. Elastic added AGPLv3 in August 2024; Redis 8 shipped under AGPLv3 around 1 May 2025. MongoDB remains SSPL; Terraform remains BUSL inside IBM. > **That does not weaken the argument. It sharpens it.** The same single-holder standing that let them leave is what let them come back. Nobody had to negotiate with thousands of contributors in either direction. **Structure determines what is possible in both directions** — and a project that can be closed by one party's decision can be reopened by one party's decision, which is a description of dependence, not of safety. One precision worth keeping: **none of the four went closed source.** They went *source-available* — SSPL, BUSL, and similar. The code remained readable; the freedoms did not remain. Conflating the two is the most common error in commentary on this period, and it makes the situation sound both better and worse than it was. ## What to do with this ### [Run the Change-of-Control Stress Test](stress-test.md) *The tool* Four legs, all answerable from public artefacts, requiring no cooperation from the vendor. Answer them here and keep the result — nothing is sent anywhere. ### [We run it on our own estate](self-audit.md) *The self-audit* A tool whose author will not apply it to themselves is a marketing asset. Here is the result on each of the four legs, what changing it would take, and which changes are planned. ### [Sovereignty, at a different scale](../views/sovereignty.md) *The same argument* "A European company gets acquired and the sovereignty moves" is this argument applied to a country instead of a project. Saying so makes both stronger. [← The position](../views/index.md)[The stress test →](stress-test.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /survivability/stress-test.html (markdown twin: /survivability/stress-test.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/survivability/stress-test.html* > Four legs — copyright structure, trademark holder, schema licence, named fork capacity — every one answerable from public artefacts without the vendor's cooperation. Answer them here and keep the result. A vendor that cannot answer them has answered them. --- # The Change-of-Control Stress Test Four questions to ask about any open-source dependency you are betting on. Every one is answerable from **public artefacts** — a repository, a licence file, a trademark register, a foundation charter — which means you can run this without the vendor's cooperation, without a procurement process, and without telling anyone you are doing it. > "The stress test is a query, not an interview. 'Show me the CLA' and 'show me who holds the trademark' are answerable from public artefacts, and **a vendor that cannot answer them has answered them.**" > **This runs entirely in your browser.** Nothing is sent anywhere — there is no server, no analytics on your answers, and no account. Your answers are kept in this browser's local storage so the page remembers them if you come back, and the **Copy the result** button gives you a markdown summary to paste into your own notes. Clearing the form removes them. **What are you assessing?** 1. ### Leg 1 Copyright structure Who holds copyright in the code, and could one party relicense the next release? PassesDCO / inbound=outbound, copyright distributed across contributors. No single party has standing to change the terms. FailsA single-entity CLA aggregating contributor copyright — or one company simply wrote it all. UnclearYou could not find out from public artefacts. **Where to look:**`CONTRIBUTING.md`, a `CLA.md` or CLA-bot check on pull requests, `Signed-off-by:` lines in the commit log (a DCO signal), and the copyright headers in source files. **Unclear is not neutral** — see the verdict note below. 2. ### Leg 2 Trademark holder Who owns the name, and what would stop them using it against a fork? PassesHeld by a neutral foundation, with charter-level restrictions on transferring it. FailsHeld by the operating company, transferable with the company. UnclearNo trademark policy published, or the holder is not stated. **Why it is a separate leg:** a fork can take the code and cannot take the name. Losing the name means losing the search results, the documentation people have bookmarked, the package identifier, and the recognition a new user needs to find you at all. **Trademark is how a fork is made expensive even when it is legally permitted.** 3. ### Leg 3 Schema licence Are the data schemas and formats licensed separately, and openly? PassesCC0 or CC BY, licensed *separately* from the code. FailsUndeclared, or silently bundled with the code licence. UnclearYou could not establish what governs the schemas. **The leg everyone skips.**[The schemas matter as much as the code](../views/sovereignty.md#step2): your data is only portable to the extent that its structure is something you may reimplement. A schema bundled with a code licence that later changes moves with it — and an undeclared schema is a dependency with no terms at all. 4. ### Leg 4 Fork capacity If the terms changed tomorrow, who would actually run the fork? PassesA **named party** with the headcount and the mandate to run it. You can say who. Fails"The community would fork it" — with no named party. UnclearThere are candidates, but none with a stated mandate. **The test is whether you can name them.** illumos existed and OpenSolaris users had somewhere to go; OpenTofu and Valkey existed within weeks because organisations with engineers decided to fund them. A fork is not a right that gets exercised automatically — **it is a payroll**, and if nobody's payroll is available, the right is theoretical. Answer the four legs to see the verdict. Copied. ## How to read the verdict **This is not a score.** Four passes does not mean "safe" and one fail does not mean "avoid" — plenty of excellent software fails legs one and two, including software you should absolutely keep using. What the four legs tell you is **what kind of exposure you are carrying**, so you can price it, plan for it, or decide it does not matter for this dependency. A single-holder project you use for something easily replaced is a fine risk. The same structure under something with your data in it, five years of integration around it, and no named fork capacity is a different proposition entirely — and the point of the test is that you find that out *before* the announcement rather than during it. > **"Unclear" is an answer.** Every one of these legs is answerable from public artefacts. When a project's own materials do not let you determine who holds copyright, who owns the name, or what governs the schemas, that opacity is itself the finding — and it is the finding for a project whose whole proposition is openness. *A vendor that cannot answer them has answered them.* ## Why we do not publish scores for named vendors We ship the test; you run it. Publishing a scorecard about named commercial projects would turn a diagnostic into a weapon, and it would be a weapon wielded by [a participant in the same market](../about/index.md#interests) — which is exactly the conflict the test is designed to let you route around. The four legs work without us. The one exception is running it on our own estate, in public. [That is the self-audit →](self-audit.md) [← Survivability](index.md)[The self-audit →](self-audit.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /survivability/self-audit.html (markdown twin: /survivability/self-audit.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/survivability/self-audit.html* > The Change-of-Control Stress Test run against the sgit estate itself, with the same four legs and the same evidence rules: the result on each leg, what changing it would actually take, and which changes are planned. --- # We run the test on our own estate A tool whose author will not apply it to themselves is a marketing asset. One who does is a standard. So here is [the Change-of-Control Stress Test](stress-test.md) run against this project's own estate, with the same four legs and the same evidence rules — the result on each, what changing it would take, and which changes are planned. > **The short version.****The estate's copyright is held by one company** — the single-holder pattern the [survivability argument](index.md#mechanism) identifies as the mechanism behind every catalogued relicensing between 2018 and 2024. Applied to us, the test says so, for the same structural reason it says so of the projects we cite. That is the result a single-founder company with no external contributors should expect, and the useful part of this page is the second half: what each leg would take to change, and which of those changes are on the build order. ## The four legs | Leg | Result | The evidence, and what it means | |---|---|---| | **1 · Copyright structure** | Fails | Copyright is held by **a single company**. There is no distributed-copyright structure and no DCO regime with independent contributors behind it — which is partly a consequence of [the position that open source is right even with zero contributions](../views/index.md#zero-contributions). That position is coherent, and this is its structural cost: a project with no external contributors has, by construction, no distributed copyright. **One party could ship the next release under different terms.** Nothing structural prevents it. | | **2 · Trademark holder** | Fails | Held by the operating company, transferable with the company. There is no neutral foundation and no charter-level restriction on transfer. A fork could take the code and could not take the name — the same asymmetry the test asks you to check for in anyone else. | | **3 · Schema licence** | Partial | The stated position is unambiguous — *"The customer's schemas can be closed, a lot of their data is closed, **but our schemas are open**"* — and [the argument that schemas matter as much as code is ours](../views/sovereignty.md#step2). What is missing is the artefact: the schemas are not **separately licensed** with their own declared terms in the way leg three asks for. The intent passes; the paperwork does not yet exist. This is the cheapest of the three to fix and it is not fixed. | | **4 · Fork capacity** | Fails | There is no named party with the headcount and mandate to run a fork. Honestly: there is no community to be the unnamed party either, so this is not even the *"the community would fork it"* answer the test flags as failing — it is the answer below that one. The code is Apache-2.0 and genuinely forkable; **nobody is standing by to fork it**. | > **Result, by our own tool: single-party dependent.** Three legs against, one partial. This is the pattern every relicensing in the 2018–2024 wave followed. It does not mean this project will be relicensed. It means **nothing structural would stop it**, and that an acquisition would carry the standing along with the company — which is exactly what we say about everyone else, and it is exactly as true here. The code already published is Apache-2.0 and stays that way whatever happens; the result is about the terms of the *next* release. ## Why publish this Three reasons, in order of how much they matter. **Because the test would be worthless otherwise.** The whole proposition of a four-leg test answerable from public artefacts is that it does not depend on the assessor's goodwill. An assessor who exempts themselves has demonstrated that the test is a marketing instrument dressed as a diagnostic, and every reader is right to discount it accordingly. **Because it is the same discipline the author already applies elsewhere.** His own listed tension about publishing security reviews reads: *"It is unusually transparent and **it publishes your own weaknesses to an audience that includes people looking for them**."* That cost is real. It is also the reason the transparency claim is worth anything at all. **Because the honest answer to "will you fix it?" may be no** — and that is still publishable, and still more useful than silence. ## What would have to change, and whether we intend to | Leg | What fixing it actually requires | Position | |---|---|---| | **1 · Copyright** | Either move copyright to a neutral entity, or adopt a DCO with inbound=outbound and accumulate enough independent contribution that no single party retains standing. The first is a legal step available now; the second cannot be done unilaterally and is **years of other people's work**. | **Not resolved.** A single-founder company with no external contributors cannot distribute copyright by deciding to. Moving it to a foundation is possible and has costs — governance, control, the ability to relicense for a customer, which is [an existing commercial mechanism](../views/open-core.md). **No decision has been taken, and pretending one has would be worse than saying so.** | | **2 · Trademark** | Transfer to a neutral holder, or publish a trademark policy that states what a fork may and may not call itself. | **Not done.** The second half — **publishing a policy** — costs almost nothing and removes the worst of the ambiguity even while the holder stays the same. It is the clearest unforced gap on this page. | | **3 · Schemas** | Declare the schemas under their own licence (CC0 or CC BY), separately from the code, in the repositories that define them. | **Should be done, and is the cheapest.** The position is already stated; the artefact is missing. It is on [the build order](../roadmap/index.md), and there is no good argument for its not being done. | | **4 · Fork capacity** | A named third party with engineers and a mandate. | **Not in our gift**, and worth being blunt about: **this leg is not fixable by the project it is about**. It is a fact about the world outside the project. Any vendor claiming to pass leg four on its own say-so should be treated with suspicion — including us. | ## What this does not concede Failing the test is not a confession that the model is wrong; it is the model working. The four legs describe **exposure**, and the exposure described here is real, priced, and now public. What a reader should take from it: - The code is **Apache-2.0 and already published**. The licence you have cannot be withdrawn — [that is what the licence file genuinely guarantees](index.md#mechanism), and it is not nothing. - What is not guaranteed is the terms of the *next* release, and no assurance from us changes that. **Structure is what changes it**, and the structure is what this page is about. - Every argument on this site about the risk of single-holder projects **applies to this one**. Readers should discount accordingly, and the discount is the honest price of the argument. > **What this page does not yet cover.** It audits *structure*. An SBOM of the estate, a licence-scan result and an upstream-contribution record — the things the site argues companies should publish — are [first on the build order](../roadmap/index.md#supply-chain), and will be linked from here when they ship. [← The stress test](stress-test.md)[The history →](../history/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /history/index.html (markdown twin: /history/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/history/index.html* > Unix circulated because it was illegal to sell it. BSD lost to litigation risk, not its licence. Netscape's release was a six-year near-failure. Christine Peterson coined open source. Eyeballs are not a security property. And two of the four relicensings reversed. --- # Six corrections Everyone has a timeline. [So does this site](timeline.md) — but it sits behind these, because the corrections are the part almost nobody publishes and they are the part that matters. Each one is checkable. And every one of them points the same way: **the model succeeds on economics and structure, not on virtue and not on eyeballs.** > **Why this section leads.** The author's own writing on open source is about strategy and structure, not history — it argues from what companies and projects actually do, not from the movement's story about itself. So the history was [researched for this site from primary sources](../documents/index.md), 1955 to 2026, with every claim carrying its source and date. The finding that shaped everything else is that **the accurate history is a better argument than the romantic one**. ## 1. Unix circulated because it was illegal to sell it The founding act of the sharing culture is usually told as generosity: Bell Labs gave Unix away to universities, a gift culture formed, everything follows. The mechanism was regulatory. The **1956 AT&T consent decree** barred Bell Labs from any line of business except common-carrier communications. Selling software was not available to them. Unix shipped for the cost of media and postage as a **compliance artefact** — the cheapest lawful way to let it out of the building. Universities got the source because there was no commercial channel that AT&T was permitted to build. And the control experiment ran itself: **the decree was lifted in 1982, and AT&T commercialised System V immediately.** The moment the constraint was removed, the behaviour reversed. That is not a story about culture. It is a story about what an organisation was allowed to do. ## 2. BSD lost to litigation risk, not to its licence The permissive-versus-copyleft debate frequently invokes BSD as the case study: BSD was permissive, companies took it private, BSD lost, therefore copyleft. The chronology does not support the inference. **USL v. BSDi ran from April 1992 to February 1994** — precisely the window in which a free Unix could have become the default and Linux was starting from nothing. During those two years, adopting BSD meant adopting an unresolved lawsuit over your operating system. Linux carried no such cloud. Then the settlement: **three files were removed out of eighteen thousand**, and copyright notices were added to about seventy. The claim was, in substance, nearly empty. **The uncertainty was what did the damage**, and the uncertainty had two years to work. Linux's victory is, in part, a litigation artefact — which says nothing about the merits of either licence and a great deal about how technology choices actually get made. ## 3. Netscape's source release was a six-year near-failure This is the founding case study of the open source movement, and it is a cautionary tale. Announced 22 January 1998, released 31 March 1998. The code was in such poor condition that the team eventually **threw it away and rewrote from scratch**. Netscape 6 shipped in November 2000 and was not good. **Firefox 1.0 did not arrive until November 2004** — six and a half years after the release — by which time Internet Explorer had comprehensively won the browser war the release was intended to fight. Firefox went on to matter enormously, so this is not a story of failure. It is a story about **what opening a codebase does and does not do**. It does not summon a bazaar to fix a codebase nobody can work in. Releasing source is the beginning of a very long piece of engineering, and the romantic version of 1998 skips the six years in the middle. ## 4. Eric Raymond did not coin "open source" **Christine Peterson**, of the Foresight Institute, did — in the first week of February 1998. And the detail worth keeping is the tactic: she **deliberately had someone else introduce the term**, Todd Anderson, who had more credibility with the room as a Linux programmer, so that it would spread on its merits rather than stall on its source. Sources disagree on the exact day — OSI records 3 February; Peterson's own account describes 2 and 5 February — and the disagreement is worth stating rather than smoothing over. They do not disagree on who. It is a small correction with a large amount of the movement's self-image resting on it, and the reason to publish it is the same as the reason to publish everything else on this page: **the mythology is load-bearing, and it is wrong in checkable ways.** ## 5. "Given enough eyeballs, all bugs are shallow" is not a security property The most-quoted line in open source is a claim about development velocity that has been silently promoted into a claim about security. It does not survive the promotion. **Heartbleed** survived two years in OpenSSL — the most security-critical library on the internet, read by everyone, audited by nobody in particular. Jim Zemlin, running the Linux Foundation, put it exactly: *"In these cases, the eyeballs weren't really looking."* **xz is worse, and it is the case that should end the argument.** The backdoor was not missed by review — **it was engineered by the maintainer specifically to survive review**, by someone who had spent years earning the position from which to introduce it. It was found by Andres Freund, one engineer, who was **benchmarking SSH latency** and noticed the numbers were wrong. Not a security review. A performance investigation. Robert Glass had called the law a fallacy back in 2003, on the evidence that useful reviewers cap out at somewhere around two to four. Two decades of practice have not contradicted him. > **What this correction does not say.** It is not an argument that open source is less secure than proprietary software, and the comparison is not the point. It is an argument that **"many eyes" is not the mechanism** — visibility is a precondition for review, not a substitute for it, and a project's security comes from someone actually being paid to look. Which is [the funding argument](../funding/index.md), arriving from a different direction. ## 6. Two of the four relicensings reversed — and none went closed source The 2018–2024 relicensing wave is usually recalled as four one-way doors. Two of them opened again: - **Elastic added AGPLv3** in August 2024. - **Redis 8 shipped under AGPLv3** around 1 May 2025. - **MongoDB remains SSPL.** - **Terraform remains BUSL**, and HashiCorp is now inside IBM — the acquisition closed 27 February 2025. And the precision that most commentary loses: **none of the four went closed source.** They went *source-available*. The code stayed readable. The freedoms did not stay. Treating those as the same thing makes the period sound both better and worse than it was. > **This sharpens the survivability argument rather than weakening it.** The same single-holder standing that allowed them to leave is what allowed them to come back — nobody had to negotiate with thousands of contributors in either direction. **Structure determines what is possible in both directions**, and a project that one party can close is a project that one party can open. Either way you are describing dependence, not safety. [The argument in full →](../survivability/index.md) ## Where to go next ### [The timeline, 1955 → 2026](timeline.md) *Supporting material* Behind the corrections rather than in front of them, which is where a timeline belongs on a site whose argument is that the standard telling is wrong. ### [The success stories](stories.md) *Six, not fourteen* Linux, Let's Encrypt, SQLite, PostgreSQL, cURL, Blender — each chosen because it proves something argued elsewhere on this site, not because it is famous. ### [The numbers, and the ones to refuse](numbers.md) *Handle with care* The $8.8 trillion figure and what it actually measures; "70–90% of a codebase"; and the claims this site will not publish because the research could not source them. ### [Survivability](../survivability/index.md) *The consequence* PostgreSQL as the control case and OpenSolaris as the counter-case are history doing the work of an argument. [← The self-audit](../survivability/self-audit.md)[The timeline →](timeline.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /history/timeline.html (markdown twin: /history/timeline.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/history/timeline.html* > A sourced timeline of open source from the 1956 AT&T consent decree to the relicensing wave and its partial reversals — placed behind the corrections rather than in front of them, because the corrections are the part worth reading first. --- # The timeline, 1955 → 2026 Deliberately the second page in this section rather than the first. [The six corrections lead](index.md), because a timeline is a shape everyone already has and the corrections are the part that changes what you think. This is the supporting material — with a column for what each moment is *evidence of*, since a date on its own argues nothing. ## Before there was a name (1955–1991) | When | What happened | What it is evidence of | |---|---|---| | **1955–56** | SHARE, the IBM user group, forms and circulates code between installations. The **AT&T consent decree** (1956) bars Bell Labs from any business but common-carrier communications. | Sharing preceded ideology. The decree is the structural fact that made the next twenty-five years possible. | | **1969–1975** | Unix is written at Bell Labs and distributed to universities **for media and postage** — the only lawful channel available. | [Correction 1.](index.md#unix) A compliance artefact, not a gift. | | **1977–1980s** | Berkeley builds BSD on top of it; the Berkeley licence emerges as the permissive model. | Permissive licensing predates the debate about it by a decade. | | **1982** | **The consent decree is lifted.** AT&T commercialises System V immediately. | The control experiment. Remove the constraint and the behaviour reverses within months. | | **1983–1991** | The GNU project begins (1983); the GPL formalises copyleft (1989, v2 1991); the FSF is founded (1985). | Copyleft as a deliberate legal invention — a licence designed to make a structural guarantee the BSD licence does not attempt. | | **1991** | **Linux 0.01.** Relicensed to GPLv2 in 1992. | Arrives at the exact moment the alternative becomes legally uncertain. | ## The window that decided it (1992–1998) | When | What happened | What it is evidence of | |---|---|---| | **Apr 1992 – Feb 1994** | **USL v. BSDi.** Free Unix is clouded by litigation for two years. The settlement removes **three files out of eighteen thousand** and adds copyright notices to about seventy. | [Correction 2.](index.md#bsd) Litigation risk, not licence design, is what moved adoption. | | **1995** | Apache httpd released; the Apache Group forms (Foundation, 1999). | The first large-scale demonstration of **neutral-foundation governance** — which is [leg two of the stress test](../survivability/stress-test.md#leg2), working, thirty years before anyone needed the test. | | **Feb 1998** | **Christine Peterson coins "open source"** and has Todd Anderson introduce it. OSI founded shortly after; the Open Source Definition published. | [Correction 4.](index.md#peterson) | | **22 Jan / 31 Mar 1998** | Netscape announces, then releases, the Communicator source. The code is so degraded the team eventually rewrites from scratch. | [Correction 3.](index.md#netscape) Opening a codebase is the start of the engineering, not the end. | ## The commons becomes infrastructure (1999–2013) | When | What happened | What it is evidence of | |---|---|---| | **2000** | SQLite begins — public domain, and explicitly **not open-contribution**. | The case that inverts nearly every assumption on this page. [See the story →](stories.md#sqlite) | | **Jul–Sep 2002** | **Blender's community buys its freedom** out of bankruptcy: €100,000 in seven weeks. | The one case where the romantic version is simply true. [See the story →](stories.md#blender) | | **Nov 2004** | **Firefox 1.0.** Six and a half years after the Netscape release. | The other half of correction 3, and the reason to state the interval rather than the outcome. | | **2005** | Git is written to replace BitKeeper after its licence terms are withdrawn. | A licence withdrawal by a single holder producing, by accident, the most widely used developer tool in the world. **An early instance of the pattern the survivability argument describes** — and of what fork capacity looks like when it exists. | | **2008** | GitHub launches; the OWASP European Summit runs in the Algarve. | Distribution stops being the problem. [The summit thread starts here →](../owasp/index.md) | | **2010** | **Oracle acquires Sun. OpenSolaris is killed.** illumos forks and survives. | The counter-case for [survivability](../survivability/index.md#cases): an OSI-approved licence did not save it; a named fork party did. | ## Eyeballs, foundations, and the wave (2014–2026) | When | What happened | What it is evidence of | |---|---|---| | **Apr 2014** | **Heartbleed.** Two years undetected in OpenSSL. The Core Infrastructure Initiative follows. | [Correction 5](index.md#eyeballs), and the first industry-scale admission that critical infrastructure was unfunded. | | **2014–2015** | **Kubernetes** released by Google; CNCF founded 2015. | The clearest strategic use of open source in the industry's history: commoditise the layer below your business. [See the story →](stories.md#kubernetes) | | **Dec 2015 – 2025** | **Let's Encrypt** enters public beta. HTTPS page loads go from under 30% globally to roughly 80%, and to around 95% in the US; issuance reaches ~10 million certificates a day by September 2025. | The largest measurable civilisational impact on the list — and the mechanism was **automation, not price**. [See the story →](stories.md#letsencrypt) | | **2018–2024** | **The relicensing wave.** MongoDB → SSPL (2018); Elastic → SSPL/ELv2 (2021); Terraform → BUSL (Aug 2023); Redis → RSAL/SSPL (Mar 2024). OpenTofu and Valkey fork within weeks. | The event the whole [survivability argument](../survivability/index.md) is built from. Every one: **a single corporate copyright holder with the standing to move.** | | **Aug 2024 – May 2025** | **Elastic adds AGPLv3; Redis 8 ships AGPLv3.** IBM's acquisition of HashiCorp closes 27 Feb 2025 — **and Terraform stays BUSL.** | [Correction 6.](index.md#reversals) Structure works in both directions, and acquisition entrenches rather than reverses. | | **Mar 2024** | **The xz backdoor** — engineered by the maintainer to survive review, found by one engineer benchmarking SSH latency. | The strongest single refutation of the eyeballs claim, and of social-trust models generally. | | **Jan 2026** | **cURL announces its bug bounty will close** on 31 January, after ~20% of 2025 submissions were AI-generated slop against ~5% genuine. | The story that belongs to this site more than any other. [Read it →](../funding/curl.md) | > **On sourcing.** This timeline is compiled from [the research document published with this site](../documents/index.md), which reports its fetch failures inline rather than working around them. Where dates are contested — the coining of "open source" is the clearest case — [the disagreement is stated](index.md#peterson) rather than resolved by picking one. Items the research could not verify from a primary source are **not on this page at all**; [they are listed as unverified](numbers.md#unverified). [← Six corrections](index.md)[Six success stories →](stories.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /history/stories.html (markdown twin: /history/stories.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/history/stories.html* > Linux, Let's Encrypt, SQLite, PostgreSQL, cURL and Blender — six, not fourteen, each chosen because it carries an argument made elsewhere on this site. Plus Kubernetes and VS Code, which complicate the picture honestly. --- # Six success stories Fourteen were researched. Publishing all fourteen at equal weight produces a listicle, so these are the six that **carry an argument made elsewhere on this site** — including one that inverts nearly every assumption the rest of the site runs on, and one that is here because it is currently failing. ## Linux — copyleft turned competitors into co-maintainers **What it proves:** that a licence can restructure an industry's incentives. Under GPLv2 no vendor could privately fork the kernel and out-develop the commons, because improvements shipped to customers had to come back. Upstreaming stopped being generosity and became **the cheaper option** — which is the whole thesis of this site, achieved by legal design rather than persuasion. **The number:** kernel 6.18 (30 November 2025) was built by **2,134 developers — the most in its history** — including 333 first-time contributors across 13,710 commits. The largest corporate contributors were Intel at 10.4%, Google at 7.9%, Red Hat at 6.3%. **No single party is close to controlling it**, which is [the survivability property](../survivability/index.md) visible as a statistic. ## Let's Encrypt — and the mechanism was not price **What it proves:** the most measurable civilisational impact in the list, and the reason it worked is the part most often mis-stated. Certificates had been cheap before. **Free was necessary; automated was sufficient.** What Let's Encrypt removed was not the cost — it was **the transaction**: the purchase, the paperwork, the annual renewal somebody had to remember, the outage when they did not. **The numbers:** HTTPS page loads went from **under 30% globally in 2015 to roughly 80% globally and around 95% in the US**. Issuance went from one million certificates in March 2016 to **around ten million per day** by September 2025. > **Why this matters beyond TLS.** It is the strongest available evidence that [the maintainer-platform argument](../funding/index.md#platform) is about infrastructure rather than money: the relationship was missing because the *mechanism* was missing. Build the mechanism and behaviour changes at civilisational scale, without anyone being persuaded of anything. ## SQLite — the case that inverts almost everything **What it proves:** that almost every rule on this site has a successful exception, and intellectual honesty requires publishing it. - It is **public domain**, not open-source-licensed. There is no licence to reason about. - It is explicitly **not open-contribution** — it refuses patches from anyone who has not signed a public-domain dedication affidavit. ["Given enough eyeballs"](index.md#eyeballs) is not merely unused here; it is structurally declined. - The original affidavits are kept **in a firesafe.** **The number:** an estimated **one trillion databases in active use** — plausibly the second most-deployed software library in the world after zlib. By the standards of most open-source advocacy, SQLite does everything wrong: closed contribution, centralised control, no community governance. It is also one of the most successful and most trusted pieces of software ever written, and its reliability comes from an **extraordinarily rigorous test suite maintained by a tiny team** — not from openness to contribution. **The lesson this site takes: the mechanism that produces quality is being paid to care, and the licence is not the mechanism.** ## PostgreSQL — the control case for the whole relicensing wave **What it proves:**[the survivability argument](../survivability/index.md), demonstrated rather than asserted. **No company owns PostgreSQL, so no company could relicense it.** It went through the entire 2018–2024 wave untouched — not because its licence is stronger than MongoDB's or Redis's was, but because **there is no party with standing to move it**. **The number:****55.6% of developers** use it — the most-used database in the Stack Overflow 2025 survey (n=49,063). It is the single cleanest piece of evidence on this site: the projects that could be relicensed were relicensed, and the one that structurally could not be, was not. That is the argument, and PostgreSQL is the experiment. ## cURL — here because it is currently failing **What it proves:**[that open source is not free and somebody is always paying](../views/index.md#not-free), as a measured fact with a date and a casualty. ~30 billion installations. One project lead since 1998. **Seven volunteers on the security team.** And a bug bounty programme shut down on 31 January 2026 because the cost of processing AI-generated submissions exceeded what the programme was worth. It is the most important open-source story of 2025–26 and it belongs to this site more than any other, so it has its own page. [Read it →](../funding/curl.md) ## Blender — a community that bought its own freedom **What it proves:** the one case where the romantic version of the story is simply, literally true — and it should be published for exactly that reason, because a site that only publishes corrections is doing something other than history. In 2002, with the company behind it bankrupt, the community raised **€100,000 in seven weeks** (July–September) to buy the source code and release it. **They bought their own software's freedom, in cash.** **The number that closes it:***Flow* (2024), made entirely in Blender, won the Academy Award for Best Animated Feature. Note what is *not* being claimed. This is not evidence that crowdfunding solves open-source sustainability — it is one rescue, once, of a tool with an unusually devoted user base, twenty-four years ago. It is evidence that the ceiling is higher than the cynical account allows, which is a different and more modest claim. ## Two more, because they complicate the picture ### Kubernetes — commoditising the layer below your business Google released the orchestration layer and gave it to a foundation. The strategic logic is exact: **commoditise the layer beneath the thing you sell**, so that the layer beneath stops being a place a competitor can build a moat, and the workloads flow upward to where you compete. It is the clearest strategic use of open source in the industry's history, it worked, and it is a direct illustration of [the technology-is-not-the-moat argument](../views/index.md#not-the-moat) — executed by a company with the resources to be right about it. ### VS Code — open core, executed so well it is invisible An MIT-licensed core, a proprietary shipped binary, and a marketplace whose terms restrict use to that binary. **A textbook open-core structure, executed so smoothly that most of its very large user base does not know it is running proprietary software.** That is the strongest available case both *for* and *against* open core, which is why it is here rather than on the [open core page](../views/open-core.md) as a settled example. For: an enormous amount of genuinely valuable software got built and given away. Against: the boundary is invisible to the people standing on the wrong side of it, and invisibility is precisely what makes a boundary easy to move. ## And the failure that belongs here A history of open source with no failures in it is marketing. **OpenSolaris** is on this site, in [the survivability section](../survivability/index.md#cases), where it does the most work: open-sourced under a licence deliberately chosen to be GPL-incompatible, under governance Sun retained, then killed by Oracle after the acquisition. **The licence was not the problem; the copyright holder was.** illumos survives as the fork — which is also the point, because a named party existed. [← The timeline](timeline.md)[The numbers →](numbers.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /history/numbers.html (markdown twin: /history/numbers.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/history/numbers.html* > The $8.8 trillion figure and what it actually measures, the 70–90% claim that is really a presence figure, and the statistics the research could not source — listed as unverified rather than published as established. --- # The numbers, and the ones we refuse to publish This site's credibility position is that it corrects other people's unsourced figures. That only works if it does not accumulate its own — so this page states what the load-bearing numbers actually measure, and lists the ones the research **could not source** and which therefore do not appear anywhere else on this site. > **The standing warning, in the author's own words:***"the figures circulating are largely recycled from a smaller set of studies through commercial blogs, so **the direction is well supported and the precision is not**."* That is the right way to hold nearly every number in this field, including the ones below that survive scrutiny. ## "Open source is worth $8.8 trillion" — no This is the most-repeated figure in the field and it is almost always cited without the thing that makes it meaningful. It comes from a Harvard Business School working paper (24-038), and it is a **demand-side replacement cost**: what it would cost *if every firm using open source independently recreated the software it uses*, priced at global average developer wages. > **The source, linked — because this page asks other people to cite theirs.**[↗ Revealing Value: The Economic Power of Open Source Software](https://aiinstitute.hbs.edu/revealing-value-the-economic-power-of-open-source-software/), the HBS AI Institute's own summary of working paper 24-038 by **Manuel Hoffmann** (Harvard LISH), **Frank Nagle** (HBS Strategy Unit) and **Yanuo Zhou** (Rotman Toronto). It is worth reading rather than citing second-hand for one reason: it carries **both** figures, in the same table, which is exactly the context that falls off in transmission. It ends where this site does — on the *tragedy of the commons*, the risk that something free and ubiquitous is overused and underfunded, with the remedy framed as treating open source as critical infrastructure rather than as goodwill. > > **And two findings in it travel better than the trillion does.** Six languages — JavaScript, Java, Go, TypeScript, C, Python — account for **84% of the demand-side value**, and roughly **5% of developers** create the bulk of it. Those are *concentration* figures rather than valuation ones, they are measured rather than counterfactual, and concentration is [a survivability question](../survivability/index.md). The headline is the least useful number in the paper. | Measure | Figure | What it means | |---|---|---| | **Demand-side replacement** | **$8.8 trillion** | Every firm rebuilds everything it uses, separately. Counts the same library once per user. | | **Supply-side replacement** | **$4.15 billion** | Recreate everything *once*. Three orders of magnitude smaller, and the same paper's own figure. | | **Goods-market model** | **~$177 million** | A substantive published critique argues the paper's own alternative model — the realistic counterfactual, in which firms would have bought or substituted rather than rebuilt — yields this. **Four orders of magnitude below the headline.** | **The rule this site applies:** publish $8.8tn only with its definition and the critique attached, or do not publish it. It is not a fabrication — it is a real calculation of a specific counterfactual, and the counterfactual is unrealistic in a way that matters. Quoted bare, it functions as a claim about market value, which is not what it measures. > **The author's own earlier writing cited it bare, and this page is the correction.** Stated rather than quietly fixed, because a site that holds others to a citation standard should be seen applying it to itself first. ## "70–90% of a modern codebase is open source" — a different measurement The underlying finding, from Black Duck's OSSRA report, is that **98% of 947 audited codebases *contain* open source**. That is a **presence** figure, not a share-of-lines figure. "Does this codebase contain any open source at all?" and "what proportion of these lines are open source?" are different questions with very different answers. And the population matters: OSSRA's audit sample is **skewed toward M&A due diligence** — codebases being examined because someone is buying the company. That is not a random sample of software, and there is no particular reason to think its composition matches the industry's. **The direction is not in dispute.** Modern applications rest heavily on open source; that is obvious to anyone who has read a lockfile. The precision is what is unsupported, and quoting "70–90% of the code" as though it were measured lends a rhetorical exactness the evidence does not carry. ## The numbers that hold up These appear elsewhere on the site, with their source, date and caveat: | Number | Source and date | Caveat | |---|---|---| | **2,134 developers** on Linux kernel 6.18, the most in its history; 333 first-timers, 13,710 commits | Kernel release, 30 Nov 2025 | Counts contributors to one release, not the maintainer population. | | **55.6% of developers** use PostgreSQL — the most-used database | Stack Overflow Developer Survey 2025, n=49,063 | Self-selected respondents. Reliable for direction, not a census. | | **HTTPS page loads: <30% (2015) → ~80% globally, ~95% US**; ~10M certificates/day by Sept 2025 | Let's Encrypt / browser telemetry, 2015–2025 | Telemetry measures the browsers reporting it. | | **~30 billion cURL installations; seven volunteers on the security team** | Project statements, 2025–26 | Installations are an estimate by the project; the security-team figure is a headcount. | | **81 genuine reports, >$90,000 paid** since 2019; ~20% of 2025 submissions AI slop vs ~5% genuine; bounty closed **31 Jan 2026** | curl's own published figures, Jan 2026 | First-party, from the programme that ran it. [The full story →](../funding/curl.md) | | **€100,000 in seven weeks** to free Blender, Jul–Sep 2002 | Contemporary records | — | | **Three files out of eighteen thousand** removed in the USL v. BSDi settlement | Settlement, Feb 1994 | — | | **Licence conflicts in 68% of audited codebases**, up 12 points — the highest in the report's history | OSSRA 2026 | Same skewed audit population as above. Use for direction. [Relevant to the compliance argument →](../agents/index.md#compliance) | | **Mean vulnerabilities per codebase up 107% year on year**, attributed to AI-accelerated code creation | OSSRA 2026 | **Correlation, not demonstrated causation** — and the report's attribution is its own interpretation. [Cited that way on the agents page →](../agents/index.md) | ## The claims this site will not publish These were investigated and **could not be established from a primary source**. They do not appear anywhere else on this site, and this list is the reason. | The claim | Why it is not published | |---|---| | **"Linux runs 90% of the cloud"** | **No primary source found.** Every result traced back to SEO content citing other SEO content. The number may well be roughly right; there is nothing behind it to cite. | | **"All 500 of the TOP500 supercomputers run Linux"** | TOP500's OS-family table could not be fetched, so this is **unverified** — though the top five on the June 2026 list are all Linux-derived, which is stated as what it is. | | **Wikipedia's traffic figures** ("18 billion views, 500M uniques") | Traces to a **February 2014** New York Times report. `stats.wikimedia.org` is cache-only and could not be fetched. A twelve-year-old number presented as current. | | **GitHub's scale figures** | **They do not reconcile with each other.** Octoverse 2025 reports 630M repositories and 180M+ developers; GitHub separately announced its billionth repository in June 2025; Wikipedia carries "150 million users, May 2025". Cite Octoverse and say which measure you mean — or say nothing. | | **CNCF's 2025 headline** that Kubernetes is "the de facto operating system for AI" | The survey **published no sample size and no field dates.** And its own data shows **44% of organisations run no AI/ML workloads on Kubernetes at all** — which is difficult to reconcile with the headline. | > **Why publish a list of things you are not saying?** Because the absence is otherwise invisible, and because these are figures a reader will encounter everywhere else. Naming them is more useful than silently omitting them — and it is the same reasoning that puts [the site's own open questions](../roadmap/index.md#open) on a page rather than in a footnote. [← Six success stories](stories.md)[The practice →](../practice/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /practice/index.html (markdown twin: /practice/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/practice/index.html* > Apache-2.0 on the code, CC BY 4.0 on around 1,100 working documents and on the published essays — decided 6 September 2026, after the published-articles repository was found to carry CC0. The licensing in force across the estate, what each licence is for, and the reasoning behind the CC BY choice. --- # Three licences, three layers, and one nobody had noticed Anyone can hold a position on open source. Showing the licence file is different. This page is the licensing actually in force across the estate — two licences across three layers, and what each one is for — followed by the reasoning behind the choices, and the one alignment question, found while building this page and since settled. ## What is actually in force | Layer | Licence | Evidence | |---|---|---| | **Code** — the application repositories and the Issues-FS estate | **Apache-2.0** | `LICENSE` files, and `license = "Apache 2.0"` in every `pyproject.toml` | | **Briefs and corpus documents** | **CC BY 4.0** | A footer on roughly 1,100+ files: *"This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0)."* | | **Published articles** — `docs.diniscruz.ai` | **CC0 1.0 Universal** in the `LICENSE` file — **decided 6 September 2026: CC BY 4.0**; the file follows | The repository's `LICENSE` file, reported as it is on disk | > **Three layers, three jobs.** Apache-2.0 for code, where the patent grant matters. CC BY 4.0 for the working documents, where attribution carries provenance — it is *rule two* of the writing discipline, applied to every document, which is what produced 1,100 consistent footers. And CC BY 4.0 for the published essays too — decided on 6 September 2026, after the repository's `LICENSE` file was found to say CC0. **Two licences, three layers: Apache-2.0 for code, CC BY 4.0 for everything written.** ## The alignment question — decided: CC BY The CC0 licence on the published-articles repository sat outside the CC BY rule that governs everything else in writing, and the working documents did not say whether that was a deliberate carve-out. Two readings were available, and both were published here until the author settled it: | | Reading A — deliberate layering | Reading B — drift | |---|---|---| | **The claim** | Each layer got the licence its *function* needs: Apache-2.0 for code, where a patent grant matters; CC BY for the working documents, where attribution carries provenance; CC0 for finished essays, where the goal is maximum reach and attribution is friction. | Three repositories were set up at three different times, each with a sensible default for its job, and the layers were never written up as one policy. | | **What supported it** | It is coherent, and the estate does think in layers: the essay is meant to travel; the brief is meant to be traceable. | Rule two of the writing discipline says CC BY, without exception or carve-out — and a deliberate third layer is exactly the kind of thing that discipline writes down. | > **Decided, 6 September 2026: CC BY.** Reading B was the right one. The documents layer — working briefs and published essays alike — is **CC BY 4.0 throughout**, and the estate has **two licences across three layers**: Apache-2.0 for code, CC BY 4.0 for everything written. The `LICENSE` file in the published-articles repository is the follow-through; until it is replaced it still reads CC0, which is why the table above reports what is on disk rather than what was decided. **Attribution survives** — into human reuse and, more interestingly, into machine reuse, which is [the fourth agent-era thesis](../agents/index.md#cc0). ## The CC BY reasoning, which *is* documented Four distinct arguments exist for the CC BY choice, and they are worth separating because they are not the same argument: **Alignment, not compliance.***"The Creative Commons licence aligns with our zero-lock-in principle. We are already committed to zero lock-in and open standards. A project released entirely under CC BY 4.0, using open source tools, with no proprietary components — this is the natural extension of our existing values."* **It is a hard rule, not a preference.** Rule two of the writing discipline is a licence footer at the bottom of every document, and every day-index brief closes with it. That is what produced 1,100+ consistent footers — **a rule, mechanically applied**, which is why the CC0 divergence stood out as much as it did. **BY versus BY-SA was actively considered, and BY won.** The question is recorded — *"CC BY-SA 4.0 or CC BY 4.0 for the licence? BY-SA encourages derivatives to stay open; BY is more permissive"* — and permissive was chosen. That is a real decision, and it sits interestingly against [the survivability argument](../survivability/index.md), which is in effect the claim that **licences are the weakest of the structural protections**. If you believe that, choosing the more permissive licence costs you less than it appears to, because you were never relying on the licence to do the work. **Openness is a credibility asset, and it is backed.***"The transparency claim is credible because it is **backed** (the CC BY 4.0 corpus, the public briefs, rendering from a public vault)."* ## Downstream licences are respected *"CC BY 4.0 for the article and most contents; original source materials retain their own licences."* In practice that means Wardley-map briefs carry a bespoke footer crediting Simon Wardley's own Creative Commons terms — a small discipline, and a good illustration of the general rule: **your licence governs your contribution, not the material you built on.** This site applies the same rule and states it explicitly, because it quotes the open-source world at length: Wikipedia material is CC BY-SA and is quoted with attribution rather than adapted; project documentation and vendor reports are cited with source, date and caveat rather than reproduced; [charts from all-rights-reserved analyst reports are never reproduced at all](../history/numbers.md). ## The line: everything open, except at the customer > "The line is very simple: **everything is open source**, so you do not even have that conversation. It is a key pillar. It is not for everybody, some investors will not like it, but you find the ones who do, and it is a good match. You can always commercial-license or relicense everything for a customer who wants it, but the core is all open source. **No part of the company or the ecosystem is not open source.**" Note the mechanism hidden in the middle of that: *"you can always commercial-license or relicense everything for a customer who wants it."* That is only possible **because a single company holds the copyright** — which is [exactly the structure leg one of our own stress test asks about](../survivability/self-audit.md). The flexibility and the exposure are the same fact viewed from two sides, and it is worth being clear that they cannot be separated. And the commercial hook is explicitly not the code: *"We do not have that lock-in on technology, and that is fundamental. The natural line is a business line, and that is okay: that is when you charge to maintain it. It is the hook, but a hook based on value… The customer's schemas can be closed, a lot of their data is closed, **but our schemas are open**."* Whether the customer subset makes this open core rather than packaging is [a separate page with a one-question test](../views/open-core.md). ## What has actually been published | Package or estate | Where | Note | |---|---|---| | **`sgit-ai`** | PyPI · `SGit-AI/SGit-AI__CLI` | Named that way because *"`sgit` was already taken"*. CI: push to main → tests → deploy to qa → PyPI publish. | | `sg-send-cli` | PyPI | **Deprecated 20 March 2026**, superseded by `sgit-ai`. | | **`issues-fs`** and six siblings | `owasp-sbot` | All Apache-2.0. [The org choice is itself a thread →](../owasp/index.md) | | **The `osbot-*` / `mgraph-*` family** | PyPI · `owasp-sbot` | Described internally as *"2 years of open source infrastructure"*. **`MGraph-DB` is publicly credited to the OWASP community.** | > **Next for this page: the retrospectives.** Six published projects, and the story of why each was open-sourced, what the licence decision was, and what happened afterwards is still to be written — the O2 Platform account exists, written about the author rather than by him, and is the model. [On the build order →](../roadmap/index.md#interview) ### [Why Apache-2.0 rather than MIT](apache-vs-mit.md) *Written fresh* The most conspicuous unwritten page in the whole brief: the entire estate rests on that choice and the reasoning existed nowhere. ### [Publish the source next to the render](publish-the-source.md) *A mechanism* The markdown twin at every URL, how it was actually built, and the radical version nobody has shipped: publish the evidence and every prompt. [← The numbers](../history/numbers.md)[Why Apache-2.0, not MIT →](apache-vs-mit.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /practice/apache-vs-mit.html (markdown twin: /practice/apache-vs-mit.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/practice/apache-vs-mit.html* > The patent grant, defensive termination, the NOTICE file, and the explicit contribution clause — the four things Apache-2.0 does that MIT does not, the honest costs of each, and when MIT is the better choice. --- # Why Apache-2.0 rather than MIT This page is written fresh. The entire estate is Apache-2.0 and **the reasoning existed nowhere** — no brief, no document, no commit message. For a site about open source that was the most conspicuous unwritten page in the whole commission, so here is the argument, including where it does not hold. > **Read this as reasoning, not as legal advice.** Nothing here is a lawyer's opinion, and licence choice has consequences that depend on your jurisdiction, your patent position and your corporate structure. What this page can honestly offer is *what the differences are and why they might matter to you*, which is more than had been written down anywhere before. ## Start with what is the same Both are **permissive**. Both let anyone use, modify, distribute and commercialise the code, including in proprietary products, with no obligation to publish changes. Both are OSI-approved, GPLv3-compatible, and universally understood. **On the question most people think they are asking — "can someone take this and sell it?" — the two licences give the same answer: yes.** So the choice is not about permissiveness. It is about four specific things Apache-2.0 says and MIT does not. ## The four differences ### 1. The express patent grant — the main reason Apache-2.0 section 3 grants every user a licence to any patents the contributors hold that are necessarily infringed by their contributions. **MIT says nothing about patents at all.** The usual reassurance is that MIT grants an implied patent licence. Perhaps — it is a plausible reading, it has some support, and it has never been comprehensively settled. **An express grant is not a stronger version of an implied one; it is a different thing, because it does not need to be argued.** The value is the absence of the argument. This matters most to the party *downstream*. A company adopting a dependency wants to know it will not be sued over patents by the people who wrote it, and Apache-2.0 answers that in writing. MIT requires them to reason about it — and legal teams asked to reason about an unsettled question tend to produce a delay rather than an answer. ### 2. Defensive termination The same section adds a condition: **if you initiate patent litigation alleging the software infringes your patents, your patent licence under Apache-2.0 terminates.** This is a genuine structural protection and it is a mutual one. It does not stop anyone suing; it makes suing over this software cost you your own right to use it. For a small project it is a deterrent out of proportion to its size, and it costs nothing to have. MIT has no equivalent. ### 3. The NOTICE file — attribution that survives Apache-2.0 section 4 requires redistributors to carry the `NOTICE` file. MIT requires the copyright notice and licence text to be preserved, which is a weaker and much more easily satisfied obligation in practice. The practical difference: **a NOTICE file survives vendoring, bundling and repackaging in a way a header comment often does not.** For a project whose commercial position is ["we are selling trust"](../views/index.md#not-free) and whose value is being the recognised source, attribution that survives redistribution is not a vanity concern — it is the mechanism by which anyone downstream can find out who to call. ### 4. It says what a contribution is Apache-2.0 section 5 states that a contribution submitted for inclusion is licensed under the same terms unless explicitly stated otherwise — **inbound=outbound, written into the licence itself.** This one is worth sitting with, because it connects directly to [the survivability argument](../survivability/index.md#cla). Apache-2.0's default is the structure that argument prefers: contributions come in under the project's licence, and **nobody acquires the standing to relicense everyone else's work.** A separate copyright-assignment CLA layered on top is what creates the single-holder pattern — and that is a choice a project makes *in addition to* the licence, not something the licence does. ## The honest costs | Cost | How much it bites | |---|---| | **It is heavier to comply with.** Roughly 200 lines against MIT's 20, and the NOTICE obligation is a real step in a release process. | **Genuinely true.** A downstream packager has more to do. For very small libraries this is a defensible reason to prefer MIT — the compliance burden can exceed the code. | | **Nobody reads it.** MIT can be read and understood by a developer in a minute. Apache-2.0 cannot. | **True, and it matters more than it should.** Comprehensibility is a real property of a licence. Against it: the people for whom the differences matter — legal and procurement — do read it, and they prefer it. | | **GPLv2 incompatibility.** Apache-2.0 is incompatible with GPLv2 (though fine with GPLv3). | **Occasionally decisive.** If your code needs to be linkable into GPLv2-only projects — the Linux kernel being the notable one — this settles it against Apache-2.0. | | **The patent grant only matters if you have patents.** | **Partly right, and it misses the point.** The grant's value to a downstream adopter is the assurance, which does not depend on the contributor's portfolio being large. It is worth something precisely when there is nothing to grant, because it says so in writing. | ## When MIT is the better answer A page arguing for one licence that cannot describe when the other wins is advocacy. MIT is the better choice when: - **The code is small enough that the licence is a meaningful fraction of the artefact.** A 200-line utility with a 200-line licence is faintly absurd. - **You need GPLv2 compatibility.** This is not a preference, it is a constraint. - **Maximum adoption with minimum friction is the entire goal**, and you accept the patent ambiguity as the price. MIT's ubiquity is itself a feature — nobody has ever had to think about whether they can use an MIT dependency. - **Your ecosystem's convention is MIT** and swimming against it costs you contributors. Convention is a real force and ignoring it is a choice with a cost. ## The position, stated **Apache-2.0, for code that other organisations will build production systems on.** The patent grant and defensive termination remove questions a procurement process would otherwise have to answer, the NOTICE obligation preserves attribution through redistribution, and the inbound=outbound default aligns the licence with [the structural argument this site makes about survivability](../survivability/index.md). The compliance weight is a real cost and it is worth paying at that scale. **And CC0 or CC BY for content**, which is a different question entirely — software licences applied to prose produce nonsense, and [the estate's own three-layer split is the subject of the previous page](index.md#reading). > **What this page is not.** It is not a licence taxonomy, and the site does not yet have one — no worked treatment of copyleft versus permissive, licence compatibility, or where AGPL fits. That is [next on the build order](../roadmap/index.md#taxonomy): the [history research](../history/index.md) supplies the ground for it, and the position is to be written. [standards.sgit.ai owns the SPDX machinery](https://standards.sgit.ai); the argument belongs here, and it is not written yet. [← Three licences](index.md)[Publish the source →](publish-the-source.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /practice/publish-the-source.html (markdown twin: /practice/publish-the-source.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/practice/publish-the-source.html* > Every page available as markdown at the same path with the extension swapped, and the links inside the markdown pointing at markdown — the practice, how it was actually built with edge functions, and how this site implements it. --- # Publish the source next to the render This is the strongest practice page available, because it is **a mechanism rather than an intention**. It is also the one this site implements on itself — [this page has a markdown twin](publish-the-source.md), generated in CI, and the build fails if it is stale. ## The markdown twin at every URL > "**every page is available as markdown at the same path with the extension swapped, and links inside the markdown point at markdown, so a traversing agent never has to parse HTML.**" The second clause is the one that makes it work, and it is the one usually left out. Publishing a markdown version of a page is common. Publishing a markdown version **whose internal links also point at markdown** means an agent that arrives at one `.md` never has to return to the HTML surface — it can traverse the entire site without a parser, and without ever needing to guess that a twin exists for the next page. ## Why it is load-bearing rather than decorative An agent-access report run against this estate in August 2026 found the failure precisely, and it is not the failure people expect: > "many agents can only fetch URLs that a search engine has already returned to them… **A link listed inside a fetched document did not count as having been seen.** … **It can read the map and cannot walk it.**" > "**The markdown is exemplary and the discovery layer is what stops agents using it.**" And the consequence, which should worry anyone publishing technical material: > "the package registry page, which is a summary written for a different purpose, **becomes the authoritative source by default because it is the only one that ranks**." That is the real failure mode. Not that your documentation is bad — that **a worse summary of it becomes canonical** because it is the only version an agent can reach. Publishing excellent markdown that nothing can discover is a solved problem that stays unsolved. ## The mitigation ladder, and what this site ships | Rung | What it does | Status here | |---|---|---| | **Get indexed** | **The real fix**, and the only one that addresses the root cause: agents that can only fetch what a search engine returned need the search engine to have returned it. | **In progress** — the site is new. Not in our gift on any particular timescale, and [on the build order](../roadmap/index.md) rather than quietly hoped for. | | **Make `llms.txt` self-sufficient** | **The cheap fix.** If a link inside a document does not count as seen, then a file that is *only* links is the failure mode restated. It has to carry the substance. | **Shipped.**[llms.txt](../llms.txt) states the thesis, the central claim and its mechanism in the file itself. | | **Ship `llms-full.txt`** | **Removes link-following entirely.** Every page, one file, one fetch. | **Shipped.**[llms-full.txt](../llms-full.txt), generated from the pages themselves. | | **The markdown twin at every URL** | Keeps a traversing agent on the markdown surface once it arrives anywhere. | **Shipped, and enforced.**`validate.js` fails the build if any page lacks a twin, and CI regenerates and fails if a committed twin is stale. | > **The mechanism is published with the site.**`admin/build/gen_markdown.py` converts each hand-written page, rewrites internal `.html` links to `.md`, and concatenates the result into `llms-full.txt`. It is about 400 lines with no dependencies, so it runs in CI with nothing installed. [The build tooling is documented →](../admin/index.md) — which is itself the practice this page is about. ## How the original was built — the part that is actually hard > "we added native support to the library for serving `llms.txt` and `.md` files… The way it was done is important: it was done using **edge functions**. These are static files, the browser will not run any JavaScript on them, so we couldn't render encrypted data. What we did was add a little bit of JavaScript on the Lambda@Edge function that does the rendering of the file." That detail is worth preserving because it names the genuine obstacle. The whole point of a markdown twin is that it is served as **plain text to a client that will not execute anything** — which is exactly what makes it useful to an agent, and exactly what rules out any client-side rendering strategy. If the content needs any transformation at all, the transformation has to happen *before* the bytes leave the server. An edge function is the smallest place that can be true. This site takes the simpler road available to it: the twins are **generated at build time and committed**, so GitHub Pages serves static files and there is no runtime component at all. Same contract, no edge function — and CI is what keeps the two surfaces from diverging. ## The ambition beyond markdown > for every page on the website, serve not just the content but **the semantic knowledge graph of that content (and the references)**, alongside the LLM-friendly text. Not implemented here, and named as an ambition rather than a feature. [graphs.sgit.ai owns the how](https://graphs.sgit.ai); what this site would own is the argument for why a publisher should do it — and that argument is not yet written. ## And the version nobody has shipped > publish **"not just the article text but the full body of evidence, the semantic graph, the source materials, the multilingual versions, the agentic workflow provenance, and **every prompt and decision that went into the finished piece**."** That is a genuinely radical openness claim and it is barely stated anywhere public. It is worth taking seriously because of what it would prove: **in a world where a great deal of published text is machine-assisted, provenance is the only thing that distinguishes a considered document from a generated one** — and provenance is checkable if you publish it and unfalsifiable if you do not. This site ships part of it and should be precise about which part. **The source materials are published verbatim** — [the briefs this site was built from are in the repository](../documents/index.md), in full, as the source of truth for anything the pages summarise. The evidence trail is partial: [every number carries its source, date and caveat, and the unverifiable ones are listed as unpublished](../history/numbers.md). **The workflow provenance and the prompts are not published**, and claiming otherwise would be exactly the kind of thing this page argues against. > **The cost of this practice, in the author's own words.** He lists it as a tension: *"Publishing security reviews — it is unusually transparent and **it publishes your own weaknesses to an audience that includes people looking for them**."* That is real, it is the argument against everything on this page, and it is disclosed rather than glossed. It is also the reason the transparency is worth anything: [a self-audit that could not fail would not be evidence of anything](../survivability/self-audit.md). ## One place the openness stops, and why The practice is not openness for its own sake, and the boundary is instructive. A public vault's **read key is published by definition**, so cataloguing read keys adds convenience and no exposure. A central list of **write** keys would be *"a single artefact whose compromise hands over write access to everything"* — and the estate has already had a key exposure, which it also documents. The sharper rule comes from the irreversibility: *"**Nothing published can be corrected.** If a frozen sample vault turns out to contain something it should not, there is no edit available."* Hence the discipline — **escrow the write key before publishing, not after.** Publishing is a one-way door, and the time to think about it is before you walk through, which is a general principle rather than a vault-specific one. [← Why Apache-2.0, not MIT](apache-vs-mit.md)[Agents and open source →](../agents/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /agents/index.html (markdown twin: /agents/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/agents/index.html* > Code-reading as the appreciating scarce asset, two dated positions on the junior pipeline both published, and four theses that follow from the author's writing and are next to be written — including licence compliance at machine speed. --- # Agents and open source The claim this page makes: **the economics of maintaining open source have changed, the change is measurable, and it currently runs against maintainers before it runs for them.** The claim it deliberately does not make is that agents will fix the sustainability problem — every piece of 2025–26 evidence points the other way, including this project's own. ## Code-reading was already the problem. It was accelerated, not created The argument opens by refusing its own easy version, which is why it is worth reading: > "Before AI agents started writing code, you could argue that **90% of the code running in production was not being read by anyone**… So let us not pretend that 'nobody reads the code anymore' is a new problem. **It is an old problem, accelerated.**" And the passage underneath it, which is the best-written thing the author has published on this subject: > "I would argue that this narrative has caused more damage than people admit… **Applications with 2,000 dependencies. CI pipelines that download half the internet. Layers of abstraction where nobody on the team understands what is happening below their layer.** The answer was never 'stop abstracting.' The answer was '**someone still needs to understand what is underneath.**' Linus Torvalds reads C code." The three-phase answer maps onto [the Wardley teams](../views/villagers.md): *"Explorers: agents read it (scans, checks, basic quality)… Villagers: mid-level developers read it… Town Planners: senior developers really read it."* Which is a coherent structure — and it depends entirely on the middle tier continuing to exist. ## Two dated positions on the junior pipeline, both published This is the second place the author's position moved between two dated documents. Like [the open-core question](../views/open-core.md), it is more valuable published as two dates than tidied into one. | When | The position | |---|---| | **21 March 2026** optimistic | *"The learning path is not eliminated. It is restructured… Instead of learning by writing simple code from scratch, **juniors learn by reading, evaluating, and improving code at scale. The density of learning per hour increases.**"* | | **28 July 2026** evidence | *"apparent gains **shifted work from juniors to seniors** rather than removing it."* | | **31 July 2026** the market claim | the junior pipeline *"is being disrupted at exactly the moment the maintenance need is growing."* | Four months, opposite directions. The March position is a plausible theory about how learning could restructure; the July position is what the evidence looked like when someone went and checked. **Both are on the record here.** > **What would settle it.** Not opinion — a cohort measurement: are people who entered the profession after 2023 acquiring the ability to read and repair unfamiliar code at the same rate, faster, or slower than the cohort before them? Nobody appears to be measuring it. Until someone does, this is [an open question](../roadmap/index.md#open), and [the villagers market argument rests on the July answer being the right one](../views/villagers.md) — which is worth saying plainly, because it means that argument is exposed if March turns out to be correct. ## Agents currently add maintenance load The author wrote this down before the evidence arrived, which is the strongest form of a prediction: > "**AI slop** for low-quality, auto-generated pull requests that flood maintainer queues without adding value, increasing the burden on already-stretched maintainers. So AI is, for now, **adding maintenance load** rather than only creating maintainable work. **This does not refute the thesis, it sharpens it.**" And then it acquired a named casualty with a date. cURL — ~30 billion installations, seven volunteers on the security team — **closed its bug bounty on 31 January 2026**, because roughly 20% of 2025 submissions were AI-generated slop against roughly 5% genuine, each report consuming three or four people for up to three hours. [The full story is its own page →](../funding/curl.md) Independent corroboration, with the caveat it needs: Black Duck's OSSRA 2026 reports **mean vulnerabilities per codebase up 107% year on year** and attributes it to AI-accelerated code creation. That attribution is **the report's interpretation, and correlation rather than demonstrated causation** — [this site's rule is to say so](../history/numbers.md). ## Where the economics genuinely do change Four pieces exist across the author's writing and had not been assembled into one claim. Assembled: 1. **Agentic mass-customisation replaces professional services.***"you turn the tail around. You use agentic workflows to create mass-customised and supported versions of the product… whoever creates this will be a domain expert in all of them, but the company is unlikely to have a person who understands all those phases."* 2. **The value margin moves.***"The sweet spot is to operate at that margin where it is profitable for companies to pay you versus doing it themselves. As long as you operate there, you have a valid business model, and **now with agents that is possible in ways it was not before**."* 3. **Multi-level expertise becomes affordable.***"In the past, having people who could operate at multiple levels of abstraction was expensive and rare. **With AI agents handling the volume, it becomes economically viable.**… That is not a problem AI creates. It is a problem AI finally makes economical to solve."* 4. **And, for now, it runs the other way** — see above. The assembled thesis is narrower than the optimistic version and more defensible: **agents make it economically possible to pay attention to things that were previously too expensive to attend to** — which is precisely [the NFR maintenance market](../views/villagers.md). Whether that materialises before the maintainer attrition it is currently causing is genuinely undecided. ## Four theses that follow, and are written nowhere These are the most original writing still available on this subject, and each is an obvious consequence of material that already exists. None is written. They are listed here as an agenda rather than claimed as work done. ### (a) Licence compliance at machine speed Three components exist separately. **One:** a single manual SPDX review of 17 transitive dependencies, from February 2026. **Two:** the PBOM idea — *"you leverage the ideas and concepts around SBOMs, but say, this is about permissions… a bill of actions or a bill of permissions"*, with the claim that *"this mapping is more important than the SBOM, because it should impact the SBOM"*. **Three:** the bridge — *"**SPDX identifiers are the evidence artefact**"*, with a falsifiable predicate attached. Nobody has written **"agents doing licence compliance continuously"** as a thesis, and the external evidence makes it urgent: OSSRA 2026 reports **licence conflicts in 68% of audited codebases, up 12 points — the highest in its history**, and that **only 24% of organisations check AI-generated code across security, IP/licence, quality and all four categories.**[standards.sgit.ai owns the SPDX machinery](https://standards.sgit.ai); the argument belongs here. ### (b) Provenance and attribution of AI-generated code The closest existing artefact is a **signed-licence proposal** from February 2026 which explicitly extends to code: *"**MIT-S** adds: 'This software includes a cryptographic signature from the original author. You must preserve this signature in all copies and substantial portions of the software.'… If the code is modified (fork): → Fork must be signed by the modifier → Original signature preserved alongside → **Chain: original author → modifier**"*. It was written about **human** authorship and never applied to machine-generated code. **The bridge is the obvious next move**: a signature chain is exactly what an AI-authored contribution needs and exactly what it cannot currently produce. [pki.sgit.ai holds the signing machinery](https://pki.sgit.ai); nobody has written the licensing argument on top of it. ### (c) Training-data licensing One substantive passage exists, from a 2025 article: *"European lawmakers and creative industries are discussing mechanisms so that **creators can be remunerated when AI uses their works**… **Open-source projects can lead the way here by openly cataloguing their training sets** and filtering out data that's proprietary or sensitive. Ultimately, an ecosystem where **both models and their training data are open and auditable** is one where users (and regulators) have far more control."* The argument has moved a long way since then, and the author's published position has not yet followed it. The live question is the **OSI's Open Source AI Definition**, which drew heavy criticism, and the fact that **almost no model marketed as "open source AI" meets it** — "open weights" being the accurate term for most of them. That is a licensing argument, it is exactly this site's subject, and it is unwritten. > **A browser vendor is now betting on that distinction, in public.** Mozilla's chief executive **Anthony Enzor-DeMeo**, interviewed by Sabrina Ortiz for [↗ The Deep View](https://www.thedeepview.com/articles/why-mozilla-is-on-a-mission-to-prevent-ai-lock-in) (August 2026), states that Mozilla will *not* build a frontier model and will instead ship **model choice** in Firefox — *"We want to give users access to different things they wouldn't normally have access to when they're kind of confined and locked in."* The stated failure mode being avoided is the search default: one provider becoming everyone's default and the default becoming the market. The bet is placed on **open-weight** models, which is precisely the term this thesis says is the accurate one. The reason he gives is [this site's own argument](../views/index.md#zero-contributions), arrived at independently and applied to models rather than to code — *"if you're giving something away, it's obviously easier to gain adoption, and then more people will conform to those standards — and thus those people will be in more control. We saw that with the web"*, his own pull-quote from the same conversation. Giving it away is not generosity. It is how the standard gets set, and whoever sets the standard keeps the control. That is the strategy-not-charity claim in somebody else's words, made by somebody with a browser to fund. > **Read it as positioning rather than as evidence.** It is a strategy statement from an interested party — Mozilla's commercial position depends on there being no single gatekeeper, so it would make this argument whether or not it were correct, and a stated intention to ship is not a shipped thing. What it does establish is a **dated instance**: an organisation with real distribution choosing open weights on lock-in grounds in 2026. > > **And it sharpens [Q7](../roadmap/index.md#open) rather than settling it.** "Open weight" is exactly the category the OSI's definition holds is *not* open source AI. So the most prominent organisation making the openness argument for models is backing the thing the definition excludes, and the interview does not address training data at all — which is the whole of what the definition is about. That gap, between the openness people are willing to fund and the openness the definition requires, is the argument this thesis still has to make. ### (d) What CC BY means for machine reuse [The estate's writing is CC BY 4.0 throughout](../practice/index.md#reading) — the published essays included, since 6 September 2026, when the CC0 in that repository's licence file was settled as drift rather than a third layer. In a world where models train on public text and agents synthesise from it, **choosing CC BY over CC0 is a decision about machine reuse, not human reuse**: it keeps the one obligation that can survive into a synthesised output — attribution — where CC0 would have removed it. What attribution *means* when the reuser is a model rather than a person is the page nobody has written: what a synthesised paragraph owes its sources, whether a licence footer is machine-readable enough to count, and whether the estate's provenance discipline — every document dated and footed — is exactly the artefact that makes the obligation enforceable. It may be the most interesting of the four. ## Agents are a primary audience of this site Not a topic — an audience, which makes traversal a build requirement. *"**The audience is disproportionately agents**… If agents are a primary audience, the failure mode is a primary failure mode."*[How this site implements the mitigation ladder →](../practice/publish-the-source.md), and [the whole site in one file](../llms-full.txt) if you are one. [← Publish the source](../practice/publish-the-source.md)[Funding →](../funding/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /funding/index.html (markdown twin: /funding/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/funding/index.html* > Market forces and supply-chain labelling, a maintainer platform, and sovereignty bounties that fund the exit rather than the supply. None was costed, none piloted, and none compared against the others — until here. --- # Three funding proposals, and a position The author has proposed three answers to the sustainability question at different times, while being clear that *"the sustainable funding question is unsettled."* This page puts them side by side for the first time, says what each one actually fixes, and takes a position on how they fit together. > **The framing that makes the whole page work** comes from [the site's central argument](../views/index.md): if open source is a gift, underfunding is a moral failure and the remedy is persuasion. If it is [a strategy whose costs someone always bears](../views/index.md#not-free), underfunding is an **externality** — and externalities have never once been corrected by asking nicely. ## 1. Market forces and supply-chain labelling > "**Charity will not fix this. 'It is the right thing to do' will not fix this. The only thing that will fix this is market forces.**" The mechanism: declare your supply chain, calculate your value contribution, pay the projects you depend on proportionally — *"Not as charity. As a cost of doing business. The same way you pay for cloud infrastructure, for office space, for salaries"* — and **publish a rating**. With the best image in the argument: > "Just like a restaurant health rating on the door: you can still choose to eat at the restaurant with a bad rating. **But you know.**" And the counterintuitive claim that gives it commercial legs: *"paying for open source is cheaper than not paying… They spend more money internally maintaining open source software than they would have spent supporting the project directly."* | What it fixes | What it does not | |---|---| | The **information problem**. Nobody currently knows which companies free-ride, so there is no reputational cost to doing it. A published rating creates one, and reputational costs are the only lever that works on organisations too large to shame individually. | It is **uncosted and unpiloted**, and "calculate your value contribution" is doing enormous unexamined work — that calculation is the entire hard problem, and no method is proposed. Ratings systems also get gamed, captured, or quietly ignored. | ## 2. A maintainer platform — the relationship is missing because the platform is This one relocates the problem entirely. The claim is that the obstacle is not licensing and not goodwill but **missing infrastructure**: > "A solo maintainer publishing a Python package today has no realistic path to capture value from production users. **The relationship is missing because the platform is missing.**" With a boundary sharp enough to build on: > "the commercial line is where the package touches the target app." / "A consultancy can study the package. **The maintainer *is* the package.**" And a principle it refuses to trade away: *"It does not pull docs behind paywalls… That generosity is a core principle of open source and it stays."* | What it fixes | What it does not | |---|---| | The **transaction problem**, and there is strong evidence this is the right diagnosis. [Let's Encrypt did not succeed because certificates got cheaper — it succeeded because the transaction disappeared.](../history/stories.md#letsencrypt) Build the mechanism and behaviour changes without anyone being persuaded of anything. | Platforms need **critical mass on both sides**, and several have tried. It also does nothing for the projects most at risk — the ones with no commercial users to transact with, which are frequently the most load-bearing. | ## 3. Sovereignty bounties — fund the exit, not the supply The strongest single idea of the three, and genuinely unclaimed elsewhere. > "**Every one of those programmes funds the supply side**… None of them funds the **substitution side**… on present evidence nobody is funding it." Every public open-source funding programme pays people to *build and maintain* open-source software. None pays anyone to build **documented, working migration paths off proprietary platforms** — which is the thing an organisation actually needs in order to have the sovereignty that [the argument says open source makes possible](../views/sovereignty.md). Having the source is a precondition. **Having a walked path is the capability**, and nobody is buying it. Two second-order ideas make it more than a grant scheme: **Bounty size as a published lock-in metric.***"it's then market economics, like the more complicated is the bigger the bounty."* If the cost of exiting a platform is *published*, then lock-in stops being a vague complaint and becomes a **measurable, comparable property of a vendor** — a number in a procurement spreadsheet. **Vendor-sponsored proof of no lock-in.** A vendor funding *"a documented, working exit path from its own product acquires a strong and checkable claim that it does not hold its customers by lock-in."* That is a genuinely novel commercial move: the only credible way to prove you are not holding someone captive is to pay for the door. | What it fixes | What it does not | |---|---| | The **substitution problem**, which nothing else addresses and which is the binding constraint on every sovereignty argument ever made. It also converts a political goal into a procurement line item, which is where things actually get funded. | **Nobody has piloted it, no bounty has been sized, and the moral hazard is unaddressed** — a vendor sponsoring its own exit path controls how good that path is. An exit path that technically works and is miserable to walk is worse than none, because it can be pointed at. | ## The three, side by side | | Labelling | Platform | Sovereignty bounties | |---|---|---|---| | **Failure it addresses** | Information — nobody knows who free-rides | Transaction — there is no way to pay | Substitution — the exit is theoretical | | **Who pays** | Consuming companies, under reputational pressure | Production users, per transaction | States, and vendors proving a point | | **Who it reaches** | Projects with identifiable corporate dependants | Projects with commercial users | **Nobody currently** — it is not the maintainers, it is the migrators | | **Helps cURL?** | **Yes** — 30bn installations is a very visible rating | **Partly** — no natural production-user transaction | **No** — different problem entirely | | **Piloted?** | **No** | **No** | **No** | ## The position **They are not competing answers, and presenting them as three options was the error.** They address three different failures, and the reason the sustainability problem has resisted a single solution is that it is not one problem. - **Labelling is the precondition.** Nothing else can be priced while consumption is invisible. It is also the one whose hard part — the value-contribution calculation — is entirely unsolved, and that should be the next piece of work rather than a fourth proposal. - **The platform is the mechanism**, and the Let's Encrypt precedent is the strongest evidence on this page that mechanisms beat exhortation. - **Sovereignty bounties are the most original and the least connected to the other two.** They do not fund maintenance at all — they fund *migration*. Filing them under "open-source funding" is what caused three answers to look like competitors. > **And cURL settles part of the argument empirically — after all three were written.** Thirty billion installations. A bounty programme that paid over $90,000 across 81 genuine reports since 2019. **Shut down on 31 January 2026** because the cost of processing AI-generated submissions exceeded the value of the programme. **Charity did not fix it. No platform existed to fix it. An externality nobody was paying for destroyed the mechanism.** That is the strongest evidence in the world for the market-forces argument, and it arrived after the argument was made. [The full story →](curl.md) [← Agents](../agents/index.md)[cURL →](curl.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /funding/curl.html (markdown twin: /funding/curl.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/funding/curl.html* > On 31 January 2026 curl closed its bug bounty because roughly 20% of 2025 submissions were AI-generated slop against roughly 5% genuine. An externality nobody was paying for destroyed a funding mechanism, with a date and a named casualty. --- # cURL: thirty billion installations, seven volunteers, and a bounty that closed This story belongs to this site more than any other, because it is **three of its arguments colliding in one project** — with a date, a measured cost, and a named casualty. It is the most important open-source story of 2025–26, and it arrived *after* the arguments it settles had already been written. ## The facts | | | |---|---| | **Reach** | **~30 billion installations.** In effectively every operating system, phone, car, television and appliance that speaks HTTP. | | **People** | One project lead, **Daniel Stenberg, since 1998**. **Seven volunteers on the security team.** | | **The bounty, 2019–2026** | **81 genuine reports, over $90,000 paid.** By any measure a well-run programme that found real things. | | **2025 submissions** | **~20% AI-generated slop. ~5% genuine vulnerabilities.** Each report consuming three or four people for thirty minutes to three hours. | | **The decision** | Announced **22 January 2026**: the HackerOne bounty would close on **31 January 2026**, moving to unpaid reporting via GitHub. | | **The reason, in the project's words** | *"The main goal with shutting down the bounty is to **remove the incentive for people to submit crap**."* | Read the ratio again, because it is the whole story: **four times as much fabricated work as real work**, arriving at a seven-person volunteer team, each item requiring several people and up to three hours to triage — because a plausible-looking security report cannot be dismissed without reading it. **That is the attack.** Nobody intended it as one. It worked anyway. ## Why it is this site's page ### It is "open source is not free" as a measured fact [The argument](../views/index.md#not-free) is that somebody is always paying — usually in unaccounted time rather than money. Here the payment is visible and it has a denominator: **thirty billion installations, seven volunteers.** A number that large next to a number that small is not a curiosity; it is the funding failure stated as a ratio, and it existed long before AI arrived. ### It is an externality destroying a mechanism, in public Nobody submitting an AI-generated report intended to shut down a bug bounty. Each individual submission was, from the submitter's point of view, nearly free — write a prompt, paste the output, possibly collect money. **The cost landed entirely on someone else**, in units of volunteer attention, and it accumulated until the mechanism could not bear it. That is the textbook shape of an externality, and it is why the response was structural rather than moral. The project did not appeal to people's better nature. **It removed the incentive** — which is the only thing that has ever worked on an externality, and it is precisely [the market-forces argument](index.md#labelling) in action. ### It is the strongest available evidence that charity does not fix this > "**Charity will not fix this. 'It is the right thing to do' will not fix this. The only thing that will fix this is market forces.**" That was written in March 2026 as an argument. By January 2026 it had a worked example: a project with more goodwill than almost any other in the world, more visible need, and a maintainer with an unusually large platform for asking — and none of it was sufficient. **Goodwill was never the scarce resource. Attention was, and nobody was paying for it.** ### And it confirms a prediction the author made before the event [The author wrote down the AI-slop mechanism](../agents/index.md#slop) — *"low-quality, auto-generated pull requests that flood maintainer queues without adding value, increasing the burden on already-stretched maintainers… AI is, for now, **adding maintenance load** rather than only creating maintainable work"* — before curl's announcement. A prediction that names the mechanism and is then confirmed with a date is worth considerably more than a retrospective explanation, and it is the reason [the agents page refuses to claim agents will fix sustainability](../agents/index.md). ## What this story does not prove A page that only presses its advantage is advocacy, so: - **It is one project.** A well-known one with an unusually exposed bounty programme, which is exactly the profile that attracts volume submissions. It is not a survey. - **The bounty closed; the project did not.** curl continues, security reports continue via GitHub, and the maintainer has been explicit that this is a change of mechanism rather than a retreat. Reporting it as "curl is collapsing" would be false. - **The percentages are the project's own figures**, first-party and self-measured. That makes them the best available evidence and not an independent audit. They are stated here as what they are. - **"AI slop" is a claim about submission quality, not about the tools.** The failure is a system with no cost on the submitting side, and it would have arrived eventually with any technology that made plausible text cheap. ## What would actually have helped Testing the three proposals against a real case, which is the only way to find out whether they are proposals or wishes: | Proposal | Would it have helped curl? | |---|---| | [**Labelling and proportional payment**](index.md#labelling) | **Yes, and more than anything else.** Thirty billion installations is the most legible dependency claim imaginable — every large technology company could be shown, precisely, to depend on it. A published rating would make free-riding on curl specifically embarrassing. **It would have funded triage capacity**, which is exactly what ran out. | | [**A maintainer platform**](index.md#platform) | **Partly.** curl's users are mostly not in a transactional relationship with it — it arrives bundled inside something else. The platform argument works best where a production user knowingly depends on a package; curl's dependants frequently do not know they are dependants. | | [**Sovereignty bounties**](index.md#bounties) | **No.** Different problem entirely — they fund migration off proprietary platforms, and curl is the thing you migrate *to*. Worth stating plainly, because it is the clearest evidence that the three proposals were never competing answers to one question. | > **The uncomfortable conclusion.** The mechanism that failed here was **a volunteer security team's attention**, and none of the three proposals is aimed at it directly. Labelling funds projects; platforms fund maintainers; bounties fund migrations. **Nothing funds triage** — the unglamorous, high-skill, entirely thankless work of reading reports about software you did not break, most of which are wrong. That is a fourth gap, it is where this failure actually happened, and this page is the first place on this site to name it. [← Funding](index.md)[OWASP & the summits →](../owasp/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /owasp/index.html (markdown twin: /owasp/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/owasp/index.html* > Four summits from 2008 Algarve to 2017 Woburn's 173 sessions, the working-session format and no spectators only participants — written from the public record, with the first-person account planned and its questions published. --- # OWASP and the summits > **How this page is written.** Everything below is **sourced and checkable**, and it is written from the public record rather than from memory — the summits as they were reported, with the author's role in them as the record states it. The first-person account — board tenure, the projects led, the founding of the Open Security Summit — is [planned, and its questions are published below](#interview), so that when it is written it answers what a reader would actually ask. ## What the public record establishes | Claim | Source | |---|---| | **Former OWASP Board member** | Founder biography, repeated across several documents, with the evidence column reading *"Public record, founder biography"* | | *"OWASP Leader — Contributed to multiple OWASP projects and **organized global security summits**"* | `docs.diniscruz.ai/about` — his own published bio, and therefore self-stated | | Email of record is **`dinis.cruz@owasp.org`** | The `pyproject.toml` authors field. A hard artefact. | | The entire Issues-FS estate lives under the **`owasp-sbot`** GitHub organisation | Repository location. A hard artefact. | | **`MGraph-DB` publicly credited to OWASP** — *"an open source, serverless graph database… published by the OWASP community… available in the OWASP SBot GitHub repositories"* | Published article | > **Note what the last three mean.** This is not a historical affiliation being cited for credibility. **The current work ships under the OWASP organisation, under an OWASP email address, with at least one project publicly credited to the OWASP community.** The thread is live, and this page presents it in the present tense. ## The summits — four, and the format is the argument ### 2008 · OWASP European Summit · Algarve, Portugal · 4–7 November Around 80 attendees. Theme: *"Setting the Web Application Security Agenda for 2009."* And one striking detail: *"the OWASP Foundation **covered travel and accommodation costs for all participants (~80 people)** using OWASP funds."* The outcomes were structural rather than technical: **OWASP's core principles and a formal code of ethics**, and the creation of **six new global committees**. A foundation spent its money flying people to a room to decide how it would govern itself. ### 2009 · Washington D.C. · 11 November One day, leadership only: *"review 2009 & decide directions for 2010."* ### 2011 · OWASP Global Summit · Lisbon · 8–11 February *"Over 150–180 attendees from more than 20 countries and 120 companies."***Named as an organiser:***"A dedicated organizing team (led by OWASP volunteers **including Dinis Cruz** and others) spent months preparing working session topics."* The format is the part that matters: *"**designed in a working session style format**"*, with *"**no vendor booths, no purely lecture-style talks to a passive audience**."* Attendees came from Google, Mozilla, Microsoft, PayPal, Facebook, Apache, Verizon and Dell. Outcomes: board elections by membership, the first full-time Executive Director, the Browser Security Report 2011, OpenSAMM v1.1, and the seeds of the OWASP Mobile Top Ten. Plus a detail worth pausing on — *"reportedly 'thousands' joined some sessions remotely via live streams or IRC, **a forward-thinking move in 2011**."* ### 2017 · Woburn Forest, UK · 12–16 June Five days. **173 sessions in total across the week**, with attendance in the low hundreds. **Named as primary organiser:***"organized by OWASP community leaders (with **Dinis Cruz, a long-time OWASP contributor, acting as a primary organizer and evangelist**)."* Open planning: *"proposed working sessions were gathered on a public wiki and interested participants could sign up."* Tracks covered Threat Modeling, SAMM, DevSecOps, Education, Mobile, CISO and Research. And the ethos, stated as a rule: ***"no spectators, only participants."*** ### 2018 onward · the Open Security Summit *"the concept of an open, working-session-based security summit was embraced outside the strict OWASP umbrella… **The Open Security Summit series explicitly built on the OWASP Summit 2017 model**, using the same 5-day intensive format for broader security topics."* > **And this is where the public record stops.** Why the series moved outside the OWASP umbrella, what changed, and its current state are part of the first-person account. [The questions are published below →](#interview) ## The lesson the summits taught, stated in the third person > "the **format became more purely collaborative over time**… OWASP learned that maximal value came from letting experts 'roll up their sleeves' together rather than having people passively watch slide decks." > "even in an era of constant virtual communication, **face-to-face collaboration can significantly accelerate progress on complex security problems**." > "OWASP maintained its stance that sponsor involvement should not compromise the neutrality of the content — sponsors contributed to logistical costs but did not get speaking slots or marketing displays at summits, preserving the collaborative, **vendor-neutral** atmosphere." ## The connection nobody has made The current agentic-team operating model — briefs with named outcomes, cross-team reviews, day-indexes, acceptance criteria on every brief, and *"no spectators"* as an implicit rule for agents — **is the OWASP working-session format applied to a company, and then to a set of AI agents.** That is a real, traceable line from a room in the Algarve in 2008 to an agent team in 2026, and it is one page. It is also the most interesting thing on this site for a reader who came for open source and did not expect a governance argument: **the summit format was a solution to the problem of getting expert attention onto hard problems without a vendor capturing the agenda** — which is, restated, [the funding problem](../funding/index.md) and [the neutrality problem](../survivability/index.md) at the same time. ## The OWASP monetisation thread — a live, unclaimed argument > "say you are an OWASP leader or member with a good reputation for a certain set of application-security skills… **One of the challenges today is that you do not have good revenue streams easily, apart from working for companies or doing consulting.** That is where skills come into play, because you should be selling those skills." And the sharper diagnosis: organisations *"either use the broad standards as-is… or **fork them into static custom guides, losing the benefit of OWASP's ongoing improvements**."* The proposal — a knowledge-graph working group, an ontology, machine-readable releases — is a finished argument that has never been executed. This is [the funding problem](../funding/index.md) in the same shape, applied to a specific community the author belongs to. That matters: it is **a proposal made from inside rather than a critique from outside**, which is the only position from which it lands. ## What is needed, stated as questions These are published rather than held privately, because the gap is the point. Thirteen questions, ready: **On OWASP.** What years on the board, and what did the role actually involve? Which projects were led or contributed to, and which mattered most? **Why is the current estate under `owasp-sbot` rather than a personal or company org — was that a deliberate statement?** What did OWASP get right that other foundations got wrong, and what did it get wrong? And, applying [this site's own stress test](../survivability/stress-test.md) to OWASP: who holds the trademark, what is the copyright structure, would it survive a hostile change of control? **On the summits.** Why did 2017 leave the OWASP umbrella and become the Open Security Summit? Does it still run? Where did *"no spectators, only participants"* come from, and did it work? The 2008 summit paid travel and accommodation for ~80 people — would that be possible now, and what did it buy? What did running four summits teach you that shows up in how the agent team is run today? **On the projects.****O2 Platform, MGraph-DB, OSBot, memory_fs, sgit-ai, Issues-FS — why was each one open-sourced?** Did anyone ever contribute? What happened when they did? What would you do differently? > **The model already exists.** The O2 Platform article — a real retrospective on the 2010–2012 OWASP SAST engine — shows what these accounts look like when written. It was written about the author rather than by him; the six retrospectives on [the build order](../roadmap/index.md#interview) are the first-person versions. [← cURL](../funding/curl.md)[What's next →](../roadmap/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /roadmap/index.html (markdown twin: /roadmap/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/roadmap/index.html* > What is built, what is next in order, and the open questions — seven still open, one decided — including whether the customer subset is open core, which funding model to back, and what the estate will change after its own stress test. --- # What's next The build order is published **with its open questions visible**, because a position that hides what it has not yet settled is advertising. This page is what is built, what is next in order, and the open questions — seven still open and one decided — several of which are decisions for the project rather than research tasks for the site. ## What is built | Section | State | Note | |---|---|---| | [**/views/**](../views/index.md) — the argument | shipped | The position, sovereignty, open core, the villagers. Each with its counter-case attached. | | [**/survivability/**](../survivability/index.md) | shipped | The argument, [the stress test as a working tool](../survivability/stress-test.md), and [the self-audit, run on the estate itself](../survivability/self-audit.md). | | [**/history/**](../history/index.md) | shipped | Six corrections leading, timeline behind them, six success stories, and [the numbers with the unpublishable ones named](../history/numbers.md). | | [**/practice/**](../practice/index.md) | partial | The three licences and [Apache-vs-MIT](../practice/apache-vs-mit.md) are written. Q5, the licence alignment, is decided: CC BY. | | [**/agents/**](../agents/index.md) | partial | The argument ships. **Four theses are named and next to be written** — the most original writing still available. | | [**/funding/**](../funding/index.md) | shipped | Three proposals compared for the first time, a position taken, and [cURL](../funding/curl.md). | | [**/owasp/**](../owasp/index.md) | partial | Summit history ships from the public record. **The first-person account is the author's to write**, and is planned. | | [**/founders/**](../founders/index.md) | shipped | [Owning the code, or opening it](../founders/index.md) — the guidance from a strategy session with another founder, released CC BY. | | [**/about/**](../about/index.md) | shipped | The author, the companies the strategy runs on, and interests declared. | | **Agent surface** | shipped | [Markdown twin at every URL, self-sufficient llms.txt, llms-full.txt](../practice/publish-the-source.md) — all three enforced in CI. | ## What is next, in order 1. **An SBOM of the estate, and a licence audit in CI.** The single highest-value item on the list: it is roughly a day's work and it converts [the labelling argument](../funding/index.md#labelling) from a proposal into a demonstration. The site asks companies to declare their supply chain; this is the estate's own declaration. One manual licence review exists (February 2026 — 17 transitive dependencies, an SPDX table, a clean verdict); the automated, continuous version is the item. 2. **The four agent-era theses** — [licence compliance at machine speed](../agents/index.md#compliance), [provenance of AI-generated code](../agents/index.md#provenance), [training-data licensing](../agents/index.md#training), and [what CC BY means for machine reuse](../agents/index.md#cc0). Each follows obviously from material that exists; none is written. 3. **A licence taxonomy.** Copyleft versus permissive as a position, compatibility, where AGPL fits, and how to treat source-available. [The history research supplies the ground](../history/index.md); the position is next. 4. **The first-person OWASP account, and six project retrospectives** — [thirteen questions, already published](../owasp/index.md#interview), that only the author can answer. O2 Platform, MGraph-DB, OSBot, memory_fs, sgit-ai, Issues-FS: why each was open-sourced, and what happened next. 5. **A trademark policy.**[The clearest quick win from the self-audit](../survivability/self-audit.md#change): publishing one costs almost nothing and removes the worst of the ambiguity even while the holder stays the same. 6. **Separately licensing the schemas.** The cheapest of the self-audit fixes, and there is no good argument against it. 7. **Visual assets.** A timeline, a licence-family diagram, a map of the estate. [The timeline](../history/timeline.md) and [the four-leg test](../survivability/stress-test.md) both want a picture. ## The open questions — seven open, one decided | # | Question | Where it stands | |---|---|---| | **Q1** | **Is the customer subset open core or packaging?** | [The test is proposed](../views/open-core.md#test): does the customer build contain anything the public repo does not? The June and July positions are both published, and the July document names the tension itself. **Needs a decision, not more analysis.** | | **Q2** | **Which funding model?** | [A position is now taken](../funding/index.md#position) — they address three different failures and were never competitors. Still: none costed, none piloted, and the value-contribution calculation unsolved. | | **Q3** | **Does the junior pipeline restructure, or break?** | [March and July say opposite things, four months apart.](../agents/index.md#pipeline) What would settle it is a cohort measurement nobody appears to be making. [The villagers argument depends on the July answer.](../views/villagers.md) | | **Q4** | **Would the estate change to pass its own stress test?** | [Leg by leg, with what each fix requires.](../survivability/self-audit.md#change) The honest answer on leg one may be *"no, and here is why that is an accepted risk"* — still publishable, and better than silence. | | **Q5** | **Was CC0 on the articles deliberate?** | **Decided, 6 September 2026: no — CC BY.** The CC0 in the published-articles repository was drift, not a third layer; the documents layer is CC BY 4.0 throughout and the repository's licence file follows. [Recorded on the practice page.](../practice/index.md#reading) | | **Q6** | **Do agents help or harm open-source sustainability?** | Current evidence says harm — [cURL's bounty closed 31 Jan 2026](../funding/curl.md), vulnerabilities reported up 107%. **Is that a transition cost or the steady state?** Nobody knows, and [this site declines to claim the optimistic answer](../agents/index.md#audience). | | **Q7** | **Is "open source AI" coherent without training data?** | The OSI's definition exists and drew heavy criticism; almost no model marketed as open source meets it. [The author's 2025 position, and a browser vendor now betting on the open-weight side of the line.](../agents/index.md#training) | | **Q8** | **What does this site owe a community it does not have?** | [The position that open source is right even with zero contributions](../views/index.md#zero-contributions) is coherent — and it means governance, review and codes of conduct are not yet written about here, despite [the survivability argument turning on DCO-versus-CLA in practice](../survivability/index.md#cla). The next contributor relationship is where that page gets written. | ## Where this site stops Several arguments here sit on a boundary with a sibling site, and the rule is **one canonical copy, cross-linked** rather than a duplicate on each. | Site | Owns | The shared edge | |---|---|---| | [wardley-maps.sgit.ai](https://wardley-maps.sgit.ai) | Mapping technique; Explorer/Villager/Town Planner as a pattern | ["Somebody has to be the villagers"](../views/villagers.md) — they own the pattern, this site owns the NFR market argument. | | [standards.sgit.ai](https://standards.sgit.ai) | Instruments, provisions, crosswalks, the SPDX machinery | [Licence compliance at machine speed](../agents/index.md#compliance) — they own the machinery, this site owns the argument. | | [graphs.sgit.ai](https://graphs.sgit.ai) | Graph theory, meaning through connectivity | Semantic OWASP and the PBOM. This site owns the *why*; graphs owns the *how*. | | [pki.sgit.ai](https://pki.sgit.ai) | Keys, signatures, the registry design | [Provenance of AI-generated code](../agents/index.md#provenance) — they hold the signing machinery, the licensing argument belongs here. | | [sgit.ai](https://sgit.ai) | The parent project and the vault layer | Should link *here* for the licence and sovereignty argument. | [← OWASP](../owasp/index.md)[The documents →](../documents/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /documents/index.html (markdown twin: /documents/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/documents/index.html* > The commissioning brief pack this site was built from, published whole and unedited: nine briefs, an 18,000-word history research document, and a 55-row source manifest. The raw markdown is the source of truth. --- # The documents A site that argues you should [publish the source next to the render](../practice/publish-the-source.md) owes a reader its own. These are the briefs this site was built from, published **whole and unedited**. Where a page here summarises, disagrees with, or declines to follow one of them, **the raw markdown is the source of truth** and you can check. > **How to read these.** The brief pack was written *to* the agent commissioning this site, so it reads as instructions rather than as content — including instructions this site did not follow, and open questions it could not close. That is the useful part. [Where the site diverges from the brief is listed at the bottom of this page.](#divergences) ## The commissioning brief pack | Document | What it holds | Where it landed | |---|---|---| | [**00 — The brief**](../briefs/00__brief.md) | The commission, the honest split across the three asks, the thesis, the five pages only this author can write, the two dated changes of position, and the build order. | [Front page](../index.md), [build order](../roadmap/index.md) | | [**01 — Concepts index**](../briefs/01__concepts-index.md) | All 56 concepts with verbatim quotes, paths and dates, classified as widely-held, personal position, or original argument. **24 originals.** | [The position](../views/index.md) | | [**02 — The practice**](../briefs/02__practice.md) | The three-licence estate, the CC0 discovery, publish-the-source-next-to-the-render, the read-key discipline, and the compliance gap. | [Practice](../practice/index.md), [publish the source](../practice/publish-the-source.md) | | [**03 — The history, and how to use it**](../briefs/03__history-and-success-stories.md) | The editorial guidance: lead with corrections not a timeline, pick six success stories not fourteen, and the numbers to handle carefully. | [History](../history/index.md) | | [**04 — The arguments**](../briefs/04__the-arguments.md) | Survivability, the stress test, open core, funding, sovereignty, the villagers — with the counter-case for each. | [Survivability](../survivability/index.md), [funding](../funding/index.md), [views](../views/index.md) | | [**05 — Agents and open source**](../briefs/05__agents-and-open-source.md) | Code-reading as the scarce asset, the March/July change of position, and **four theses that are named nowhere and written nowhere.** | [Agents](../agents/index.md) | | [**06 — OWASP and the summits**](../briefs/06__owasp-and-the-summits.md) | The OWASP thread, four summits, and the interview that has to happen — thirteen questions ready. | [OWASP](../owasp/index.md) | | [**07 — Architecture and boundaries**](../briefs/07__site-architecture-and-boundaries.md) | The house pattern, the quoting table, do-not-publish, and the network boundaries between sibling sites. | [Boundaries](../roadmap/index.md#boundaries), and this site's structure | | [**08 — Gaps and open questions**](../briefs/08__gaps-and-open-questions.md) | Ten build-fresh items, eight open questions, eight honest tensions. | [What's next](../roadmap/index.md), [open questions](../roadmap/index.md#open) | | [**09 — Source manifest**](../briefs/09__source-manifest.csv) | 55 rows: every source tiered 0–3 with its proposed page and publishability. Every path verified on disk. | Provenance for the whole pack | ## The history research | | | |---|---| | [**research — the history, from scratch**](../briefs/research__history-and-success-stories.md) ~18,000 words · compiled 24 August 2026 | The single largest document behind this site, and the reason [the history section exists at all](../history/index.md): the author's writing contained **no history of open source**, so one was researched. A sourced timeline 1955→2026, fourteen success stories, two instructive failures, an evidence table, seven both-sides arguments, seventeen corrected myths, and a source list that separates what was fetched from what was only search-derived. **It reports its fetch failures inline rather than working around them**, and marks several facts as not verified. [Those are listed on this site as unpublished](../history/numbers.md#unverified) rather than quietly promoted to established. | ## The pack's own front matter - [**README**](../briefs/README__brief-pack.md) — the reading order, and the four things the pack said would shape the build. - [**LICENSE**](../briefs/LICENSE__brief-pack.md) — CC BY 4.0, the three-licence problem, and the quoting table that governs how this site handles other people's material. ## Where this site diverges from the brief Publishing the instructions makes the divergences checkable, so they are stated rather than left to be found. | The brief said | What was done, and why | |---|---| | **"Resolve the licensing inconsistency *before* writing a word"** — it is described as blocking the practice section. | **Resolved by the author on 6 September 2026: CC BY.** Until then [both readings were published and neither picked](../practice/index.md#reading), because declaring an intention on his behalf would have been the tidying this site argues against. The decision is recorded on the practice page and [Q5 is closed](../roadmap/index.md#open). | | **"Copy `pki.sgit.ai`. Add the `/llms-full.txt` it lacks."** | **Done, and extended.** Same CI pipeline (validate → tag → deploy), same chrome tooling. `llms-full.txt` ships, and so does [a markdown twin at every URL](../practice/publish-the-source.md#ladder) — generated, and **enforced by the build** rather than maintained by hand. | | **"Ship the stress test as a form or checklist, not an essay."** | **Done** — [it runs in the browser](../survivability/stress-test.md), keeps your answers locally, and exports a markdown summary. Nothing is sent anywhere. | | **"Ship `/practice/` with an SBOM, or state the gap with a date."** | **Stated as a gap, without a date** — which the brief itself calls the weaker of the two options. It is [first on the build order](../roadmap/index.md#supply-chain). | | **Publish market figures from the villagers brief.** | **Declined.** The brief flags them as loosely attributed and notes that much of what circulates is vendor commentary recycling a smaller set of studies. [They are omitted, and the omission is stated on the page.](../views/villagers.md#numbers) | | **Do not publish a marked-unverified fact as established.** | **Followed.**[The unverifiable claims have their own section](../history/numbers.md#unverified), naming what was not established and why, rather than being silently dropped. | > **On quoting other people's material.** This site quotes the open-source world at length, under the rules in the pack's licence file: Wikipedia material is CC BY-SA and is **quoted with attribution rather than adapted**; project documentation is quoted briefly and never mirrored; **vendor and analyst reports are cited by number, source, date and caveat, and their charts are never reproduced**. Naming projects, foundations, licences and the public authors of public work is fine and necessary. [Running the stress test on a named commercial competitor and publishing a scorecard is not](../survivability/stress-test.md#notascorecard) — we ship the test and let readers run it. [← The build order](../roadmap/index.md)[About the author →](../about/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /about/index.html (markdown twin: /about/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/about/index.html* > Dinis Cruz — founder of The Cyber Boardroom, MyFeeds.ai, RiskMandate.ai, VoiceDebrief.ai and the sgit.ai network (commercialised through sgraph.ai); former OWASP Board member and organiser of the OWASP Summits; creator of the O2 Platform. This site is the open-source strategy those companies run on, written from the experience of running it — with the author's interests declared. --- # Dinis Cruz This site is my position on open source — what it is for, how to practise it, and the history that supports it. It is written from the experience of building, open-sourcing and running security software and companies, and it is **the strategy those companies actually run on**: everything they ship is open source, and so are their investor materials. ## The record | Role | What it involved | |---|---| | **Founder, [sgit.ai](https://sgit.ai)** | Encrypted vaults with git semantics — clone, commit, branch and merge files encrypted before they leave your machine — under Apache-2.0, and the [network of nineteen sites](https://sgit.ai/network/index.html) of which this is one. Each site publishes its argument before its implementation, so the commitments are checkable. | | **Founder, [sgraph.ai](https://sgraph.ai)** | Where the strategy turns into revenue: the commercial home of **SG/Send**, the secure file-sharing service built on the open-source sgit layer, and the place that sells access to **SG/Vaults** — hosted sgit vaults. The code stays Apache-2.0; what is sold is the running, maintained, certified service, which is [exactly where this site says the commercial line belongs](../views/index.md#not-the-moat). | | **Founder, [MyFeeds.ai](https://investor.myfeeds.ai/)** | Role-aware cybersecurity briefings built on semantic knowledge graphs — CISO, engineer and board views of the same news, with source attribution. **100% open source, serverless, no vendor lock-in.** The seed pitch, use of funds and unit economics are [published in the open](https://investor.myfeeds.ai/). | | **Founder, [The Cyber Boardroom](https://thecyberboardroom.com)** | An AI-powered platform for the conversation between technical security teams and the board — bridging the two with knowledge-graph technology. Apache-2.0, with the community edition, the website and the automation in public repositories. | | **Founder, [RiskMandate.ai](https://riskmandate.ai)** | The business risk layer for autonomous systems. The newest of the startups, alongside VoiceDebrief. | | **Founder, [VoiceDebrief.ai](https://voicedebrief.ai)** | Voice recordings into transcripts and debriefs, entirely in the browser — no account, and nothing uploaded to a server. The ["ask for keys at run time, store nothing"](../founders/index.md#week) habit from the founders' page, shipped as a product. | | **Former OWASP Board member** | And organiser of the OWASP Summits — [Lisbon 2011 and Woburn 2017](../owasp/index.md#summits), the working-session format with *"no spectators, only participants"* that the Open Security Summit series went on to build on. Current open-source work still ships under the `owasp-sbot` organisation, with `MGraph-DB` publicly credited to the OWASP community. | | **Creator, the O2 Platform** | The OWASP static-analysis engine of 2010–2012, and the first of a line of open-source tooling that continues in the `osbot-*` and `mgraph-*` families, `memory_fs`, `Issues-FS` and `sgit-ai` — [all Apache-2.0, all on PyPI](../practice/index.md#published). | ## Built in the open, including the parts most companies keep closed The argument on this site is that [open source is a strategy rather than a charity](../views/index.md), and the strongest evidence I can offer for it is that I run companies on it. That extends past the code: - **The code** is Apache-2.0. **The working documents** — roughly 1,100 of them — are CC BY 4.0. **The published essays** at [docs.diniscruz.ai](https://docs.diniscruz.ai) are CC BY 4.0 as well — decided on 6 September 2026, after that repository's licence file was found to say CC0; the file follows. [Two licences, three layers, and what each is for →](../practice/index.md#reading) - **The investor materials are public.**[MyFeeds.ai's investor relations site](https://investor.myfeeds.ai/), its [source repository](https://github.com/the-cyber-boardroom/MyFeeds-AI__Investor_Relations), and [The Cyber Boardroom's investment repository](https://github.com/the-cyber-boardroom/cbr-investment) are on GitHub rather than behind a data room. If technology is not the moat, neither is the pitch deck. - **This site's own source** — every page as markdown, the build tooling, the briefs it was written from — is [in the repository](https://github.com/SGit-AI/SGit-AI__Website__Open-Source), and the estate is run through [its own stress test](../survivability/self-audit.md) with the result published. - **The advice is published too.**[Owning the code, or opening it](../founders/index.md) is the reasoning from a strategy session with another founder, released CC BY so that it applies to every founder asking the same question. ## Interests declared I run companies whose strategy this is, and which sell maintenance, quality and certification rather than code — [the market this site describes](../views/villagers.md) is one I intend to be in. Read the argument knowing that. Two things are built in to keep it honest: - **The history is checkable without trusting me.** Every claim in [the six corrections](../history/index.md) and [the timeline](../history/timeline.md) carries its source and date, and several of them cut against the story that would flatter the argument. [The numbers this site declines to publish](../history/numbers.md) are the ones that would have helped it. - **The tool works without me.**[The stress test](../survivability/stress-test.md) is answerable from public artefacts and runs entirely in your browser; nothing is sent anywhere. And rather than publish verdicts on named competitors, [it is run on my own estate](../survivability/self-audit.md), in public, with what each leg would take to change. ## Reach me, or correct me [↗ LinkedIn](https://www.linkedin.com/in/diniscruz) is the fastest route. Corrections and requests for this site are tracked in the open on [the comms board](../admin/comms.md), and [the repository](https://github.com/SGit-AI/SGit-AI__Website__Open-Source) takes issues and pull requests. If you find something wrong here, I would rather know. [← The documents](../documents/index.md)[Admin & engineering →](../admin/index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /admin/index.html (markdown twin: /admin/index.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/admin/index.html* > The build tooling, the CI pipeline (validate → auto-tag → deploy), the release process, and the markdown-twin generator that makes the site traversable by agents. Published, because a site arguing you should publish the source should publish its own. --- # Admin & engineering Every page here is hand-written static HTML, deployed to GitHub Pages from `dev`. What is *not* hand-maintained is the chrome, the markdown twins and the agent surfaces — those are generated, and CI fails the build if what was committed does not match what the generators produce. ## The pipeline Same order as the sibling sites — **validate → tag → publish** — because a release that cannot be validated should never acquire a tag, and a release that was never tagged should never reach the web. | Stage | What it does | What stops the release | |---|---|---| | **1 · validate** also on pull requests | Regenerates the markdown twins and `llms-full.txt`, then fails if the working tree changed — so a stale generated surface is caught rather than shipped. Then `node admin/build/validate.js`. | A failure here means **no tag and no publish**. Running on pull requests means branch work is gated before it can reach the release branch. | | **2 · tag-release** pushes to `dev` only | Every push to `dev` is a minor release, tagged `v{release}.{major}.{minor}`. The version is owned by `admin/build/version.txt` and **must also appear in the release commit's subject** (`site vX.Y.Z: …`). CI verifies the two agree and that the bump is the next minor (or a deliberate major), then tags **the release commit** — which is HEAD on a direct push and HEAD's parent when a pull request lands as a merge. | Version disagreement, a reused version, or a skipped minor. The first run also **backfills tags** for any historical release from the commit subjects. | | **3 · deploy** | Publishes the tagged commit to GitHub Pages. Runs on manual dispatch even without a tag. | **Never runs when validation failed**, and never from a pull request. | ## What validation actually checks 1. **Version agreement** — `version.txt` against every page's version badge, the versions table, `llms.txt` and `llms-full.txt`. It also catches a release listed twice in the history table, which is what a blanket version-bump `sed` produces and which shipped once on a sibling site. 2. **Internal links** — every relative `href` and `src` in every page resolves to a file that exists. 3. **Canonical host** — every `rel="canonical"` and `og:url` points at the host in `CNAME`, and **every page has one**. 4. **Markdown twins** — every `.html` has its `.md` twin, `llms-full.txt` carries every page, and `llms.txt` lists every twin. [The site's agent-discovery argument rests on this](../practice/publish-the-source.md), so a missing twin is a release-stopping defect rather than a nice-to-have. 5. **Licence footers** — every markdown file carries the CC BY 4.0 line. The site holds others to declaring their licensing; it does not get to be sloppy about its own. 6. **Key-leak tripwire** — nothing anywhere in the tree may look like a vault key. This site discusses keys; it must never contain one. ## The build tooling | File | What it owns | |---|---| | `admin/build/version.txt` | **The version.** One file, bumped exactly once per release. Everything else derives from it. | | `admin/build/chrome.py` | **The single definition of the nav and footer**, applied across every page. Pages stay hand-written; the chrome does not drift. It also stamps the version into `llms.txt`, because hand-editing it silently missed twice on a sibling site. | | `admin/build/gen_markdown.py` | **The markdown twin of every page**, plus `llms.txt` and `llms-full.txt`. Converts the HTML, **rewrites internal `.html` links to `.md`** so a traversing agent never leaves the markdown surface, and concatenates everything into one file for agents that cannot follow links at all. No dependencies — it has to run in CI with nothing installed. | | `admin/build/validate.js` | **The pre-release gate.** Node with no packages, for the same reason. | | `assets/site.css`, `assets/nav.js` | The shared sgit.ai design language and the two-level nav component. | | `assets/stress-test.{css,js}` | [The Change-of-Control Stress Test](../survivability/stress-test.md). Entirely client-side; answers persist in `localStorage` and are never transmitted. | ## The release process 1. Bump `admin/build/version.txt` (`vX.Y.Z`, **exactly once per release**) and add a row to [`admin/versions.html`](versions.md); update [`admin/comms.html`](comms.md). 2. `python3 admin/build/chrome.py` — propagates the version badge and any nav or footer change to every page. 3. `python3 admin/build/gen_markdown.py` — regenerates the twins, `llms.txt` and `llms-full.txt`. 4. `node admin/build/validate.js` 5. `git commit -am "site vX.Y.Z: …" && git push origin dev` > **The commit subject is load-bearing.** CI reads the version out of it and refuses to tag if it disagrees with `version.txt`. That is deliberate: it means the version cannot be bumped in a file without someone also saying so in the history, and the tag always lands on the commit that claims to be the release. ## Why any of this is published Because [the argument of this site is that you should publish the source next to the render](../practice/publish-the-source.md), and a site making that argument with an opaque build would be making it badly. The repository is public, the generators are readable, and [the briefs the content was written from are published verbatim](../documents/index.md) — including [the instructions this site did not follow](../documents/index.md#divergences). [← About the author](../about/index.md)[Comms →](comms.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /admin/comms.html (markdown twin: /admin/comms.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/admin/comms.html* > The open board: the items only the author can supply, and the tasks the site is carrying. Numbered, dated, and published rather than held privately. --- # Comms: tasks & requests The open board. **Needs (N)** are items only the author can supply — first-person accounts and decisions. **Tasks (T)** are work the site can do. Both are published rather than held privately, because [publishing the build order with its open questions visible](../roadmap/index.md) is the house rule. ## Needs — only the author can answer these | # | What is needed | What it unblocks | State | |---|---|---|---| | **N1** | **Was CC0 on `docs.diniscruz.ai` deliberate?** Answered 6 September 2026: **no — CC BY.** The documents layer is CC BY 4.0 throughout; replacing that repository's `LICENSE` file is the follow-through. | [The practice section](../practice/index.md#reading) now records the decision, and [thesis (d)](../agents/index.md#cc0) is reframed as what CC BY means for machine reuse. | answered | | **N2** | **The OWASP interview** — [thirteen questions, published in full](../owasp/index.md#interview). Board tenure and what the role involved, projects led, whether `owasp-sbot` hosting was deliberate, why 2017 left the OWASP umbrella, and whether the Open Security Summit still runs. | [The whole OWASP section](../owasp/index.md), which currently ships the summit history in the third person and marks the rest pending. | open | | **N3** | **Why was each project open-sourced?** O2 Platform, MGraph-DB, OSBot, memory_fs, sgit-ai, Issues-FS. **Six published projects, not one retrospective** — the O2 article being the exception, and written about him rather than by him. | A retrospectives section, and it would make [the practice page](../practice/index.md#published) something other than a list of packages. | open | | **N4** | **Q1: is the customer subset open core or packaging?**[The test is proposed](../views/open-core.md#test) — does the customer build contain anything the public repo does not? — and the answer is a fact about the product that only the project knows. | [The open-core page](../views/open-core.md) can then state a verdict rather than a test. | open | | **N5** | **Q4: will the estate change to pass its own stress test?**[Leg by leg, with what each fix requires.](../survivability/self-audit.md#change)*"No, and here is why that is an accepted risk"* is a publishable answer. | [The self-audit](../survivability/self-audit.md), which records the result and can then record the plan. | open | | **N6** | **Confirmation of the summit facts** restated here from the author's own summit history — attendance figures, the 2008 travel funding, the 173 sessions at Woburn. | Removes the last third-hand layer from [the summit section](../owasp/index.md#summits). | open | ## Tasks — work this site can do | # | Task | State | |---|---|---| | **T1** | **CI pipeline and auto-tagging** — validate → tag → deploy, matching the sibling sites. [Documented →](index.md#pipeline) | done | | **T2** | **The agent-discovery ladder** — markdown twin at every URL, self-sufficient `llms.txt`, `llms-full.txt`, all generated and **enforced by the build**. [Read →](../practice/publish-the-source.md#ladder) | done | | **T3** | **The stress test as a working tool** rather than an essay — four legs, client-side, exportable. [Run it →](../survivability/stress-test.md) | done | | **T4** | **The self-audit, published in full.**[Read →](../survivability/self-audit.md) | done | | **T5** | **Why Apache-2.0 rather than MIT** — the most conspicuous unwritten page in the brief. [Read →](../practice/apache-vs-mit.md) | done | | **T6** | **An SBOM of the estate, plus a licence audit in CI.** Roughly a day's work, and it converts [the labelling argument](../funding/index.md#labelling) from proposal to demonstration. [First on the build order.](../roadmap/index.md#supply-chain) | next | | **T7** | **The four agent-era theses** — [named on the agents page, none written](../agents/index.md#unwritten). The most original writing still available. | open | | **T8** | **A licence taxonomy** — copyleft vs permissive as a position, compatibility, AGPL, source-available. [The history research supplies the ground.](../roadmap/index.md#taxonomy) | open | | **T9** | **A published trademark policy** — [the clearest unforced gap in the self-audit](../survivability/self-audit.md#change), and it costs almost nothing. | open | | **T10** | **Separately license the schemas** (CC0 or CC BY), which is the cheapest self-audit fix and has no argument against it. | open | | **T11** | **Visual assets** — a timeline, a licence-family diagram, a map of the estate. [On the build order.](../roadmap/index.md#visual) | open | | **T12** | **Verify the marked-unverified facts** in the research document — several founding dates and licences are flagged. [Nothing flagged has been published as established.](../history/numbers.md#unverified) | open | | **T14** | **Link the sources this site names.**[The HBS paper](../history/numbers.md#88tn) and [the Mozilla interview](../agents/index.md#training) are now linked; **OSSRA, the Stack Overflow survey, the kernel release notes and the Let's Encrypt telemetry are still named without a URL**. A site whose credibility position is that it checks other people's citations should make its own followable — by a reader and by [the agents it says are its primary audience](../agents/index.md#audience). | open | | **T13** | **Get indexed** — [the top rung of the ladder, and the real fix](../practice/publish-the-source.md#ladder). The other three rungs are shipped. | open | ## Corrections None yet — the site is new. Corrections will be recorded here with the date and what changed, rather than being applied silently. [A site that corrects other people's numbers](../history/numbers.md) has to show its own working when it gets something wrong. [← Admin & engineering](index.md)[Release history →](versions.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).* ============================================================================== PAGE: /admin/versions.html (markdown twin: /admin/versions.md) ============================================================================== *[open-source.sgit.ai](/index.md) · site v0.2.2 · canonical: https://open-source.sgit.ai/admin/versions.html* > Site release history. Every push to dev is a release, validated then auto-tagged by CI against the version in admin/build/version.txt and the release commit's subject. --- # Release history Every push to `dev` is a release: CI validates the site, verifies the version bump, tags the commit `v{release}.{major}.{minor}`, and deploys to GitHub Pages. The version is owned by `admin/build/version.txt` and must agree with the release commit's subject. [How the pipeline works →](index.md#pipeline) | Version | Date | What shipped | |---|---|---| | v0.2.2 | 6 Sep 2026 | **Q5 decided: CC BY.** The one open question that only the author could answer — whether the CC0 licence on the published-articles repository was a deliberate third layer or drift — is answered: drift. The documents layer is CC BY 4.0 throughout, and the estate has two licences across three layers: Apache-2.0 for code, CC BY 4.0 for everything written. Recorded on [the practice page](../practice/index.md#reading) (which still reports the CC0 file as it is on disk, until it is replaced), on [the roadmap](../roadmap/index.md#open), on [the comms board](../admin/comms.md) (N1 answered), in the documents divergence table, and in the README. [Thesis (d)](../agents/index.md#cc0) is reframed from "what CC0 means for machine reuse" to what CC BY means — attribution as the one obligation that survives into a synthesised output. | | v0.2.1 | 6 Sep 2026 | **The company list, corrected by the author.** Akeia.ai removed — he has stepped down from it. [RiskMandate.ai](https://riskmandate.ai) and [VoiceDebrief.ai](https://voicedebrief.ai) added as the most recent startups. And [sgraph.ai](https://sgraph.ai) added as the place where the strategy has started to turn into revenue: the commercial home of SG/Send, and where access to SG/Vaults — hosted sgit vaults — is sold, with the code staying Apache-2.0. On [the about page](../about/index.md), the front page byline and author section, and the README. | | v0.2.0 | 6 Sep 2026 | **The site becomes the author's position, written as one.** The first release read as an audit of its own material — a "where this site is weak" section on the front page, a "what is missing" page, a "where we lose" disclosure, a stage pill reading *first draft*, and argument pages that described the author's writing as "the corpus" arguing with itself. That framing undersold work that is, in substance, a founder's strategy backed by a shipping estate. This release keeps every counter-case and every open question, and drops the self-deprecation. **New: [Owning the code, or opening it](../founders/index.md)** — guidance for founders from a strategy session with an early-stage SaaS founder: what copying the code would actually cost an incumbent, four instincts and their counter-arguments, the explorer–villager–town-planner frame, eight steps in order, and what a week of building in the open looks like when it is counted. Released CC BY; attribution Dinis Cruz and Kate Curtis-Evans. It is the first section on the front page and the first group in the nav.**New: [About the author](../about/index.md)** — Dinis Cruz, the companies the strategy runs on (sgit.ai, MyFeeds.ai, The Cyber Boardroom), the OWASP record, the tooling lineage from the O2 Platform, and the investor materials published in the open. Interests are declared on the same page, in two paragraphs rather than a discount table. Replaces `about/participant.html`.**Folded: `shipped/index.html` into [What's next](../roadmap/index.md).** The forward-looking content — what is built, what is next in order, eight open questions — was already on the roadmap; the duplicate page that restated it as a list of failings is gone, and every link to it now lands on the corresponding item.**Reworded across the site:** the front page (byline under the hero, founders first, the weakness section replaced by what's next, the author section), the self-audit (a result and a plan rather than "we fail leg one"), the practice page (three layers with a job each, and one alignment question, rather than "an inconsistency nobody had noticed"), open-core and agents (a position that moved between two dates, rather than a contradiction), funding, OWASP, history, numbers, and the footer — which now carries the author line instead of a warning triangle. The markdown twins, `llms.txt` and `llms-full.txt` regenerate from all of it. | | v0.1.2 | 6 Sep 2026 | **Two external sources cited, where the site had been naming sources without linking them.**[The numbers page](../history/numbers.md#88tn) now links the **HBS AI Institute** summary of working paper 24-038 — the origin of the $8.8tn figure it spends a section correcting — with its authors, its data sources, and the two concentration findings in it that are more useful than the headline. A page whose credibility position is that it checks other people's citations should carry its own. **And [the training-data thesis](../agents/index.md#training) acquires a dated instance.** Mozilla's chief executive, interviewed by **The Deep View** in August 2026, is shipping model choice in Firefox and backing **open-weight** models on lock-in grounds — making this site's standards-and-control argument, in his own words, about models rather than code. Cited with the caveat it needs: it is positioning from an interested party, and it [sharpens Q7](../roadmap/index.md#open) rather than settling it, because open weight is the category the OSI's definition excludes. | | v0.1.1 | 25 Aug 2026 | **The build tooling was never committed.** The repository's stock Python `.gitignore` carries a bare `build/` rule, which silently swallowed the whole of `admin/build/` — `chrome.py`, `gen_markdown.py`, `validate.js` and `version.txt`. Everything passed locally, where the files exist; the first CI run failed at once, on the very first step, because they were not in the checkout. Fixed with the same `!admin/build/` negation the sibling sites carry. Recorded here rather than amended away, because [a site that publishes its own failed audit](../survivability/self-audit.md) does not get to quietly rewrite a bad release out of its history. It is also a small illustration of the pipeline working as intended: **the release that could not be validated never got a tag and was never published.** | | v0.1.0 | 25 Aug 2026 | **First release.** The site, built from the commissioning brief pack, which is [published verbatim alongside it](../documents/index.md). **The pipeline first**, matching the sibling sites: validate → auto-tag → deploy, with the version owned by one file and verified against the release commit's subject. Validation additionally enforces the things this site's own argument depends on — **a markdown twin at every URL**, `llms-full.txt` carrying every page, and a CC BY 4.0 footer on every markdown file.**The content:**[the position](../views/index.md) with every argument carrying its counter-case; [survivability](../survivability/index.md) with [the stress test as a working tool](../survivability/stress-test.md) and [a self-audit run on the estate itself](../survivability/self-audit.md); [six corrections](../history/index.md) leading the history rather than a timeline; [the three-licence estate](../practice/index.md) and [the Apache-vs-MIT page that existed nowhere](../practice/apache-vs-mit.md); [agents](../agents/index.md); [the three funding proposals compared for the first time](../funding/index.md) and [cURL](../funding/curl.md); [the summit history](../owasp/index.md); and the build order with its open questions visible.**Two things deliberately not done:** the CC0/CC BY licensing question is [published unresolved](../practice/index.md#reading) rather than settled on the author's behalf, and the SBOM the site tells other people to publish [is first on the build order rather than shipped](../roadmap/index.md#supply-chain). Both are [recorded as divergences from the brief](../documents/index.md#divergences). | > **Reading a version number.**`v{release}.{major}.{minor}` — every push to `dev` increments the minor. CI refuses a tag that is not the next minor (or a deliberate major), and refuses one where `version.txt` and the commit subject disagree, so the history above cannot silently skip a release. [← Comms](comms.md)[Front page →](../index.md) --- *This page is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).*