but wait it’s me - so first a brag. Although I don’t make modules/plugins any longer, my full collection was in the V2 library from day one. Thanks mostly to the hard work of @robert.kock , but slightly to my being a tinny bit proactive on this.
For developers who are still around, and would like to do this as smoothly as possible, what is the best thing to do, other than the obvious (give someone permission to port them, let the library know)?
In particular, the GPLv3 most of us use prohibits others from modifying plugins and redistributing them unless they are clearly marked, etc. But of course this is exactly what I want done.
Is a best practice for me to add some words to my license explicitly giving someone the right do to this?
Conversely, what should people do who are porting plugins (even if just bumping up the revision) and then wish to redistribute these ports? For example if save seen some people augment the info/author to make it clear these are modified (at least it’s clear to me!).
Sorry what? GPLv3 doesn’t prohibit anyone from modifying plugins and redistributing them. As long as they inherit the License this is absolutely fine. Heck one could even sell the resulting derivative. GPLv3 does not prohibit this in any way.
The only thing you could do is add different licensing restrictions to trademarks, artwork etc. so that people are forced to rename/rebrand. But purely on the code (which is what the GPL covers) this is not the case.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".```
That could be legal. When you say “say your forked it” do you you mean put a notice in a readme that it was forked any modified?
That whole clause 5 doesn’t really say anything about conveying a complied executable that doesn’t prominently say it was modified from something else, but that is how I interpret it.
Making a flat copy of a project, changing some code, archiving, then distributing that archive without any notice in the archive; I think, yes, does not fulfill clause 5a.
But I’m fairly sure VCS logs essentially count as “marking” these days, so it’s not an onerous thing, instead rather kinda hard not to do, so the example I give above that creates a situation that doesn’t meet the clause is kind of tortured. Anyway, it is a way to brag that you’ve contributed/participated
Tbf though, there’s probably FSF and SFC FAQs that cover such details, I’d recommend check with such sources first or make direct contact those organisations if you want a better understanding.
Ah, so you are saying the GitHub history is enough? Makes sense. But shouldn’t you change the link in the plugin ui to point to the new, legal, modified repo, rather than leave it pointing back to the original repo?
Afaiu, yes, though if the bare “there has been a change made” minimum ‘marking’ is done, not updating the source location URL in the software (or README) is something on another level. The minimum requirement of providing a copy of the modified source when requested is something that is already complete (trivial these days given code hosting services).
But if you don’t update the url in the plugin, and then post the plugin binary, how could anyone who downloaded it possibly know that it’s modified? I would think leaving the url pointing to the wrong source is a kind of “un-best” practice. How would anyone find you to request the source in this case?
Section 6d only requires you to “offer access” to the source code. Nowhere it is stated that you need to assist in finding it. As long as the modified source repo is not deleted, 6d should be satisfied. Maybe it’s not “nice” or “best-practice”, but it seems to still align with the GPL requirements.
Maybe, but a) I’m kind of wondering what the best practice is, rather than just the minimally legal. But even there b) It you put a “fake” url in your plugin that points to a repo other than your own, how could that possibly count as making it available? It would be almost impossible for anyone to do that. Not that anyone is going to sue anyone over VCV modules, but I can’t see that defense holding up in court, because it’s silly.
I’m “offering access”. I buried a paper copy of the source code in Greenland. You may go there and dig it up and read it.
I think you are saying that at the very least if someone modifies a plugin and redistribute it, that the modified version should be in github somewhere?
I’m not sure I understand the thread title clearly. I don’t see a real issue for adopting plugins. Once a plugin is adopted, the adopter is given an explicit authorization in writing (with me it’s preferably a written communiqué on a GitHub issue thread so it’s public and available for all - I’m not a proponent of “I’ve sent him an email and got approved”). Once this is done;
The forked, modified repo of the adopter must become the authoritative repo
The plugin xxxUrl metadata must be re-pointed to the new repo (at a minimum plugin/manual/source)
The “author” tag should be post-fixed with the adopter identity (per Andrew’s recommendation)
The plugin readme may be modified providing historical and current ownership and giving credit where it’s needed. I believe it’s fair to recognize anyone who contributed and it may be of interest to the end users.
Based on the plugin license terms, the adopter may want to add herself as a contributor
I agree with your list of best practices for adopted plugins. btw, I think I put my “public permission” in the readme on my github - maybe that’s easier to find that an issue? Or do you mean an issue on the adopter’s github?
Anyway, thanks.
As to the the issue I hijacked to - I’ll come back to best practices for distributing ports later. I’m pretty sure it’s not “modify the code on your computer, post a zip file on google drive”.
