# ModelingToolkit V11 Library Split and Licensing, Community Feedback Requested **URL:** \ **Category:** Community\ **Tags:** community, sciml, modelingtoolkit\ **Created:** [December 6, 2025, 1:37am UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396 "2025-12-06T01:37:26Z")\ **Posts on this page:** 20\ **Page:** 4

**Author:** ![isaacsas](https://avatars.discourse-cdn.com/v4/letter/i/f6c823/32.png) [@isaacsas](https://discourse.julialang.org/u/isaacsas)\ **Post date:** [December 9, 2025, 3:14pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/61 "2025-12-09T15:14:28Z")

At the level of the SciML Steering Council it was never discussed – JuliaHub communicated to us the desire to use AGPL. As I said above, we discussed and suggested more permissive license alternatives but they were not considered sufficient to address the concerns of my original post. To be honest, I have not even heard of the EUPL license before. ---

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\ **Post date:** [December 9, 2025, 3:37pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/62 "2025-12-09T15:37:51Z")

This recent blog is highly relevant to the core issues in this thread: [https://thenewstack.io/the-reality-of-open-source-more-puppies-less-beer/](https://thenewstack.io/the-reality-of-open-source-more-puppies-less-beer/) ---

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\ **Post date:** [December 9, 2025, 5:09pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/63 "2025-12-09T17:09:10Z")

It may be a moot point since it seems like AGPL has already been decided, but one issue for could be Article 15 of the EUPL: _15. Applicable Law_ _Without prejudice to specific agreement between parties,_ _— this Licence shall be governed by the law of the European Union Member State where the Licensor has his seat, resides or has his registered office,_ _— this licence shall be governed by Belgian law if the Licensor has no seat, residence or registered office inside a European Union Member State._ My immediate question would be, how does this clause affect non-EU persons and companies using the EUPL, such as JuliaHub? But a separate thread is definitely required to discuss the merits and drawbacks of different licenses. ---

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\ **Post date:** [December 9, 2025, 5:24pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/64 "2025-12-09T17:24:21Z")

> [@mihalybaci](#): > > But a separate thread is definitely required to discuss the merits and drawbacks of different licenses. E.g. Like > [@Package licenses: Contemplations and considerations](https://discourse.julialang.org/t/package-licenses-contemplations-and-considerations/117922): > > I’ve recently been giving more thoughts to the way I license my packages. While I don’t anticipate the choice becoming practically significant any times soon, I’ve realised that the topic probably deserves more consideration that I’ve previously given it. Why we need to think about licenses While many of us want to “just do (F)OSS” without paying much attention to licenses, they are an unavoidable part of the landscape due to the way intellectual property law has developed over the last several… ? > [@mihalybaci](#): > > My immediate question would be, how does this clause affect non-EU persons and companies using the EUPL, such as JuliaHub? You’d still be bound by this. This clause only affects the decision which court will handle disputes, which is the reason that this license is tied to EU law. Most other software licenses don’t have this, which results in a minefield of differences due to jurisdiction depending on where a suit is filed (of note: most interpretations of copyright law you can find in english online is chiefly about _US_ copyright law, so may not even apply to you if you’re in the EU! If in doubt, contact a lawyer to help you navigate this.) I personally am not a user of MTK, so my input may be only of limited interest, but I imagine that JuliaHub chose AGPL because it’s somewhat well known how a potential litigation would go in their jurisdiction. It’s a reasonable choice from that perspective, and even though there seems to be very little room for changing the detail of the license at this point, it’s good that this feedback is solicited. ---

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\ **Post date:** [December 10, 2025, 2:00pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/65 "2025-12-10T14:00:47Z")

> [@tecosaur](#): > > Out of curiosity, was the [EUPL (v1.2)](https://eupl.eu/) ever considered? I mention it because after spending an ~~excessive~~ _substantial_ amount of time reading various software licenses, it stood out to me as one of the most most rigorous and well-designed open-source licenses currently around. It’s designed in/by the EU, and authoritatively translated for all official EU languages, but makes a lot of sense globally. > [@mihalybaci](#): > > It may be a moot point since it seems like AGPL has already been decided, but one issue for could be Article 15 of the EUPL: > > _15. Applicable Law_ > > _Without prejudice to specific agreement between parties,_ > _— this Licence shall be governed by the law of the European Union Member State where the Licensor has his seat, resides or has his registered office,_ > _— this licence shall be governed by Belgian law if the Licensor has no seat, residence or registered office inside a European Union Member State._ > > My immediate question would be, how does this clause affect non-EU persons and companies using the EUPL, such as JuliaHub? It was not. I was not made aware of it and I’ll have to bring this back to discuss with folks. The exact licensing has not been decided, though you’ll see that the package splitting has already occurred, that’s because it’s a better design of the code infrastructure anyways so the code is at least in its final form and registering, but the licensing can still be changed. > [@isaacsas](#): > > Since that time the idea of a split was further discussed, and everyone agreed it seemed the best solution given the constraints we are operating under (as I mentioned in my original post). JuliaHub has since gone ahead and, I believe, essentially finished MTK11 development for an initial release at this point. Chris’ draft blog post links some of the split libraries. It is not releasing yet in order to give a chance for community feedback here, including the possibility of changes due to this feedback. Realistically though, at this point the discussion doesn’t seem to really be suggesting alternative, MTK restructurings that are sustainable for its ongoing development. Instead, the discussion primarily seems focused on the details/implications of the license for the JuliaHub extension libraries in different use cases, and these are questions that only JuliaHub can really address. > > On my end, and I would _guess_ for the majority of the steering council (but that is just my guess), there is no sense of urgency in finalizing everything, but the question would be whether JuliaHub is ok waiting on getting MTK 11 released so we can extend the comment period? The final details licensing can change separate from the v11 boundary, while it is very clear at least that the new code structure makes sense regardless of what licenses are chosen. So we can continue working on the code and getting things released even if there is a change to in the next week or so. But we should time box it so everything is clear in the next few weeks and stick to it so that there is no uncertainty in the ecosystem as to what the licensing of everything is. > [@bilderbuchi](#): > > FWIW, the [OpenModelica project](https://openmodelica.org/), which has been mentioned above, uses such a licensing approach – the IDE/compiler are licensed (effectively) as AGPL, but any artifacts (read: compiled simulation models) it creates are under a runtime license (effectively: AGPL or BSD-New, at your choice). And in the past they specifically called out that their intention is to avoid people offering closed OpenModelica-as-a-Service, while they do _not_ want to restrict the outputs that the users create. Indeed OpenModelica being GPL was also something that influenced this choice, as it’s the most closely related open source project to ModelingToolkit and had similar justifications for the AGPL choice. > [@bilderbuchi](#): > > Also, a metadata-level (or other) flag as proposed above, to avoid unintentionally dragging in (A)GPL components sounds like a useful thing to ensure one stays compliant with the involved licenses. 👍 This should really be a Pkg.jl feature, and a separate discussion. I believe there are already issues open on this? > [@bilderbuchi](#): > > In light of Julia’s maturing trimming feature and binary compilation, clarity on the license of the resulting binary seems quite relevant. Also for things like [Dyad exporting FMUS](https://discourse.julialang.org/t/features-of-fmugeneration/132812/8). Yes we will work to clarify this in a bit. > [@bilderbuchi](#): > > The OpenModelica project shows a third way, I think, which is setting up a [non-profit consortium](https://openmodelica.org/home/consortium/) for the development and sustainability of the project, so going commercial is not the _only_ way. > > Also, they seem to have had a number of (publically funded, e.g. EU) projects over decades, where they get funding for compiler/tool work, so that seems to be possible in practice? (surely it’s not all roses and there are limitations that I’m not aware of as an outside observer) It is possible. But I’ve been to Linkopeng a few times and have been on thesis committees so I know a bit about it and my assessment would be that the project is underfunded in comparison to the project that they are trying to attempt, and the funding that is there is largely due to the goodwill of the Modelica community which has mostly grown due to the well-funded commercial compilers. With MTK not being a Modelica implementation, I don’t think we’d get the same situation where some Modelica using companies are willing to pitch into the open source bucket, at least we largely have not benefitted from this in the past, and most of the requests (demands?) we have gotten are in comparison to the commercial compilers like Dymola, where companies only want to adopt when we outperform Dymola. That work, purely optimization and scaling work, is generally orthogonal to the grant funded work anyways which is generally for students to perform novel research. > [@oxinabox](#): > > Now, given we are primarily using SciML ecosystem via Catalyst, or the solvers, or Symbolics/SymbolicUtils, I think we are unaffected. > I don’t think the acausal modelling or higher order index reduction will come up for us. > So I do not foresee a problem for us personally in the near future. Indeed, I don’t see Cell Bauhaus in the group which would care about this change. The reasoning for the very detailed slice of what specific part is AGPL is because we wanted the vast majority of users to be unaffected, which should include you. > [@oxinabox](#): > > I guess for confidence, what i would like to be sure about is that it will be possible to license these components and thus receive them under different terms. And that this license is actually practically usable by us. Indeed our plan is to clarify this in the Dyad license so that there’s a single source of what the licensing is for this whole acausal domain. > [@GeorgeGkountouras](#): > > LinearSolve being GPL is news to me. I thought only FFTW (which I don’t use) was affected in Julia Base. It never came up because it wasn’t possible to deploy Julia binaries & shared libraries before. [Except in the ASML fork-and-use-internally sense.] LinearSolve.jl is GPL because of SuiteSparse. You most likely want to do a GPL-free build of Julia, and then if you hardcode to KLU or Sparsepak as the sparse LU you should be fine. For your specific problems that’s like to be okay for performance, but whether it’s a major hit or not largely depends on your sparsity patterns. > [@GeorgeGkountouras](#): > > Can we develop with the GPL internally to cut down compile times and distribute with no-GPL? Yes, this is very common to do. GPL is about how things are distributed, not how they are developed (if you’re not copying the source code of course). > [@GeorgeGkountouras](#): > > - LinearSolve written in Julia is faster for small systems > - Vendor libs (e.g. AppleAccelerate) are faster for medium systems > - I suppose for large systems the GPL stuff takes over? Yes, SuiteSparse SPQR, CHOLMOD, and UMFPACK are the top notch for large sparse systems that have enough regular structure to exploit BLAS. For most large sparse systems they are the default. > [@GeorgeGkountouras](#): > > Is there a roadmap for all-julia, all-MIT numerics? Presumably they would also be faster on modern hardware than libs from the 70s. Not really, it comes and goes based on what students happen to arrive at a given time and what funding decides to exist. Instead there’s more of a big todo list of hundreds of things, and a random 1% get done each year. That’s the purely open source numerics part at least. Most of the list is captured in the repo issues, so for example this year we got a ButterflyLU because we had a student interested, though if you asked me before the year started I would’ve not thought that would be on this year’s list. > [@GeorgeGkountouras](#): > > From a developer perspective, let’s say I add a component. It results in `N=200`, which switches silently to a viral license. This is not a good look, especially if you want the language to be mainstream beyond academics. SPICE engines don’t change license depending on the size of the system or what’s in it! Your build can just always hardcode KLU and you’d eliminate that. > [@GeorgeGkountouras](#): > > Moving variables to observed is also affected. This is essential for realtime audio processing. You can always run a climate model etc. slower. But you can’t trade for latency! This is a feature of the MTKBase pipeline, at least explicit algebraic expressions should automatically be removed. > [@GeorgeGkountouras](#): > > So SPICE-style (i.e. acausal) circuit simulation may be index-1, index-2 or more! Furthermore, it’s not obvious which systems/components will result in a higher index. Yes, circuit simulations can be in this domain. While for the vast majority of the people in the thread they are not effected, you are effected by this change for work that is not open source. > [@GeorgeGkountouras](#): > > How much money has JuliaHub spent sponsoring conferences? Not all that much. > [@GeorgeGkountouras](#): > > Goodwill is hard to come by and easy to squander. Especially for a VC looking only at numbers on a spreadsheet. Need I bring up the Unity fiasco? > > I’ve been evangelizing about “JuliaHub are good guys, they’d never do that” where the response is often “They’re VC-backed, of course they would!”. I’m staking my professional reputation. If that’s betrayed, at best I come off as naive, and at worst as actively misleading. > > There is enough value being created at the bottom for everyone (it’s why we’re here for MTK!). Don’t kill the golden goose with “next quarter” thinking. Our interests are aligned. A robust ecosystem includes small entities. Indeed, we are doing this to think about the long term health of the ecosystem. The purpose of this thread was to find out the cases that we missed, and to be clear your case, a small hobbyist user doing this in a way that’s not open sourced but also not just academic, but also not some multi-million dollar business, is a case that not captured in our prior analysis. And I personally will be seeing that we get an answer that works well for you given what I know about your use case. ---

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\ **Post date:** [December 10, 2025, 2:01pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/66 "2025-12-10T14:01:56Z")

We did this thread to collect feedback from the ecosystem in order to better reflect on and refine what we need to do next. It seems the things that we need to come back with answers for are: - What to do about these hobbyist projects, clarification of the commercial license. - Clarification of the licensing of the AGPL aspects in relation to the Dyad license - A complete deep dive into EUPL vs AGPL - Licensing of exported code and FMUs Give us a bit of time to reflect on these concerns. ---

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\ **Post date:** [December 10, 2025, 2:43pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/67 "2025-12-10T14:43:40Z")

Could you please also say something about other MTK libraries like ModelingToolkitStandardLibrary.jl and ModelingToolkitNeuralNets.jl will be affected in any way or what the plans are there? ---

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\ **Post date:** [December 10, 2025, 3:25pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/68 "2025-12-10T15:25:08Z")

> [@tecosaur](#): > > Out of curiosity, was the [EUPL (v1.2)](https://eupl.eu/) ever considered? > … > Oh, it’s also more broadly compatible with other open source licenses, while requiring reciprocity, which is nice. I do not know if that is of any relevance, but it doesn’t list MIT among compatible licenses. ---

**Author:** ![AronT](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aront/32/24890_2.png) [@AronT](https://discourse.julialang.org/u/AronT)\ **Post date:** [December 10, 2025, 3:38pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/69 "2025-12-10T15:38:58Z")

Exactly this. Moving to AGPL is definitely the correct move. JuliaHub has no obligation to subsidize competitors or other commercial entities. However, startup companies (for example) might not have the resources to modify and contribute code back but are perfectly willing and interested in paying for a commercial license, since GPL is a no-no for investors and customers. Since the commercial fee is going to a non-commercial entity it can be used to fund development. This is a win-win all around. The commercial license should be structured in such a way that it ties reasonably to both level of use and importance in the whole product. ---

**Author:** ![Datseris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/datseris/32/13406_2.png) [@Datseris](https://discourse.julialang.org/u/Datseris)\ **Post date:** [December 10, 2025, 3:55pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/70 "2025-12-10T15:55:57Z")

I just wanted to say that I really appreciate the openeness of the MTK project, and that I agree with the post above by AronT that I feel this overall is a good move. I am happy to see the MTK project thrive in a more sustainable way going forwards! In my understanding academic use is not affected by this in any meaningful way so I am personally happy to give my supporting vote! I do want to give a +1 though to the statements by GeorgeGkountouras regarding considering a special clause for hobbyists or sufficiently small (financially) entities, whatever small means in your eyes. ---

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\ **Post date:** [December 10, 2025, 5:58pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/71 "2025-12-10T17:58:37Z")

> [@langestefan](#): > > Could you please also say something about other MTK libraries like [ModelingToolkitStandardLibrary.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/ModelingToolkitStandardLibrary) and [ModelingToolkitNeuralNets.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/ModelingToolkitNeuralNets) will be affected in any way or what the plans are there? ModelingToolkitNeuralNets.jl is basically unaffected. It probably need to change its dependency to ModelingToolkitBase.jl and that’s it. ModelingToolkitStandardLibrary.jl is kind of a different beast. It’s just the right time to do clean up here. MTKStdLib is just… bad right now 😅 Like it you look at the Translational library: > **[ModelingToolkitStandardLibrary.jl/src/Mechanical at main ·...](https://github.com/SciML/ModelingToolkitStandardLibrary.jl/tree/main/src/Mechanical)** > > A standard library of components to model the world and beyond - SciML/ModelingToolkitStandardLibrary.jl you have: - TranslationalPosition - TranslationalModelica - Translational Which are 3 different ways of writing the library. One is numerically just more stable than the others, all 3 are incomplete, and the tests are all wonky. I actually forget which one between Translational and TranslationalModelica is the one you should use, I just know TranslationalPosition can give some numerical instabilities so I don’t recommend its components. It’s just… in not good shape. Meanwhile, Dyad’s standard library has TranslationalComponents.jl, and this library has the ModelingToolkit code for all of its documented components: > **[TranslationalComponents/generated at main · DyadLang/TranslationalComponents](https://github.com/DyadLang/TranslationalComponents/tree/main/generated)** > > A library of translational components for Dyad. Contribute to DyadLang/TranslationalComponents development by creating an account on GitHub. It’s well documented [TranslationalComponents | Dyad](https://help.juliahub.com/dyad/dev/stdlib/TranslationalComponents/) And the Dyad standard library is a permissively licensed library as well, since it’s BSD-3. For all of the 5 standard library modules that are based on the Modelica standard library, they are BSD-3, which is functionally very similar to MIT: > So the real question becomes, if we have one version of the translational components that is well-documented, well-tested, permissively open source licensed, and really thought out, and the other one has broken tests, components repeated in some bad ways that can be mine fields, etc. I think we just deprecate the broken one. What this means is that we should make sure to document the 5 standard libraries for Non-Dyad ModelingToolkit users, similar to how we document the ModelingToolkitStandardLibrary today. But if we just set that up as documentation, you basically just switch from an 5 unmaintained MIT-licensed libraries to 5 maintained BSD-3 licensed libraries, so everyone wins here. And because the generated MTK code is in the library which presents itself as a Julia package, you can just use it without caring that Dyad ever exists. So this is what I have been meaning when I say the ModelingToolkitStandardLibrary is deprecated. I want to make sure these other libraries fully cover everything in the mtkstdlib, and then we update the docs so that the MTK docs also have the standard library (from these 5 repos), and then archive the repo. We might want to pull some things out to a separate lib, like maybe planor mechanics? That was a contribution, but we need to find the right structure for these things to be better maintained without packing everything into one repo (which is bad for loading times anyways. ---

**Author:** ![baggepinnen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/baggepinnen/32/693_2.png) [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)\ **Post date:** [December 10, 2025, 6:12pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/72 "2025-12-10T18:12:55Z")

We might want to do something about [BlockComponents/Project.toml at fde606420a043f4758ed9f5d6770dacbc01e9ea8 · DyadLang/BlockComponents · GitHub](https://github.com/DyadLang/BlockComponents/blob/fde606420a043f4758ed9f5d6770dacbc01e9ea8/Project.toml#L11) for MTK users to want to use the DyadLang libraries, that dependency is very cumbersome ---

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\ **Post date:** [December 10, 2025, 6:53pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/73 "2025-12-10T18:53:13Z")

yeah good point, for the standard libraries we should probably just use an MTKBase dep, and then DED should just be a test dep. It’s not actually needed as a direct dep I think. That’s a small quality of life thing that would do wonders for users. ---

**Author:** ![langestefan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/langestefan/32/207923_2.png) [@langestefan](https://discourse.julialang.org/u/langestefan)\ **Post date:** [December 10, 2025, 7:36pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/74 "2025-12-10T19:36:57Z")

Happy to hear MTK standard library is not being forgotten about, and I agree it needs some love 🙂 I think having a well-stocked standard library of ‘basic’ components would be a huge asset to the MTK ecosystem. My idea would be to go through the libraries in Modelica and Simulink, see what we’re missing, and add it. Could I already start using `DyadLang/ElectricalComponents` as if it was an MTK library for example? ---

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\ **Post date:** [December 10, 2025, 8:26pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/75 "2025-12-10T20:26:23Z")

> [@langestefan](#): > > Could I already start using `DyadLang/ElectricalComponents` as if it was an MTK library for example? Yup, that already works and it already has the open source license. We just need to document it. One other caveat which was mentioned is that it has DyadEcosystemDependencies as a dep, which is effectively a tool to set a manifest to the SciML ecosystem for stabilizing versions. We can remove that dep though, and we should, so we’ll do a little bit more to make it natural. ---

**Author:** ![rayegun](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rayegun/32/26729_2.png) [@rayegun](https://discourse.julialang.org/u/rayegun)\ **Post date:** [December 10, 2025, 8:56pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/76 "2025-12-10T20:56:24Z")

For what it’s worth Julia’s GPL’d dependencies (at least the sparse parts) are v2.1 _or later_. I imagine this is in part due to the compatibility issue. In general for sparse systems the fastest codes are all GPL (or MKL / US government license depending on scale. Distributed memory codes are most often the boilerplate US government license), and this is why the default distribution of Julia is GPL v2.1+. Pkg.jl should probably be updated to transmit this information somehow both for Julia itself and for packages. This is particularly important since many of the _Julia packages_ are **not** GPL, they are MIT. But they rely on JLLs which are GPL. This is not always obvious to end users. I’m not sure how or where this should be indicated. I would reckon 95% of Julia users aren’t aware the distribution they use is GPL. ---

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\ **Post date:** [December 11, 2025, 9:55am UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/77 "2025-12-11T09:55:27Z")

According to [julia/THIRDPARTY.md at master · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/blob/master/THIRDPARTY.md) there are some that are GPL-2.0+, namely `librbio`, `libspqr`, and `libumfpack`. ---

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\ **Post date:** [December 11, 2025, 11:08am UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/78 "2025-12-11T11:08:30Z")

We have not yet really heard about the goals of the new license: 1. Is the goal of the AGPL/commercial dual license to force badly behaving entities to give code back to the ecosystem? 2. Is the goal to collect some licensing fees from a variety of small players? 3. Is the goal to collect big licensing fees from some big players? 4. Is there an existing or planned business model that needs to be protected from getting undercut? e.g. libre/open MTK development is fincanced/subsidized by business X that builds on top of it. Good open-core development and financing of open-source work, nice! But business X must be protected from competitor Y who could just add their own “product layer” on top of libre MTK – they would otherwise be cheaper, not having to spend resources on MTK development. If this is the case, and you do feel comfortable talking about that commercial product, we’d be interested in hearing about it! 5. Somewhat alluded to, there is also the option: You don’t want to switch away from MIT license. But some of your funding sources demand it, and are impervious to being reasoned with (“it is policy”). They may have their (valid!) reasons, but these are not pertinent to the decision or to your future behavior when selling non-AGPL licenses, or enforcing the license. And I guess it’s not just you @isaacsas from the steering council, but also juliahub who should chime in. (afaiu the non-juliahub MTK people are in position 5, while juliahub is in one or multiple of the other 4 positions) Knowing these aims allows people to have some expectations on how this will shake out. For example, if “collecting small license fees from small commercial users” is not your goal, then we know that it may be troublesome for small players to get a commercial license, due to institutional mismatch, but you won’t haggle or care for the exact amount of money. On the other hand, if small commercial license fees are your intended business, then people know that they will find somebody willing to take their money, but they are unlikely to get a commercial license for free. And if your goal is protecting a business, then we know that the answer may be a flat “no, not for _you_” if we’d be competition. If we knew what business you are protecting, we could even guess the answer in advance. ---

**Author:** ![GeorgeGkountouras](https://avatars.discourse-cdn.com/v4/letter/g/77aa72/32.png) [@GeorgeGkountouras](https://discourse.julialang.org/u/GeorgeGkountouras)\ **Post date:** [December 11, 2025, 2:59pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/79 "2025-12-11T14:59:13Z")

1. Will sub-licensing to other companies work? With the MIT license, one can do Work-for-hire modeling. Typically, the other company sends the audio hardware circuit, along with any schematics. A consultant handles implementation of the circuit simulation, realtime DSP, etc. The result is presented either as an official collaboration or a white-label solution that the client can stamp their brand on. With the AGPL compiler, JuliaHub might demand that the client company also buys an MTK license (perhaps at a premium if they are a large company). This cost needs to be communicated up front to the client and might affect the decision to choose MTK over any alternatives. B2B licensing can be an important additional source of income for small entities in the audio field. 2. I discussed with @Janis_Erdmanis the possibility for AppBundler/JuliaC/PackageCompiler to automatically handle licenses (i.e. build a GPL-free julia from source, propagate licenses as part of Pkg). Would other parties be interested in this and/or willing to fund the effort? The problem: it is very easy to get license-trapped without your knowledge because of [how convenient the package manager is](https://www.gingerbill.org/article/2025/09/08/package-managers-are-evil/). As an example, I might pull in a fictional SpectralPlots.jl package. They don’t mention anything in their documentation about licenses, but they use FFTW.jl . They’re academics, so the licensing issue has never come up before for them. If I use AppBundler to distribute that app, I’m violating GPL (again, without my knowledge or theirs!). We can move this discussion to a separate thread as appropriate. ---

**Author:** ![isaacsas](https://avatars.discourse-cdn.com/v4/letter/i/f6c823/32.png) [@isaacsas](https://discourse.julialang.org/u/isaacsas)\ **Post date:** [December 11, 2025, 3:30pm UTC](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396/80 "2025-12-11T15:30:58Z")

Regarding the grant funding consideration; this isn’t something I’ve personally experienced. However, I am traditionally applying for grants from the US NSF and private research foundations, and I am based in academia. The restrictions that JuliaHub encounters when applying for grants, and those for which it applies apparently often have a commercialization aspect, isn’t something I can speak to. @ChrisRackauckas posted quite a bit about this as a comment in the PR for the MTK 11 draft blog post (see my link in the original post above). My impression though is that the grant issue primarily matters in that if SciML, for example, had several hundred of thousands of US dollars per year for 3+ years, we could try to hire full time MTK developers. But we don’t, and I don’t see the grant opportunities we could apply for that would realistically provide that (at this time). Right now, the one who is, and has been, supporting the full time MTK developers is JuliaHub, who needs to be able to justify paying for this support. The split and licensing change will help address their concerns that I mentioned in my original post about the behavior of other companies, and make it more justifiable for them to contribute to an open source MTK (e.g. as opposed to just internalizing their own version for their commercial products). Note, I don’t believe JuliaHub ever made any mention to the council of just forking and having their own version – from the start they favored and desired solutions that preserved all of MTK as open source with license modifications. [Previous page](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396.md?page=3) [Next page](https://discourse.julialang.org/t/modelingtoolkit-v11-library-split-and-licensing-community-feedback-requested/134396.md?page=5)