11 May
2026
11 May
'26
1:50 a.m.
Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact a whole
section of a spec, how can we be sure that it's not an existing specs for some
other place, possibly under copyright, that is copied or paraphrased? How can
an author guarantee that it's original work (hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a table from
a human written section, to correct the formulation of a sentence, or to draft
an example. This is notably useful for non native English speakers.
2. As a help to search existing state of art on some feature, or any kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns about LLMs,
I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive and there
opinions are highly divided, please express your opinion calmly. The fact is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
11 May
11 May
4:16 a.m.
IANAL, but the XSF IPR policy has some wording in it relevant in this
context. Specifically:
- §3.1 says that the author assigns ownership over the XEP to the XSF.
In recent case law, it was established that AI generated content lacks
human authorship. As such the author (referring to the human using the
AI) is unable to assign ownership, because they lack it themselves.
- §3.1 also says the XEP shall be copyrighted by the XSF. In recent
case law, it was found that AI generated content can not be
copyrighted.
- §4 mandates that the XEP carries certain legal notices, including a
copyright notice. As the XSF does not own any copyright on the AI
generated content (because it can't have copyright), such copyright
notice would be invalid.
- §4 also mandates that the XEP itself carries a notice that the XEP
was contributed in full conformance with the IPR policy.
To me this means that AI generated content that is not primarily
created by a human does not and can not comply with the IPR policy and
thus can neither be submitted by the author nor accepted by the XSF.
If we wanted to allow submission of AI generated XEPs, it would be a
board subject to adjust the IPR policy accordingly.
Marvin
On Mon, 2026-05-11 at 09:50 +0200, Goffi wrote:
Hello everybody,
I would like to bring a discussion on AI policy. We can't really
ignore
anymore that modern models have become very capable, and I suspect
that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact
a whole
section of a spec, how can we be sure that it's not an existing specs
for some
other place, possibly under copyright, that is copied or paraphrased?
How can
an author guarantee that it's original work (hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a
table from
a human written section, to correct the formulation of a sentence, or
to draft
an example. This is notably useful for non native English speakers.
2. As a help to search existing state of art on some feature, or any
kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns
about LLMs,
I think that 1. and 2. are OK, and 3. should be forbidden. And in all
cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with
legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive
and there
opinions are highly divided, please express your opinion calmly. The
fact is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
4:59 a.m.
On Mon, 11 May 2026 at 11:18, Marvin W. via Standards
<standards(a)xmpp.org> wrote:
To me this means that AI generated content that is not
primarily
created by a human does not and can not comply with the IPR policy and
thus can neither be submitted by the author nor accepted by the XSF.
If we wanted to allow submission of AI generated XEPs, it would be a
board subject to adjust the IPR policy accordingly.
I agree with this analysis. However I would note that "recent case
law" is specific to each jurisdiction and subject to change.
I would also note to all members that it's tempting to extrapolate
from "AI generated content can not be copyrighted" that such content
is outside copyright law and therefore cannot then violate copyright
law. However, this is not an accepted fact. These two aspects are
independent.
Due to the evolving relationship between "AI" and the law, I think we
must require disclosure, at a minimum, regardless of whether Board
decides to permit such contributions. Having this on record ensures
there are no nasty surprises down the road, which is the primary
purpose of the IPR policy in the first place.
For various reasons, I would very happily forbid use of LLMs and
similar tools in spec development. However, similar to the recent
debate about use of "real names", this is basically unenforceable.
Drawing clear lines between the extremes of "I only used it for
grammar checking" and "it wrote the whole document" is practically
impossible, especially at the rate such models are being integrated
into everyday tools and services — there is simply no way to prove
someone did or did not use them.
Regards,
Matthew
8:14 a.m.
Hi list,
(sorry Matthew, I'm going to quote you a little bit out of order, but
hopefully without disturbing the meaning of your message.)
On Montag, 11. Mai 2026 12:59:36 Mitteleuropäische Sommerzeit Matthew Wild
wrote:
Due to the evolving relationship between
"AI" and the law, I think we
must require disclosure, at a minimum, regardless of whether Board
decides to permit such contributions. Having this on record ensures
there are no nasty surprises down the road, which is the primary
purpose of the IPR policy in the first place.
If we have sufficient reason to require disclosure for legal reasons (and I
agree with the thread that we have, due to how the IPR Policy works), then I
don't see how we can allow AI contributions at the same time.
Suppose that it turns out that in general, AI contributions cannot be handled
under our IPR Policy. Untangling that mess post-hoc seems like an impossible
thing to do, especially because:
[… out of order quote …] especially at the rate such
models are being
integrated into everyday tools and services — there is simply no way to
prove someone did or did not use them.
is likely to cause many contributions to be made with AI assistance, if
allowed.
However, similar to the recent
debate about use of "real names", this is basically unenforceable.
Drawing clear lines between the extremes of "I only used it for
grammar checking" and "it wrote the whole document" is practically
impossible […out of order quote…]
This is true, but by forbidding it/requiring disclosure, the liability
_should_ (IANAL!) move to the submitter instead of the XSF. Similarly to how
it works under the current IPR Policy if you attempt to assign copyright of
something to the XSF where you're not allowed to.
Now we could argue that requiring the assertion of copyright assignment
already puts the burden on the submitter to ensure that the AI contribution
can, in fact, be assigned. I'm not sure I would like to rely on this, however.
kind regards,
Jonas
8:54 a.m.
On Mon, 11 May 2026 at 15:14, Jonas Schäfer <jonas(a)wielicki.name> wrote:
Now we could argue that requiring the assertion of
copyright assignment
already puts the burden on the submitter to ensure that the AI
contribution
can, in fact, be assigned. I'm not sure I would like to rely on this,
however.
Fair enough, but we already do rely on it for all cases other than AI.
By saying we won't rely on it for AI, doesn't that weaken our position for
non-AI as well?
And if not, then why not?
Dave.
5:11 a.m.
Having had my copyright in Wimsy challenged already (sigh), let me inject
some research reapplied to this...
I am also not a lawyer, but I did read the judgements.
On Mon, 11 May 2026 at 11:18, Marvin W. via Standards <standards(a)xmpp.org>
wrote:
IANAL, but the XSF IPR policy has some wording in it
relevant in this
context. Specifically:
- §3.1 says that the author assigns ownership over the XEP to the XSF.
In recent case law, it was established that AI generated content lacks
human authorship. As such the author (referring to the human using the
AI) is unable to assign ownership, because they lack it themselves.
That's not the case globally, by any stretch. In the United Kingdom, for
example, the Copyright Designs and Patents Act of 1988 says that if a work
is computer generated, then the copyright rests with the human who caused
it to be created:
https://www.legislation.gov.uk/ukpga/1988/48/section/9
In the case of a literary, dramatic, musical or artistic work which is
computer-generated, the author shall be taken to be
the person by whom the
arrangements necessary for the creation of the work are undertaken.
Having legislation in place puts the UK in a rather unique situation, and
this law is currently under review as I understand things. Though I'd note
that our government is at least as incompetent as the others around the
world, so I wouldn't hold my breath...
- §3.1 also says the XEP shall be copyrighted by the
XSF. In recent
case law, it was found that AI generated content can not be
copyrighted.
As far as I can tell, only the US has any case law related specifically to
AI, under Thaler v. Perlmutter (D.D.C. 2023). However, this explicitly
refers to "AI‑generated works without human creative input", as does the
CJEU case law (which isn't specific to AI, but establishes the same basic
precedent).
The Thaler v Perlmutter case seems to have been broadly misinterpreted.
Thaler submitted a work for copyright registration that was explicitly
authored only by an AI - he explicitly listed the AI as the sole author -
and Dr Thaler himself wanted to claim copyright over it. Dr Thaler
explicitly claimed he had not authored it.
From the appeal judgement:
In this case, a computer scientist attributes
authorship of an artwork to
the operation of software. Dr. Stephen Thaler created a generative
artificial intelligence named the “Creativity Machine.” The Creativity
Machine made a picturethat Dr. Thaler titled “A Recent Entrance to
Paradise.” Dr. Thaler submitted a copyright registration application for “A
Recent Entrance to Paradise” to the United States Copyright Office. On the
application, Dr. Thaler listed the Creativity Machine as the work’s sole
author and himself as just the work’s owner.
Furthermore, if a specification was partially written by AI, then even if a
paragraph were written entirely autonomously (tricky!) then the aggregate
whole would be copyrightable by the person assembling it, since a derived
work of an uncopyrightable work is still copyrightable.
- §4 mandates that the XEP carries certain legal
notices, including a
copyright notice. As the XSF does not own any copyright on the AI
generated content (because it can't have copyright), such copyright
notice would be invalid.
That seems predicated on the prior assertions, so I would argue that it's
false.
- §4 also mandates that the XEP itself carries a
notice that the XEP
was contributed in full conformance with the IPR policy.
Likewise.
To me this means that AI generated content that is not
primarily
created by a human does not and can not comply with the IPR policy and
thus can neither be submitted by the author nor accepted by the XSF.
I think you've misread the case law, which doesn't say "primarily
created
by a human", but deals entirely with the opposite extreme, "without human
creative input".
If we wanted to allow submission of AI generated XEPs,
it would be a
board subject to adjust the IPR policy accordingly.
I don't think it would.
The IPR policy requires, as you note, copyright assignment, but in so doing
it also requires that the contributor assert that they have the copyright
to assign. We already have some (much!) more interesting cases, such as if
I write and contribute a ProtoXEP, then under UK Law if I have done so in
the course of my employment, the copyright rests with my employer and not
me.
Marvin
On Mon, 2026-05-11 at 09:50 +0200, Goffi wrote:
Hello everybody,
I would like to bring a discussion on AI policy. We can't really
ignore
anymore that modern models have become very capable, and I suspect
that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact
a whole
section of a spec, how can we be sure that it's not an existing specs
for some
other place, possibly under copyright, that is copied or paraphrased?
How can
an author guarantee that it's original work (hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a
table from
a human written section, to correct the formulation of a sentence, or
to draft
an example. This is notably useful for non native English speakers.
2. As a help to search existing state of art on some feature, or any
kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns
about LLMs,
I think that 1. and 2. are OK, and 3. should be forbidden. And in all
cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with
legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive
and there
opinions are highly divided, please express your opinion calmly. The
fact is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
5:48 a.m.
On Mon, 11 May 2026 at 08:51, Goffi <goffi(a)goffi.org> wrote:
This raises, I believe, copyright issues: if someone
use AI to redact a
whole
section of a spec, how can we be sure that it's not an existing specs for
some
other place, possibly under copyright, that is copied or paraphrased? How
can
an author guarantee that it's original work (hint: they can't)?
Rewrite that paragraph, but drop the AI reference. If you'll pardon me
making a derived work without explicit licence (copyright joke, hopefully,
but see below) you end up with:
This raises, I believe, copyright issues: if someone writes a whole section
of a spec, how can we be sure it's not an existing
specs for some other
place, possibly under copyright, that is copied or paraphrased? How can an
author guarantee that it's original work (hint: they can't)?
Actually, an author can guarantee that they are in a position to assign the
copyright to the document to the XSF. By, literally, saying so.
This indemnifies the XSF entirely (as long as we ensure it's explicit,
which I believe we do) - as far as the XSF is concerned, we had the
copyright assigned to us by someone who warranted that they were able to do
so. Therefore, we believe we own the copyright in good faith.
Should this be discussed with board or council?
Board! It's firmly a Board matter, not a Council one. You're lucky!
But anyway - I would first and foremost suggest that AI generated text is
just one aspect of copyrightability and copyright ownership, and
concentrate on whether or not the submitter asserts they have the right to
assign, and have done so.
This is particularly weak, I think, for changes to XEPs where the wording
is taken from messages on the standards list. For initial submissions via
GitHub we have (I think?) the IPR sign-off; though I'd prefer this to be on
every submission instead of a one-off. I would much rather require that
assignment (and the corresponding assertion of ability) is made much
broader, and covered for example this message, and messages, comments, and
so on in other XSF venues.
Indeed, on a strict reading, by quoting Goffi's note here I have made a
derived work, and I don't actually know that there is a strict licence
permitting me to do so. More complex still is the paragraph I rewrote. I
think I'm safe in assuming that Goffi would allow this. I think. But what
if someone then incorporates my (derived work) paragraph into a XEP, thus
assigning the copyright in my derived work paragraph wholly to the XSF? Who
has done that assignment, and who needs to?
I would personally lean away from having to explicitly mention AI usage,
much less forbid it. It is widely misunderstood how copyright and AI
intersect in both case law and legislation in different jurisdictions, and
it's a lot less settled than you may think, as I note in my other message.
I'm unconvinced it's possible to use AI in a way that would produce an
uncopyrightable XEP contribution beyond simple grammar/spelling passes, but
I worry that any mention of AI usage will make people believe that case law
in the US means there cannot be any copyright at all. As I say, I've
already had that with Wimsy - one of the only PRs against it was removing
my copyright and licence on this basis!
Dave.
6:40 a.m.
On 11/05/2026 13.48, Dave Cridland wrote:
[..]
Actually, an author can guarantee that they are in a position to
assign the copyright to the document to the XSF. By, literally, saying so.
This indemnifies the XSF entirely (as long as we ensure it's explicit,
which I believe we do) - as far as the XSF is concerned, we had the
copyright assigned to us by someone who warranted that they were able
to do so. Therefore, we believe we own the copyright in good faith.
[..] I would first and foremost suggest that AI generated text is
just one aspect of copyrightability and copyright ownership, and
concentrate on whether or not the submitter asserts they have the
right to assign, and have done so.
I agree with this point of view. It does not matter how the work was
authored or by what or whom. Making a special case for AI does not make
sense to me here, and may actually make it harder on the XSF.
[..] I would much rather require that assignment (and
the
corresponding assertion of ability) is made much broader, and covered
for example this message, and messages, comments, and so on in other
XSF venues.
We discussed whether we should have a general Note Well, modeled after
the IETF's, before. Is that your suggestion here?
--
ralphm
7:55 a.m.
On Mon, 11 May 2026 at 13:40, Ralph Meijer <ralphm(a)ik.nu> wrote:
On 11/05/2026 13.48, Dave Cridland wrote:
[..]
Actually, an author can guarantee that they are in a position to assign
the copyright to the document to the XSF. By, literally, saying so.
This indemnifies the XSF entirely (as long as we ensure it's explicit,
which I believe we do) - as far as the XSF is concerned, we had the
copyright assigned to us by someone who warranted that they were able to do
so. Therefore, we believe we own the copyright in good faith.
[..] I would first and foremost suggest that AI generated text is just
one aspect of copyrightability and copyright ownership, and concentrate on
whether or not the submitter asserts they have the right to assign, and
have done so.
I agree with this point of view. It does not matter how the work was
authored or by what or whom. Making a special case for AI does not make
sense to me here, and may actually make it harder on the XSF.
Right.
[..] I would much rather require that assignment (and
the corresponding
assertion of ability) is made much broader, and covered for example this
message, and messages, comments, and so on in other XSF venues.
We discussed whether we should have a general Note Well, modeled after the
IETF's, before. Is that your suggestion here?
TL;DR: Yes.
We drift, somewhat, from the topic of the thread... But:
For those who are unaware, or who have forgotten, or don't care and wish we
weren't discussing this on standards, any IETF Activity begins by having
the Note Well text appear on a screen somewhere. If you join a mailing list
(and possibly on the mailman password reminders and similar), you'll get a
copy, and if you're at a physical or virtual meeting it is (or should be)
the first slide you'll see.
As I understand it, the IETF's Note Well operates as a "click through
licence" - "By participating here, your contributions falls under the
IPR",
very loosely.
However, the IETF's IPR is one based on licence (ignoring the patents area
for the moment, though that is important too for the XSF). I can licence
stuff to you (or anyone) just by saying I do; it's a unilateral action, and
so is quite convenient, legally. It's why the GPL was created as a
copyright licence, rather than a contract, despite it having some fairly
contractual-looking clauses in. They're broadly handled by all
jurisdictions where the Berne Convention is a thing - which is nearly the
entire globe.
The XSF operates on copyright assignment, however. Copyright assignments
are different in as much as under at least some jurisdictions (like the UK,
but also others) need a written, signed assignment. In some, assigning
copyright in advance of creation of the work has additional hoops to jump
through. The best way of handling assignments is by contract (for which a
consideration is required) or by a deed (which is the one with witnessed
signatures). We definitely don't want to do deeds, they're a pain.
As such, doing an assignment on click-through might work in some
jurisdictions - it looks to me like Germany, Italy, and France might all be
problematic, but the UK, US, and others might be OK. The ideal would be to
collect actual signed documents from participants, and gate participation
on having that document. We could do online signing to make that simpler,
obviously. It's not clear to me which jurisdiction we actually operate in,
for this, so it makes sense (to me) to make things as rock solid as we can
without getting in people's way too much.
But the advantage of an explicit, signed (equivalent) IPR agreement from
all participants is that not only is our copyright status rock-solid, but
we can properly address patents, which our policy is quite weak on -
loosely, it says that if we find any we'll hand-wave our way to a
replacement XEP. I'd rather see the IETF's policy or something similar,
saying that as particpants we will notify the XSF if we believe any IPR
claim affects a XEP, and that the XSF will distribute such notifications
but takes no view on their validity. This protects against stumbling onto
patents, but much more importantly it protects against "submarine patents",
where a participant deliberately introduces patent-protected concepts into
a XEP and keeps quiet about it.
It's possible all this is either wishful thinking, or simply too much work
to manage. But it'd be nice if we did it, I think.
Dave.
10:21 a.m.
Hi Jonas,
Le lundi 11 mai 2026, 17:59:05 heure d’été d’Europe centrale Jonas Schäfer a
écrit :
Hi Goffi, list,
On Montag, 11. Mai 2026 09:50:19 Mitteleuropäische Sommerzeit Goffi wrote:
The full sentence is:
put aside ethical and ecological concerns about
LLMs
Why though? Instinctively, and If we put aside ethical and
ecological concerns about
LLMs, I think that 1. and 2. are OK, and 3. should be forbidden.
That reads "1. and 2. are OK if we put aside ethical and ecological concerns",
which are relevant in general, but not directly in the question raised here
(which is more about legality and how XSF should handle AI in contributions).
Best,
Goffi1
12 May
12 May
5:57 a.m.
To me, AI is just a tool that helps you work on text. Person who uses it
still has the final say on what is being submitted. Thus, just like nobody
cares about texts being processed with other tools — spellcheckers, text
processors, XMP beautifiers, etc. —nobody should care about how the text
was produced, even if LLM generated the entire section (in fact, the last 4
words were generated by Gmail's auto-suggestion to use active voice, and it
replaced my previous phrasing).
So, i my opinion, the best course is to ignore capabilities of modern
models and just let the submitters be responsible for what they authored in
whatever way they like. Also, I don't think that LLM involvement can be
reliably proved anyway, so ....
On Mon, 11 May 2026 at 12:50, Goffi <goffi(a)goffi.org> wrote:
Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that
they
are used for spec authoring.
--
Andrew Nenakhov
https://redsolution.com <http://www.redsolution.com>
11:50 a.m.
Should this matter be on the board agenda? Do we want to discuss it more here first?
Thanks
Le 11 mai 2026 09:50:19 GMT+02:00, Goffi <goffi(a)goffi.org> a écrit :
Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact a whole
section of a spec, how can we be sure that it's not an existing specs for some
other place, possibly under copyright, that is copied or paraphrased? How can
an author guarantee that it's original work (hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a table from
a human written section, to correct the formulation of a sentence, or to draft
an example. This is notably useful for non native English speakers.
2. As a help to search existing state of art on some feature, or any kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns about LLMs,
I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive and there
opinions are highly divided, please express your opinion calmly. The fact is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
12:24 p.m.
Hi Goffi,
Thanks for raising this topic. It is one that interests a lot of people -
the quick responses to your initial message show that, too.
As for bringing this before Board: I think the discussion so far shows
there is far from consensus on whether the current IPR policy sufficiently
addresses AI-assisted contributions, or whether additional
policy/guidance/disclosure requirements/procedural changes are needed: Some
participants argue the existing policy is already sufficient, while others
believe AI-generated material introduces significant risks that are not
adequately addressed today.
Given that, my suggestion would be to continue the mailing list discussion
a bit longer to clarify concrete problem statements and possible outcomes.
That way, the Board can benefit from the technical and legal perspectives
being surfaced here. I believe this will reduce the risk of prematurely
forcing a decision, before the tradeoffs are better articulated.
I'm particularly interested in the formulation of concrete, actionable
proposals. I think that is where the real challenge lies, especially given
that there appears to be agreement on the following points:
- The legal situation is jurisdiction-dependent and evolving.
- Enforcement of any strict prohibition would be difficult in practice.
Once the discussion produces a clearer set of possible approaches, I think
it would make sense to bring those to Board for consideration.
Kind regards,
Guus
On Tue, May 12, 2026 at 7:50 PM Goffi <goffi(a)goffi.org> wrote:
Should this matter be on the board agenda? Do we want
to discuss it more
here first? Thanks
Le 11 mai 2026 09:50:19 GMT+02:00, Goffi <goffi(a)goffi.org> a écrit :
Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact a whole
section of a spec, how can we be sure that it's not an existing specs for some
other place, possibly under copyright, that is copied or paraphrased? How can
an author guarantee that it's original work (hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a table from
a human written section, to correct the formulation of a sentence, or to draft
an example. This is notably useful for non native English speakers.
2. As a help to search existing state of art on some feature, or any kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns about LLMs,
I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive and there
opinions are highly divided, please express your opinion calmly. The fact is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
_______________________________________________
Standards mailing list --
standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
13 May
13 May
3:30 a.m.
On Tue, 12 May 2026 at 19:24, Guus der Kinderen <guus.der.kinderen(a)gmail.com>
wrote:
As for bringing this before Board: I think the
discussion so far shows
there is far from consensus on whether the current IPR policy sufficiently
addresses AI-assisted contributions, or whether additional
policy/guidance/disclosure requirements/procedural changes are needed: Some
participants argue the existing policy is already sufficient, while others
believe AI-generated material introduces significant risks that are not
adequately addressed today.
"AI-assisted" falls under entirely different existing law than
"AI-generated", at least in all jurisdictions I've looked at outside of the
UK - we should be careful about which terms we're using here.
In the US, something that is *entirely* AI-generated (ie, with no human
assistance) would seem to be covered by the Thaler case. But that case
hinged on the fact that Dr Thaler explicitly disclaimed authorship of the
work.
My gut feeling is that this was a deliberate test case, actually, since Dr
Thaler had, after all, created the generative AI which in turn created the
artwork, and could have quite reasonably claimed to be the author, but that
wasn't the argument advanced.
The US Copyright authority - I forget the name - has also rejected
copyright claims for images generated (presumably from a single prompt) by
Midjourney, an image generation tool, though this has not been tested in
the US Courts.
Based on this, so far, I would expect that a XEP produced from a single
prompt, especially a trivial one, would not be copyrightable in the United
States... But I also don't think it's possible to produce a XEP of
sufficient quality that way.
On the other hand, I think the two viable cases of LLM usage would be
copyrightable here - again, I'm not a lawyer, but I have researched this
quite heavily:
1) Use of an LLM to generate the initial skeleton of a XEP - filling in
title, boilerplate, and some introductory paragraphs - the XEP would then
have significant human editing.
2) Use of an LLM on a submission to tidy it up - cleaning up grammar,
fixing inconsistent examples, even adding additional explanatory paragraphs.
I think either of these or even both in combination would be copyrightable.
The Thaler case depended on whether "human creativity" had been involved,
and not whether AI had been. Dr Thaler insisted that human creativity had
not been involved.
(Since someone's bound to ask, and I accept this is all contentious, I
write all my specs myself, but do find LLM reviews quite helpful to spot
errors - which I correct manually. But I *like* writing, and I'm writing in
my native language, I certainly won't judge others for using whatever tools
make their lives easier)
Note that it is entirely possible that the "additional explanatory
paragraphs" I note above would be uncopyrightable in isolation - though
that is definitely not clear from case law. But incorporating those into
another work that *is* itself copyrightable would yield a work which is
copyrightable - there is substantial case law to back that one up. The
additional explanatory paragraphs - the pure AI generated text - could
still be extracted without copyright, but the author need not identify
which those are. Moreover, the slightest edit to those paragraphs turns
them into a derivative work, and makes them (independently) copyrightable
independently.
However - and I think this is key from a purely legal perspective - none of
this is an issue about AI, it's an issue about uncopyrightable text. If you
want to research this, don't ask about AI - ask about Shakespeare, which is
out of copyright. Just as well we don't use any of *that* in our
specifications...
Given that, my suggestion would be to continue the mailing list discussion
a bit longer to clarify concrete problem statements and possible outcomes.
That way, the Board can benefit from the technical and legal perspectives
being surfaced here. I believe this will reduce the risk of prematurely
forcing a decision, before the tradeoffs are better articulated.
I think this is a very good point - what's the outcome of the XSF
publishing something that is entirely uncopyrightable (and, as I say, this
is very hypothetical)? We publish XEPs widely, under a highly permissive
licence, that allows essentially any use. The only restriction we have is,
in fact, our copyright. Claiming a copyright that one does not in fact
possess carries a legal risk, though honestly I have no idea what the
recourse would be here. There's almost nothing that would change, really,
so I'd argue our legal exposure is very low. But I think it's avoidable.
Peter Saint-Andre has argued before that we should simply disclaim
copyright (and require submissions to do the same) - this would eliminate
the problem entirely.
We could quite conceivably do something in the middle. If a submitter has
to say something along the lines of:
"In as much as copyright exists in this contribution, the submitter asserts
and warrants they have permission granted by all copyright holders to
assign it in perpetuity to the XSF; furthermore it is hereby assigned to
the XSF"
... you need more than this but you get the idea hopefully - and the XSF
publishes XEPs with, in Appendix C's Section "Copyright":
"To the extent that Copyright may be asserted, this XMPP Extension Protocol
is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF)."
Then that might be sufficient to allow for entirely uncopyrightable XEPs to
be published safely.
I'm not sure the second bit - the XSF copyright statement change - needs to
happen, in fact. Simply publishing a Submission is, I think, enough to make
it copyrightable even if all the text in it isn't.
Note two things:
1) I don't think uncopyrightable XEPs can exist from AI, at the very least
for the foreseeable future.
2) Nevertheless, this covers cases such as the original author putting a
spec in the public domain, and then submitting it (or someone else doing
so). That's a much more practical and legally clear way to get into this
situation.
Legal advice should be sought on this, though, obviously.
Dave.
14 May
14 May
4:24 p.m.
Hi,
I’ve been lurking for a good year now, but this is finally something I can
help with.
Dne sreda, 13. maj 2026 ob 11:30:15 Srednjeevropski poletni čas je Dave
Cridland napisal(a):
Legal advice should be sought on this, though,
obviously.
I am a lawyer, I do specialize in IPR, specifically copyright and FOSS
licensing, and I happen to have to deal with AI at work as well as have co-
authored the FLA¹ – an actually balanced CLA. But I am not an attorney, so I
cannot provide Legal Advice. Still, I can provide my thoughts, once we have a
rough idea what we want to achieve with this.
From what I followed the thread so far, Dave has already written a lot that I
would have written too, so I will not repeat or rephrase that.
Some short reading material on the topic for anyone interested:
• <https://legallayer.substack.com/p/who-owns-the-claude-code-wrote> – a good,
short intro into copyright in AI-generated stuff (mostly US-centric; and I
would advise to use other tools than those mentioned)
• <https://airisk.mit.edu/> – the most comprehensive overview of different AI
risk, that I know of
I will leave it at that for now, as I am neck-deep in work right now, but will
keep an eye on this thread and come back with more later.
cheers,
Matija
—
¹ https://fsfe.org/activities/fla/fla.en.html
We are currently finalising FLA-2.1. The RC is already on GitHub, but we
will wait for a few weeks more to gather some info about some details.
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: hook(a)campfire.wheremymonkeyis.at
matrix: @hook:kompot.si
13 May
13 May
9:41 a.m.
Hey Guus,
I very much agree that there doesn't seem to be consensus on what to do
really but I would argue that there is consensus we should do
"something". This is not ready for any Board consideration as you said.
That said I do not think that consensus will "naturally" come up if we
talk about this long enough (see MIX/MUC, SIMS/SFS, twitter/X, CoC
discussion etc.). What is needed is a well defined way with help of
facilitation to actually reach a consensus. Note that I have offered
before a decision making way other than "wait for consensus to appear by
itself" to XSF members privately but I never heard back so I'm
mentioning it here to be on record.
MSavoritias
On 5/12/26 21:24, Guus der Kinderen wrote:
Hi Goffi,
Thanks for raising this topic. It is one that interests a lot of
people - the quick responses to your initial message show that, too.
As for bringing this before Board: I think the discussion so far shows
there is far from consensus on whether the current IPR policy
sufficiently addresses AI-assisted contributions, or whether
additional policy/guidance/disclosure requirements/procedural changes
are needed: Some participants argue the existing policy is already
sufficient, while others believe AI-generated material introduces
significant risks that are not adequately addressed today.
Given that, my suggestion would be to continue the mailing list
discussion a bit longer to clarify concrete problem statements and
possible outcomes. That way, the Board can benefit from the technical
and legal perspectives being surfaced here. I believe this will reduce
the risk of prematurely forcing a decision, before the tradeoffs are
better articulated.
I'm particularly interested in the formulation of concrete, actionable
proposals. I think that is where the real challenge lies, especially
given that there appears to be agreement on the following points:
* The legal situation is jurisdiction-dependent and evolving.
* Enforcement of any strict prohibition would be difficult in practice.
Once the discussion produces a clearer set of possible approaches, I
think it would make sense to bring those to Board for consideration.
Kind regards,
Guus
On Tue, May 12, 2026 at 7:50 PM Goffi <goffi(a)goffi.org> wrote:
Should this matter be on the board agenda? Do we want to discuss
it more here first? Thanks
Le 11 mai 2026 09:50:19 GMT+02:00, Goffi <goffi(a)goffi.org> a écrit :
Hello everybody, I would like to bring a discussion on AI
policy. We can't really ignore anymore that modern models have
become very capable, and I suspect that they are used for spec
authoring. This raises, I believe, copyright issues: if
someone use AI to redact a whole section of a spec, how can we
be sure that it's not an existing specs for some other place,
possibly under copyright, that is copied or paraphrased? How
can an author guarantee that it's original work (hint: they
can't)? I think that there are 3 distinct uses: 1. As a light
formatting/checking help, for instance to generate a table
from a human written section, to correct the formulation of a
sentence, or to draft an example. This is notably useful for
non native English speakers. 2. As a help to search existing
state of art on some feature, or any kind of data, without
writing anything in a protoXEP. 3. As a way to generate whole
sections. Instinctively, and If we put aside ethical and
ecological concerns about LLMs, I think that 1. and 2. are OK,
and 3. should be forbidden. And in all cases, it should be
disclosed. I would like your feedback on this matter, in
particular people with legal knowledge. I would like to avoid
a flamewar, I know that this topic is sensitive and there
opinions are highly divided, please express your opinion
calmly. The fact is, we can't ignore this anymore. Should this
be discussed with board or council? Thanks. Best, Goffi
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
_______________________________________________
Standards mailing list --standards(a)xmpp.org
To unsubscribe send an email tostandards-leave(a)xmpp.org
7 Jul
7 Jul
9:55 a.m.
Hi,
This discussion is stalling.
Meanwhile, we've got specification(s?) which have been clearly written with AI,
and I guess it will be more and more often the case.
As a reviewer with my council hat, I would really love to at least have
disclaimer when AI is used (is it for writing whole sections, to extract a
table, to write example, to check spelling/grammar).
Many big projects have a statement on AI use, e.g., CPython:
https://devguide.python.org/getting-started/ai-tools/
I think XSF should have one too.
Do we need more discussion on standard, or should the board discuss that and
ask a team to work on a AI statement?
Thanks
Goffi
Le lundi 11 mai 2026, 09:50:19 heure d’été d’Europe centrale Goffi a écrit :
Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact a
whole
section of a spec, how can we be sure that it's
not an existing specs for
some
other place, possibly under copyright, that is copied
or paraphrased? How
can
an author guarantee that it's original work (hint:
they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a table
from
a human written section, to correct the formulation of
a sentence, or to
draft
an example. This is notably useful for non native
English speakers.
2. As a help to search existing state of art on some feature, or any kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns about
LLMs,
I think that 1. and 2. are OK, and 3. should be
forbidden. And in all cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive and
there
opinions are highly divided, please express your
opinion calmly. The fact
is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
11:23 a.m.
i am deaf software engineer. I have written with AI because many deaf poeple don’t speak
English as first language. Without AI it would take more time. All of sources must be
verified to prevent hallucinations. We need some rules for using AI. It should to prevent
errors that are made by AI.
Edward Rue.
Verstuurd vanaf mijn iPhone
Op 7 jul 2026 om 17:56 heeft Goffi
<goffi(a)goffi.org> het volgende geschreven:
Hi,
This discussion is stalling.
Meanwhile, we've got specification(s?) which have been clearly written with AI,
and I guess it will be more and more often the case.
As a reviewer with my council hat, I would really love to at least have
disclaimer when AI is used (is it for writing whole sections, to extract a
table, to write example, to check spelling/grammar).
Many big projects have a statement on AI use, e.g., CPython:
https://devguide.python.org/getting-started/ai-tools/
I think XSF should have one too.
Do we need more discussion on standard, or should the board discuss that and
ask a team to work on a AI statement?
Thanks
Goffi
Le lundi 11 mai 2026, 09:50:19 heure d’été d’Europe centrale Goffi a écrit :
Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact a
whole
section of a spec, how can we be sure that
it's not an existing specs for
some
other place, possibly under copyright, that is
copied or paraphrased? How
can
an author guarantee that it's original work
(hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a table
from
a human written section, to correct the
formulation of a sentence, or to
draft
an example. This is notably useful for non native
English speakers.
2. As a help to search existing state of art on some feature, or any kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns about
LLMs,
I think that 1. and 2. are OK, and 3. should be
forbidden. And in all cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive and
there
opinions are highly divided, please express your
opinion calmly. The fact
is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
<signature.asc>
1:16 p.m.
Hi,
It is still not very clear to me what the objective is and how a requirement to disclose
the use of AI achieves it. I see these angles:
1. AI may generate output that is of low quality (incomplete, vague, false, superfluous).
2. AI may generate output that includes parts of other works without attribution and/or
permission (from a rights perspective).
I do not see why these problems uniquely exist because of the use of AI, and why this
isn't covered by an author's existing responsibility to ensure quality and the
pre-conditions for assigning ownership rights to the XSF per its IPR policy (in particular
sections 3.1 and 3.2).
If you cannot formulate the requirements for quality for humans, then how does declaring
use of AI make things better? And if you can, and a submission complies, how does it
matter that AI was used in the process? How would you handle “AI-tainted” submissions
differently?
The same holds for potential rights issues. The author is still responsible.
My concern is that all future submissions will just have this disclosure as boilerplate,
and a recipient cannot assess how deep the impact of the use of AI is. With the
accelerating growth we see in both the capabilities and the use of AI, this becomes
increasingly hard. We will not have gained anything substantial. In that regard it reminds
me of the Evil Bit (RFC 3514) / Malicious Stanzas (XEP-0076).
The statement you linked to seems like common sense and doesn't actually require
disclosure. Consider this document again, but conceptually replace “the use of AI” with
the “use of a keyboard”. Does having such a statement change the outcome of our standards
process?
I think that our author guidelines (XEP-0143) are already clear, and sense all the above
boils down to this:
“Authors must understand, verify, and take responsibility for every contribution they
submit.” (-- ChatGPT with my prompting)
While noting that this stance is not universally accepted (e.g. see
<https://jme.bmj.com/content/51/4/230>), I think it is suitable for our standards
process. Feel free to use this phrase in a concrete proposal, like a PR to XEP-0143.
Cheers,
ralphm
Disclosure: this message was manually (glide) typed on a OnePlus 12, using Google Board,
in Thunderbird for Android. Conversing with AI may have influenced my thought process.
Except where explicitly noted, no excerpts of other works were included in this message.
On 7 July 2026 17:55:54 CEST, Goffi <goffi(a)goffi.org> wrote:
Hi,
This discussion is stalling.
Meanwhile, we've got specification(s?) which have been clearly written with AI,
and I guess it will be more and more often the case.
As a reviewer with my council hat, I would really love to at least have
disclaimer when AI is used (is it for writing whole sections, to extract a
table, to write example, to check spelling/grammar).
Many big projects have a statement on AI use, e.g., CPython:
https://devguide.python.org/getting-started/ai-tools/
I think XSF should have one too.
Do we need more discussion on standard, or should the board discuss that and
ask a team to work on a AI statement?
Thanks
Goffi
Le lundi 11 mai 2026, 09:50:19 heure d’été d’Europe centrale Goffi a écrit :
Hello everybody,
I would like to bring a discussion on AI policy. We can't really ignore
anymore that modern models have become very capable, and I suspect that they
are used for spec authoring.
This raises, I believe, copyright issues: if someone use AI to redact a
whole
section of a spec, how can we be sure that
it's not an existing specs for
some
other place, possibly under copyright, that is
copied or paraphrased? How
can
an author guarantee that it's original work
(hint: they can't)?
I think that there are 3 distinct uses:
1. As a light formatting/checking help, for instance to generate a table
from
a human written section, to correct the
formulation of a sentence, or to
draft
an example. This is notably useful for non native
English speakers.
2. As a help to search existing state of art on some feature, or any kind of
data, without writing anything in a protoXEP.
3. As a way to generate whole sections.
Instinctively, and If we put aside ethical and ecological concerns about
LLMs,
I think that 1. and 2. are OK, and 3. should be
forbidden. And in all cases,
it should be disclosed.
I would like your feedback on this matter, in particular people with legal
knowledge.
I would like to avoid a flamewar, I know that this topic is sensitive and
there
opinions are highly divided, please express your
opinion calmly. The fact
is,
we can't ignore this anymore.
Should this be discussed with board or council?
Thanks.
Best,
Goffi
1:57 p.m.
Le 7 juillet 2026 21:16:07 GMT+02:00, Ralph Meijer <ralphm(a)ik.nu> a écrit :
Hi,
It is still not very clear to me what the objective is and how a requirement to disclose
the use of AI achieves it. I see these angles:
1. AI may generate output that is of low quality (incomplete, vague, false, superfluous).
2. AI may generate output that includes parts of other works without attribution and/or
permission (from a rights perspective).
I do not see why these problems uniquely exist because of the use of AI, and why this
isn't covered by an author's existing responsibility to ensure quality and the
pre-conditions for assigning ownership rights to the XSF per its IPR policy (in particular
sections 3.1 and 3.2).
If you cannot formulate the requirements for quality for humans, then how does declaring
use of AI make things better? And if you can, and a submission complies, how does it
matter that AI was used in the process? How would you handle “AI-tainted” submissions
differently?
The same holds for potential rights issues. The author is still responsible.
My concern is that all future submissions will just have this disclosure as boilerplate,
and a recipient cannot assess how deep the impact of the use of AI is. With the
accelerating growth we see in both the capabilities and the use of AI, this becomes
increasingly hard. We will not have gained anything substantial. In that regard it reminds
me of the Evil Bit (RFC 3514) / Malicious Stanzas (XEP-0076).
The statement you linked to seems like common sense and doesn't actually require
disclosure. Consider this document again, but conceptually replace “the use of AI” with
the “use of a keyboard”. Does having such a statement change the outcome of our standards
process?
I think that our author guidelines (XEP-0143) are already clear, and sense all the above
boils down to this:
“Authors must understand, verify, and take responsibility for every contribution they
submit.” (-- ChatGPT with my prompting)
While noting that this stance is not universally accepted (e.g. see
<https://jme.bmj.com/content/51/4/230>), I think it is suitable for our standards
process. Feel free to use this phrase in a concrete proposal, like a PR to XEP-0143.
Cheers,
ralphm
Disclosure: this message was manually (glide) typed on a OnePlus 12, using Google Board,
in Thunderbird for Android. Conversing with AI may have influenced my thought process.
Except where explicitly noted, no excerpts of other works were included in this message.
On 7 July 2026 17:55:54 CEST, Goffi <goffi(a)goffi.org> wrote:
>Hi,
>
>This discussion is stalling.
>
>Meanwhile, we've got specification(s?) which have been clearly written with AI,
>and I guess it will be more and more often the case.
>
>As a reviewer with my council hat, I would really love to at least have
>disclaimer when AI is used (is it for writing whole sections, to extract a
>table, to write example, to check spelling/grammar).
>
>Many big projects have a statement on AI use, e.g., CPython:
>https://devguide.python.org/getting-started/ai-tools/
>
>I think XSF should have one too.
>
>Do we need more discussion on standard, or should the board discuss that and
>ask a team to work on a AI statement?
>
>Thanks
>Goffi
>
>
>Le lundi 11 mai 2026, 09:50:19 heure d’été d’Europe centrale Goffi a écrit :
>> Hello everybody,
>>
>> I would like to bring a discussion on AI policy. We can't really ignore
>> anymore that modern models have become very capable, and I suspect that they
>> are used for spec authoring.
>>
>> This raises, I believe, copyright issues: if someone use AI to redact a
>whole
>> section of a spec, how can we be sure that it's not an existing specs for
>some
>> other place, possibly under copyright, that is copied or paraphrased? How
>can
>> an author guarantee that it's original work (hint: they can't)?
>>
>> I think that there are 3 distinct uses:
>>
>> 1. As a light formatting/checking help, for instance to generate a table
>from
>> a human written section, to correct the formulation of a sentence, or to
>draft
>> an example. This is notably useful for non native English speakers.
>>
>> 2. As a help to search existing state of art on some feature, or any kind of
>> data, without writing anything in a protoXEP.
>>
>> 3. As a way to generate whole sections.
>>
>> Instinctively, and If we put aside ethical and ecological concerns about
>LLMs,
>> I think that 1. and 2. are OK, and 3. should be forbidden. And in all cases,
>> it should be disclosed.
>>
>> I would like your feedback on this matter, in particular people with legal
>> knowledge.
>>
>> I would like to avoid a flamewar, I know that this topic is sensitive and
>there
>> opinions are highly divided, please express your opinion calmly. The fact
>is,
>> we can't ignore this anymore.
>>
>> Should this be discussed with board or council?
>>
>> Thanks.
>>
>> Best,
>> Goffi
>
Hi Ralph,
As someone who mostly reads XEPs and does not have a specific XSF hat, one of the missing
angles that matters to me as part of the standard process (as opposed to what matters to
me in general, like the absolute awfulness of everything related to "AI" in all
possible dimensions of our shared realm), is that I would rather not read slop, and I am
probably not alone in that group.
If it is not disclosed and I find myself looking at some LLM-isms in a document supposed
to be thoughtfully crafted to describe a common protocol to achieve a worthy goal, it will
certainly make me pause and reconsider implementing the specification. If that becomes
commonplace, as it usually happens when there is no specific policy about these tools and
assume nothing changes in the distribution of responsibility, then in time I will probably
have to reconsider my involvement with this standards body.
Mathieu
3:48 p.m.
On 7 July 2026 21:57:08 CEST, Mathieu Pasquet <mathieui(a)mathieui.net> wrote:
[..]
Hi Ralph,
As someone who mostly reads XEPs and does not have a specific XSF hat, one of the missing
angles that matters to me as part of the standard process (as opposed to what matters to
me in general, like the absolute awfulness of everything related to "AI" in all
possible dimensions of our shared realm), is that I would rather not read slop, and I am
probably not alone in that group.
While acknowledging your apparent complete rejection of (the use of) AI technology, how is
this angle different from my stated first angle about the quality of the output?
I dislike reading badly written texts of any kind, and have seen plenty. We can hardly
control what comes into the Editors inbox. What happens after is up to the XMPP Council
and Standards-JIG (here).
If it is not disclosed and I find myself looking at
some LLM-isms in a document supposed to be thoughtfully crafted to describe a common
protocol to achieve a worthy goal, it will certainly make me pause and reconsider
implementing the specification.
That is fair. But depending on where in the process you step in, if our standards process
works as it should, this should have been caught before you get to this point.
If that becomes commonplace, as it usually happens when
there is no specific policy about these tools
That's quite a statement. How do you come to this assumption? Did you see this
happening elsewhere in standards organisations? Here?
and assume nothing changes in the distribution of
responsibility,
This is not an assumption, it is a given. So far I've seen no suggestion or
expectation that we would need to accept AI as the sole author (without a human involved
in the submission process).
then in time I will probably have to reconsider my
involvement with this standards body.
Ok.
But again, I do not understand why you are making a distinction between a contribution by
a human, and a contribution by a human that uses AI. In either case I expect a certain
level of quality and if the output is "slop", then the human driving the AI
tools is to blame. Or their own bad writing.
What is your concrete proposal that also addresses my concern?
ralphm
4 p.m.
On 7 Jul 2026, at 22:48, Ralph Meijer <ralphm(a)ik.nu> wrote:
But again, I do not understand why you are making a distinction between a contribution by
a human, and a contribution by a human that uses AI. In either case I expect a certain
level of quality and if the output is "slop", then the human driving the AI
tools is to blame. Or their own bad writing.
While everything you say is true at face value, I think a number of people have seen an
increase in low-effort low-quality high-magnitude contributions elsewhere because of the
use of agents allowing producing significantly sized bodies of work that take a great deal
of effort to review or repute, while having cost the person triggering the submission
little to no effort. Daniel has made the (I think reasonable) point that he’s unlikely to
be able to keep on as Editor if that role becomes having to process an increasing number
of low-quality but not low-effort-to-deal-with submissions, and I think the onward effort
of Council would also be prohibitive if such a situation were to arise. It’s a matter of
opinion whether we’ll see that happen in the XSF, but I am confident similar things are
happening elsewhere. We do, as you say, have a process that should prohibit unsuitable
XEPs being published, but the effort required to drive that process may well increase -
you would be right to assert that people could submit all the same things an agent could,
by hand-crafting them, and the quality could be similarly low, but the barrier of effort
to do that is much higher and we’ve not traditionally seen an issue with it (I also
suspect that use of agents leads to an inflated confidence in the submitted content, but
that’s just speculation) - and reading the GSoC mentor list this year has been
particularly depressing with the tales of what it’s been like for everyone. Even within
the XSF I have already watched some PRs go by that have been clearly (to me) agent-driven,
and have felt draining to read.
I do not have answers, I am not inherently anti-AI, and I do not believe that forbidding
use of agents would be the best course, but I can also see how concerns in this area could
be very reasonable, and that a desire to ‘do something’ following from that would also be
reasonable
/K
5:11 p.m.
On 8 July 2026 00:00:38 CEST, Kevin Smith via Standards <standards(a)xmpp.org> wrote:
On 7 Jul 2026, at 22:48, Ralph Meijer
<ralphm(a)ik.nu> wrote:
Yes, this is a problem. Not even hypothetically.
Can we formulate criteria that make it easier to triage? If something is "clearly
agent-driven", I am fine with a quick "nope, try again" without reading the
whole thing. But can we be more specific, objective?
Does declaring the use of AI disqualify?
How much or what type of use of AI?
What if all future contributions, including subjectively great ones, declare so?
Also, how does one prove _not_ having used AI?
But again, I do not understand why you are making a distinction between a contribution by
a human, and a contribution by a human that uses AI. In either case I expect a certain
level of quality and if the output is "slop", then the human driving the AI
tools is to blame. Or their own bad writing.
While everything you say is true at face value, I think a number of people have seen an
increase in low-effort low-quality high-magnitude contributions elsewhere because of the
use of agents allowing producing significantly sized bodies of work that take a great deal
of effort to review or repute, while having cost the person triggering the submission
little to no effort. Daniel has made the (I think reasonable) point that he’s unlikely to
be able to keep on as Editor if that role becomes having to process an increasing number
of low-quality but not low-effort-to-deal-with submissions, and I think the onward effort
of Council would also be prohibitive if such a situation were to arise. It’s a matter of
opinion whether we’ll see that happen in the XSF, but I am confident similar things are
happening elsewhere. We do, as you say, have a process that should prohibit unsuitable
XEPs being published, but the effort required to drive that process may well increase -
you would be right to assert that people could submit all the same things an agent could,
by hand-crafting them, and the quality could be similarly low, but the barrier of effort
to do that is much higher and we’ve not traditionally seen an issue with it (I also
suspect that use of agents leads to an inflated confidence in the submitted content, but
that’s just speculation) - and reading the GSoC mentor list this year has been
particularly depressing with the tales of what it’s been like for everyone. Even within
the XSF I have already watched some PRs go by that have been clearly (to me) agent-driven,
and have felt draining to read. I do not have answers, I am not inherently anti-AI, and
I do not believe that forbidding use of agents would be the best course, but I can also
see how concerns in this area could be very reasonable, and that a desire to ‘do
something’ following from that would also be reasonable
I am actually quite skeptical about AI, its limitations as well as its promise. In
particular I am wary about how people use it, and how they trust the outcome. I also
understand there's an inherent need to deal with a new reality.
However, "doing something" has to be meaningful. I don't think we can ban
the use of AI in practice. I suspect that proper use of AI becomes harder and harder to
distinguish from traditionally written contributions.
If we do continue to allow it, what is the effect of declaring the use of AI on our
processes? Should it cause a different treatment of the contribution? How?
I think we need to put this squarely on the author. Only submit stuff you have properly
proofread. You cannot hide behind AI. It is your work. Don't put in patent-encumbered
work, don't copy stuff unless allowed, don't send in slop. If that requires some
additional words in our author guidelines, please suggest some (or use the ones in my
other mail).
ralphm
5:49 p.m.
On Wed, 8 Jul 2026 at 00:11, Ralph Meijer <ralphm(a)ik.nu> wrote:
If we do continue to allow it, what is the effect of
declaring the use of AI on our processes? Should it cause a different treatment of the
contribution? How?
Low-quality contributions are not new. What's changed is that they no
longer look like low-quality contributions. Identifying slop takes an
unfair amount of cognitive effort compared to the effort required to
generate and submit it.
Knowing that a XEP submission came in part or even wholly from LLM
output changes the way I review a document. LLMs are extremely good at
generating sensible-looking documents. If a sensible-looking document
comes from an experienced community member, I am likely to spend 80%
of my time assessing the higher level aspects of their submission - I
am not likely to cross-reference every namespace or referenced
document to see if they hallucinated it or not. One can certainly
argue that we should give every document a complete thorough review
right out of the gate, checking and cross-referencing everything, but
that's more effort than many of us can commit to and has never been
the case really. LLM documents tend to be longer, and this makes such
work even harder.
My request is not that we "ban AI", for now at least. Almost nobody
has called for that in this thread (surely far fewer than are worried
about its impact). In any case, I don't think we could pull that off -
"AI" is too broad, and these days is integrated into so many tools
right down to simple spelling/grammar checkers.
Instead, I am suggesting for many reasons already presented in this
thread, that we simply ask people to declare whether and how they used
AI in their contributions. If a submission says "this is entirely my
own work, but I used an LLM to review it" and another submission says
"this is output directly from an LLM, I've put no effort into checking
any of its contents" then I'm obviously going to treat those documents
very differently as a reviewer.
If nothing else, it will allow us to get an idea of how AI tools are
being used in our community. And things *could* be fine... if in 12
months we look back and see a bunch of in-progress documents with AI
use declared, but the documents are actually in great shape, then
we'll at least know we were worrying about nothing when it comes to
XEP quality. But if we consistently see that the documents authored
using AI are below our usual standards, then we can have further
discussions in the future about what kind/amount of AI usage is
appropriate in contributions. But right now, we're largely in the
dark, and that's scary. It leads to people jumping up and down every
time they see an emdash.
Regards,
Matthew
8 Jul
8 Jul
1:45 a.m.
To make a general point, I'm not "against" AI in principle, and don't
consider myself the kind or "AI tech bro" type either. It is a tool, and
like many tools can be misused, and needs careful wielding. I've had much
success with it as a tool, and also some mis-steps.
Would I be happy with a specification that was originally written in, say,
Chinese and then blindly Google-translated into English? Probably not.
Would I be happy with a specification written by a Chinese speaker who used
Google Translate to help express themselves? Sure. Would I want either
declared? Nope, because the risk of tainting the perfectly sensible use of
the second would risk alienating otherwise good submissions.
As usual, I'd note that I don't write my XEPs using LLMs, because I happen
to enjoy writing them and was lucky enough to be born British, so get to
write English like what it's meant to be. But I also like languages, and so
I'm somewhat aware of how hard it must be to write precise technical
specifications in a foreign language. My "best" language other than English
is probably French, and there is absolutely no way I could write technical
French of that quality - I can barely read it - and if I had to do so for
some reason I'd absolutely be leaning heavily on tooling like LLMs. It'd be
painful to have that work tossed out or sneered at simply because of that.
Indeed, I'd suggest there may be an argument that it's not in line with the
Code of Conduct, as it's hardly welcoming to those who - for no fault of
their own - are not fluent English writers.
On Wed, 8 Jul 2026 at 00:49, Matthew Wild <mwild1(a)gmail.com> wrote:
Low-quality contributions are not new. What's
changed is that they no
longer look like low-quality contributions. Identifying slop takes an
unfair amount of cognitive effort compared to the effort required to
generate and submit it.
I don't think this is quite the right take.
I also don't think we have an active problem, yet, in the XSF.
But I do think it's entirely likely we'll run into an increase in the kind
of submissions which are easy-to-produce AI slop. The IETF has certainly
seen this, though in the interesting manner that much of the AI-generated
Internet Drafts there are (anecdotally) entire suites of drafts, like
"IPv8".
On the other hand, LLMs can also be used effectively to write
specifications, I'm sure. As an example, I suspect (without, yet, trying)
that generating comprehensive examples from the text I've written ought to
be possible (and if not, would be illuminating as to what is missing from
the text). Certainly I've seen LLM reviews of specifications and been
impressed at what nits (and serious issues) they spot.
Great tools, and thus can be abused greatly.
I firmly believe we should ensure we handle the abuse, not the use.
Knowing that a XEP submission came in part or even
wholly from LLM
output changes the way I review a document.
This, you see, is an example of my point at the beginning.
LLMs are extremely good at
generating sensible-looking documents. If a sensible-looking document
comes from an experienced community member, I am likely to spend 80%
of my time assessing the higher level aspects of their submission - I
am not likely to cross-reference every namespace or referenced
document to see if they hallucinated it or not. One can certainly
argue that we should give every document a complete thorough review
right out of the gate, checking and cross-referencing everything, but
that's more effort than many of us can commit to and has never been
the case really. LLM documents tend to be longer, and this makes such
work even harder.
"We" - for some value of we - absolutely should give every document a
thorough review of this form at some point prior to at least Stable. Right?
I suspect part of your stance here is the way that Experimental has shifted
in nature from being "rough draft" to "almost ready", and thus
shifting
that review back to the submission point, which means any influx of "AI
slop" causes a huge amount of workload for Editor and Council alike.
Putting aside philosophical argument against LLMs on principle for the
moment, this feels like the pragmatic problem, this feels like the actual
problem that needs addressing. We need to ensure that if - or more likely
when - we get an influx of AI slop our process can handle it without
driving "us" (again, for some values of "us") to exhaustion.
I would quite like to fix this rather large gap between what we document as
our process and what we actually appear to do, anyway.
Instead, I am suggesting for many reasons already presented in this
thread, that we simply ask people to declare whether
and how they used
AI in their contributions. If a submission says "this is entirely my
own work, but I used an LLM to review it" and another submission says
"this is output directly from an LLM, I've put no effort into checking
any of its contents" then I'm obviously going to treat those documents
very differently as a reviewer.
I refer you to Ralph's XEP-0076 comment.
The fact is that many people will be entirely unaware of LLM involvement in
their spec writing (grammar checkers are a great example you've noted - I
have no idea if Google Translate uses LLMs now), but others will ignore
this and submit a suite of 60 page XEPs generated by some LLM without any
understanding of utility.
We'll catch both, post-facto. We will penalize both, as per policy. The
damage has already been done by the abuser, and will mostly affect the
innocent user.
If nothing else, it will allow us to get an idea of
how AI tools are
being used in our community. And things *could* be fine... if in 12
months we look back and see a bunch of in-progress documents with AI
use declared, but the documents are actually in great shape, then
we'll at least know we were worrying about nothing when it comes to
XEP quality. But if we consistently see that the documents authored
using AI are below our usual standards, then we can have further
discussions in the future about what kind/amount of AI usage is
appropriate in contributions. But right now, we're largely in the
dark, and that's scary. It leads to people jumping up and down every
time they see an emdash.
I think focusing on declaring what tools have been used risks a different
kind of witch hunt.
I think we risk policing use, but tacitly allowing abuse.
Dave.
--
(This email was grammar checked automatically, though I didn't accept any
suggestions. I have absolutely no idea, as previously stated, whether this
involved the use of LLMs, so I asked an LLM, and therefore I've definitely
used an LLM in the generation of this email, irrespective of the answer.
Dagnabbit.)
1:52 a.m.
Hi,
Le mardi 7 juillet 2026, 21:16:07 heure d’été d’Europe centrale Ralph Meijer a écrit :
[SNIP]
I do not see why these problems uniquely exist because of the use of AI, and why this
isn't covered by an author's existing responsibility to ensure quality and the
pre-conditions for assigning ownership rights to the XSF per its IPR policy (in particular
sections 3.1 and 3.2).
The scale and effort required is not the same with AI.
If you cannot formulate the requirements for quality
for humans, then how does declaring use of AI make things better? And if you can, and a
submission complies, how does it matter that AI was used in the process? How would you
handle “AI-tainted” submissions differently?
I would read it differently. If I know that a whole section is AI written, I know that the
text and references can be hallucinated, and that there can be more boilerplate text than
a human would do.
If AI is used to extract table or make examples, I'll probably check quickly for
hallucinated values.
If AI is used for slight reformulation and spelling/grammar, I'll probably read it no
differently as I read pure human submission.
If a request is slop (low effort fully generated AI), I'll probably not bother and
reject it.
In any case, I would appreciate and consider polite to be informed if I'm reading a
human or machine generated content.
The same holds for potential rights issues. The author
is still responsible.
My concern is that all future submissions will just have this disclosure as boilerplate,
and a recipient cannot assess how deep the impact of the use of AI is. With the
accelerating growth we see in both the capabilities and the use of AI, this becomes
increasingly hard. We will not have gained anything substantial. In that regard it reminds
me of the Evil Bit (RFC 3514) / Malicious Stanzas (XEP-0076).
This is not what I'm seeing in other projects. Even the local inference engine
"llama.cpp", which we can hardly accuse to be "anti-AI", ask for that,
you can check PRs there: https://github.com/ggml-org/llama.cpp/pulls
The statement you linked to seems like common sense and doesn't actually require
disclosure. Consider this document again, but conceptually replace “the use of AI” with
the “use of a keyboard”. Does having such a statement change the outcome of our standards
process?
This is a very poor comparison. It's like saying "I don't see why we need a
driving license, I don't need one to walk". The scale is not the same, with LLM
you can generate easily tons of text looking on the surface more or less OK.
I think that our author guidelines (XEP-0143) are
already clear, and sense all the above boils down to this:
“Authors must understand, verify, and take responsibility for every contribution they
submit.” (-- ChatGPT with my prompting)
While noting that this stance is not universally accepted (e.g. see
<https://jme.bmj.com/content/51/4/230>), I think it is suitable for our standards
process. Feel free to use this phrase in a concrete proposal, like a PR to XEP-0143.
To clarify my (current) position: I'm not asking for an AI ban, it could not be
enforceable and AI is a great tool for accessibility and many other things. But I'm
advocating for requesting a disclosure (maybe not mandatory, but strongly suggested).
Explain that we have human reviewers behind, and that we'll reject AI slops
specifications. Use of AI need to be fully checked, and text should be reduced to
essential. The later is one of the main painful point with content generated by or with
AI: it's longer than necessary, and that make it harder to review.
We could start to have this as a template/popup when doing a pull-request.
Disclosure: this message was manually (glide) typed on
a OnePlus 12, using Google Board, in Thunderbird for Android. Conversing with AI may have
influenced my thought process. Except where explicitly noted, no excerpts of other works
were included in this message.
No need to be sarcastic here, this is a problem seen across the whole industry, it seems
legitimate to me to state our position, like many other organisations are doing.
Best,
Goffi
2:57 a.m.
On Wed, 8 Jul 2026 at 08:52, Goffi <goffi(a)goffi.org> wrote:
The odd thing is, producing a lot of content has always been easier than
producing tight, well-considered, content.
“If it is a ten‑minute speech, it takes me all of two weeks to prepare it.
If it is a half‑hour speech, it takes me a week. If I can talk as long as I
want to, it requires no preparation at all.” -- Woodrow Wilson
Also Mark Twain, and Blaise Pascal's “I have made this letter longer than
usual because I lack the time to make it shorter.” from 1657.
The problem with AI slop isn't that an AI wrote it per-se, but that AI
makes it much easier to write slop than before. But slop was always easier
to write - and harder to read - than quality submissions.
I may find myself repeating this, but really, it's a matter of scale.
Again, this seems like a problem of scale more than anything else.
... scale ...?
Again, to echo previous messages, let's fix the process such that the
review by five (and hopefully more) busy people doesn't happen right at the
entrypoint of the standards pipeline. This has always been something of a
waste of valuable resources, and this is compounding fast. If this gate
happens later, based on factors like visible interest in the community,
then the very real detrimental effect of AI slop is considerably lessened.
Hi,
Le mardi 7 juillet 2026, 21:16:07 heure d’été d’Europe centrale Ralph
Meijer a écrit :
Right - this is a potential problem of scale.
[SNIP]
I do not see why these problems uniquely exist because of the use of AI,
and why
this isn't covered by an author's existing responsibility to ensure
quality and the pre-conditions for assigning ownership rights to the XSF
per its IPR policy (in particular sections 3.1 and 3.2).
The scale and effort required is not the same with AI.
If you cannot
formulate the requirements for quality for humans, then
how does declaring use of
AI make things better? And if you can, and a
submission complies, how does it matter that AI was used in the process?
How would you handle “AI-tainted” submissions differently?
I would read it differently. If I know that a whole section is AI written,
I know that the text and references can be hallucinated, and that there can
be more boilerplate text than a human would do.
If AI is used to extract table or make examples, I'll probably check
quickly for hallucinated values.
If AI is used for slight reformulation and spelling/grammar, I'll probably
read it no differently as I read pure human submission.
If a request is slop (low effort fully generated AI), I'll probably not
bother and reject it.
In any case, I would appreciate and consider polite to
be informed if I'm
reading a human or machine generated content.
I can't find one that says AI wasn't used, and nor can I find any that say
AI output wasn't reviewed (carefully!) afterward. Going through them is
quite painful, I might have missed one, but I went through the first ten or
so which seemed representative.
Which is about what I'd expect - who's going to declare they used AI and
also declare they didn't check anything about the output? (I mean, I do
this in throwaway code, but in a spec submission?) Equally, if someone
AI-slop-generates a 60 page XEP that look vaguely pausible enough to suck
you in, are they going to declare this accurately?
Technically speaking, this isn't so much an Evil Bit as a Good Bit that
everyone will set.
Charitably, we could say this is keeping honest people honest, but it might
be more accurate to say it's simply performative.
And this is all unfortunate because I entirely understand your concerns,
and firmly believe these are real problems that we should protect Editor
and Council from, but I don't think a declaration is an effective way of
doing this.
The same holds for potential rights issues. The
author is still
responsible.
My concern is that all future submissions will just have this disclosure
as
boilerplate, and a recipient cannot assess how deep the impact of the
use of AI is. With the accelerating growth we see in both the capabilities
and the use of AI, this becomes increasingly hard. We will not have gained
anything substantial. In that regard it reminds me of the Evil Bit (RFC
3514) / Malicious Stanzas (XEP-0076).
This is not what I'm seeing in other projects. Even the local inference
engine "llama.cpp", which we can hardly accuse to be "anti-AI", ask
for
that, you can check PRs there: https://github.com/ggml-org/llama.cpp/pulls
The statement you linked to seems like common sense and doesn't actually
require disclosure. Consider this document again, but conceptually replace
“the use of AI” with the “use of a keyboard”. Does having such a statement
change the outcome of our standards process?
This is a very poor comparison. It's like saying "I don't see why we need
a driving license, I don't need one to walk". The scale is not the same,
with LLM you can generate easily tons of text looking on the surface more
or less OK.
I think that
our author guidelines (XEP-0143) are already clear, and
sense all the above boils
down to this:
“Authors must understand, verify, and take responsibility for every
contribution they submit.” (-- ChatGPT with my prompting)
While noting that this stance is not universally accepted (e.g. see <
https://jme.bmj.com/content/51/4/230>)t;), I think it is suitable for our
standards process. Feel free to use this phrase in a concrete proposal,
like a PR to XEP-0143.
To clarify my (current) position: I'm not asking for an AI ban, it could
not be enforceable and AI is a great tool for accessibility and many other
things. But I'm advocating for requesting a disclosure (maybe not
mandatory, but strongly suggested). Explain that we have human reviewers
behind, and that we'll reject AI slops specifications. Use of AI need to be
fully checked, and text should be reduced to essential. The later is one of
the main painful point with content generated by or with AI: it's longer
than necessary, and that make it harder to review.
We could start to have this as a template/popup when
doing a pull-request.
That's not sarcasm, actually, it's a reductio ad absurdum argument, though
the two look similar. Below is an example of a parody argument (again,
similar to both). Both are examples of the legitimate form of
slippery-slope arguments (or over-literalism, if you prefer). In other
words, you might or might not find it funny, but it is (aimed at) making a
valid point.
Dave.
--
This email was generated by a human, and therefore may contain mistakes.
Disclosure: this message was manually (glide)
typed on a OnePlus 12,
using Google Board, in Thunderbird for Android. Conversing
with AI may have
influenced my thought process. Except where explicitly noted, no excerpts
of other works were included in this message.
No need to be sarcastic here, this is a problem seen across the whole
industry, it seems legitimate to me to state our position, like many other
organisations are doing.
3:04 a.m.
Hi all,
Some thoughts, having read the thread through again.
On disclosure: I understand the appeal. Mattj puts the strongest version of
the case: that we're currently in the dark about how these tools are being
used in our community. My hesitation is with making it a requirement. A
requirement will mostly be honoured by people who aren't producing the
submissions we broadly agree we want to stop, while the people producing
those are unlikely to honour it. Without assignable consequences it doesn't
bite, and my worry is that it mainly burdens contributors who are making
perfectly good use of these tools. Goffi points to llama.cpp and CPython. I
don't know enough about how those requirements work in practice to say
whether they transfer here. Both, I suppose, are handling code
contributions with automated test suites behind them, which is maybe a
rather different review problem to ours?
One thing I think we should do regardless: Ralph proposed a sentence for
XEP-0143, that authors must understand, verify, and take responsibility for
every contribution they submit. That seems worth having written down
whatever else we decide, so I've opened a PR for it:
https://github.com/xsf/xeps/pull/1552. It is deliberately not AI-specific,
and is not intended to settle anything else in this thread.
Which brings me to what I think is the actual problem. One of the XSF's
most valuable assets is the volunteering force that helps us achieve our
goals. We have not historically done a great job at preventing burnout
among those volunteers, and we need to do better. If we do start receiving
large volumes of AI-generated slop (and I don't think that has happened
yet, but we would be wise to prepare) it carries a significant risk of
adding to those burdens. Kev's point about the Editor role, and about the
effort asymmetry between generating and reviewing a submission, seems to me
the concrete harm we should be organising around. Not copyright, and not
disclosure for its own sake.
So rather than "disclose AI", I'd like us to think about what we actually
need in order to identify and handle low-quality submissions at volume,
whatever produced them, AI or humans. Two things I think we need in order
to have that conversation properly:
First, prior art. Goffi, you're the one with the most energy on this and
you're seeing it from the Council side. Would you be willing to take this
on? Kev hinted at the GSoC mentor discussions this year, and the IETF has
apparently seen entire suites of AI-generated Internet Drafts. Other
organisations are dealing with this right now, and I'd like to know what
they've tried and how it worked out before we invent our own approach. It's
well-bounded work, and if it comes back showing that disclosure
requirements are doing real work elsewhere, that's an argument I'd want to
hear and one that would carry weight with Board.
Second, procedure. If we identify a submission as slop, what happens? I
think we need to guard in two directions at once: against volunteers having
to process slop, and against submitters being rejected bluntly ("computer
says no").
MSavoritias made a point earlier: consensus is unlikely to arrive on its
own if we simply keep talking. I said in May that I preferred to see
concrete, actionable proposals before this went to Board, and I still think
that's right, but I'm aware that's easy to say and harder to act on, and
I've not done much acting on it myself.
To answer the question Goffi has now put twice: I don't think we're ready
for Board yet, and I want to be honest that this is the second time I've
said so. What I think would change that is a concrete proposal with the
prior art behind it. That's not far off (and the PR above already is a
small piece of it).
Kind regards,
Guus
On Wed, Jul 8, 2026 at 9:52 AM Goffi <goffi(a)goffi.org> wrote:
Hi,
Le mardi 7 juillet 2026, 21:16:07 heure d’été d’Europe centrale Ralph
Meijer a écrit :
[SNIP]
I do not see why these problems uniquely exist because of the use of AI,
and why
this isn't covered by an author's existing responsibility to ensure
quality and the pre-conditions for assigning ownership rights to the XSF
per its IPR policy (in particular sections 3.1 and 3.2).
The scale and effort required is not the same with AI.
If you cannot formulate the requirements for
quality for humans, then
how does declaring use of AI make things better? And if
you can, and a
submission complies, how does it matter that AI was used in the process?
How would you handle “AI-tainted” submissions differently?
I would read it differently. If I know that a whole section is AI written,
I know that the text and references can be hallucinated, and that there can
be more boilerplate text than a human would do.
If AI is used to extract table or make examples, I'll probably check
quickly for hallucinated values.
If AI is used for slight reformulation and spelling/grammar, I'll probably
read it no differently as I read pure human submission.
If a request is slop (low effort fully generated AI), I'll probably not
bother and reject it.
In any case, I would appreciate and consider polite to be informed if I'm
reading a human or machine generated content.
The same holds for potential rights issues. The
author is still
responsible.
My concern is that all future submissions will just have this disclosure
as
boilerplate, and a recipient cannot assess how deep the impact of the
use of AI is. With the accelerating growth we see in both the capabilities
and the use of AI, this becomes increasingly hard. We will not have gained
anything substantial. In that regard it reminds me of the Evil Bit (RFC
3514) / Malicious Stanzas (XEP-0076).
This is not what I'm seeing in other projects. Even the local inference
engine "llama.cpp", which we can hardly accuse to be "anti-AI", ask
for
that, you can check PRs there: https://github.com/ggml-org/llama.cpp/pulls
The statement you linked to seems like common sense and doesn't actually
require disclosure. Consider this document again, but conceptually replace
“the use of AI” with the “use of a keyboard”. Does having such a statement
change the outcome of our standards process?
This is a very poor comparison. It's like saying "I don't see why we need
a driving license, I don't need one to walk". The scale is not the same,
with LLM you can generate easily tons of text looking on the surface more
or less OK.
I think that our author guidelines (XEP-0143) are
already clear, and
sense all the above boils down to this:
“Authors must understand, verify, and take responsibility for every
contribution they submit.” (-- ChatGPT with my prompting)
While noting that this stance is not universally accepted (e.g. see <
https://jme.bmj.com/content/51/4/230>)t;), I think it is suitable for our
standards process. Feel free to use this phrase in a concrete proposal,
like a PR to XEP-0143.
To clarify my (current) position: I'm not asking for an AI ban, it could
not be enforceable and AI is a great tool for accessibility and many other
things. But I'm advocating for requesting a disclosure (maybe not
mandatory, but strongly suggested). Explain that we have human reviewers
behind, and that we'll reject AI slops specifications. Use of AI need to be
fully checked, and text should be reduced to essential. The later is one of
the main painful point with content generated by or with AI: it's longer
than necessary, and that make it harder to review.
We could start to have this as a template/popup when doing a pull-request.
Disclosure: this message was manually (glide)
typed on a OnePlus 12,
using Google Board, in Thunderbird for Android. Conversing
with AI may have
influenced my thought process. Except where explicitly noted, no excerpts
of other works were included in this message.
No need to be sarcastic here, this is a problem seen across the whole
industry, it seems legitimate to me to state our position, like many other
organisations are doing.
Best,
Goffi_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
4:26 a.m.
Hi Guus,
Le mercredi 8 juillet 2026, 11:04:45 heure d’été d’Europe centrale Guus der
Kinderen a écrit :
First, prior art. Goffi, you're the one with the
most energy on this and
you're seeing it from the Council side. Would you be willing to take this
on?
No I'm not. I'm already at the edge of burn-out and can't cope with anything
more.
Our editor/council chair said twice that he won't continue if we start to see
too much AI slops in our inbox, and we do start to see submission made with AI
(I don't qualify them as "slop" at all for the moment, but I already feel
the
AI impact).
We regularly see FOSS projects and other organisations complaining about the
wave a slop PRs.
I think that this is a potential problem, and it's better to anticipate ( I
think the English proverb is "better safe than sorry", but for this one I
like more the French "Mieux vaut prévenir que guérir").
If nobody else see an issue there, so just let it be. I have neither the time
nor the energy to fight in endless debates for a simple suggestion to disclose
AI use.
Best,
Goffi
4:45 a.m.
Hi Goffi,
I'm sorry, I shouldn't have assumed. I'll do the survey myself.
Please do step back from this if you're near burn-out. It isn't that nobody
sees an issue. Others have said the concern is real, and so have I. We're
disagreeing about the mechanism. That argument can go on without you
carrying it.
Also: you've seen AI-assisted submissions and you're explicitly not calling
them slop. That's useful, and it suggests we have some time.
Kind regards,
Guus
On Wed, Jul 8, 2026 at 12:27 PM Goffi <goffi(a)goffi.org> wrote:
Hi Guus,
Le mercredi 8 juillet 2026, 11:04:45 heure d’été d’Europe centrale Guus
der
Kinderen a écrit :
First, prior art. Goffi, you're the one with
the most energy on this and
you're seeing it from the Council side. Would you be willing to take this
on?
No I'm not. I'm already at the edge of burn-out and can't cope with
anything
more.
Our editor/council chair said twice that he won't continue if we start to
see
too much AI slops in our inbox, and we do start to see submission made
with AI
(I don't qualify them as "slop" at all for the moment, but I already feel
the
AI impact).
We regularly see FOSS projects and other organisations complaining about
the
wave a slop PRs.
I think that this is a potential problem, and it's better to anticipate (
I
think the English proverb is "better safe than sorry", but for this one I
like more the French "Mieux vaut prévenir que guérir").
If nobody else see an issue there, so just let it be. I have neither the
time
nor the energy to fight in endless debates for a simple suggestion to
disclose
AI use.
Best,
Goffi_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
3:13 a.m.
On 08/07/2026 09.52, Goffi wrote:
What criteria do you use to make these
judgements. Why is there an
assumption that if a human created it, you do not have to be as thorough?
I agree that allowing submissions by PR makes it easier for agents and
people to submit them and that may contribute to increased volume. I
also think that code is different from protocol specifications. But as I
mentioned above, if you cannot triage quickly, this requires changes to how
heavy your triage process is. I do not see how an optional declaration
makes any of this better.
I love car analogies. No, my suggestion is more like you asking how I
got to the XMPP Summit, and you valuing me differently when I came by
car. Besides your personal preferences, this should not have any bearing
on my contributions in that venue. And I will certainly not show you my
drivers license or discuss its impact on the environment _in that context_.
As I
wrote earlier, if you can provide concrete changes to, say,
XEP-0143, I would be happy to judge them on face value. I am fine with
stronger indication of the responsibilities we require of authors (like
my proposed text). Preferably, you still need to define how you "reject
AI slops" using objective criteria. If "gut feeling" is the process,
then you can already do this.
FWIW, the paper I referenced is an in-depth discussion on the
responsibilities of human authors on scientific papers, which should be
an interesting read for anyone that wants to seriously discuss this
topic. There are rebuttals to it, too, but unfortunately they are not as
open-access as this CC-licensed paper.
This was not meant as a sarcastic jab at all. It was meant as a concrete
example of how hard it is to usefully declare the use of AI. I
specifically mentioned Google Board and glide typing, because it uses
machine learning and AI for writing each word based on how you glide. It
has auto-correction, spell checks, etc. I didn't run the whole text
through an LLM myself to correct my writing, though, and so there should
be no hallucinations (other than my own) or unsupported citations.
If you want to have optional declarations of the use of AI, then you
also need to specify what that declaration could look like. If it is
free-form, then you will get things like my example.
ralphm
Hi,
Le mardi 7 juillet 2026, 21:16:07 heure d’été d’Europe centrale Ralph Meijer a écrit :
In creating the contribution, this may be true. Like Dave commented
elsewhere in the thread today, I am not convinced about increased effort
on triaging (initial submission) or review of individual XEPs to move
between states. If you mean the volume of submissions or XEP PRs, then
we need to figure out how to lighten that effort. In the past, for
example, PRs were not the approach to getting a XEP changed. You'd
discuss your suggestions with the author(s) and then they would make
changes. The Editor might be involved, but there is no such requirement
unless (about) to move between states.
I agree with Dave that putting all the scrutiny at the beginning of your
process (unlike before) does not help. Instead, accepting a new
contribution with light review allows the distribution of the load to
the rest of Standards JIG. I.e. people will start reading, commenting,
attempting to implement, etc.
[SNIP]
I do not see why these problems uniquely exist because of the use of AI, and why this
isn't covered by an author's existing responsibility to ensure quality and the
pre-conditions for assigning ownership rights to the XSF per its IPR policy (in particular
sections 3.1 and 3.2).
The scale and effort required is not the same with AI.
If you cannot
formulate the requirements for quality for humans, then how does declaring use of AI make
things better? And if you can, and a submission complies, how does it matter that AI was
used in the process? How would you handle “AI-tainted” submissions differently?
I
would read it differently. If I know that a whole section is AI written, I know that the
text and references can be hallucinated, and that there can be more boilerplate text than
a human would do.
If AI is used to extract table or make examples, I'll probably check quickly for
hallucinated values.
If AI is used for slight reformulation and spelling/grammar, I'll probably read it no
differently as I read pure human submission.
If a request is slop (low effort fully generated AI), I'll probably not bother and
reject it.
In any case, I would appreciate and consider polite to be informed if I'm reading a
human or machine generated content. The same holds
for potential rights issues. The author is still responsible.
My concern is that all future submissions will just have this disclosure as boilerplate,
and a recipient cannot assess how deep the impact of the use of AI is. With the
accelerating growth we see in both the capabilities and the use of AI, this becomes
increasingly hard. We will not have gained anything substantial. In that regard it reminds
me of the Evil Bit (RFC 3514) / Malicious Stanzas (XEP-0076).
This is not what
I'm seeing in other projects. Even the local inference engine "llama.cpp",
which we can hardly accuse to be "anti-AI", ask for that, you can check PRs
there: https://github.com/ggml-org/llama.cpp/pulls The statement
you linked to seems like common sense and doesn't actually require disclosure.
Consider this document again, but conceptually replace “the use of AI” with the “use of a
keyboard”. Does having such a statement change the outcome of our standards process?
This is a very poor comparison. It's like saying "I don't see why we
need a driving license, I don't need one to walk". The scale is not the same,
with LLM you can generate easily tons of text looking on the surface more or less OK.
I think that
our author guidelines (XEP-0143) are already clear, and sense all the above boils down to
this:
“Authors must understand, verify, and take responsibility for every contribution
they submit.” (-- ChatGPT with my prompting)
While noting that this stance is not universally accepted (e.g. see
<https://jme.bmj.com/content/51/4/230>), I think it is suitable for our standards
process. Feel free to use this phrase in a concrete proposal, like a PR to XEP-0143.
To clarify my (current) position: I'm not asking for an AI ban, it could not be
enforceable and AI is a great tool for accessibility and many other things. But I'm
advocating for requesting a disclosure (maybe not mandatory, but strongly suggested).
Explain that we have human reviewers behind, and that we'll reject AI slops
specifications. Use of AI need to be fully checked, and text should be reduced to
essential. The later is one of the main painful point with content generated by or with
AI: it's longer than necessary, and that make it harder to review.
We could start to have this as a template/popup when doing a pull-request. Disclosure:
this message was manually (glide) typed on a OnePlus 12, using Google Board, in
Thunderbird for Android. Conversing with AI may have influenced my thought process. Except
where explicitly noted, no excerpts of other works were included in this message.
No need to be sarcastic here, this is a problem seen across the whole industry, it seems
legitimate to me to state our position, like many other organisations are doing.
3:45 a.m.
Hi Ralph,
Two things:
First on the review gate: Dave has made the point that it sits too early,
and you've added that XEPs used to be changed by discussing with the author
rather than by PR. Moving that gate later (light review at intake, with the
deeper reading happening as people actually engage with a spec) is a change
we could actually make. It has the property that nothing gets a careful
reading until someone cares enough to give it one, which is exactly the
wrong incentive for anyone submitting in volume. It would help whether or
not that volume materialises. It doesn't require us to agree about AI at
all. Before committing to it, though, I'd want to understand why we moved
in the other direction in the first place. Presumably it served some
purpose.
Second: you've twice invited a PR against XEP-0143 using your phrasing.
I've opened one: https://github.com/xsf/xeps/pull/1552. It's your sentence,
in the submission process rather than the pre-submission advice, since the
latter is explicitly advisory. It's deliberately not AI-specific and it
doesn't settle anything else here. I'd rather it merged on its own merits
than became a proxy for the wider argument.
You asked Goffi why a human-authored document wouldn't need the same
thoroughness. I think that's unfair to him. Reviewers have always read with
priors. You read a new contributor more carefully than a familiar one, and
for a familiar contributor you may give more attention to certain aspects
than to others. Knowing a submission came from an LLM tells you to go and
check the references. That's useful information, if you have it. My
objection isn't that disclosure would tell us nothing, it's that I don't
expect it to be accurate in the cases where it matters most. Those are
separate arguments, and I think they've been getting mixed up.
Kind regards,
Guus
On Wed, Jul 8, 2026 at 11:13 AM Ralph Meijer <ralphm(a)ik.nu> wrote:
On 08/07/2026 09.52, Goffi wrote:
Hi,
Le mardi 7 juillet 2026, 21:16:07 heure d’été d’Europe centrale Ralph
Meijer a
écrit :
> [SNIP]
> I do not see why these problems uniquely exist because of the use of
AI, and
why this isn't covered by an author's existing responsibility to
ensure quality and the pre-conditions for assigning ownership rights to the
XSF per its IPR policy (in particular sections 3.1 and 3.2).
The scale and effort required is not the same
with AI.
In creating the contribution, this may be true. Like Dave commented
elsewhere in the thread today, I am not convinced about increased effort
on triaging (initial submission) or review of individual XEPs to move
between states. If you mean the volume of submissions or XEP PRs, then
we need to figure out how to lighten that effort. In the past, for
example, PRs were not the approach to getting a XEP changed. You'd
discuss your suggestions with the author(s) and then they would make
changes. The Editor might be involved, but there is no such requirement
unless (about) to move between states.
I agree with Dave that putting all the scrutiny at the beginning of your
process (unlike before) does not help. Instead, accepting a new
contribution with light review allows the distribution of the load to
the rest of Standards JIG. I.e. people will start reading, commenting,
attempting to implement, etc.
> If you cannot formulate the requirements for
quality for humans, then
how does declaring use of AI make things better? And if
you can, and a
submission complies, how does it matter that AI was used in the process?
How would you handle “AI-tainted” submissions differently?
I would read it differently. If I know that a
whole section is AI
written, I know that the text and references can be
hallucinated, and that
there can be more boilerplate text than a human would do.
If AI is used to extract table or make examples,
I'll probably check
quickly for hallucinated values.
If AI is used for slight reformulation and
spelling/grammar, I'll
probably read it no differently as I read pure human
submission.
If a request is slop (low effort fully generated AI), I'll probably not
bother
and reject it.
In any case, I would appreciate and consider polite to be informed if
I'm
reading a human or machine generated content.
What criteria do you use to make these judgements. Why is there an
assumption that if a human created it, you do not have to be as thorough?
> The same holds for potential rights issues.
The author is still
responsible.
>
> My concern is that all future submissions will just have this
disclosure as
boilerplate, and a recipient cannot assess how deep the
impact of the use of AI is. With the accelerating growth we see in both the
capabilities and the use of AI, this becomes increasingly hard. We will not
have gained anything substantial. In that regard it reminds me of the Evil
Bit (RFC 3514) / Malicious Stanzas (XEP-0076).
This is not what I'm seeing in other
projects. Even the local inference
engine "llama.cpp", which we can
hardly accuse to be "anti-AI", ask for
that, you can check PRs there: https://github.com/ggml-org/llama.cpp/pulls
I agree that allowing submissions by PR makes it easier for agents and
people to submit them and that may contribute to increased volume. I
also think that code is different from protocol specifications. But as I
mentioned above, if you cannot triage quickly, this requires changes to how
heavy your triage process is. I do not see how an optional declaration
makes any of this better.
> The statement you linked to seems like common
sense and doesn't
actually require disclosure. Consider this document again,
but conceptually
replace “the use of AI” with the “use of a keyboard”. Does having such a
statement change the outcome of our standards process?
This is a very poor comparison. It's like
saying "I don't see why we
need a driving license, I don't need one to
walk". The scale is not the
same, with LLM you can generate easily tons of text looking on the surface
more or less OK.
I love car analogies. No, my suggestion is more like you asking how I
got to the XMPP Summit, and you valuing me differently when I came by
car. Besides your personal preferences, this should not have any bearing
on my contributions in that venue. And I will certainly not show you my
drivers license or discuss its impact on the environment _in that context_.
> I think that our author guidelines (XEP-0143)
are already clear, and
sense all the above boils down to this:
>
> “Authors must understand, verify, and take responsibility for
every
contribution they submit.” (-- ChatGPT with my prompting)
>
> While noting that this stance is not universally accepted (e.g. see <
https://jme.bmj.com/content/51/4/230>)t;), I think it is suitable for our
standards process. Feel free to use this phrase in a concrete proposal,
like a PR to XEP-0143.
To clarify my (current) position: I'm not
asking for an AI ban, it could
not be enforceable and AI is a great tool for
accessibility and many other
things. But I'm advocating for requesting a disclosure (maybe not
mandatory, but strongly suggested). Explain that we have human reviewers
behind, and that we'll reject AI slops specifications. Use of AI need to be
fully checked, and text should be reduced to essential. The later is one of
the main painful point with content generated by or with AI: it's longer
than necessary, and that make it harder to review.
We could start to have this as a template/popup when doing a
pull-request.
As I wrote earlier, if you can provide concrete changes to, say,
XEP-0143, I would be happy to judge them on face value. I am fine with
stronger indication of the responsibilities we require of authors (like
my proposed text). Preferably, you still need to define how you "reject
AI slops" using objective criteria. If "gut feeling" is the process,
then you can already do this.
FWIW, the paper I referenced is an in-depth discussion on the
responsibilities of human authors on scientific papers, which should be
an interesting read for anyone that wants to seriously discuss this
topic. There are rebuttals to it, too, but unfortunately they are not as
open-access as this CC-licensed paper.
> Disclosure: this message was manually (glide)
typed on a OnePlus 12,
using Google Board, in Thunderbird for Android. Conversing
with AI may have
influenced my thought process. Except where explicitly noted, no excerpts
of other works were included in this message.
No need to be sarcastic here, this is a problem
seen across the whole
industry, it seems legitimate to me to state our position,
like many other
organisations are doing.
This was not meant as a sarcastic jab at all. It was meant as a concrete
example of how hard it is to usefully declare the use of AI. I
specifically mentioned Google Board and glide typing, because it uses
machine learning and AI for writing each word based on how you glide. It
has auto-correction, spell checks, etc. I didn't run the whole text
through an LLM myself to correct my writing, though, and so there should
be no hallucinations (other than my own) or unsupported citations.
If you want to have optional declarations of the use of AI, then you
also need to specify what that declaration could look like. If it is
free-form, then you will get things like my example.
ralphm
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
4:46 a.m.
On 08/07/2026 11.45, Guus der Kinderen wrote:
Hi Ralph,
Two things:
First on the review gate: Dave has made the point that it sits too
early, and you've added that XEPs used to be changed by discussing
with the author rather than by PR. Moving that gate later (light
review at intake, with the deeper reading happening as people actually
engage with a spec) is a change we could actually make. It has the
property that nothing gets a careful reading until someone cares
enough to give it one, which is exactly the wrong incentive for anyone
submitting in volume. It would help whether or not that volume
materialises. It doesn't require us to agree about AI at all. Before
committing to it, though, I'd want to understand why we moved in the
other direction in the first place. Presumably it served some purpose.
I think
because PRs (in GitHub) from interaction perspective is much
easier to deal with and coders are familiar with it. I.e. when you
submit a PR, you have a malleable chain of modifications (to improve the
change during the interactive review process), you can comment on
specific parts of those modifications, mark when particular comments are
resolved, etc., and you can preserve that process both in the repository
(if you do branch merges) and in GitHub's ticketing system.
The prior mechanism was mostly discussing changes on this list
(preferably) and in private and public conversations on IRC (initially)
and XMPP.
I do not think that lightening the triage affects submission volume,
though. I also assume in all my previous comments that AI-assisted
contributions are still done by humans and not automated as well.
Lightening the triage does provide a way to handle increased volume.
Second: you've twice invited a PR against XEP-0143
using your
phrasing. I've opened one: https://github.com/xsf/xeps/pull/1552. It's
your sentence, in the submission process rather than the
pre-submission advice, since the latter is explicitly advisory. It's
deliberately not AI-specific and it doesn't settle anything else here.
I'd rather it merged on its own merits than became a proxy for the
wider argument.
Thanks for the PR. As the mediate author / human prompter, it would
be
weird to approve the change, but I do support it.
You asked Goffi why a human-authored document
wouldn't need the same
thoroughness. I think that's unfair to him. Reviewers have always read
with priors. You read a new contributor more carefully than a familiar
one, and for a familiar contributor you may give more attention to
certain aspects than to others. Knowing a submission came from an LLM
tells you to go and check the references. That's useful information,
if you have it. My objection isn't that disclosure would tell us
nothing, it's that I don't expect it to be accurate in the cases where
it matters most. Those are separate arguments, and I think they've
been getting mixed up.
Right, individuals gather reputation. Does a known author
that increases
its use of AI in the generation of their contribution lower their
reputation because of that? I personally expect from any known
contributor that the quality of their work does not decrease.
Does / should disclosure materially affect the review process for
newcomers? If so, how can you trust their disclosure one way or the other?
Also, I don't think that it is the role of a reviewer (in general,
including code) to become experts on all details of contributions. This
includes the XMPP Council. Like in the IETF, the responsibility for the
quality and correctness of a given specification is shared between the
authors, the Standards-JIG, and the Council. Besides managing our
standards process, the Council exists to provide a set of people that
have the specific task to provide technical advice and in general review
contributions, on top of the wider community view. A dedicated
collection of additional eyes, so to say.
If the current understanding is that the Council is fully responsible
for the outcome, then I believe that is undesirable and we need to make
the role of the Council more explicit in this regard.
ralphm
5:09 a.m.
Hi Ralph,
I agree Council is not fully responsible, and I'd support saying so
explicitly. However, I think that XEP-0001 is already quite explicit in
this (requiring rough consensus, running code, Council approval reads like
the "shared responsibility" that we're talking about). I'm not sure
there's
a gap.
If you think the current _understanding_ differs from the current text,
that seems worth saying out loud on the list.
Kind regards,
Guus
On Wed, Jul 8, 2026 at 12:47 PM Ralph Meijer <ralphm(a)ik.nu> wrote:
On 08/07/2026 11.45, Guus der Kinderen wrote:
Hi Ralph,
Two things:
First on the review gate: Dave has made the point that it sits too
early, and you've added that XEPs used to be changed by discussing
with the author rather than by PR. Moving that gate later (light
review at intake, with the deeper reading happening as people actually
engage with a spec) is a change we could actually make. It has the
property that nothing gets a careful reading until someone cares
enough to give it one, which is exactly the wrong incentive for anyone
submitting in volume. It would help whether or not that volume
materialises. It doesn't require us to agree about AI at all. Before
committing to it, though, I'd want to understand why we moved in the
other direction in the first place. Presumably it served some purpose.
I think
because PRs (in GitHub) from interaction perspective is much
easier to deal with and coders are familiar with it. I.e. when you
submit a PR, you have a malleable chain of modifications (to improve the
change during the interactive review process), you can comment on
specific parts of those modifications, mark when particular comments are
resolved, etc., and you can preserve that process both in the repository
(if you do branch merges) and in GitHub's ticketing system.
The prior mechanism was mostly discussing changes on this list
(preferably) and in private and public conversations on IRC (initially)
and XMPP.
I do not think that lightening the triage affects submission volume,
though. I also assume in all my previous comments that AI-assisted
contributions are still done by humans and not automated as well.
Lightening the triage does provide a way to handle increased volume.
Second: you've twice invited a PR against
XEP-0143 using your
phrasing. I've opened one: https://github.com/xsf/xeps/pull/1552. It's
your sentence, in the submission process rather than the
pre-submission advice, since the latter is explicitly advisory. It's
deliberately not AI-specific and it doesn't settle anything else here.
I'd rather it merged on its own merits than became a proxy for the
wider argument.
Thanks for the PR. As the mediate author / human prompter, it
would be
weird to approve the change, but I do support it.
You asked Goffi why a human-authored document
wouldn't need the same
thoroughness. I think that's unfair to him. Reviewers have always read
with priors. You read a new contributor more carefully than a familiar
one, and for a familiar contributor you may give more attention to
certain aspects than to others. Knowing a submission came from an LLM
tells you to go and check the references. That's useful information,
if you have it. My objection isn't that disclosure would tell us
nothing, it's that I don't expect it to be accurate in the cases where
it matters most. Those are separate arguments, and I think they've
been getting mixed up.
Right, individuals gather reputation. Does a known author
that increases
its use of AI in the generation of their contribution lower their
reputation because of that? I personally expect from any known
contributor that the quality of their work does not decrease.
Does / should disclosure materially affect the review process for
newcomers? If so, how can you trust their disclosure one way or the other?
Also, I don't think that it is the role of a reviewer (in general,
including code) to become experts on all details of contributions. This
includes the XMPP Council. Like in the IETF, the responsibility for the
quality and correctness of a given specification is shared between the
authors, the Standards-JIG, and the Council. Besides managing our
standards process, the Council exists to provide a set of people that
have the specific task to provide technical advice and in general review
contributions, on top of the wider community view. A dedicated
collection of additional eyes, so to say.
If the current understanding is that the Council is fully responsible
for the outcome, then I believe that is undesirable and we need to make
the role of the Council more explicit in this regard.
ralphm
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
5:22 a.m.
On 08/07/2026 13.09, Guus der Kinderen wrote:
Hi Ralph,
I agree Council is not fully responsible, and I'd support saying so
explicitly. However, I think that XEP-0001 is already quite explicit
in this (requiring rough consensus, running code, Council approval
reads like the "shared responsibility" that we're talking about). I'm
not sure there's a gap.
If you think the current _understanding_ differs from the current
text, that seems worth saying out loud on the list.
My understanding of how it should work (and worked during my 8 year
tenure) is supported by what we have written down, but mostly focused on
the perspective of an author. I increasingly feel that the current
Council and Standards-JIG in general do not, as evidenced by the
discussions on Experimental vs. Draft, the topic at hand, and perceived
pressure on the work of the Editors and Council.
Our procedures are not very explicit about what is expected of Council
or Editors, i.e. how to review and what the responsibility for the
outcome is.
ralphm
5:34 a.m.
Hi Ralph,
I think you've diagnosed this more sharply than I did. Would you write it
up? I've taken the prior-art survey; this seems like the more important
half.
Kind regards,
Guus
On Wed, Jul 8, 2026 at 1:22 PM Ralph Meijer <ralphm(a)ik.nu> wrote:
On 08/07/2026 13.09, Guus der Kinderen wrote:
Hi Ralph,
I agree Council is not fully responsible, and I'd support saying so
explicitly. However, I think that XEP-0001 is already quite explicit
in this (requiring rough consensus, running code, Council approval
reads like the "shared responsibility" that we're talking about). I'm
not sure there's a gap.
If you think the current _understanding_ differs from the current
text, that seems worth saying out loud on the list.
My understanding of how it should work (and worked during my 8 year
tenure) is supported by what we have written down, but mostly focused on
the perspective of an author. I increasingly feel that the current
Council and Standards-JIG in general do not, as evidenced by the
discussions on Experimental vs. Draft, the topic at hand, and perceived
pressure on the work of the Editors and Council.
Our procedures are not very explicit about what is expected of Council
or Editors, i.e. how to review and what the responsibility for the
outcome is.
ralphm
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
11:07 a.m.
Two passerby thoughts here for the list:
1. It seems to be a consensus in the list that XEPs can be rejected if
they are "bad" in some way. The issue here is that its not clear what
"bad" means. This would help the editor (or council) a lot for example
to be able to point at "something" that is public and clear. This can of
course also help for the Code of Conduct and for the Experimental
process among other things.
IMHO a good baseline is:
- The author of said XEP *CAN* give the copyright to XSF
- The author of said XEP *CAN* explain why and how in a XEP
- The author of said XEP *HAS* communicated with the XSF (in one of our
rooms, mailing list, summit, etc.) or is vouched by one of the members
of XSF before making the XEP that their approach is at least desired and
may make some sense for initial experiments.
This solves: XEP "dumps" where we don't know why it is like this, who
wrote this, is this in good faith, is this wanted/needed etc., solves
the work of somebody submitting XEPs without knowing what it is written
in there and also covers liability. Note that the first is already
written (and imo that makes llms unable to be used already as openjdk
and other projects have stated)
Last one admittedly may be a bit controversial but i think all these can
lower significantly the load. (Yes the XEP process doesn't make much
sense anymore as it is done (including the Author) but these are
suggestions for another day).
2. Regarding what approach we can have to actually write this down some
examples are that *DO NOT* ban LLMs:
- The netbsd commit guidelines
https://www.netbsd.org/developers/commit-guidelines.html
- The OpenJDK guidelines: https://openjdk.org/legal/ai
The OpenJDK ones have also a nice FAQ that is beneficial for everybody
here to read.
Now up to the question that was stated: "How do we make sure that LLMs
were/were not used?" you don't. Just like we still have people that
break the Code of Conduct in chats sometimes.
The point is to instead: Discourage people that don't want a CoC or
would break the CoC not to come into the rooms (mostly it works) and
second (for the people that do break the rules) to be able to point to
what rules we follow (so we are not a autocracy). Of course any rules
are up to us to enforce so they are on a case by case basis, blindly
applying rules leads without reason leads to oppression.
A bit of a meta comment feel free to disregard, I aim to formalize the
following at some point:
- Consent is followed, no data scraping/harvesting without consent,
https://www.consentfultech.io/
- The tools used follow permacomputing principles,
https://permacomputing.net/principles/
- You can license them to our license
- You have complete understanding of the text/graphic (code or
otherwise), can explain it and know how and why it works (or doesnt)
A reviewer can just close PRs they suspect that do not follow these
guidelines. Of course the rules are contextual so they are taken on a
case by case basis.
Regards,
MSavoritias
On 7/8/26 2:22 PM, Ralph Meijer wrote:
On 08/07/2026 13.09, Guus der Kinderen wrote:
Hi Ralph,
I agree Council is not fully responsible, and I'd support saying so
explicitly. However, I think that XEP-0001 is already quite explicit
in this (requiring rough consensus, running code, Council approval
reads like the "shared responsibility" that we're talking about). I'm
not sure there's a gap.
If you think the current _understanding_ differs from the current
text, that seems worth saying out loud on the list.
My understanding of how it should work (and worked during my 8 year
tenure) is supported by what we have written down, but mostly focused
on the perspective of an author. I increasingly feel that the current
Council and Standards-JIG in general do not, as evidenced by the
discussions on Experimental vs. Draft, the topic at hand, and
perceived pressure on the work of the Editors and Council.
Our procedures are not very explicit about what is expected of Council
or Editors, i.e. how to review and what the responsibility for the
outcome is.
ralphm
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
9 Jul
9 Jul
7:12 a.m.
On Wed, 8 Jul 2026 at 18:08, MSavoritias via Standards <standards(a)xmpp.org>
wrote:
1. It seems to be a consensus in the list that XEPs
can be rejected if
they are "bad" in some way. The issue here is that its not clear what
"bad" means. This would help the editor (or council) a lot for example
to be able to point at "something" that is public and clear. This can of
course also help for the Code of Conduct and for the Experimental
process among other things.
I think your last suggestion actually handles the "definition of bad",
or
rather, defines a "definition of good enough" that I think - with maybe
some tweaks - is ideal.
IMHO a good baseline is:
- The author of said XEP *CAN* give the copyright to XSF
Right. I think (hope!) we have this already. I refer to this as the
copyright warranty.
- The author of said XEP *CAN* explain why and how in
a XEP
I'm less bothered about this, but I see the logic, and think it's covered
by Guus's PR (of Ralph's words).
If you want clarification, I mean that obviously it's sensible to
understand the spec you're submitted in all its details, but I'm not sure
we need a warranty to that effect. It equally obviously does no harm,
though, so I've no objections either!
- The author of said XEP *HAS* communicated with the
XSF (in one of our
rooms, mailing list, summit, etc.) or is vouched by one of the members
of XSF before making the XEP that their approach is at least desired and
may make some sense for initial experiments.
I think this needs tweaking but the essential concept - that other people
support the submission - is really important.
This does two things:
- It means that the kind of mindless AI slop that I think we're all rightly
concerned about never gets traction - not because it's AI, but because it's
mindless slop.
- It also means that the early stage workload is offloaded from Council.
Council only need to take notice of submissions that actually gain any kind
of traction in the community.
I would s/one of the members of XSF/participants in the Standards SIG/
because we've not selected our membership on the basis of technical
scrutiny, and it just feels like if a ProtoXEP is getting positive
discussion and engagement on the standards list it's probably good for
Experimental. Council's effort is then a judgement call on that, rather
than having to scrutinise the specification itself as much.
This solves: XEP "dumps" where we don't know why it is like this, who
wrote this, is this in good faith, is this wanted/needed etc., solves
the work of somebody submitting XEPs without knowing what it is written
in there and also covers liability. Note that the first is already
written (and imo that makes llms unable to be used already as openjdk
and other projects have stated)
Your parenthetical opinion is far from universal.
First, the situation with code is radically different to that for text, and
second, the copyrightability of AI output varies heavily by jurisidiction
and human effort involved. Here in the UK, for instance, we have existing
primary legislation (from 1986!) that says LLM output is copyrightable.
Other jurisdictions have case law concerning the extremes of AI output, so
we know that a XEP coming from a US citizen solely generated by a single
prompt of something like "Create a new XEP for something" would likely not
be copyrightable.
But, this doesn't matter, because by requiring the author to warrant they
can assign copyright, we push that liability onto the author. Hoorah!
2. Regarding what approach we can have to actually
write this down some
examples are that *DO NOT* ban LLMs:
All these are code based, and our concern here is prose. We're protected in
any case because of the warranty we demand from submitters.
You can stop reading here if you want, the rest is just saying "I
understand the argument but reject it".
There's an argument that because the training data for LLMs was (possibly
misused) copyright code, the output is a derived work (in copyright terms)
of the original training data. This is supported because at least in some
cases in the early days, if you asked for particularly niche code, you'll
end up with output looking very similar to pre-existing projects. I have
not duplicated these results, and I absolutely tried hard - I have the only
open source code based on certain specifications which are not public, so
niche in some interesting ways, but I've seen other claims and have no
reason to doubt it can (or could) happen.
The problem with this is that few people are making this argument with
prose - people actually complain that AI generated prose doesn't look human
enough - and also nobody makes this argument with human generated anything.
I can fully assure you that this email is not considered a derived work of
Asimov or Bujold or Scalzi, despite the fact I have read all three an
almost unhealthy amount. Similarly, the code I write has never been
considered a derived work even though I certainly read other people's
copyright code to learn how to write it.
Whether or not the LLMs were originally trained with copyright works in
contravention of their licences is a whole other matter, but from a purely
legal perspective I think that's between the copyright owners and the LLM
developers. You are welcome to take an ethical stance on that one on a
personal basis.
Dave.
8:46 a.m.
Hi Dave,
Thanks for this. I quite like this direction, as it elegantly addresses the
actual harm: slop consuming the time of Council or Editor at intake. That's
now replaced by a judgement call on whether engagement exists, which is
considerably lighter.
This does introduce a trade-off: For someone like Edward, self-described as
being a newcomer writing in a second language, this can be a hurdle. A good
submission from someone not yet accustomed to interacting with the
community may struggle to gain traction, because seeking that engagement is
harder for them.
That said, requiring some minimal level of interaction before asking
Council to spend significant review effort doesn't seem unreasonable to me.
I mainly wanted to call out that trade-off to see whether it's something
we're comfortable with accepting.
Kind regards,
Guus
On Thu, Jul 9, 2026 at 3:13 PM Dave Cridland <dave(a)cridland.net> wrote:
On Wed, 8 Jul 2026 at 18:08, MSavoritias via Standards <standards(a)xmpp.org>
wrote:
1. It seems to be a consensus in the list that
XEPs can be rejected if
they are "bad" in some way. The issue here is that its not clear what
"bad" means. This would help the editor (or council) a lot for example
to be able to point at "something" that is public and clear. This can of
course also help for the Code of Conduct and for the Experimental
process among other things.
I think your last suggestion actually handles the "definition of bad",
or
rather, defines a "definition of good enough" that I think - with maybe
some tweaks - is ideal.
IMHO a good baseline is:
- The author of said XEP *CAN* give the copyright to XSF
Right. I think (hope!) we have this already. I refer to this as the
copyright warranty.
- The author of said XEP *CAN* explain why and
how in a XEP
I'm less bothered about this, but I see the logic, and think it's covered
by Guus's PR (of Ralph's words).
If you want clarification, I mean that obviously it's sensible to
understand the spec you're submitted in all its details, but I'm not sure
we need a warranty to that effect. It equally obviously does no harm,
though, so I've no objections either!
- The author of said XEP *HAS* communicated with
the XSF (in one of our
rooms, mailing list, summit, etc.) or is vouched by one of the members
of XSF before making the XEP that their approach is at least desired and
may make some sense for initial experiments.
I think this needs tweaking but the essential concept - that other people
support the submission - is really important.
This does two things:
- It means that the kind of mindless AI slop that I think we're all
rightly concerned about never gets traction - not because it's AI, but
because it's mindless slop.
- It also means that the early stage workload is offloaded from Council.
Council only need to take notice of submissions that actually gain any kind
of traction in the community.
I would s/one of the members of XSF/participants in the Standards SIG/
because we've not selected our membership on the basis of technical
scrutiny, and it just feels like if a ProtoXEP is getting positive
discussion and engagement on the standards list it's probably good for
Experimental. Council's effort is then a judgement call on that, rather
than having to scrutinise the specification itself as much.
This solves: XEP "dumps" where we don't know why it is like this, who
wrote this, is this in good faith, is this wanted/needed etc., solves
the work of somebody submitting XEPs without knowing what it is written
in there and also covers liability. Note that the first is already
written (and imo that makes llms unable to be used already as openjdk
and other projects have stated)
Your parenthetical opinion is far from universal.
First, the situation with code is radically different to that for text,
and second, the copyrightability of AI output varies heavily by
jurisidiction and human effort involved. Here in the UK, for instance, we
have existing primary legislation (from 1986!) that says LLM output is
copyrightable. Other jurisdictions have case law concerning the extremes of
AI output, so we know that a XEP coming from a US citizen solely generated
by a single prompt of something like "Create a new XEP for something" would
likely not be copyrightable.
But, this doesn't matter, because by requiring the author to warrant they
can assign copyright, we push that liability onto the author. Hoorah!
2. Regarding what approach we can have to
actually write this down some
examples are that *DO NOT* ban LLMs:
All these are code based, and our concern here is prose. We're protected
in any case because of the warranty we demand from submitters.
You can stop reading here if you want, the rest is just saying "I
understand the argument but reject it".
There's an argument that because the training data for LLMs was (possibly
misused) copyright code, the output is a derived work (in copyright terms)
of the original training data. This is supported because at least in some
cases in the early days, if you asked for particularly niche code, you'll
end up with output looking very similar to pre-existing projects. I have
not duplicated these results, and I absolutely tried hard - I have the only
open source code based on certain specifications which are not public, so
niche in some interesting ways, but I've seen other claims and have no
reason to doubt it can (or could) happen.
The problem with this is that few people are making this argument with
prose - people actually complain that AI generated prose doesn't look human
enough - and also nobody makes this argument with human generated anything.
I can fully assure you that this email is not considered a derived work of
Asimov or Bujold or Scalzi, despite the fact I have read all three an
almost unhealthy amount. Similarly, the code I write has never been
considered a derived work even though I certainly read other people's
copyright code to learn how to write it.
Whether or not the LLMs were originally trained with copyright works in
contravention of their licences is a whole other matter, but from a purely
legal perspective I think that's between the copyright owners and the LLM
developers. You are welcome to take an ethical stance on that one on a
personal basis.
Dave.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
10:21 a.m.
Hi all,
Firstly, thank you to MSavoritias (and Dave) for bringing focus to what
is actually the issue here: not the fact that something was created
using a certain technology or other but the fact that it is mindless
slop. I actually started composing an email to that effect earlier this
morning, but got a bit overwhelmed by all the nuances, so I'm thankful
to the others who managed to make a better job of it than I :-)
This does introduce a trade-off: For someone like
Edward,
self-described as being a newcomer writing in a second language, this
can be a hurdle. A good submission from someone not yet accustomed to
interacting with the community may struggle to gain traction, because
seeking that engagement is harder for them.
That said, requiring some minimal level of interaction before asking
Council to spend significant review effort doesn't seem unreasonable
to me. I mainly wanted to call out that trade-off to see whether it's
something we're comfortable with accepting.
While still leaving that trade-off on the table for everyone to think
about, I wonder if this might not be a positive change in other ways.
We have been talking in the past about encouraging more participation in
the standards list. Now we will have an incentive for submitters to
actually go out there and talk to people (to encourage more visible
discussion about the XEP) rather than sitting around waiting for the
Council to respond. This is an area where people can participate in a
less technical way as well ("hey it would be neat if my app could have
this feature" rather than the more technical "wait so how would that
work with X, Y, Z existing XEPs" that we have at the moment). I know
this can happen even without the additional "incentive" but it isn't,
and maybe this will be what pushes it.
(The other possibility is that the mailing list and MUCs get filled with
mindless-slop "discussions" as well, but hopefully "you have to also
text us" will be a decent barrier and I suspect the community will be
adept at weeding out any garbage that does make it through.)
~Badri
14 Jul
14 Jul
9:19 a.m.
Hi all,
I said I'd do the prior-art survey. It's here:
https://wiki.xmpp.org/web/AI_contribution_policies_in_other_projects
It's a wiki page. Please correct it directly.
The main caveat: almost none of this evidence is about standards. Of the
many organisations that are cataloged, by far most are code projects, where
CI catches some of what a reviewer otherwise would. The analogies may not
stretch far.
Three things that seemed relevant here. Ghostty required AI disclosure from
August 2025, for the reason Mattj gives. They still do, and have since
added a vouching system for first-time contributors as well. OpenJDK and
GraalVM are both Oracle projects whose contributors sign the same
agreement, and they published opposite policies six weeks apart. And curl
reopened the bug bounty it closed in January: volume hadn't fallen, but the
reports had stopped being wrong, which Stenberg attributes to the models
improving.
Kind regards,
Guus
On Thu, Jul 9, 2026 at 6:21 PM Badri Sunderarajan <badrihippo(a)disroot.org>
wrote:
Hi all,
Firstly, thank you to MSavoritias (and Dave) for bringing focus to what
is actually the issue here: not the fact that something was created
using a certain technology or other but the fact that it is mindless
slop. I actually started composing an email to that effect earlier this
morning, but got a bit overwhelmed by all the nuances, so I'm thankful
to the others who managed to make a better job of it than I :-)
This does introduce a trade-off: For someone like
Edward,
self-described as being a newcomer writing in a second language, this
can be a hurdle. A good submission from someone not yet accustomed to
interacting with the community may struggle to gain traction, because
seeking that engagement is harder for them.
That said, requiring some minimal level of interaction before asking
Council to spend significant review effort doesn't seem unreasonable
to me. I mainly wanted to call out that trade-off to see whether it's
something we're comfortable with accepting.
While still leaving that trade-off on the table for everyone to think
about, I wonder if this might not be a positive change in other ways.
We have been talking in the past about encouraging more participation in
the standards list. Now we will have an incentive for submitters to
actually go out there and talk to people (to encourage more visible
discussion about the XEP) rather than sitting around waiting for the
Council to respond. This is an area where people can participate in a
less technical way as well ("hey it would be neat if my app could have
this feature" rather than the more technical "wait so how would that
work with X, Y, Z existing XEPs" that we have at the moment). I know
this can happen even without the additional "incentive" but it isn't,
and maybe this will be what pushes it.
(The other possibility is that the mailing list and MUCs get filled with
mindless-slop "discussions" as well, but hopefully "you have to also
text us" will be a decent barrier and I suspect the community will be
adept at weeding out any garbage that does make it through.)
~Badri
7
days inactive
71
days old
42 comments
14 participants
participants (14)
-
Andrew Nenakhov -
Badri Sunderarajan -
Dave Cridland -
Edward Tie -
Goffi -
Guus der Kinderen -
Jonas Schäfer -
Kevin Smith -
Marvin W. -
Mathieu Pasquet -
Matija Šuklje -
Matthew Wild -
MSavoritias -
Ralph Meijer