Add AI policy to committer's guide after D54366 merged.
Details
Details
Diff Detail
Diff Detail
- Repository
- R9 FreeBSD doc repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 70046 Build 66929: arc lint + arc unit
Event Timeline
Comment Actions
Frankly, I don't think this policy is strong enough. "You are responsible" doesn't have any teeth. What happens when somebody makes a contribution that they're "responsible" for that plagiarizes from copyrighted code and/or violates a license? How is FreeBSD protected when somebody "considers" licensing and decides they don't care?
I like the proposed policy in D50650. What was wrong with it?
Comment Actions
It's the same thing we face when people copy linux drivers. It's nothing new. Responsibility lies with the tool users.
I like the proposed policy in D50650. What was wrong with it?
It was unworkable. AI isn't some binary 'one shot that produced code' but a thousand different ways that AI can help the developer. The vast majority of them are fine and pose no risk whatsoever outside the system that the AI is being run on. So banning it entirely is a non-starter. That ship has sailed. Outlining responsible use is really the only path forward today.
| documentation/content/en/articles/committers-guide/_index.adoc | ||
|---|---|---|
| 2418 | I'd add 'and haven't tested' to the last sentence even though it's repetitive. | |
| 2419 | Refining the prompt can re-introduce problems corrected in prior iterations, so check it all each iteration as best you can. | |
| 2422 |
| |
Comment Actions
It is not at all the same thing, because the risk associated with it isn't properly assigned. You can say that the person who uses the tool bears responsibility for the contribution that used it, but there is no way to assign accountability. For the sake of argument, what happens if a person's "due diligence" fails to turn up the fact that their AI-contributed code infringes on copyrighted code (perhaps because that code isn't publicly visible but was nonetheless present in the coding agent's training set; perhaps because the person just didn't do proper due diligence). Who bears legal and financial responsibility for that infringement?
I like the proposed policy in D50650. What was wrong with it?
It was unworkable. AI isn't some binary 'one shot that produced code' but a thousand different ways that AI can help the developer. The vast majority of them are fine and pose no risk whatsoever outside the system that the AI is being run on. So banning it entirely is a non-starter. That ship has sailed. Outlining responsible use is really the only path forward today.
There is no currently accepted way to "prove" that an AI assisted contribution is non infringing, and there is still significant uncertainty around whether AI assisted code can even be copyrighted at all. Accepting AI-assisted code contributions now, before a relatively stable legal framework is established around it, introduces legal and financial risk both to the project that accepts the code and to the end users of that project. I don't know how you're determining what a "vast majority" are, or how you can claim that they "pose no risk," because literally all I see is risk. Accepting AI contributions before there's a way to "prove" them is an unworkable problem.
And sure, you can say "it's good enough for IBM and Red Hat / Canonical and Ubuntu / Microsoft / Amazon" but they have vastly more resources to deal with legal, financial, or coding challenges that may later appear as precedents are established. FreeBSD is already a very small player in comparison to that landscape, and I think the potential risks are not worth the perceived value. If you think FreeBSD should accept those contributions, then before you do that you need to figure out a gameplan for how you can prove code is acceptable and copyrightable, how can pay the legal fees if you get sued, and how you can deal with the sudden absence of an accepted feature if the only way to resolve any infringement is just to yank out the change and revert to how things were before it was accepted.
Comment Actions
Maybe we should rename ai-policy to ai-note. During the many and length meetings, discussions, a "policy" cannot please everyone.
The current situation and the truth is that people are already using it, and we can't stop them. A strong "NO" will just let some people lie and pretend not using it, or worse, we lost some good contributions. A strong "YES" will cause big risk of getting lots of AI slop. Finally and unfortunately, we can't enumerate all the "YES" and "NO" cases -- after all, we should and still depends on the committer's expertise and sense to handle the final commit in a proper way. The "proper" here includes the technical and legal correctness, and not limited to them. That's probably the meaning of human in the loop.
The only thing we can do and should do is guide the good use of a new tool. The standard and the requirements to make a contribution to FreeBSD is not changed because of the existence of a new tool.
| documentation/content/en/articles/committers-guide/_index.adoc | ||
|---|---|---|
| 2418 | I guess it should be "Do not commit code you do not understand or haven't tested" ? | |
Comment Actions
I simply do not understand this argument. We can indeed not 100% guarantee that no one would commit LLM generated code if we stated an explicit policy against this.
But neither can we guarantee that no one would commit copyright infringing code, but we still have a strong policy against it.
Comment Actions
I am not saying we cannot have a strong policy against it. It's exactly like what you said: we can not 100% guarantee no one would do that. And what's worse is that it's harder to enforce it. (And in many meetings and discussions people use this reason to say we don't need a policy/note/answer/whatever.) For the copyright it's easier to examine and proof.
Please note that the meaning of the texts in this diff and D54366 is: the standard of a contribution will not be changed because of a new tool, but since it's new, there is a guide for letting contributors to avoid the pitfalls.