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 :-) .

    Ah, the irony anyway ;^D

    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 -0700

I'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.

https://www.tomshardware.com/software/linux/linux-lays-down-the-law-on-ai-generated-code-yes-to-copilot-no-to-ai-slop-and-humans-take-the-fall-for-mistakes-after-months-of-fierce-debate-torvalds-and-maintainers-come-to-an-agreement

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.

    Indeed, even I'm now beginning to use AI (codex) for auditing my own 40 yrs of software, as of a week or two ago.

    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?

    I think people who use the library feel the same, perhaps not so much programmers as the legal departments of companies where those programmers work.

    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,

    Bah, this seems a total non-issue to me.

    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.

    Ya, I'm not yet sold on vibe coding, except maybe making small tools that are demonstrably working or not.
    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.

    Yes, feel pretty much the same.

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.

    Ya, I think the way we pick through user contributions, instead of importing PRs wholesale, it takes on our mark.

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.

    I'd offer we should ask people to cite AI use, for credit and historical purposes if nothing else.

    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.

    +1

• 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

    Whatever we decide should be said in the CMP and/or issues submit form pages.

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.

    I feel the same.

[Greg Ercolano]

 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.

    Ya, I'm not yet sold on vibe coding, except maybe making small tools that are demonstrably working or not.
    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.

    A recent anecdote:

    For fun/curiosity, I tried using codex to write a simple command line tool from scratch.

    My goal was to have it make a small tool on a mac that lists all the connected cameras, prompt me to pick one, and then snap a photo from that camera and save the image to disk as a raw pixel RGB dump using C++. The project I have in mind is to shoot animation (stop motion or 2D art), and also scan books and magazines with.

    And it did, and it worked first shot, creating a simple Makefile, and used a mix of C++ and Objective C, apparently because it had to for properly accessing the AVFoundation framework, something I know nothing about, and never wanted to know about, lol.

    Of interest, it even added command line options, something I didn't ask for, but is something any good command line tool would do, so I'm glad it took that initiative, and was pleasantly surprised/impressed.

    It even made a README.md file that described how to build and run the program, showed examples of  how to use the command line flags, and described why the program was written the way it was with the mix of C++ and Objective C.

    Next  I told it to modify the program to write out a PNG, and prompt me for the compression value, and it did that too, adding a command line flag as well, and somehow doing it without needing a PNG library, just by using zlib. Wow, yeah, ok, didn't know that's how PNGs could be done, and the code is really small to do that. And it updated the README.md and Makefile, making a clear commit history.

    All in all, the entire program is a single file almost 700 lines long. It did in a few minutes what might take me a week to figure out, and it did it in 5 or so minutes.

    So overall pretty impressed with that.. brave new world.

    I remember trying to get through the Apple library docs to research this a few years ago, but it was super complicated to figure out which foundation class was right for this purpose, and wasn't looking forward to dicking around with Objective C, which is very native to the Apple platform. So it's nice it did all that without my having to learn it. From here I'm sure I could write an FLTK app around it to do interactive cropping, playback timing for animation, etc.

    For making open source tools, it seems amazing.

    The messy shake-out of copyright I guess I'll leave to the future to figure out.
    But it sure seems like the AI freight train is coming through, and it will be writing code and managing companies, like it or not.

[Albrecht Schlosser]

On 5/29/26 13:01 Matthias Melcher wrote:

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.

I agree.

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.

We can only review the code itself (checking for quality issues) but we can obviously not check for copyright issues. See below for more.

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.

+1

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.

OK, but see below on my proposal regarding disclosure of AI contributions.

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.

+1

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.

OK, agreed.

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.

OK.

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

There may be a difference in the amount of contributed code if it is AI generated. But I'd say that it's OK if reviewed properly. We should be aware of this and don't accept code we (i.e. the team members who are reviewing the code) don't understand. It should be clarified that such code won't be accepted and PR's may be closed.

• Whether we want to ask contributors to disclose AI use (I lean against requiring it, but I am open to discussion)

I suggest that we require the user/contributor to disclose whether their contribution was generated by or with the help of AI. This should be done in the context of the issue / patch / PR and - maybe even more important (?) - in the commit message. This is intended to keep the code itself clean, while also enabling us to examine AI contributions later.

Side note: I read that Linux kernel contributions require commit tags "Assisted by ..." or similar. We could adopt this practice.

• Whether we want to say anything specific about AI in the contribution guidelines, or simply rely on the existing review standards

I propose to write or extend contribution guidelines to cover practices of AI usage so potential contributors know in advance how we will deal with such code. This should discourage unreflected usage of AI coding, since contributors will know that they can use the help of AI but they must still know what they're doing (as if it was code written by themselves). Or something like that...

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.

Absolutely YES.

@Matthias: Thanks for your proposal.