Iterate on wording related to AI Tools and Copyright infringement

[willingc]

After an extended discusssion on #880, it is clear that the sentiment about using AI tools for PR generation falls across the spectrum from "Never use commercial tools as the training source is unknown and likely includes copyrighted material." to "Commercial tools have some value in surfacing new approaches to difficult problems."

This is not an easy policy point to get unanimous agreement upon given the wide spectrum of views.

We hashed out a similar issue for the CPython dev guide (python/devguide#1778 (comment)) and haven't fully resolved this point. Though, we do have a policy that I authored 2 years ago in place. Here's my proposed suggestion on addressing this for Python (which has far more polarized views than here):

I would like to strongly word in this section that the LLMs/AI tools are software development tools not humans. An individual human is responsible for PR and issue submission as well as the quality and security of any code submitted. While AI tools may be used to assist the individual, the individual is still responsible for their submissions.

[KirstieJane]

I agree with this framing ✅

In general the framing of LLMs as a tool - nothing more, and nothing less - sits much better with me than “artificial intelligence”. They are not intelligent - they’ve been trained on billions of examples - and they are not artificial - humans created all that training material!

I think where this conflicts with the current JupyterHub (proposed, but to be merged) policy is (at least!) around the copyright implications of the tool and I’m not sure how to square that perspective with this one….

[willingc]

I do think that there was copyright infringement when training used copyrighted material.There is a reasonable probability that token from the training could be served as a response by an LLM that was trained on this material.

This is why I believe that being explicit:

• human contributor is responsible for submission
• Mention tools/models exist that openly disclose the training data
• Contributors should disclose when and which tools/models were used (this begins to build trust through transparency)
• Maintainers determine suitability of all contributions

[willingc]

I would also reframe the discussion from policy to guidance. Policy is pretty heavy-handed. It is also difficult to enforce and places the maintainer in the position of enforcer over collaborator.

Maintainers have responsibility for any PR merged into the codebase. This does not change whether a PR is 100% generated, fully human written or somewhere on the spectrum.

All PRs are not the same in scope. Maintainers, as they have years, determine whether a PR is suitable for a project.

[willingc]

I also find Angie Jones' reframing of the problem to be helpful to reduce maintainer burden: https://angiejones.tech/stop-closing-the-door-fix-the-house/