LibreOffice’s “No AI” Turns a Product Promise Into a Contribution Policy, and Its Git Log Holds 48 Disclosed LLM Commits Where The Register Cited Three

On October 29, The Register reported that The Document Foundation (TDF) says LibreOffice has no built-in AI features and that its core developers do not use LLMs, then pointed to three commits that credit Claude or GitHub Copilot. The three came from a Fediverse thread of September 3. TDF’s spokesman told the paper that there is no departure from the foundation’s public statements, “as they were about user features and not about development.”

I wanted to see what the repository itself shows, so I read the policy page TDF points to, its edit history and the engineering committee minutes behind it, and I counted LLM disclosures in the LibreOffice core repository myself. Among 18,662 non-merge commits from January 2, 2025 through October 29, 2026, 48 disclose LLM help, and one more is a revert that mentions it. Forty-four of the 48 came on or after April 22, 2026, when the policy page lost its DRAFT label, and 32 came in October, when they were 3.6 percent of the month’s commits. On September 3, when the Fediverse thread linked three commits, the log already held 11. Eight weeks later it holds 37 more.

What the evidence supports, in short:

• The product claim and the policy agree. The 26.8 announcement says the release “contains no generative AI features,” and the policy page allows LLMs in contributions “with certain restrictions.”
• The sentence the log does not support is the shorthand “No core developers use LLMs.” TDF’s reply does not say who counts as a core developer. By each of the three proxies I tried (a project email address, a place among the busiest author addresses, and committing one’s own change), the log has entries, including two from the third busiest address in the past week.
• The page asks for the product, the version, the steps taken and the line numbers. Of the 44 entries since adoption, 43 name a product, 41 name a version, 32 say what the tool did, and none gives line numbers.
• One merged commit labels its patch description “AI generated,” although the page says an LLM must not be used when writing the commit message.
• The Register describes the Copilot commit as “More recently, September’s” work. Its author date is September 19, 2025, so it is the oldest of the three and predates the policy’s adoption by seven months.

Where I computed something myself I say so, and the commands to repeat the count are below. The scan covers the core repository only, and it can only see use that people disclosed.

What TDF said, and what each statement covers

Four public statements matter here, plus the policy page. They cover different things, and the difference decides how the log should be read.

The first two statements and the spokesman’s clarification are about the product, and they are consistent with the policy: nothing on the policy page says LibreOffice may not be built with help from an LLM, and the page says the opposite. The release headline is broader than its body, which says “no generative AI features,” but neither speaks about how the code is written. The September 4 reply is the only public statement about development, and it is the one the log can test. The Register’s subhead leans on it too, “Core developers avoid AI coding assistants, while community contributors face disclosure and review rules.”

What the policy page says, and how it got there

The rules

The page opens by saying that generative AI in software development “has several issues” and that LLMs “are allowed in LibreOffice contributions with certain restrictions.” In its current form the restrictions are:

• “You must be able to explain in your own words every changed line of code in a patch you created with the help of an LLM.”
• “You must disclose the use of an LLM in the commit message, mentioning the product and version used and the steps taken. Point out the line numbers where an LLM was involved.”
• “You must not use an LLM when writing the commit message for your patch.”
• “You must not use an LLM when communicating with others.”
• “You must not use an LLM to solve easy hacks.”
• “You must not use an LLM to write reports or proposals related to internship projects such as Google Summer of Code or Outreachy.”

Two softer lines finish it: start small if you plan many patches in one area, and research skill atrophy. The page gives no reasons for any rule, and it does not say what counts as use of an LLM. I read it through the wiki’s MediaWiki API, because the wiki’s HTML pages answer scripts with a bot check while the API does not.

curl -s "https://wiki.documentfoundation.org/api.php?action=query&prop=revisions&rvprop=timestamp%7Ccomment&rvlimit=50&titles=Development/AI_policy&format=json&formatversion=2"

The history

That call returns eight revisions. Set beside the engineering steering committee (ESC) minutes that are posted to the developer list, they give this timeline.

