Every Indian CIO who has run a generative AI pilot eventually faces the same question from the board, the CISO and the finance team at once: should the next phase run on a proprietary model through an API, or on an open-weight model the company hosts and controls itself? The question sounds technical. It is really a question about licences, control, cost structure, capability and who answers the phone when something breaks. The open source LLM enterprise decision is one of the few AI choices that touches all five at the same time.
The global evidence does not point in one direction. Menlo Ventures' State of Generative AI in the Enterprise report, published on 9 December 2025 and based on a survey of 495 US enterprise AI decision-makers, found that open-source models accounted for 11% of enterprise usage, down from 19% a year earlier. Menlo describes enterprises as "cautious, preferring closed-source models", and attributes part of the decline to a lack of major new Llama releases after Llama 4 in April 2025. That is a US reading. Indian enterprises face pressures that US buyers mostly do not: data protection rules with localisation provisions for some firms, sector regulators with their own outsourcing and cloud frameworks, and a language mix that general-purpose models handle unevenly.
This piece does not argue that open weights are better or worse. It sets out what "open" actually means in model licences, separates the five dimensions on which the choice turns, and offers a decision table that a CIO can use to place each workload on the right side of the line. Cost modelling, on-premise economics and evaluation are covered in separate PanScience Research pieces and are referenced rather than repeated here.
Most "open source" models are open-weight, and the licence is the first test
The phrase "open source" is used loosely for language models. The Open Source Initiative's Open Source AI Definition, version 1.0, published in October 2024, sets a demanding bar. It requires the freedom to use the system "for any purpose and without having to ask for permission", to study it, to modify it and to share it. It also requires, as the preferred form for modification, "sufficiently detailed information about the data used to train the system", the full code used for training and inference, and the model parameters, each under OSI-approved terms. Very few widely used models publish their training data information to that standard. What most enterprises call open source is, more precisely, open-weight: the parameters are downloadable, but the training data and much of the pipeline are not.
Within open-weight models, the licence itself varies sharply. Three examples illustrate the range.
The Llama 3.1 Community License Agreement, dated 23 July 2024, grants broad rights but attaches conditions. A licensee whose products had more than 700 million monthly active users in the preceding calendar month must request a separate licence from Meta, which Meta may grant at its sole discretion. Licensees must "prominently display 'Built with Llama'" on a related website or in product documentation. Use must comply with an Acceptable Use Policy incorporated by reference, and the agreement is governed by the laws of the State of California. For almost every Indian enterprise the user threshold is irrelevant. The Acceptable Use Policy, the attribution clause and the foreign governing law are not, because legal teams must review them and because the policy can change.
Mistral Small 3, a 24-billion-parameter model released on 30 January 2025, is published under the Apache License 2.0. Apache 2.0 grants a copyright licence that is "perpetual, worldwide, non- exclusive, no-charge, royalty-free, irrevocable", and an equivalent patent licence, which terminates only for a licensee that starts patent litigation alleging the work infringes a patent. There is no acceptable use policy embedded in the licence and no user threshold. For a legal team, this is the most familiar and least ambiguous position.
Google's Gemma models sit in between. The Hugging Face model card for Gemma 2 requires users to "review and agree to Google's usage license" before downloading, and points to a separate Gemma Prohibited Use Policy. The weights are open; the terms are bespoke.
The practical lesson is that "open" is not a single category. A procurement team that treats an Apache 2.0 model and a community-licensed model as equivalent has skipped the first gate.
Five dimensions that decide the choice
Once the licence is understood, the choice between proprietary and open-weight models turns on five dimensions. They are listed in the order in which they usually become binding in Indian enterprises. Licence. Can the enterprise use, modify and embed the model in the way the business case requires, including in products sold to its own customers, without renegotiation? Is the licence stable, or can a use policy change after deployment?
Control. Where does inference run, who can see prompts and outputs, and can the enterprise freeze a model version? Proprietary APIs are updated by the provider. Research by Lingjiao Chen, Matei Zaharia and James Zou, "How is ChatGPT's behavior changing over time?", found that GPT-4's accuracy on identifying prime numbers fell from 84% in March 2023 to 51% in June 2023 for the same service. Self-hosted open weights do not change unless the enterprise changes them. That is an advantage for regulated, audited workflows and a burden when improvements must be adopted manually.
Cost. Proprietary APIs convert AI into a variable cost per token. Self-hosting converts it into a largely fixed cost of GPUs, engineering and operations. Which is cheaper depends almost entirely on utilisation, which a separate PanScience Research piece on the unit cost of enterprise AI covers in detail.
Capability. On the hardest reasoning, coding and multimodal tasks, the strongest proprietary models have generally led. On narrower tasks, such as classification, extraction, summarisation of domain documents and retrieval-grounded answering, smaller open-weight models fine-tuned on the enterprise's own data are often sufficient. A separate PanScience Research piece covers small language models.
Support. Who patches a vulnerability in the serving stack, who tunes throughput, who decides when to upgrade, and who is accountable when output quality drops? A proprietary provider bundles this. An open-weight deployment requires the enterprise, or a partner, to supply it.
A decision table for open source LLM enterprise choices
The table below is this article's analytical contribution. It does not score models. It scores workloads, because the right answer for a customer-facing chatbot and for a credit-memo drafting tool inside a bank are rarely the same. For each dimension, the table states the condition under which it tilts the decision towards proprietary APIs or towards open-weight models the enterprise controls.
Two decision rules make the table usable.
First, licence and control are gates, not weights. If a workload's data cannot leave the enterprise's environment under its regulatory or contractual obligations, a public API is out regardless of capability or cost, unless the provider offers a deployment inside a compliant boundary. If a licence does not permit the intended commercial use, the model is out regardless of benchmark scores.
Second, cost, capability and support are traded off only after both gates are passed. A workload that clears both gates for either option should be decided on evaluated capability first, then on total cost of ownership, then on support. Deciding on cost first is the most common way enterprises end up with a cheap model that fails its users.
Control and the Indian regulatory context
Control matters more in India than the global adoption data suggests, because several Indian rules speak directly to where data sits and who processes it.
The Digital Personal Data Protection Rules, notified on 14 November 2025 with an 18-month window for most obligations, subject significant data fiduciaries to additional duties, including annual data protection impact assessments, independent audits and restrictions on transferring specified personal data and related logs outside India. The Reserve Bank of India's 2018 circular on storage of payment system data requires payment data to be stored only in India. SEBI's framework for adoption of cloud services by regulated entities, issued on 6 March 2023, sets out the conditions under which securities market entities may use cloud services.
None of these rules prohibits the use of proprietary model APIs. They do raise the cost of using them for prompts that contain regulated data, because each such flow must be mapped, contracted and audited. For many Indian banks, insurers, hospitals and law firms, the practical effect is that the most sensitive workloads run on models the enterprise hosts, while less sensitive ones use APIs. A separate PanScience Research piece examines on-premise AI economics and another the sovereign AI stack; this article does not repeat that analysis.
Capability and the Indic language question
Capability comparisons in enterprise settings should rest on the enterprise's own evaluation set, not on public leaderboards. That is particularly true for Indian languages.
Sarvam AI's Sarvam-M illustrates both the opportunity and the caution required. According to Sarvam's own blog post of 23 May 2025, Sarvam-M is a 24-billion-parameter model built on Mistral Small, which Sarvam describes as Apache 2.0 licensed, and it reports an average improvement of 20% on Indian language benchmarks over the base model, and an 86% improvement on a romanised Indian- language version of the GSM-8K maths benchmark. These figures are self-reported. They nonetheless show the mechanism that makes permissive open-weight models attractive in India: an Apache 2.0 base can be adapted for Indic languages and redistributed without negotiating with the original developer.
For an enterprise, the implication is procedural. Build an evaluation set from real queries in the languages and scripts customers actually use, including romanised Hindi and mixed-language text, and test both proprietary and open-weight candidates on it before deciding. A separate PanScience Research piece covers evaluation before deployment.
Support and the hidden operating burden
Open-weight models are free to download. They are not free to run. The operating burden includes serving infrastructure, throughput tuning, security patching of the inference stack, monitoring of quality and drift, and the decision of when to move to a newer model. Menlo's observation that open- source share fell as Llama releases slowed is a reminder that an open-weight strategy also depends on the continued investment of whoever publishes the weights. An enterprise that standardises on one open-weight family is exposed to that family's roadmap in much the same way that an API customer is exposed to a provider's.
Two mitigations recur in mature deployments. The first is to keep the model behind an abstraction layer, so that the application calls a stable internal interface and the model can be replaced. A separate PanScience Research piece on LLM gateways describes that layer. The second is to keep the enterprise's own assets, meaning retrieval indexes, permissions, evaluation sets and fine-tuning data, independent of any single model. Those assets carry over when the model changes. The model weights, whether open or proprietary, are the most replaceable part of the system.
What this looks like in practice
Within the PanScience Innovations portfolio, two ventures work on the control side of this decision. PanScience reports that Eigen provides on-premise AI for regulated industries, and that Insituate AI provides an on-premise enterprise retrieval-augmented generation and agent platform (both descriptions company-reported). The design pattern both descriptions imply is the one this article recommends: the enterprise's documents, access controls and audit trail stay inside its own environment, and the model is a component that can be chosen, and later replaced, on the basis of evaluated performance for the task.
The pattern does not require that every workload run on open weights. A common arrangement is a portfolio. Sensitive document workflows, such as contract review, credit analysis or clinical summaries, run on a self-hosted open-weight model inside the enterprise boundary. General productivity tasks with no regulated data use a proprietary API. The routing between them is governed by data classification, not by team preference.
A worked placement
Consider three workloads at a hypothetical Indian private-sector bank to show how the table resolves.
A customer-facing chatbot that answers questions about public product information carries little regulated data and needs strong conversational ability in several languages. Both gates pass for a proprietary API. If evaluation shows acceptable Indic performance, the API is likely the faster and cheaper route at uncertain volumes.
An internal tool that drafts credit memos from loan files processes personal and financial data. The control gate tilts strongly towards an enterprise-controlled deployment, and the task is narrow enough that a fine-tuned open-weight model may meet the evaluation threshold. Licence review then decides between Apache 2.0 and community-licensed candidates.
A developer coding assistant used on proprietary source code sits in between. The data is commercially sensitive but not personal. Many enterprises accept a proprietary provider here under an enterprise agreement that excludes training on inputs, because frontier coding capability is valuable and volumes are moderate.
The same bank therefore ends up with three different answers, which is the point. The open source LLM enterprise question is answered workload by workload.
Conclusion
The choice between open-weight and proprietary models is not ideological, and the adoption data does not settle it. In the US, enterprises have moved towards closed models. In India, data protection rules, sector regulation and language diversity give control and adaptability more weight. The defensible approach is to treat licence and control as gates, decide capability on the enterprise's own evaluation set, compare total cost only after that, and be honest about the support burden. Enterprises that keep their data, retrieval and evaluation assets independent of any one model retain the option to change their minds, which in a market moving this quickly is worth more than any single model choice.
Methodology and sources
This article draws on primary licence texts and published research opened by the author. Licence terms are taken from the Llama 3.1 Community License Agreement published by Meta (github.com/meta- llama/llama-models/blob/main/models/llama3_1/LICENSE), the Apache License 2.0 (apache.org/licenses/LICENSE-2.0), Mistral AI's announcement of Mistral Small 3 (mistral.ai/news/mistral-small-3) and the Gemma 2 model card on Hugging Face (huggingface.co/google/gemma-2-9b). The definition of open source AI is from the Open Source Initiative (opensource.org/ai/open-source-ai-definition). Enterprise adoption figures are from Menlo Ventures, 2025: The State of Generative AI in the Enterprise (menlovc.com/perspective/2025-the-state- of-generative-ai-in-the-enterprise), a survey of US decision-makers that should not be read as representative of India. Model drift evidence is from Chen, Zaharia and Zou (arxiv.org/abs/2307.09009). Sarvam-M figures are self-reported by Sarvam AI (sarvam.ai/blogs/sarvam-m). Indian regulatory references are to the DPDP Rules 2025 as summarised by PIB (static.pib.gov.in) and SCC Online (scconline.com), the RBI payment data storage circular of 6 April 2018 (rbi.org.in) and SEBI's cloud services framework of 6 March 2023 (sebi.gov.in). The decision table, the two decision rules and the worked bank example are the author's original analysis; the bank is hypothetical and illustrative. PanScience venture descriptions are company-reported from panscience.xyz. This article does not provide legal advice; licence terms should be reviewed by counsel against the current published text.