Do open-source plugins need to be submitted to the VCV Library by its original developers?

Development
#1

Hello people,

I 've come across some modules that regardless of their libre source code and 1.x porting status, they are not available to VCV. E.g. Southpole which was ported to 1.x but not from the original developer:

https://github.com/gbrandt1/southpole-vcvrack is the original branch and https://github.com/dogonthehorizon/southpole-vcvrack/tree/v1 is the ported fork.

My question is:

  • For a module to be in the library is it mandatory for the original developer to continue being the module’s active owner ?

And if somebody ports the module to 1.x is there an active need (e.g. maybe copyright issues) for the original developer to take action on a pull request for the module to appear in the library?

1 Like
Aria Salvatrice Modules: Psychopump & Future of the collection
#2

There seems to be an expectation that a fork will either have the blessing of the original author, or be rebranded by the submitter. (Cf. Palette, ethics policy)

#3

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.

2 Likes
#4

Thanks a lot to Aria and Andrew for your responses,

A bit more clarification: Does a port to 1.x count as an improvement worthy of adoption?

Will the new developer have to redo the graphics? I mean if the previous developer’s trademarks remain in place no graphics changes are needed right?

#5

This answer brings multiple questions about hypotheticals to mind:

  • If a plugin has no serious bugs like crashes, is the inactivity policy enforced as strictly as if the plugin were broken?
  • If a plugin no longer works with current versions of VCV, does fixing it constitute an improvement sufficient for takeover?
  • In the case of a plugin such as mine, that is named after the author, would you allow takeover of the name and slug for inactivity?
  • Would the author be allowed to expand upon the collection (create new modules, take it into a different creative direction than intended by the original author), or be only allowed to take on a maintenance role?
  • Should the original author resurface, can they claim back their plugin and slug?

Personally, I regard my more esoteric modules as being part of work as an artist, not as utilitarian tools whose authorship can change without denaturing them.
And my personal life certainly hasn’t been so kind to me so far that I can exclude being AWOL for over a month and unable to make time for hobby software communities.
It’s concerning there’s any chance I could come back from a personal hardship to see myself disowned of my artistic work. But it’d be cool if they could be kept working if I were hit by a bus.
I welcome people to fork my code to do anything they want with it, but I do not want them to do it under my name.

2 Likes
#6

Sure, it’s a “significant improvement”.

You probably mean copyright. Most open-source modules don’t use a registered trademark.

That depends on the licenses of the graphics and/or whether you have permission to derive or distribute the graphics.

#7

The policy just mentions “significant improvements”. If the original developer is inactive and the fork is significantly improved from the original project by fixing serious bugs or adding lots of features, then it can replace the original version in the VCV Library.

Sure.

Possibly, depending on the specific case.

If their “new original” significant improvements are more significant than the fork, and it doesn’t break patches much, it can replace the fork on the VCV Library.

Same answer as above.

Then I would recommend a non-open-source license such as freeware or commercial. One of the Four Essential Freedoms of free software is the “freedom to distribute copies of your modified versions to others”.

Make sure you state this in your plugin’s license text. In the US there is no IP protection of your name unless you file a trademark. But VCV doesn’t only follows IP laws, it also follows morals and the non-legal wishes of software creators.

#8

I did not release this work as free software out of a lack of education about what the licenses I use actually say. People are free to do whatever they want with my code. My signature logo is copyrighted, my docs say so unambiguously, and that logo is added to the faceplates at runtime as a separate SVG, specifically to make it easy for people to remove or alter it if they fork my stuff.

What’s concerning is that the VCV project could allow for its library, the de facto arbiter of what is the “canon” fork of a plugin, to release under my own name a fork that is not canonical to what I created. That people are allowed to distribute forks of my code in the library under their own name is not a concern. And changing the slug of an existing JSON patch save is trivially automatable, so migration to a fork isn’t a pain point for users. Didn’t the VCV website used to automate the task for the old paid version of Audible Instruments?

A huge amount of plugins are named after their author. Whether a nickname or a real name, it’s not something anyone should be able to simply take over. Almost none of us have adversarial clause in our documentation saying “Software libraries are only allowed to release my canonical fork under my own name, other forks should change the name”: most of us assumed it went without saying.