I read the 24 ESC minutes posts on the developer list for March through June 2026, and none mentions an LLM or AI policy item, so the wiki comments are the only record of the adoption I could find. I found no ESC minutes for July or later in that archive. The comment of April 27 does not say which experiences it means.

The reasons live in the minutes

On September 11 the ESC wrote down what it called common ground: “we can’t prevent people from using it, but be upfront of the usage”; the submitter is responsible for the code and has to understand the patch; “not using it at all is still perfectly OK”; no use for easy hacks or mentored Google Summer of Code projects because that “goes against the idea of a learning task”; and “don’t use it in communication / gerrit comments.” Those are the reasons behind the rules, and none of them made it onto the page.

One question from that week is still open on the page. On the list thread that followed the September 18 minutes, a contributor asked “where do you draw the line on ‘use of an AI’” and pointed out that some IDEs now have “tab-complete which use an AI to complete a line.” The page does not say whether that counts. The Copilot commit below treats it as use, listing “support from LLM/code completion.”

What the git log shows

How I counted

I cloned LibreOffice/core as a shallow, tree-less history, which holds commit messages and no files, from January 1, 2025, and pinned every count to one snapshot commit, ec75111a57, committed October 29 at 15:39 in a UTC+1 time zone. Three wider searches (names of LLM products, phrases such as assisted by and generated with, and a third pass over model and tool names) returned about 100 candidate commits. I read every one and kept 49; the rest were things like library upgrade messages that list the command they were generated with, and a text cursor. The pattern in the script below returns exactly those 49, so the count can be repeated without repeating my reading. The 49 are 48 commits that disclose LLM help and one revert whose message gives ChatGPT as the reason.

git clone --filter=tree:0 --no-checkout --shallow-since=2025-01-01 --single-branch https://github.com/LibreOffice/core.git core_tl
python llmscan.py core_tl ec75111a57

# llmscan.py
# Count LLM disclosures in LibreOffice core commit messages.
# Usage: python llmscan.py CLONE_DIR SNAPSHOT_SHA
import re
import subprocess
import sys
from collections import Counter

clone, snapshot = sys.argv[1], sys.argv[2]
RS, FS = "\x1e", "\x1f"
raw = subprocess.run(
    ["git", "-C", clone, "log", snapshot, "--no-merges", f"--format={RS}%H{FS}%ae{FS}%ce{FS}%cI{FS}%s{FS}%b"],
    capture_output=True, text=True, encoding="utf-8", errors="replace", check=True,
).stdout
commits = []
for chunk in raw.split(RS):
    if chunk.strip():
        sha, ae, ce, cdate, subj, body = chunk.split(FS, 5)
        commits.append(dict(sha=sha[:10], ae=ae.lower(), ce=ce.lower(), day=cdate[:10], subj=subj, body=body))
print(f"non-merge commits: {len(commits)}  ({min(c['day'] for c in commits)} to {max(c['day'] for c in commits)})")

# 1. candidates: any commit message that names an LLM product or says "AI" (read by hand afterwards)
CAND = re.compile(r"\b(claude|copilot|chatgpt|gpt|gemini|gemma|deepseek|llms?|openai|anthropic|"
                  r"assisted[- ]by|ai[- ]assist\w*|ai[- ]generated)\b|(?<![A-Za-z])AI(?![A-Za-z])", re.I)
cands = [c for c in commits if CAND.search(c["subj"] + "\n" + c["body"])]
print(f"candidate commits by this pattern: {len(cands)}")

