We should require AI disclosure
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
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
On Mon, 11 May 2026 at 11:18, Marvin W. via Standards <standards@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
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
On Mon, 11 May 2026 at 15:14, Jonas Schäfer <jonas@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.
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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Mon, 11 May 2026 at 08:51, Goffi <goffi@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.
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
On Mon, 11 May 2026 at 13:40, Ralph Meijer <ralphm@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.
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:
put aside ethical and ecological concerns about LLMs
Why though?
The full sentence is:
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
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@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>
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@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
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@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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Tue, 12 May 2026 at 19:24, Guus der Kinderen <guus.der.kinderen@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.
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@campfire.wheremymonkeyis.at matrix: @hook:kompot.si
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@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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org
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
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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org <signature.asc>
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@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
Le 7 juillet 2026 21:16:07 GMT+02:00, Ralph Meijer <ralphm@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@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
On 7 July 2026 21:57:08 CEST, Mathieu Pasquet <mathieui@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
On 7 Jul 2026, at 22:48, Ralph Meijer <ralphm@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
On 8 July 2026 00:00:38 CEST, Kevin Smith via Standards <standards@xmpp.org> wrote:
On 7 Jul 2026, at 22:48, Ralph Meijer <ralphm@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.
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?
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
On Wed, 8 Jul 2026 at 00:11, Ralph Meijer <ralphm@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
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@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.)
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
On Wed, 8 Jul 2026 at 08:52, Goffi <goffi@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. > > Right - this is a potential problem of scale. > > 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. > > 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. > 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 > > 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 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. > > Again, this seems like a problem of scale more than anything else. > > 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. > > ... 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. > 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. > 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.
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@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>), 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@xmpp.org
> To unsubscribe send an email to standards-leave@xmpp.org
>
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
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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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>), 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
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@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>), 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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
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@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Wed, 8 Jul 2026 at 18:08, MSavoritias via Standards <standards@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.
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@cridland.net> wrote:
On Wed, 8 Jul 2026 at 18:08, MSavoritias via Standards <standards@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
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@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
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