Correct/legal way to distribute desktop app that uses Gurobi
OngoingWhat is the right way to distribute a desktop application that uses Gurobi? Specifically, what gurobi files am I allowed to redistribute in our application's installer for a .NET desktop application?
Internally, we've been bundling required Gurobi DLLs in the application installer. The application deliberately does not work unless the user has their own valid Gurobi license file installed on their workstation - the application does NOT include a license file and does NOT give any access to Gurobi that they would not have without the application installed. But if they have Gurobi set up correctly, the application works right out of the box.
We now plan to distribute a Gurobi-based application outside of our company. The most reliable approach would be to include Gurobi DLLs in our installer, just as we have done internally. You don't have to worry about version conflicts, path issues, or requiring the user to do extra setup. But, the user agreement seems to say that isn't allowed. Unfortunately it's not just convenience that makes us want/need to install at least one gurobi DLL as part of our application - the .NET framework doesn't use PATH to find assemblies, so the gurobi .NET assembly either needs to be in the application folder or we need to tell .NET exactly where to look. We won't know exactly where Gurobi is installed because these are user's machines configured in whatever way they happened to set things up.
In other words, .NET applications you didn't compile yourself won't work even if you have Gurobi installed, unless there is a gurobi .NET assembly installed in your application folder.
So, are we truly not allowed to include any Gurobi DLLs whatsoever in our installers? If we can't include at least gurobi95.netstandard20.dll in our application folder then we'll have to drop Gurobi support (fortunately we already have the plumbing in place to use a different solver).
Please sign in to leave a comment.
Comments
0 comments