# 2. the commits that survived the hand check: 48 disclosures plus one revert (5b90de9a48)
VETTED = """fde5f8afc3 5b90de9a48 70c7f6ba49 7c0d875aca 822df5f882 42cdc47554 9f01c44561 f7b81f9789 edc78d10a9
d3b0de73da 0a03f797bb ff95e14a30 e808025d6f 137f0c8cc6 790dd1d0c6 4cd4f3421b 342dabb28d 756af9723b 3b3de52a31
913526ca7d 27d0911584 5776e55464 b58f48f824 823e3c683e 00a5ba578c bc51331a9a 1fa9e5f87b 05e3afa985 b3b9765f3d
a75fb9d21d bbb785af22 78899f825b 0123e36ed8 528ba1172c 6b9d57f6d4 1d4e6ecb23 f11508a0d7 40da43ca14 ec75111a57
aec77a1a64 2bcd6f7063 8f2eee739d 9a167d8335 4356b79e9a c8ebd5d142 d54fa3f423 1f10349bf4 5ffeebb4d4 03b6d67df3""".split()
by_sha = {c["sha"]: c for c in commits}
missing = [s for s in VETTED if s not in by_sha]
assert not missing, missing
rows = [by_sha[s] for s in VETTED]
print(f"vetted entries: {len(rows)}  (48 disclosures + 1 revert); pattern and vetted list are the same set: {set(c['sha'] for c in cands) == set(VETTED)}")

# 3. the three periods the policy page defines
PERIODS = [("2025-01-01", "2025-09-19", "before the policy page"),
           ("2025-09-19", "2026-04-22", "page exists, DRAFT label from Apr 20"),
           ("2026-04-22", "2099-01-01", "adopted per the wiki edit of Apr 22")]
print()
print(f"{'period':<42}{'commits':>8}{'entries':>9}{'share':>8}")
for lo, hi, label in PERIODS:
    n = sum(1 for c in commits if lo <= c["day"] < hi)
    k = sum(1 for c in rows if lo <= c["day"] < hi)
    print(f"{label:<42}{n:>8}{k:>9}{100 * k / n:>7.2f}%")

# 4. by month
tot_m, hit_m = Counter(c["day"][:7] for c in commits), Counter(c["day"][:7] for c in rows)
print()
print("month     commits  entries")
for m in sorted(hit_m):
    print(f"{m}  {tot_m[m]:>7}  {hit_m[m]:>7}")

# 5. who: authors ranked by commits in the window; no names or addresses are printed
n_by_author = Counter(c["ae"] for c in commits)
rank = {a: i + 1 for i, (a, _) in enumerate(n_by_author.most_common())}
adopted = [c for c in rows if c["day"] >= "2026-04-22"]
print()
print(f"distinct author addresses in the window: {len(n_by_author)}; with a vetted entry: {len({c['ae'] for c in rows})}")
print(f"since Apr 22: {len(adopted)} entries from {len({c['ae'] for c in adopted})} addresses")
print("rank  commits  entries(all)  entries(since Apr 22)")
for a in sorted({c["ae"] for c in rows}, key=lambda a: rank[a]):
    print(f"{rank[a]:>4}  {n_by_author[a]:>7}  {sum(1 for c in rows if c['ae'] == a):>12}  {sum(1 for c in adopted if c['ae'] == a):>8}")

top15 = sum(1 for c in rows if rank[c["ae"]] <= 15)
every = [a for a in {c["ae"] for c in rows} if sum(1 for c in rows if c["ae"] == a) >= n_by_author[a]]
two = Counter(c["ae"] for c in adopted).most_common(2)
print(f"entries before Sep 3, 2026: {sum(1 for c in rows if c['day'] < '2026-09-03')}; from Sep 3 on: {sum(1 for c in rows if c['day'] >= '2026-09-03')}")
print(f"entries from the 15 addresses with the most commits: {top15} of {len(rows)}")
print(f"addresses whose every commit in the window is an entry: {len(every)}")
print(f"since Apr 22, the two heaviest addresses: {two[0][1]} + {two[1][1]} of {len(adopted)}")
TOOL = re.compile(r"\b(claude|copilot|chatgpt|gpt|gemini|gemma|deepseek|cursor)\b", re.I)
VER = re.compile(r"\b(sonnet|opus|gpt|gemini|gemma|deepseek|claude code)[ -]*v?\(?\d", re.I)


def text_of(c):
    return c["subj"] + chr(10) + c["body"]


print(f"since Apr 22: names a product: {sum(1 for c in adopted if TOOL.search(text_of(c)))}; "
      f"names a version: {sum(1 for c in adopted if VER.search(text_of(c)))}")

