On 3 Aug 2026, at 15:37, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
Dear Pierre,
thanks for starting the discussion. And great to hear the improved numbers for mirage-qubes-firewall/GSO.
Likewise, this is very encouraging! So now we're only roughly half the performance of Linux \o/
Although there is still a lot of work to do to improve the bandwidth, it's not on the GSO path any more.
The 'bad' thing, leading to this email, is that across the branches for mirage-xen, mirage-net-xen, mirage-nat and qubes-mirage-firewall, some (a lot of) findings and code were produced using Claude Opus 5 as a 'rubber duck'. I tried to be explicit in the commits about the help I got from it, from findings to co-authorship, and I want to convey that, even if I've done a lot of work before, I would not have been able to finish so quickly without that tool. It really helped me a lot for tracking issues in pcaps, comparing packets byte by byte, finding references in the Xen or Linux sources, etc.
So my question about this work is whether the way I disclosed it in the commits the right granularity? Especially, when Claude Opus is credited with co-authorship (e.g. the mirage-xen PR [3]), it means the code was written by the tool and reviewed by me, I cannot guarantee that the same code does not exist in another repository, possibly under a more restrictive licence.
From my point of view, the first item is crucial: be transparent (as you are) about the usage thereof. Review all the changes in detail, and figure out whether that is the way to go or there would be some other way (which also means, be open for constructive feedback on PRs). The license issue is a real one, where I don't have any clue about. If the first point - you reviewed and now own the code - is done extensively, it shouldn't be a thing to re-implement the solution you saw with your own fingers -- but that certainly won't solve the licensing in any way (since it is not a clean-room implementation). I wonder what a good strategy is? Maybe other people who use AI a lot have some ideas about it? All I can tell is that last Friday in Germany some AI music generator lost in court against real musicians -- so the AI generated music violates copyright. I believe the same will be in the future being adapted to software and copyright. And obviously, using AI to find references, compare packets, ... is an ok utilization - as long as you agree to the terms and impact (to climate, politics, strengthening bigtech companies, likely more) of AI. [To make it transparent, I never used AI, and I don't plan to use any for writing code. If you're interested about some reasoning, I find the article https://superrr.net/en/blog/about-ai-and-unlikelihood very interesting, with lots of useful links. If you're more of an audio person, https://techwontsave.us/episodes also has tons of interesting episodes.] I am happy to review your PRs, and am not so happy to review random passing-by PRs which are heavily done by AI without any manual review (as https://github.com/mirage/mirage/pull/1647).
My very quick 2c is that I largely agree with Hannes:
- I recommend not putting Claude Code as a coauthor, but instead ensuring that you've read through everything and are willing to standup for it. I generally follow the SF Conservancy guidelines here ( https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html) which keep an eye on the legal status here, but generally speaking following the existing project licensing and being judicious in your inputs seems to be the best we can do right now.
- I'm hopeful in the future we'll have a high quality fully open model (like https://www.apertus-ai.org/, for which a new version is forthcoming I'm told).
- I'm happy to review Claude generated PRs from people I know like you, and I'm interested in the performance of the Xen backend again recently since I'm running it in my home router as of a month ago after several years of not running Mirage/Xen in production...
More generally, it's clear that LLM-assisted programming is here to stay, and every community is going to have to (painfully) adapt, so being open and transparent is the best we can do. Everything is changing, everywhere, and all at once :-)
-anil |
