Gard Spreemann <[email protected]> writes: > Russ Allbery <[email protected]> writes: > >> Sean Whitton <[email protected]> writes: >> >>> - It clearly distinguishes including LLM output in what gets committed >>> from other uses of LLMs for software development, as I have been >>> repeatedly advocating is important, without much uptake. >> >> For the record, I also strongly agree with this distinction. Sean is not >> alone. > > I completely agree, too. And I fear that none of the ballot options > sufficiently cater to this distinction. > > Sean & Russ: How would you feel about a ballot option that bans > LLM-generated contributions, but explicitly does not opine on the > contributing human using LLM tools to e.g. debug, learn, plan, critique > etc. when creating the contribution? > > (I realize that such a proposal might be interpreted by some as forcing > those who are fine with LLM-generated code to become transcribers for > the LLM, but I hope that's a minority view and that most would > understand that that is not the intent.)
Something like: DRAFT BALLOT OPTION **Ban AI-generated contributions, but allow AI assistance** Debian neither endorses nor prohibits the assistance of AI tools, including generative ones, during the work of contributing to the project. This includes e.g. tools used for research, learning, debugging, critique, adversarial testing etc. during the creation of contributions to Debian. However, the actual outputs of these tools suffer from several problems: * Unclear copyright status. * Difficulty with quality review and future maintenance. * Unanswered questions pertaining to what the preferred form of modification is for software created this way. Debian therefore prohibits the inclusion of any AI-generated code, documentation or other content into the project.
signature.asc
Description: PGP signature