# 6. review trailers: is the only Reviewed-by trailer the author's own?
def reviewers(c):
    return [(n.strip().lower(), e.lower()) for n, e in re.findall(r"^Reviewed-by:\s*(.+?)\s*<([^>]+)>", c["body"], re.M)]
own = [c for c in adopted if c["ae"] == c["ce"]]
print()
print(f"since Apr 22: committed by their own author: {len(own)}; committed by someone else: {len(adopted) - len(own)}")
print("  of the 'someone else' commits, with a Reviewed-by trailer:", sum(1 for c in adopted if c["ae"] != c["ce"] and reviewers(c)))
authors_self = Counter(rank[c["ae"]] for c in own)
print("  self-committed entries by author rank:", dict(sorted(authors_self.items())))

# 7. project addresses and company addresses among authors of ALL commits
def group(addr):
    d = addr.split("@")[-1]
    if d in ("libreoffice.org", "documentfoundation.org"):
        return "project address"
    if d.startswith("collabora."):
        return "collabora address"
    return "other"
g_all = Counter(group(c["ae"]) for c in commits)
g_hit = Counter(group(c["ae"]) for c in rows)
print()
for k in ("project address", "collabora address", "other"):
    print(f"{k:<18} commits {g_all[k]:>6} ({100 * g_all[k] / len(commits):.1f}%)   entries {g_hit[k]}")

The script prints this at the snapshot:

non-merge commits: 18662  (2025-01-02 to 2026-10-29)
candidate commits by this pattern: 49
vetted entries: 49  (48 disclosures + 1 revert); pattern and vetted list are the same set: True

period                                     commits  entries   share
before the policy page                        6986        2   0.03%
page exists, DRAFT label from Apr 20          6196        3   0.05%
adopted per the wiki edit of Apr 22           5480       44   0.80%

month     commits  entries
2025-09      703        3
2026-04      912        3
2026-06      925        1
2026-07      921        2
2026-08      811        3
2026-09      733        5
2026-10      893       32

distinct author addresses in the window: 406; with a vetted entry: 17
since Apr 22: 44 entries from 16 addresses
rank  commits  entries(all)  entries(since Apr 22)
   3     1260             2         2
  10      365             1         0
  13      233            18        16
  34       77             1         1
 113       10            10        10
 132        8             4         2
 180        4             1         1
 195        3             3         3
 271        1             1         1
 274        1             1         1
 276        1             1         1
 277        1             1         1
 278        1             1         1
 279        1             1         1
 283        1             1         1
 285        1             1         1
 291        1             1         1
entries before Sep 3, 2026: 12; from Sep 3 on: 37
entries from the 15 addresses with the most commits: 21 of 49
addresses whose every commit in the window is an entry: 11
since Apr 22, the two heaviest addresses: 16 + 10 of 44
since Apr 22: names a product: 43; names a version: 41

since Apr 22: committed by their own author: 18; committed by someone else: 26
  of the 'someone else' commits, with a Reviewed-by trailer: 26
  self-committed entries by author rank: {3: 2, 13: 15, 34: 1}

project address    commits   2273 (12.2%)   entries 3
collabora address  commits   6642 (35.6%)   entries 0
other              commits   9747 (52.2%)   entries 46

Three things in that output are my own work rather than counts of something a project reports. The short SHAs in VETTED come from my hand reading of the candidates. The grouping into project, Collabora and other addresses uses only the domain of the author’s address, so it says nothing about who employs anyone. And the ranks are by commits per address, so a person with two addresses counts twice.

The Register’s three, and the rest

The Fediverse thread linked the Copilot commit and two commits that credit Claude, 7c0d875aca and 42cdc47554. The Register writes that the thread “highlights three LibreOffice commits this year,” that two “date from April,” and then, “More recently, September’s Add Copy Image button to screenshot dialog acknowledges using GitHub Copilot in VS Code.” The dates in the repository are different. The Copilot commit has an author date of September 19, 2025 and a committer date of September 22, 2025, so it is last year’s and the oldest of the three, more than six months before the first April commit. The Claude commits were committed on April 7 and April 23, 2026.

