What is a derivative work

Definition

A derivative work is new software that is based on, adapted from, or incorporates existing software in a way that copyright law treats as derived from the original. In the open source context, the question is whether your software counts as a derivative work of a component you have used. If it does, the license that governs that component can reach your code and impose its conditions on it. If it does not, those conditions stay with the original. The boundary is drawn by copyright law and by how a specific license defines its scope, which means the precise line is a legal determination and belongs with your own counsel. What matters for risk is recognizing when the question is live.

Why a derivative work matters for license risk

The reason the concept carries weight is copyleft. A permissive license asks little, so whether your code is a derivative work of a permissively licensed component rarely changes much. A copyleft license is different. Licenses such as the GPL and the GNU AGPL attach reciprocal obligations to derivative works: if your software is a derivative work of the copyleft component, the license can require you to release your own source code under the same terms. For an organization that ships proprietary software, that is a material outcome. The classification is therefore not academic. It determines whether a copyleft obligation reaches your code or stops at the component boundary. For the broader mechanism, see what is copyleft.

Where the boundary is contested

The hardest part is that the boundary is genuinely disputed in places. Combining two pieces of code by copying source from one into another is widely accepted as creating a derivative work. Far less settled is linking, where one program calls another at build time or run time. Strong copyleft licenses are often read to treat linked code as part of a single combined derivative work, while a Lesser GPL deliberately includes a linking exception so that linking to the library does not pull your code into the same obligation. The answer turns on the type of linking, the structure of the software, and the wording of the license. Because reasonable parties disagree, the safest posture is to identify where the question arises and resolve it with counsel rather than assume. The network dimension adds another layer: the GNU AGPL extends the trigger to software offered over a network, not only software distributed as a file.

Derivative work versus distribution

It helps to separate two questions that often travel together. Whether something is a derivative work is about how your code relates to the original. Whether you distribute is about whether you convey the software to anyone else. Many copyleft obligations are triggered only when a derivative work is also distributed, so both conditions usually need to be met before the obligation bites. This is why a copyleft component used purely internally, never shipped, often carries less practical exposure than the same component in a product you sell. The exception is a network license like the GNU AGPL, which can treat offering software as a service as the equivalent of distribution. For a buyer mapping exposure, the practical step is to record which copyleft components are present, how they are combined with your code, and whether the software reaches users, then to confirm the classification with counsel. Doing this within an open source license risk assessment turns an open ended legal worry into a bounded, documented question.