ModelingToolkit V11 Library Split and Licensing, Community Feedback Requested

Community
, ,
1

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)

34 Likes
Project for Intermediates - Advance
2

Licensing parts under the AGPL seems like a reasonable solution, but be careful with overdoing this. If there is some functionality that provides a key financial/strategic advantage to JuliaHub, better to just make it AGPL or proprietary to begin if possible. Still, I understand the funding situation for research is difficult right now and this likely couldn’t have been predicted. JuliaHub also obviously deserves to benefit from the massive investment it makes into the Julia ecosystem at large.

That being said, its rather important to be reasonably assured the things I’m building on won’t be suddenly incompatible with commercial use. I don’t use MTK but started building commercial products on other parts of the SciML ecosystem. Yes, there are companies that only take with open source, but if at all possible try to do things in a way that doesn’t hurt commercial use indiscriminately. After reading the entire post I don’t think I have any reason to be worried, but thought I should at least give my two cents.

5 Likes
3

Thank you very much for the incredible SciML and ModelingToolkit ecosystem. This is huge asset for Julia as a language. It is great to see how much thought is going in to making this sustainable going forward.
Are you considering a dual license model for companies that have “AGPL-problems”?

6 Likes
4

Sounds great to me. I have been moving my packages to use more restrictive copyleft licenses because I find the MIT license too permissive: companies can easily take your code, improve it, and not share back the contributions. Using an AGPL license will make it possible to make great OSS without having the fear that some big company doesn’t contribute back. (Or if they do they can get a big fine :wink: ).

I think a lot of people have been using the MIT license without thinking too much about it, because everyone uses it. But there are good reasons to use a copyleft license, and I think people should consider it more.

3 Likes
5

If I read this correctly MIT is still preferred, but the switch to AGPL is made to improve the chances for neccesary funding.

Switching from MIT to AGPL is easy, but the other way is hard. I can imagine the situation changing in the future, where MIT would actually make it easier to attract funding, or otherwise becomes problematic. Have you considered using contributor license agreements (CLA) to keep the option of going back open?

5 Likes
6

I’d be curious to learn which companies fit into this category. Could this information be disclosed?

4 Likes
7

I don’t get this part. structural_simplify / mtkcompile must be called on a MTK system for MTK to generate code for it, so how can the base library generate code without the addon library?

4 Likes
8

Generating the code and simplifying it are two different steps. You can create a model and simulate it without simplifying it. It is just slow.

1 Like
9

I think releasing advanced parts of MTK under AGPL is a good approach and I much prefer it to the (failed) attempt of JuliaSimCompiler.

I too wonder about the implications on the structural simplification thing. Would that mean that all structural simplification code, even basic tearing and alias elimination would end up in the AGPL extension? I think that would make base MTKBase essentially useless, because you’d end up with DAE constraints for every single intermediate variable, of which there are plenty for any non-trivial system. For example, Symbolz.jl seems to depend on mtkcompile despite beeing listed as one of the potential MTKBase users.
I’d much prefer to have baseline tearing and alias detection still present in MTKBase, which could be extended by more advanced restructuring and additional compiler passes in the AGPL libs.
Also, would the system for extending the simplification pipeline itself live in MTKBase? So would it be possible to have community driven, relativly basic tearing implementation which plays nice with MTKBase?

What does AGPL means for usage without redistribution? So lets say a commercial entity uses MTK for simulations during product development, but not shipping any software components or SAAS products. Would that be fine?

4 Likes
10

Hi everyone. Thank you for the good and helpful questions and comments so far.

I think it makes sense for the steering council to collate these, discuss, and put together a public faq to answer them as best we can. We can then link it here for continued discussion.

3 Likes
11

I’m not doing anything with MTK, so take this with a heap of salt from an outsider.

I agree that it is super important to make this change reversible. This means at the very least CLAs for outside contributors, because otherwise the adage about fishing piss out of a swimming pool applies.

