pith. sign in

arxiv: 2606.24896 · v1 · pith:TNUWVIPGnew · submitted 2026-06-05 · 💻 cs.DL · cs.CY

Why Memory Components Fail: Eight Years of License and Sustainability Events in Open-Source Data Infrastructure

Dmitrii Dmitrenko This is my paper

Pith reviewed 2026-06-27 19:55 UTC · model grok-4.3

classification 💻 cs.DL cs.CY
keywords open sourcedata infrastructurelicense sustainabilitygovernanceventure capitalfoundation governanceAI toolingmemory components
0
0 comments X

The pith

Open-source data infrastructure projects backed by single vendors see adverse license events at nineteen times the rate of foundation-governed projects.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper contends that project governance and capital structure function as key architectural variables for memory components used in large language model agents. Surveys of such systems have overlooked these factors. Analysis of 105 projects reveals a sharp split in adverse event rates, with single-vendor venture-backed projects at 46 percent and foundation-governed projects at 2.5 percent. This nineteen-fold gap persists regardless of how events are coded. The work also tracks rising incidence over eight years and offers a six-field checklist for selecting stable components.

Core claim

In a sample of 105 production-relevant open-source data-infrastructure and AI-tooling projects, 38 license-and-sustainability events were catalogued from 2018 to May 2026, affecting 24 percent of the projects. Adverse event rates reached 46 percent among single-vendor venture-backed projects but only 2.5 percent among foundation-governed projects funded outside the venture cycle, yielding a roughly nineteen-fold differential that remains stable under alternative classifications. Incidence increased from 2.7 to 4.2 events per year. Stable projects such as PostgreSQL, pgvector, SQLite, Apache Kafka, and Caddy illustrate different structural sources of resilience, including distributed copyrigh

What carries the argument

The empirical split in adverse event rates by governance and capital structure, measured through a catalogue of 38 events in 105 projects.

If this is right

  • Memory component selection in LLM agents should incorporate governance and capital structure assessments to mitigate license risks.
  • Foundation governance can prevent unilateral relicensing even when corporate stewards have venture backing.
  • Adverse events have become more frequent over the study period.
  • Different structural features such as distributed copyright or absence of monetization pressure can each produce long-term stability.
  • The observed differential holds across variations in event classification.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Designers of LLM agent architectures may need to prioritize foundation-governed memory stores to lower long-term sustainability risks.
  • The pattern suggests that venture funding models in open source may systematically increase the likelihood of license changes.
  • Applying the six-field instrument to other categories of open-source software could reveal similar governance effects.
  • Empirical validation through direct observation of component migrations following adverse events would strengthen the case for the proposed decision tool.

Load-bearing premise

The 105 projects form a representative sample of production-relevant open-source data infrastructure and the 38 events are consistently and unbiasedly identified as adverse.

What would settle it

A replication study on an expanded or independently sampled set of projects that finds comparable adverse event rates between single-vendor venture-backed and foundation-governed projects.

read the original abstract

