Re: We should require AI disclosure

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 -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]