Open-Source AI Still Has Lock-In: Where to Look in the Stack

"We use open-source AI" is a sentence that hides four or five different decisions. Each one can be open or closed, free or conditional, portable or sticky. Treat the stack as a stack, and the lock-in becomes visible layer by layer.

Layer one: the model and its licence

Downloadable weights are not the same thing as an open-source model. The Open Source Initiative published its Open Source AI Definition (version 1.0, October 2024) and set a demanding bar. It says the preferred form for modifying an AI system includes three elements: sufficiently detailed information about the training data, the complete code used to train and run the system, and the model parameters, all made available under OSI-approved terms.

A model can ship its weights and still withhold one or more of those elements. That is not a moral failing, but your legal and technical teams should know which elements are missing before they build on it.

Take a widely used family as a worked example. The Llama 4 Community License Agreement, as published by Meta, is a custom licence written by Meta, not a standard text such as Apache 2.0. Among its terms:

• If the licensee's products or services (including those of its affiliates) exceeded 700 million monthly active users in the month before the Llama 4 release date, the licensee must request a licence from Meta, which Meta may grant at its sole discretion.
• If you use the materials or their outputs to create, train, fine-tune or improve an AI model that you distribute or make available, you must include "Llama" at the beginning of that model's name.
• You must adhere to Meta's Acceptable Use Policy, which the agreement incorporates by reference.

For a mid-market company, the user threshold is irrelevant today. The naming rule and the incorporated usage policy are not: they travel with anything you derive. The usage policy is a separate document incorporated by reference, so ask counsel which version binds you and how changes reach you. Read the licence of the exact model version you deploy, not the family's reputation.

Compare with a permissive licence such as Apache 2.0. Its patent clause says that if you sue an entity claiming the work infringes a patent, the patent licences granted to you terminate on the date the suit is filed. That is a condition too, but it is a short, standard, widely reviewed one. Fewer surprises, less legal time.

Practical rule: keep a register with one line per model in production. Licence name, version, link to the text, obligations that propagate to your derivatives, and the date someone last read it.

Layer two: the inference stack

Once you have weights, something has to run them. Inference servers, quantisation tools and model formats are separate decisions, and each narrows your options. A model quantised in one format may only run on some runtimes. Some optimisations only exist for some accelerators. The vendor-neutral appearance of "open model" can mean you picked a runtime whose best features sit on one hardware family.

Ask what happens if you change one thing. Same model, different server: how much of your configuration, monitoring and tuning survives? Same server, different accelerator: does it run at all?

Layer three: drivers and low-level toolkits

This is the layer people forget because it works quietly. Most AI hardware reaches your software through a vendor toolkit, and that toolkit has its own licence.

One example worth reading in full: the NVIDIA CUDA Toolkit end user licence agreement (version 13.5, last updated January 2026, at the time of writing). Its limitations section includes a clause that you may not reverse engineer, decompile or disassemble any portion of the output generated using SDK elements for the purpose of translating such output artifacts to target a non-NVIDIA platform.

This is not legal advice, and how that clause applies to your case is a question for counsel. It is enough to note that a licence term exists in the toolchain that bears directly on porting. If a future move to a different accelerator is part of your exit plan, put that clause in front of counsel before you write the plan down.

Also map the operational dependencies: driver versions pinned to kernel versions, container images that only exist for one distribution, firmware you cannot update independently.

Layer four: where it runs

An open model on a proprietary managed service is still tied to that service. Managed endpoints, vector stores, identity systems and monitoring wrap the model in APIs that exist nowhere else. The weights are portable. Everything around them is not.

Test it. Could you redeploy the whole system, not just the model, on a different provider or on your own hardware within a window the business would accept? If the honest answer is "we have never tried", the system is not portable yet, whatever the licence says.

Layer five: tooling and data

Orchestration frameworks, prompt formats, evaluation harnesses and embedding models create quieter dependencies. Switching an embedding model means re-embedding your entire document collection. Prompts tuned for one model may behave differently on another. Evaluation sets that live in a vendor's console are not yours until you export them.

Store prompts, evaluation cases and configuration in your own repository, in plain formats. That one habit removes more lock-in than any licence choice.

What to do on Monday

1. Build the register: one row per model, runtime, toolkit and managed service, with licence and version.
2. Mark every row with the cost of replacing it: a day, a month, a project.
3. Pick the three most expensive rows and write an exit sentence for each. If you cannot, that is your first finding.

Open is a spectrum, and most real stacks sit somewhere in the middle. The aim is not purity. It is knowing, in advance and in writing, what you would have to do to leave.