Open source licensing was built for a world in which software is distributed as source code, modified by developers and passed along under conditions the original author chose. Machine learning has disturbed that arrangement in ways the licence texts did not anticipate.
Three questions now recur. Does training a model on licensed code constitute a derivative work? Do model weights inherit the licence of their training data? And can a licence condition such as requiring attribution be satisfied when a model has absorbed millions of files whose provenance is unknown?
Why the derivative work question is hard
Copyright law asks whether a new work copies protected expression. A model’s weights are numerical parameters, and the relationship between them and any single training example is diffuse. Courts have begun to address this, and no settled answer applies across jurisdictions.
What is clearer is that outputs can infringe. If a model reproduces a substantial portion of a licensed file verbatim, the licence conditions attach to that reproduction. Tools that detect such overlap exist and are used by developers who care about compliance.
The licence families and their intent
Permissive licences such as Apache 2.0 and MIT impose few conditions beyond attribution and, in the Apache case, patent terms. Copyleft licences such as the GPL require derivative works to carry the same licence. Which category applies to a model depends on a legal question that has not been resolved.
Some projects have responded by writing licences specifically for models, adding terms about acceptable use, commercial thresholds or the requirement to publish training data. These are not open source in the traditional sense, and the Open Source Initiative has worked on a definition intended to clarify what the term should mean for models.
What maintainers are actually doing
Many maintainers of widely used libraries have added language to their repositories stating expectations about training use, even when the licence itself does not cover the question. Others have adopted dual licensing, offering a commercial option alongside a copyleft one.
The practical effect is that a company building a product must now audit both the code it ships and the data used to train any model it ships. Few organisations were set up to do the second, and the tooling is younger.
The compliance burden falls unevenly
A large company can afford lawyers and provenance tooling. A small team cannot, and may avoid open source models for fear of unknowable risk. That outcome is the opposite of what the licence system was designed to achieve.
Provenance standards are emerging, including work on dataset documentation and content credentials that record origin. Adoption is partial, and interoperability between the schemes is still being worked out.
What a careful team should do
Inventory the models in use and the datasets behind them, to the extent that information is available. Keep records of licence terms at the time of download, because terms change. Filter model outputs for verbatim reproduction of known licensed code, and retain the filter logs.
For code the team releases, state explicitly whether training use is permitted, rather than leaving it to inference. That single sentence removes more ambiguity than a long discussion in a repository issue.
Model licences and the open source definition
A growing number of releases attach terms that restrict use, whether by field, by organisation size or by the requirement to publish derived data. These terms may be reasonable, and they are not open source as the term has traditionally been understood.
The dispute over vocabulary matters commercially, because procurement policies frequently require open source components and auditors check licence identifiers. A model described as open but carrying use restrictions can fail that check, which creates an awkward conversation late in a project.
Some organisations have responded by publishing both a restricted model and a genuinely permissive one, letting users choose. Others rely on detailed acceptable use policies, which are enforceable as contract terms but do not make the licence open.
For developers, the practical advice is to record the licence identifier and the version of the terms, not just the model name, because terms are revised and the revision that applies is the one in force when the model was obtained, which may differ from the terms visible today.
Where this is heading
Legislatures and courts are moving, unevenly and at different speeds. The likely outcome is a patchwork, with different rules for different jurisdictions and a period of uncertainty that rewards documentation over optimism.
Teams that keep clean records of what they used and when will navigate that period far more easily than teams that discover the problem during diligence. The licence may be ambiguous, but the audit trail is entirely within a developer’s control. That is the practical lesson: in an unsettled area, documentation is the cheapest form of insurance available.
Image: Cycling2 · CC0 · via Wikimedia Commons.