The NetBSD Foundation announces a new development policy: code generated by a large language model or similar technology (e.g. ChatGPT, GitHub Copilot) is considered corrupted (i.e. whose copyright is unclear, which does not meet NetBSD’s licensing goals) and cannot be shipped to to NetBSD.
NetBSD is a free and open source Unix operating system based on the Berkeley Software Distribution (BSD). It continues to be actively developed and is available for many platforms, including servers, desktops, portable devices and embedded systems. The NetBSD project emphasizes code clarity, careful design, and portability across many computer architectures. Its source code is publicly available and under a permissive license.
The NetBSD Foundation announces a new development policy: code generated by a large language model or similar technology (e.g. ChatGPT, GitHub Copilot) is considered corrupted (i.e. whose copyright is unclear, which does not meet NetBSD’s licensing goals) and cannot be shipped to to NetBSD.
The following commit directives define project standards for committing to the source tree:
1. Submit only the code you know.
If you are not sure whether the code you plan to submit is acceptable (for example, when you take code submitted with a problem report), ask a developer familiar with that part of the system to review it. If you are new to the project, please contact your sponsor.
2. Don’t commit broken code to the repository.
If you submit code that you didn’t write, check that the license for that code allows import into the NetBSD source repository and allows free distribution. Check with the author(s) of the code, make sure they are the only authors of the code, and check with them that they haven’t copied other code.
Code generated by a large language model or similar technology, such as GitHub/Microsoft’s Copilot, OpenAI’s ChatGPT, or Facebook/Meta’s Code Llama, is considered broken code and may not be shipped without prior written approval from the core.
3. Do not send code from foreign trees.
Do not submit code from a tree downloaded from anywhere other than cvs.NetBSD.org. Note that all developers have access to the private service rsync-over-ssh at cvs.NetBSD.org.
4. The more intrusive your changes are, the higher the level of pre-approval required.
- “Obvious” corrections may be submitted without prior discussion or revision. (The definition of “obvious” in the draft GCC is: “not capable of raising objection from anyone.” This definition is adopted here)
- All other repairs (ie “non-obvious” repairs) should be inspected.
- Implementation of new (significant) features requires prior discussion on the appropriate technical mailing list.
- Adding a completely new package (eg openldap) requires prior discussion on the mailing list and kernel approval.
5. Only release code that you’ve tested.
Verify that your code works as expected by compiling and running the code affected by your change using your system’s tools. If you edited the man page, check that groff/nroff creates the formatted man page you expect.
For normal commits (to the trunk), test that your code runs on -current. Before requesting a pull to a branch, test the changes you will require to be relinked on the appropriate release branch.
Run all relevant tests from /usr/tests or ideally the entire suite of tests. Automated test logs are currently available. Long-term regressions (compilation breaks or test failures) are not acceptable and the changes that cause them will be rolled back if the regressions are not fixed.
6. Group commits that are part of the same patch.
Rototiling a make variable that affects 50 Makefiles should result in listing for all of them together.
7. Every commit should be a patch/fix/addition/etc. spar.
Don’t fix 3 bugs with the same commit and turn it into “Fixed a few bugs”. Fix one, test, validate, clean, repeat. This makes life immensely easier to push fixes as often not everything is applicable to a particular branch.
8. Do not confuse feature or bug fixes with spacing or layout updates.
Do them separately (besides the general requirement that changes be made in a way that it’s easy to distinguish what each fix did, as described in point 6, there will be problems with escalation with heavily modified files from trunk->branch when mixing whitespace with feature fixes).
9. Clearly document the reasons for your changes in the delivery log.
Describe in some detail what has changed and why. This doesn’t have to be a code/how-to review, but it should be informative for someone reading the journal and considering the problem in 6 months. The focus should be on the “why” since the target audience reading the newspaper can usually understand the “what” by looking at the differences.
If your change fixes the PR, document it with an appropriate message. Using the “PR category/bug-id” template in your edit will also add it to the appropriate issue report in the bug database.
10. Give appropriate credit.
If you are submitting code that was submitted in a PR, please give proper credit.
11. Do not revert another developer’s changes.
If you disagree with another developer’s commitment, don’t overrule it yourself. Contact another developer and explain the problems you are having with the listing in question. Ask another developer to undo the changes instead of doing it yourself.
Source : NetBSD Commit Guidelines
and you
What are your thoughts on this new directive from NetBSD?
See also:
Code Review: A 5-step guide to making your colleagues hate you, Mensur Duraković