As an asbestos connoisseur (srsly?) and not a scholar of the law, even less across multitudes of jurisdictions. I'd like to posit the following:

We have roughly three categories:

1. Restrictive (various form of licenses, EULA, ...) licensing which tries to tell their users what they can, and can not do with the software.

2. Permissive (BSD, MIT, ...) which in spirit say: "Hey here's some code I'm proud of, please mention that your work was derived from this."
3. Copyleft (FSF/Gnu licenses), which kinda say: "Hey, here's some code I've created, and I'm happy for you to use it and modify it, but if you distribute, I'm putting obligations on you".

Let's assume there is some violation to any of these:

1. There is probably some body who derives significant financial or other incentives from the licensing, and as such has a strong interest in ensuring said licenses are upheld if violated.

2. This is generally the "throwing code over the fence" situation, take it or leave. If it is violated (e.g. someone didn't add the license/mention) is the author going to sue in court? The whole thing centers around an honor/honest system. Also oftentimes there are no financial incentives attached in a way that would make suing someone for said violation makes much sense.
3. This is a bit of an interesting case. There is a body (FSF) behind these, whose purpose it is to further software freedom, and the Gnu licenses are the vehicle for this. It's also the only OSS license that has seen some court cases. And there are some cases in the West from which one might be able to derive something.

Now let's assume someone contributes significant LLM generated code to these, with the assumption that this code is not copyrightable, or potentially falls under copyright violations.

1. This is a problem, as your basis for claiming copyright and subsequently enforcing licenses over code that you potentially can't claim ownership over is tricky, I guess. Legal scholars will certainly have their fun with this, with probably different outcomes across different jurisdictions.
2. Again this license mostly says: hey here is some code I threw over the wall, please include the license and attribute that I curated this code, e.g. provide some lineage.
3. For the copyleft license to work, a much stronger ownership claim needs to be made, e.g. if it is upheld that LLM output is uncopyrightable, and significant parts of the project end up with LLM generated content, the copyright, and thus validity of the copyleft license might be questionable. (How can you enforce something over something you don't own?)

This also explains why we see the stratification of LLM policies based on project philosophies, and licenses.

1. A proprietary licenses project with restrictive licenses runs the risk of inadvertently potentially including regurgitated copyleft code; which should courts at some point decide that said code is actually copyleft, might have poisoned the  codebase enough to force it under a compatible copyleft license.
2. Somewhat similar problem of potentially poisoning the project to potentially having to adapt a copyleft license. This is really only an issue if there are downstream proprietary consumers.
3. These projects really have an incentive of making sure to stay pure to be able to uphold their copyleft claims.

As we see businesses increasingly adopt LLMs in their day-to-day use--whether or not we think this is a good idea--they have a clear incentive to lobby for laws that do not poison their codebases and invalidate their licenses. Similarly for the LLM providers have similar incentives to make sure that the product they sell is compatible with the consumers they are trying to sell their product to. Given that lawyers and lobbying is a rather expensive endeavor, I strongly suspect that we'll see judgements similar to the non-copyright for purely LLM generated output, and human authorship going to play a central role in the US. This of course is just my prediction, not legal advice, given my experience as an asbestos connoisseur.

This also seems to be reflecting in the LLM policies we see emerging:

1. corporations seem to make the judgement call that values LLM use above legal risks.  And I think they generally have their own legal counsel involved in these decisions. In many corporate settings the use of LLMs seems to be permissible at this point. Restrictions on LLM providers may exist, and some providers offer indemnification in their enterprise offerings.
2. Permissive projects seem to be more relaxed in their LLM policies and mostly focus on the project's culture without being overly prescriptive. Generally seemingly leaning towards human authorship.
3. copyleft projects feeling the need to protect their purity to continue upholding their license claims going forward.

There are of course projects in group 2, and group 1 that also opt for less permissive LLM policies for various project reasons.  I believe however, on the whole, we do see more restrictive policies from copyleft projects compared to more permissive licenses projects, reflecting a somewhat different understanding of the project's identity around its code.

A rather extreme take and thought experiment then is: shouldn't copyleft licensed projects campaign for excessive LLM use in permissive licensed projects, while being very strict about LLM use in their own codebase? This might later open up the claim that substantial portions of copyleft code ended up in other projects, and as such those would have to be relicensed under copyleft licenses, if these claims hold up in court. Therefore if the idealized goal is to make every software free software, not using LLMs oneselves but promoting their use, while hoping for favourable legal outcomes seems a viable although risky strategy.

I think the counterpoint to this applies to a permissively licensed project like GHC (as Andreas also outlined), the risk is mostly getting infected by copyleft code enough to force a relicensing under copyleft terms.

Ultimately I think the whole licensing topic is very interesting, yet seems to be a different dimension to the questions concerning guidelines and acceptable behaviour around contributions, the initial policy tried to address.

As far as I see we have legal, behavioural and ethical/philosophical/ideological concerns around the use of LLMs. I think we would probably do well to separate them out to address them, rather than lumping them together, which is where misunderstandings happen. I don't think there is a natural correlation between these dimensions. I also believe each of these dimensions should be taken seriously. What the conclusion will be, I don't know; it could be that an additional policy, or mission/identity statement, or license or ... will be the end result.  The more precise and clear our policies are, the better it will be for the project. Solving something indirectly or by proxy will only lead to uncertainty, confusion, relitigation and debates.

Best,

 Moritz