📖 Lecture — Open Models, Licenses, and the Fine-Tuning Toolchain

Last week you got comfortable running inference on pretrained models. This week we slow down and ask a question that trips up almost everyone new to fine-tuning: can you actually use this model the way you want to? The answer depends entirely on licensing, and licensing is not a footnote — it can determine whether your entire business model is legal.

"Open source" vs. "open weight": the distinction that matters

In casual conversation, people say a model is "open source" when they really mean the weights are downloadable. These are not the same thing. True open source, in the sense the Open Source Initiative (OSI) uses the term, means the code, training data, weights, and license are all public, and the license itself meets the OSI's open source definition (no restrictions on who can use it or what they can use it for). Open weight only guarantees that you can download the model's parameters and run them yourself. The license attached to those weights can still say a great deal about what you're allowed to do next. This is the single biggest misconception new fine-tuners walk in with: most of the popular "open" models you've heard of — including Llama — are open weight, not open source. That doesn't make them bad models. It means you must read the license before you build a product on top of one.

Reading model licenses like an engineer, not a hopeful user

Two categories show up constantly in 2026:

  1. Permissive OSI licenses — Apache 2.0 and MIT. Models like Qwen 3, DeepSeek, and Mistral are released this way. There are no usage caps, no royalty obligations, and no restrictions on commercial deployment. You can fine-tune, redistribute, and sell a product built on these weights without asking permission.
  2. Custom "community" licenses — most notably Meta's Llama Community License. This is not an OSI-approved open source license. It imposes real restrictions, including a usage cap (companies with more than 700 million monthly active users must obtain a separate license directly from Meta) and other field-of-use conditions that vary by version. The Open Source Initiative has publicly stated that Meta's Llama license does not meet the open source definition, precisely because of these restrictions.

That 700M MAU threshold sounds like it only matters to giant companies, but the deeper lesson is more general: a custom license can restrict any part of your business model, not just scale. Some community licenses have, in various versions, restricted using outputs to train competing models, imposed field-of-use limits, or required specific attribution in your product. You cannot assume that because you can download a .safetensors file, you can do anything you want with it.

License type Examples Usage cap? OSI-approved? Commercial fine-tuning/deployment
Apache 2.0 Qwen 3, Mistral (most releases) No Yes Unrestricted
MIT DeepSeek (select releases) No Yes Unrestricted
Llama Community License Llama 3.x, Llama 4 Yes (700M MAU) No Allowed below cap; separate license required above it, plus other field-of-use terms

Why you must check the model card every time

Here's the second misconception worth naming directly: not all downloadable-weight models are equally suitable for commercial deployment, even when they look similar on paper. Two models can both be free to download, both perform similarly on benchmarks, and still have completely different legal postures. A license clause that blocks "serving the model via a closed API" could invalidate an entire SaaS business plan overnight, and version differences make this worse — a license can change between v1 and v2 of the same model family, so a "we checked six months ago" answer is not good enough. Before any commercial deployment or fine-tuning project, verify the model card, the license text, and any geographic or usage restrictions directly on Hugging Face. Don't rely on secondhand summaries, including this one — go read the primary source for the exact model and version you intend to ship.

The 2026 fine-tuning toolchain

Once you've cleared a model for use, you need the right tools to adapt it. The current standard stack breaks down into layers:

Layer Tool What it does
Speed on consumer GPUs Unsloth Heavily optimized kernels for fast, memory-efficient fine-tuning on a single consumer or free-tier GPU
Config-driven multi-GPU pipelines Axolotl YAML-configured training pipelines that scale from one GPU to multi-node clusters
Post-training objectives Hugging Face TRL Unified library for supervised fine-tuning (SFT), reward modeling, DPO, and GRPO
Parameter-efficient methods PEFT LoRA, QLoRA, and other adapter-based methods so you don't have to update every weight
Model loading and inference Transformers The base library for loading architectures and running forward passes
Multi-device orchestration Accelerate Handles device placement, mixed precision, and distributed training boilerplate
Quantization bitsandbytes 8-bit and 4-bit quantization for training and inference on limited memory
Data handling datasets Loading, streaming, and preprocessing training data at scale

TRL is worth calling out specifically: it is the unified post-training library hub. It supports SFT, reward modeling, DPO, and GRPO objectives, and it's the integration point where PEFT adapters and Transformers models plug into a training run. When you fine-tune next week, TRL will likely be the library orchestrating the whole job, calling into PEFT for efficient parameter updates and Transformers for the base model.

Bringing it together

By the end of this week, you should be able to look at any model on the Hugging Face Hub, correctly classify its license, decide whether it fits a hypothetical commercial use case, and have a working notebook environment with every library you'll need for the fine-tuning runs starting next week. Get the licensing habit right now — it's far cheaper to spend twenty minutes reading a model card today than to discover a blocking clause after you've shipped.