LLM agent memory is now treated as a first-class architectural component in five major surveys published between January and April 2026. None of these surveys treats project governance, capital structure, or license posture as architectural variables. We argue they are. In a constructed sample of 105 production-relevant open-source data-infrastructure and AI-tooling projects, we catalogue 38 license-and-sustainability events between 2018 and May 2026. About a quarter of the sample (24 percent) experienced at least one adverse event. The conditional rates split sharply by structure: 46 percent for single-vendor venture-backed projects, 2.5 percent for foundation-governed projects funded outside the venture cycle. The headline differential -- roughly nineteen-fold -- is invariant to the most contested coding choice in the catalogue; we show the sensitivity table in Section 7. A small subset of foundation-governed projects with venture-backed corporate stewards (n=3) contains one adverse event. The cell is too small for stable estimation, but it points to a mechanism: foundation governance may block unilateral relicensing while leaving distribution decisions to the steward. Annualized incidence within the catalogue rose from 2.7 to 4.2 events per year across the window. Counterfactuals -- PostgreSQL, pgvector, SQLite, Apache Kafka, Caddy -- each show stability arising from a different structural source: distributed copyright, absence of monetisation pressure, foundation governance with non-venture stewardship. We propose a six-field decision instrument for architects choosing memory components: governance, capital structure, license, foundation membership, fork-or-migration availability, and steward concentration.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The manuscript catalogues 38 license-and-sustainability events across a constructed sample of 105 production-relevant open-source data-infrastructure and AI-tooling projects from 2018 to May 2026. It reports that 24% of projects experienced at least one adverse event, with conditional rates of 46% for single-vendor venture-backed projects versus 2.5% for foundation-governed projects funded outside the venture cycle (a roughly nineteen-fold differential claimed to be invariant to contested coding choices). Counterfactual stable projects are identified, and a six-field decision instrument (governance, capital structure, license, foundation membership, fork-or-migration availability, steward concentration) is proposed for architects selecting memory components.

Significance. If the sample is representative and event classifications are unbiased, the work would be significant for treating governance and capital structure as first-class architectural variables in LLM memory systems—an aspect absent from the five 2026 surveys cited. The empirical rates, robustness table, and concrete counterfactuals (PostgreSQL, SQLite, etc.) supply falsifiable, practitioner-relevant evidence that could shift component-selection practice.

major comments (3)
  1. [Abstract/Methods] Abstract and (presumed) Methods: The sample of 105 projects is described only as 'constructed,' with no sampling frame, inclusion/exclusion criteria, or universe definition supplied. This omission is load-bearing for the central 46% vs. 2.5% rate comparison; without it, the nineteen-fold differential cannot be distinguished from selection bias. Section 7's sensitivity table addresses only post-selection coding choices and does not mitigate the upstream selection step.
  2. [Results] Results paragraph on n=3 cell: The subset of foundation-governed projects with venture-backed corporate stewards (n=3) contains one adverse event. The cell size is acknowledged as too small for stable estimation, yet the text still invokes it to 'point to a mechanism.' This interpretive step rests on an underpowered observation and should be removed or reframed as speculative.
  3. [Abstract] Abstract: The annualized incidence rise (2.7 to 4.2 events per year) and the claim of invariance to 'the most contested coding choice' both presuppose a fully documented event-classification protocol and a fixed sample; neither protocol nor sample-construction details appear, rendering both claims unassessable.
minor comments (2)
  1. [Methods] The precise definition of an 'adverse event' (license change, fork, abandonment, etc.) and the verification steps used to classify the 38 events should be stated explicitly in the Methods section.
  2. Table or figure presenting the 105 projects by category (single-vendor VC, foundation non-VC, etc.) would allow readers to assess balance and cell sizes directly.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive and precise comments. They correctly identify areas where additional documentation is required to support the central claims. We address each major comment below and commit to revisions that strengthen the manuscript without altering its empirical findings.