It also means that there needs to be at least one entity that has the unambiguous right to re/sub-license under a less restrictive license (afaiu multiple entities could have that capability).

And this entity also needs the necessary internal infrastructure:

At many corporations, it is an absolute pain to get legal to sign off on open-sourcing anything. Not because the corporation objects, but rather because it has a pocket-veto on open-sourcing of components, and “handle weird requests by some rando engineer” is something that many companies institutionally suck at.

(in fact many companies unintentionally pocket-veto very benign OSS contributions – nobody can’t be arsed to take responsibility for sign off on a CLA to upstream some internally developed bugfix, and the engineer doesn’t have the standing to sign)

That doesn’t even touch the can of worms that is fiduciary duty to investors or creditors: E.g. you may come into the situation where all people at juliahub would individually support some lifting of license restrictions, but the company just can’t do it.

================

A probably not so uncommon experience from my dayjob: We are happily using unmodified library xyz in (a minor component of) our mainly saas product. Alas, a later review finds that xyz is GPL and not LGPL, and some customer wants to buy on-prem instead of cloud. We look into paying xyz for a license, but they’re not interested – and probably not even capable, because they accepted outside / open-source contributions under GPL without CLA (contributor license agreement). Pain ensues.

I think you should be clear on your goals: Is this to force large corporate users to contribute code back? Or are you OK with such users contributing back in terms of money / licensing fees? To whom would they pay their licensing fees? Will juliahub itself have access to the code under MIT-style license, in order to enable their and their licensees commercial offerings?

Or is the goal to potentially strangle some potentially competing commercial offerings? Which would be totally fair, not judging, you just need to be transparent about it.

Is your commercial license plan in the style of “if you are our intended customer, you get to pay us; if you are not our intended customer, then please go away”, or rather “you get to use MTK also in commercial / AGPL-incompatible settings. Whether you need to pay for that depends on how you fit into our commercial offerings.”

This is a big difference. Just recall all the issues you have with books that are out-of-print.

To give a hypothetical example:

Suppose I set up some cool thing that uses both the AGPL’ed MTK components, and some GPLv2’ed library. The resulting work can probably not be redistributed at all (AGPL and GPL2 are incompatible) and I probably cannot offer (free public) internet access to the resulting software running on the workstation under my desk.

The situation would be much better if one could ask some copyright holder for an exception (i.e. a limited non-redistributable license), and the exception would be granted unless it interferes with juliahub’s business interests (as opposed to “denied, unless it aligns with juliahub’s business interests”).

8 Likes
12

The vast majority of SciML is focused on topics which have gotten traditional research funding. Numerical solvers for (differential) equations, (scientific) machine learning, differentiable programming, etc. are all topics which have traditional funding areas in the NSF mathematics, NIH biomathematics, etc. domains. We’ve had plenty of PhD students participate in developing new ODE solvers, nonlinear solvers, adjoint methods, etc. as part of their work at MIT. These have had students and academic contributors since the first day the code went open.

That is in very stark contrast to ModelingToolkit which is a model compiler, something that doesn’t fit squarely within the funding regimes of traditional academic funding, and not necessarily a common research topic at all (I know like two labs doing this, and they are the ones building OpenModelica, and are rather small and underfunded themselves). Most of the MTK related to the DAE portions has not received outside contributions in the last 6 years, which is a very interesting note given that we have about 100 unique contributors every year to SciML. This space is a bit of an anomaly that isn’t research enough for most people to call it research, but is still highly mathematical so it’s not like every Javascript developer can chime in. The grants “in this space” are thus not really in this space, they tend to be around commercializable elements where a compiler able to generate code that can build a real-world controller and do things in aerospace/automotive, which then comes from defense, ARPAs, etc. which have sustainability requirements to prove the project can be self-funded in the future, which effectively means proof of a commercial model.

