Intellectual Property, Open Source and Sovereignty in the Toolchain

All courses / AI Developer / Module 5 / Chapter 26

Learning objectives

After the lesson the participant can:

Explain why the human contribution to generated code is the thread on which ownership hangs, as the chapter reads Directive 2009/24/EC
Classify the four routes by which licence contamination arises and name the two layers of detection
Review what the cited litigation does and does not settle for an organisation using a coding assistant
Draft a toolchain dependency and exit record with a tested alternative and an evidence age

Key concepts

Authorship of generated code: Directive 2009/24/EC protects software that is its author's own intellectual creation, so the human contribution is what ownership depends on, and no court in the Union has ruled on the point for code. The practical step is a provenance record where exclusivity matters and contract terms for consultants and suppliers.
Licence contamination: The arrival in a codebase of code whose licence terms the organisation cannot or will not meet. It arises by reproduction by the model, by a dependency an assistant or agent adds, by code pasted in by a person, and by code leaving the organisation.
Litigation as signal: Public cases do not settle what the organisation should do, and a single first-instance judgment is not the law. None of the four cases the chapter reads decides that an organisation using a coding assistant infringes, or that it does not.
Exit tested: An exit route that has never been used is a hypothesis. The test for a coding assistant is small and carries no risk to production: run held-out tasks on the alternative against a gate, record the result with an age, and record a failed test as failed.
Toolchain dependency and exit record: The chapter's artefact: dependencies by layer (editor, assistant and model, agent runtime, gateway, registries and key libraries, compute), each with a named owner, an exit route, a tested alternative and a review date.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

Instruments behind rights and dependence

Match each instrument to what the chapter says it provides. The readings are the book's own, not legal advice.

Interactive exercise 2 · Scenario

The exit test missed its gate

Apply the chapter's rule for testing an exit route from a coding assistant.

Teaching plan

15 min	Lecture on copyright in generated code and on who owns what the team commissions from consultants and suppliers, framed as the book's reading and not a ruling.
15 min	The teacher presents the four routes of contamination and the illustrative licence policy LIC-HM-DEV-01, then the four cases as signal.
10 min	Short input on maintainers' load and on providers that retire models on their own schedule; participants name their most critical dependency with the fewest maintainers.
25 min	Exercise: groups record the dependencies of their coding toolchain with an exit route and a tested alternative.
10 min	Comparison of the two worked examples: Nordvik's exit test that failed its gate and Hansa's that passed within stated limits.

Discussion

Nordvik Region's second model scored 0.86 against a gate of 0.90 and the record says so. What does an organisation gain by recording a failed exit test as failed?
Self-hosting changes the dependency and does not remove it: seven engineers own the serving stack. How would you weigh that concentration against a provider's retirement schedule?
The dependency record asks how many maintainers a critical dependency has and what the organisation does to support it. What would an honest answer be for your stack?

Written exercise

Exercise · 25 minutes

A toolchain dependency and exit record

Record the dependencies of the coding toolchain of your team, or of the assistant NR-DEV-001 at Nordvik Region. List them by layer: the editor and its ambient features, the assistant and its model, the agent runtime, the gateway, the package registries and the open-source libraries that matter, and the compute. For each, name an owner, what the contract or licence says about training on your code and notice of model changes, the exit route, and whether an alternative has been tested, with the result, the gate and the date. For one critical library, record the number of maintainers and who reads its security advisories. Mark every exit that has never been tested.

Deliverable: A one-page dependency and exit record by layer, with owners, exit routes, test results with dates, and untested exits marked.

Your work

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

Which of the following is one of the four routes of licence contamination the chapter lists?
Show the answer
C. A dependency that the assistant or agent adds, with its licence
The four routes are reproduction by the model, a dependency the assistant or agent adds, code pasted in by a person with unknown origin, and the organisation's own code leaving.
What does the chapter conclude from the four cases it reads under litigation as signal?
Show the answer
B. None decides that an organisation using a coding assistant infringes, or that it does not
The chapter warns against presenting a single first-instance judgment as the law. The decisions diverge and do not settle the user's position, which is least settled where generated code enters distributed software.
When is the dependency and exit record reviewed, according to the chapter's summary?
Show the answer
D. At the earlier of evidence expiry, a model-retirement notice and a change of terms
The record has a named owner, a tested exit with an age and a review date at the earlier of evidence expiry, a model-retirement notice and a change of terms.