Dear MTK Community,

I am posting today in my role as a member of the SciML Steering Council about a decision the council has been discussing regarding the future of ModelingToolkit (MTK). As this decision impacts the MTK community, we wanted to solicit community feedback before we officially make the changes discussed below.

Background:

ModelingToolkit is one of SciML’s most popular and widely used libraries, second only to DifferentialEquations.jl. It provides an acausal symbolic modeling framework for a large variety of mathematical models, which can then be converted to optimized inputs for use with DifferentialEquations.jl and other SciML solvers. A number of open source libraries have been built on top of MTK, including Catalyst.jl, NeuralPDE.jl, SymBoltz.jl, and others. Likewise, a number of commercial products have also been built on top of MTK, including Dyad, Neuroblox.jl, and Pumas.

The overwhelming majority of MTK development has been carried out by JuliaHub employees as part of their employment there, see https://github.com/SciML/ModelingToolkit.jl/graphs/contributors and note that the most prolific contributors were associated with JuliaHub for most of their work contributing to MTK.

Issue:

JuliaHub has communicated to the steering council the following concern: increasingly, several large companies are leveraging MTK for commercial work, but not participating in the open source ecosystem or contributing back improvements. JuliaHub has indicated that this trend, combined with lack of available grant funding outside of JuliaHub for open source development of MTK, has created a situation where JuliaHub cannot continue development of what they consider “product-like” MTK components under MIT licensing. Existing contributions cannot and would not be relicensed, but going forward, JuliaHub will not contribute the work of its employees to what they consider the more product-like parts of MTK under the MIT license.

Realistically, based on the current contributor base, the SciML steering council feels that if JuliaHub is not able to continue supporting one or more full-time open source MTK developers, any SciML-based open source MTK library will likely stop being actively developed.

Disclosure:

Three of the five SciML steering council members have financial conflicts with regard to this issue due to being JuliaHub employees or employees of companies in which JuliaHub has a financial interest. These members have recused themselves from any vote on how SciML should proceed, but are participating in our council discussions (per the SciML governance policy).

Options for MTK’s Continued Open Source Development:

JuliaHub has communicated to the SciML steering council several possible paths forward that address their concerns including:

1. JuliaHub’s future contributions to what they consider the more “product-like” parts of MTK v11+, which are being used by other large companies, will be via a separate JuliaHub-hosted open source AGPL plugin/extension library. An MIT MTKBase library will remain hosted at SciML. Others can continue to make contributions to, and use, MTKBase under the original MIT license. The overall effect, however, is that some current components of MTK will only be available under an AGPL license in MTK 11+.
2. JuliaHub switches all development to a fork of MTK. SciML and the community would then be responsible for all future development of an MIT MTK from the current MTK 10 code base.

JuliaHub has communicated to us that the first path is their preferred option since it allows them to continue actively developing all of MTK as an open source project. Anyone who uses only the base MIT library would have no new license restrictions on what they can do with their own libraries, scripts, or products. As mentioned above, given the current contributor base, the SciML steering council feels option 2 would result in the SciML-hosted MTK stopping active development and ultimately being archived.

JuliaHub has indicated that they feel the decision on how to structure this should involve the steering council and community. Based on the preceding considerations, the SciML steering council is inclined to proceed with the following plan for MTK 11+:

• MTK 11 will be split into a base MTK library (MTKBase) that is MIT, and a JuliaHub-hosted and developed MTK add-on library that will be licensed as AGPL.
• The base library will contain all system definitions, and be able to generate code for DAEs, jump processes, ODEs, and SDEs for use with SciML solvers.
• The AGPL JuliaHub-hosted library will contain the components that are currently used to optimize acausal models, such as the structural_simplify command to simplify ODE and DAE models. It will also include a variety of current and future optimizing compiler passes and code-generation components. This includes new components in MTK 11 for generating fast vectorized code for large systems.

Please see the draft blog post Chris Rackauckas has created for more details on the split.

License Implications:

Libraries, notebooks, and scripts that only use the new MIT MTKBase library will have no new restrictions, and can continue to use whatever license they want. The goal of the split is that libraries that are not designed for acausal modeling, such as Catalyst, NeuralPDE, and SymBoltz, should be able to work with the MIT MTKBase library with no loss of functionality, and have no AGPL dependencies when updating to version 11.

In contrast, the AGPL is a significantly more restrictive open source license than MTK’s current MIT license. For example, modifications to AGPL libraries must be shared if the library is distributed to others or used to implement a network service that is made available to others. The exact implications of using JuliaHub’s MTK AGPL add-on libraries will depend on how one is using them. Note that many companies, and some institutions, have policies against AGPL software due to the AGPL’s restrictions. As non-lawyers, we encourage consulting with legal counsel about how AGPL would affect your specific use case if this is a concern.

Request

While the steering council feels this is the best approach for the SciML community, we fully acknowledge that there could be even better solutions we overlooked or aspects of the split we have not sufficiently thought out. We would therefore like to use this thread to solicit feedback from MTK and SciML developers and users.

Implications for Other SciML Libraries

A natural concern might be whether similar issues could arise for other SciML libraries. We do not anticipate this happening, even for those libraries for which JuliaHub employees are the (current) primary contributors. The reason for this is that most other SciML libraries are focused on numerical algorithms, while MTK is a symbolic-numeric compiler. The former are much easier to obtain funding for as part of research grants, and can more easily serve as components in Ph.D. and Master’s students’ theses, thereby providing a natural contributor base outside of JuliaHub. They have had many academic-based contributors to drive their development in the past. In contrast, because MTK is essentially a compiler, and has not been able to secure standard research grant funding that can support graduate students and their research careers, the overwhelming majority of its developer contributions have come from JuliaHub employees to enable JuliaHub’s commercial offerings.

Please keep your responses to constructive suggestions/feedback for the council. If you have other aspects of this situation you would like to discuss, please feel free to open separate threads. Please also feel free to advertise this thread on other platforms – we would like to receive as much feedback as possible from the broader SciML community. We plan to collect feedback through December 10th. After reviewing community input, the council will make a final decision and communicate it to the community and JuliaHub.

Thank you very much,

Samuel Isaacson (Boston University), on behalf of my fellow SciML Steering Council members:

Aayush Sabharwal (JuliaHub)

Torkel Lohman (University of Oxford)

Chris Rackauckas (JuliaHub, Massachusetts Institute of Technology, PumasAI)

David Müller-Widmann (PumasAI)