Update ModelingToolkit license and README to describe AGPL license inclusions

[isaacsas]

While the source code in this repository is MIT licensed, ModelingToolkit.jl now pulls in components that are AGPL licensed. This creates a situation where a user might install this package believing they are working within a permissive MIT context, while their dependency tree actually carries AGPL restrictions.

Could the LICENSE file and README be updated to clarify this distinction?

It would be very helpful in the license to explicitly state something like:

ModelingToolkit.jl pulls in AGPL dependencies.

Users requiring a pure MIT stack should use ModelingToolkitBase.jl instead.

This would prevent users from inadvertently violating strict license terms in commercial or proprietary projects.

[ChrisRackauckas]

It doesn't follow the conventions in the ecosystem, for example https://github.com/JuliaSparse/SparseArrays.jl/blob/main/LICENSE.md. Looking at a sample of GPL libraries:

• https://github.com/TuringLang/Turing.jl
• https://github.com/JuliaTopOpt/TopOpt.jl
• https://github.com/sebapersson/PEtab.jl
• https://github.com/augustinas1/MomentClosure.jl
• https://github.com/baggepinnen/MonteCarloMeasurements.jl
• https://github.com/JuliaManifolds/Manifolds.jl
• https://github.com/JuliaAI/MLJ.jl
• https://github.com/JuliaNLSolvers/LsqFit.jl
• https://github.com/infiniteopt/InfiniteOpt.jl
• https://github.com/JuliaStats/GLM.jl
• https://github.com/Evovest/EvoTrees.jl
• https://github.com/JuliaDynamics/ChaosTools.jl

Given only GLM.jl does this, it's definitely not standard.

But what really matters is consistency. This probably needs to be an org level thing and someone should do all of the repos at the same time consistently. If this is added then we also need to update the other GPL libraries, which includes:

• https://github.com/SciML/SymbolicAnalysis.jl
• https://github.com/JuliaSymbolics/Symbolics.jl
• https://github.com/SciML/Surrogates.jl
• https://github.com/SciML/SciMLSensitivity.jl
• https://github.com/SciML/SciMLExpectations.jl
• https://github.com/SciML/NeuralPDE.jl
• https://github.com/SciML/Integrals.jl
• https://github.com/SciML/GlobalSensitivity.jl
• https://github.com/SciML/EasyModelAnalysis.jl
• https://github.com/SciML/DifferenceEquations.jl
• https://github.com/SciML/DiffEqBayes.jl
• https://github.com/SciML/DiffEqParamEstim.jl
• https://github.com/SciML/DiffEqNoiseProcess.jl
• https://github.com/SciML/DiffEqBase.jl (earlier versions)
• https://github.com/SciML/DataDrivenDiffEq.jl
• https://github.com/SciML/CurveFit.jl

Those are just the obvious ones that most people would know are GPL off the top of their head, but we should do a complete audit if we are going to commit saying that our licenses declare all GPL dependencies.

Also the text there is not accurate because ModelingToolkitBase doesn't have a "pure MIT stack" of course.

And it's kind of scary to make such a firm statement in a license file because it's legally hard for us to guarantee. It changes all of the time and requires constant updates. I mean remember, until very recently DiffEqBase and Symbolics were GPL as well through the dependency stack. If we make such a commitment we'd need some kind of CI to continue keeping that alive since it's very common that we need to root out some GPL dependency that pops up. Remember, this happens every 3 months or so, so making a legal guarantee without CI is something we know we would have failed at least 20 times in the last decade on libraries we thought were GPL-free.

[isaacsas]

I agree that consistency across the SciML organization is key, and I certainly understand the hesitation to make legal guarantees in the LICENSE file that might become outdated without automated checks.

Longer-term, the idea of a "License CI" that audits dependencies to flag GPL/AGPL ingress is excellent. That sounds like a perfect candidate for a NumFOCUS grant project (or a Google Summer of Code project) to build a tool that standardizes this reporting across all SciML repos (if we can find someone interested working on that).

While I agree we shouldn't make a "firm statement" or guarantee of purity that we can't automatically verify, there is a distinction between guaranteeing a stack is MIT and warning that a stack includes AGPL/GPL.

Even if we don't touch the LICENSE file itself to avoid that "legal warranty" risk, could we add a "License" section to the README? And I'd note AbstractAlgebra.jl is a good example of how to handle this in a license. They explicitly note that while their code is BSD, they link to GPL libraries.

But even a simple README note saying: "Note: Standard installation of ModelingToolkit pulls in AGPL dependencies. Users requiring permissive-only stacks should audit their dependency tree or consider ModelingToolkitBase" would be helpful.

That doesn't promise MTKBase is perfect, but it flags the known issue of potentially pulling in AGPL in the main package.

[ChrisRackauckas]

I think what's done in GLM.jl is probably the the safest way to do this: https://github.com/JuliaStats/GLM.jl/blob/master/LICENSE.md

But if we do that, we should also make sure to update all libraries at the same time, which crucially includes anything that uses Distributions.jl. Otherwise we're making a promise that we're stating what has GPL but wrong in most cases, which is worse than just not making a statement at all.