The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Concept ACK, makes sense, though IANAL.

Concept ACK.

The two thoughts that come to mind are that

but not limited to, ChatGPT, GitHub Copilot, and Meta LLaMA

1. This section could become a cat and mouse game between the various models and which ones of these will still have relevance in the future.

2. LLMs right now are the benchmark for text to text models but there are other types of models as well example NLP and RNN models. So this language could become obsolete overtime.

This post was written by GPT4 ... Just Kidding.

Conecpt ACK 08f9f62

I was one of the mentioned PR's #28101 (comment)

Would make sense to have this in the CONTRIBUTING.md

Sent a mail to Jess from the Bitcoin Defense Legal Fund to collect more legal opinions with the context. Normally luke-jr (luke@dashjr.org) and jonatack (jon@atack.com) are cc.

Concept ACK, but happy to wait for legal opinions. Hopefully they clarify the risks in two separate categories:

1. Content the AI obtained somewhere else without permission (i.e. claims from the original author)

2. Content the AI generated itself. Potentially owned by some corporation who didn't give permission to the person making the pull request to MIT license it.

When it comes to (1) I'm more worried about snippets of fresh code than e.g. suggested refactorings. I don't see how one can claim copyright over e.g. the use of std::map over std::vector.

When it comes to (2) in a way it's not a new risk. A contributor could already have a consultant standing next to them telling them what to write. It could then turn out the code belongs to that consultant (who didn't license it MIT) and not contributor (who at least implicitly did). But these AI companies have a lot more budget to actually legally harass the project over such claims.

ACK

The copyright lobby is pretty strong, and stands to lose a lot from AI. I think there's a significant chance that AI copyright gets resolved in favor of copyright owners in such a way that is disastrous for AI. Just look at how the copyright lobby managed to keep extending the duration of copyrights worldwide to ludicrious, economically irrational, lengths until very recently.

Also, AI poses unknown security threats. It frequently hallucinates incorrect answers. Bitcoin Core is a type of software that needs to meet very stringent reliability standards, so much so that review is usually more work than righting the code. Saving time righting the code doesn't help much, and poses as yet unknown risks.

NACK from me, because I think legal questions like this are essentially political questions, and you make absurd legal outcomes more likely to happen by expecting them to happen, and by writing official documentation which gives them credence.

If the risk is that openai or microsoft could claim copyright over parts of the bitcoin codebase, that would be absurd because their usage agreements assign away their rights to the output and say it can be used for any purpose.

If the risk is that someone else could claim copyright over parts of the bitcoin codebase, like in the SCO case (https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes), that would also be an absurd outcome, which would have bigger repercussions beyond this project, and could happen about as easily without an LLM involved.

I had the feedback from the Bitcoin Defense Legal Fund, they need more time to analyze the issue though it is thought as an important one.

I did additionally cc Andrew Chow and Fanquake as maintainers on the mail thread for open-source transparency.

I think whatever one individual political opinion on copyrights or legal risks tolerance, the fact is we have already dubious copyrights litigations affecting the project, so I think it’s reasonable to wait for risk clarification before to do a change to the contributing rules on the usage of AI / LLM tooling.

I mostly agree with @ryanofsky.

The reality is that going forward it'll be essentially impossible to avoid contributions that may include output from AI/LLMs, just because (in almost all cases) it'll be impossible to tell, unless the author makes it apparent.

We certainly don't want to end up in some situation where contributors are trying to "guess" or point out these types of contributions, or end up with reversion PRs (incorrectly) trying to remove certain content.

If we end up with an opinion from the BLDF then maybe we can consider making an addition to our license, if necessary.

 If we end up with an opinion from the BLDF then maybe we can consider making an addition to our license, if necessary.

+1. If we have professional advise to change the license or add a separate policy document or agreement like a CLA, we should consider doing that. But we shouldn't freelance and add legal speculation to developer documentation.

In this case and in general I think a good strategy is to:

• First, focus on doing the right thing morally. If contribution includes content that seems plagiarized, or not credited properly, or is not fair to someone, we should not include it.
• Second, try not to make political mistakes. Avoid doing things that would be unpopular broadly or would offend a particular group of people and provoke an attack. Avoid waving meat in front of hyenas and taking actions that could give credibility to absurd legal claims.
• Third, try not to innovate. Have a software license, follow professional advise, maybe participate in a patent network. Avoid doing things that are speculative or new and not obvious wins.

Moved to draft for now, as there's not consensus to merge as-is, and in any case, this is waiting on further legal opinions.

Agree with the intent of avoiding legal problems, but NACK on adding this text. Unless we have some kind of legal guidance saying this text would protect us beyond what our existing license-related docs say, I don't see any reason to discourage specific tools in the contributing guidelines. I agree with the above that trying to speculate/innovate can do more harm than good.

I think we should close this for now and reconsider if/when a a lawyer advises us to do something like this.

Closing this for now.