I have tried out Rack2, and it’s super rad and cool. BUT…
A big part of how I compose with Rack is using the 8Face to save snapshots of modules.
Earlier in the beta process, I was able to build the v2-dev branch of Stoermelder-PackOne but the 8Face didn’t seem to work at all with Rack2. Now, it doesn’t even compile. @stoermelder’s last commit was in October.
I know that Ben’s work on this is a labor of love and he’s doing things that exploit the Rack API in ways no one else has considered. Just curious and feeling impatient.
If you’re still using V1 as a primary tool, give 8Face Mk2 a try, too. It is amazing to be able to change up sequences/quantizers/voice parameters with one click, AND to sequence them as well. It’s a new way to organize and sequence compositions!
As a temporary measure, Steve Russel has made a fork of Stoermelder that compiles and works fine in the latest betas 1 & 2 (he’s also sent Ben a Pull Request and I should add I haven’t tested 8face specifically)
I looked at that fork you mention. And I looked at the license for the original modules, which states:
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.
I think this is a modified version of the original, but it doesn’t carry any notices at all that I can see. In fact the readme seems to be unmodified and uses the word “I”.
I’m certainly no expert. Do others think that making a fork like this with no modification notes is compatible with GPLv3?
Sure. Are you saying “and therefore it’s legal to do in a public GitHub”, or “and therefore the time duration will be so short that the license doesn’t apply”?
I’m saying that there’s a difference between having a public fork on github, and having a fork to improve/fix bugs, via pull request.
In the second case, it’s not like the forkers are releasing a derivative work. They’re trying to fix/enhance a plugin, and submit pull requests.
By me checking the forked repo out and build it, I’m helping the forker (Steve Russell) test his code. No one is doing anything that would violate the terms and spirit of the license. No one is ‘conveying a work’ – they’re working on modifications to be merged via pull request into the actual official plugin.
You may be right. I interpreted publishing a public fork is “conveying” it. Of course I know that everyone has honorable intentions. I just don’t know if they are legal.
I don’t think the license is supposed to account for intention. Like if you can’t convey it for a “bad” reason you also can’t convey it for a “good” reason. Very few laws that I know of take intention into account, and then ones that do are a mess.
Again, I admit I don’t know the answer, but If you aren’t allowed to fork a repo, modify it, and make it publicly available, then you aren’t allowed to do it. Even if your reason is "I’m only going to modify it, test it, submit it back as a PR, then un-publish it.
In summary, I don’t think there is a meaningful difference between two things you mentioned. At least not meaningful to IP laws.
True, sort of. It seems what this person has done is make a public fork on github. As Bruce points out, the licenses doesn’t really care why, so in this form the licenses is likely violated.
The improve/fix bugs/pull request workflow shouldn’t require forking. Anyone can clone the original repo locally, create a branch, work on it, push the branch back to the original repo and create a pull request based on the branch. This would be allowed by the license as the 3rd party dev is not publishing their own version/fork.
so your interpretation of “prominent notice” is a github commit without a comment, leaving in place the readme that suggests the opposite? well, like I said, I don’t know for sure. So maybe?
I think a quick reader might think this implied that steverussel33 got permission from Emile Gillet to re-distribute those images, but I’m guessing that actually Andrew Belt got that permission. But it could be that the permission was “anyone, anywhere can use these graphics”, I guess.
A fork of a public repo cannot be made private for security reasons. So what you’re suggesting is impossible.
Forks of public repos for PR purposes are made all the time. Policing the enforcement of licenses is going to be a problem. Most of these “PR use only” forks are deleted once the PR is merged or rejected. This is the approach I and many others use.
The only time lawyers are going to turn up is if there’s a complaint from the original repo owner/copyright holder. How’s that going to work out?
It won’t, because all the forker has to do is get the original owner to merge the PR (if done so, there’s no case) or the owner/holder rejects the PR and tells the forker to delete the forked repo used for the PR = there’s no case.
Tech note: even if a forked repo (along with any branches, obviously) is deleted and/or the PR is rejected, the code remains part of the closed PR on the orignal repo. So it’s not like someone cannot come along look at the modded code and fork a repo themselves and add the PR code manually. You can even add closed PRs as new branches at the command line to a fork.
AFAIK they stay open for as long as the repo that the PR was posted to exists. Delete the repo, everything gets deleted along with it. Forking a repo that has PRs doesn’t copy those PRs over to the fork, for an obvious reason.
