Afaiu reason for the GCC “runtime exception” is not that compiled works are derivatives of the compiler (they are normally not!). It is rather that C++ compilers are expected to provide stuff like the STL. So your compiled C++ binary is not derived from the used compiler, but if you use e.g. std::string then your compiled binary is a derived work of the GNU libstd++ implementation of std::string. I think it’s also a derived work of GNU libstdc++ if you compile with clang -stdlib=libstdc++.
I personally think that this is utterly insane C++ nonsense-- language and standard library should have been more separate, ABI over API. But
(I think the otherwise obvious approach – make libstdc++ LGPL instead of GPL – can’t really work, because you need to inline from libstdc++, dynamic linking is too slow, and LGPL afaiu doesn’t permit that)
There is no issue with GPLv3, but afaiu AGPL is incompatible with GPLv2.
In other words: Even if you don’t care about licenses at all and want to open-source everything, it would probably be problematic to distribute artifacts that depends on both GPLv2 and AGPL libraries (even if you don’t modify/fork the libraries).
I think you’d be allowed to pass on the source code to the resulting package; but I think you’d be in hot water if you additionally wanted to distribute a docker image with everything pre-compiled to your students in a course: GPLv2 demands that recipicients of the precompiled binary code inside the docker image are entitled to source code without onerous extra restrictions, but AGPL is considered such an incompatible onerous restriction by GPLv2. But IANAL, please discuss that in the FAQ!
The general availability release of Dyad is happening later in Dyad, in which case yes a simple pricing model and license (along with the new agentic AI system tuned for Dyad) follows with that. So stay tuned, lots going on.
Part of this is moving the crazy part into a separate repo with a well-defined API attached to the core so that the core can have less movement. Hopefully it has a lot less now that the symbolics pieces are pretty solid (some functions still need work to be type-stable though)
I have always found GPL licenses a minefield to figure out when the copy-left protection is relevant. I think the varying views here show I’m not alone in this.
I would rather my code and package be MIT (specifically to avoid this headache for other people), but at what point am I forced to use AGPL instead?
Is using MTK enough to require AGPL? What about if I didn’t include a compat bound for MTK and this license change happened without my involvement?
What about MTK generated models? Is any code that uses them bound to AGPL?
What about package dependencies vs extensions?
Can I include the AGPL MTK as a test dependency to make sure it doesn’t break my code, or will that require all my code being released under AGPL?
Or is this only relevant to the MTK source code and forks, but not for uses of the MTK code, like using MTK; mtkcompile...?
It would be helpful if this change came with guidance from JuliaHub on when they consider this to be required.
I understand from a business perspective JuliaHub may prefer not to do this and rather anyone who has any questions seek legal help - but for academics and hobbyists, this isn’t really feasible.
The desire to protect the ecosystem is very understandable. However, GPL licences do more than this in my experience. Many entities won’t touch anything GPL with a ten foot pole because of the hassle involved. Which might have an opposite chilling effect on the ecosystem, but who knows?
I do wonder whether AGPL is the only license that achieves the goals, or if there is a more permissive license that would achieve the same.
The steering council were told AGPL is the most permissive license that would be accepted and address the concerns I mentioned in the original post. We proposed LGPL but that was not found to adequately address those issues.
This is my personal opinion based on the general consensus that is out there and having talked to many lawyers, but yes you should talk to your own lawyer. We can have a legal opinion that gets posted in an FAQ that is double/triple checked, but what I am posting here is pretty much just the basics of GPL that are pretty standard and already have to be considered when using Julia which also has GPL dependencies.
You can always copyright your own code to whatever license you want, given it’s not derived from another source (such as translation). So you can have MIT dependencies for an (A)GPL project. Julia itself is an example of this as stated above: it’s MIT licensed but bundles GPL dependencies by default, so its code is MIT but its default builds have GPL restrictions unless you specifically do a GPL-free build.
This is my interpretation of a discussion based on a question/answer that was explicitly checked and confirmed with a lawyer provided by NumFOCUS, but of course seek your own legal advice if you have questions.
I think we’ll need to clarify the case of, if you use MTK to generate the code, then take the generated code and stick it into some file and save it, what the licensing is there. Definitely if you just use MTKBase that’s MIT, but I’ll need to check what happens with the structurally simplified acausal models. That is a very good question.
An extension that isn’t triggered does not imply GPL.
This is my interpretation of a discussion based on a question/answer that was explicitly checked and confirmed with a lawyer provided by NumFOCUS, but of course seek your own legal advice if you have questions.
If you are not shipping any AGPL dependencies, then AGPL licensing does not apply. Julia’s test system will never even download the code for test dependencies except when testing, so I do not see how the licenses of test dependencies could be an issue.
If you’re open sourcing your code, then there are no issues with GPL. That covers the vast majority of academics and hobbyists. If you’re not bundling your code in binaries or launching commercial web services, then you have no issues with AGPL. If you’re not using high-index DAEs in acausal modeling (most academics and open source projects built on MTK are not), then you also can use the MTKBase AGPL-free build. Only if you’re in the segment of using high-index DAEs / acausal modeling + distributed the code in binaries or a web service and you’re not open sourcing, then GPL restrictions apply. But again, if you’re in this segment then you’re already having to do a custom build of Julia for GPL-free versions, and so this will likely already be in your mind. I do not think that many academics and hobbyists are in this subset of users, though yes it is non-zero and we will need to clarify Dyad licensing in order to make this easier.
My interpretation is that I do not believe the lawyer would agree with several of your statements you have been making about the AGPL license implications. But we can not provide a statement from a lawyer on these issues, so this is all just our personal interpretation.
My interpretation is that if I using SOME_AGPL_LIBRARY or import SOME_AGPL_LIBRARY as a dependency in my public Julia library, my library needs to be AGPL. If I using or import another library that does this than my library needs to be AGPL. The issue you mention about Suitesparse and potential community license violations is something that should probably be discussed as many may not be aware of the license implications in Julia of saying using SparseArrays (I was not). However, I think that is something to discuss in another thread as this one should stay focused on MTK and its split.
edit: To be clear this is all my personal interpretation, and not any consensus from the SciML steering council.
You are mixing up the copyright of your code vs the effective license on users. The statement is that if you using SOME_AGPL_LIBRARY or import SOME_AGPL_LIBRARY as a dependency in my public Julia library, then your library is effectively shipping as AGPL. That does not mean you cannot make the copyright of your own code MIT, that’s your own code and it can be any license. But having an AGPL depedency means that someone building with this code needs to follow the AGPL practices.
I’ll note that if that interpretation there was correct, then you would be claiming that Julia itself would have been in license violation for at least a decade. As most people here would know, it has always released its code as MIT:
while being effectively GPL licensed until ~2023. If dependencies required a copyright change then that license file would be in violation. Note that the GPL linking and timeline etc. is discussed here:
Also a good chunk of the Julia numerical package ecosystem until ~2018 would also need to relicense to GPL, because NLsolve.jl was GPL and so anything depending on that (such as DifferentialEquations.jl) also needed to change its license from MIT to GPL. A lot of the symbolic ecosystem as well would not be able to be MIT licensed code because there are some GPL dependencies.
This is an important point: virality of licenses like GPL and AGPL doesn’t mean you have to put your code under the same license when you use (A)GPL libraries. It just means that you have to make your code available under terms that satisfy the requirements of the (A)GPL, which MIT/BSD licenses very much do.
To be even more concrete: you always own the copyright of code you yourself write and can control how it’s licensed for others to use. That code can be licensed such that others can use/edit/modify/re-distribute it.
Where the licensing of other people’s code might come in is:
If you copied from other people’s copyrighted code as you wrote your thing. This is plagiarism (a copyright violation) unless they’ve granted you a license to do so. And if they granted you a license, you must comply with the terms of that license.
If you share (or convey in some fashion) other people’s copyrighted code yourself. Again, this is a copyright violation unless they’ve granted you a license to do so. And again, this is where you’d have to ensure you’re satisfying those terms.
Now, if you do share a thing that incorporates other people’s copyrighted (A)GPL code intermingled with your own code, the license demands that the whole thing must satisfy the terms of the (A)GPL. That’s not the same as making that code “(A)GPL” — the MIT license satisfies those terms!
It’s worth noting that there’s a pretty big difference between sharing other people’s code yourself and telling your users to go get some component/library separately. This is exactly how arcade game emulators work — they can’t distribute the copyrighted games themselves, but if you happen to have purchased those proprietary materials separately, you can use them in the emulator.
Regarding understanding the AGPL, this StackOverflow Q&A is very helpful:
In particular, the FSF itself says this about the AGPL:
The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.
@foobar_lv2 makes a good and important point: AGPL is compatible with GPLv3 but incompatible with GPLv2—the added requirement is considered too restrictive for GPLv2. Most GPL software is GPLv2+ or GPLv3+ so that’s not an issue, but there are occasionally things that are GPLv2 only, like the Linux kernel and BusyBox. Everything that Julia itself depends on is GPLv2+ at least, so that’s not a problem, but if someone used one of the rare GPLv2 only libraries out there, it could be.
Specifically, if someone were to use AGPL code and some GPLv2-only library to build some application and redistribute it, then that would be a GPLv2 violation. Of course, if anyone is building and redistributing software, they should get legal advice, but this is something to be aware of. Building a SaaS using AGPL code and GPLv2 code, on the other hand, is actually fine because it doesn’t count as redistribution under the GPL, so the terms of the GPLv2 code are satisfied and the terms of the AGPL code are satisfied (GPLv2 is fine from the AGPL’s perspective). So I don’t think there’s much of a legal hazard here.
your server must also allow them to download the source code corresponding to the modified version running there.
That’s a tricky one. As I understand it, this would contain all source code that is loaded when running the server, even if the server has 1000 endpoints and 999 of them do not use the AGPL code.
It goes step further than just requiring any modifications to the AGPL part be contributed back by also requiring the entire work to be open source, but I understand it from a business perspective. This allows it to be used in an academic / pure open source setting while also ensuring that JuliaHub gets return on investment from commercial closed source usage.
I would like to thank the steering committee for being sensible in this thread. License changes are challenging for everyone involved and tensions run high. We should work together and find an approach that works for everyone.
In particular, I consider the “running locally” matter resolved. Artifacts remain an open question. @viralbshah also mentioned a license that kicks in after revenues build up, looking forward to that. It would go a long way to dispel uncertainty for small entities (see the rest of this thread).
I believe we can also come to an understanding regarding my particular use case, given the attitudes displayed in this thread. By this I mean the actual people involved, since there are no official JuliaHub statements yet.
I mentioned the license should be cheap and available. To expand, JuliaHub could not return my emails asking for a license: “We only deal with enterprise customers. Open an account and sign up for this 6-month high-touch process.” This is within their right.
[Not answering the phone is bad business practice, but legal. But I digress.]
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.]
That means that effectively every Julia binary must build Julia from source. Do we need to wait 30 minutes per build locally? Can we develop with the GPL internally to cut down compile times and distribute with no-GPL? The following statement suggests yes, but my interpretation is no, so we’re back in “ask a lawyer” territory:
My understanding:
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?
I also recall Intel MKL being faster on AMD systems but MKL is not under GPL.
Is there a roadmap for all-julia, all-MIT numerics? Presumably they would also be faster on modern hardware than libs from the 70s.
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!
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.
Furthermore, from my understanding this isn’t just about the index reduction. 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!
I don’t use Dyad or agents, but I still follow the MTK license. Unless Dyad is the marketing name for all the AGPL MTK.
Some final thoughts. How much money has JuliaHub spent sponsoring conferences? 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.
Not having read the thread but focussing on just the openinging post.
And linked blog post.
Now my background is possibly unique.
In that in the past I worked for JuliaHub and did build things that shared code with ModelingToolkit, in particular for the higher order index reduction that is proposed to be AGPL Licences, and so I know how some of those parts of it work fairly well, and would be in a position to change them if cause came up. So like I could contribute to this code. Currently unlikely, as I wouldn’t do that without being paid for that, and in those circumstances I would most likely be looking into paying someone eg at juliahub to do it a I am too busy.
But i do make a handful of small improvements everywhere across the ecoystem.
Secondly I do work for a startup that is putting SciML code into production that will be exposed as a SaaS.
Now an important thing here is that we actually not only have the direct worry about the consequence of incorporating AGPL code into our code base. But also the indirect worry that we have a contract with out investors more or less forbidding us to do so in a way that is more agressive than even the AGPL’s terms. It’s going to be varied at some point. Since it is very silly. But still things do happen, esp with investors that are not familar with open source scientific ecosystems.
As a consequence of this is I would be extremely cautious about touching it.
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.
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.
E.g. it is not “you need to run your software as a JuliaHub app” or something like that.
And doesn’t get bogged down in months of back and forth with lawyers to acquire.
NB: Do not take this an an official communication from my employer, this is just some quick and largely personal thoughts.
I wanted to support the question of runtime exceptions, quite an important point, so it’s appreciated that you intend to offer clarity here.
FWIW, the OpenModelica project, 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.
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.
Personally, as an acausal fluids-system person (so it looks like the MTKBase split will impact me), it will be good to know, as it impacts the relative attractiveness of Julia (which I’d like to use) vs. Modelica (which I do use), in practice, at work.
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.
The OpenModelica project shows a third way, I think, which is setting up a non-profit 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)
Out of curiosity, was the EUPL (v1.2) ever considered? I mention it because after spending an excessivesubstantial 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.
Like the AGPL, it covers all distribution modes (remote execution, SaaS, etc.) but it does so through a definition of “distribution or communication” that explicitly includes providing access to essential functionalities. From my reading, as well as what I’ve seen written on the EUPL, this achieves the same practical protections as the AGPL, but grounds them in statutory EU software-copyright law rather than relying on how individual jurisdictions interpret network use.
The EUPL also defines what exactly a “derivative work” is, and so offers clear guidance on how dynamic linking/software outputs are to be treated, instead of being subject to local interpretation.
Oh, it’s also more broadly compatible with other open source licenses, while requiring reciprocity, which is nice.
The comment period is short, and this is partially my fault. I insisted the steering council try to get a lawyer’s opinion via NumFocus in the hopes we could provide a statement about the AGPL’s impact to everyone. This ultimately didn’t result in anything we can share unfortunately, and took around a month. (The council originally was informed and discussed this issue back in late October, at which time we immediately contacted NumFocus.)
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?
edit: But just to clarify, I was the one who suggested tomorrow as the last day for commenting based on my understanding of the desire to get MTK 11 released.
but MKL is not under GPL.