Open Weights Have a Business Boundary

Original analysis · October 16, 2026.

Muse Spark Open makes a procurement blind spot visible: the model file can stay exactly the same while the business using it changes. A technical deployment review therefore needs a companion question: does the commercial decision still describe the product being sold?

Model services above US$20m in combined licensee-affiliate revenue over 12 consecutive months require Meta’s prior agreement; §3 exempts internal and non-model-service uses.

Give the decision an expiry event

Our proposal is to treat a deployment decision as a dated description of a business configuration. Record which entity operates the system, who can call it, what customers receive, and who owns the commercial review. A model checksum can identify the software; it cannot describe the customer relationship.

Consider a hypothetical analytics company that first uses a model to prepare reports for employees. Later, it sells an interactive customer feature; eventually, it considers exposing a general-purpose endpoint. These are three product decisions even if engineers reuse the same weights. We would reopen the review at each change, rather than assume that the original approval travels with the file. This example does not classify any particular product under the license.

The useful addition is an observable trigger. A changed customer interface, a new operating entity or an acquisition should create a review task with an owner and a deadline. Finance, product and engineering should each be able to initiate it. Otherwise, each team can hold an accurate piece of information while nobody notices that the combined picture has changed.

Describe what the customer buys

Modal offers the model through a metered shared endpoint.

An endpoint establishes a delivery mechanism. Our question is what the customer is actually purchasing: a bounded product outcome, or access to a general capability? API plumbing alone is an incomplete description. A company could use the same underlying model for an invoice-extraction feature and for an unrestricted text-generation service, while making quite different promises to its customers. We are identifying a question for review, not assigning either example a legal classification.

We would keep a one-page interface brief covering accepted inputs, intended outputs, customer control and support obligations. Revisit it when a sales promise expands beyond the documented product. For example, allowing customers to replace task-specific instructions with arbitrary prompts may change what the service is for. A subscription price or a per-token bill records how money is collected; neither is a sufficient account of the product being sold.

Make future changes discussable

OSI’s definition requires freedoms to use, study, modify and share.

Our practical takeaway is to replace broad adjectives with explicit questions. Can the team keep serving existing customers if a new product launch is delayed? Can it switch models without changing promised behavior? Who checks the business assumptions after an acquisition? These questions test useful flexibility without turning a download button into a promise about every future use.

Before committing to customer terms, run a short tabletop exercise: change the audience, operating entity and delivery interface one at a time. For each change, identify the unanswered question, the person who can resolve it and the evidence they need. Keep uncertainty visible; do not turn a plausible interpretation into a launch authorization.

This is a proposed business-planning practice, not a complete license review or legal advice. The objective is simple: make the commercial review easy to revisit while the product is still cheap to change. Open weights can expand technical choice; preserving that choice requires knowing which business decision was actually made.