License-Only Versus Stewarded Open Source  🔗 **Source:** [License-Only Versus Stewarded Open Source](https://dri.es/license-only-versus-stewarded-open-source) > [!note]+ Document Notes > > [!info] Provenance > > **Analysis generated:** 2026-08-27 by Claude (Opus 5) via the `readwise-deep-read` pipeline. > > **Source:** dri.es — https://dri.es/license-only-versus-stewarded-open-source > > **Length:** 528 words · article · **Author:** **Dries Buytaert** (creator of Drupal, co-founder of Acquia) > > **Register key:** `[STATED]` author-stated · `[EVIDENCE]` demonstrated · `[INFERENCE]` reviewer inference · `[RECOMMEND]` reviewer recommendation. > > **Coverage:** Full article read. Short by design — a vocabulary post rather than an argument post. > > **Series note:** `[INFERENCE]` This is the **taxonomy** the other two posts assume. Read in order it goes: *this* (what kind of project is it?) → `dries_open-source-infrastructure-business-model.md` (who pays for it?) → `dries_open-source-cost-allocation-system.md` (how does architecture decide?). **The newest post is the least self-sufficient of the three**, which is what caused my error this morning. > > **Disclosed interest:** `[INFERENCE]` Acquia is the largest commercial beneficiary of Drupal, which is the paradigm case of "stewarded." Noted for calibration. > > # 🏷️ Title: License-only versus Stewarded Open Source > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References `[EVIDENCE]` **No outbound links and no external citations.** The piece is a definition, not an argument from evidence. ## 📝 Summary **The distinction.** | | **License-only Open Source** | **Stewarded Open Source** | |---|---|---| | What it is | `[STATED]` *"code released under an Open Source license, without active stewardship or any promise of ongoing care"* | `[STATED]` *"code cared for as shared infrastructure"* | | What you get | `[STATED]` *"no guarantee of updates, fixes, security response, or long-term support"* | `[STATED]` maintainers who *"review contributions, fix bugs, respond to security issues, manage releases, provide long-term support"* | | Who pays | Nobody, by design | `[STATED]` *"Organizations fund maintainers, support core development, donate infrastructure, and absorb costs end users never see"* | | Obligation to contribute | `[STATED]` *"no one is required to contribute, and that is the point"* | `[STATED]` *"the question is not only what the license allows, but who helps carry the responsibilities beyond what the license requires"* | **The observation that motivates it.** `[STATED]` *"A weekend hobby project and business-critical software can ship under the exact same license. **Legally, they look identical. Practically, they are worlds apart.**"* **The two lines worth keeping.** - `[STATED]` *"The license makes code available; **stewardship makes it dependable**."* - `[STATED]` *"**Responsibility is the tax on relevance.**"* **Bottom line.** `[INFERENCE]` A clean, useful vocabulary with one real gap: **it gives you two categories and no way to tell which one you are depending on** — which is the question a consumer actually has. ## 📖 Main Content ### The warranty disclaimer is read fairly, which is the piece's best move `[STATED]` *"Near the end of most Open Source licenses, usually in capital letters, sits a clause that disclaims almost everything: no warranty, no liability, use at your own risk."* And: `[STATED]` *"For an organization that depends on that code, the clause is harsh. If the code fails and takes your data or revenue with it, the license owes you nothing."* `[EVIDENCE]` Then the defence, immediately: `[STATED]` *"That is the license doing its job. It makes the code available and protects the people who share it. Without that protection, sharing code could become a gift that backfires: **a generous act turned into unlimited legal risk**."* `[INFERENCE]` **Establishing that the disclaimer is correct before arguing that it is insufficient is what makes the rest land.** The easy version of this argument treats the warranty clause as a loophole; this treats it as load-bearing and then asks what it does *not* cover — which is a different and more honest question. `[STATED]` The boundary he draws: *"the license can only answer the legal questions: who may use the code, on what terms, and what risk the authors are willing to accept. **It cannot tell you what kind of Open Source project you are working with.**"* ### The gap: there is no test `[INFERENCE]` **The taxonomy's whole value is giving consumers vocabulary for a distinction they need to act on — and the piece supplies no way to determine which side a given project is on.** `[INFERENCE]` The signals a consumer might use are all unreliable: - **Release cadence** — a stewarded project between releases looks dormant. - **Responsiveness** — a well-run license-only project with a generous maintainer looks stewarded, right up until that person stops. - **Funding** — invisible from outside, which is precisely the problem the third post in this series is about. - **A foundation or company behind it** — Drupal has one; so do abandoned projects. `[RECOMMEND]` **The practically useful version is a question a consumer can ask the project directly:** *what happens to a security report on a weekend?* `[INFERENCE]` That single question discriminates better than any of the above, because stewardship is precisely the commitment to respond when nobody feels like it. `[INFERENCE]` **And the more uncomfortable point the piece avoids: the category can change without notice.** A project is stewarded until its funding ends or its maintainer burns out, and **nothing in the licence or the repository signals the transition.** The Duck Alignment piece elsewhere in this batch — inactive maintainers as a standing liability — is that transition observed from the security side. ### "Responsibility is the tax on relevance" is the strongest line and the least examined `[STATED]` *"The difference is stewardship. The license makes code available; stewardship makes it dependable. **And the more people or organizations depend on a project, the more stewardship it often requires. Responsibility is the tax on relevance.**"* `[INFERENCE]` **The sentence is doing two things and only one is defensible as stated.** As a description — *popular projects demand more maintenance* — it is obviously true and useful. As a prescription — *if your project became popular you now owe more* — **it is exactly the obligation the warranty disclaimer exists to refuse.** `[INFERENCE]` He is careful in the contribution section (*"the license may still require nothing"*), and the aphorism is not. `[INFERENCE]` **The phrase most likely to be quoted is the one carrying the strongest unearned claim** — a maintainer whose weekend project got popular did not sign up for a tax, and "relevance" was not something they chose. `[RECOMMEND]` The honest reading, and I think his intended one: **the tax is real and falls on someone; the question is whether it falls on the maintainer by default or is deliberately distributed.** That is the argument of the other two posts, and this line is the bridge to them. ### The contribution argument is where the taxonomy earns its keep `[STATED]` *"If a company depends on Open Source, should it give back?"* `[EVIDENCE]` And the answer is genuinely bifurcated rather than rhetorical: - **License-only:** `[STATED]` *"no one is required to contribute, and that is the point. The code was shared freely, without a promise of care or an expectation of return."* - **Stewarded:** `[STATED]` *"The license may still require nothing, but the work does not happen for free. Someone is paying to keep your code usable, secure, and available."* `[INFERENCE]` **Conceding the license-only case fully is what makes the stewarded case persuasive.** A version that argued *all* open-source consumption creates obligation would be easy to dismiss; this one identifies the specific circumstance under which the question is even coherent — **someone is currently paying, and you are benefiting from that payment.** `[EVIDENCE]` And the closing reframes the disclaimer rather than arguing against it: `[STATED]` *"**The license says use at your own risk. Stewardship is what happens when people decide you should not have to.**"* `[INFERENCE]` That is the piece's best sentence: **stewardship as a voluntary act that the licence neither requires nor prevents.** It leaves the disclaimer intact and locates the obligation in a social commitment rather than a legal one — which is both more accurate and harder to enforce, and the piece does not pretend otherwise. ### Where it sits against the rest of the series `[INFERENCE]` Reading all three, the argument is a chain and each post supplies what the next assumes: 1. **This post:** there are two kinds of open source, and the licence cannot tell you which you have. 2. **Infrastructure post:** stewardship costs money, nobody has a mechanism to collect it, and *"whoever funds the infrastructure controls it."* 3. **Cost-allocation post:** the allocation is set by **architecture**, usually without anyone deciding. `[INFERENCE]` **The taxonomy is the weakest link and the load-bearing one.** Everything downstream depends on "stewarded" being a category you can identify — because the argument that beneficiaries should help fund stewardship requires knowing that a project is stewarded. **No test is offered here or in the other two.** ## 🗒️ Notes - **The piece is 528 words and does one job.** `[INFERENCE]` Unusual discipline: it introduces a distinction, defends the licence, applies the distinction to one question (contribution), and stops. **No proposal, no data, no call to action** — the proposals live in the other posts. - **The stewardship list is concrete**, and worth noting for what it includes beyond code: `[STATED]` *"review contributions, fix bugs, respond to security issues, manage releases, provide long-term support, and much more."* `[INFERENCE]` **Four of the five are not writing software**, which is the same observation the cost-allocation post makes with a longer list. - **"Absorb costs end users never see"** is the phrase that connects directly to the third post. `[INFERENCE]` The invisibility is the mechanism, and it is named here first. - **The image is reused across the series** — the same stone-bridge/wooden-bridge photograph appears on the cost-allocation post, with identical alt text. `[INFERENCE]` A deliberate visual signature for the series, and **the metaphor fits this post better than the one it was reused on**: sturdy versus fragile is exactly license-only versus stewarded. - **No examples are named.** `[INFERENCE]` No project is identified as license-only or stewarded anywhere in the piece — which avoids insulting anyone and **removes the only thing that would make the categories concrete.** - **"Both types of projects are Open Source"** is stated explicitly. `[INFERENCE]` Worth crediting: the taxonomy is not used to define license-only projects as lesser, and it easily could have been. ## 📚 References `[EVIDENCE]` **None.** No citations, no links, no examples. `[INFERENCE]` Defensible for a 528-word definitional post — it is proposing vocabulary, not establishing facts — and it does mean **every claim rests on the reader recognising the pattern from their own experience.** `[INFERENCE]` The absence that costs something is **examples**. A single named license-only project and a single named stewarded one would make the categories operational instead of intuitive, and the piece's central complaint is that people lack the vocabulary to tell them apart. ## 🗣️ Paraphrase Most open-source licences end with a clause disclaiming everything — no warranty, no liability, use at your own risk. For an organisation depending on that code it reads harshly: if it fails and takes your revenue with it, you are owed nothing. But the clause is doing its job. It makes the code available while protecting the people who share it, so that a generous act does not become unlimited legal exposure. What it cannot tell you is what kind of project you are dealing with. Some open source is licence-only: released under an open licence with no stewardship and no promise of care — no guaranteed updates, fixes, security response or support. Other open source is stewarded: maintained as shared infrastructure, with people reviewing contributions, fixing bugs, handling security reports, managing releases, and organisations funding that work and absorbing costs users never see. Both are open source. A weekend project and business-critical software can ship under the identical licence. Legally indistinguishable; practically nothing alike. The licence makes code available; stewardship makes it dependable. And the more people depend on a project, the more stewardship it needs — responsibility being the tax on relevance. The distinction matters most for the question of giving back. For licence-only projects, nobody is required to contribute, and that is precisely the point: it was shared freely with no promise attached. For stewarded projects the licence still requires nothing, but somebody is paying to keep the code usable and secure — so the question becomes not only what the licence permits, but who helps carry responsibilities the licence never imposed. The licence says use at your own risk. Stewardship is what happens when people decide you shouldn't have to. ## 📰 Newsletter **The most useful vocabulary I've read for a distinction everyone works around without naming.** Dries Buytaert splits open source in two: **license-only** — released under an open licence with no promise of care, no guaranteed updates, fixes or security response — and **stewarded** — maintained as shared infrastructure, with people reviewing, fixing, releasing, and organisations funding it and *"absorbing costs end users never see."* **"A weekend hobby project and business-critical software can ship under the exact same license. Legally, they look identical. Practically, they are worlds apart."** **What makes the piece work is that it defends the warranty disclaimer first.** The all-caps no-liability clause reads harshly if you depend on the code — and it's doing its job, because without it *"sharing code could become a gift that backfires: a generous act turned into unlimited legal risk."* Establishing that the disclaimer is *correct* before arguing it's *insufficient* is a much stronger move than treating it as a loophole. **Then the payoff, on whether companies owe anything back.** For licence-only: *"no one is required to contribute, and that is the point."* For stewarded: the licence still requires nothing, *"but the work does not happen for free. Someone is paying to keep your code usable, secure, and available."* **Conceding the first case fully is what makes the second persuasive.** And the closing line reframes rather than argues: *"The license says use at your own risk. **Stewardship is what happens when people decide you should not have to.**"* **Two things to push on.** First, **there's no test** — you get two categories and no way to tell which one you're depending on. Release cadence, responsiveness and having a foundation all fail as signals. The question that actually discriminates is *what happens to a security report on a weekend?*, because stewardship is exactly the commitment to respond when nobody feels like it. **And the category can change without notice** — a project is stewarded until its funding ends, and nothing in the repo signals the transition. Second, *"responsibility is the tax on relevance"* is the most quotable line and the one carrying the most unearned weight. As description it's obviously true. As prescription it's **exactly the obligation the warranty disclaimer exists to refuse** — a maintainer whose weekend project got popular never chose relevance. Read it first if you're reading the series: it's the taxonomy the other two posts assume, and the newest one is the least self-sufficient of the three. ## ✅ Action Items #### DevRel - **Education:** `[RECOMMEND]` Teach the distinction with the **security-report-on-a-weekend** test, since the post supplies the categories and not the diagnostic. - **Developer advocacy:** `[INFERENCE]` *"The license makes code available; stewardship makes it dependable"* is the one-line version and is worth borrowing intact. - **Developer experience / Developer marketing / Community management / Cross-project:** Not applicable to this source. #### OSPO - **Policy & Governance:** `[RECOMMEND]` **Classify your dependencies by stewardship, not by licence.** `[INFERENCE]` Licence tells you what you may do; it tells you nothing about whether anyone will answer a security report — and procurement processes routinely record the first and never ask the second. - **Software Inventory:** `[RECOMMEND]` **Add a stewardship field.** `[INFERENCE]` And treat it as perishable: a project is stewarded until its funding ends, and **nothing in the repository signals the transition.** - **Security Management:** `[INFERENCE]` A license-only dependency has **no security response commitment by definition.** That is a risk register entry, not a licence question. - **Community Engagement:** `[INFERENCE]` The contribution argument gives a defensible basis for *which* projects to fund: **the ones where someone is already paying and you are benefiting from that payment.** - **License Compliance / Developer Support / Strategic Alignment:** Not applicable to this source. #### Community - **Maintainers:** `[RECOMMEND]` **Say which kind you are, in the README.** `[INFERENCE]` The piece's whole complaint is that consumers cannot tell — and a maintainer who states *"license-only, no support commitment"* both sets expectations and reclaims the protection the disclaimer intends. - **Sponsors:** `[INFERENCE]` *"Absorb costs end users never see"* is the sentence that identifies what sponsorship actually buys. - **Contributors / Ecosystem:** Not applicable to this source. #### WordPress - **Plugins / Themes:** `[INFERENCE]` The wp.org directory hosts both categories under identical presentation — **a plugin with a paid team and a plugin last touched in 2019 look the same on the listing page.** `[INFERENCE]` The active-install count and last-updated date are proxies for stewardship and poor ones. - **All other WordPress teams:** Not applicable to this source. #### The WPOCC - **Programs:** `[INFERENCE]` The taxonomy sharpens the funding target: **the fundable gap is projects that are depended upon as if stewarded and are actually license-only.** That is a more precise criterion than "support maintainers," and it is identifiable. - **Projects / Funding experiments:** Not applicable to this source. ### FAIR - `[INFERENCE]` **The distinction applies directly to a distribution layer.** A federated package source is infrastructure — the paradigm case of stewarded — which means **it needs a stewardship commitment, not only working software.** `[INFERENCE]` Read against the infrastructure post's account of FAIR (*"the software works but its organizers recently stepped back"*), **this taxonomy names precisely what was missing: the code existed and the stewardship commitment could not be funded.** ## 🧪 Hypotheses 1. **H1 — Consumers cannot classify their dependencies.** Asked to sort their own top dependencies into license-only versus stewarded, developers disagree with the projects' own self-descriptions at a high rate. 2. **H2 — Weekend security response discriminates.** Time-to-first-response on security reports filed outside business hours separates stewarded from license-only projects better than release cadence or contributor count. 3. **H3 — Category transitions are unsignalled.** Projects moving from stewarded to license-only (funding ends, maintainer departs) do so without any repository-visible announcement in most cases. 4. **H4 — Stewardship is invisible in registry metadata.** Package registry listings contain no field distinguishing the two categories, so consumers rely on proxies (stars, downloads, last commit) that correlate weakly with stewardship. 5. **H5 — The obligation framing changes behaviour.** Organisations presented with the stewarded framing contribute at a higher rate than those presented with a general "give back to open source" appeal. 6. **H6 — Popularity precedes stewardship, not the reverse.** For projects that became stewarded, the dependency load arrived before the maintenance commitment did. ## 📊 Methodology - **H1 — the one that tests whether the vocabulary is usable.** Survey developers on their own dependencies; compare against each project's stated support policy. **Confound:** most projects have no stated policy, which is itself the finding — **report the "no statement available" rate as the primary result.** - **H2 — the most valuable and entirely mechanical.** Mine public security-advisory and issue timestamps; compute time-to-first-response split by weekday/weekend. `[RECOMMEND]` **A clean separation would give the taxonomy the diagnostic it lacks**, which is the gap this post leaves. - **H3:** Longitudinal repository observation — track funding announcements, maintainer departures, and whether any README or policy change accompanied them. `[INFERENCE]` **Expect the answer to be "almost never,"** which is exactly why the category feels stable to consumers and is not. - **H4 — trivially checkable today.** Inspect the metadata schemas of npm, PyPI, Packagist, wp.org. `[INFERENCE]` **None has a stewardship field**, and confirming that is a one-hour task that would support an argument for adding one. - **H5:** A/B framing experiment in sponsorship appeals. **Confound:** organisations that respond to any appeal are self-selected; needs a large enough sample to compare within similar org profiles. - **H6:** Reconstruct timelines for a sample of now-stewarded projects — dependency growth against first funded maintainer. `[INFERENCE]` **If popularity reliably precedes stewardship, "responsibility is the tax on relevance" is descriptively right and the tax arrives before anyone agrees to pay it** — which is the sharper version of the point. ## ❓ Questions - **How does a consumer tell the difference?** `[INFERENCE]` The piece's central omission, and the question its own framing creates. - **What happens when a project moves between categories?** Stewardship is not permanent and nothing signals the change. - `[INFERENCE]` **Is "responsibility is the tax on relevance" description or prescription?** The post uses it as both and the difference matters enormously to a maintainer. - Should maintainers declare their category? `[INFERENCE]` It would resolve the consumer problem at no cost, and the post does not suggest it. - `[EVIDENCE]` Why are no examples named? `[INFERENCE]` Naming a project as license-only reads as criticism, which is presumably the reason — and it leaves the categories abstract. - `[INFERENCE]` Is there a middle? Most real projects are partially stewarded — security yes, features no — and the binary has no room for that. ## 🔮 Future Research - **A diagnostic for stewardship** that a consumer can apply from outside. `[INFERENCE]` The taxonomy is only actionable with one, and none exists. - **Category transition rates and their signals.** `[INFERENCE]` How often does stewarded become license-only, and does anyone find out? - **Whether registry metadata could carry a stewardship declaration**, and whether maintainers would use it honestly. - **Partial stewardship as the actual distribution.** `[INFERENCE]` The binary is a simplification and the shape of the real distribution is unstudied. ## 💡 Implications - **Practice.** `[RECOMMEND]` **Classify dependencies by stewardship, not licence**, and use the weekend-security-report question. **Maintainers: declare your category in the README.** - **Policy.** `[INFERENCE]` Procurement and risk processes record licences and almost never record support commitments. **The licence is the wrong field for the question actually being asked.** - **Security.** `[INFERENCE]` **A license-only dependency has no security response commitment by definition** — that belongs on a risk register, and the transition into that state is silent. - **Education.** `[EVIDENCE]` *"Legally, they look identical. Practically, they are worlds apart"* is the whole argument in two sentences, and it is the version that will be remembered. - **Funding models.** `[INFERENCE]` The taxonomy supplies the precondition for the other two posts: **you cannot argue about who should fund stewardship until you can say which projects have it.** ## 🧠 Learning Styles Assessment **Reading level estimate.** `[INFERENCE]` **Flesch–Kincaid grade 10–11** — short sentences, plain vocabulary, almost no jargon. Hand estimate on 528 words, ±1.5 grades. `[EVIDENCE]` **The most accessible of the three posts**, and appropriately so for a piece whose purpose is to install vocabulary. #### 👀 Visual learners - **Present:** `[EVIDENCE]` The stone-bridge/wooden-bridge image with descriptive alt text — **and the metaphor fits this post better than the one it is also used on**: sturdy versus fragile is exactly the distinction being drawn. - **Improve:** `[INFERENCE]` The two categories are a two-column table waiting to happen, and the piece keeps them in prose. #### 🔊 Aural learners - **Present:** `[EVIDENCE]` The aphorisms are built for the ear — *"the license makes code available; stewardship makes it dependable"* has a rhythm the rest of the prose does not. - **Improve:** `[INFERENCE]` Low value overall for a 528-word definitional post. #### 🗣️ Verbal learners - **Present:** `[EVIDENCE]` **The strongest dimension by a distance** — this is a vocabulary post and the vocabulary is good. Three memorable formulations in 528 words. - **Improve:** `[INFERENCE]` *"Responsibility is the tax on relevance"* is the most quotable and the least precise; **the compression hides whether it is a description or a demand.** #### 🧩 Kinesthetic learners - **Present:** Nothing directly actionable. - **Improve:** `[EVIDENCE]` **No test, no checklist, no examples.** `[INFERENCE]` A reader persuaded by the distinction has nothing to *do* with it — which is the piece's main practical limitation. #### 🧠 Logical learners - **Present:** `[EVIDENCE]` Clean structure — defend the disclaimer, identify what it cannot answer, define two categories, apply to one question. `[INFERENCE]` The defence-before-critique ordering is what makes it hold. - **Improve:** `[EVIDENCE]` **The binary admits no middle**, and most real projects are partially stewarded. And the taxonomy has no membership test. #### 🧑‍🤝‍🧑 Social learners - **Present:** `[EVIDENCE]` The contribution question is framed socially — *"who helps carry the responsibilities"* — rather than legally. - **Improve:** `[EVIDENCE]` No maintainer, no organisation, no project is named or quoted anywhere. #### 🧘‍♀️ Solitary learners - **Present:** Self-contained; the distinction can be applied to your own dependencies immediately. - **Improve:** `[EVIDENCE]` **No links, no examples, no further reading** — including to the two companion posts that develop the argument. #### 🌿 Naturalistic learners - **Present:** `[EVIDENCE]` The bridge image, and *"cared for"* / *"tax"* framing. - **Improve:** `[INFERENCE]` The **commons** vocabulary is the natural fit and is unused across all three posts. Stewardship is literally the commons-management term, and the literature it belongs to is never invoked. ## 📊 Accessibility Assessment Assessed against **WCAG 2.2 AA**, from the captured markup only. `[INFERENCE]` **Scope limit:** content structure and text as retrieved. Focus, keyboard operation, live contrast, and reflow require the rendered page and are **not assessed**; absence of a finding is not a pass. #### Screen reader semantics - **Present:** `[EVIDENCE]` Descriptive alt text on the lead image — *"View from under a sturdy stone bridge toward a fragile wooden bridge in the distance, with two people standing on it."* `[INFERENCE]` Conveys the metaphor, not just the picture. Consistently good across this author's posts. - **Improve:** `[EVIDENCE]` **No headings in the body.** **WCAG 2.4.6 Headings and Labels (AA).** `[INFERENCE]` At 528 words with a single clear argument this is the mildest instance of a failure that has now appeared in **eight sources this batch** — and unlike the others, the piece is short enough that the cost is small. #### Keyboard navigation - **Not testable from the captured markup.** #### Contrast and readability - **Not testable** — no CSS captured. `[INFERENCE]` Textual readability is high. #### Text resizing and reflow - **Not testable from the captured markup.** No wide content that would create the usual hazard. #### Media and captions - **Not applicable** — no audio or video. #### Forms and interactions - **Not applicable.** #### Standards reference - **1.1.1 Non-text Content (A)** — **satisfied.** - **2.4.6 Headings and Labels (AA)** — **failure**, mitigated by brevity. - **2.4.4 Link Purpose (A)** — vacuously satisfied; no links. ## 🌍 DEIB Assessment #### Cultural breadth - **Present:** Abstract and universally applicable; no region-locked framing. - **Improve:** `[INFERENCE]` One substantive point the piece does not reach: **who can afford to be a steward.** Stewardship as defined requires organisations able to fund maintainers, and **the license-only category is where projects from under-resourced contexts necessarily sit** — not by choice about care, but by absence of funding. **The taxonomy describes a resource gradient as though it were a commitment gradient.** #### Inclusive language - **Present:** `[EVIDENCE]` **Notably careful.** *"Both types of projects are Open Source"* is stated explicitly, and license-only is never described as lesser — *"no one is required to contribute, and that is the point."* - **Improve:** Nothing substantive. #### Neurodiversity support - **Present:** `[EVIDENCE]` Short, linear, one idea per paragraph, and brief enough to hold entire. - **Improve:** `[EVIDENCE]` No headings and no summary — mild at this length. #### Representation - **Present:** Nothing to assess. - **Improve:** `[EVIDENCE]` **No maintainer is quoted or named**, in a piece whose subject is what maintainers do and do not owe. `[INFERENCE]` The population whose obligations are being categorised has no voice in the categorisation. #### Psychological safety - **Present:** `[EVIDENCE]` **Handled well and deliberately.** The license-only category is defended rather than disparaged, and the disclaimer is defended before being qualified. `[INFERENCE]` A maintainer reading this is not being told they are failing. - **Improve:** `[INFERENCE]` *"Responsibility is the tax on relevance"* is the exception. `[INFERENCE]` To a maintainer of an unexpectedly popular project, **that reads as an obligation arriving unbidden** — which is precisely the situation that produces burnout, and the piece's own framing elsewhere would reject it. ## ✅ Logical Validity #### Strong reasoning - **Defending the disclaimer before qualifying it** is the piece's structural strength. `[INFERENCE]` It grants the strongest form of the opposing position — the licence is right to disclaim — and then asks a question the disclaimer does not answer, which is much harder to resist than treating the clause as a flaw. - **The identical-licence observation is the argument in one move.** A hobby project and business-critical software under the same terms is an observation the reader can verify immediately, and it establishes that the licence is the wrong instrument for the question. - **The contribution answer is genuinely bifurcated**, and the license-only concession is total. `[INFERENCE]` Refusing to claim universal obligation is what makes the narrower claim credible. - **The closing reframes rather than argues:** *"Stewardship is what happens when people decide you should not have to."* `[INFERENCE]` It locates the obligation as **voluntary and social**, leaving the legal position untouched — which is both accurate and admits its own unenforceability. #### Fallacies - **Category without a membership test.** Two classes are defined and no criterion is given for assigning a project to either. **Weakness:** the taxonomy's entire value is consumer-facing, and a consumer cannot apply it. **Fix:** one diagnostic question. - **False dichotomy.** `[INFERENCE]` Most real projects are **partially** stewarded — security patched, features not; one maintainer responsive, releases irregular. The binary has no room for the common case. - **Aphorism outrunning the argument.** *"Responsibility is the tax on relevance"* slides between description and prescription. **Weakness:** as prescription it asserts the obligation the disclaimer refuses, and it is the line most likely to be quoted alone. - **Assertion without instance.** No project is named on either side. `[INFERENCE]` Understandable — naming one as license-only reads as criticism — and it leaves both categories unfalsifiable in practice. #### Tone of voice `[EVIDENCE]` Calm, definitional, and unusually restrained for a piece that is laying groundwork for an argument about money. `[INFERENCE]` **The restraint is strategic:** by refusing to argue for any obligation here, it makes the vocabulary adoptable by people who would reject the conclusion the later posts draw from it. `[EVIDENCE]` Confidence is well calibrated — *"often requires"*, *"can be simple"*, *"may still require nothing"* — with one exception. `[INFERENCE]` **The aphorism is the only unhedged sentence in the piece**, and it is the one carrying the contestable claim. **The hedging pattern runs opposite to where the argument is weakest**, which is the same observation I made about the FAIR claim in the companion post. ## 🛡️ DARVO Analysis **No DARVO pattern present, and the framework is inapplicable.** `[EVIDENCE]` DARVO — Deny, Attack, Reverse Victim and Offender — describes a response to accusation. This is a definitional essay with no accusation, no accused party, and no adversarial dimension. Checking each element explicitly rather than omitting the section: - **Deny:** None. `[EVIDENCE]` The piece affirms that the warranty disclaimer is harsh for dependants — *"the license owes you nothing. No fix, no refund, and no one to explain what went wrong"* — before defending it. Affirming the discomfort you are about to justify is the opposite of denial. - **Attack:** None. `[EVIDENCE]` **Conspicuously so.** License-only maintainers, the obvious target for a piece about people not carrying responsibility, are explicitly protected: *"no one is required to contribute, and that is the point."* Companies consuming without contributing are not criticised either — the question is posed and answered conditionally. - **Reverse victim/offender:** None. `[EVIDENCE]` Maintainers absorbing costs are described as doing something voluntary — *"people decide you should not have to"* — rather than as wronged parties, and no counterparty is cast as an offender. `[INFERENCE]` One adjacent observation, recorded separately because it is **not** DARVO: **the taxonomy is a precondition for an argument about money that the author has a commercial interest in.** Establishing that "stewarded" projects create a reasonable expectation of contribution is the groundwork for the funding proposals in the companion posts, and Acquia is the largest commercial beneficiary of the paradigm stewarded project. `[INFERENCE]` **The vocabulary stands on its own merits and the sequencing is worth seeing.** Already logged under Logical Validity. ## 🎯 Conclusion **Bottom line.** `[INFERENCE]` The best vocabulary in the series, and the load-bearing weak link in it. 1. **The distinction is real and useful.** `[STATED]` *"A weekend hobby project and business-critical software can ship under the exact same license. Legally, they look identical. Practically, they are worlds apart."* **License-only** promises nothing by design; **stewarded** means someone is reviewing, fixing, releasing, responding to security, and *"absorbing costs end users never see."* 2. **Defending the disclaimer first is what makes it work.** `[STATED]` The all-caps no-liability clause is *"the license doing its job"* — without it, *"sharing code could become a gift that backfires."* `[INFERENCE]` Granting that the licence is **right** before asking what it **cannot answer** is far stronger than treating the clause as a loophole, and it is why the contribution argument lands. 3. **There is no test, and that is the gap.** `[INFERENCE]` The taxonomy's value is consumer-facing and **a consumer cannot apply it** — release cadence, responsiveness, and the presence of a foundation all fail as signals. `[RECOMMEND]` **The question that discriminates is: what happens to a security report on a weekend?** Stewardship is precisely the commitment to respond when nobody feels like it. **And the category changes without notice** — a project is stewarded until its funding ends, and nothing in the repository signals the transition. 4. **One line to handle carefully.** *"Responsibility is the tax on relevance"* is the most quotable sentence and the only unhedged one. `[INFERENCE]` As **description** — popular projects need more maintenance — it is plainly true. As **prescription** — you became popular, so you now owe — **it is exactly the obligation the disclaimer exists to refuse**, and a maintainer whose weekend project took off never chose relevance. **Where it sits in the series.** `[INFERENCE]` Read in order: **this** (what kind of project is it?) → **infrastructure** (who pays, and *"whoever funds the infrastructure controls it"*) → **cost allocation** (architecture decides, usually without anyone deciding). **The taxonomy is the weakest link and everything downstream depends on it** — the argument that beneficiaries should help fund stewardship requires being able to say which projects are stewarded, and no test is offered in any of the three. **And it names what the FAIR account was missing.** `[INFERENCE]` The infrastructure post reports *"the software works but its organizers recently stepped back."* **This taxonomy gives that its precise description: the code existed, and the stewardship commitment could not be funded.** A federated package source is infrastructure — the paradigm stewarded case — which means **working software was never the sufficient condition.** **Practical next steps.** 1. **Classify your dependencies by stewardship, not licence** — the licence is the wrong field for the question you are actually asking. 2. Use the **weekend security report** question as the diagnostic the post omits. 3. **Maintainers: declare your category in the README.** `[INFERENCE]` It resolves the consumer problem at zero cost and reclaims the protection the disclaimer intends. 4. `[INFERENCE]` Treat stewardship as **perishable** in any risk register. It ends quietly. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/License-Only Versus Stewarded Open Source.md|License-Only Versus Stewarded Open Source by Dries Buytaert]] ## Highlights - Both types of projects are Open Source, but they are *not* the same. A weekend hobby project and business-critical software can ship under the exact same license. Legally, they look identical. Practically, they are worlds apart. ([View Highlight](https://read.readwise.io/read/01m12snybscxkeq2y0wfxecbps)) - Note: THE DISTINCTION, AND THE BEST VOCABULARY IN THE THREE-POST SERIES. LICENSE-ONLY: "code released under an Open Source license, without active stewardship or any promise of ongoing care" — no guaranteed updates, fixes, security response or support. STEWARDED: "code cared for as shared infrastructure," where people review contributions, fix bugs, respond to security, manage releases, and organisations "absorb costs end users never see." What makes the piece work is that IT DEFENDS THE WARRANTY DISCLAIMER FIRST — the all-caps no-liability clause is "the license doing its job," because without it "sharing code could become a gift that backfires." Granting the licence is RIGHT before asking what it CANNOT ANSWER is far stronger than treating the clause as a loophole. BUT THE GAP: THERE IS NO TEST. You get two categories and no way to tell which one you're depending on. Release cadence, responsiveness and having a foundation all fail as signals. THE QUESTION THAT ACTUALLY DISCRIMINATES: WHAT HAPPENS TO A SECURITY REPORT ON A WEEKEND? Stewardship is exactly the commitment to respond when nobody feels like it. AND THE CATEGORY CHANGES WITHOUT NOTICE — a project is stewarded until its funding ends or its maintainer burns out, and NOTHING IN THE REPOSITORY SIGNALS THE TRANSITION. The Duck Alignment piece this batch (inactive maintainers as a standing liability) is that transition observed from the security side. FOR FAIR: this names precisely what the infrastructure post said was missing — "the software works but its organizers stepped back." A federated package source is infrastructure, the paradigm STEWARDED case, so WORKING SOFTWARE WAS NEVER THE SUFFICIENT CONDITION. Read this post FIRST of the three — it's the taxonomy the others assume. #atom/zettel/z1 #action/h1 - Responsibility is the tax on relevance. ([View Highlight](https://read.readwise.io/read/01m12spcxp89kmkygvaf1226r9)) - Note: THE MOST QUOTABLE LINE AND THE ONE CARRYING THE MOST UNEARNED WEIGHT — and it's the only unhedged sentence in the piece. IT'S DOING TWO THINGS AND ONLY ONE IS DEFENSIBLE AS STATED. As DESCRIPTION — popular projects demand more maintenance — obviously true and useful. As PRESCRIPTION — you became popular, so you now OWE more — IT IS EXACTLY THE OBLIGATION THE WARRANTY DISCLAIMER EXISTS TO REFUSE. A maintainer whose weekend project got popular never signed up for a tax, and "relevance" was not something they chose. That's precisely the situation that produces burnout, and the piece's own framing elsewhere (careful in the contribution section: "the license may still require nothing") would reject it. THE HONEST READING, AND PROBABLY HIS INTENDED ONE: THE TAX IS REAL AND FALLS ON SOMEONE; THE QUESTION IS WHETHER IT FALLS ON THE MAINTAINER BY DEFAULT OR IS DELIBERATELY DISTRIBUTED. That's the argument of the other two posts, and this line is the bridge to them. NOTE THE PATTERN ACROSS THE SERIES: the hedging runs OPPOSITE to where the argument is weakest. Same observation I made about the unhedged FAIR claim in the infrastructure post — the confident sentences are the contestable ones. Worth carrying as a reading heuristic for this author: the aphorism that lands hardest is the claim to check. The closing line is the better formulation of the same idea and IS properly scoped: "The license says use at your own risk. Stewardship is what happens when people decide you should not have to." — stewardship as a VOLUNTARY act the licence neither requires nor prevents. That leaves the disclaimer intact and locates the obligation in a social commitment rather than a legal one. #atom/zettel/z2 #fallacy/description-as-prescription