The Copilot commit was authored on the day the policy page was created, and its message already follows most of what the page’s first text asks. It names the product, describes the steps, and gives line ranges, “(lines 205-239)” for the class the tool wrote and “(lines 330-353)” for a method written by hand with completion support. It has no version, and it is the only entry in the log that gives line numbers.

The thread also did not include the other eight disclosures that existed by September 3. They include a September 2025 commit whose subject says an OpenCL test was improved “by ChatGPT.” A revert the same day, September 9, 2025, says, “It seems the fact that it comes from ChatGPT is a pb.” Ten days later the policy page existed. The address that authored the ChatGPT commit and the revert is the 13th busiest in the window, and it accounts for 16 of the 44 entries since April 22.

A surge, mostly from a few addresses

Disclosures were rare for a year: three entries in September 2025 (two disclosures and the revert), none from October 2025 through March 2026, three in April, one in June, two in July and three in August. September had five. October had 32 of its 893 commits, 3.6 percent, and the share since April 22 is 0.80 percent of 5,480 commits.

The curve comes from few addresses. Two of them account for 26 of the 44 entries since April 22, 16 from the 13th busiest address and 10 from an address that made only 10 commits in the whole window, every one of them in October and every one disclosing GPT 6.1 Sol High. In all, 11 of the 17 addresses with an entry have a disclosure on every commit they made in the window, and nine of those made exactly one commit. Those 11 addresses wrote 22 of the 49 entries, so a large part of what the log shows is people whose only commits in the window are LLM-assisted patches.

Who is disclosing

Addresses are not employment records, and plenty of people commit from personal addresses, so the table describes addresses only. Collabora’s absence is not evidence that its engineers do not use LLMs. The policy requires disclosure, and the log can only show what was disclosed. It is still worth noting that The Register’s account sets the foundation’s stance against Collabora, which it says made AI integration a headline feature of its CODE 26.04 release, and that the commits from Collabora addresses, a little over a third of the history, carry no disclosure.

The statements against the log

“No core developers use LLMs”

The policy page does not use the term, and the reply uses it without defining it, so I tried three proxies of my own: an author address on libreoffice.org or documentfoundation.org, a place among the busiest author addresses since January 2025, and being the committer of one’s own change, which suggests commit rights.

On September 4, when the reply was posted, five of the 11 disclosures so far came from addresses in that top 35: the 13th busiest (the 2025 ChatGPT commit and two in July that credit ChatGPT GPT-5.5), the 34th on June 26, and the tenth in 2025. The two project-address entries from the third busiest address came later. Both are test additions for existing fixes, tdf#173410 and tdf#169252. Their messages say “Patch created with Claude Sonnet 5.5,” that the author supplied the fix and asked for a test, and in one case that the test was run locally and fails without the fix. They follow the disclosure rule better than most entries, and the page allows what they describe. The point is not the practice. It is that the Mastodon sentence is seven weeks older than the first of them.

TDF may mean something narrower than I do, such as its own employees or the people who prepare releases, and I have not asked. The spokesman’s clarification does not reach this sentence, because it says the public statements were about user features, while this one was about development. What the log supports is narrower: nearly all disclosures come from outside the project’s own addresses, 46 of 49, but a claim that none comes from core developers needs a definition to survive three project-address entries, 21 entries from the 15 busiest addresses and 18 entries that their own authors committed.

“We do require people disclose”

Every entry discloses, by construction, because disclosure is how I found it. The useful question is how closely the disclosures follow the page. I read all 44 entries since April 22 and checked each against the four things the page asks for.

The product and version counts come from the script, and the steps and line-number counts come from my reading. No entry in the log meets all four, because the only one with line numbers has no version. The 12 that name only a tool are nine commits that end with “Assisted by GPT 6.1 Sol High” or the same text as an Assisted-by: trailer, two with only a Co-Authored-By: trailer that names Claude Opus 5.5 and an anthropic.com noreply address, and one that says “Claude Opus 5.5 was used.” Line numbers are a hard ask when the tool found a root cause rather than writing lines, which is what many of these messages describe, and the page does not say what to do then. At the other end are a commit that uses the page’s fields (“LLM Disclosure: Product: Claude OPUS 5.5 Steps taken:” followed by four steps), one that adds “I reviewed the code” and “take responsibility for the patch,” and the one entry that quotes its prompt.

