I was trying to imagine what a "middle ground" proposal might look like if it were to exist and I got a glimpse of it when I saw GCC announcing its own AI policy [1].
>The GCC steering committee has announced <https://lwn.net/ml/all/CAGWvny=kzcazorvmcu3gdt4dbcmjm6s_769ne+atfbo_nz_...@mail.gmail.com/> that it has accepted an AI contributions policy <https://forge.sourceware.org/redi/gcc-wwwdocs/commit/4d0793a6a14bf9bfe9e92ac1599840780355199d> recommended by >the GCC AI policy working group.
>The policy, in part, states that the project will decline any ""legally significant contributions which include LLM->generated content or are derived from LLM-generated content"". It uses the definition <https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant> of "legally significant" >from the GNU Project maintainer guidelines, which holds that the threshold is ""around 15 lines of code and/or >text"" to qualify as significant for copyright purposes. GCC maintainers may, however, choose to accept legally >significant test cases that are generated by an LLM.
>The policy does not forbid use of LLMs for research, analysis, bug discovery and reporting, patch review, etc. as >long as the output is not included in contributions. The committee says that it expects the policy will evolve and >will be revisited periodically.
I feel like a similar proposal (maybe Proposal F) could focus on something similar:
" Allow LLM usage only for research or understanding purposes but forbid any of that work from being directly materialised into code or documentation (copy pasting). "
This way we can not only limit the usage of LLMs in the project but also avoid DFSG compliance issues because the code must be written by humans.
I personally feel like allowing LLM usage directly in the project would only result in more unmaintainable codebases, poor quality packages and a technical debt that will be a burden on new contributors as they may not be actively interacting with mentors for help. We're already dealing with several occurrences of server downtime because of the clankers and some vibe coded debian packages lying out there in mentors.d.net.
On the other hand, we're way past the point where we can just block the usage of LLMs completely because to be honest, despite being an anti-LLM person previously (I still am but not very aggressive), I found them to be of some use when dealing with problems where there's a lack of documentation or little resources online but when it comes to code, they still do a horrible job. We need to focus on maintainability too and LLMs are bad at that.
A good way forward that I personally see is actively discouraging LLM usage but not outright banning it completely and ensuring that the final work is human written even though there might be some LLM assistance with research or understanding errors.
I do not have voting rights yet so I just thought I'd raise my point of view about this GR.
[1] https://lwn.net/Articles/1086041/ -- Regards, Aryan Karamtoth, Debian Maintainer "Sic Parvis Magna" - Sir Francis Drake Homepage:https://spaceports.in IRC: spaciouskarter78 Matrix: @spaciouskarter78:matrix.debian.social GPG Fingerprint: 7A7D 9308 2BD1 9BAF A83B 7E34 FE90 07B8 ED64 0421
OpenPGP_0xFE9007B8ED640421.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
