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 > ## 🧭 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 a Some Open Source is simply shared. Some is maintained as infrastructure. Naming the difference changes the conversation. View from under a sturdy stone bridge toward a fragile wooden bridge in the distance, with two people standing on it. 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. 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. No fix, no refund, and no one to explain what went wrong. 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. But 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. Some Open Source is "License-only Open Source": code released under an Open Source license, without active stewardship or any promise of ongoing care. There is no guarantee of updates, fixes, security response, or long-term support. Other Open Source is "Stewarded Open Source": code cared for as shared infrastructure. Maintainers review contributions, fix bugs, respond to security issues, manage releases, provide long-term support, and much more. Organizations fund maintainers, support core development, donate infrastructure, and absorb costs end users never see. 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. 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. Distinguishing license-only from stewarded Open Source gives us the vocabulary to describe two very different realities that the words "Open Source" alone do not capture. For example, the distinction becomes useful when we talk about contribution. If a company depends on Open Source, should it give back? For license-only Open Source, the answer can be simple: 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 Open Source is different. 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. When you depend on that work, the question is not only what the license allows, but who helps carry the responsibilities beyond what the license requires. The license says use at your own risk. Stewardship is what happens when people decide you should not have to. Join 5,000+ readers. I'm the creator of Drupal and co-founder of Acquia. I write about Open Source, AI, and the future of the web, with a focus on building, scaling, and thinking long-term., License-Only Versus Stewarded Open Source, Dries Buytaert, 01m12prxpwrm8cg1b5bkb01fet.