Lock down versioning/release process

[yupferris]

I really want to do this ASAP, both to make it easier for users to get up and running without necessarily building anything (assuming we'd ship pre-built VSTs and perhaps also libs/converter tools as part of the releases) but also as I think WS could be made a lot better with a few fundamental changes/fixes, and I'd rather start doing those after we get a release of WS in its current state made, so users can in theory always have something to go back to for old projects if it's important to them (though I suspect users are almost always happier with new toys than ways to keep the old ones working).

[yupferris]

We probably also want some way of determining tool/VST versions so it's easy for users to check their compatibility.

[yupferris]

Note that when distributing plugins, it's crucial that we adhere to the VST SDK license terms, whatever those may be (this requires some investigation). The tools themselves might also have licenses we need to adhere to (eg. the converter tests at least use a third-party JSON codec lib).

[yupferris]

OK, so TL;DR the VST SDK terms are really awful, see https://developer.steinberg.help/display/VST/VST+3+Licensing. If I'm interpreting them correctly, then TL;DR we would have to:

• Start putting "VST Compatible" logos and Steinberg copyright text on basically everything (doable I guess, but it seems we might already be in violation of this?)
• Re-license WS as GPLv3 (lol nope)
• Migrate to VST3 ("If you do not have a license agreement signed with Steinberg before October 2018, you are not allowed to distribute VST 2 plug-ins or VST 2 hosts!" yes, that's really what it says)

Alternatively we might be able to find an alternative framework (eg. iPlug2, which is not yet ready for prime-time) or reimplement this API ourselves (the API surface is fairly small, but can we do this "clean-room" enough etc? Will plugin hosts drop VST2 support any time soon?); neither are very attractive right now. Ugh.

Note that we should still be able to version/ship source-only releases, which is likely sufficient for what I really want here (which is to nail down proper versions so we can start making potentially-breaking changes).

[yupferris]

I've looked into/thought a bit more about this, and I'm currently thinking the following (note that the usual IANAL/this is not legal advice etc apply):

• We re-implement the VST 2 API itself. I believe this API surface is fairly small, and it shouldn't be too hard to get something sufficient for our (relatively minimal) needs, esp. by modeling it after something like vst-rs. This way, we drop the VST SDK dependency and all of the terms/conditions that come with it.
• For GUI, we maintain our current dependency on VSTGUI, which is BSD3, which means its licensing terms are very easy to abide by. We should rely on the standalone distribution instead of the one that ships with the VST SDK.
• "VST" is still a registered trademark of Steinberg, and we should mention this in our documentation/licensing for distribution.
• Re "If you do not have a license agreement signed with Steinberg before October 2018, you are not allowed to distribute VST 2 plug-ins or VST 2 hosts!" - yeah, no. There's no way that using our own implementation of an API can ever be enforceably disallowed. We absolutely can and should explicitly ignore/violate this.

So, I think the next step is to look into reimplementing the parts of the VST2 plugin API that we actually want/need to support, using vst-rs as a reference/model impl.

[yupferris]

After looking a bit into vst-rs and talking to the folks behind it, it still seems some of this stuff operates in a legal grey-area, which I'm not entirely thrilled about. Another option came up, which was to migrate to VST 3 proper, still BYOSDK for developers, and sign the VST 3 proprietary agreement myself in order to ship binary builds on behalf of the project (at least covering the main repo; we might need to be very explicit that other folks couldn't distribute the same plugs under these terms). As far as I can tell, this avoids any legal grey-areas and allows us to be fully compliant with the license terms, but could actually be considered a breaking change, as it locks out older DAWs that don't support VST 3. One such DAW is Live 9, which we've used for years and currently have test projects for in the converter test suite. I'm not entirely sure if this matters tho; afaik most folks are on Live 10 or even 11 by now, but still.

All of this is still fairly unsatisfactory, but I realized another important point - shipping binary plug builds and starting to have versioned/tagged "releases" are two separate issues, and we can have one without the other. So, I'm going to spawn another issue (Edit: #83) to handle the binary build work (and defer it probably) and instead shrink-wrap today's codebase as a source release and go from there.

[yupferris]

Since we don't currently build any binaries or anything, I think we can simply draft tagged source releases via the Github UI for now, and properly document/detail a process (likely including a proper changelog too) later for future versions.