Guidance on how to systematically block dependencies using SponsorLink?

[cdrnet]

Is there a way e.g. to fail my build if any of my dependencies are using SponsorLink? Some way which is entirely local, not sending any data to a remote server. Maybe directly on NuGet level?

In my opinion, SponsorLink is actively hurting opensource sustainability and usage in both commercial and non-commercial cases, so I'd like to ensure I don't accidentally depend on any package using it. Similarly, at work, SponsorLink is now essentially banned, I'm therefore also looking for a good way to enforce that ban.

Thank you!

[kzu]

The v1 implementation of SL is no longer shipping in any public packages. So I think this is mostly wasted effort.

[kzu]

There's no license, no SLA. If you don't install it, you can still use the software and it's still OSS. Not sure what part of that isn't clear.

You don't HAVE to sponsor, neither install anything. Depending on the package author, if you sponsor, you might get more productive. That's all. But otherwise, business as usual.

[jeroenwalter]

Fine, keep ignoring normal business practices.
If you sponsor, you need to install the app to benefit from it. As I understand it correctly after reading your comments the last 2 weeks, your vision is that each and every developer, even if they are employees of a company, need their own personal github account and needs to sponsor projects individually.
I highly doubt there will be any companies that think that is a good solution.

[kzu]

Nobody will need anything. You can continue using the OSS parts of it and/or ignore an info message. No biggie, IMHO.

[jeroenwalter]

That's not the issue. Once you want to use the licensed stuff, you must install the app. That's a problem for the reasons I already stated above.
You make light of it, but that attitude will not result in a wide acceptance of SponsorLink.

[kzu]

There is no licensed stuff. You already install a nuget to use it, and being OSS, the "administrative/legal overhead" is likely minimal because of that. Same thing with additional features. And "my app" is just the GH CLI and an extension to it, which are both also OSS. So I fail to see why the situation would be worse than the original one of getting permission to use the OSS library in the first place.

[cdrnet]

Why was this closed? This is not outdated. SponsorLink is still geared towards misusing sponsorship for pseudo-licensing, which is still unacceptable to me – so I'm still interested in systematically blocking dependencies using SponsorLink.

[kzu]

That's at best a nuget issue (not unlike blocking packages from a given publisher or that contain analyzers, etc.).

SponsorLink will provide just source-only helpers to deal with the standard manifest but what a package author decides to do with that is entirely up to them. Ergo, there's nothing "special" that you could use to detect this.

Being against packages that seek sponsorships is like being against OSS being sustainable, so I'm not even sure why that's a good thing for anyone.

In any case, there's nothing that SL itself needs or can provide to support your scenario.

[cdrnet]

That's at best a nuget issue (not unlike blocking packages from a given publisher or that contain analyzers, etc.).

Fair point. Maybe I'll just have to manually maintain a deny-list, or apply some static analysis in CI.

Being against packages that seek sponsorships is like being against OSS being sustainable, so I'm not even sure why that's a good thing for anyone.

I never mentioned being against projects seeking sponsorship, that's perfectly fine, and great if it works out. What doesn't work for me is if any behavior of a package depends on a sponsorship level – then that's really misusing sponsorship for commercial licensing without being honest and calling it so, and without dealing with the legal implications. There's nothing wrong with commercial licensing, I happily pay for many commercial licenses myself, but I'd want to know about that from the start, and I'd stay away from them in any of my open source work.