#9

Then a fork cannot use your signature logo without your permission.

As I said above, make sure you state this in your plugin’s license text, and VCV will respect the wishes of you, the creator of the software. Something like the following statement: “As a non-binding recommendation, I request that all forks of this software do not include the name Aria Salvatrice.”

#10

It’s unreasonable to expect authors to have to state explicitly that the name they go by as shouldn’t be taken over.

In a context where ethics guidelines say that “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.” (emphasis mine), it’s simply incomprehensible that a protection gladly afforded to corporations would not extend to the very names we go by as humans, whether they are legal names or nicknames.

It’s also a long-standing cultural expectation of open-source and free software that forks either change the name, or obtain the authorization of the original author to continue under the same name, even if the fork is adversarial, as it prevents user confusion.

Does it look good for the VCV project, and encouraging to potential developers, if every single plugin’s README has language that roughly says “Aria Salvatrice is my name as a person: the VCV project, and software libraries compatible with the VCV API, should only distribute my own canonical fork under the name Aria Salvatrice. Should I become inactive, maintained forks of my code should not be released in a way that impersonates me.” ?

Because you bet it goes on mine right now.

#11

You’re explaining a pretty hypothetical/exotic/rare scenario that I’ve not yet needed to handle, so I haven’t given it enough thought to make a general policy about it. Policies are for “mass-producing” case-by-case decisions. It’s pointless to make a policy if specific cases have never happened!

I feel confident that given a specific situation, I would make the most reasonable decision for the situation. But the situation is unlikely so I likely won’t need to make a decision at all, because all of the below have to occur in order for the decision to arise.

  1. An original developer uses their personal name as their plugin name.
  2. The original developer becomes inactive.
  3. Another developers finds it interesting enough to fork and make significant improvements.
  4. They decide to use the same name as the original plugin.
  5. They ask me (on the VCV Library thread) to replace the original plugin with their fork.

That’s a lot of requirements for your hypothetical situation to occur! What I’m telling you is that I don’t know what I will decide in a future specific situation, so if you feel strongly about it, don’t rely on my “hypothetical policies” that don’t exist, just cover your own bases. I helped you write a statement to add to your license, so take it or leave it.

3 Likes
Aria Salvatrice Modules: Psychopump & Future of the collection
#12

Of course one would have such an abject reaction to the idea one could be impersonated, have software released in their own name, then have the matter treated in such a legalistic fashion, as if it were a generic resource identifier that’s more convenient not to change.

I have added language to my docs leaving no ambiguity whatsoever that I ask for my own name to be treated the same way as that of a company.

4 Likes
#13

You should definitely be fine now. I see that you chose to write your own license statements instead of using my one-sentence statement suggest which would have been enough. But either way, there is now no chance that VCV will accept someone’s fork named “Aria Salvatrice” to replace your plugin in the VCV Library in the event that you become an inactive developer.

By the way, when I said “take it or leave it”, I was referring to my license statement suggestion, not anything else. Apologies if there was any confusion over what that was referring to.

If you’re curious why I’m not adopting a general policy that bans all forks that use the original plugin’s name from being accepted to the VCV Library and replacing the original plugin, imagine the following very likely scenario.

According to Rack development blog, there will be a >=6 week period where plugin developers have access to Rack v2’s source and development builds but before Rack v2.0 is released. In this period, I predict most developers will do what is needed to make their plugin work in Rack v2. But there still might be a dozen or so who can’t be reached, so VCV or volunteers may update their plugins for them. (This is usually as trivial as updating their plugin’s version from v1.2.3 to v2.migrate1.2.3.) In this case, it’s perfectly reasonable to make this change, because the developer would likely not want their plugin to be unavailable in Rack v2 simply because they were busy or on vacation for 6 weeks. And yes, some of the plugins we migrate contain the author’s name or pieces of the name, such as ChowDSP, JW-Modules, Grande, KautenjaDSP Potato Chips, DHE Modules, ML Modules, and a few more, but if they are inactive and a volunteer adopts those plugins, I will likely accept them as is.

13 Likes