KDE's policy proposal explicitly allowed for contributors to not disclose that AI was used, which according to the FSFe and Software Freedom Conservancy, is not a good idea in legal terms.

“FOSS project leaders cannot make good decisions about LLM-gen-AI policy if they cannot survey which contributions were assisted, and how much they are assisted. Part of the contribution process should (at least) include a disclosure of what LLM-gen-AI system was used, its version (as these systems change over time), and a brief description of how the system assisted the contributor. This information should be included in a machine-readable format in commit logs."

Indeed, such disclosure can be an important foundational step to allow for the accurate assessment of the copyrightability of code that has been assisted or generated by AI tools, in order to assess their licensability into Free Software. Open and clear disclosure is a helpful step for the Free Software community to maintain a healthy licensing ecosystem, which is currently threatened by the legal uncertainties that come with the advent of generative AI.

Additionally, it is worthwhile for developers to document in some capacity the extent of human work that they have done in their software projects, whether it be the writing of code, the selection and arrangement of components within the project, or the extent of human modification of machine generated content.

Not to mention the ethical and environmental concerns with corporate AI usage, the use of which KDE was not interested in attempting to curb within its own project, which personally I think was disappointing, and even their KDE Eco group stated the policy was incompatible with the goals of KDE being a green project.

[–] bilb@lemmy.ml 3 points 1 day ago* (last edited 1 day ago) (2 children)

As far as code quality and reliability goes for mature projects like KDE and Linux, I trust the maintainers to know what they are doing. I have no place second-guessing them. If they think LLM usage disclosures are useful I believe them, if they feel otherwise I accept that as well. To me as an end user, it makes no difference. I'm not going to stop using Linux or KDE over LLM-assisted code contributions either way.

As far as copyright-ability, I could be convinced here. I'm not a legal expert at all, but it seems pretty speculative. I did read your first link, which is interesting. The legal risks as I understand them are:

A judge somewhere might say "This long-lived project has recently merged some patches which, to some unspecified and unknowable degree, involved LLM usage and therefore the GPL license indicated for this project is no longer valid. Therefore, the project is now Public Domain and it may be used and modified without releasing the changes." Seems unlikely to me, but who really knows?

and probably much more likely:

A patch is accepted that replicates copyrighted code exactly, putting an unwitting maintainer in jeopardy. I looked around for examples of open source project maintainers being sued for this sort of infringement out of curiosity, but I really couldn't find any. If this happens, I bet it's typically handled outside of court with a C&D type situation.

Are there other legal risks I'm missing? I think it's only a matter of time before some type of consensus for what the implications of the copyright questions are for FLOSS software.

[–] SapphironZA@sh.itjust.works 3 points 1 day ago

Agree 100%, whether you allow AI coding assistants or not, will depend on the nature of the team and their QA processes.

At the end of the day, we should not prohibit people from using calculators instead of doing the math themselves. So long as the outcome quality is good, and the process is efficient.

[–] ProdigalFrog@slrpnk.net 1 points 1 day ago* (last edited 1 day ago)

I looked around for examples of open source project maintainers being sued for this sort of infringement out of curiosity, but I really couldn’t find any.

Since most corporate software is closed proprietary software, there traditionally wasn't a lot of opportunities for an open-source project to even have the ability copy code, except in instances of a source code leak or perhaps the odd ex-employee. Back in the day, developers would do clean-room designs to avoid being sued for infringement. A famous example is the development of the PC compatible Compaq BIOS.

In comparison, every LLM on the market now is able to inject copyrighted code into any project, completely unknowingly to the contributor or the project. It's such a recent issue with the introduction of this technology, there likely hasn't been too many court cases on it yet.

If a FLOSS project was sued in the future over this, personally I think being able to point to a policy that completely rejects contributions from a known source of copyright infringement would give them a better legal defense compared to a project that explicitly says not to inform them of any use of a known copyright infringing tool. This is also why WINE has hard rules to not allow anyone who has ever seen Windows source code, either leaked or from working at MS, to ever contribute to the WINE project, as then if anyone submitted some source code anyway, they can point to their policy as a legal defense.