read point-by-point responses

  1. Referee: [Abstract/Methods] Abstract and (presumed) Methods: The sample of 105 projects is described only as 'constructed,' with no sampling frame, inclusion/exclusion criteria, or universe definition supplied. This omission is load-bearing for the central 46% vs. 2.5% rate comparison; without it, the nineteen-fold differential cannot be distinguished from selection bias. Section 7's sensitivity table addresses only post-selection coding choices and does not mitigate the upstream selection step.

    Authors: We agree that the sampling procedure must be documented explicitly. The revised manuscript will add a dedicated Methods section (Section 2) that defines the universe as all open-source data-infrastructure and AI-tooling projects referenced in production LLM deployments or the five 2026 surveys cited. Inclusion criteria (minimum 500 GitHub stars, active maintenance through 2023, relevance to memory components) and exclusion criteria (non-open-source, purely academic, or lacking license metadata) will be stated in full. This addition directly addresses the upstream selection step and allows readers to evaluate potential bias. revision: yes

  2. Referee: [Results] Results paragraph on n=3 cell: The subset of foundation-governed projects with venture-backed corporate stewards (n=3) contains one adverse event. The cell size is acknowledged as too small for stable estimation, yet the text still invokes it to 'point to a mechanism.' This interpretive step rests on an underpowered observation and should be removed or reframed as speculative.

    Authors: The referee is correct; the n=3 cell is too small to support any mechanistic claim. In revision we will excise the sentence that invokes a mechanism and will present the observation strictly as a descriptive note, accompanied by an explicit statement of its limited statistical power and the absence of any causal inference. revision: yes

  3. Referee: [Abstract] Abstract: The annualized incidence rise (2.7 to 4.2 events per year) and the claim of invariance to 'the most contested coding choice' both presuppose a fully documented event-classification protocol and a fixed sample; neither protocol nor sample-construction details appear, rendering both claims unassessable.

    Authors: We will revise the abstract to cross-reference the new Methods section for sample construction. A new Appendix A will supply the complete event-classification protocol, including the decision tree, examples of borderline cases, and resolution rules. The sensitivity table already in Section 7 demonstrates invariance across coding variations; the appendix will make the underlying protocol transparent. The annualized rates are simple counts of dated events within the fixed catalogue window and will be supported by a supplementary table listing all 38 events with dates. revision: yes

Circularity Check

0 steps flagged

No circularity: purely empirical catalogue with no derivations or self-referential quantities.

full rationale

The paper presents an empirical catalogue of 38 events across 105 projects and computes conditional rates by governance/capital categories. No equations, fitted parameters, predictions, or derivations appear in the provided text. The sample is described as 'constructed' but the rates are direct counts, not quantities that reduce to their own inputs by definition or self-citation. No self-citation load-bearing steps, ansatzes, or uniqueness theorems are invoked. This matches the default case of a self-contained empirical study.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

Abstract-only; the central claims rest on an unverified constructed sample and event classification whose criteria are not stated. No free parameters or invented entities appear.

axioms (2)
  • domain assumption The sample of 105 projects is representative of production-relevant open-source data-infrastructure and AI-tooling projects.
    Stated directly in the abstract as the basis for the catalogue.
  • domain assumption Events can be consistently classified as adverse license-and-sustainability events across projects with different governance models.
    Implicit in the reported counts and conditional rates.

pith-pipeline@v0.9.1-grok · 5830 in / 1386 out tokens · 20904 ms · 2026-06-27T19:55:45.796634+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

