Re: [Hamlib-developer] The use of LLM generated code in Hamlib (long)

[Mikael N. <mik...@fa...>]

Hi all!

Regarding the AI / LLM code generation discussion, Nate summarized my thoughts well here:

> I do think the licensing aspect is an important consideration. I do trust that you and Terrell are taking the time to test the LLM code against an actual radio and working out any bugs. Perhaps, other than generic programming concepts, Hamlib code is so specialized that an LLM can only train on Hamlib and thus is just spitting Hamlib code right back to you and if so, there wouldn't be a licensing issue.

I really do not think licensing is an issue because of the very specific area of expertise required for Hamlib development. Using AI agents is very close to just Google searches and Stack Overflow usage for generic constructs, like Nate mentioned.

However, what I'd like to emphasize is that I'd encourage all Hamlib developers to actively review and **clean up** any code generated by AI agents. IMO we should strive for code that looks like a human wrote it, making it readable. This also means we should document the code where it needs to and, more importantly, remove any excess comments, inconsistencies and historical details (about code what _used to be_ there) that many AI agents tend to write.

We saw some examples of this phenomenon in PR #1961 - but now it's more or less all cleaned up. 👍 

I think the goal in any software development should be to produce the least amount of code and documentation to allow other developers to easily understand the purpose and internal logic of a piece of code. This is why the clean-up phase after using AI agents is essential.

Nate and others: Maybe we could incorporate some of this into HAMLIB.developer file instead of an "absolute ban" of AI agents?

73,
Mikael OH3BHX

On Mon, Dec 22, 2025, at 18:52, Nate Bargmann wrote:
> Jeremy Box posted this to GitHub pull requests 1826 and 1961:
>
> ----- Forwarded message from Jeremy <not...@gi...> -----
>
> Date: Mon, 22 Dec 2025 07:14:40 -0800
> From: Jeremy <not...@gi...>
> To: Hamlib/Hamlib <Ha...@no...>
> Subject: Re: [Hamlib/Hamlib] Added Yaesu FTX-1 Support (PR #1961)
>
> jeremybox left a comment (Hamlib/Hamlib#1961)
>
> Just returning from vacation and seeing the flurry of activity here.  I
> don't know what the appropriate forum for this question is, so if this
> isn't it, please redirect me, but I was just rereading the
> https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer
> file again and I came across the LLM section starting here
> https://github.com/Hamlib/Hamlib/blob/2805dc5ed66412f80e008650169d5d78f2a94cb1/README.developer#L517
>
> My initial commit for the ftx-1 code started with taking the existing
> 991A code, and trying to iteratively get the functions to work on my
> FTX-1.  When coding I do use a LLM tool in my IDE to assist while
> writing my code, and so some of the code that I contributed was assisted
> with a LLM with the intent of staying as close to the existing
> format/style of hamlib code as I could, but it was not 100% hand written
> by me.  This new PR similarly looks extremely LLM driven, and I don't
> know where that leaves us on actually wanting to use either my or this
> code at all based on the current wording and intent of the README.  As
> it is mentioned that we are using the 'honor system' for this, I don't
> know what the appropriate path foward is, but wanted to raise it before
> further work was done either by myself or Terrell that is not acceptable
> for this project.
>
> This is in no way intended to detract from either of our respective
> contributions, as we were both I'm sure just eager to try to get FTX-1
> capability into hamlib for anyone who hjas this radio, but I again am
> not clear on the proper process here or what the 'right' thing to do is.
> I find using a LLM assistant extremely valuable in speeding up my coding
> output, and handling boring 'chores' in coding, but I do understand the
> reasoning behind, and respect that the project has specifically asked
> not to use them.  Now that I am aware of this, I will be pasting this
> same comment into both my existing accepted PR and Terrell's outstanding
> one, and encourage discission on the more active PR
> https://github.com/Hamlib/Hamlib/pull/1961 unless there's a better place
> to bring this up.  Perhaps the 'right' way to solve this is to roll back
> my PR entirely, and then work together to commit (by hand) working code
> for this radio?  I don't really know.
>
> ----- End forwarded message -----
>
> Here is the section of README.developer that I added a few months back:
>
> 1.5. A word about AI
>
> Over the past several years the latest rage is so-called Artificial
> Intelligence, a.k.a. Large-language Learning Models (LLM).  Companies are
> pushing using AI for development.  GitHub (owned by Microsoft) seems to be
> pushing "Copilot" at every turn.  Many thoughts about this technology exist
> among Free Software developers.
>
> Perhaps the most questionable aspect of LLM generated code is licensing--can
> such code be licensed under the GPL/LGPL?  It's not an easy question to answer.
> Code that is written by a developer is copyrighted by that developer, presuming
> it is original work.  That does not change even when code is collaboratively
> developed and held in a common repository.  Ostensibly, the developer has
> written the code and not plagiarized that of someone else without due credit
> (certainly, it is fine to "borrow" code from compatibly licensed projects, just
> credit the project/authors and disclaim it is your original work).
>
> The question leads to another question, did the LLM have access to sources that
> were licensed under an incompatible license?  Could this lead to a copyright
> infringement issue?  At this time LLMs don't seem to reveal their learning
> sources and Copilot likely has access to closed sources that are hosted at
> GitHub.
>
> The Hamlib project accepts contributions on the "honor system".  It is implied
> that contributions are the original works of their respective authors and
> offered under the license terms of the GPL 2.0 or LGPL 2.1.  Use of LLM
> generated code breaks this model.  The contributors of such code cannot claim it
> as their own original work.
>
> Finally, Hamlib is a hobby project for hobbyists and as such all contributors
> should take pride in having their original work included for the benefit of many
> other radio hobbyists.  Against that backdrop, using LLM generated code seems
> like cheating.
>
> --------------------------
>
> I added the following reply to GitHub PR 1961:
>
> Jeremy,
>
> Those are my thoughts and my thoughts alone. I am certainly willing to
> revise them if other contributors think I am being to rigid. I
> understand the speed and ease LLMs provide to developers. Maybe I'm
> stuck a bit in the "hard way" mold. Perhaps this brave new world is just
> beyond my comfort zone.
>
> I do think the licensing aspect is an important consideration. I do
> trust that you and Terrell are taking the time to test the LLM code
> against an actual radio and working out any bugs. Perhaps, other than
> generic programming concepts, Hamlib code is so specialized that an LLM
> can only train on Hamlib and thus is just spitting Hamlib code right
> back to you and if so, there wouldn't be a licensing issue.
>
> I'd be lying if I tried to state that I've not used search engines over
> the years to get a lead on something I seek to accomplish. Often times
> this led to a manual excerpt or code snippet from another project that
> sparked an idea. I think we all do that. LLMs seem to be that capability
> on steroids!
>
> ---------------------------
>
>
> I want to add that I don't want to stifle development.  I'm stuck in a
> quandary of how to proceed with PR 1961 and would appreciate guidance.
>
> 73, Nate
>
> -- 
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
>
> Attachments:
> * signature.asc