Open Source Development and Model Licences

Author : James Smith | Published On : 21 Sep 2026

Adopting an open model feels like adopting an open library. It is not, and the difference has caught out more than one team I have spoken to.

A library has a licence covering the code. A model has weights, training data, a licence that may cover use rather than distribution, and occasionally terms that change with your company size.

The distinction that matters most and gets blurred constantly.

Some models publish weights you can download and run. That is genuinely useful and it is not the same as open source development in the sense the term usually means.

The training data is rarely published. The training code frequently is not. You can run it, you can often fine tune it, and you generally cannot reproduce it or fully audit what went into it.

We use several on that basis, deliberately, with the limitation written down rather than assumed away.

Four questions we ask before any model enters the estate.

Can we use it commercially? Some permit research only, and the distinction is sometimes buried.

Can we serve it to customers, or only use it internally? Those are different grants.

Are there restrictions based on our size or usage volume? Several licences change terms above a threshold.

Do we have to publish anything if we fine tune it? Some require derivative weights to be shared.

Our legal review found two models on our shortlist that we could not have used the way we intended. Both were widely described as open.

The question teams answer late.

If you fine tune a model on your own data, what is the resulting thing? Whose licence applies? Can you keep it private?

For most permissive licences the answer is straightforward. For a few it is not, and the answer determines whether your fine tuned model is an asset or something you must publish.

We settle this before any fine tuning begins. It takes a conversation with legal and it removes a question that would otherwise arrive after the work is done.

The question we ask of every model we run.

If the weights became unavailable tomorrow, or the licence changed, what happens to the feature built on them?

For two of ours the answer is that we hold a copy and can continue indefinitely. For one, we depend on a hosted endpoint and would need to migrate.

Knowing which is which shapes how much we build on each. Open source development gives you the option to continue, and the option is only real if you have actually stored what you need.

A model arrives with a stack underneath it.

The serving framework, the tokeniser, the quantisation tooling, the inference runtime. Each is its own project with its own licence, maintenance status, and abandonment risk.

We inventory all of it. When a vulnerability is disclosed in something widely used in this ecosystem, the question is which of our services contain it and at what version. Without an inventory, answering takes days.

A practice we adopted after a scare elsewhere in the industry.

We download from the official source, verify the checksum, and store our own copy. We do not pull weights at runtime from a public endpoint.

A model swapped upstream, or a mirror serving something modified, would be difficult to detect and would run with whatever access the serving layer has.

That is ordinary supply chain hygiene applied to a new kind of artefact, and it costs almost nothing once set up.

The split has been stable for about a year.

Open models for anything internal, anything high volume where cost matters, and anything with a data residency constraint.

Commercial APIs for anything where quality at the frontier matters more than cost, and where the volume does not justify the operational commitment.

Running a model yourself is a real commitment. Inference infrastructure, scaling, monitoring, and somebody who understands it. Our machine learning engineering team carries that, and machine learning engineering capacity is not free.

We used a partner for the initial serving architecture, which was outside our experience.

The generative AI consulting we bought alongside it was less useful, mostly because we had not defined what we wanted from it. That was our failing rather than theirs. A consulting engagement scoped as help us with AI produces a survey.

The narrow engagement worked. Design review, a reference implementation, and pairing.

• Licence reviewed against four specific questions before adoption.
• The fine tuning position settled before any fine tuning.
• Every component in the serving stack inventoried.
• Weights downloaded from source, verified, and stored internally.
• A named owner per model, with an abandonment plan.

Is an open model cheaper?

At high volume, usually. At low volume the infrastructure and attention cost more than the API calls you avoid.

Does this differ from ordinary library adoption?

The process is similar and the artefacts are not. Open source development in this area involves weights, training provenance and use restrictions that a code licence never covers.

Can we audit an open weights model?

Partially. You can inspect behaviour thoroughly and you generally cannot inspect what it was trained on.

Who should own the licence review?

Legal, with engineering explaining the intended use. Open source development licence questions in this area are less settled than in software, and the wording matters.

Does this slow adoption?

By about a week per model. Considerably less than discovering a licence problem after building on it.

Treat an open model as a supply chain component rather than as a free library.

It has a licence with specific terms, a stack of dependencies underneath it, a provenance question, and an abandonment risk. All four are familiar from ordinary open source development, and all four need answering before it runs in production.

The teams I have seen struggle here are the ones that treated downloading weights as a technical decision rather than an adoption one.