Thanks for the thoughtful engagement with our work. We appreciate your positive feedback and address your questions and suggestions below.

Regulatory Goals

It is somewhat implied that the goals the model is designed to address are “innovation,” model performance as measured by industry-designed benchmarks, and possibly competition related goals, rather than other regulatory goals that are also facilitated through open-sourcing such as model transparency and explainability related goals.

Defining Regulatory Goals.

We agree that the regulatory goals should be stated more explicitly. To handle this, we’ve moved the formalism of a Pareto-optimal policy (Def. 1) from the Appendix into 4.2. The regulator can choose any set of utility functions (i.e., $\alpha_1, \omega, U_D, U_G$) and any weighting of those utility functions to define regulatory objectives. At the same time, we avoid committing to a particular balance of objectives, since we want to illustrate the full space of possible regulatory approaches.

While the regulator could be modeled as a third player with an explicit utility function, we intentionally refrain from defining specific regulatory preferences. This enables flexible parameterization of the model according to different objectives, rather than constraining analysis to a particular social utility function that may not suit diverse regulatory contexts. We also want to note that providing a more granular definition of regulatory utility beyond what Def. 1 offers would invite the well-documented complexity of ranking and weighting various objectives from social choice and welfare aggregation literature.

Other Open-Sourcing Goals.

Our analysis assumes $\omega$ is a 1D variable that captures a property like model access. One could imagine using an equivalent model for reasoning about a spectrum of transparency or explainability measures. Sec. 5.2 now mentions that model transparency and explainability can be captured in addition to model access in future work: “While our analysis assumes that higher model openness and performance are generally beneficial, a regulator must consider safety risks associated with higher performance or market-wide loss scenarios, such as possible intermediate levels of openness where consumers may be worse off. This complexity suggests that defining openness as a multidimensional property may be valuable to capture factors beyond simple model access, such as documentation and explainability of model outputs.”

Modeling Assumptions

The paper does not adequately define or explain reputational benefits, how they are measured, or how the size or market power of a company might affect reputational benefits/premiums.

We roughly capture the issue of market power in $G$’s utility function by scaling the reputational premium by model performance. The $\epsilon \alpha_1$ term in $U_G$ means firms with superior models receive greater reputational benefits from openness.

To better explain reputational benefits, Sec. 2.2 now references extensive prior work on defining reputational benefits in the context of OSS contributions and commons-based production:

• “Coase’s Penguin, or, Linux and The Nature of the Firm” (2002), which discusses reputation as an “indirect appropriation mechanism.”
• “Why develop open-source software? The role of non-pecuniary benefits, monetary rewards, and open-source licence type” (2007), which profiles OSS developer motivations.
• “Social Status in an Open-Source Community” (2005), which has a case study on OSS reputation incentives.

In our case, $\epsilon$ captures reputational advantages within developer and research communities, which may aid in recruitment and third-party integration with the product. We don’t provide an exact approach for measuring $\epsilon$, though it should in general be low (at least $< 0.5$), given that reputational benefits generally do not exceed the amount of closed revenue that can be gained from monetizing a model.

as just one example, the model does not consider the impacts of venture capital funding which could allow generalists or specialists to tolerate lower revenue goals.

This is an interesting point. We have updated L102 to explicitly state the assumption that players abstain when their utility is negative. Venture capital might lower revenue goals because it provides capital that firms can sit on, but on the other hand, it tends to push companies towards high risk and fast growth. Modeling scenarios where players tolerate lower revenues in expectation of future profits requires introducing time variance and additional parameters specifying players’ tolerance for short-term losses. This would substantially increase model complexity and require additional assumptions about discount rates and availability of capital. We have therefore added modeling time variance and multi-firm competition as an important future direction in Sec. 5.2.

It also does not consider political forces, or other factors that might disrupt the model.

