Heads-up: new AI policy [reverted pending further discussion]

[McDutchie]

There's a new AI policy paragraph in README.md. See 286fc25.

[avih]

I like it. I'd drop "forever" and other references to the future, because we can't tell the future.

I think it should describe the current policy - not future policy.

[siteshwar]

Thanks for your great work on ksh!

This policy should have been discussed with distribution maintainers (and other active contributors). In the case of RHEL, we are getting a significant amount of AI generated bug reports that are real upstream bugs and AI is suggesting patches based on those reports. So, basically we are coauthoring patches with AI. You can see an example pull request for scipy. I understand the concerns regarding the noise LLMs are creating for upstream maintainers, but they are also having a positive impact on the upstream communities. It seems technically infeasible to not have AI generated contributions in an open source project in the future. Legacy codebases like ksh that have a very limited contributor base would be the biggest beneficiary of AI assisted contributions in the future.

I would suggest ksh should follow similar guidelines as kernel for AI assisted contributions. I am proposing a replacement for policy point 9. This change was initially generated with Claude and manually refined:

9. AI policy: AI tools assisting with ksh development must follow the
standard development process described in the preceding policy points.
  - Human responsibility: The human submitter is responsible for 
reviewing all AI-assisted code, ensuring compliance with licensing
requirements, and taking full responsibility for the contribution's
correctness and quality. This includes documentation, commit messages
(see point 6), bug reports, and pull requests — all must reflect the
submitter's own understanding, not unreviewed AI output.
  - Attribution: When AI tools are used in developing a contribution,
the commit message must include an Assisted-by trailer in the
following format:
Assisted-by: TOOL_NAME:MODEL_VERSION [ANALYSIS_TOOL1] [ANALYSIS_TOOL2]
For example: Assisted-by: Claude:claude-sonnet-4-20250514
  - Quality standards: AI-assisted contributions are held to the same
quality bar as any other contribution. Submitters must be able to
explain and defend every change. Contributions that show signs of
insufficient human review — generic commit messages, code that does
not match the surrounding style (see point 7), missing regression
tests, or inability to discuss the change — will be rejected and 
submitters possibly be banned.
  - Licensing: All contributions must be compatible with this
project's license regardless of origin. The submitter certifies that
AI-assisted code does not knowingly incorporate copyrighted material
in a manner that would violate the project's licensing terms.

---
Key differences from the current ksh policy and how they map to the kernel's
approach:

Aspect: AI-generated code
Current ksh (ban): Banned outright
Kernel: Allowed with human review
Proposed ksh: Allowed with human review
────────────────────────────────────────
Aspect: Human responsibility
Current ksh (ban): N/A (banned)
Kernel: Human certifies DCO, reviews all code
Proposed ksh: Human takes full responsibility, must explain changes
────────────────────────────────────────
Aspect: Attribution
Current ksh (ban): N/A
Kernel: Assisted-by: trailer
Proposed ksh: Assisted-by: trailer (same format)
────────────────────────────────────────
Aspect: Quality bar
Current ksh (ban): "Vibe-coding" = ban
Kernel: Follow standard process
Proposed ksh: Same quality bar as any contribution; signs of insufficient
review = rejection
────────────────────────────────────────
Aspect: Licensing
Current ksh (ban): Copyright/plagiarism concerns cited
Kernel: Must comply with GPL-2.0-only
Proposed ksh: Must comply with project license

The approach retains the spirit of the original concern (quality, legal
liability) but channels it into enforceable guardrails rather than an
unverifiable ban.

[McDutchie]

Thanks @avih and @siteshwar for your comments. Fair enough, some community input would be a good idea. I have reverted the policy pending further discussion.

In the meantime I reserve the right to arbitrarily reject anything that smacks of AI slop to me, should it come up. I will also say now that the AI policy decision is ultimately mine, because the buck stops with me around here, and I have to live with the consequences of whatever is decided.

It's worth keeping in mind that none of the contributors are getting paid for any of this. This is a labour of love now.

[siteshwar]

Thanks @avih and @siteshwar for your comments. Fair enough, some community input would be a good idea. I have reverted the policy pending further discussion.

Thanks for considering our feedback!

In the meantime I reserve the right to arbitrarily reject anything that smacks of AI slop to me, should it come up. I will also say now that the AI policy decision is ultimately mine, because the buck stops with me around here, and I have to live with the consequences of whatever is decided.

I have been involved in a couple of AI projects in the last year or so. I have seen depressing AI slop, but also useful AI assisted contributions. In my experience, solving a clearly defined problem with the right model and the right prompt produces useful results. I would suggest you to sign up for Claude for Open Source. Since this project has only a couple of regular active upstream contributors who can only spend limited time on it, you would see a signnificant boost in your productivity if you can use AI to investigate bugs, review pull requests, write patches and test cases, analyze complex code and document it etc. I understand that the upstream maintainers are very cautious about making changes to this codebase due to its complexity, this is exactly the reason you would be more productive with AI assistance.

It's worth keeping in mind that none of the contributors are getting paid for any of this. This is a labour of love now.

People who are not familiar with this code do not realize the effort it takes to maintain it. Its a solid effort. Keep up your great work!

[McDutchie]

I understand that the upstream maintainers are very cautious about making changes to this codebase due to its complexity,

@siteshwar, I invite you to take some time to actually go through the commit log over the last five years. Virtually no part of this code base has been left untouched. While we always try to work with surgical precision, we have made many fundamental and far-reaching changes under the hood, and a lot has improved. As of the current commit, among many other things:

