Always ask a lawyer, indeed. But: If a plugin uses a GPL3 library it will almost definitely be GPL3 itself. You are comfortable with GPL3 plugins.
So what’s the difference between a GPL3 plugin with no dependencies and a GPL3 plugin with GPL3 dependencies from a Rack perspective? Your first hop is to GPL3 code. And Rack code itself wouldn’t include the GPL3 source due to the binary link of the plugin.
I’m pretty sure it doesn’t (I spent a long time wondering about compatibility of 3rd party licenses for plugins with this change before my earlier reply, because my knee-jerk reaction was this immediate concern). As a plugin author, with the VCV Rack Non-Commercial Plugin License Exception (NCPLE), I’m free to use the Rack API without being impacted by GPL restrictions - the NCPLE even allows me to release as closed-source as long as I distribute my plugin free-of-charge. I’m also free to use the Rack API and release my work under GPL, which is what linking against a GPL 3rd party lib would require me to do.
What the exception prevents, and you already addressed this, is you or anyone else building Rack (or a Rack derivative not subject to the NCPLE) and link against a GPL library. Which is taken care of by you not using GPL libs you don’t own.
Of course, not a lawyer etc.
Certainly, the plugin will be GPL. Let’s define some variables for conversation.
The question that @xtrememapping brought up is: Does the developer of Plugin violate Library’s license upon distribution of source and binary?
To find an answer, look at a similar situation of Rack as it is currently licensed with BSD. BSD Rack allows plugin developers to release proprietary plugins, and it would be ridiculous to say that because of this, the developer of Plugin is violating Library’s license. So what’s the difference? I think there is none.
Because the exception only permits things you can do with Rack’s source code relative to the GPLv3, not restricts things, my gut feeling is no, the developer of Plugin does not violate Library’s license.
Oh I gotcha. Yeah right does my using a GPL3 library in a binary where I release all the source, but that GPL3 binary can only run in an environment which “GPL3 with exception” (or as an extremist would say “Not GPL3” - not a position I hold but one I can imagine hearing) has it violated the terms. Interesting.
But I still don’t see why the plugin developer and the library developer are in different situations. Library is GPL3; plugin is GPL3. If the Library use in rack is inconsistent with GPL3 because of “with exception” isn’t the plugin in exactly the same situation? The extra level of indirection doesn’t seem to add all that much.
I agree with your gut though. And also agree you should check with counsel!
I just now read this, but it looks like our thought processes have reached the same exact conclusions, so I feel more confident that the GPL+NCPLE is a valid way to solve the problem. I think I am overhyping the GPL Library issue because it’s now clear to me that the answers are the same as Rack licensing has always operated.
The question is whether the Plugin developer violates the Library license. If the Plugin developer doesn’t use Library but still wishes to license Plugin under GPLv3, the question would become “Is Plugin developer violating Plugin’s license?” which of course is “no” because you can’t sue yourself for punching yourself in the face.
If your question is “Does Rack violate the Library (or Plugin) license?” the answer is inarguably “no” because 1) you can not violate a license for software which does not exist yet, and 2) the actions of others (e.g. someone releasing Plugin) cannot affect the legality of my own decisions.
Sorry if I’m misunderstanding your post, just want to get these trivialities out of the way.
You’d be surprised what people can sue for 
But I was more thinking this conflict would arise, of course, where there were multiple contributors to a project. So for instance, I’m working on a project which is GPL3 and everyone holds their own copyright (there is no entity). The idea that one of our devs thinks Rack is GPL3 consistent and another thinks it is GPL3 inconsistent was the sort of scenario I was considering. (That won’t happen with our project; I think you are not inconsistent and you have it right; and people are excited about adapting our project for rack).
Anyway as you said: seems we have found agreement.
Nah we are agreeing it’s all good.
I was thinking “does the act of distributing a GPL3 plugin which requires Rack (a GPL3-plus-exception) violate the GPL3 nature of the plugin (or subordinate library)” of course. You have clean copyright and can do whatever you want with Rack. (And I applaud you for a dual license model which I think is generally a good decision)
Forget about the plugins and the plugin developers, the issue I raised is that you won’t be able to use GPL libraries (not owned by VCV) in Rack, the application, because of the more restrictive license under which you are planning to re-license Rack source code (aka the “exceptions” and additional rules for commercial/non-commercial distributions). Not an open-source expert but I would verify this before doing the move.
Also I don’t think this is true, you can achieve binary compatibility without using any of the licensed source code (this is true for Rack and other host/plugin systems) since an API is basically a “convention” (or as they say in book, a “contract”) on where to find what in the layout of a code unit (in this case a class). It’s definitely not a fun task, but it definitely can be achieved.
Rack doesn’t need GPL libraries, problem solved. And if I used them, no proprietary plugins would be legal.
You’re technically right, but you’re talking about maybe 2,000 symbols in the API you’d need to reverse engineer. You couldn’t pay me $100k to do that.
Right, all problems solved but…
The worst the damage would be is that a commercial plugin developer wouldn’t need to pay royalties, and their API would be broken in major version increments.
The worst the damage would be is that by doing this you piss off the commercial plugin developer community which is the one making the most interesting (as in, most time invested in them, less bread-and-butter) modules for your platform and, in the end, for your users.
If these people go away your offering, which is still to reach a mature and self-sustainable state (in terms of number of users, dollars spent in plugins per year, loyalty of users towards the platform), will be less appealing.
Think of how many well established 0.6 commercial plugins might not be ported to 1.0 because developers not willing to comply with the new licensing. Who do you think the users will blame for the lack of a 1.0 version of those plugins? And who would be harmed more in the end?
I repeat, your “will of more control” is legit but it’s not the right point in time in Rack’s history to do such a shift. My (hopefully last) 2 cents, of course!
I would say don’t underestimate the open source module developpers. Some of the best Oscillators, Filters, Sequencers, Reverbs are open-source. And there are also some top quality free closed-source modules, like Vult-Free, Blamsoft and the new Alright-Devices for example.
You’re saying after the v1 release would be better? Ridiculous, this is the ideal time if the change is to be made. Rack isn’t even stable yet.
I have a dozen or so happy commercial vendors and over a hundred open-source/free plugin developers happy to be distributed in the Plugin Manager. I know of maybe 3 commercial vendors that choose not to be in the Plugin Manager. You’ve thrown lots of reasons at the wall against the relicense. Some of them have stuck, some of them haven’t. So you clearly have an agenda.
My question is: Which of the three are you? And if not, what plugins do you wish to develop that don’t benefit the VCV project? I’m more or less convinced at this point to relicense, so if you want to have a chance at convincing me, give me an honest argument of why you personally feel so strongly against it. Include all plans for plugins you wish to create and your business model. If you’re honest, I can work with you.
The goal of the relicensing isn’t to kill commercial plugins obviously, since I of course agree that most of them benefit the VCV project. So if I think in the best interests of VCV, I won’t be charging high royalties on commercial plugins. Some great plugins might even receive free royalty offers. But this needs to be on a case-by-case basis so I can make intelligent judgements.
Lets use a real example here… since many users are currently using the Bunnies collection and a video guide has just been done about them.
How would this re-licensing move affect users of these modules and the Developer?
It sounds like the plugin manager and to some extent the Rack itself will become a gateway solely under your control. Is it correct to state that only you will decide which modules are suitable for official release and can be sold under as yet unclear terms or $ split?
Have I misunderstood something here?
In that case, the developer will need to contact me about licensing in order to make a Rack v1 plugin binary and sell it, just like using any other dual-licensed GPL/commercial library. This is addressed in the original post.
So to restate, if a user has purchased the Bunnies collection… they will not run in V1 unless the Dev either works out an arrangement with you or gives them away freely…
Is that fair to say?
Correct.
Good discussion here while I was away. I think my concerns surrounding the open-source license have all been addressed.
The next thing I was wondering is what the commercial license entails. A few questions that immediately came to my mind. Will it be a set fee? Percentage of sales? Is it a fixed rate or scaled somehow to sales? Will there be some form of gate keeping i.e. plugins would need to go through an approval process? How would the commercial license differ between plugins released on the Rack store and plugins released independently?
I think some transparency in this area might alleviate a lot of developer concerns. Apologies if this information is already available somewhere, I haven’t put much effort into looking for it.