This chapter treats three questions that every development organisation inherits when AI enters its toolchain: who holds the rights in what the toolchain produces, what the toolchain rests on, and what the organisation can do if a part of it must be replaced. It concerns three of the five developer functions. D2 Design is where the choices are made and recorded: which model, which licence, which hosting, which exit. D3 Build is where generated code enters the repository and where a licence problem starts. D5 Steward is where the organisation lives with the consequences for years. Legal statements are attributed to the instrument and article and framed as organisational and architectural implications, not legal advice. Chapter 24 maps the wider regulation of the toolchain and Chapter 18 treats procurement and public code; this chapter takes the rights and the dependencies.
The thesis, drawn in the Summary, is plain: a dependency nobody recorded is one nobody decided, and a right nobody checked is one the organisation only hopes it has. The stewardship principle of Chapter 4, Name, Understand and Revert, applies to the supply side of the toolchain as to code.
The question that developers ask first is whether anyone owns what an assistant generates. The honest answer is that European law answers it only by implication, that the answer turns on the human contribution, and that no court has ruled on it for code.
Primary topics explored
- Copyright in generated code
- Licence contamination
- Text and data mining and the AI Act
- Litigation as signal
- Open source and maintainers' load
- Dependence and exit
About AI Developer
AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader.
developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 26: Intellectual Property, Open Source and Sovereignty in the Toolchain in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Regulation, Ethics and Responsibility” and is one of 37 drawn from the manuscript.