Licensing and Usage Rights for Models

This article follows one line of reasoning. We start with the origin of the training data, follow that data through the licenses and terms attached to it, and then look at how evaluation has to account for what the model has absorbed. By the end, you should be able to look at a model and ask the questions that its lineage makes necessary.

Models are likely trained on data scraped from the internet. Because of this, lineage is not an abstract concern. It determines what the model may have learned from, and whose rules apply to that material.

The definition has two parts that you should keep separate. The origin is the first place the material came from, such as content published on the open web. The history is everything that happened to it afterward, including every party that handled, collected, or passed it along. Lineage asks about both. Knowing only that a model was trained on web content tells you about the origin, but not about the chain of parties that may have added their own conditions.

The diagram below shows the path that training data can take. A model does not stand alone. Its training data can come from the open web, and it can also come from the outputs of another model. Each of those sources carries its own conditions. Reading the diagram from left to right is the lineage question: where did each input come from, and who set the rules for it?

The diagram is a simplified view. Its purpose is to show that the record of where the data came from can pass through several hands before it reaches the model. Lineage is the discipline of reconstructing that path, so that you can see at each step which party set which rules.

A model can be governed by more than one set of rules at once. The first layer is the model's own license, which states what its owner allows. The second layer is the upstream material the model was built from. That material may have an owner who set separate restrictions. A license that permits something does not automatically override a restriction placed upstream in the chain.

The source states this directly: a model's own license does not override restrictions on its upstream training sources, such as the terms of a model whose outputs were used for training. This is why a permission on one layer is not enough on its own.

Read the tree from the top down. The model's own license grants some permissions, but the upstream branches add constraints that reach down into the final list of permitted uses. Those constraints do not disappear because the top layer is permissive. The result is limited by every layer that feeds into it.

A lineage review asks a fixed set of questions about each model before evaluation results are trusted. Work through the questions in order for any model you are asked to assess. The questions below follow directly from the source's examples. They do not replace legal advice.

Lineage explains what a model may have absorbed. Model evaluation then asks whether the model behaves correctly with that knowledge. One of the harder parts is knowledge boundaries. A model playing a role should respond the way that character would, and that includes not knowing things the character would not know.

The source describes a roleplaying example built around Jackie Chan. If Jackie Chan does not speak Vietnamese, then the roleplaying model should not speak Vietnamese either. Evaluating that model means deliberately testing for this boundary. You ask about the thing the character should not know and check whether the model reveals it.

The comparison shows the two sets a negative knowledge check examines. Replies should stay within the allowed set, and any reply that falls into the disallowed set is a failure, even if the reply is accurate. The check overlaps with ordinary evaluation, but it asks a different question: not whether the model is correct, but whether it keeps within the limits its role requires.