When you first get involved with open source software some of the licensing issues can seem a bit abstract. But it can really pay to get this right as soon as you can. By the time some of this matters it can be too late to do anything about it.
These issues get even more complex if you are making VCV modules, for a couple of reasons. One is that you are going to be making modules that will probably “compete” directly with other VCV modules, and this may affect your thinking about who you want to use your “stuff”. Also, most VCV modules are distributed through VCV’s Library. This introduces some extra complexity and considerations.
License, copyright, and trademark are complex issues. I am not a lawyer, nor an expert in this topic by any means. Hopefully this article will inspire some developers to think more about these issues. But please to not take anything in this article as expert advice.
Often it can be a good exercise to think through different scenarios, and whether you want to allow or forbid them.
- Do you want people to use you code to make other VCV modules?
- Do you want someone to make a module that looks exactly like yours?
- Do you want someone to take your free code and make a paid product from it?
- Are you using any third party code that requires your to license your code in a certain way?
- If you decide you want to stop making VCV modules, do you want someone else to update your module and submit them back to the VCV library?
- Do you want to allow other developers to use your instruction manuals?
With all open source projects, you have to think of many of these issues. VCV adds their own “rules of ethics”, and their own conventions for doing business. It’s probably easiest to think of these issues separately.
- The default license terms are that everything in your repo belongs to you, and no-one has any right to re-use it. However you can always state that anyway.
- Most licenses grant some rights to re-use.
- It is common to license code under one set of terms, and graphics under another.
- It is almost impossible to make your license more restrictive once you have published something under permissive terms.
- There are quite a few libraries that require you to have a license as permissive as theirs. Libsndfile is a classic example.
- Code licenses are completely separate from trademarks and copyright.
- They do have a code of ethics that says even if something may be permitted legally, there is a certain code of conduct you must follow or they will not distribute your modules in the library.
- They have indicated that if you say in your license, “please don’t do this”, that they would not let someone do that.
- In the past there were special rules for taking over "abandoned" plugins. These have since been revoked.
Above, 1) asks “do you want people to be able to use your code to make their modules”. Most people use a permissive license that does allow this. And they in turn use other people’s code in their modules, subject to the license. So it is normal to have a license that lets people use your code for any free products, including modules.
If you don’t want to allow that, you don’t have to. But it may limit what third party code you are allowed to use.
Question 2) is more about the look of your module. Often developers don’t want a third party to copy the look of their modules. So it is common to have a different license for your graphics and panels than for your source code, or to assert a copyright over this visual design. On this other hand, a restrictive license for the graphics may make it impossible to have your modules included in a host like Cardinal.
A good example is VCV Rack itself. Note that there is a copyright claimed on the visual design, and it is not permitted for anyone else to build on the design of the core modules. The same is true of the Fundamental modules.
It is difficult to imagine a scenario where you want to grant the right for anyone to re-use your panel designs, and possibly your control designs too. If this is the case, make sure you license does not inadvertently give someone that right. Although if you would like to allow this in the case that you abandon the plugins, you should consider spelling that out in your license.
Regarding 3), again, many developers don’t want someone to take their code and put it in a commercial product. Yet, this happens all the time, and most licenses allow it. Make sure you license addresses this issue in the way you desire.
Most of the written “rules” are here: https://vcvrack.com/manual/PluginLicensing. The ethics guidelines say this:
You may not clone the brand name, model name, logo, panel design, or layout of components (knobs, ports, switches, etc) of an existing hardware or software product without permission from its owner, regardless of whether these are covered under trademark/copyright law.
It is recommended to follow these guidelines for all plugins, but you are not legally obligated to do so. However, it is a requirement for: distributing your plugin on the VCV Library.
In the past, on the issue of “taking over” inactive plugins, Andrew has said:
If the original developer hasn’t responded to questions/comments in a month, I’ll consider the developer inactive. Once inactive, another developer who has made significant improvements to the plugin can adopt the project and request build updates on its VCV Library thread with the same slug/name. Of course, all IP licenses have to be followed.
Since this rule conflicted with the main plugin ethics rule, and has never been used, it has been revoked. So, if a developer wants to take over an abandoned plugin, fork it, and re-release it to the library as is, they must either get explicit approval for that, or run afoul of the plugin ethics rule against copying a plugin.
If you want to ensure that someone is, in fact, able to do this in case of your untimely "demise" (or retirement), it would be cleanest to state this in your license up-front. If, one way or another, you do not grant someone the rights to copy the look of your plugin, they will not be allowed to distribute it via the VCV library.
It’s difficult to tell what these policies mean in reality, but it does suggest that if you care about these issues you should speak to them in your license.
For example, you can put in your license “These panels all say Acme Widget Co. While not a registered trademark, I am not giving anyone a license to re-use it, and do not want others to submit modules to the library labeled Acme Widget Co. In addition, the brand field in my plugin.json is Acme Widget Co. I do not want anyone to use that. And I also consider my module slug acmewidgetco-slug is a part of my brand, and do not wish for anyone to use that slug in their modules.
On the other hand, you can encourage someone to adopt your plugins in case you abandon them. Do it by granting some explicit rights in your own license file.
It’s difficult to determine what VCV might do by default when presented with these scenarios, but I take them at their word that they will honor requests when possible.
Until you need to change it, or want to change it, you might consider keeping all rights to yourself, and not giving away any in a license.
It’s better to be explicit about what permissions you are giving people than to leave things up to chance or interpretation.
If you don’t want someone to make a knock-off of your module, make sure that your license doesn’t give someone that right. If you do want to allow that, make sure your license allows it.
Think carefully about what you want people to do with your source code, graphics, and text. Then make sure your license is appropriate.
It is strongly in your interest to think through these issues as early as possible.
Licensing is complex. Consider seeking out more knowledge from other developers or from the Internet.