I have to admit what you explain here about MTKStdLib is just confusing to me.
If I get it right, you say it’s bad because for example it has 3 different implementations of the same library in it. And the solution seems to be…to add a 4th implementation in an independent library? Why not fix the already available package, or (re)create it under the SciML umbrella?
Also, if I get your vision right, the library of standard components for MTK should not live in ModelingToolkitStandardLibrary.jl, but under the umbrella of a (proprietary) julia sub-language/compiler? (Sorry if I don’t precisely describe what Dyad is, I think that’s not too important here.)
With a somewhat cynical hat on, that sounds like it could well be a play to pull (parts of) MTKStdLib behind the Dyad paywall at some point? As in, sure it’s permissively/BSD licensed, but for it to actually work you need to buy the Dyad compiler? It’s under DyadLang, after all
Which is, I guess is fine, it’s just good to be clear so that people can manage expectations? I actually hate to feel sceptical here, but I’ve seen too many OSS rug-pulls to just be all
Please tell me a better reason for such a move/reimplementation!
I think the “standard” answer to that problem is to make use of Software Bill of Material (SBOM) tools, because those will (ideally) crawl your project and collect license info (or flag where it’s not available), so it should be easier to get a handle on what you pull in.
With the upcoming Cyber Resilience Act, if you’re working commercially, you’ll probably have to do this anyway.
There seems to be a Julia package, but I have no experience with it: https://github.com/SamuraiAku/PkgToSoftwareBOM.jl Also highly relevant: Launching the Julia Security Working Group
The 4th already exists, is tested, and works really well. So the plan is just to deprecate the 3 bad ones and update the docs to point people to the one that works well.
The 5 standard libraries mirroring the 5 Modelica standard libraries are intended to just be permissively open source licensed. We have other libraries which are not, but these are purposefully open source licensed because we know that other system, i.e. Modelica, provide this as part of the open source offering. And the ModelingToolkitStandardLibrary.jl only has these same 5, just not as good versions .
I mean, if you want to fork and continue maintaining the ModelingToolkitStandardLibrary.jl, be my guest. ModelingToolkit could and should have just a bunch of random component libraries around. I just don’t see a reason for me to be maintaining multiple versions of the same exact library when both are permissively open source licensed, especially when one of them is effectively already the version that fixed the issues of the others. That’s just a waste of time.
@ChrisRackauckas what maybe is being missed here is that the 5 libraries hosted under Dyad in no way require Dyad to use them. i.e. they should be usable as a normal Julia package (with a permissive BSD license) via the package manager with MTKBase right?
The BSD-3 license means you pretty much do whatever you want with that code. At least that’s what I understand from the comments here.
I think people are just confused that now the MTK standard library is going to be hosted / managed by dyad. If dyad decides to remove the generated MTK components, then non-dyad users are screwed right?
The old versions are still BSD-3 licensed, so anyone could just fork it off. I think if it comes to that, we’d just fork that last version to SciML to be the new MTK standard library or something. But while they are the same (which I don’t think is changing), then we might as well just have the single code base with the fixes.
I don’t think anyone outside SciML wants to fork anything and take complete responsibility. That is an absolute last resort.
That would also be my preference. I just don’t see how it’s possible to have dyad generated MTK components be completely independent of dyad itself and how/where SciML would host those.
That would also be my preference. I just don’t see how it’s possible to have dyad generated MTK components be completely independent of dyad itself and how/where SciML would host those.
That is a good point. I guess in practice only people with access to Dyad would be able to contribute to these libraries, since the MTK components are generated from Dyad, and I presume JuliaHub would want to keep the libraries structured such that the MTK components remain generated from the Dyad components.
I think that is a good compromise. I would then only ask that this is clearly documented and that users have the option to use the same components either through Dyad or through MTK.
I am not very familiar with those licenses but I have a question. Being AGPL, if I decided, inside my Institute, to use MTK now and need to make some internal modification, would I be forced to send a PR if all the use is internal but generating deliverables for projects? Notice, I will never send a software, executable, or code to anyone else. However, I will send reports generated by those algorithms.
The problem is that, if I am forced (I personally do not have anything against it), then I might need to fully stop using those components since I would need to obtain a formal government approval before.
The AGPL does not force you to make pull requests or send any source code to the distributor. It does require you to make the source code available under the same terms to your users, whether they are directly running your software or using your software via a web service.
Depending on how you make those deliverables avaliable, you may need to make the source code avaliable to receivers of the documents if they are directly interacting with the AGPLv3 software to obtain those deliverables.
AGPLv3 requires a program to offer source code to “all users interacting with it remotely through a computer network.” It doesn’t matter if you call the program a “client” or a “server,” the question you need to ask is whether or not there is a reasonable expectation that a person will be interacting with the program remotely over a network.
I see. However, no one will be directly interacting with the code itself. They will be reading documents / sheets / etc generated by this code. I have no idea if this can be called “interaction with the code”.
Likely not, since the final artifact can be just as well created without GPLd code.
Also, “make available” doesn’t mean that you have to preemptively publish any changes you make anywhere, it’s perfectly sufficient to respond to emails with diffs in case someone asks (after miraculously figuring out that you have modified some GPL library).
This is precisely my biggest problem. Most of the work I do related to algorithms used in space analysis is permitted because I can select which code I will publish and which I will not (SatelliteToolbox.jl is MIT). If I use something, modify it to meet my Institute necessity, and I am force to share this work without prior formal approval, I can face legal actions here. On the other hand, if I ask for permit to do so, I will probably be denied. I know it is something very particular with my use case, but it is important to share this point of view.
Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
I think this partially answers above:
If you develop your own private bunch of tools, based on AGPLed MTK, and use them to do modeling-for-hire, with MTK-output as final deliverable, then the AGPL does nothing (you don’t need a commercial license, and there is no license claim on the output / compiled / optimized model).
On the other hand, if your private bunch of tools is very cool and you want to sell (or gift) them to your buddies who are also in the modeling-for-hire business, then the AGPL demands that you make these tools available to your buddies under the AGPL (especially: your buddies can ask you for the source code, and put it on github or resell it. You are not allowed to have other side-contracts in place that forbid your buddies from that). This would be the same under good old GPL. The AGPL additionally demands: If you don’t sell the tools directly, but instead run them only on your server, and sell subscription / web / saas - access to your modeling-for-hire buddies, then they also must receive source-code under AGPL upon request.
Afaiu you are permitted to hire your buddies and give them temporary access to your private tools without giving them AGPL access, though. (they, just like you George are acting on behalf of “Gkountouras Consulting, Inc”)
Almost surely not. And “generated by AGPLed code” does not in itself impart any claim on generated docs. However, if the docs are generated by stitching together existing snippets from MTK, or filling in templates from MTK with numbers you provided or computed, then this imparts the same claim as if you copy-pasted these snippets from MTK sources by hand (ie the issue is not the license of the MTK executable / source code, the issue is the copyright on the “text assets” included into the MTK output). Same situation as with GCC runtime exception (which is not needed for compilation, but is needed for the c++ standard library / runtime).
The answer is there is not likely a requirement to make the source code available to people just looking at the artifacts of the code. For example see this part of the FAQ.
One major difference between the GPLv3 and AGPLv3 is that the AGPLv3 also covers accesing a program over the network. If you built a web service that links to AGPLv3 code and also allows the user to generate and download documents and spreadsheets, then there might be a requirement to share the source code.
If you or a user are running the program or accessing the program over a network, and then are manually emailing or uploading the documents, then there is not a need to make the source code available to the recipient of the email.
Where this gets unclear to me is if you start automating the email itself from a AGPLv3 linked program.
If you have very specific needs to not share the code under complex circumstances, then you might want to discuss purchasing access to MTK under a separate license from the licensor (e.g. JuliaHub).
This is one of my concerns. We have automatic diagnosis that uses simulator data to compare to the satellite telemetry and send emails if something wrong is found. My plan was to change the simulator to MTK. However, if it is being licensed using AGPL, I will probably need to avoid it for now.
The current guideline is to use open source software everywhere we can. In the contrast, I can contribute back to the community by coding algorithms (that’s why SatelliteToolbox.jl was born). I am 100% sure that I will not be able to justify purchasing a license since we have other open-source tools, like Orekit that uses Apache 2.0.
I’m not sure what the assertion that there is no license claim on a compiled model is grounded in?
It’s not 100% clear from the original description
…implementation of the circuit simulation, realtime DSP, etc…
if the output of the consulting work is software (derived from MTK), or reports/paper created with software derived from MTK.
If the former, AFAIUI, if you compile AGPL software/code into a binary, that is a derivative/covered work, and as such also AGPL licensed, no? That is precisely the point of clarification I asked for above - if there is a “runtime exception”-like solution, or something like the OpenModelica permissive runtime license. And this will be clarified at some point.
