Live data from Hacker News

GitRoyalty – First OSS Paywall

gitroyalty.com

21–30 of 52 posts

Re: GitRoyalty – First OSS Paywall

#21
post #15
post #13

Isn't this going to get banned by npm like those ads did?

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?

Re: GitRoyalty – First OSS Paywall

#22
I very much sympathize with the goals here (I'm deeply concerned about open source sustainability), but this doesn't strike me as a good solution. Not a single company I have worked for would allow a dependency like this in their repo (and I wouldn't blame them). Not only is it legally gray, but somebody has to maintain that subscription. We do buy licenses but only for big/important stuff. Something like this could work for a project of sufficient magnitude, but I don't think it will for smaller stuff.

Re: GitRoyalty – First OSS Paywall

#23
Not sure hiding/removing the project build or manifest is the best approach. Documentation seems like it’d be a better target. Use the software free full OSS but non-simple or extensive documentation for a subscription fee. It seems a number of OSS devs make money by writing books, and it could incentivize good documentation as well. There’s been many times I’d not want to pay for a license but would’ve begged for in depth documentation.

Re: GitRoyalty – First OSS Paywall

#24
post #15

Earlier quoted context omitted.

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).

Re: GitRoyalty – First OSS Paywall

#25
post #19

If it's truly OSS what's there to prevent someone from simply forking it to make a version where the manifest file is distributed freely (in both senses of the word)?

What is the incentive for someone to pay to access the manifest file and then maintain a free fork that includes it?

Re: GitRoyalty – First OSS Paywall

#26

I very much sympathize with the goals here (I'm deeply concerned about open source sustainability), but this doesn't strike me as a good solution. Not a single company I have worked for would allow a dependency like this in their repo (and I wouldn't blame them). Not only is it legally gray, but somebody has to maintain that subscription. We do buy licenses but only for big/important stuff. Something like this could…

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).

Re: GitRoyalty – First OSS Paywall

#27
post #8

I had to check that today is not April 1st. If you badly want my money, sell me your product honestly, under a commercial license, and don't call it OSS. There are other "source available" licenses. If you want a donation from me, show your tipping jar / patreon / whatever else link. If you want your software be OSS, well, don't conceal the source. I suppose that a project of any significance that would use such a "p…

Charging money for OSS is perfectly kosher under FOSS definition.

Re: GitRoyalty – First OSS Paywall

#28

Not sure hiding/removing the project build or manifest is the best approach. Documentation seems like it’d be a better target. Use the software free full OSS but non-simple or extensive documentation for a subscription fee. It seems a number of OSS devs make money by writing books, and it could incentivize good documentation as well. There’s been many times I’d not want to pay for a license but would’ve begged for in…

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.

Re: GitRoyalty – First OSS Paywall

#29
Ok, I'm pretty fond with this, and it looks like a great model.

Some things that bugs me:

* I wouldn't term it as an 'OSS paywall'. I would rather term it as an 'package paywall', or 'repo paywall', or something else.

* I would prefer not using GitHub accounts, and rather have an own GitRoyalty account. I would like to have multiple login methods (like GitHub, GitLab, Google, Facebook, GitRoyalty account).

* I think the process of using GitRoyalty package as dependencies are too complex, I'm not sure if anyone would like an experience of searching (a git-committed) package-lock.json, changing all of the GitRoyalty package links, installing the packages, and removing the license keys when committing an updated package-lock.json. There should be a more straightforward way (preferably without any file changes, e.g. using environment variables) to install dependencies.

Also, I'm pretty impressed with the beautifully done website. May I ask what the site/docs are made of?

Re: GitRoyalty – First OSS Paywall

#30

Not sure hiding/removing the project build or manifest is the best approach. Documentation seems like it’d be a better target. Use the software free full OSS but non-simple or extensive documentation for a subscription fee. It seems a number of OSS devs make money by writing books, and it could incentivize good documentation as well. There’s been many times I’d not want to pay for a license but would’ve begged for in…

I love this idea.
Post reply on HN