Social utility considerations of the regulator give some capacity for modeling political factors -- e.g., political pressures associated with setting the penalties and thresholds too high. We allude to this in L255 when discussing “wasted enforcement costs” associated with ineffective, high thresholds. However, this could be formalized alongside Def. 1 by applying a regulator penalty for different $(\theta, p)$ combinations: ${\arg\max}_{p, \theta}\ w^\top \mathbf{u} - \lambda \theta p \ \quad s.t.\ \|w\|_1=1, w_i>0, \forall i \in [d]$.

Our paper focuses on levers that the regulator can directly control (see Appx. C for our justifications for omitting considerations like deployment scale). We abstract away from exogenous factors to isolate causal relationships between policy instruments and equilibrium outcomes. However, we acknowledge that several factors may disrupt the model’s outcomes in practice, and future work can systematically characterize these factors or add stochasticity to examine how the model performs under uncertainty or unexpected market changes.

An overarching and relatively obvious weakness of this work is the game’s existence as a theoretical exercise that -- despite its addition of nuances prior work does not consider (such as incorporating impacts of openness along a spectrum rather than an open/closed binary) – does not consider several other real world factors

We acknowledge that our work relies on several simplifying assumptions, though these abstractions serve two important purposes. First, this approach follows established practices in economic modeling, where parsimony yields more robust and interpretable insights by isolating the most direct relationships between regulation and developer choices. Second, the abstract definitions of $\omega, \alpha_0$ are designed to provide flexibility over how such measures are constructed, allowing the model to remain general while accounting for relative magnitude. This abstraction is meant to accommodate different measurement capabilities, rather than tying the model to particular technical definitions – i.e., $\alpha_0$ may cover efficiency or latency considerations beyond benchmark accuracy alone.

Miscellaneous

Did the authors consider factoring-in the distinctions among how G, D, and regulators define model improvements or performance?

When constructing the model, we did consider how regulators may consider emissions targets or safety as part of performance, while $G$ and $D$ may focus more narrowly on commercial viability or benchmarks. Our model is designed to evaluate regulator-defined objectives, so we maintain $\alpha_0$ as a metric focused on task accuracy and efficiency and rely on the regulator’s utility function / discretion to incorporate broader environmental, safety, or equity concerns that diverge from firms' revenue-maximizing definition of performance. However, we recognize this is an important modeling consideration and have added a discussion in Sec. 5.1 about how regulators might choose different definitions of average performance: “Given that models may excel in certain domains while underperforming in others, regulators must determine whether to use composite performance metrics, domain-specific benchmarks, or capability-weighted averages to define model performance, with each approach reflecting different model development priorities.”

A minor point, but the authors could more directly explain and cite the Nash bargaining solution

We have added a citation on L188 and included a discussion of properties and limitations of the bargaining solutions: “Our analysis mainly examines Nash bargaining, which uniquely satisfies independence of utility origins and units, Pareto efficiency, symmetry, and independence of irrelevant alternatives. The two alternative bargaining solutions we consider (VM and Egalitarian) are also Paretian, symmetric, and independent of utility origins. However, generalists and specialists may arrive at non-standard bargaining agreements in practice which violate these properties, especially when utilities are expressed in currency and players have bounded rationality.”

We thank the reviewer for engaging carefully with our work. The feedback has helped us refine explanations of our model’s assumptions.

Robustness

I would like to see a specialist-side penalty term (or a brief formal argument for why it is negligible).

We derived closed-form results and ran simulations with a specialist-side penalty ($\phi_D$ includes a $p \mathbb{1}[\omega < \theta]$ term). The qualitative takeaways remain the same, since the solutions for ${\alpha_1}^\*$ and $\omega^\*$ do not change, but the specialist penalty increases $D$’s region of abstaining above the indifference curve because the feasibility condition becomes $\omega \leq \frac{1}{\delta - c_\omega}(\frac{p}{\alpha_0} + \delta - 1)$ instead of $\omega \leq \frac{1-\delta}{c_\omega - \delta}$. There’s also a slight effect on $\delta^*$ and joint utilities above the indifference curve because $U_D$ goes down by $p$, but this does not change our Pareto improvement and utility transfer findings. We have added the results to Appx. B.