The page asks for prose, and the log shows what prose turns into. The entries use at least eight phrasings: “Fix found with the help of,” “Assisted by,” an Assisted-by: trailer (three commits, the tag whose rules the Linux kernel has just removed), a Co-Authored-By: trailer, “LLM disclosure:”, “llm-usage:”, “Patch created with,” and first-person sentences such as “I used GPT 5.6 Luna to find root cause and for the fix.” A person can read all of that. A script cannot count it without a hand pass like mine.

“We carefully review submissions by contributors”

I cannot see the review itself, because Gerrit, where LibreOffice reviews patches, answered scripted requests with a bot check. The trailers Gerrit leaves in the commit message are enough for a count. Of the 44 entries since April 22, 26 were committed by someone other than their author, and all 26 carry a Reviewed-by trailer. The other 18 were committed by their own author, and the only Reviewed-by trailer in each names that author (in one case under a second address): 15 from the 13th busiest address, two from the third busiest and one from the 34th. For those 18 the log records no second reviewer. The project may check them in other ways, such as comments in Gerrit or review after merging, that the log cannot show. As written, the reply is consistent with the log for contributors who do not merge their own work, and the log cannot test it for those who do.

The page’s own rules: commit messages, easy hacks and students

The commit message rule is the sharpest test, because the page widened it on April 27. Commit 1fa9e5f87b, committed October 20, has a body introduced by “AI generated patch description:” and an Assisted-by: GPT 6.1 Sol High trailer. Its Reviewed-by trailer names a committer with a project address. The page says an LLM must not be used when writing the commit message. The log does not show whether the rule was waived or missed in review. I found no other entry that says its message was written by a model.

For easy hacks I looked up the keywords of the 39 bug numbers that appear in the entries through the Bugzilla REST API.

curl -s "https://bugs.documentfoundation.org/rest/bug?id=99296,121759&include_fields=id,keywords" | python -m json.tool --compact --sort-keys

{"bugs":[{"id":99296,"keywords":["difficultyInteresting","easyHack","skillCpp","topicUI"]},{"id":121759,"keywords":["bibisectNotNeeded","regression"]}]}

Only tdf#99296 carries the easyHack keyword. It appears in commit ff95e14a30, whose own bug is tdf#121759 and whose message says it “Implemented the fix suggested in comment#33 of tdf#99296” and that Claude Opus 5 was used “for code review.” I count that as a boundary case, not a breach.

The student rule is worded three ways. The page bars LLMs for “reports or proposals related to internship projects,” the ESC minutes wanted LLMs avoided for mentored Google Summer of Code projects generally, and the Mastodon reply says “LLMs are prohibited for students.” The log cannot show who is a student, so this one stays unchecked, but the reply is a wider sentence than the page.

How this compares with Debian and Linux

The Fediverse post that started the thread said LibreOffice is “still coded using AI, same as what Debian just decided to do.” Debian’s general resolution, “LLM usage in Debian,” ran its vote from August 15 to August 28, 2026 on eight proposals plus “None of the above,” and The Register reported that the winner was proposal E, “Responsible Use of Generative AI,” whose disclosure line reads, “We encourage our contributors to disclose whether a contribution was made with AI assistance, but do not require them to do so.” The principle is the same, LLMs allowed and the human responsible. The disclosure rule is not. LibreOffice’s page makes disclosure mandatory and asks for four fields, which makes it stricter than Debian’s resolution on paper.

The Linux kernel sits between them. I counted its Assisted-by tag earlier this month: the kernel committed the removal of the tag’s rules on October 14, and at my snapshot days later the tag was on 14.5 percent of the 7.4 merge window’s commits. The kernel’s tag was countable with one regular expression. LibreOffice never had a tag, and three LibreOffice entries use the kernel’s trailer anyway. If you want to know how much of a codebase is LLM-assisted, a trailer lets you count it, and LibreOffice’s prose took a hand pass over about 100 candidates.

What this means in practice

