Issues around taking over an existing module slug

Development
1

There has been a lot of talk if the community updating abandoned plugins to V2. Some questions naturally come up. One is “who owns the slug, and what are the rules for transferring it”?

For the non-devs here, the slug is an identifier you put in your plugin. VCV uses this identifier when it loads a patch. If the new slug matches the old one, the new plugin will be loaded for patches originally created with the old plugin.

Scenario 1: Dev A make some module, puts them in Library, then disappears. Dev B comes along a year later, forks the repo, updates the modules, submits to VCV Library with original slug.

Scenario 2: Dev X makes a new module, but re-uses an already existing slug. “Fundamental”, for example. They submit this new module to the library.

Scenario 3: Dev A make some module, puts them in Library, updates them from time to time, then no activity for a month. Dev B comes along, forks the repo, updates the modules, submits to VCV Library with original slug. The Dev A comes back, wants updates their original modules, submits to VCV Library with original slug.

2

The only thing I recall Andrew saying about it, was during the last upgrade from 0.x to 1.x. It was something along the lines of: “If you want to adopt the plugin, and you have contacted the original dev, and there’s no response within a couple of weeks, then fork it, upgrade it and submit it to the library as is”. That was followed by a few mutters that maybe a couple of weeks might be too short, but I think this “adoption of orphan plugins scheme” is still the idea. I think it’s reasonable, given that appearently there’s (to my surprise at least) quite a percentage of “code and disappear” plugin developers, and people really value their plugins once they find them useful. I think if you’ve not updated a plugin for a long time, and disappear without contact, it’s reasonable that someone else adopts it and submits it to the library. It’s open source after all, not like someone is stealing someone else’s code. If someone wants to put reservations in, like “no one else can call the plugin XYZ”, then they should put it in the license, and although it’s not a legal trademark I’m pretty sure Andrew would respect that and ask the new submitter to change the name.

3

Scenario 1

  • Great, as long as it doesn’t turn into scenario 3

Scenario 2

  • Sorry, that slug is already being used, pick another

Scenario 3

  • Pistols at dawn
3 Likes
4

Well-thought-out examples, @Squinky. This is an important thing to get right.

I think there’s a pretty strong case that Scenario 1 should be limited by Andrew/the library maintainers to minimal changes of the modules (necessary updates, and maybe new functionality like bypassing, expanded tooltips, etc.). IMO actually new features/rewrites/etc. should warrant a new slug. That way Scenario 3 won’t have to involve pistols.

5

I don’t disagree with that anyone is saying here, but…

Scenario 1: Yes, this is the classic. But as far as I can tell it does violate the official plugin ethics, which 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.”

Isn’t it impossible to “take over an abandoned plugin” without cloning its brand? Or at least very difficult? This most easy scenario seems to pose serious questions.

I think we agree Scenario 2 is bad. But what keeps it from happening? Does the build system check for this somehow? And how can you distinguish scenario 1 from 2? It would seem to take some “judgement”.

Lastly, scenario 3 - it may seem far fetched, but I saw discussion of it as a real life thing on this community site today. Even in @gc3 's scenario, what exactly is the process when the original author “comes back”, and finds a someone else has taken over their “stuff”? Do they then re-clone the second dev’s repo and modify that? And how exactly do they get back the “exclusive right” to use their slug? In essence, isn’t scenario 3 also like scenario 2 (two different repos wanting to use the same slug at the same time)?

6

You do raise some good points Bruce for sure.

It was essentially disagreements about this stuff that led to the big blowout some months back and Aria leaving. If you want Andrew’s take on this it might be worth digging out that thread and having a read through if you can bear it. I think he did talk about scenario 3 and iirc the jist of it was that in the rare case a situation like that arose, he would make a reasonable decision on it based on the specifics of that case - could be wrong about that though and I’m certainly not going digging through that thread again… :grimacing:

Regarding the apparent conflict between scenario 1 and the ethics guidelines you mentioned - if the fork/port is simply a minimal conversion to get the plugin working in a new rack version (as gc3 said), and the forker/porter is not trying to claim ownership or copyright of the modules (which should remain with the original developer), then it would kind of fall under some equivalent of ‘fair use’ in my book (in terms of the ethics).

7