I ask for (a) at least one empirical learning-curve plot or citation supporting the concavity assumption, and (b) a short discussion of how a second axis such as inference cost would change the results. Demonstrated robustness to alternative tuning curves or an extended two-dimensional game would lift my novelty and insight scores; silence on the issue would pull them down.

(a) We assume $U_D$ is concave in $\alpha_1$ because higher performance should only benefit $D$ up to a critical point before further investments in fine-tuning cause utility to taper off (costs go up but performance and revenue do not) -- see: Springer et al. “Overtrained Language Models Are Harder to Fine-Tune” (ICML 2025). We don’t claim anywhere that $U_G$ is concave, but we believe most utility functions should be concave because the optimum will always be on a boundary otherwise ($\omega^\*=0, \omega^\*=1$ and ${\alpha_1}^\*=\alpha_0, {\alpha_1}^\* = \infty$). Concavity guarantees $D$ will adopt high-performing models as-is, choosing $\alpha_1 = \alpha_0$ instead of always fine-tuning (addressing your concern with L136).

(b) We’ve moved Prop. 3 from Appx. D into the main body of the paper for an analytical way to inspect how something like inference ($c_\omega$) affects openness choices. We’ve also added discussion of inference costs and a 2D game (jointly optimizing $\omega^\*, {\alpha_0}^\*$) to the Appx.

Generalists also worry about efficiency. Reference the debate around DeepSeek, o3, o3-mini, and new nano-style models.

"[m]odel performance is the only feature in G's strategy space" describes prior work (the paper which introduced the framework of fine-tuning games). Our paper presents a 2D game with both openness and performance in $G$’s strategy space, though the main results analyze when $G$ decides an openness level given $\alpha_0$.

We capture efficiency through the $c_\omega$ constant (L145). The operation cost to performance ratio should be low in the case of high-capability, small models like those you cite but closer to 1 (or even > 1) for inefficient models. Our rationale for not representing efficiency as a strategic dimension is that translating investments into efficiency improvements is dependent on external technological and resource constraints (e.g., hardware innovation, energy capacity) and model-specific relationships between architecture choices and inference costs (consistent with the Xia et al. reference you provided). As noted in Appx. C, efficiency is an important dimension for future work, but our paper is primarily concerned with how model openness, as a policy-relevant dimension, affects players’ choices.

Weaknesses

The window of relevant performance changes over time? Once upon a time, GPT-3 was very high performing, but today we would call it low performing.

Figure 3(b) is meant to address this concern, as it shows that high vs. low performance is determined relative to the current generation of models.

who decides what is high or low performance?

This is relative (see above), but we’ve added clarification to Sec. 5.1: “Given that models may excel in certain domains while underperforming in others, regulators must determine whether to use composite performance metrics, domain-specific benchmarks, or capability-weighted averages to define model performance, with each approach reflecting different model development priorities.”

This analysis should minimally define performance, and to improve the modeling, introduce time variance.

Sec. 2.2 has been updated: “Performance represents a coarse measure of the model's accuracy on target tasks, generation speed and efficiency, and user satisfaction.”

We acknowledge that our work relies on several simplifying assumptions. This follows established practices in economic modeling, where parsimony yields more robust and clear insights. While we agree time variance is an important consideration, it substantially complicates the analysis (see response to Reviewer 1) without meaningfully strengthening our core theoretical insights about regulation. That said, we appreciate the modeling suggestions and have noted time variance as a future direction.

The paper treats "foundation models” as uniquely troublesome for open-source definitions, yet earlier software and ML precedents raise identical dilemmas.

We understand the concern and didn't mean to suggest they’re fully unique (see L607 in Appx.). Our position is that foundation models raise the stakes of open-source definitions because (1) they implicate a broader set of capabilities and downstream uses, (2) achieving reproducibility requires more than open code and data, and (3) high inference costs amplify the advantages of open-sourcing. We have incorporated Gupta et al. as a caveat to our terminology and rewritten Sec. 1 to make this position clearer.

It's worth citing "The Value of Open Source Software" by Hoffman et. al. [0]

Hoffman et al. was cited in our related works (L50).

Cost Modeling

