How should a review handle the licence and provenance of generated code while the law is unsettled?

## What is actually unsettled Several different questions get compressed into "is generated code safe to use", and they do not have the same answer: - Whether output that no person authored attracts copyright protection at all. - If it does, who holds it - the person who prompted, the operator of the tool, or nobody. - Whether output that closely resembles material in the training corpus can infringe the rights in that material, and what "closely" would mean. - What the terms you accepted when you used a particular tool say about all of the above. These are moving, they differ between jurisdictions, and the last one is contractual rather than statutory. **Teach and answer this as unsettled**, because a candidate who states it as settled law in either direction is the one being screened out. That is true of the optimistic version ("no person wrote it, so it is free") and the pessimistic version ("it is all derivative") alike. ## Why a reviewer must not rule on it A code review is the wrong forum for a legal judgement, for three reasons that have nothing to do with the reviewer's competence: the question is jurisdiction-sensitive and the reviewer does not know where the code will ship; it is fact-specific in a way a diff does not reveal; and an answer given in a review thread binds nothing and is never seen again. The review's job is to **notice and route**, not to decide. The corollary is that the team needs a decision made **once**, at policy level, with whoever owns legal risk. If the reviewer has to invent the answer, the standard has failed. ## The shapes worth flagging Small idiomatic code is not the interesting case, and treating it as one makes the whole line unusable. What is worth stopping for: 1. **A large, self-contained, distinctive block** that does something specific and complete, rather than glue fitted to the surrounding code. 2. **Attribution debris.** A licence header, a copyright line, a distinctive comment in a different voice, or a stray reference. These are worth asking about precisely because they are the only free provenance signal anyone will get - and the wrong response is to delete the header and merge, which changes nothing about what the code is while destroying the evidence. 3. **A named algorithm or a recognisable implementation** that a person would normally have obtained from a specific place. 4. **Configuration, data files and long fixed text** copied in whole, where the question of origin is starker than in code. ## Recording provenance while it is cheap Nobody will maintain a full audit trail, and a scheme that asks for one dies on volume. The cheap, high-value slice is narrower: **for a substantial block a person did not write line by line, note that at the time**, in the change description or a commit trailer. The purpose is modest and worth stating plainly - that a question months later has *an* answer rather than a shrug. It is a memory aid with known gaps, not a control. ## Scaling the bar to the surface The durable policy axis is not the tool and not the jurisdiction; it is what happens to the code afterwards. | Where the code ends up | Why the exposure differs | A reasonable bar | |---|---|---| | Internal tooling, never distributed | Nobody outside receives a copy | The ordinary review | | A product shipped to customers | Copies leave the building | Flag distinctive blocks; policy decides | | An open-source release | Relicensed onward under your terms | Highest bar; legal sign-off on the policy | | Contract work delivered to a client | Obligations you signed up to | Whatever the contract says, checked first | This is a risk gradient rather than a legal claim, which is exactly why it stays usable while the law moves. ## How to talk about it The shape of a good answer is: name the uncertainty, name the decision-maker, name the posture, stop. Say that it is unsettled and jurisdiction-dependent. Say that the reviewer routes rather than rules. Say what your team does anyway - flag distinctive blocks, record cheap provenance, raise the bar for redistributed code. **Do not cite a case, a statute or a ruling**, and be openly suspicious of a half-remembered one; a confident citation is the fastest way to be wrong in front of someone who knows the area. One neighbouring subject stays out of this answer: what may be pasted *into* a tool from a proprietary codebase is a separate policy question about data leaving the building, not about the licence of what comes back. ## What an interviewer is listening for Calibration, mostly. They want to hear that you know the question is open, that you do not pretend to resolve it, and that not resolving it has not stopped you from having a workable posture. The answer that fails is not the wrong legal opinion - it is any legal opinion, delivered confidently, by someone whose job was to route it to the person who owns it.