How do the Gemma Terms of Use differ from an OSI licence like Apache 2.0?

## Open weights versus open source These two phrases get used interchangeably and they are not the same thing. **Open weights** means the parameter files are published and you may download and run them. **Open source**, in the OSI sense, means the licence grants freedoms with a specific shape — among them, no restriction on the *field of endeavour* in which the software may be used, and no discrimination against persons or groups. A licence that says "you may not use this for X" is, by that definition, not an open-source licence no matter how generous it otherwise is. Gemma is squarely in the first camp. The weights are free and freely runnable; the licence is Google's own **Gemma Terms of Use**, paired with a **prohibited-use policy** that enumerates applications you agree not to build. ## What the terms let you do Generously read, the permissions are broad: - **Download, run and modify** the weights, on your own hardware or a cloud you rent. - **Use commercially**, in a product that makes money, with **no revenue cap and no user-count threshold**. This matters because some other open-weight families do attach a scale threshold above which you must negotiate a separate licence; Gemma does not. - **Fine-tune** and create derivatives. - **Distribute** those derivatives. - **Keep your outputs.** The terms state that Google claims no rights in the outputs you generate. Text, code or analysis your deployment produces is yours to use and to license to your customers. ## What the terms require of you The obligations cluster around **use restrictions** and **propagation**. **Use restrictions.** You accept a policy listing prohibited applications. The policy lives with Google and can be updated; the terms bind you to the policy as it stands, not to a snapshot you saved on the day you downloaded. For a compliance team, this is the sharpest difference from Apache 2.0, whose text is fixed forever once you receive the software. **Propagation to derivatives.** A fine-tune, a merged model, a distilled student trained on the weights — these are derivatives, and the terms follow them. If you *distribute* such a model, you must supply the recipient with the terms and a notice identifying the model as Gemma-derived, and the recipient is bound by the same restrictions. Distribution here is broader than publishing on a hub: shipping weights inside an on-prem product, or handing a customer a container image with the weights baked in, is distribution. **Serving is not distributing.** If you host the model yourself and expose only an API, you are not handing anyone the weights. Your obligations are still to comply with the use policy, but the pass-along mechanics do not fire. ## Why the OSI distinction has teeth It is tempting to treat this as lawyer's pedantry. It is not, for three concrete reasons. 1. **Enterprise policy gates.** Many organisations run an approved-licence list built from OSI identifiers. A non-OSI, bespoke model licence will not match any SPDX identifier the tooling knows, and the request lands on a human's desk. Plan for that review rather than discovering it a week before launch. 2. **Customer contracts.** If you redistribute, your customer inherits restrictions they did not negotiate. Enterprise buyers with their own compliance regimes may push back or demand indemnities. 3. **Patent grant.** Apache 2.0 carries an explicit, irrevocable patent licence from contributors. A bespoke model licence's patent posture is whatever its own text says — read it rather than assuming Apache-style protection. ## What a good answer sounds like An interviewer asking this is checking whether you can tell "free to download" apart from "unencumbered". The strong answer names three things: it is Google's own terms, not OSI; commercial use is genuinely free of scale thresholds; the restrictions propagate to anything you fine-tune and distribute. The weak answer is "it's open source, so you can do whatever you want". ## Practical checklist before you ship - Decide whether you will **serve** the model or **distribute** the weights — the obligations differ. - Record the notice and terms you must pass along if you distribute; automate it into your release artefacts rather than relying on memory. - Read the prohibited-use policy against your **actual** product use case, not against a generic one. - Keep the model swappable behind your own inference interface, so a licence change is an engineering decision rather than a crisis. ## Version caution Model licences are living documents and vendors revise them. Cite the terms as they read when you check, say when you checked, and re-read before any release that distributes weights.