How should Gemma's licence terms shape choosing it over an Apache-2.0 open-weight model?

## Framing the decision This is a portfolio question, not a licence-trivia question. The interviewer wants to see whether you can convert legal terms into an architectural constraint and then trade it against capability and cost. The structure that works: 1. What is the **delivery model** — do weights leave your infrastructure? 2. What is the **capability gap** on your actual task? 3. What is the **exit cost** if the terms or the model change? ## Axis 1: delivery model **Serving.** You run the model, customers call an API. No weights leave your control, so licence propagation never fires. Your remaining duty under a restricted licence is to comply with the use policy yourself. This is the cheapest posture and it makes the licence axis nearly irrelevant — pick on quality and cost. **Distributing.** Weights ship: an on-prem install, an air-gapped deployment, a desktop app, a published fine-tune, a container image with the model baked in. Now the licence is a product requirement. Under Gemma's terms you must supply the terms and a notice, and your recipient is bound by the same prohibited-use policy. Under Apache 2.0 you supply the licence text and attribution and nothing constrains what the recipient does. The practical consequence: for a company whose business is shipping software into other people's data centres, a permissively licensed model removes a recurring conversation with every customer's legal team. For a SaaS company, it removes almost nothing. ## Axis 2: what Apache 2.0 gives that a bespoke model licence may not - **No field-of-use restriction.** Your customer may build anything. - **An explicit, irrevocable patent grant.** Bespoke licences vary; read the text rather than assuming. - **A stable text.** Apache 2.0 does not change under you. A vendor policy referenced by URL can be updated, and terms that bind you to the current policy make your compliance surface a moving target. - **Compliance-tool recognition.** Approved-licence lists are built from standard identifiers. A bespoke licence fails the automated check and lands on a human's queue — plan weeks, not hours. ## Axis 3: what a restricted licence may buy you Don't argue this from ideology. Restricted-licence families are sometimes simply better on your task, better documented, or better supported by vendor-published quantised builds and tooling. Quantify the gap on your own evaluation set. A five-point quality difference on the metric your customers feel can be worth substantial compliance work; a one-point difference on a leaderboard you don't care about cannot. Also note what the restricted licence does **not** take: with Gemma, generated outputs are yours — Google claims no rights in them. If your product's value sits in the artefacts the model produces rather than in the model itself, that removes the objection people most often raise first. ## Axis 4: exit cost The strategic risk with any bespoke licence is that the terms are the vendor's to revise. You cannot price that risk away, so you engineer around it: - Put every model behind **your own inference interface**, so callers depend on your contract, not on a vendor's prompt format. - Keep the **fine-tuning dataset and pipeline reproducible**, so retraining on a different base is a scheduled job rather than a research project. - Maintain a **evaluated fallback** — a second family you have actually measured, not one you assume would work. - Track which **prompt-format assumptions** leak into your application code; template differences between families are the real switching cost, and they are cheap to isolate up front and expensive to untangle later. Do this and the licence question becomes reversible, which is the whole point of a principal-level answer. ## What a weak answer looks like "Always pick the permissive licence" ignores capability and is not a judgement. "Licences don't matter, everyone uses these models" ignores that your customers' compliance teams disagree. "We'll just fine-tune it, then it's ours" is a legal misunderstanding that a reviewer will pounce on: derivatives stay bound. ## A defensible recommendation For a hosted product: choose on capability per GPU-hour, comply with the use policy, and record the decision. For a shipped product: default to a permissively licensed family, and adopt a restricted one only with a measured capability gap that justifies the recurring distribution overhead — and with the notice and terms automated into the release artefacts so compliance is not a human remembering. ## Version caution Licence texts and use policies get revised. Re-read the terms before any release that distributes weights, and record the date you checked alongside the decision.