@steve, yeah, :frowning_face:. I was in that thread as it was happening and still feel bad about it.

This issue needs careful handling. I know Aria said it wasn’t just that conversation that made her decide to leave, but I understand why this point is so personal and important for her and other devs. In addition to that misunderstanding/conflagration, I’ve seen plenty of “vCv wilL sTeAl yOuR cOdE” comments outside this forum, which indicate that the existing policy is not well understood at all.

I’m assuming that we’re dealing with open-source plugins using one of the standard open-source licenses (GPLv3, BSD 3-clause, MIT, CC0, to pick the ones mentioned in the docs). I’m also assuming that the bar here is entry into the Library (which is how the existing plugin ethics guidelines are enforced), so out-of-Library enforcement doesn’t need to be considered. That’s actually helpful, because the Library isn’t that large and it’s maintained by a small group of reasonable, well-intentioned people. (@Squinky, I think that this is the step that prevents your Scenario 2; my understanding is that Andrew and @cschol , and whoever else has access to the Library repo, maintain the slug list manually, possibly with some script assistance).

I agree that a clear policy should be spelled out ASAP. With V2’s release approaching, this is about to cross from theory to reality over and over again. Below is an attempt at drafting one.

Andrew’s on record as saying that he’ll respect explicit language in the repo saying “don’t upgrade my plugins without my permission” (even if the language is outside the official license) so I think that case is clear; if a dev wants to be the only one who’s allowed to upgrade their plugin(s), they should say so. That seems fine to me.

So, for me the question is: what would a dev who was on an extended vacation during an API change, and whose plugins were upgraded, want to come back to? I think the sensible default is a minimal upgrade that they can regain control over at will. For that to work, I think Andrew and the library maintainers should create an explicit process for, essentially, fostering a plugin. It could work something like this:

  • If:
    • a version upgrade is taking place which requires that an open-source module’s source code be changed to be compatible, AND
    • that module’s developer is unreachable, meaning they have not responded to X attempts to contact them over Y time period, AND
    • that module’s developer has not opted out of this policy with a note in the module’s repository, THEN:
  • With VCV’s approval, a volunteer developer will be allowed to fork and make source-code changes to the module before resubmitting it to the library under the same slug, AS LONG AS:
    • The source code changes consist only of:
      • Minimal changes necessary to allow the plugin to run in the new version of Rack;
      • (possibly) Simple implementations of new optional features (such as bypassing and tooltips for V2), as long as those implementations are of high quality and do not involve significant new design decisions; AND
    • Text is added to the forked repo indicating that the source code changes have been made in compliance with VCV’s “abandoned plugin” process and briefly describing the process.
  • The original developer, if they reappear, is free to either:
    • Adopt the changes and resume control of the project; OR
    • Reject the changes and perform the upgrade themselves; OR
    • Elect to remove the plugin from the new version’s library unless or until they perform the upgrade themselves (as if they had included “do-not-adopt” language in the first place).
  • This process will provide an extremely limited exception to VCV’s “no-clones-without-permission” policy, as the fork will, from an ethical standpoint, be considered a community-based upgrade, not a clone.

A key point here is that without the original dev’s permission, those modules are only going to be given the minimum amount of attention necessary to make them run in (and maybe interoperate with) a new Rack version. Under the proposed policy, if a volunteer developer wants to take a project forward, they will need to do it in the normal open-source way, giving it a new name and identity (per the no-clone policy), crediting the original code, and asking for a new slug.

I’m sure there’s no way around this :slight_smile: Again, from my perspective, the Library maintainers are the people who matter here. They’re the ones whose judgment is enforcing the existing no-clone rule. That’s also a judgment call, probably a more complicated one than what we’re contemplating here, and in my opinion it’s worked out quite well. The Library is full of official versions of hardware modules, many of them free; there are plenty of inspired-by modules which definitely aren’t clones; and, as far as I know, there aren’t any hardware companies who are currently angry at Rack. Even out-of-Library enforcement has worked; I think Andrew noted somewhere that Floats (as updated) would be allowed into the Library if its developer wanted that.

3 Likes
8

Above discussion possibly made irrelevant by this; it looks as though taking over abandoned plugins is no longer on the books as a policy.

2 Likes