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.
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/
2 Likes
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.
E.g. Like
?
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.
2 Likes
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.
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.
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.
This should really be a Pkg.jl feature, and a separate discussion. I believe there are already issues open on this?
Yes we will work to clarify this in a bit.
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.
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.
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.
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.
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).
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.
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.
Your build can just always hardcode KLU and you’d eliminate that.
This is a feature of the MTKBase pipeline, at least explicit algebraic expressions should automatically be removed.
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.
Not all that much.
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.
4 Likes
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.
12 Likes
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?
I do not know if that is of any relevance, but it doesn’t list MIT among compatible licenses.
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.
3 Likes
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.
7 Likes
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:
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:
It’s well documented TranslationalComponents | Dyad
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.
1 Like
We might want to do something about BlockComponents/Project.toml at fde606420a043f4758ed9f5d6770dacbc01e9ea8 · DyadLang/BlockComponents · GitHub
for MTK users to want to use the DyadLang libraries, that dependency is very cumbersome
1 Like
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.
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?
2 Likes
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.
1 Like
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.
6 Likes
According to julia/THIRDPARTY.md at master · JuliaLang/julia · GitHub there are some that are GPL-2.0+, namely librbio, libspqr, and libumfpack.
We have not yet really heard about the goals of the new license:
- Is the goal of the AGPL/commercial dual license to force badly behaving entities to give code back to the ecosystem?
- Is the goal to collect some licensing fees from a variety of small players?
- Is the goal to collect big licensing fees from some big players?
- 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!
- 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.
4 Likes
- 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.
- 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. 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.
1 Like
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.