Sec. 2.3 has been rewritten to distinguish when we’re referring to the structure of a utility function (broader classes of production, regulatory, and operation costs) vs. a specific functional form (quadratic cost and monotonic revenue).

There are already costs associated with documentation internally, as well as the cost of a proper internal model release process. Perhaps this is better modeled as log scaling rather than linear?

This is a good point. We ran numerical simulations with log scaling, and the results are qualitatively the same. $G$’s best response is similar to the one derived in Appx. B, except it requires solving for roots of $A \omega^3 + \omega^2, C (\text{without} -\alpha_0) \omega - \alpha_0$ because $\frac{\partial}{\partial \omega} \alpha_0 \log (\omega)= \alpha_0 \omega^{-1}$. The quadratic/cubic terms from revenue dominate the production cost in either case.

Currently this implies that operation costs hinge on the final performance reached after fine-tuning, not the baseline. Why does the generalist bear this cost?

For a closed model that offers fine-tuning via API (e.g., GPT‑4o), the generalist handles inference costs and prices this into per-token API rates. This also ensures operation costs sum to a constant between players ($c_\omega \alpha_1$).

L128: "safety risk management for open models". This is a regulatory cost, but you are trying to provide an example for production costs.

This example has been replaced.

Can you justify quadratic cost? Empirical fine-tuning curves often show super-linear returns for early steps.

We want to make sure we’re interpreting your point correctly. Could you clarify why super-linear returns for early steps contradicts quadratic cost scaling? Our understanding is that “super-linear returns [for model performance] for early steps” is captured by a curve like $\alpha_0 = \text{cost}^{1/k}$, where initial investments get much more mileage for performance. Our quadratic cost claim describes the relationship $\text{cost} = \alpha_0^{k}$, where marginal cost for each unit of improvement gets more expensive. These are the same equations. Is it possible that we’re talking about the same relationship, just with flipped axes?

L157: "higher openness increases production costs". There is ample evidence showing this to be false. Projects like YOLO, vLLM, etc. have benefited drastically from open-source contributions. Outside of ML, look at Docker, Redis, etc. Even within foundation models, improvements to Gemma have led to improvements in Gemini.

The line has been changed to clarify that higher openness increases production costs only for the particular product being offered at higher openness. We capture the benefits of open-source contributions through revenue rather than reduced production costs -- i.e., when an open model is improved by specialists to a higher level, $G$ recoups the increased production costs through higher revenue ($r(\alpha_1)$) because cheaper model access encourages specialists to invest more in $\alpha_1$.

Checklist

We can upload the code as Supplementary Material. CPU runtime depends on the granularity of simulations. A simulation to produce a set of plots like those in Figures 4 and 5 with a sweep over 100 penalties, 100 thresholds, and 100 $\delta$ values (100,000 parameter combinations) executes in 317.362s / ~5 min on a single CPU. Similarly:

• 150 $p$, 150 $\theta$, 100 $\delta \rightarrow$ 717.484s / ~12 min
• 200 $p$, 200 $\theta$, 100 $\delta \rightarrow$ 1470.59s / ~24 min

We were able to produce smooth plots at 200 x 200 x 100 granularity. For each plot in Appx. F, we used a sweep over 200 $\epsilon$, 200 $\alpha_0$, and 100 $\delta$, which executes in 1216.88s / ~20 min on a single CPU. We did not optimize for efficiency. Item 8 in the checklist has been updated with approximate lengths of runs and # of CPUs needed.

We appreciate the positive review and have addressed your questions below.

Questions

Are there other parameters that could lead to the same behavior as described in Figure 3 than those that you give?

Increasing $\alpha_0$ under no penalty always leads to more closed behavior as long as $\epsilon < 1$ and $c_\omega < 1$. For example, the openness trends in Figure 2 and Appendix F continue for higher values of $\alpha_0$ (we tested at $\alpha_0 = 10$ and $\alpha_0 = 100$). We require $\epsilon < 1$ because when reputational benefits always match or exceed closed revenue ($\epsilon=1$), $G$ will just open the model fully.

