Restore GDPR compliance and privacy

[DanWillman]

No description provided.

[CLAassistant]

All committers have signed the CLA.

[DanWillman]

Fixes #1372 #1371 #1370

[tomaskarban]

This PR is reverting commit 6057dd2. Looks good to me.

[kzu]

Superseeded by https://github.com/moq/moq/pull/1375

[jakoss]

Superseeded by #1375

Isn't #1375 only removing the reference to the project that contains the analysis? And under completely difference pretense?

[SelectiveHouse]

Superseeded by #1375

Surely SponsorLink.cs should also be removed to supersede this PR?

[aradalvand]

Superseeded by https://github.com/moq/moq/pull/1375

@kzu Not really. That PR's description literally says it addresses #1371; not #1372. How does it supersede this PR?!

[wardboumans]

Brilliant

[CalvinWilkinson]

Based on the actions that I am seeing by the project maintainers, they don't even want to discuss it.

At the very least, expose and be transparent about everything and try to plead your case. Also, at least spend the time to have conversations with your community. Isn't that one of the benefits of OS?

[phillip-haydon]

👍

[ZXeno]

Watched this unfold for a bit, but closing this PR and saying it was "superceded" by another only removing a single project reference and doing aboslutely 0 to address the overwhelming backlash of privacy, GDPR, and security concerns... I'll now be removing this package from all of my personal and work projects, filing a report with my company's infosec team, and migrating all of our projects to an alternative.

Not the first package I've done this with, and I'm convinced this won't be the last.

Good luck in your efforts to secure funding going forward, but I suspect you're going to have to somehow rebuild your reputation first, and I see no clear or easy way to accomplish that.

[kzu]

@CalvinWilkinson perhaps you missed https://github.com/moq/moq/issues/1374. Please join the conversation.

Removing the project reference is enough to remove it from the package, which is why it superseded this PR.

I @ZXeno sad to see you go. I hope you enjoyed Moq all these years though!

[LucHeart]

This PR should be reopened as stated before.
Not "superseeded" by your other PR that only removes it because of "MacOS restore"..

Please be honest with your community around Moq, and dont try to downplay it with your PR. There is so many reasons for why so many people hate this change. One of the reasons is that people actually liked moq and used it for previous projects, both private and enterprises!

[CalvinWilkinson]

@CalvinWilkinson perhaps you missed #1374. Please join the conversation.

Removing the project reference is enough to remove it from the package, which is why it superseded this PR.

I @ZXeno sad to see you go. I hope you enjoyed Moq all these years though!

I did not know this was going on. Thanks. I will take a look!!

[0x56696B]

You know you've screwed things badly, when such a popular framework gets linked by the second on different projects as "replace with X, because of privacy issues".

Also, legitimate question: Why was such change merged without any PR approvals from any of the maintainers/contributers?
I get why you pushed such change, but considering the scale of the library, it seems like quite a rushed decision. No comments, no reviews, no nothing. No public ones, at least

[sjd2021]

I planned to use the allowedVersions attribute to block upgrades > 4.1.*, but I just realized that is only supported in packages.config, not with the PackageReference element in csproj files. Does anyone know of a way to ensure devs are significantly less likely to accidentally upgrade the package when using some sort of "use latest of everything" feature in their respective IDEs?

[ys-jeffn]

Check out
https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#Constraining_Upgrades_To_Allowed_Versions

It has details on how to block upgrades in csproj files as well.

[scovetta]

@sjd2021 I'm pretty sure you can use semantic versioning in csproj files:

<PackageReference Include="Moq" Version="[4.18.2]" />

https://learn.microsoft.com/en-us/nuget/concepts/package-versioning

[sjd2021]

@scovetta That's how I had it set up, but the IDEs don't seem to do anything significant when someone generically clicks "upgrade packages" at the solution level. It just replaces it with 4.2.

[giddy11]

great

[mletterle]

I planned to use the allowedVersions attribute to block upgrades > 4.1.*, but I just realized that is only supported in packages.config, not with the PackageReference element in csproj files. Does anyone know of a way to ensure devs are significantly less likely to accidentally upgrade the package when using some sort of "use latest of everything" feature in their respective IDEs?

There is no guarantee that SponsorLink "support" won't be backported to a minor (or patch!) release of a version < 4.20, this is what happens when trust is broken.

[wrexbe]

Can someone fork it, and make another nuget package?

May I suggest the name for the fork:
MOP
Mocking objects with privacy

Also here is an icon that could be used for the Repo, I license this image under Public Domain

[Matthew-Davey]

I suggest the forked project should be named moqq - because we're all crying with anguish, or laughter, or both.

[kzu]

Merging this is not really relevant anymore since SponsorLink is OSS and no longer shipping with the latest Moq, but nevertheless, it sends the right signal at this point to merge this in the meantime.

@DanWillman could you merge main on your side and push again to your branch to GH will let me click the "Reopen" button here? I'm trying it now and it's not doing anything :(

[DanWillman]

I synced my fork with main, but I'm unable to re-open. Seems like it might be a maintainer that has to do that. If you or @stakx don't have the option for it, I could just open a new PR. Just let me know how you want to proceed.

[stakx]

@DanWillman, for me the Reopen pull request button is also disabled. When I hover over it, a tooltip says, "The main branch was force-pushed or recreated." Not sure how you would need to go about resolving this.

Would it perhaps be an option to submit these changes as a new PR with the same title, and link to this PR in the description (in order to retain the comment history)?

[DanWillman]

Yeah, that is probably for the best, I'm not quite sure how it ended up in this state, but no biggie.