I’ll note in passing that Symbolics stuff is quite underfunded from a government standpoint as well (with the MTK symbolic-numerics then being even moreso), but it fits more inline with general PhD student research and we still have students in that space so it generally gets outside contributors. Symbolic ecosystems very naturally split by function anyways, where a simplify or rootfind function can very easily live in a separate package, with things like SymbolicIntegration.jl, Groebner.jl, etc. all living as separate little pieces, so “most” of the difficult and interesting work of the Symbolics space is in add-ons and it makes sense to have the core just be easily accessible as a single building block for “what is a symbolic expression” common element.

Yes, this is related to Dyad licensing and we can discuss other approaches as well. The Dyad license should update to clarify this in the near future.

I agree that it should be considered. I think defaulting to MIT is good for research projects that are “one and done” and potentially something you’d rewrite in the future anyways, but for things that are infrastructure, giving licenses a bit more thought is probably required.

Something that made me consider it more was the fact that there are some really strong open source communities that attribute a good chunk of their success to this license choice. It’s talked about here:

Grafana, Forem, Mattermost, etc. are projects that we use in the Julia community even, so a lot of the tools we’re using daily that are robust open source projects with a company backing actually have been built via this AGPL style licensing. I hope to get as many contributors into the MTK project and these other communities are some good models that are working in that respect.

All of the code in SciML is still MIT licensed. The AGPL parts are libraries in JuliaHub’s JuliaComputing Github organization.

Yes, the JuliaComputing Github organization will be handling CLAs to make relicensing to MIT possible.

I don’t think I can give the concrete names and projects publicly.

Technical details. The new MTK v11 has a structural_simplify / mtkcompile pipeline that has a base system for the code generation, and it has a flexible pass system that transforms the equations before codegen. The MTKBase version has some simple transformations, like lowering ODEs to first order and outlining explicit algebraic equations to observed variables. Then other libraries can define compiler passes to the API, of which things like ModelingToolkitTearing.jl and StateSelection.jl are specific modifications in the pipeline which can detect if the system is a certain type of DAE and can transform them into easier to solve DAEs. SymbolicUtils.jl v4 then has a code generation with a flexible pass generation as well, where it would take the resulting equations and just spit out a simple Julia code. SymbolicCompilerPasses.jl then defines some new compiler passes for doing things like CSE of array equations, and we hope to soon make it do things like integrate with Reactant to auto-GPU equations generated from MTK/Symbolics.

So MTKBase runs mtkcompile with its built-in passes. MTK itself then sets up extra dependencies and preferences and such so that mtkcompile then does some of the more advanced passes by default, effectively making ModelingToolkitTearing.jl, StateSelection.jl, SymbolcCompilerPasses.jl, etc. all automatic. And I’ll mention that there is no restriction here to just these passes, if other compiler passes get made that do things like symbolically solve a subset of the equations, then having that as a separate library which gets tied into MTK could make sense (depends on how fast it runs etc. because if symbolically solving integrals takes a few minutes you probably want to bypass that by default :sweat_smile: but it’s just an example… something like Buckingham-PI might be a better example). This means that MTKBase is a lean version, and then loading the MTK version basically tries to read your mind and do the best mtkcompile it can do by default.

Even if there weren’t license things, this is a better architectural design. For folks not doing acausal modeling with high index DAEs (which is probably like 90% of MTK users), you can just use MTKBase and you’ll see a pretty dramatic load time / compile time improvement.

And then having this as a set of well-defined passes opens up the possibility for research projects in things like optimal tearing algorithms (though I’ll point back up to the top part here that I have tried to get optimal tearing as a funded research thing at MIT for a few years now with no bite, also no PhD students were ever interested, so :person_shrugging: I’m not sure if that will ever happen but that is an example of an alternative tearing that could be implemented that’s less focused on scaling to large equations but instead more about having provable minimality). Alternative codegen outlets like Reactant codegen on Symbolic expressions is just one cool one that we’re already looking into.

I’ll note that a lot of the future work in the SymBoltz.jl paper https://arxiv.org/pdf/2509.24740 can be implemented using the compiler pass API as a nice maintainable way to implement them as general passes.

