Is it ok to port a third party module from V1 to V2 and post build binaries here?
Most of these plugins are GPLv3, and I’m having trouble understanding the clauses about modifying the software and redistributing it.
The verbiage is mostly around redistributing the source, but it’s super ambiguous to me.
Does this community forum have any guidance or rules around this?
(Edit: added clarifications below).
Thanks
I guess it depends on the definition of a derivative work .For many of us, although the the source code is GPLv3, the panel layout and graphics are not so building of a V1 plugin for V2 and distribution by anyone but the plugin author is probably breaching the license unless the panel and graphics are changed.
If you don’t change these files then it’s not a derivative, it’s simply a copy.
However some art and brand licensing will have clauses that you can’t display logos etc.
This of course means that either you find some way to hide the logo or name without changing the files, or replace all the artwork with original/other material.
If the code (the non-artwork part of the repository) is GPLv3 then of course you can copy it and distribute binaries. Any changes you make must be published under the same license, of course.
Ah, sorry, that was a little ambiguous. Let me be more specific.
I’m thinking of a plugin that is purely GPLv3, with no special “other” license for the graphics.
Someone who is not the original author ports the code from VCV V1 to VCV V2, and/or otherwise modifies the source code (including plugin.json).
The source is now modified and is not yet public. So section 6 kicks in (you must make the source available in one of the ways specified). And potentially section 5 kicks in, “Conveying modified source”.
Now the case I am wondering about is that the person who ported the code compiles it and puts the compiled plugins in public – let’s say a link on the community site to a Dropbox folder.
I believe that to satisfy section 6 they must make the modified source public. This could of course be done in any number of ways.
But section 5 seems unclear to me. Distributing a binary from a modified source isn’t quite the same as distributing the modified source itself. So in this case must the binary distribution contain the prominent warning that it has been modified?
Tangled up in this – if one does make the source available in a way that satisfies section 6, then what of posting the binary without a reference back to the source? Is publishing the source in a way that satisfies 6 meaningful if the recipient of the end-product has no way of knowing where the source?
Oh, and as I stated in the OP, I am looking for guidance from a forum moderator or someone who can speak on behalf of forum policies.
The plugin.json should contain a sourceUrl section pointing to it. So at least then there is a reference in the module.
Section 6d doesn’t require you to add reference to the source inside, but rather “next” to the object code on the network server that provides it. Assuming the object code unit is the *.vcvplugin, isn’t it sufficient to provide a reference link just beside the object-code download link?
I suppose, I figured sourceURL would be the easiest place without being too obscure to find.
(if you give a direct link to the files you’d never find it otherwise)
I think you mean that if it’s posted as a “release” in the github repo where the modified source lives, then it’s clear (enough) where the source lives? I can see that - I’m not making a policy, just hoping that the forum will.
I think @netboy3 and @dreamer are both implying that it probably violates section 6 if you, for example, did the port locally and didn’t push it, then posted the resulting “naked” binary?
I have gotten some replies about section 6. But I have yet to hear anyone speak to section 5 (modified source). What does section 5 mean in this case?
All the porting by kind souls I’ve seen is in public, in a forked repository. But yes, if people port from a local clone and publish the binaries, they should make the clone public which is trivial with Github forks.
Yes, I think the consensus (so far) is that porting (by kind souls or any others) should be done in a forked repo that is public, andthat any binary builds should be distributed in such a way that the source repo can be found. That should assure compliance with section 6 of GPLv3.
Despite my repeated queries (trolling?), no one has ventured an option on what section 5 means for a v2 port. Section 5 is of course the section that covers modified source.
Of course I would say the odds of anyone “getting into trouble” for very small technical violations of GPL are quite remote. But I do think that it would be a bad choice for this community forum to allow the trading of plugins that are in (minor) violation of the licenses. That’s why I am looking forward to this forum publishing their own guidelines. But I think everyone is understandably very busy right now.
Which part of section 5 do you think is problematic in your view?
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.
(btw, fwiw, my personal opinion is that you do a first rate job with your ported plugins. They are [to me] clearly labeled as modified from their originals, and of course the source url in the plugin.json points to where the source actually is)
I appreciate your candor. When I adopt a plugin I do make those changes, but for plugins that are ported and pending a PR, I typically end up clearly marking the modified source repository (and even the commit) that was used to create those in the landing section that I publicize. Though not as convenient as the sourceURL, I believe it satisfies section 6d to “maintain clear directions next to the object code saying where to find the Corresponding Source”.
Regarding section 5, I believe that the mere GitHub forking mechanism satisfies section 5a. The forked repo has the words “forked from” prominently displayed on the top left of the page, together with the identities of the owner and the modifier. The modifications are clearly listed in the commit history which details the modifier’s identity and time and day of each modification and even the modification itself which is not required.
I believe that if the GitHub forking system for public repositories itself was not satisfying the requirement of the GPL, we would have most of the public GitHub repositories up in arms once forked and modified and it’s obviously not the case, so why would it be any different with a GPL forked VCV plugin?
What you are saying sounds reasonable, and obviously forking and submitting a PR is super common, and it’s either completely legal, or at the very worst it should be.
But distributing binaries is not something that is commonly done in the GPL world, as far as I know. That why some of these cases are harder to fit with accepted GPL practice.
I think I would tend to agree with you, if what you are saying is “it’s ok for modify a plugin by forking it, and the post a binary in the “releases” section of your repo.”
But, be that as it may, I’ve mentioned a number of times that I am specifically asking about two things.
I suspect, and I suspect you do, too, that posting the naked binary on the internet without any link back to the modified github likely violates the terms of GPL. (although this may not really be the case - certainly people are doing this today on the community forum).
The other thing I have asked about several time is “Does this community forum have any guidance or rules around this?”
You may recall that VCV has rules that are sometimes more restrictive than underlying license rules themselves. I’m thinking of the rules that one can’t copy the look and feel of someone else’s module and submit it yourself the the VCV library (whereas you may well be able to do that under the original plugin license).
So, if VCV were to come up with forum rules around the distribution of plugin binaries via the VCV forum, things would be more clear. Purely speculation, but I’m going to guess that at the very least the VCV rules would require you to follow the original license.
Seriously? Ever heard of “Linux distributions”? 
Take the average Ubuntu ISO and imagine how much of that is GPL licensed (the vast majority).
Now come back to your statement and realize it doesn’t make any sense.
Linux is a small part of the GPL world.
edit: okay, that didn’t make as much sense as I thought. I mean there are a huge number of pieces of software available under the GPL, Linux is only one piece of all this and quite unusual in that it has multiple distributions.
Sure, GPL goes far beyond just Linux, but saying “distributing binaries is uncommon in GPL world” is about as far off as one can get. It’s just a typical and obvious example.
Point of the topic is not resolved and I don’t know the answer: are there forum guidelines to linking foss binaries without it being apparent where the source-code is?
No, I don’t think there are any forum guidelines around this.