I work on a couple of synths which are under GPL3. One of them is a JUCE synth and some of our users have asked if the standalone of this could contain ASIO. This is mechanically easy in JUCE.
But to do it, a few headers need to be included in the code. The ASIO license is pretty clearly not compatible with GPL3 software (someone needs to sign it, there’s no redistribution rights without others signing it, etc…) so I shared with the user that I would not be able to do it.
But: you have of course released VST3SDK under a mixed GPL3 license (thank you for that; it has made VST3 possible in the open source synth world in a wonderful way). And so I was wondering if there has been any consideration to doing the same with ASIO, or at least with the ASIO client libraries (I don’t need to write an ASIO driver, it seems, just send ASIO messages out; but honestly I spend most of time time on macOS so I’m not an ASIO expert, I just realized the code wasn’t licensable).
Our workaround is to tell users to execute an ASIO license themselves, set a build flag on our tools, and build themselves. For a tiny subset of our users this works, but most users are not working in environments where they can self-compile and execute a license.
I’m wondering if theres any further thought on this? It’s a bummer, but the way things stand now at the end of the summer we will end up releasing a set of synths where the standalone exe version is on mac and linux only, because Windows is not useful without ASIO it seems, and ASIO licenses seem to have a incompatibility with GPL3.
I think it’s debatable whether the Steinberg licence agreement for ASIO is incompatible with the GPL. It depends perhaps on exactly what you are doing with the ASIO code in your application, but you might be able to grant additional permissions under the terms of the GPLv3 that anyone (modifying your code and?) distributing it also has to obtain a licence from Steinberg. The GPL lets you do that as long as the additional permissions do not constitute “further restrictions” under the terms of the GPL’s Section 10 (so stuff like demands for money, which Steinberg don’t make). I’ve not looked hard enough to see if they do.
More likely though is that if you don’t have any Steinberg code in your app (so maybe the declarations of the methods, not the code), then you could interpret their agreement to distribute “an application that can host ASIO device drivers” as only relating the binary, not the source. All you need therefore do is say that if somebody wants to re-distribute your binary, they need to get the Steinberg agreement. The GPL only applies to the source.
But of course none of us are lawyers, we can’t pay for lawyers, and even if we could those lawyers may not understand what your app is actually doing …
I recently purchased a Steinberg UR22 AI for home use and am disappointed that the ASIO driver is not legally available to open-source software; specifically, Audacity. In order to solve some latency problems using Audacity with this UR22 I have had to resort to downloading the Steinberg ASIO SDK and rebuilding my own personal (non-redistributable, non-professional-use) version of Audacity to support the ASIO driver. It works, but only just and is, at best, a marginally effective workaround.
I had heard rumors that Steinberg/Yamaha might loosen their licensing restrictions but have about no movement on that front. I respectfully ask that the Steinberg ASIO driver be made available for use under GNU or MIT-style open-source software.
Different software has different licenses and open source licenses are a cluster of things, not a single thing.
For the use case of being a client of asio, the gpl3 license (which audacity and surge use but ardour does not) is incompatible with the requirement that the associated code in asio can’t be redistributed.
Basically gpl3 requires that if you distribute a binary you distribute the source; and asio license says you can’t redistribute the source.
Steinberg fixed this problem with vst3 using a “dual license” approach. The vst3sdk can either be gpl3 (which “contages” requiring your client to be open) or commercial.
If the same were to occur with asio, I could turn on asio in all our properties in about 5 minutes, which is what prompted my original request. Essentially - symmetrize asio and vst3. (There are other strategies too like make the client api very open and the driver api still not).
That is odd. The Audacity man page about ASIO states it is not compatible with software licensed under GPL, the same as Ardour. I built my own personal Audacity .exe using the Steinberg ASIO SDK and it kind of, sort of, works.
Oh and we have made it so it is trivially easy for you to build a surge exe with asio yourself. It’s a flag in our cmake! Works fantastically! Just we can’t redistribute that binary.
Bumping this, I’m getting similar feedback from my users. For many users, audio apps are almost useless on Windows without ASIO. It’s a shame I can’t add support for ASIO for legal reasons only.
A dual license like you’ve done for the VST3 SDK would help a lot. There are many FOSS apps that would benefit a lot from this.