The behavior in Figure 3 also requires that $c_\omega < 1$ because if operation costs exceed any revenue $G$ can earn from model adoption, $G$ always fully opens the model or abstains at any performance level. $c_\omega < 1$ is a realistic assumption because developers can price the costs of inference into model offerings via API pricing or subscription charges.

As far as I understand, the model only captures a single $G$ and a single $D$. How would many $G$ to many $D$ change the analysis. Would it be a worthwhile analysis? Is this future work?

Yes, this definitely seems like worthwhile analysis. We have noted modeling competition between multiple players as a future direction.

Extension to multiple $G$ with varying $\alpha_0$ levels. This can only be done via simulation. In the first stage of backward induction, $D$ would need to solve multiple optimization problems and choose the $G$ that maximizes their utility payoff (potentially with switching costs). Both $\alpha_0$ and $c_\omega$ would be specific to each $G$.

Extension to multiple $D$. $G$’s revenue would be the sum of all $\alpha_1$ for the $D$ who adopt their model. However, this extension is trickier because it requires modelling multiple $D$ with different valuations and priorities; e.g., one specialist might prefer cheaper operation costs if inference demand is high, while another tolerates high operation costs for better model accuracy due to domain-specific requirements. Future work could model the strategic dynamics of $G$ differentiating their product along different dimensions -- higher model openness vs. higher performance -- to target a specific subset of specialists (see: Giarratana & Fosfuri, “Product Strategies and Survival in Schumpeterian Environments: Evidence from the US Security Software Industry”).

Modeling multiple $G$ and $D$ would require solving a separate bargain for each ($G, D$) pairing. Since we identify $\delta^*$ via grid search over the interval [0,1] and there are $G/D$-specific cost functions with multiple players, this would be intractable as add-on analysis for the paper.

Why is there not a constant term specifying the cost in the production cost term $\alpha_0\omega$? As I read the term, both $\alpha_0$ and $\omega$ are rates. When they are added together with operation and regulatory which both contains constants ($c_w$ and $p$), then this would not yield the correct result. Am I wrong? What is it that I do not understand?

It’s a good idea to include the constant terms more explicitly. We had analyzed the version where constants for production and regulatory costs are normalized to 1 and the $c_\omega$ constant compares between operation costs and revenue. However, we realize we can provide more general results where these constants are any positive number. We have now included all constant terms into closed-form solutions and our numerical simulations. An important empirical direction would be estimating appropriate values for the two constants based on how regulatory requirements map to dollar value penalties, how documentation costs correspond to inference costs, etc.

Clarifications

Many OSS licenses do not restrict use, but some do, especially those that have twin licenses where academic and non-commercial use is OK but commercial use is restricted.

These distinctions seem significant, so we have updated L23 to reflect nuances in OSS licensing. We had originally written “no use restrictions” based on the Open Source Initiative definition of OSS.

Fully open models, as described in lines 26 and 27, should also share the code used for training and inference/reasoning. If not, they are not reproducible (which should be the main goal of open-sourcing foundation models).

This has been noted in the text, with supporting examples drawn from Gundersen (2021).

Weaknesses

We have revised Section 2 for clarity and changed Section 5 to rearticulate findings as high-level considerations for regulatory bodies without referencing player utilities or Pareto improvements.

I would like a discussion on negative examples. Which scenarios will the model fail to capture?

See Appendix C for our justifications for omitting considerations like deployment scale. To more explicitly discuss negative examples, the discussion in Section 5.2 has been revised with more examples: “The two-player framework also overlooks important social utility considerations. While our analysis assumes that higher model openness and performance are generally beneficial, a regulator must consider safety risks associated with higher performance or market-wide loss scenarios, such as possible intermediate levels of openness where consumers may be worse off. This complexity suggests that defining openness as a multidimensional property may be valuable to capture factors beyond simple model access, such as documentation and explainability of model outputs. Additionally, modeling multi-firm competition between a closed-source incumbent and multiple generalists can reveal when established firms pivot to open-source strategies and how timing of market entry affects whether entrants adopt open-source approaches.”