Yeah… we are still about a year behind, not because of the mathematical ideas themselves, but the fact of having two separate repos… didn’t work. Basically once a bug gets fixed in one version of the compiler, no one has the appetite to spend a few days fix it in the other version of the compiler because they just put the work in. So some folks do a few things to MTK, some do a few to JuliaSimCompiler, and over time each model only works on one of the compilers that fixed the related bugs. That just makes everything feel buggy. A goal here was to have just a single compiler infrastructure so that never happens again.

The utility is very domain-specific. Most domains using ModelingToolkit effectively never make the high-index DAEs that require the structural transformations passes. Catalyst.jl is a good example of this, where even in the mode to generate conservation laws its all linear algebraic equations in an algebraic variable and thus a simple index-1 DAE, so the structural transformation approach does little change. PDE libraries like MethodOfLines.jl just have index-1 DAEs. (unless you specifically add high index algebraic equations). These just solve with the same mass-matrix ODE solver directly and are stable.

My understanding from the SymBoltz.jl paper https://arxiv.org/pdf/2509.24740 and code is that it’s all ODEs, in which case the MTKBase no-pass behavior is actually sufficient.

This is THE very advanced code and the only part that was made AGPL. It is extremely advanced partially because we didn’t have modular passes before we just had one pipeline, but also it’s just very difficult to get it correct so it naturally grow in complexity overtime. There’s just so much to do here. This is the little piece that is used by 10% of the use cases but requires significantly more effort to get correct.

Yeah that’s perfectly fine. It would be cool to see one. And as mentioned earlier, I’d look into an optimal tearing implementation as a research project that uses a SAT solver to solve the NP-hard problem and get a provably minimal tearing. Alternative tearing implementations are things that I hope result from this modularizing of the compiler.

Though, I will say I wouldn’t get the hopes up too much for difficult cases… we’re about 6 years into working on this algorithm and the version that is there is still insufficient for most difficult problems like Multibody.jl system (which is why JuliaSimCompiler.jl was required for Multibody, because it made some modifications to this space that never got upstreamed). The big purpose for these changes was to be able to get more funding and backing of the project to be able to finally properly grow this algorithm to something that is robust, something that was very difficult when grants and other funding were rejected due to the licensing being too permissive.

But yeah, it would be interesting to see a version that say doesn’t do partial state selection and does a simple Pantelides. It would work on most of the small DAE cases, but it would fail on most things like multibody, two-phase flows, etc. but it would get things like RC circuit. And it’d probably compile faster, so in a best of all worlds kind of scenario this code should exist and we should switch to it whenever we detect the system is simple enough. Th biggest issue here is just bodies: we have enough of an issue getting 1 person to work on just one structural transformation pass (and to reiterate, this change is specifically try and change that and make this area get more contributions in), so then trying to get a second person to start working on another structural transformation pass just hasn’t happened in the last 6 years. But it could :person_shrugging: , and again I think the most likely version of it would be if the optimal tearing project ever gets off the ground (it would also have a nice separation because OT would be very robust but have terrible scaling to large equations, so it would be a great tool for those small cases and help with debugging / building better heuristic algorithms… but I digress).

Oh I was just going top to bottom and had already written a lot so I’ll just click send here :sweat_smile: :sweat_smile: :sweat_smile: :sweat_smile: :sweat_smile: :sweat_smile: :sweat_smile: though I’ll take a quick look at the one right below while I’m on.

We can craft detailed responses in full etc. etc. but this is top of mind kinds of things, just my own opinion, and I thought it’s best to share more than less so might as well hit the reply button.

JuliaHub’s plan is to make sure any of its AGPL pieces have proper CLAs (which is why they are not in the SciML Github organization) and for the commercial license for these parts to be a part of the Dyad license.

17 Likes
13

Thanks for communicating this. I think this is a fair compromise given the situation and after reading some of Chris’s comments I can only support it. MTK is an amazing tool that we have all benefitted greatly from, and we should do everything to guarantee its existence and development.