If you chose LibreOffice because it is AI-free

Read the claim at the layer where TDF makes it. According to TDF, the 26.8 release has no generative AI features and does not send documents to remote services for processing, and the default installation has no AI of any kind. I did not audit the product, and those are TDF’s statements. The development process is a different layer. The log shows LLM-assisted patches rising in disclosed numbers, mostly from outside the project’s own addresses, and the foundation’s sentence about core developers is not one to rely on without a definition. If your requirement covers how the software is made, ask for it in those terms, and expect an answer like the policy page rather than a ban.

If you contribute patches

Follow the page’s four fields even though no entry in the log meets all four: product, version, the steps, and line numbers where the tool wrote them. Write the commit message yourself, including the disclosure line. Check the bug for the easyHack keyword before involving a tool. And expect the reviewer to treat your sentence as a claim you can explain line by line, because that is the first rule on the page. The Harvard study of 718 firms that I covered found pull requests waiting longer to merge once firms adopted AI coding agents, so a policy that leans on reviewers leans on the part of the pipeline where that study found work piling up.

If you write or enforce a policy like this

• Ask for a trailer if you want counts. Prose cannot be counted without a hand pass, and eight phrasings appeared within months.
• Say what counts as use. The tab-complete question was raised in September 2025 and the page still does not answer it.
• Put the reasons on the page. The ESC’s common ground explains the rules and sits in mailing-list minutes.
• Make public sentences checkable. “No core developers use LLMs” needs a definition, or a count, or retirement.

What I could not check

I could not read Gerrit, so I do not know what reviewers said or asked, and I did not check how its permissions map to commit rights, so reading a self-committed change as commit rights is an inference. I do not know who the authors are, what roles they hold or whether any is a student, and I have not asked TDF or the authors for comment. I did not look at other repositories, such as the online editor, the help content or the website. The log cannot show LLM use that nobody disclosed, so every count here is a floor, and the foundation’s stated discouragement of LLM use may lower disclosure. I did not audit the product for AI features. The ESC minutes after June 2026 were not in the archive I could reach.

The bottom line

The Document Foundation’s product claim is precise and consistent with its policy: LibreOffice 26.8 has no generative AI features, and nothing on the policy page promises that it is built without LLMs. The development claim is the weak part. The page is stricter than Debian’s resolution on disclosure, but the 44 entries since adoption follow its format loosely, one merged commit says its description was AI generated, 18 entries carry only the author’s own review trailer, and the sentence “No core developers use LLMs” needs a definition to survive entries from the third busiest address in the repository. The count of disclosures rose from 11 on the day of the Fediverse thread to 48 on October 29. For anyone judging an AI-free claim, ask which layer it covers. For anyone writing a policy, make the disclosure countable, because the log shows what happens when it is prose.

Sources and method

I read The Register’s October 29 article in full, the September 3 Fediverse post and the September 4 reply through their instances’ public APIs, the 26.8 announcement and the September 3 blog post. I read the policy page text and its eight revisions through the wiki API, and the ESC minutes of September 11, September 18 and September 25, 2025, with the thread that followed the second. I scanned every ESC minutes post I could find from September 2025 through June 2026 for LLM and AI policy wording. The Debian material is the vote page and The Register’s report on it. The Bugzilla keywords come from the REST API for the 39 bug numbers that appear in the 49 entries, tdf#99296 being the one with the easyHack keyword.

My counts come from llmscan.py above, run on a tree-less clone with --shallow-since=2025-01-01 and pinned to commit ec75111a57. Periods use committer dates in each commit’s own time zone, and the three periods are before September 19, 2025 (the page was created), September 19, 2025 to April 21, 2026, and April 22, 2026 onward. Authors are lower-cased addresses, so one person with two addresses counts twice; the rank of an address is its place by commit count in the window. The product and version counts use regular expressions in the script, and the steps and line-number counts are my hand classification, which another reader could draw differently at the edges. The LibreOffice account’s reply is treated here as TDF’s reply, as The Register treats it. Only merged commits are in git history, so none of this describes patches that were never merged, and nothing here measures how much code a model wrote.