34 extracted references · 1 canonical work pages

  1. [1]

    OpenReview,

    [Anonymous, 2026] LLM Agent Memory: A Survey from a Unified Representation. OpenReview,

    2026

  2. [2]

    Evolving ArangoDB’s Licensing Model for a Sustainable Future

    https://openreview.net/forum?id=KPs1EgGKcT [ArangoDB, 2024] ArangoDB. Evolving ArangoDB’s Licensing Model for a Sustainable Future. February

    2024

  3. [3]

    Announcing Linkerd 2.15 with mesh expansion, native sidecars, and SPIFFE

    https://arango.ai/blog/update-evolving-arangodbs-licensing-model-for-a-sustainable-future/ [Buoyant, 2024] Buoyant. Announcing Linkerd 2.15 with mesh expansion, native sidecars, and SPIFFE. 21 February

    2024

  4. [4]

    23 October

    https://linkerd.io/2024/02/21/announcing-linkerd-2.15/ See also the eight-month retrospec- tive: Towards a Sustainable Service Mesh. 23 October

    2024

  5. [5]

    Caddy License for Commercial Use

    https://linkerd.io/2024/10/23/making-linkerd- sustainable/ [Caddy, 2019] Caddy Community. Caddy License for Commercial Use. GitHub Issue #2786 and community thread, October

    2024

  6. [6]

    Protecting NATS and the Integrity of Open Source: CNCF’s Commitment to the Community

    https://caddy.community/t/caddy-license-for-commercial-use/17170 [CNCF, 2025] Cloud Native Computing Foundation. Protecting NATS and the Integrity of Open Source: CNCF’s Commitment to the Community. 1 May

    2025

  7. [7]

    Graduated and Incubating Projects

    https://www.cncf.io/blog/2025/05/01/protecting- nats-and-the-integrity-of-open-source-cncfs-commitment-to-the-community/ [CNCF, 2026] Cloud Native Computing Foundation. Graduated and Incubating Projects. https://www.cncf.io/projects/ [Cockroach Labs, 2024] Cockroach Labs. CockroachDB Software License. Announced 15 August 2024 (effective with v24.3 in Nove...

    2025

  8. [8]

    License Changes for Confluent Platform

    https://rfd.shared.oxide.computer/rfd/0508 [Confluent, 2018] Confluent. License Changes for Confluent Platform. 14 December

    2018

  9. [9]

    DB-Engines Ranking, May

    https://www.confluent.io/blog/license- changes-confluent-platform/ [DB-Engines, 2026] DB-Engines. DB-Engines Ranking, May

    2026

  10. [10]

    Du et al

    https://db-engines.com/en/ranking [Du et al., 2026] Y. Du et al. Memory for Autonomous LLM Agents: Mechanisms, Evaluations, and Open Problems. arXiv:2603.07670, March

    arXiv 2026

  11. [11]

    [Eghbal, 2020] N. Eghbal. Working in Public: The Making and Maintenance of Open Source Software. Stripe Press,

    2020

  12. [12]

    Licensing Change

    [Elastic, 2021] Elastic. Licensing Change. 14 January

    2021

  13. [13]

    Elasticsearch is Open Source, Again

    https://www.elastic.co/blog/licensing-change [Elastic, 2024] Elastic. Elasticsearch is Open Source, Again. 29 August

    2024

  14. [14]

    License F AQ.August

    https://www.elastic.co/blog/elasticsearch- is-open-source-again [HashiCorp, 2023] HashiCorp. License F AQ.August

    2023

  15. [15]

    IBM Completes Acquisition of HashiCorp

    https://www.hashicorp.com/en/license-faq [IBM, 2025] IBM. IBM Completes Acquisition of HashiCorp. 27 February

    2025

  16. [16]

    InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License

    https://newsroom.ibm.com/2025- 02-27-ibm-completes-acquisition-of-hashicorp [InfluxData, 2025] InfluxData. InfluxDB 3 Open Source Now in Public Alpha Under MIT/Apache 2 License. January

    2025

  17. [17]

    https://community.influxdata.com/t/influxdb-3-open-source-now-in-public-alpha-under-mit- apache-2-license/55208 [Kane, 2026] A. Kane. pgvector LICENSE. https://github.com/pgvector/pgvector/blob/master/LICENSE [Lin et al., 2026] H. Lin et al. Toward Mnemonic Sovereignty: A Survey on the Security of Long-Term Memory in LLM Agents. arXiv:2604.16548, April

    Pith/arXiv arXiv 2026

  18. [18]

    Linux Foundation Launches Open Source Valkey Commu- nity

    [Linux Foundation, 2024] Linux Foundation. Linux Foundation Launches Open Source Valkey Commu- nity. March

    2024

  19. [19]

    Luo et al

    https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey- community 13 [Luo et al., 2026] Y. Luo et al. From Storage to Experience. ICLR 2026 MemAgents Workshop. https://openreview.net/forum?id=l9Ly41xxPb [Mem0, 2026] Mem0. Open Source: Migrating to the New Memory Algorithm (v2 to v3). April

    2026

  20. [20]

    MongoDB Issues New Server Side Public License for MongoDB Community Server

    https://docs.mem0.ai/migration/oss-v2-to-v3 [MongoDB, 2018] MongoDB. MongoDB Issues New Server Side Public License for MongoDB Community Server. 16 October

    2018

  21. [21]

    https://www.mongodb.com/company/newsroom/press-releases/mongodb-issues- new-server-side-public-license-for-mongodb-community-server [Neo4j, 2025] T. Claburn. Free Software Foundation Defends AGPLv3 in Neo4j Appeal. The Register, 4 March

    2025

  22. [22]

    What are Apache, GPL and AGPL licenses and why OpenObserve moved from Apache to AGPL

    https://www.theregister.com/2025/03/04/free_software_foundation_agplv3/ [OpenObserve, 2023] OpenObserve. What are Apache, GPL and AGPL licenses and why OpenObserve moved from Apache to AGPL. November

    2025

  23. [23]

    The OpenTofu Fork Is Now Available

    https://openobserve.ai/blog/what-are-apache-gpl-and-agpl-licenses- and-why-openobserve-moved-from-apache-to-agpl/ [OpenTofu, 2023] OpenTofu. The OpenTofu Fork Is Now Available. September

    2023

  24. [24]

    https://opentofu.org/blog/the- opentofu-fork-is-now-available/ [Ostrom, 1990] E. Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press,

    1990

  25. [25]

    [PostgreSQL, 2026] PostgreSQL Global Development Group. About. https://www.postgresql.org/about/ [Pracdata, 2024] Open Source Data Engineering Landscape

    2026

  26. [26]

    Redis Adopts Dual Source-Available Licensing

    https://www.pracdata.io/p/open-source- data-engineering-landscape-2024 [Redis, 2024] Redis. Redis Adopts Dual Source-Available Licensing. 20 March

    2024

  27. [27]

    Redis is Now Available under the AGPLv3 Open Source License

    https://redis.io/blog/redis- adopts-dual-source-available-licensing/ [Redis, 2025] Redis. Redis is Now Available under the AGPLv3 Open Source License. 1 May

    2025

  28. [28]

    Schweik and R.C

    https://redis.io/blog/agplv3/ [Schweik & English, 2012] C.M. Schweik and R.C. English. Internet Success: A Study of Open-Source Software Commons. MIT Press,

    2012

  29. [29]

    Why We’re Moving to a Source Available License

    [ScyllaDB, 2024] ScyllaDB. Why We’re Moving to a Source Available License. 18 December

    2024

  30. [30]

    Introducing the Functional Source License: Freedom Without Free-Riding

    https://www.scylladb.com/2024/12/18/why-were-moving-to-a-source-available-license/ [Sentry, 2023] Sentry. Introducing the Functional Source License: Freedom Without Free-Riding. 17 Novem- ber

    2024

  31. [31]

    Copyright Notice

    https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/ [SQLite, 2024] SQLite. Copyright Notice. https://sqlite.org/copyright.html [TechCrunch, 2023] K. Wiggers. ScyllaDB raises $43M to scale its NoSQL database platform. TechCrunch, 17 October

    2024

  32. [32]

    https://techcrunch.com/2023/10/17/scylladb-raises-43m-to-scale-its-nosql-database- platform/ Cited for cumulative venture funding (~$103M as of October

    2023

  33. [33]

    [Wu, 2026] J

    used in capital-structure coding of ScyllaDB. [Wu, 2026] J. Wu. Memory in the LLM Era: Modular Architectures and Abstractions. arXiv:2604.01707, April

    Pith/arXiv arXiv 2026

  34. [34]

    [Yin et al., 2022] L. Yin, M. Chakraborti, Y. Yan, C. Schweik, S. Frey, and V. Filkov. Open Source Software Sustainability: Combining Institutional Analysis and Socio-Technical Networks. Proc. ACM Hum.-Comput. Interact. 6, CSCW2, Article 404 (November 2022). https://doi.org/10.1145/3555129 [Zep, 2025] Zep. Announcing a New Direction for Zep’s Open Source ...

    work page doi:10.1145/3555129 2022