Few small questions:

Does ‘hosted at JuliaHub’ mean it will not be accessible from GitHub? Will it still be possible to make contributions to / create issues in the GPL part of MTK?

What is the future of the MTK standard library, will it still be maintained? Personally I think we need to maintain a good standard library with all the basic components. The community can pitch in here because it is not difficult to do.

3 Likes
14

I’m not that familiar with the different kinds of license and I only use MTK within my research. In this academic context, would it be limiting ?

15
  1. structural_simplify() is at the core of MTK. As far as I know, every user of MTK uses it, it’s in the tutorials, etc. Without it, the MIT compiler will only work for toy examples. This isn’t a quantitative, but a qualitative distinction when it comes to systems that cannot meet realtime guarantees (e.g. audio). For systems with e.g. 300 states, libraries are needed. This cannot realistically be done manually.
  2. Everyone so far mentioned large companies, without consideration for the small companies or hobbyists that are building on top of MTK. I believe there are way more of these than megacorps like ANSYS. In that case, the relicensing feels like a rug pull, potentially invalidating years of effort. These risks were factored in when choosing an MIT licensed MTK instead of other (potentially commercial) options.
  3. What is considered small? An exception should apply for entities under 25000 euros of annual revenue. This won’t affect anyone serious: large companies would get a proper license rather than deal with licensing minutiae. Realistically, JuliaHub won’t recoup their attorney costs by going after parties without revenue. An assurance of a commercial license that is both cheap and available for medium entities would also help. For comparison, a Mathematica Desktop Perpetual hobbyist license is about 400 euros and includes the full symbolic simplification capabilities.
  4. What does “JuliaHub hosted” mean in this context? Can we run the AGPL compiler locally or is it strictly offered as a SaaS?
  5. Are artifacts generated by the AGPL compiler bound by AGPL? Traditionally, compilers are under a different license than their artifacts. For example, the gcc compiler is under GPL, but includes a “runtime exception” for compiled programs.
  6. The situation raises concerns about the continued future of MTK. You mention in the GitHub issue that you require “a 15 million private donation and 2 full time maintainers”. In light of that, how can we be assured that you (or any potential JuliaHub acquirers, it’s VC-funded) won’t change the license further?
  7. Is this simply “to satisfy grant reviewers and other funders” as you claim, or will JuliaHub go after small entities? I have good faith in the stewards of this project, but a public and official statement would go a long way to alleviate any concerns.
  8. I know you’re going to say “get a lawyer” for this one. However, as a small entity that in itself is challenging, so I have to ask. Suppose someone develops a commercial version of ModelingToolkitDesigner.jl (GitHub - bradcarman/ModelingToolkitDesigner.jl: A helper tool for visualizing and editing a ModelingToolkit.jl system connections). This version only generates MTK systems and does not bundle any (MIT or AGPL) version of ModelingToolkit. The software functions by itself, thus does not meet the AGPL requirements for linking MTK. Optionally, the end user may download an AGPL version of MTK, which is then linked (by the end user) to the Designer frontend. Therefore, the company does not “distribute” the AGPL version as part of a binary. The end user is bound by the AGPL, but does not distribute anything. Did I get all that correctly?
  9. Deploying Julia is already hard (Review: Julia trimming for Advent of Code 2025). Any additional licensing burdens (including attorney consultation fees) contribute to the problem. Similar concerns surround Modular and their Mojo/MAX distinction.
  10. Circuit simulation is index-1 DAEs, so MTKBase should suffice, right?

Proposal:

  • Clear & irrevocable license grant for small entities
  • Exception for compiled artifacts
  • Make the AGPL library fully available for local building & JuliaC/PackageCompiler deployment
7 Likes
16

Thank you very much for discussing these issues upfront! I only started using MTK/Catalyst, and being mostly research focused, I am comfortable with these ideas.

