Submitting a fix to the Linux kernel means writing code, sending it to a maintainer, and watching it land in the next release. Submitting a fine-tune to Llama means starting a file on your own machine that Meta will never open. Both practices get called open source in vendor decks this year. The mechanism underneath them is not the same, and the gap decides whether an engineering team's work becomes part of the next model or disappears into a private fork the day the checkpoint downloads.

Open weight means a company publishes the trained numbers that make up a model, the parameters, for anyone to download and run on their own hardware. Open source means anyone can also read the code and data that produced those numbers, change them, and send a fix back that could land in the next version. Most vendors marketing a model as open source have shipped only the first one.

A Checkpoint Accepts No Pull Request

Open source code has a submission point. A contributor forks a repository, writes a patch, and opens a request for a maintainer to review and merge. Thousands of people can touch the same codebase and the codebase gets better because of it. That loop runs on readable, mergeable text.

A model checkpoint is a few hundred billion numbers with no merge target. Fine-tuning, LoRA adapters, and quantization all start from a released checkpoint and end somewhere else. A LoRA adapter, short for low-rank adaptation, freezes the base model and trains a small set of new parameters that sit alongside it, often under one percent of the original size, so a team can adjust behavior without touching or redistributing the underlying weights. None of it travels back into the base model. Hugging Face hosts thousands of Llama derivatives, and not one of them changes what ships as Llama 5.

This is a structural fact about weights, not a complaint about any one vendor. A fork is still useful to the team that made it.

It does not compound the way a kernel patch does.

Meta Closes the Loop in the License, Not Just the Architecture

Weights alone would make upstream contribution hard. The Meta Llama Community License adds a separate barrier on top of that. Earlier Llama versions barred using outputs to improve a competing model outright. The Llama 4 terms replaced that ban with a naming requirement: build a new model on Llama's outputs and distribute it, and that model's name must start with the word Llama. Either way, nothing in the license creates a path for that new model to become part of the next Llama release. Reach 700 million monthly active users and the free license stops applying at all, and a separate deal with Meta becomes the only path forward (Meta, 2026).

A company that spent enormous compute training a model has reason to protect it this way. Calling the result an open source community stretches past that reason, since neither version of the license creates the one path that defines an open source community: a way for what a contributor builds to fold back into the project itself.

Databricks and Automattic Kept Two Questions Separate

Databricks did not invent Apache Spark's contribution model to sell Databricks. Spark took patches from outside engineers long before Databricks existed as a company, and Databricks built a managed service and proprietary extensions on top of a project whose community loop was already running. Automattic sits in the same position relative to WordPress core, which takes contributions under the GPL regardless of what Automattic charges for hosting.

Contribution and monetization are separable questions in both cases. A company can sell support, hosting, and compliance on top of a project without controlling whether outside engineers can change the project itself. That separation is what an AI lab borrows when it markets an open-weight release using open source language. It keeps the monetization playbook and skips the part that made the playbook trustworthy in the first place.

Olmo Draws the Boundary Somewhere a Contributor Can Reach

The Allen Institute for AI ships a different artifact with Olmo 3: training data, training code, and intermediate checkpoints alongside the final weights, released under Apache 2.0. Ai2's own claim is that because the entire flow is public, an outside team can intervene at any stage, swapping in domain data during mid-training or adjusting the post-training recipe, rather than starting from a finished model and working backward (Ai2, 2026).

That is the difference this piece has been building toward. Olmo's openness sits at the layer that produces the next checkpoint. Llama's openness, and most of what ships under that label from Qwen to Gemma to Mistral's restricted tiers, sits at the layer that consumes it.

Most Open-Weight Models Can Be Retrained. The License Decides What Happens Next.

Most open-weight models on the market can be fine-tuned. The real split is whether that fine-tune carries the original license's restrictions with it, or ships clean.

Fine-tune with no strings attached (Apache 2.0 or MIT):

• Mistral's core open releases
• DeepSeek
• Most Qwen sizes
• Microsoft Phi
• AI2's Olmo family

Fine-tune permitted, but the license follows the derivative:

• Meta Llama, naming requirement plus the 700 million MAU threshold (Meta, 2026)
• Google Gemma, every derivative stays bound to the Prohibited Use Policy and must carry a "Built with Gemma" notice (Google, 2026)
• RAIL-licensed models such as BLOOM and StarCoder2, where use restrictions pass to every downstream fine-tune

A legal team evaluating a vendor pitch should check this list before the benchmark scores. The model that wins on paper can still hand you a derivative you cannot ship the way you planned.

Olmo 2 32B trained on up to six trillion tokens and still competes with far larger open-weight-only models on benchmarks, so full openness has not cost Ai2 a weaker model (Ai2, 2026). The artifact a vendor lets a contributor touch separates the two approaches, not the compute spent building it.

About Shashi Bellamkonda

Loading bio…

LinkedIn Profile

Get new posts by email:

Subscribe

Powered by