What is the VCV Library's policy for adopting a plugin?

I am trying to understand how the VCV plugin ethics code and the VCV guidelines for taking over abandoned plugins apply to each other.

The ethics state:

“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”.

Whereas the rules for taking over abandoned plugins have been stated as:

“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.”

Both seem fairly reasonable, but it isn’t obvious whether they conflict or not. If one were to take over an abandoned plugin and submit it to the library, would the submitter need to change the branding and panel design before submitting them?

1 Like

Good point. If someone made a fork of a plugin with the same name as the original, it would technically be “cloning the name of a software product”, so we won’t accept it into the VCV Library. The “rule for taking over abandoned plugins” doesn’t make sense and is now nullified. It has never been used anyway.

P.S. In the future, if you have a question or comment about a VCV policy, you can simply contact VCV Support. We don’t read all messages on this forum, and these are things that can only be answered by VCV.

2 Likes

Makes sense. This has also been established practice in the open source software world for many years. The way to rescue a faltering project is to fork it, change its name and carry on with the forked codebase. OpenOffice → LibreOffice, Hudson → Jenkins, etc. etc.

So I guess for Rack the rule then is: Change the name (on faceplates and documentation as well) and slug and submit it. Of course if the license says you can’t copy the graphics you’ll have to change that as well. Or do you extend that to “all graphics, no matter what the license says”? Because that would probably amount to: “No abandoned plugins will ever be rescued” which would be a great shame, because there seems to be a lot of abandonment going on.

1 Like

That would still seem to conflict with the ethics guidelines.

So just changing the name, logo and slug would not seem to be sufficient. The panels would need to be redesigned and the layout of components changed (in the code too)

Sounds like we need a new policy for abandoned plugins then, particularly with the current migration from v1 to v2 and the number of plugins that are looking like they may be abandoned. If this is just dealt with under the current ethics guidelines then it looks like we will lose a significant number of them as porting would involve a complete code and design overhaul. Losing these plugins is not great for users who may love them and have existing patches which use them.

Perhaps there could be an exception made in the ethics guidelines for abandoned VCV plugins, where cloning the “panel design, or layout of components (knobs, ports, switches, etc**)” is allowed as long as the license does not prohibit it. This would mean just the name, logo and slug would need to change which would make porting them take significantly less effort. Rack 2 includes hard coded plugin/module fallbacks so it would potentially be possible to have the old module slug to be swapped out for the new one, allowing old patches to be opened easily with the ported plugin.

While the ‘rule for taking over abandoned plugins’ may have never been used, clarity around this seems more important than ever right now with the change to v2. A rule is needed and consideration should be given to the differing interests of both developers and users.

@vortico I presume you are very busy with the v2 launch right now and the last thing you want to be doing is fussing over this stuff, even though now is exactly the time that clarity is needed.

Would it help if some of us got together, thought through the various scenarios, and thrashed out a clear and reasonable policy that works for everyone? We could then submit it to you for approval as the final say on this is yours of course.

3 Likes

That’s what I adressed in my next sentence: “Of course if the license says you can’t copy the graphics you’ll have to change that as well. Or do you extend that to “all graphics, no matter what the license says”?”

But yes, there’s unclarity and I very much agree with what you’ve written.

1 Like

Panel design and component layout are part of source code and graphic assets. If the plugin’s license allows redistribution of these assets, you already have permission from the owner to clone them, so you do not need to change the design or layout.

If you are not clear about VCV policies regarding your sitatuion, you can contact VCV Support to explain your scenario’s details and I’ll answer whatever questions you have.

1 Like

These aren’t good examples because OpenOffice and Hudson are trademarked names, so you cannot legally distribute a fork using the same names. @Squinky was asking about forking plugins whose names are (likely) not trademarked and submitting them to the VCV Library with the same name.

1 Like

This is contradicted by your ethics guidelines: “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”.

So - if the plugins’ license allows copying the graphics, and you change the name,slug,brand, are people allowed to clone them and submit to the library (rescuing abandoned plugins) or not?

