I think the main problem with this is that you can be paid/coerced to vote for someone and be able to easily prove that you voted for the person they wanted. It’s easier to vote for the person you actually wanted to vote for, and maintain plausible deniability, if you go in person to a voting booth.

The unfortunate reason this isn't doable in the US anyway, and any time someone has a great idea on how to improve elections this inevitably comes up: preventing coersion. It's difficult to balance transparent voting with ensuring that you can't prove which way you voted in exchange for money or favors.

For something like voting on decisions for some open source project, sure.

For actually voting on representatives it would be an absolute disaster.

> I understand there might be a lot of reasons for why it could fail in practice, but it would be a start.

For a start this would make bringing in tens of thousands of mail-in ballots at the last seconds to tip a state's vote in your favor much harder to pull off.

So some people (those planning to rig elections) are going to be against this.

Neither choice 7 nor 8 attempt to forbid packaging of any upstream project with LLM contributions like the kernel.

Choice 7 says "The proposal does not cover indirect contributions, i.e. those originating from upstream works.". It's only making requirements on Debian work specifically.

Choice 8 says "We also acknowledge that LLM usage can be hard if not impossible to detect and that Debian as a distribution cannot really impose LLM policies on other projects we package and distribute. Therefore this text is just a position statement." It doesn't impose any requirements at all on anybody, even for debian specific work: it just says "we'd prefer it if you don't use this technology".

Well, they could try to prove the correctness of that LLM-based kernel code.

If it passes, then they could use it, no?

This is the way general resolutions in Debian generally work. There's a lot of pre-vote discussion where different people and groups propose and draft their preferred options, to produce what they feel is the best expression of their position. If you can get enough seconders for your proposal it goes on the ballot, with the text you chose and your seconders agreed with. There isn't any requirement for the options to use consistent terminology or avoid overlap, and no overarching editorial process to impose consistency (which would be tricky anyway in cases like this where terminology choices and overall framing can be part of the disagreement between people.)

> Sounds like several people wrote them and did not agree on the form

Of course several people wrote different position statements to vote on.

Did you expect one Debian developer to cook up half a dozen possible stances he is not even personally invested in? Are you constantly surprised that election programs of different parties are worded differently (and use different fonts)?

Yes, and I'll be waiting patiently for some AI-slop Rust port of Debian to gain any traction.

Any day now.

I am not saying if they should or should not accept AI contributions, but this sort of comment misses the point so hard that is laughable.

Copyright IS an issue to Debian, and always has been for the last 30 years or so. They are, rightfully so, extremely picky when it comes to respecting copyright and licensing. It is the 0.01%.

> Who the f*ck cares who made it? A monkey could have made it for all I care. If it does what it claims to do, and I understand how, it's all good.

Copyright laws do care. As an example one can send a patch claiming its their own but because they had do it under their employer duty, the copyright might well be associated to their employer rather than them individually. Does the patch does what it claims to? Surely. Is that a copyright infringement? DEFINITELY SO.

The copyright rationale for the first proposition (Choice 1: Ban LLM contributions from Debian via Social Contract):

> 1. Copyright

> -------------

>

> LLM output has very unclear legal status: it may be possible to copyright on its own merits, or not; it may be affected by all of the licenses and copyrights in the training data, or not.

> Debian Policy and the DFSG require absolute clarity for licensing and copyright[1][2]. Software and other contributions written conventionally by humans with unclear copyright or license status are not allowed in Debian; LLM output should not have a special exception to this.

This rationale states if there is doubt about the copyright of the code, it not suitable for inclusion. Until I guess LLM output get a clarification regarding who is the author of its output.

> No, the copyright issue is nonsense

This is wishful thinking for any project of Debian’s size. You not wanting to deal with it doesn’t mean that people won’t get sued.

Funding for the 100,000th vibe coding startup is running out?

It sounds like you would be in favour of Choice 5.