No need to relicense your plugin. The Apache v2 license is compatible with GPLv3.
Yes, compiling a binary that can be loaded by VCV Rack makes your binary a derived work of Rack, so it needs to follow Rack’s license.
MIT and 3-clause BSD are also GPLv3 compatible, so a plugin released under those licenses are permitted by the GPLv3. No need to relicense any plugins to GPLv3. See the “What about open-source plugins?” section of my original post.
Oh yeah. I would relicense just because gpl3 is better.
And yeah totally get it on binary distributions. My only point was the gnu faq says if you subclass gpl3 code your source is derived. That may have consequences which require people to split code into, say, mit source which is included by their module indirectly rather than in their code. Or do you read the gnu faq differently?
But most importantly: thanks! The world having better open software is wonderful and I appreciate you for making it happen!
I am almost certain this is not what GPL compatible means. You can use compatible code in your GPL software, not the other way around. See this part of the FAQ. All current plugins would need to be released with the same GPL version as Rack.
I think the proposed exception would provide the escape hatch for this, but I don’t know what legal implications that would have for downstream code. Seems like it might get messy mixing more permissive licenses with a GPL with exceptions.
Another thing to consider would be current contributions to the code base. There appears to be 8 contributors on Github that are not you. Have they all agreed to transfer ownership? I think your last paragraph is hinting at this, but I’m not sure.
I am definitely not a lawyer, so I think some real legal council would be wise.
This was the point I was also talking about. Binary distribution vs source contagion seem like different things; and the gnu faqs seem to make me think that source contagion is a real possibility in a subclass oriented system like Rack.
I wonder if there is some clever solution like “rack SDK is MIT or Apache or BSD-3 and rack runtime is GPL3” which may avoid plugin source contagion but still meet the laudable goal of stopping non-supporting commercial activities.
Of course if your counsel has told you that the GPL is not contagious in subclassing systems then that’s fine too. Like I said, i’m moving all my plugs to GPL3 independently of your decision!
I’ll address the easy question first:
All contributed code has eventually been replaced in the v1 branch.
Now the tough one:
Is a plugin a derived work of Rack?
To get the simple cases out of the way, it is inarguable that a compiled plugin binary is a derivative work of Rack, since binaries include the result of Rack source code. It is also inarguable that a plugin that copies a significant amount of code from Rack is a derivative work of Rack. The difficulty is a plugin whose source code doesn’t.
17 U.S.C. §101 is not specific enough to determine whether
struct Bar : Foo {
...
};
is a derivative work of
struct Foo {
...
};
The FSF claims that it is, I claim that it isn’t, but neither of our opinions matter in a court, so we can only assume that it might.
I fully believe that exception #1 handles this issue for all plugins. The text I used is draft quality for the purpose of discussion and openness, but the final license will clean it up and fully define “VCV Rack plugin”.
By “downstream”, I assume you are thinking of the following scenario:
Draft license to be placed in https://github.com/VCVRack/Rack/blob/v1/LICENSE.md:
All VCV Rack source code is copyright © 2019 VCV and licensed under GPLv3 with a non-commercial plugin license exception and commercial licensing available.
VCV Rack Non-Commercial Plugin License Exception
A Plugin is defined as a software package intended to be linked and executed by this software.
You are granted the permission to use and redistribute this software’s Application Programming Interface (API) in your Plugin in source and binary forms, as well as link to this software with the Plugin, regardless of the Plugin’s license terms, provided that the Plugin is distributed free of charge.
Derived works of this software may keep or omit this Exception.
This means that non-commercial plugins do not need to be licensed under the GPLv3 and can be distributed in source or binary form under any license (open-source or proprietary freeware). However, plugins that copy a significant portion of non-API source code from Rack must be licensed under GPLv3.
Email contact@vcvrack.com for licensing commercial plugins.
I applaud the goals and I think this approach of GPL3+exception is a good and smart way of achieving them.
I think you’ll want a FAQ, explain-like-I’m-five explanation of the consequences of this license for plugin authors. If I’m not mistaken, here’s what I understand it could look like:
I want to write a free (as in free speech, or as in free beer) plugin for VCV Rack, what do I need to do?
You are free to copy VCV Rack’s source code, modify it, etc. under GPL3 terms. If your plugin copies Rack source code, you need to abide by the GPL3 license and license your own plugin under a license that preserves GPL3 rights and obligations, such as the GPL3 itself.
Additionally, I you use the Rack API without copying Rack code, you do not have to license your code under the GPL: this means you can license it under GPL-incompatible licenses as well. You can even distribute your plugin free of charge without distributing the source code, because GPL restrictions do not apply to your plugin. This remains true as long as you only use the Rack API, not if you embed Rack code in your software.
I want to write a commercial plugin for VCV Rack, what do I need to do?
Email contact@vcvrack.com to discuss licensing terms. Commercial plugins sold on the VCV Plugin Manager can obtain a license similar to the Non-Commercial Plugin License Exception, and can use the Rack API without having to be licensed under GPL3 themselves. Commercial plugins sold outside of the VCV Plugin Manager need to contact contact@vcvrack.com for licensing terms.
(if my FAQ is inaccurate, please correct and I’ll edit this message to remove it to avoid confusion for people scrolling through this thread).
I think you also may want to define precisely what is covered as part of the API and what isn’t. My naive interpretation is “if I don’t copy-paste VCV code, and I can build my plugin using only the SDK I’m in the clear”, but I’m not entirely sure it’s accurate.
In your first post you mention that VCV-distributed commercial plugins will get an exception in the Rack license, but that part isn’t present in your draft license. Did you mean that VCV-distributed commercial plugins will get that exception as part of a separate, commercial license?
Another aspect to consider is what will happen to commercial plugins if VCV disappears (I really hope it doesn’t) or gets acquired or suchlikes. If VCV stops existing as a company, the GPL3 license remains for the public, including the VCV Rack Non-Commercial Plugin License Exemption, so all non-commercial plugins are in the clear. Similarly, open-source contributors could fork the Rack code base and keep developing and distributing Rack under GPL3 (after rebranding it to at least remove the VCV branding, since that isn’t licensed to the public). Presumably, commercial plugin providers with a custom license will have terms to handle that. What about commercial plugin providers who distribute their plugins through the VCV Plugin Store, will they be effectively banned from distributing their plugins due to licensing terms?
When I expand the Plugin Development Tutorial into multiple pages, I’ll have a “Releasing” page where this can be described in simpler language.
Your FAQ looks correct. I’d restructure it a bit differently though.
Your “naive interpretation” is correct. Using an API involves copying named symbols into the structure of your code. Anything more makes your plugin a derived work. There’s not really a more rigorous definition.
It doesn’t need to be actually, since VCV is who’s distributing it, and I don’t need permission from myself. However, it will be explicitly stated in the license/contract I’ll give to commercial plugin developers.
This is an important point in most commercial platforms and other GPL/commercial platforms. Some companies even restrict free plugins in a way that would render them broken if the company dissolves.
That will be one of many details in the new commercial licensing terms. It’ll probably take me a whole day in the next couple weeks to write.
I think it’s a terrible idea which could easily harm the project. Here is my feedback on your points in sparse order…
- Preventing unlicensed commercial clones of VCV Rack itself
I don’t think this represented a big threat up to today as 99% of the users use the official VCV Rack distribution. If somebody is willing to fork/clone VCV Rack, the license change would leave these people the only option to contribute to unofficial Rack versions based on forks made before the license change.
- Preventing commercial modules from being sold without supporting the VCV project
I think each module, free or commercial, however it is sold/distributed supports the VCV project as it spreads the usage of the platform, engaging user and potentially bringing sales to VCV (modules or add-on products being released in the future). Do you think VST would have been the success it is today if Steinberg would have applied such restrictions?
- Applying terms to modules which negatively affect the VCV project
I don’t see how a module can negatively affect the VCV Project. But let’s say I developed a commercial module falling in that category, from what I read I would be able to release the very same “negative” module for free with no issue (using the non-commercial exception of the new license), also “negative” could be a very subjective evaluation so a list of rules (same as what Apple publishes for AppStore developers). Again with the VST parallel, there are countless badly written or malicious VST plugins out there but common sense and word-of-mouth between users make them “banned” from the community (aka don’t use it, everybody knows it sucks) without enforcing this at the license level.
- Open-sourceness of the VCV project
As you already stated in this thread, applying such changes to the license would have two immediate effects: 1) you can’t accept contributions unless the contributors gives away copyrights or accepts to contribute under the new license terms. 2) you won’t be able to use libraries which are not developed by you/VCV or which have a less permissive license. I know you think 1) is not a big deal as you can develop everything in house (I think this is very short sighted but this is for another thread) but 2) sounds really self-limiting to an unnecessary level given the crazy development going on in the larger technology community (AI, cloud-based computing, just to name a few) and release in form of libraries to be open-ly used.
I totally see how you would like to make this project to become your “job” for the next one or two decades, the problem of making a project sustainable is real and your aim is absolutely legit. There are few different “how”s to get there. From what I happened to read here on the forum it seems like you would want something like an AppStore, having control and a share of the revenues from all the plugins being run on the platform. It’s not a crazy idea (actually it’s pretty common these days) but I think VCV is pretty far from providing developers with the agreements/services/guarantees that these app-store solutions usually include. But this totally kills the community vibe these early days of VCV Rack were able to build around the project. In addition, having changes like this makes projects less appealing to middle-big sized software houses which might want to invest on a platform but can’t afford instability because they have a business to run and numbers to check at the end of the year.
Maybe be open about the project costs and your goals, or your fees and commisions for the VCV Store so we can see what motivation/consequence this change has and contribute with ideas?
I feel that some of your points are somewhat wrong to blatantly incorrect, so I’m going to be more harsh than usual with the responses. However, you raise good points and if others chime in, I’ll be able to see statistically the opinions of users and plugin developers.
That number is too high. Go to Modular Synthesis Forum - KVR Audio and tell me which VCV-related thread has more posts. Hint: it’s not the official VCV Rack distribution.
Don’t underestimate software developers. If there is low hanging fruit via a software project that is licensed too freely, they will take it and profit. I need to close that hole, and I’m humbly admitting the mistake I made in 2017 by licensing Rack as BSD. Fundamental, Audible Instruments, etc are fine. But I need to be more careful now with the flagship project, Rack.
By “in house”, I meant developing myself but also contracting and purchasing software from other developers. This is the way software is developed in 100% of software companies.
If you told Apple that you want to give them a 20-line patch for MacOS (typical of most open-source contributions), they would laugh at you. If you look at most open-source projects, you’ll see one (1) “hero” maintainer and several hundred drive-by contributers with just 20 commits. That’s not because the contributers are “bad programmers” or anything, it’s just the nature of open-contribution. It takes a lot of babysitting to maintain open-contribution, and in my experience I could be writing 10x better quality/quantity of features in the same effort as handling free contributions.
Paid contributions are another thing. There’s nothing more helpful to me than a well-motivated professional programmer. They’re expensive but completely worth it in the long run. That is, if the platform isn’t exploited due to being “too free”.
I think you’re getting confused here. If Rack used a GPL library, regardless of being licensed by GPL itself, I wouldn’t be able to release a commercial fork or allow any commercial plugins. Or maybe I’m misunderstanding your statement?
How so? Have you been through the process to release a commercial plugin on the VCV Store? And if VCV is “far from providing” this arbitrary goal of being similar to Apple’s App Store, isn’t what I’m doing right now pushing in that direction?
This paragraph doesn’t make sense whatsoever.
Maybe in the future I’ll add a streamlined “Line up! Get your commercial Rack plugin license here!” application in the future, but right now I’m perfectly fine with custom offers and fail to see how releasing this information is relevant to the discussion about Rack’s license.
Forgot to respond to this one.
VST2 is 2,000 lines of C and C++. The thousands of VST plugin developers do not rely on Steinberg to supply 30 features a month to the VST API. Rack plugin developers do.
Please elaborate what you mean by apply terms to modules which negatively affect the VCV project, what does that mean can you give some examples?
Plugin developers who purposefully steal intellectual property to make profit 1) give a bad look for VCV Rack to users, 2) devalue the work of all other plugin developers who work hard to make fantastic original modules, and 3) sever potential collaborations between VCV and those they stole IP from, e.g. Eurorack manufacturers.
Your Stellare modules have been developed with flying colors, by rightly asking permission from Tom Whitwell about Turing Machine and following Ableton’s trademark/source guidelines. The regulations are to protect developers like you whose work might be devalued the more unlicensed VCV clones people see. “Oh look, another ripped clone, this time it’s Turing Machine.” vs. “Oh wow, looks like Music Thing Modular has joined the VCV movement too, ported by the same guy who made the Link module!”
Other people might steal IP and release clones for free, perhaps because they don’t understand copyright law/ethics, but I don’t think they’re in it for “evil”. So I have no interest in regulating non-commercial plugins whatsoever.
I also think this is not a good idea. Considering this has always been a open platform where a developer could either choose to release in the VCV store or do the sale outside of the VCV store. It should be up to the developer to contribute to the VCV project or not and it should not be forced in such a way implied by this license change. Plugin developers also need to make a living and spend a huge amount of time developing modules for the VCV platform, some free, some for money but in the end we also like to see a fair return of investment so the only thing I can see happening after this change is that developers will raise the prices of the modules to make up for the commissions so this will have a negative effect on the end-user.
This license change will not prevent that choice. But in both cases, the commercial plugin developer should be responsible for paying for the intellectual property they take advantage of. VCV Rack’s mission has always been “free to use” but has never been “free to make money off of”. This decision rests solely on the question “Will the VCV Rack ecosystem and userbase be improved/stablized by relicensing?”
A 3rd party developer is also a user of the VCV Rack ecosystem and honestly I do not see how this improves anything for the 3rd party developer, it only makes their lives harder.
I completely agree that understanding the new license is more difficult than understanding the BSD license. But other than that obstacle, it should only make the life harder of a plugin developer who wishes to exploit a platform which provides the opportunity to make profit in the first place. Open-source and freeware plugins, and commercial plugins sold on the VCV Plugin Manager, will not be affected in any way.
i think you are going in the right direction with this. i support this change.
Maybe it’s too high but I still think the majority of Rack users use VCV official distribution. This is still a growing project/community so I would add that a new user is definitely more likely to land - for his/her first Rack experience - on VCV Rack than on another distribution.
Also, let me be honest on this, if there are “alternative” distributions of such a young open source project is also because of your attitude towards contributions to the repository. I’ve seen people trying to contribute with pull requests, then being disappointed, then starting their own forks.
If we are talking about this kind of deplorable - I fully agree with you here - people changing the license won’t help as long as the project stays open source. If someone’s moral is that low a new license won’t stop him/her to copy code from your repo and take advantage of it in other projects.
I think it depends case by case, sometime a two lines PR can be the fix to a critical bug (even Apple accepts those, I can guarantee, when presented with the right context info). Of course a maintainer has the burden to make sense of all the PR and keep a coherent “vibe” through all the code base. But I don’t see this as a reason not to accept well-focused contributions. Of course this is a matter of taste/approach.
with this I was referring to this…
if tomorrow Google releases a super cool ML library under GPL you won’t be able to use it in Rack (e.g. to implement a recommendation engine for the plugin browser) because of the “exceptions” you are planning to introduce. I think this is the point in which the amount of disadvantages of such a decision clearly outweighs the potential advantages (which I still fail to see, but again this is opinion-based).
I have two apps on the Apple stores, they provide developers with a sales channel (the App Store) which reaches millions of users, they take care of copy protection (I know your opinions about this but this still is a thing for a lot of people/companies involved in commercial software), they take care of tax-compliance and a loooot of legal stuff, apart from the fully fledged back-office portal with reports, app management, reviews, etc (not that it’s mandatory for VCV to have all of that).
It’s pretty understandable why VCV won’t be able to provide all of this and, if you ask me, it’s also good for the community if you don’t spend your time implementing “reviews on the VCV store” instead of spending your time on the core Rack application. To put it down short: the size of the project and the community around it doesn’t justify such an expensive approach to fix the (again, super legit) problem to make the project sustainable for you.
I will try to explain better since I think this is pretty important: your project got a fair amount of attention, from the user base but also from the industry. Bigger plugin manufacturers looked at VCV Rack and asked: “is this a competitor or one more platform we can sell plugins for?”. Success of any platform (again, I want to think all of this discussion is about the sustainability/success of your project) is having good content, nobody would buy a Kindle without the huge selection of ebooks, or an iPhone without the App Store.
Now, back to my original point if - let’s say - Arturia is thinking of releasing their DSP stuff in the format of a Rack plugin, seeing you act as the Imperator of Rack Kingdom (changing license 1 month before releasing 1.0, strong opinions on using IDEs, class vs struct, etc, etc) won’t help convincing them in going with such a project. A small developer can afford having a few hours of his/her free time being wasted because you changed your mind about insert topic here, a bigger software vendor just can’t and, one more time, this is bad for the VCV Rack project.
I don’t think Rack plugin developers expect you to provide 30 features/month. I certainly don’t. Sure the 0.x days are hard in each project but after 1.0 is out I think this should be less and less likely the case.
In general and just as a suggestion I think a better separation to what’s Rack (the app) and the SDK (so the features exposed to the plugin developers) would definitely benefit the code and, potentially, your evaluation of the topic (I mean the paragraph I just quoted up here). Rack SDK could (and maybe should) be just 2,000 lines of C and C++.
Once again, I totally see your aim but I think this re-licensing is a wrong move towards a solution which could possibly harm the project more than what it could benefit it.
I would think of asking for a yearly fee to access the SDK (even for free plugin developers) or to get a “official developer” badge or to get access to the Plugin Manager services… and few other ideas but I wouldn’t know what to suggest (in case you want to hear suggestions) without knowing the “details” of the problem, that’s why I was asking for your goals and commissions of the store.
Luckily the law will be on my side if Rack is relicensed to GPLv3.
Re contributions: I experimented with this a year ago, and truly found it taking 10x longer than just implementing features myself. That is not an exaggeration.
That raises a good question. Does GPLv3+“VCV Rack Non-Commercial Plugin License Exception” prevent third-party plugins from using GPL libraries? I actually don’t know. May need to consult lawyer.
Sorry, I’m going to stop my responses to you here to allow others to offer their opinions. The above point is the last important detail that should be resolved.