What would be your suggestion for handling my two purposes in the original post?
…while not affecting open-source plugins whatsoever. The first is a stronger requirement than the second.
Yes that’s right; but the acceptance of the granted open source Rack license the portion of my code which links Rack may be in some technical sense in conflict with the MIT license (since that rack linking part of my code can’t be included in a proprietary system as is, so it isn’t MIT licensed).
Again this isn’t a big deal and is easy to work around. If you really care have a submodule which exports an API and make your rack code as “small” as possible or what not. And (unlike it appears you!) I’m supportive of dual license models which allow commercial / open source software so I think the plan is reasonable. Just all edge cases, as it always when you get into license stuff!
Actually @Vortico I’ve figured out a great way to frame my question. Lets take this super simple bit of code
#if BUILD_WITH_RACK
#include "rack.hpp"
#endif
struct PaulsSuperClass
#if BUILD_WITH_RACK
: rack::Module
#endif
{
};
So clearly you get the idea. I have a makefile which toggle BUILD_WITH_RACK to either use it or not. So clearly your license lets me license that MIT plus accepting your GPL3 waiver for free software automatically. But if someone included that source in a proprietary system (and just compiled it without BUILD_WITH_RACK defined) is your intent to be OK with that?
Like I said an edge case. The other choice is to have PaulsSuperClass not subclass Rack at all and then add another class above it which you have completely distinct. But wondering how you think about that particular question.
Seems to me that the reference to Rack’s API is still there regardless of macros, so the GPL would still cover the software (assuming FSF is right about subclassing = derived work).
Normally most people do their complicated DSP in another program. For small stuff <1000 lines, I usually put everything in one file. Anything more, and I break DSP into header libraries and other source files. If this is done, you can simply delete MyModule.cpp file, so Rack’s GPL would no longer possibly cover the whole repo.
Trademarks work for Mozilla. Forks (ex. Palemoon) have to relabel/rebrand and build their own communities and resources. [L]GPL means others have to keep the code published, so anything interesting they do can be recaptured back upstream.
More than that, is somewhat outside of the FOSS realm. CC-BY-NC comes to mind. It isn’t really intended for code, but there’s not many OSS-approved licenses that try to prevent people from sales/donations/crowdfunds. I still find this angle somewhat strange since Blender, Krita, Godot, Mozilla and KDE foundations are operating without non-commercial clauses just through inertia and support.
I ultimately understand and sympathize for wanting to avoid having work copied verbatim and remarketed. An LGPL core or a GPL core with an open plugin endpoint (that takes non-GPL code, i think possible but might need some finagling) seems fine.
I don’t believe this is a valid desire.
How many DAWs out there only allow plugins the developer personally approves of? (Not many.)
Do you write the FSF a royalty check for having used GCC to write commercial software which in turn seeks royalties for commercial software? (If no, why not? Isn’t this what you want the gumshoe sellers to do?)
I ultimately do not know why some plugins are being sold on Gumshoe instead of the plugin manager. I suspect some are from explicit rejection, though a few appear not to be hardware clones. It might be worthwhile (if not already done, since there’s no way I would know) to figure out why they are doing this, since trying to forcibly deplatform them in this way could create permanent ill-will instead of compliance.
Yes that’s the solution obviously. And what all rational software would do (and what you and I discussed this morning). My point was more subtle or perhaps more annoying (I’m sorry to keep on about this).
You seem to be saying the code I showed above can’t be licensed under the MIT license since it adds conditions beyond just the representation condition.
Again that’s fine for me. But it means I’m not sure your dual license lets people write MIT plugins.
This is our sole disagreement. Consider the following libraries
These are all libraries while Rack is both a library and host for plugins, but there is some similarity. All of these projects charge fixed rates or royalties for non-GPL software. Nothing is wrong with this, and I still consider them free software as much as anything else. These software packages are extremely popular in the open-source community well. If you use any distro of Linux with video/audio players, you probably have at least 1 or 2 installed. None of them are open-contribution of course.
Now consider all of my commercial competitors. Name a single one (it doesn’t even have to be a direct competitor) that offers commercial plugin licensing automatically and irrevocably for free.
In summary, in order for me to believe that it’s a good idea to freely allow commercial plugins to exist with no compensation, I need to be convinced of two points:
Not only do I disbelieve those points, I think the large majority of users and plugin developers agree with me. And since they’re fine with it, Rack cannot be significantly threatened by commercial plugin licenses. I forsee a future where VCV Rack is still a standard in open-source modular, having hundreds more open-source plugins than it does now, and dozens of new commercial + licensed Eurorack plugins as well.
I just thought of a point that could be misleading people.
In 5 years, whose commercial plugins will be most popular in VCV Rack?
After re-reading some of these posts, it seems some of you would answer “unknown small developers that make $2k on their plugin”.
Those plugins will certain be around, but the most popular products will be established companies that are mature enough to be accustomed to paying for licenses to join a professional platform. They might make $20-200k per plugin. I am already contracted with a dozen developers that are waiting a year for the stability of Rack to level off. (I actively recommend to large companies to not start developing on the crusty v0.6 API and maybe even wait a bit for v1 to settle after release.) These contracts will be grandfathered into the proposed commercial plugin license, so this entire thread doesn’t affect them. They just want their profit share, and Rack is a growing platform that can supply it.
As for smaller companies/individuals, I don’t see why VCV would fail to license these parties as well. It takes me only a few hundred $ of effort to handle each small company’s technical questions, requested Rack features, process payments, handle customers and refunds/chargebacks, and handle banking/taxes/accounting/legal. If a company is making a few thousand $, it is worth it for VCV to pick them up because a bit of profit is made for each one. They won’t individually pay much of my salary, but their power will be in numbers. If there’s a flood of small companies, their revenue could pay for future contractors/employees of VCV to work on GPL-licensed software that is pumped back into Rack itself.
Hopefully this view gives some insight into this debate.
Finally, I want to make one last point about current commercial plugins.
Several months from now, when the dust has settled from Rack’s relicensing, the process for developing a commercial plugin will be
If your offer is not accepted, your time isn’t wasted, you simply move on with your life.
Dozens of commercial plugins are already available in the VCV Plugin Manager. There are only 3 I’m aware of that sold outside. Migrating them into licensing offers will be a one-time growing pain of the relicense. However, once it’s over they will likely agree on something to make these plugins available again. I am not aware of any of their reasons for not being on the Plugin Manager, so I can’t make a statement on whether they will then agree on joining the Plugin Manager. But I’m hopefully that a commercial license of some sort can be worked out with all of them.
I believe those would qualify as direct competitors for a DAW.
Oh.
That explains everything.
I thought this whole thread was weird. Now I feel like this thread was not asking, but informing us about a weaponized license change to protect the desires of upcoming contract interests and seeing if there was going to be extreme backlash.
I feel like I made the point clear enough from the original post when I said “[this relicense] prevents unlicensed commercial clones of VCV Rack itself that do not support the VCV project”. Anyway, it seems we’re on the same page now. The mission of Rack has never been to been to give out free licenses to commercial plugins to make profit for free. VCV uses commercial plugins as a significant funding source. See https://vcvrack.com/manual/About.html#mission-statement, particularly the last paragraph.
Now let’s end the debate of the purpose for the change since this isn’t really the focus of the thread and focus on the details of the best way to pull it off in a way that will most benefit the open-source community of users and developers, while simultaneously guaranteeing the success of VCV Rack v1+ as a professional platform for getting actual work done, rather than an unstable toy like v0.6.
Thanks to the many people who have brought up fantastic points in this thread. As v1 is finished, I’ll post any updates about the licensing before going live. Who knows what the exact form of the license will be, but I think we’ve thought out most of the scenarios and details.
If I may ask a tangential question here [move this to another thread if you like], what is the plan if you get run over by a (proverbial) bus Andrew? In order to be recognised as a professional platform, and with so many developers of all types, not to mention us users, dependent on one man, is there a disaster plan (hopefully never required) in place?
@Skrylar, I respect your passion for FLOSS but I don’t think that’s fair. Given the quality of free contributions to VCV Rack, and the very very low barriers to releasing free plugins through the Manager, if existing contracted developers really had a hold of @Vortico’s strings here they would be wanting to put up barriers to libre projects, not peer commercial developers. I’m guessing that a fair number of these are recognizable names who are effectively licensing existing IP, and so they would already have a leg up over less brand-worthy commercial competitors; the harder task is to prove themselves against free, functionally similar plugins.
This is basically how partner development for big curated professional platforms like UAD and Plugin Alliance works, right? What’s novel about the NCPLE is that it allows free software a guaranteed path towards peer status on the same platform (which UAD would never do in a million years) and provides them distribution through the same central repository as the commercial options (which PA would never do in a million years).
I’m sympathetic to the existing Gumroad and offsite devs (I think there are five, actually) and I hope @Vortico is able to bring them into the fold. I also hope that he makes fair decisions about who to grant commercial licenses to and on what terms. (One idea might be an open-door contract, like the Unity Asset Store contract, with a base rate and guidelines, that practically guarantees acceptance if guidelines are followed; better terms could be negotiated privately).
Softube has a worse platform, which they sell very cheaply, and some impressive licenses, which start near the high end of existing VCV Rack pricing and go up from there. I would absolutely love to see some of those licenses in VCV Rack. But if Softube were to release VCV Rack ports of their modules, I wouldn’t want them to sell them through their own platform and capture 100% of the proceeds (which they absolutely could do under the existing license), and I certainly wouldn’t want them to start stripping the VCV Rack v1 code for parts.
This is a competitive industry and V1 is going to be in the major leagues, feature- and content-wise. For Rack to reach its potential, it’s got to protect both its codebase and its revenue stream.
Also, Rack is one person’s software in a way that plenty of open-source projects are not. Third-party commits to < V1 weren’t significant (there’s basically only one other substantive contributor, and that was on a limited set of MIDI issues), so this isn’t an attempt to flip a community-written project for commercial advantage. The only existing contributors this disadvantages (as far as I can tell) are the non-Plugin-Manager authors, and while some of them are pretty good, there are literally only a handful, and they certainly aren’t responsible for VCV Rack’s success. To the extent that this is a bump in the road for them I don’t think it’s an ethical issue, especially if they’re handled reasonably going forward.
Currently the plan will happen as usual for companies this size. My family will inherit the company who will put it up for sale. If VCV becomes incorporated with a board of directors, this will change. However, VCV’s revenue is not high enough to even begin talking about that.
Correct. I’m a big NI Kontakt user and love the high-quality third-party sample libraries. I think NI Reaktor works the same way but I’m not sure. You come to them (or they come to you) and say you want to record a Bossendorfer in a cathedral, you agree on a fair license to use the Kontakt platform, and you get to work with the guarantee that your work will be released under the pre-agreed terms, provided that you hold your side of the contract and not release something completely different, or a year late, or a Boston in a bathroom.
Just a quick note about that if anyone’s interested. “bontric” from GitHub offered his time and skill to help design the MIDI modules with me in v0.5 or so. In v0.6, Grayscale overhauled the design, and in v1 all MIDI modules were completely rewritten to support polyphony and other features. bontric’s help was much appreciated, but I later realized that working in “sprints” with Grayscale over Skype allowed the redesign to happen over 1-2 days, which was much faster than the first designs, which took a few weeks.
This is the plan. I have no plan to give outside commercial plugin developers ridiculous terms. They will be offered normal contracts like the others.
I think there was some talk about “professionalism” a few dozen posts above (regarding that my quick license change was unprofessional). Sure, but if you run a large audio company, a BSD license would appear much more unprofessional to major leagues than a relicense to GPL with a commercial option. i.e “why should we develop for your platform if you don’t even have a solid grasp on its rights?” kind of thing.
What about projects which are already 6 months in development prior to this decision? I think a more fair approach would be to not apply this change to modules which have been sold/released in 0.6.x already so that at least the users who bought those plugins are not affected by this radical change in case the developer decides not to come a agreement with you.
After the relicense, if you contact me for licensing with your story, I can be understanding and accommodating. Again, my goal is not to prevent people from developing on Rack, as that would be a lost opportunity for me as much as it would be for you.
And in the event of it being sold moving it to GPL rather than a more permissive licence would prevent a future buyer from ‘closing’ the source for Rack and the API (by forking it and not making any more commits to the original)? ( I’m thinking of Rogue Amoeba, Soundflower & Loopback.)
Unfortunately not how it works. Selling the company would involve selling the copyrights owned by VCV.