Proposal: FLTK Policy on AI-Assisted Code Contributions
melcher....@googlemail.com
Much of the following text has been written by AI, not to give this some irony - the content is still exactly what I asked AI to write - but it's worded so much nicer :-) .
Background
AI coding tools are now mainstream. Contributors are using them, whether or not they mention it. We need a stated position because the community has concerns that deserve a direct response and because silence on the topic is itself a policy choice.
The biggest worry seems to be copyright. Will an AI-generated patch carry hidden copyright from training data? Will merging it expose FLTK to a claim? Will downstream users of FLTK be endangered if their product is built on code that turns out to be tainted?
There are secondary concerns too: AI tools consume significant energy, AI output tends to be verbose and generic rather than carefully crafted, and "vibe-coded" submissions may be difficult to maintain by anyone other than the person who prompted them.
My Position
The copyright concern is real — but it is not new, and it is not specific to AI.
FLTK has always accepted patches from contributors. We have always taken them on good faith. We have never been able to verify that a human contributor did not copy code from a proprietary library, did not reproduce a snippet from a Stack Overflow answer with a non-compatible license, or did not inadvertently carry prior employer IP into their submission. The risk of a contaminated patch has existed since the project began. We have managed it through the same mechanism that every open source project uses: review.
The legal exposure from AI-generated code is, right now, genuinely unsettled. There are active court cases. There is no consensus. But the theoretical risk that some fragment of training data could surface in generated output is not categorically different from the theoretical risk that a human contributor copies a few lines they saw somewhere. In both cases, the answer is the same: we review the code before it goes in.
The secondary concerns — energy use, code quality, maintainability — are real quality-of-contribution issues, and we should address them as quality issues, not as a separate class of prohibition.
I propose we adopt the following position:
FLTK does not prohibit or require disclosure of AI-assisted contributions. The standards for acceptance are the same regardless of how the code was produced.
Core developers treat every externally contributed patch as they always have: as a starting point that requires careful review, line-by-line scrutiny, and likely modification or partial rewrite before it can be merged into the main tree. This is not a comment on the contributor's skill or intent - it is how we maintain coherence in a C++ library with a 30-year history, tight platform constraints, and a strict ABI discipline. That standard applies equally whether the author is a seasoned developer, a newcomer, or a language model.
Contributors should be aware of this. A patch - however well-crafted - is not a merge. The core team will adapt it to FLTK conventions, may restructure it substantially, and takes final responsibility for what lands in the tree. That responsibility is exactly why we review it ourselves rather than delegating it to the submitter's tool chain, human or automated.
What This Does and Does Not Do
It does not expose us to new copyright liability. We are not importing AI output wholesale. We are reviewing, rewriting where needed, and taking authorship of the result. The core developers are the authors of what goes into FLTK, drawing on contributions as raw material - which is what we have always done.
It does not lower the quality bar. If a submission is unmaintainable, over-engineered, or stylistically foreign to the codebase, it will not be merged in that form. That is true of human submissions today and has been for as long as I can remember.
It does not endorse careless use of AI tools. Contributors who submit large AI-generated blobs with no effort to understand what they are proposing will find the process frustrating - not because we ban AI, but because we require contributors to be able to engage in a technical discussion about their patch. That expectation is unchanged.
What I Am Asking the Group
This is a starting point for discussion, not a final rule. I would like to hear:
- Whether anyone sees a genuine legal risk here that is materially different from the existing risk of human-contributed code
- Whether we want to ask contributors to disclose AI use (I lean against requiring it, but I am open to discussion)
- Whether we want to say anything specific about AI in the contribution guidelines, or simply rely on the existing review standards
I do not think we need a long or complex policy. The simpler the better. But I do think we need something written down, so we can point to it rather than relitigating the question each time someone raises it.
- Matthias
Greg Ercolano
On 5/29/26 04:01, 'melcher....@googlemail.com' via fltk.coredev wrote:
Much of the following text has been written by AI, not to give this some irony - the content is still exactly what I asked AI to write - but it's worded so much nicer :-) .
BTW, for what it's worth, we might want to look towards what other larger projects are doing. Linux has hit a few issues with AI, and linus has weighed in several times. I posted an article a month ago here on fltkcoredev, Subject: "AI an open source", which included an article in Tom's Hardware about the linux project's first issues with AI generated code, repasting here:
To: fltkc...@googlegroups.com From: Greg Ercolano <er...@seriss.com> Subject: [fltk.coredev] AI and open source Date: Sun, 12 Apr 2026 19:45:12 -0700I've seen some of the bug reports and AI assisted patches.
Apparently linux has had their share and came to some conclusions about the subject,
making this short article interesting read.
Perhaps we should consider tagging all commits that include AI assisted code.
There's been more about this subject recently in the news,
including an enormous inrush of AI generated bug reports to the
linux kernel that's inundating devs and code maintainers.
AI coding tools are now mainstream.
Gotta say, I'm impressed with its ability to find bugs, offer
patches, reword and check documentation for grammatical errors,
omissions and/or incrongruities with respect to source code,
checks for inconsistencies between comments and code, and can even
determine code intention vs. what's actually implemented. Finds
bugs compilers can't, offers patches in my own coding style, etc
etc. More often than not, it's been brilliant!
When I use it, I've been carefully inspecting everything, and
retype patches to be sure I don't miss anything, and often find
ways to better write the code as I do.
Very unlikely for there to be any kind of copyright issue with
small bug fixes. I suppose where it might get interesting is large
blocks of code or functions.. I haven't run into that though, but
might.
So far, whenever I commit something ai assisted, in my case
I've been marking the commit "codex: <some commit message>",
if for no other reason, to simply give credit where credit is due,
but also to indicate the source of the bug report for historic
purposes. (In my case I've been mostly using ai to identify bugs,
so it's basically the author of bug reports)
I don't know if that practice of including a prefix in all my
commits will be useful, but I think it's important to do.
Not sure I see if it can hurt if we /require/ people to
identify use of AI (and which AI) in any patches or
bug reports. Even if we don't take the code word-for-word, it's
possible for historical provinance. Basically the same reason we
have non-anonymous bug reports/patches, it'd be good to site the
AI agent for any involvements; issues or patches.
I haven't yet used AI on FLTK, but I probably will soon, to
have it audit my contributions for bugs and docs inconsistencies
my larger widgets; Fl_Table/Tree/Terminal, example programs, side
projects like Fl_OpDesk, etc.
I'm still going through my commercial software at the moment;
spent the last week or so going at it.
The biggest worry seems to be copyright. Will an AI-generated patch carry hidden copyright from training data? Will merging it expose FLTK to a claim? Will downstream users of FLTK be endangered if their product is built on code that turns out to be tainted?
Can't blame them, lawyers are always looking to avoid problems.
I think by, as you say, carefully picking through bug reports/patches/PRs, instead of taking them as written, we shouldn't have to worry about it.
And I don't /think/ anything we're doing is so innovative as to infringe copyright. Hard to call, but I mean really we are purposefully behind the curve when it comes to UI.
There are secondary concerns too: AI tools consume significant energy,
Despite what we might do or say about that issue, the AI freight train is smashing into the global business world with gusto, and I expect data centers are being built in anticipation of the world using AI to run companies in every which way, up, down and inside out. AI software is surely but a tiny insignificant spec in that consumption/drive.
The only reason I can think of for even mentioning energy use as a consideration is someone seeking a position of activisim or moral posture.
Most importantly, AI is actively being used by hackers to
find bugs. So we're obligated to use AI to find bugs and fix them,
just to keep up..! The same way we use full compiler warnings to
detect problems, so should we use AI. We kinda have to. I think
users of our software feel the same way, pressed to find bugs and
report them in this new suddenly hostile climate, and will surely
audit our code and provide us bug reports subsequentally.
AI output tends to be verbose and generic rather than carefully crafted, and "vibe-coded" submissions may be difficult to maintain by anyone other than the person who prompted them.
I've had good luck with "make me a small perl script that converts code page 437 to utf-8", but I've heard people having problems with generating more complex tools. Depends on the tool I think; stuff that has a lot of precidents gives better results than using it for newer tech, like "rewrite my opengl program using metal" might not give great results.
That said, from one knowledgeable person I've talked to, I know some people who vibe code just let AI do all the maintenance. Hard to believe, given some of the things I've caught AI doing, but I guess it might be at that level for certain types of jobs, like small tools that are easily demonstrated to be working or not.
My Position
The copyright concern is real — but it is not new, and it is not specific to AI.
FLTK has always accepted patches from contributors. We have always taken them on good faith. We have never been able to verify that a human contributor did not copy code from a proprietary library, did not reproduce a snippet from a Stack Overflow answer with a non-compatible license, or did not inadvertently carry prior employer IP into their submission. The risk of a contaminated patch has existed since the project began. We have managed it through the same mechanism that every open source project uses: review.
The legal exposure from AI-generated code is, right now, genuinely unsettled. There are active court cases. There is no consensus. But the theoretical risk that some fragment of training data could surface in generated output is not categorically different from the theoretical risk that a human contributor copies a few lines they saw somewhere. In both cases, the answer is the same: we review the code before it goes in.
I propose we adopt the following position:
FLTK does not prohibit or require disclosure of AI-assisted contributions. The standards for acceptance are the same regardless of how the code was produced.
At least initially it can't hurt, and may be useful if people in the future mistake works predating our use of AI as AI generated.
I expect when I do actually use AI to go thru my FLTK
code/docs looking for problems, I expect I'll cite the AI tool in
the issues/commits.
Core developers treat every externally contributed patch as they always have: as a starting point that requires careful review, line-by-line scrutiny, and likely modification or partial rewrite before it can be merged into the main tree. This is not a comment on the contributor's skill or intent - it is how we maintain coherence in a C++ library with a 30-year history, tight platform constraints, and a strict ABI discipline. That standard applies equally whether the author is a seasoned developer, a newcomer, or a language model.
Contributors should be aware of this. A patch - however well-crafted - is not a merge. The core team will adapt it to FLTK conventions, may restructure it substantially, and takes final responsibility for what lands in the tree. That responsibility is exactly why we review it ourselves rather than delegating it to the submitter's tool chain, human or automated.
- Whether we want to ask contributors to disclose AI use (I lean against requiring it, but I am open to discussion)
+1
- Whether we want to say anything specific about AI in the contribution guidelines, or simply rely on the existing review standards
I do not think we need a long or complex policy. The simpler the better. But I do think we need something written down, so we can point to it rather than relitigating the question each time someone raises it.