Can you explain why you think that is a contradiction? I want to hear your thought process.

You’re omitting a lot of details here, but a changed name, slug, and brand will usually not bar a forked plugin from being accepted to the VCV Library.

If you have a specific example of what you’re trying to do, send an email to VCV Support and I’ll tell you whether we’ll accept your fork to the VCV Library, and if not, what to change to be accepted.

I don’t think it is actually. Andrew is saying that unless otherwise specified, panel design, components and layout are part of source code and graphic assets and are covered by the same license - therefore if the license gives you permission to use the code, it also gives you permission to use the panel layout, components and graphics.

This is the reason we (MindMeld) license our panel designs and graphics differently from our source code.

The perceived contradiction hinges on the word “permission” and what it means. As I recall, when you wrote the ethics guidelines you said that permission means actual communication with the developer or company, and that words like “it’s fine by me” needs to be exchanged. Maybe you only meant that for cloning hardware modules? But now you seem to be saying that if it’s not forbidden by the license then it’s permitted. I think you need to clearly state the difference between: “It’s not Ok to just clone Maths because…” and “It’s Ok to clone ABANDONED-PLUGIN because…”.

Are you saying that:

  • If a plugin seems to be abandoned,
  • And it’s license does not forbid copying its graphics,
  • And you change the brand, slug and name in the manifest,

Then it’s usually Ok to clone it and submit it to the library? Because that would be a workable policy.

Can you give a citation or URL of this quote?

At this point, if you are still unclear about the VCV Plugin Ethics Guidelines and interested in starting a fork project, you can contact me at VCV - Support and I will explain to the best of my ability what you will need to do to be accepted to the VCV Library.

Sorry, it’s simply from my recollection. If I’m wrong I’m happy to be told so.

Yes, it’s unclear, that’s why we’re talking about it.

Wouldn’t it be helpful to post the info publicly since there are a lot of people currently trying to fork and fix abandoned plugins? Or do is it easier to have 50 developers email you individually?

3 Likes

Another aspect of the lack of coherent policy of plugin adoption is the status of adopters. About two years ago I started a quest trying to migrate pre-v1 plugins to v1. I’ve selected ones that were heavily used in 0.6 and were coveted by many members of the community. I have also adopted a few of them once I got a positive approval from the original developer. In total, more than 10 plugins were migrated by me to varying degrees of adoption. Today, I was surprised to receive an email from the VCV library slug thread for a plugin that I adopted a while back, informing me that it was “taken over”. I have invested many hours enhancing the plugin (such as adding polyphony and fixing many issues), just to end up losing maintainer status for someone that modified the manifest. Adopters seem to have no recourse or defense against such takeovers. It is disappointing to a point where adopters will just abandon their work which simply seem to not be appreciated.

2 Likes

Can you send me an email with a link to your VCV Library issue thread and repo? We can get your work submitted to the VCV Library if you’d like.

You emailed me earlier from VCV support about this re 21kHz.

  1. would I be able to submit my 21kHz v2 repo to the VCV library as the new maintainer?

Yes, because it sounds like you have his permission. Just use the original VCV Library repo thread with a link to the updated git repo.

I got permission from Jake as the new maintainer. As I told netboy3 in a PM I had no way of contacting him to ask whether he was going to continue with this particular slug (it’s been 2 years) and noted to you that he had done the v1 migration - which was added to the library 2 years ago. VCV Library - 21kHz

This issue is outside the scope of this thread and belongs in 21kHz · Issue #491 · VCVRack/library · GitHub

Andrew, netboy’s repos can be found at netboy3 (Netboy3) · GitHub and I can vouch that he did the work, chased developers, asked permission and provided many of the builds much of the community use for v1.

Moreover, he was super responsive in asking for recommended plugins to port, and even making further changes once his initial ports were found to have bugs.

3 Likes

Having said that, I’m glad to see Steve Russell’s builds, I think it has seen a huge boost to the number of plugins readily available for v2.

2 Likes