What kind of licenses are there in the included algorithms (such as those used by the examples)?
Can they be leveraged for producing commercial VST plug-ins out of Cabbage?
Discussion about licenses (commercial use of Cabbage)
All of the examples are copyrighted to their authors. If you wish to port one of the examples as a commercial product you should contact the author first. FYI, all of the opcodes and processing algorithms included with Csound are LGPL, and can be freely used in commercial products. Cabbage is GPL but that shouldnāt stop you selling Cabbage based products, as long as you adhere to the conditions of the license.
Actually I think LGPL is not trivially compatible with audio plug-ins. Or have not heard proper workarounds for the following problem.
The reason is that plug-ins (VST, ā¦) are always distributed in such way that the source is not available. LGPL wants the source of the LGPLād code distributed, which is impossible other than by, for example, providing the LPGLād code (e.g. as a .dll) in the .zip file the plug-in is distributed in.
I donāt know how Cabbageās license relates to the license of the produced VST. The VST SDK is known to be incompatible with GPL code, since the VST SDK cannot be distributed (itās proprietary), thus VSTs cannot adhere to the GPL. I donāt know how youāve worked out that Cabbage can be GPL, but produce VSTs.
This should be clarified since to me Cabbage seems very suited for developing certain kinds of plug-ins in the style of āSynthMakerā that benefit from a large library of pre-made stuff and a simple and fast to use āscripting languageā.
You should also clarify, how is Juce used in Cabbage. Since Juce is commercial software if producing commercial VSTs.
If it turns out that Juce is creating a problem, then I might recommend porting Cabbage to WDL-OL . Or I might attempt it myself.
I donāt, and never will distribute the VST SDK. To do so would violate the terms of their license. All my Cabbage code is available for anyone to view on Github, and is also available to download through a .zip file from the same site. I will admit that distributing pre-built versions of Cabbage is a grey area. But so far no representative of Steinberg has taken any issue with it. Iāve not heard of any other open source developers that have had an issue with this. Iām also using a version of their SDK that is no longer maintained by them. It has been mark obsolete. I find it highly unlikely that they will take issue with this project.
The reason I use JUCE is because I can use it as a GPL library. WDL-OL looks interesting, but is no where near as extensive as JUCE. For now Iām more than happy to continue using JUCE as a GPL library.
Cabbage users are free to licence their Cabbage patches as they see fit. Their code does not belong to the Cabbage/Csound code base, so doesnāt have to adhere to the terms of the GPL. If however, a user wishes to contribute to Cabbage in the form of some low level C/C++ code, then it will need to be GPLāed too. Users can publish or sell Cabbage instruments without ever needing to distribute binaries, so can remain exempt from any of kind of licensing issues.
And what about the license status of the VSTs exported from Cabbage?
Can they be distributed as such or are there other conditions than those imposed by the musical/DSP algorithm creators (if oneās using a copyrighted algorithm).
This is where it gets interesting 
Technically speaking, VSTs exported with Cabbage are GPL, because they have been spawned from Cabbage. However, the underlying Csound/Cabbage code that the instrument is built with can be any license. Users who wish to publish plugins have two options. They can either distribute their instrument code with a Cabbage VST binary, or they can simply publish their instrument code and get their end users to export it as a VST plugin using Cabbage. Personally speaking, Iāve no issue with users distributing Cabbage binaries with their instrument code commercially or otherwise. But as we discussed previously, this may be in breach of the VST SDK license.
All the processing algorithms used by Csound are compatible with the LGPL license, otherwise they could not be distributed with Csound. Therefore, Iām pretty sure the underlying algorithms used in the examples are all available in the public domain. So I donāt think you need to ask permission from anyone to develop an FM synth per say. However, if you wish to adapt a UI, or UX element from one of the examples Iād suggest you contact the author.
Both of those options seem to be asking for opening the source, which is not what a commercial plug-in developer would want to do. If they wish to protect their algorithms or e.g. avoid unlicensed distribution.
In what way do either of the two options Iāve mentioned imply that you need to release your instrument code as open source? Cabbage is a framework for developing audio software. Users implement their software using a high level scripting language. The scripts you write can be licensed in any way you see fit. They are not bound in any way to any open source license.
This isnāt anything new in the world of software development. The vast majority of audio software in existence today was and is developed using GCC/G++. That compiler is GPL-ed, but it doesnāt stop companies from selling the software they create with it.
They can either distribute their instrument code with a Cabbage VST binary, or they can simply publish their instrument code and get their end users to export it as a VST plugin using Cabbage.
Snap, I just thought of this after I sent the last message. So basically we need a way to hide that code from users, and still abide by the GPL. Iām open to suggestions? Surely there is a clever way to do this?
Iāve just seen many plug-in and plug-in framework developers deviate from the GPL, because there are other licenses that are more trouble-free.
I donāt know whatās the problem in allowing the closing of the source code, if the developer wants to close it. One can still enforce e.g. attributing the source that comes from other authors, but not displaying it.
Have a look at e.g. the WDL-OL license:
The problem is this, if I close the source code for Cabbage I have to pay a fee to use JUCE. Thatās not currently viable. Itās GPL versus paying $3000-$5,000. The WDL-OL license is great but for me the quality of the library is far more important than its license. As such WDL-OL doesnāt come close to JUCE. I would have to remove many features of Cabbage if I changed and it would also mean saying goodbye to all the Linux Cabbage users. Considering Iām a Linux user myself there is no way I could support such a move.
The bottom line is that it wouldnāt be hard to hide the underlying Csound code from the end user if you didnāt want them to see it. The very first version of Cabbage (circa 2008) embedded the Csound code into the binary. It wasnāt to hide it from the end-user, but to make it easier to distribute binaries.
The WDL-OL camp knows that JUCE is a more advanced framework, but WDL-OL does have some architectural advantages over JUCE. E.g. the code is much more clearer and modular. So it could be expected that WDL-OL is at least speculatively trying to compete with the JUCE user base. Itās just that it would take a lot more developer effort to add GUI designers and such quirks, but they have been discussed at the WDL-OL forums. Linux support also. Iām personally using WDL-OL over JUCE, because of the modularity and openness and since I can cope without the extras that JUCE offers.
A fork perhaps?
In my experience forks are rarely successful if they canāt offer the same features as their original project, but Iām happy for you to try. I guess the number one advantage of a fork over the current project would be that the ambiguity over GPL and VST would be eliminated? Considering this has never been an issue, Iām not sure if it would be worth the hassle? I think a better idea would be to simply use WDL-OL and Csound to create your own plugins, rather than trying to recreate Cabbage using WDL-OL?
p.s. It seems to me that OL is using JUCE more these days than WDL?
I was thinking that it would be cool to use Cabbage for commercial plug-in development since it reminds of the fairly successful ReaJS for Reaper. ReaJS is a simple scripting language āsimilar toā Cabbage that leverages lower level C++ DSP and itās really good for creating plug-ins for Reaper. It does not pose much limitations and itās much faster than writing C++.
I would love for Cabbage users to be able to sell their instruments without having to share their Csound/Cabbage code. Iām sure it can be done. The code could for example be encrypted and saved as binary data itself that Cabbage loads on startup. Or it could simply be embedded into the exported binary?
So youāre thinking going around the GPL by having the user compile the VST by opening the plug-in in Cabbage and exporting?
I guess it could work, especially if one could provide some sort of runnable script for doing it automatically. I.e. that the user can run e.g. an install.exe or install.sh or something.
Iām not trying to get āaroundā the GPL. I just donāt think it should prevent users from selling what are essentially āadd-onsā. Anyhow, I was thinking that when the end user exports their plugin for distribution, Cabbage could embed the code into it as binary data. From then on in the code would be embedded and hidden from any future users?
And the the usage of that code would be performed by the user having to download Cabbage (and export to VST from that, if he/she wanted to use the VST)?
One idea could be to make a VST (and perhaps even RTAS and AAX) plug-in version of Cabbage. So that one can load Cabbage into a VST host. Then all that was distributed was āCabbage patchesā. Thatās how ReaJS works.
It does seem that Cabbage AU is in the pipeline already. So have you thought about Cabbage VST?
Not necessarily, but this would certainly take any culpability away from the end-user in terms of distributing binaries. But I imagine a Cabbage user could export a binary which in turn would embed the Csound code. Users could then distribute this binary if they wished.
I always thought it was more streamlined to go with the current approach, which is to simply export a VST plugin from Cabbage, but I see your point. I think many users would still like to be able to export unique VST plugins with Cabbage.
The AU implementation exists simply because I couldnāt figure out how to do the same thing with AUs as I do with VSTs. It drove me mad trying. In the end I decided that I could simply let users instantiate a Cabage AU and load whatever instruments they wanted. I guess if users were loading binaries instead of code it might work. But the problem is that VSTs canāt dynamically alter the number of parameters they have.