• ksh is finally fully 64-bit ready, for example, it will no longer crash if a variable value's length exceeds INT_MAX bytes. Special thanks to @JohnoKing who made that his project. (These fixes are not released yet but will be in the next release, soon.)
• I've applied a workaround for a fundamental design flaw in the lexer, parser and variable handling code that resulted in spurious syntax errors or a crash when certain grammatical constructs in scripts crossed 64 KiB buffer boundaries. This could potentially kill any script longer than 64 KiB and it's a problem that has always been in ksh. (This fix is not released yet but will be in the next release, soon.)
• Discipline functions now work reliably and without crashing, even when the shell throws an error.
• Fundamental problems have been fixed in the interaction between exception handling and ksh function scoping, as well as the DEBUG and KEYBD traps.
• A huge amount of undefined, inconsistent and/or incorrect behaviour has been fixed.
• ...etc. etc. - I could fill a book with this list at this point, but it's all in the NEWS file and in the commit log (which has detailed explanations of every substantial change in the commit messages, so you can use git blame to find the reason for all changes).

What I'm trying to say is that this small number of contributors has been a great deal more daring and productive than you seem to think. Therefore I am not feeling a particular need to resort to AI in order to make substantial improvements happen here. They have been happening.

That's not to say that it couldn't be better, of course. So, I have in fact been evaluating how AI (in particular, GitHub Copilot) performs in working out various open bugs. Suffice to say that, while it gave me some potentially useful pointers on where to look, its suggested fixes were very wrong every single time, and would have caused ksh to break in unacceptable ways, usually while not even fixing the bug in question.

I could see AI being potentially helpful in getting us started in documenting the code; it seems to be better at finding where things happen than in fixing things.

But first we need to grapple with the unresolved ethical and legal questions. I'll leave those points for another message.

[siteshwar]

What I'm trying to say is that this small number of contributors has been a great deal more daring and productive than you seem to think. Therefore I am not feeling a particular need to resort to AI in order to make substantial improvements happen here. They have been happening.

Point taken! But I was not questioning the daring or productiveness of the contributors. I only appreciated the attention to detail contributors have shown to this project. Thanks to everyone who contributed.

[dnewhall]

Personally, I'm 85% doomer when it comes to AI nowadays, so I strongly believe that we should remain as AI-free as possible.
Based on my experiences, my biggest issues with it are:

1. AI generated bug reports are often either wrong or duplicates, and then their proposed fixes are either suspect or wrong place/formatting/etc. for the project. If someone at, say, Red Hat is running LLMs over the code base and finds a legitimate issue, then they can contribute it under their own name after verifying.

2. I fully expect some copyright court ruling to have apocalyptic ramifications for AI generated code. I could see, say, Microsoft suing Anthropic over source copyright claims, Claude being unable to verify their models are clean of copyrighted code, and then every single Claude contribution becoming illegal.

[siteshwar]

Personally, I'm 85% doomer when it comes to AI nowadays, so I strongly believe that we should remain as AI-free as possible.

How would you verify that a contribution was not generated using AI? What shall be done with such contributions if they are useful, but found to be generated using AI later?

AI generated bug reports are often either wrong or duplicates, and then their proposed fixes are either suspect or wrong place/formatting/etc. for the project. If someone at, say, Red Hat is running LLMs over the code base and finds a legitimate issue, then they can contribute it under their own name after verifying.

I agree that projects with widespread active community receive duplicated reports that can be hard to manage. The reports and fixes may be wrong depending on how well they were manually verified.

I fully expect some copyright court ruling to have apocalyptic ramifications for AI generated code. I could see, say, Microsoft suing Anthropic over source copyright claims, Claude being unable to verify their models are clean of copyrighted code, and then every single Claude contribution becoming illegal.

I would not comment on the non technical aspects of using AI. AI (LLMs) are good at finding and generating patterns and they should be used accordingly. You can use very constrained prompts with these LLMs to generate similar patterns that already exist in the codebase. If you want to be cautious with AI generated contributions, it all comes to constraints you put on these models, whether automated through prompts or human driven through reviews.

It is still being actively discussed through out different communities about how to deal with AI assisted contributions. I can only tell you my technical opinion based on the constructive use of AI I have seen with my projects. I believe the active contributors to this project should adopt AI for the use cases they consider helpful.

[dnewhall]

How would you verify that a contribution was not generated using AI? What shall be done with such contributions if they are useful, but found to be generated using AI later?

Same way we already handle someone contributing code they didn't write or have permission to give us: once it's discovered we remove it and reimplement.

I would not comment on the non technical aspects of using AI.

I absolutely disagree. Every open source project of a decent enough size has to deal with licensing and copyright issues. KornShell has famously had its own issues with this. I believe that right now there are very strong reasons to be suspicious about every mainstream "AI" system that generates code when it comes to copyright assignment. (Although, OpenWALDO and similar might fix that.)

There are a lot of different tools that fall under the umbrella of "AI". Using it as basically a glorified search engine is obviously fine (but please verify any results, people). And I think using it to find issues in the code would be fine, so long as a human makes the fix(es) and submits the code. But right now I think allowing anything that generates code or changes infrastructure automatically in a project is a terrible idea.

If you get Claude or something to write your code, you don't get to say you wrote it. To quote Beej, if I pay a contractor to put in a deck, I don't get to say "I built a deck"; the best I can do is say "I had a new deck put in".

[siteshwar]

Same way we already handle someone contributing code they didn't write or have permission to give us: once it's discovered we remove it and reimplement.

This is not going to be pragmatic going forward.