But let me share some experience with dual (AGPL+Commercial) licensing of the TetGen mesh generator. See TetGen.jl for more info. I was/am mostly responsible for developing the license model with lots of trial and error.

The project started at my institute when we were able to hire the author after he posted an initial version of the code on the internet. Open source was a tough sell internally then due to mostly old style thinking about research software licensing among the top management.

So we started with an academic (non OSS) and commercial dual licensing approach in order to be able to prove that it is possible to get money with freely available code. After a couple of flame wars we switched to AGPLv3/commercial which worked out very well. AGPL was chosen due to the fact that it also covers SAAS.

We got many international top level companies as commercial customers. We would never have reached them without being visible by open sourcing the code. Assuming that the single developer has worked half of his time on the code, the revenues more than covered development effort (in the financial dimension). The price cap was essentially due to the fact that licenses were sold for the code “as-is”, without any service. We did offer a finite number of service/consulting hours for an additional fee. If I recall properly this was used ony once.

The pricing model converged to the following: One large upfront lump sum + 20% yearly maintenance. Maintenance just meant the right to use newer versions under the same license. Without 5 years of new versions, maintenance contracts would automatically terminate. As for the amount, we distinguished between large companies and startups, pricing quotes were always upon request. We had the commercial license template designed by a law firm.

Nowadays the project is in a transition state, as the developer left our institute, see the new upstream repo TetGen/TetGen: Primary development repository for the TetGen mesh generator - Codeberg.org . We set up a CLA which essentially requires contributors to provide their code under both MIT/AGPL in oder to be open for the continuation of the dual licensing model.

10 Likes
17

I think Option 1 makes a lot of sense given that the current contributors are largely sponsored or employed by JuliaHub.

I would like to see a clear demarcation of the last MIT licensed release and the first AGPL release. For example, a major version number increment may be warranted as dependents should switch to the AGPL licensed versions intentionally.

It may be nice to later relicense old versions of MTK components under MIT after some years, so I would also like to see contributor license agreements in place to ensure this option is available. The ecosystem still needs to compete with permissively licensed equivalents in the scipy and scikit Python ecosystems after all. I am also sure there may be interest in commercial licensing.

A MIT-licensed fork with current but not new features should be possible to maintain if there is community interest and volunteers. It is not clear to me that currently exists.

The future of Julia very much depends on a sustainable funding model for JuliaHub, so I am glad to see thought put into this transition.

4 Likes
18

@mkitti the changes would begin with the next breaking release (MTK 11.0). They would not be made as part of the current MTK 10 set of releases.

1 Like
19

@GeorgeGkountouras, regarding structural_simplify, there are a variety of ModelingToolkit system types for which it is not needed, or particularly useful. Catalyst.jl, which I work on, is one such case. It generally is used to create purely ODE, SDE, or jump process models, none of which have historically benefited from or needed structural_simplify (even for systems with thousands of states). But I certainly understand your concern with regards to acausal models relying on it.

My understanding is that one of the benefits of the MTK 11 split is that MTKBase would now have a much more flexible system to add compiler passes and transformations (which the AGPL libraries themselves will use to interface with MTKBase). So there is nothing preventing someone else from developing more permissively licensed alternatives to the AGPL components. But of course someone has to want, and have the resources to do, this work. If someone wanted to take on such a project they would at least have the benefit of having access to the MIT-licensed MTK 10 versions of such code as a starting point.

I believe all the AGPL libraries will be accessible to install as normal packages within the general registry, but hopefully @ChrisRackauckas can comment more on that aspect of your questions.

Regarding AGPL implications, as you said speaking with a lawyer is the only response we can give. The Steering Council asked a lawyer ourselves, via NumFocus, for a public statement we could give about the impact of having an AGPL license for the JuliaHub extension library on downstream users and developers, but unfortunately we can not provide any substantive guidance about this (and will not be able to).

This month in Julia world - 2025-11
20

@sablonl unfortunately, this is something you will need to research for yourself, as we can’t really give good guidance about it.