You're absolutely right this should not be a clause in our ToS. I've just removed it and notified all repository owners of the change.
There was a misunderstanding of what 'Content' entailed on my part–it was meant to encompass anything without a license already attached in order to grant us rights to distribute unlicensed software. Our ToS should have been more specific, I apologize.
We measure contributions using a project's git history (i.e. # of commits) every time a release is published. I realize this is terrible and it's my #1 priority to improve this after we get some engineers on board. I'm currently talking to the owner of SourceCred to see how we can use their protocol: https://sourcecred.io/
This is a tough problem and something we're actively working on improving. I'm currently talking to the owner of SourceCred to see how we can use their protocol: https://sourcecred.io/
Very interesting thought–I'd love to see how this dynamic actually plays out. I personally would welcome more contributors v.s. doing their work myself.
I think if a project maintainer were to act maliciously in terms of earnings share, developers would call them out and less people would contribute as a result.
This is definitely on the roadmap and eventually we'll expand outside of GitHub and allow repos from other hosts like GitLab.
> ... changing all of the GitRoyalty package links, installing the packages...
You should always commit your GitRoyalty license keys and share it with your teammates. This way you never have to deal with your package.json/lock files directly, just `npm install` and you're good to go! (This takes care of updating for you as well)
> I'm pretty impressed with the beautifully done website.
Thank you! I just used bootstrap and made the docs myself.
Great idea and you can do this with GitRoyalty! You can hide any files you want behind the subscription–it doesn't have to be the manifest or build script. So in your case you can hide a docs.md file.
Like any file that you would hide with GitRoyalty, you could always share the full repo once you have access to it (probably illegally)
I believe documentation would become outdated sooner than build scripts with new releases, and would require effort to maintain (more than build scripts), which would better justify to pay.
Anyway, the idea of GitRoyalty seems not to make technically impossible to share the payed content, but rather to propose a way for honest people to remunerate honest developers and library maintainers.
I think companies will hop on board if it means saving engineering hours. OSS has monetary value to these businesses, enough to make a small subscription to support the tremendous development efforts behind it. In most projects, OSS makes up the majority of the codebase, so it is "big/important" IMO.
As for the legal aspect, permissive licensing like MIT/Apache 2.0 allows developers and consumers to distribute and use code pretty freely, which is what makes OSS so great and why GitRoyalty doesn't impose any other licensing.
One of the driving factors behind making GitRoyalty was the corporate mentality I've experienced where management will pay for whatever is necessary, but think twice before sponsoring anything (especially transitive projects).
GitRoyalty just hosts a git remote repository that you pay to get access to. NPM and almost all other package managers support installing from git URLs, and too many people rely on this functionality for it to ever be removed.
How do you stop someone from forking the project on GitHub, adding in a manifest, and then pushing to a package repository like npm?
Is there a risk of popular projects that are distributed through GitRoyalty having unofficial versions with malicious code on the package repositories, similar to now typo-squatting works?
There are a few reasons to not rely on unofficial forks. The chance of malicious code is one. Also: unwanted changes, missing updates, maintenance confusion...
These issues already exist in the world of open source, as you note, and the only way that I know of to stop it would be to have a more restrictive license (and to pursue any violations).
Oh, fair enough then. It seemed to line up with less than $8 total payout, which itself I don't quite get because the minimum payout is $20..??
I took it as the equivalent of looking at a list of "Patreon" projects and the total contributions they make, rather than a storefront with sticker prices.
The problem with non-permissive licensing is that a lot of employment contracts strictly forbid them. That and commercially licensed OSS projects have no way to distribute funds to arbitrary contributors in a legally straightforward way.
And I personally have not had any success with donations, whereas 2 days after setting up my project with GitRoyalty me and my contributors are making $10/month.
This is indeed an interesting problem! It looks like a way to sell a commercial license in effect, without selling it in any legal terms.
I wonder how funds acquired via GitRoyalty get distributed, from the legal standpoint, and what makes such distribution different from distributing a share from a sale of a commercial license.
What is the difference between your open source repository and this one. I am assuming that the model is having 2 repos one open source and the other with gitroyalty with something extra (edit I see it uses sub modules)
We whitelist common dynamic IPs, for example CI, CD, and deployment IP address ranges including:
* AWS
* Heroku
* GitHub
* Circle CI
(this whitelist is a WIP and I'm open to adding more)
Also since the goal of rate limiting by IP is to limit # of users, not necessarily # of machines, we allow you to remove any previously used IP addresses from your subscription's history. This way if you hit your limit, just go to the payment page, hit 'Manage IPs' and remove any unused IPs.
There was a misunderstanding of what 'Content' entailed on my part–it was meant to encompass anything without a license already attached in order to grant us rights to distribute unlicensed software. Our ToS should have been more specific, I apologize.