As a final follow up on this, my advice for anyone wishing to use Cabbage to produce commercial software is to develop your instruments first to make sure they are viable. Then approach me about how we can make it possible for you to sell your instruments without giving away any of your trade secrets. Some of the ideas presented above might work but might still need more fleshing out. It’s not something I’m going to spend much time on until I have some users who are really definitely interested in pursuing it and have instruments ready to go 
Discussion about licenses (commercial use of Cabbage)
BTW I asked about the license of Csound. They replied that the Csound doesn’t need to be distributed with the code using Csound. One only needs to provide a link to the Csound source IF one’s asked to.
So in that case I guess that Cabbage works the same. The LGPL means that one must provide link to source code to Csound, if asked, but does not have to open source the things that use Csound.
http://comments.gmane.org/gmane.comp.audio.csound.user/53539
Perhaps this means that Cabbage could/should be LGPL as well? Or as well MIT-license.
That’s correct. It’s been possible since Csound5 to use it in closed source applications. However, I can’t re-license Cabbage as anything other than GPL unless I buy a JUCE license. Some day, if the project receives enough donations I could think about buying a JUCE license. But the current number of donations is at $0
You could try crowdfunding it. Juce license is ‘only’ $999 and Cabbage is something that I could pay 30-70 euros easily, if it was a commercial software.
But even if I did have a JUCE license, Cabbage would remain very much open source. All the licence would enable me to do is to hide a few lines of code that would make it possible to embed a Csound source file with the binary. Which is something that I would like to be able to offer to people.
I’m still a little confused about what you would like from Cabbage? You say you would like to produce commercial software with Cabbage. But the problem is you don’t wish to share your underlying Csound source code with everyone who buys your instruments? Is this right? So why not create a way to embed the Csound source into the Cabbage binary so end-users don’t actually receive a .csd. If you make that feature public you won’t be violating any GPL, and you’ll still be able to sell your instruments?
I cannot profit from writing plug-ins using Csound if I share the code. My idea is to sell the plug-ins that I may come to develop in order to fund the development time.
So, whatever that keeps the source in non-viewable form.
You’re referring specifically to the underlying Csound source code? Or are you talking about developing new widgets/controls for Cabbage to go with your plugin?
Well, to allow for as much developer freedom it might be reasonable to expect to be able to add custom controls as well.
But this got me thinking. If Cabbage is merely a GUI layer for Csound, then if one writes the GUI without JUCE, then there are no licensing problems? I do like the controls in Cabbage though (are they all from JUCE or are some custom made by you)?
What about the Python scripting thing? Is that a JUCE feature as well?
That’s correct, you can just use the Csound API with whatever toolkit you wish if you want to create a commercial Csound product. There already exists quite a few examples of commercial Csound software.
The controls in Cabbage are standard JUCE widgets, apart from a few custom one. But I’ve modified the look and feel so that they don’t look like the standard JUCE widgets.
The Python scripting is a Csound feature Cabbage just taps into it.
I am wondering if I could use Cabbage to design and layout a GUI and then pull the file into JUCE somehow? I want to work with libPD and GEN~ in max/msp as I am a well versed visual modular programmer, but I don’t know csound.
so it seems there is a bit of confusion in this thread because the cabbage user is actually a plugin developer. I’m no expert but I find licensing interesting and so I thought I’d pipe in.
I think I need a better understanding of what cabbage does to comment more confidently on licensing, but it seems that cabbage “compiles” a binary that combines the VST sdk with a JUICE UI and some code to “link” to csound. The resulting binary I think is fine to distribute commercially unless cabbage licenses the output (which it may be important to expressly make clear in the license that exported works are not covered in the cabbage license) OR VST prevents closed source distribition (which we know is not true) OR JUICE does. That last one is what I’m most concerned about. I believe the plugin dev (who is also the cabbage user) should pay JUICE for a license for a commercial plugin. This maybe could be avoided if the GUI part is a separate binary that you release under GPL.
Of course the csound instrument file needs to get wrapped into that binary for this to be any use to a proprietary plugin developer. It wasn’t clear to me if that’s being done yet or not.
Does that seem accurate? I wish I had a lawyer friend who could go over all this. Licensing will become more important as cabbage becomes more widely known.
It’s a little tricky. Users can’t sell Cabbage but they can freely distribute it. They can sell their instruments, but the code is not currently bundled into the binaries. Therefore users must also be willing to distribute their Csound code. If enough people were interested I could look into a way of bundling the Csound code, but it would need to be licensed as open source unless I purchase a commercial license from JUCE. Therefore, people can see how Cabbage does it in the source code. On the other hand, only developers themselves would be able to follow the C++ code and figure out how it all works, and if they go to that much trouble, maybe they’ll just start contributing to Cabbage.
As it stands, if we want to sell Cabbage plugins without violating the terms of the GPL. they need to be open source. If enough people were still interested we could look at getting a commercial license for JUCE. But it just got costly. I have to say, this is merely my understanding of things. I could well be wrong. Either way I’m happy to discuss whatever options you may think of.
1 Like
my immediate thought is that there should be some way for a developer to get his or her own commercial license for JUCE if they want to make non-GPL plugins and use that for cabbage. So it should be possible but not the default. So you don’t need one built into cabbage, just a way to add a commercial licence. Would that work?
Is there a different SDK for proprietary vs GPL JUCE?
No, the SDKs are the same. I think the only way it could work would be for Cabbage to sell a closed source port that users can use if they wish to sell any Cabbage instruments. Having them gain their own JUCE licenses would cause a serious mess because Cabbage is GPL-ed, and they have no authority to change. Only I do. I could release a closed source version, if I was able to get a commercial license for JUCE. But that costs quite a sum. So we’re back to square one 
so then part of cabbage is compiled into the binary, not just a tool used to compile the plugin. Thats the part I didn’t understand. It does make it more complicated.
Can the csound instrument be kept proprietary somehow but the cabbage part remain GPL? I think some commercial devs would go for that.
Cabbage doesn’t actually compile anything. It simply duplicates and modifies a dummy plugin that can dynamically become any instrument described in the users end code. Users can license their Csound code in any way they wish, but because of the way Cabbage is written, the Csound code can be accessed by the users. I’m of the opinion that anyone who would buy a Cabbage instrument would do so because they can’t afford to spend time learning Csound, In which case the Csound source code is of little use to them. I imagine anyone with a good grasp of Csound will simply develop their own instruments.
1 Like
Update…
The guys at ROLI are soon to announce a new license which will let users publish closed source software, so long as it contains a splash-screen saying made with JUCE. This means that I could potentially offer a version of Cabbage that can hide Csound source code from users, thus protecting whatever synthesis and processing algorithms users may wish to keep secret.
Anyway, I’m not sure how much interest there is in this. I just thought I would put it out there.
2 Likes
Hey Rory, first of thank you for creating this amazing piece of software. 
I just discovered it today and this is the best solution yet for me to develop audio device ideas and have them actually exported as viable VSTs to be used directly in the DAW. The only downside for me currently is, that from what I can see in the thread currently if you share a plugin, you always share the c-sound code as well. I believe having an option to have it encrypted, would be a great addition!
That’s kind of what my last post to this thread was about. I could now potentially create a closed source version of Cabbage that would hide the Csound code from users. However, it would involve a little bit of work, and I think I would probably change a nominal fee for it. But it’s certainly something I would be willing to explore.
Sold, i would totally pay a small fee for that!
Matt