PayDev: FOSS Monitization or new supply chain attack?

Discussions
#1

Received a spam email, personal information is redacted:

Hello Aravinth,
as the maintainer of the OSS project ‘@mcaptcha/vanilla-glue’, I hope you can help me. I have developed a system to monetize OSS libraries called PayDevs and I’m now starting a private beta. I wanted to ask if you could give some feedback on the idea and maybe test it with one of your JavaScript packages (either ‘@mcaptcha/vanilla-glue’ or another one).

PayDevs offers a closed registry for JavaScript packages, that can only be accessed after paying for an account - maintainers do not have to pay anything for the service. The idea is that the package will no longer be available on NPM - or only if maintainers dual- or delay-publish their package. Users would then have to pay for the convenience of accessing the built / compiled package. The collected money is then pooled and distributed monthly based on the number of users a library has.

If you’re intrigued you can find a short description of next steps at [redacted]

Best regards,

#2

My response:

I’m all for monetizing FOSS work but

The idea is that the package will no longer be available on NPM

This sounds like a supply chain attack to me(see colorsjs0). What you are proposing will require devs to yank packages off NPM and republish on the PayDevs registry, which will break builds globally.

A less damaging option(and maybe more attractive one too), would be encouraging devs to publish only AGPL/GPL packages on the public NPM registry and selling more permissive licenses using your implementation.

Regards,
Aravinth Manivannan

#3

Received a response, not sure how I feel about it:

Hi Aravinth,
its not a supply chain attack - the old version of the packages on NPM
would still exist on npmjs.com. However the new versions would either be
exclusive on PayDevs or delay-published after several weeks/month. Manual
or automated builds would not be affected - they would only not get new
features or bugfixes.

A dual-licensing approach would also be possible but even more problematic
as companies would suddenly pull GPL code from the public NPM and “infect”
code. Not everyone watches the licenses with each version update.

Cheers,

#4

This is an ancient business model (https://www.ghostscript.com/ did that in the 80’ IIRC): delaying releases and selling access to them earlier. It did not work out significantly although there has been a few examples that persisted in implementing that strategy.

A platform designed to facilitate the implementation of this particular business model is a novel idea. But I’d be extremely surprised if it gets traction.

I think this should be a good fit for discussion on https://coding.social/

P.S. I took the liberty to redact the URL to this service assuming you would be inclined to not help it with referencing. Feel free to revert the change if you feel I overstepped.

1 Like