no llm code

Lobsters Hottest News

Summary

git-annex announces a policy to exclude LLM-generated code from its project due to copyright uncertainties, and provides a build flag to avoid dependencies that include such code.

<p><a href="https://lobste.rs/s/4h3zn9/no_llm_code">Comments</a></p>
Original Article
View Cached Full Text

Cached at: 07/03/26, 02:18 AM

# no llm code Source: [https://git-annex.branchable.com/no_llm_code/](https://git-annex.branchable.com/no_llm_code/) [LLM](https://en.wikipedia.org/wiki/Large_language_model)generated code in free software is a potential landmine\. The copyright of such code is an open question, and any current answer to that question risks changing at some point in the future\. This is a particular problem for git\-annex since[future proofing](https://git-annex.branchable.com/future_proofing/)is an important aspect of its design\. So, git\-annex does not contain code generated by LLMs and guarantees it will never do so\. However, libraries and other things that git\-annex depends on do not generally have such guarantees\. Although it would be very much appreciated if they did\. git\-annex currently supports being built with versions of dependencies that pre\-date any introduction of LLM generated code\. To do so, turn on the`NoLLMDependencies`build flag\. When building with stack, use`stack\-NoLLMDependencies\.yaml`\. \(It is not currently built that way by default, but such builds are welcome\.\) Unfortunately, it's not possible to guarantee that will continue to work in new versions of git\-annex\. That's the goal, but it may become untenable\. See below for details about possible future problems with specific dependencies\. Note that if a security hole is only fixed by a newer version of a dependency, the`NoLLMDependencies`build flag will still build with the older, insecure version\. Additional work needs to be done on an ongoing basis to review git\-annex's dependencies to detect the addition of LLM generated code\. Help with finding these is welcome\. Please edit this page and/or file bug reports on git\-annex if it cannot be built without LLM generated code\. ## known dependencies that contain LLM generated code 1. [ghc](https://git-annex.branchable.com/no_llm_code/#index1h3) 2. [ram and its reverse dependencies](https://git-annex.branchable.com/no_llm_code/#index2h3) 3. [persistent](https://git-annex.branchable.com/no_llm_code/#index3h3) 4. [yesod](https://git-annex.branchable.com/no_llm_code/#index4h3) 5. [Cabal](https://git-annex.branchable.com/no_llm_code/#index5h3) 6. [git](https://git-annex.branchable.com/no_llm_code/#index6h3) ### ghc [This commit](https://github.com/ghc/ghc/commit/a5ec467ee3d4e77c026437a545981269acde3434)is probably the first, and will be released in the upcoming ghc 9\.15\. git\-annex remains buildable with older versions of ghc back to 9\.6\.6\. This will probably prevent git\-annex from taking advantage of most new improvements to the Haskell language going forward\. That is deeply unfortunate\. This is the main reason why git\-annex is not guaranteed to never change to depend on LLM generated code, because cutting it off from all future Haskell language improvements may be worse than the alternative\. ### ram and its reverse dependencies [ram](https://hackage.haskell.org/package/ram)since 0\.21\.0\. Note particularly[large LLM generated code churn](https://github.com/jappeace/ram/commit/3a0c034648f1cb7e60e96a681fd74066ff5944fe)with apparently broken \(how?\) changes in 0\.21\.0 being reverted in 0\.21\.1\. Rather than use ram, git\-annex continues to use the unmaintained[memory](https://hackage.haskell.org/package/memory)that ram was forked from\. But ram is an dependency of other dependencies, and these in particular depend on 0\.21\.0 or newer: - crypton since 1\.1\.0 - tls since 2\.3\.1 [Reverse dependencies of ram](https://packdeps.haskellers.com/reverse/ram) The`NoLLMDependencies`build flag depends on an older version of ram in order to prevent such dependencies using the newer version\. ### persistent [persistent](https://hackage.haskell.org/package/persistent)since 2\.15\.0\.0 [First LLM generated code](https://github.com/yesodweb/persistent/commit/ac0a8698f38ae3b07acdacf0ce236d7fc73bb077) git\-annex supports being built with older versions\. ### yesod [yesod](https://hackage.haskell.org/package/yesod-core)since 1\.7\.0\.0 [First LLM generated code](https://github.com/yesodweb/yesod/commit/1b033c741ce81d01070de993b285a17e71178156) [LLM generated commit with a 1489 line commit message](https://github.com/yesodweb/yesod/commit/1ee25122d82f8f94136bf1496a825c6c00b74fcf)and 10,000\+ lines of changes\. \(See[ditch yesod](https://git-annex.branchable.com/todo/ditch_yesod/)\) ### Cabal [First LLM generated code](https://github.com/haskell/cabal/commit/da8b314563feb15a3df7bc1baeef4b7aa08f7578) Cabal is needed to build git\-annex, but is not linked into it\. There is a risk that a new version of Cabal could need changes to git\-annex\.cabal that prevent an old version building it\. ### git Since 2\.53 [First LLM generated code](https://github.com/git/git/commit/d7971544fe17378f44f49983010dbfc1834f7bef) git\-annex supports git back to 2\.22\.

Similar Articles

No LLM Code in Dependencies

Hacker News Top

The git-annex maintainer details efforts to remove dependencies containing LLM-generated code, expressing concerns about code quality and ethical implications.

NLNet Labs LLM Policy

Lobsters Hottest

NLNet Labs announces a policy restricting the use of LLMs in code and documentation contributions, requiring disclosure of LLM use and prohibiting AI-generated code.

General Resolution: LLM usage in Debian

Lobsters Hottest

Debian is holding a general resolution to decide whether to forbid contributions made with LLMs or generative AI, citing copyright and quality concerns.

Protecting our FLOSS commons from LLMs

Lobsters Hottest

Codeberg e.V. members voted to forbid using user data for LLM training and to prohibit 'vibe-coded' projects, citing harms to the free software ecosystem.

LLM Agents Can See Code Repositories

Hugging Face Daily Papers

This paper presents the first systematic empirical study of using visual repository representations to enhance LLM-based coding agents, showing that integrating visual graphs as a supplementary modality reduces token consumption by up to 26% while maintaining or improving issue-resolution accuracy.