Recently on the r/dotnet Reddit community, a new post has been published with an alarming title: Does Moq in it's latest version extract and send m...
For further actions, you may consider blocking this person and/or reporting abuse
It raises some important questions:
It reminds me of a saying I once heard, "If you don't have to pay for the product, you are the product."
Either way, it sounds like the maintainer won't have to spend their free time working on an unpaid project. ¯_(ツ)_/¯
The thing is, if you start your own open-source project with extremely permissible license you don't expect people to pay or donate for it to make you a lving, do you? You always have the choice to offer additional services (e-mail/phone support, consultations, etc.) or make a paid version of a product with extra corporate-focused features.
I'm not trying to defend people that built multi-billion dollar businesses on top of OSS libraries and products. Just understand that people will not do what they don't have to or should do, unless you make them in the most polite way.
This reminds me of IdentityServer who also made OpenSource code on GitHub but slowly moved towards a different business model, without harming the community nor the trust it has from it
It's sad that it came to this. I don't think the intention was to cause harm or steal sensitive information, but I do believe actions speak louder than words.
What I find problematic is that the PR in question was merged without a single reviewer. How can a library so foundational in millions of repos be held with such little accountability?
What can we do, as a community, to avoid repeating this problem? I don't think the answer is to never trust open source again...
Well, the harm has been done. This all has been done wiith hot needle. I've no idea what was the impulse but it was irresponsiible to change OSS project to data-collecting machine. Moreover it broke MacOS and Linux builds so it was not even properly tested. That raises even more questions about what actually happened that lead to his decision?
Neither do I but sadly the way the
@kzuforced his way into this might not have been the best solutionI get the impression that the general feeling of the community is that it didn't even had the opportunity to opt-out by design, let alone a word on the embedding of SponsorLink into Moq
Sure, there is a deeper problem that needs to be addressed and it's not new at all, but, with this update, I don't know if the community will still be supportive
I personally think that the targeted audience should have been different: SponsorLink seems to target individuals while companies are the ones holding money (look at AG Grid for example)
How exactly is the community supportive ?
What I see is a library used by millions, including corporations, who all saved a lot of time and effort by using someone else's code in their own product, commercial or not.
What I see is those same millions complaining to the sole maintainer of the library, who gracefully provided his many hours of work to them free of charge, that he made a move (maybe not a perfect move) to try and get some financial reward out of his hard work.
What I see is millions of downloaders whose only actions towards the author are to ask for more features and expect bug fixes, but never ever consider paying back for it, in one way or another.
What I sadly only see is users of OSS software complaining that the maintainer is not doing what they want, or is introducing security risks in their software supply chain, or have an inappropriate governance for their project which puts theirs at risk.
Which talented and idealistic developer would still want to contribute a piece of software to the world knowing that, if succesful, the road ahead will look like this sacerdotal hell ?
Those unhappy with Moq can walk away, find a replacement, or better, fork it and fix it themselves, or pay for it, ot help the maintainer, but they should not complain over something that they have used for free for many years.
There's an issue in the Moq repository explaining that SponsorLink is now OSS too, and that 'Future versions of the package will come from there, will no longer be ofuscated, and will also have an OSS license.'
It seems you missed the actual concern. Making SponsorLink OSS is one small issue, but the major issue is breaking GDPR law, which is not just applicable for European Union, but for entire world (at least theoretically) because getting email address, even in hashed form, is illegal without users' consent.
Hi Nikunj
Thanks for raising this point. As you rightly mentioned, it's a violation of GDPR if they get an email address without a user's consent. The following is an excerpt from the SponsorLink Readme:
According to this, SponsorLink only gets your hashed email address 'after you install the SponsorLink GitHub app and give it explicit permission to do so'. The concern expressed in the linked Video is that as a compiled and obfuscated library, there's no way to tell whether this statement is true. However, by opening up SponsorLink and linking to that, it's now possible to see what's going on.
In addition to this, there appears to be an open issue where people are discussing GDPR compliance here
It looks like a step in the right direction
Harvey Dent was right. And I probably have lived long enough already.