SponsorLink and supporting OSS more broadly

[kzu]

Trying to aggregate the various issues into one to collect feedback.

I invite everyone to read the SponsorLink announcement to understand the intention behind it. No nefarious purpose, I promise! 🙏. I also wrote a follow-up post with additional context based on feedback so far.

With that in mind, I'm obviously open to suggestions that help achieve both your goals and mine :)

SponsorLink is now OSS too

An improved and more privacy-preserving implementation could use your feedback

NOTE: 4.20.2 removes SponsorLink since it breaks MacOS/Linux restore. I'll take the opportunity to collect more feedback.
The underlying issue still needs addressing, IMHO.

NOTE: SponsorLink won't be coming back until I improve on the suggestions made here. In particular, those mentioned in the announcement on OSS'ing it

[kzu]

Thoughtful blog post here: https://codingbolt.net/2023/08/08/a-deep-dive-into-sponsorlink-implications-for-open-source-and-privacy/

[rouke-broersma]

@kzu there's two main issues:

1. You're collecting email addresses. Even though you say you only send hashes, you send these hashes to your infrastructure. We don't know what you do with these. You could store these hashes (we can't verify because it's your infrastructure) and at some point compare these hashes to hashes you or someone else with access to email address hashes collected from somewhere else. As a non-evil example, you could use this list to give a priority to issues created in this repo based on if the hashed public email of the github user matches a user on your sponsor list, or on your non-sponsor list (since you could save whether a given hash is a sponsor or not, again we cannot verify). You can then also start building out your user info list with the other information you can gather from the github user. This is not a justified use of the email address we configure on our local machine, so for example any employer in Europe would be forced to move away from Moq, so they are not in violation of GDPR.
2. SponsorLink is obfuscated and closed source. It connects remotely to your infrastructure. You or some external entity could modify SponsorLink and/or your private infrastructure with malicious intent and we would not have an easy way of verifying the changes made. It's basically supply-chain malware in the making. It doesn't matter that it only runs on developer machines (at the moment) either because there are tons of developers who still publish from visual studio (yes, the horror).

[maartenvana]

Maybe, just maybe, you should approve #1373 first, to save whatever goodwill there is left. Then try to get a discussion going about how to get sponsers/paid.

That whole PR to add this closed source nonsense to this otherwise great package has only hurt this project and will continue to do so the longer this version is live.

[bartdebever]

I'm pretty sure a discussion about this is pointless, people are already mass removing your software and I'd personally not trust someone that added this to an objectively popular package. Figuring out you made it yourself is even worse.

This seems like a way for you to get more support and money but with this move I'm pretty sure you are going to get the reverse of that. Even IF you revert the PR, I doubt anyone will still trust you or the package and the mass amount of PRs removing Moq within a day confirms that point.

[DanielCordell]

No nefarious purpose, I promise!

I do actually believe you, and I'm glad that you're opening up a place to collect feedback rather than just closing any issues discussing the point. I think people should want to help projects like this continue to support themselves sustainably, just in a way that is agreeable to as many people as possible, and doesn't have any potential security/vulnerability ramifications.

A lot of people are going to be very negative, maybe rightly so, but I think that if we're going to have this discussion it should be from a place of "known safety" for everyone involved (and to reduce the general panic from everyone!) so would seriously consider merging #1373 or some equivalent ASAP, just so everyone can calm down a bit and have this discussion without having to be worried about their own projects.

I do think it is a conversation that needs to happen though, what is the best way that a FOSS developer can continue to make great stuff for the betterment of the entire dev community.

Of course to some people the project may just be "tainted" for good, not necessarily much you can do there, but reverting the change for now will definitely help with anyone who's currently "on the fence".

Edit: devlooped/SponsorLink#16 (comment)

edit: @kzu as other have said, you are now exposed to litigation. I would urge you to remove the 4.20.x versions just to limit the legal risk. It would only take one vindicative organisation to make things worse for you.

This is definitely something else to consider, you (probably) don't want to be at the receiving end of something like this.

[jakoss]

A lot of people are going to be very negative, maybe rightly so, but I think that if we're going to have this discussion it should be from a place of "known safety" for everyone involved (and to reduce the general panic from everyone!) so would seriously consider merging #1373 or some equivalent ASAP, just so everyone can calm down a bit and have this discussion without having to be worried about their own projects.

Exactly, opening discussion after merging the changes without bigger announcement is the biggest issue here i think

[baynezy]

Sponsorship is problematic for many companies as it does not fit into their financial model. Guerilla tactics to run code that harvests information from developers' machines and stores it in a closed system is not the way to solve this problem.

I have no issue with OSS maintainers making money, but you have to understand that if you don't engage your community on how you go about this and just try and sneak (and there is no way you can deny that is what has happened here) a data mining system into your product there is going to be a backlash.

This has just harmed your reputation and now means that many people will have to look for alternatives. Whereas maybe you could have looked at a licensing model or some other vehicle that companies can actually get past their finance department more easily.

[PoteRii]

https://github.com/moq/moq/pull/1373#issuecomment-1670914563
Are you trying to blackmail the community or what? LMFAO

Sorry no time for discussion, got to go remove Moq.

[DanielCordell]

I'm pretty sure a discussion about this is pointless, people are already mass removing your software and I'd personally not trust someone that added this to an objectively popular package. Figuring out you made it yourself is even worse.

@bartdebever Feel this is a bit defeatist no? Maybe I'm being too optimistic here, but a lot of this could easily be attributed to a genuine unintentional mistake on the part of @kzu. I'm sure there are plenty of people who would be perfectly happy if this change was removed, but arguing that the discussion is "pointless" just means that the sort of problems that incite people to do stuff like this never get looked at.

[BenjaminAbt]

You asked for feedback: @kzu, it's too late. You screwed up really hard. Sorry to say that but you have damaged the .NET community very badly after doing very very very great work for many many years.

With https://github.com/moq/moq/pull/1373#issuecomment-1670914563 you started to blackmail the community.

From a financial point of view, by taking this step you have decided that a great many hundreds of thousands of dollars/euros/X will have to be invested in order for projects to remain privacy compliant.
The only way to save this now is to accept the PR (https://github.com/moq/moq/pull/1373) now, take the affected versions offline and provide a new version.

However, the damage is beyond repair for us/me. We already revert to 4.18 and then switch to another library.
Thanks for Moq. It was great with Moq.

[LarsWesselius]

@kzu Really appreciate all the hard work that went into Moq. No one is denying it's hard work, and often underappreciated. It's fair to ask for something in return.

But I cannot stress enough that you can not do this by introducing a closed source, obfuscated dependency without discussion, and then pushing it as a new version. I'm sure your intentions are good but we can't see the code and we can't afford to assume it's ok. You have a massive user base in massive companies. I reported this to the large company I work at and they shit themselves. Does this not make you see that the way you've gone about this is totally insane?

The problem is now that even if the change is reverted, the trust in its maintainer(s) is gone.

[cdrnet]

SponsorLink would be a reason for me to stop sponsoring this project (if I were a sponsor).

[DibranMulder]

With this change you have just crossed an unreversible line. Trust has been violated and this privacy breach will force users to remove Moq from their code. Not only have you failed in creating a sustainable source of income for yourselves but you just threw away your lives work and lots of work from your users.

I understand that the current OSS work is unsustainable for you. And at times it may feel like everyone is benefitting from you and you don't get anything in return for it. This is true, but remember you have benefited from your work by building a name for yourselves which might open up new opportunities.

If that's not enough you should have considered to go commercial like the guys from IdentityServer did or another direction might be to drop support and go on with a new project and let the community figure it out. Sadly you chose to harden your stance which is going to backfire on you.

Thanks for all to good work on Moq is was great.

[VmPeter]

In your recent blog post, I noticed a delay in the build process for non-backers, indicated by "build paused for 1681ms." Is this intentional, and could you explain the rationale behind it?

Additionally, there are concerns about the security implications of transmitting emails to a remote server, especially given potential vulnerabilities associated with SHA. How do you address these concerns?

From a business angle, if a team of six developers uses their corporate emails in git, are they expected to personally fund software and NuGet packages? Should new team members also bear these costs, especially for tools like Moq? Given that the main beneficiary is the employer, wouldn't it make sense for the company to cover these expenses? How should we approach new members about these potential costs?

Moq is frequently referenced on several Microsoft developer pages as a recommended mocking framework. Do you believe Microsoft will maintain its endorsement of Moq in the future?

Is your motivation genuinely rooted in a desire to improve the FOSS landscape, or might there be underlying sentiments or experiences influencing your decisions?

[ArcadeArchie]

maybe a bit extreme but i recommend for anyone if this isn't reverted notifying your country's GDPR Supervisory Authorities as a last resort

[jakoss]

maybe a bit extreme but i recommend for anyone if this isn't reverted notifying your country's GDPR Supervisory Authorities as a last resort

Too extreme, definitely. This could destroy a person, and i'm certain we do not want to do that..

[kzu]

@rouke-broersma great points! So, if SL itself is OSS too, it might remove those concerns? How would one check sponsorship without resorting to email-based lookup? I wish GH/MS offered this OOB...

Thanks @DanielCordell for the vote of confidence. I just hope more people see this as an opportunity to discuss the very important issue of OSS sustainability.

@LarsWesselius "You have a massive user base in massive companies.". You know how many of that massive user base has sponsored my work? And those massive companies? Never heard of them. Only @aws contributed, once.

[4sneilhighley]

If you want to use sponsorlink to help you write Moq vNext, you should have had it only on that branch, not on the main

[PlayerModu]

Unfortunatly you decided the approach of blindly collecting PII data into a closed-source app. Doesn't matter if it's hashed or not. You can't f* around with GDPR. I hope you see sense and revert this change and seek a better more open way to monetise the project if you need too. But for now you have decimated anyone's trust in Moq, including mine and I will be removing it from all applications.

[kzu]

It's fine for folks to stop advocating for Moq. I think it would be far better to advocate for devs to realize there are actual people behind OSS projects. If you appreciate using OSS, you should be advocating for sponsoring as many projects as you personally enjoy using.

There is a chicken-egg problem with just adding SponsorLink to vNext: it requires a massive amount of work and there's no certainty the SL mechanism will even work at all (as noticed by many raising the GDPR concern).

[mikocot]

even if the whole thing is rollbacked and a satisfying sponsorship system introduced, we would need at least some additional reviewers in the project that would ensure such situation is not going to happen again out of nowhere

[BenjaminAbt]

You know how many of that massive user base has sponsored my work? And those massive companies? Never heard of them. Only https://github.com/aws contributed, once.

With SponsorLink, you have put many people into risk. Your current behavior is making sure that a lot of developers and companies now have to burn money to fix that. Money that you could have profited from yourself with an intelligent move.

Do you really think this step will help you change the problem of sustainable OSS?
Short: no.

[xDamon]

I invite everyone to read the SponsorLink announcement to understand the intention behind it. No nefarious purpose, I promise! 🙏

Do you have an explanation on why CPU and GPU utilisation spikes on your blog site? @kzu

[shoter]

@rouke-broersma great points! So, if SL itself is OSS too, it might remove those concerns? How would one check sponsorship without resorting to email-based lookup? I wish GH/MS offered this OOB...

You can create private nuget feed which allows sponsored user to download special version of library without any kind of messages.

And for free version you could always display an info message about sponsorship request. There would be no email checking involved - you would always display a message in free version.

Think outside the box you are currently in.

[karl-sjogren]

In your recent blog post, I noticed a delay in the build process for non-backers, indicated by "build paused for 1681ms." Is this intentional, and could you explain the rationale behind it?

Wow, I read this and thought "Maybe he justs logs how long the API calls took" but after looking through the obfuscated code there actually is a Thread.Sleep() in there at the end..

[kzu]

@BenjaminAbt I'm sorry if I don't believe that said massive amount of developers and companies could have spent that money benefiting me. It hasn't happened in a decade+.

[BerendWouters]

I've learned something from this: I should take a closer look at the (FOSS) packages I am using. I'm a software developer, and I rely on a lot of software written by other people. Sometimes they are being paid for it, but often they're not. I shouldn't blindly implement such packages. If I would've read the announcement regarding this implementation - which was half a year ago - I would've had the time to take a look at this implementation and decide what to do with it. Now I have to act on it too quickly, which puts me in a position I don't like: cornered. I have to adhere to GDPR rules, so I'll need to make some changes (or not upgrade to this version, but security issues and so on).
If I'd just taken a look at this 6 months earlier, I wouldn't be in this situation. And maybe this discussion would have taken place in a better setting.

The scariest thing I learned about this all is the fact that I use tooling that can run arbitrary code (code analyzers) on system. I should be more aware of these security risks.

Regarding the entire FOSS discussion: FOSS devs don't get enough credit. Help them.

[jeroenwalter]

How long until someone publishes a fork of that with the "checking subscribed" function returning true...and then keeping their fork up to date with Moq...

See FastHub being forked into FastHub Libre as an example of that happening

A better example is CivetWeb (https://github.com/civetweb/civetweb) and Mongoose web server (https://github.com/cesanta/mongoose).
CivetWeb is a fork of Mongoose, because Mongoose changed its license from MIT to dual licensed GPL/commercial.
Several contributors didn't agree with that, because this would mean they couldn't use the project any longer in their own open and closed source projects. Some even requested their contributions to Mongoose to be reverted.
Both projects are still actively maintained, but also show how a difference in views between the project owner and the project contributors can cause major shift in development, popularity and reach of a project.

[slangeder]

How long until someone publishes a fork of that with the "checking subscribed" function returning true...and then keeping their fork up to date with Moq...

It already happened... https://github.com/hassanhabib/CleanMoq

[stakx]

... and here: https://github.com/stakx/moq. (Though I hope this is only a temporary thing, as I'd much prefer sending PRs to this main repo directly instead of helping to facilitate a splitting-up of the Moq community. That's one of the reasons why I've decided to restrict collaboration on that fork in a particular way; the other is explained in https://github.com/moq/moq/issues/1396#issuecomment-1684974621 as well as in the fork's CONTRIBUTING.md.)

[stakx]

Out of curiosity, is anyone here familiar with Fody? (They have for the longest time stated upfront that developers using it are expected to contribute or sponsor the project... and at least for me, that simple measure would have worked, had I actually ever used Fody. Most projects simply aren't that explicit about their expectations.) I wonder how their approach has worked out for them over time, and in what ways they struggled with it. Does anyone here know?

[rouke-broersma]

Out of curiosity, is anyone here familiar with Fody? (They have for the longest time stated upfront that developers using it are expected to contribute or sponsor the project... and at least for me, that simple measure would have worked, had I actually ever used Fody. Most projects simply aren't that explicit about their expectations.) I wonder how their approach has worked out for them over time, and in what ways they struggled with it. Does anyone here know?

I only know that some of the developers/contributors of Fody are also users of Stryker and as far as I remember they've often fixed their own issues so I am very happy with them.

[tonyqus]

@kzu @stakx I have a not-so-great idea. If you create your youtube channel and have a live discussion about SponsorLink, I guess you can get a few donation during the live session. Youtube is a good channel to get donation or sponsorship.

How do you guys think? Vote by emoj, pls

[kzu]

Hehe, one-time donations aren't sustainable. So the proposal would require me to become a YouTuber every month? 😉

[tonyqus]

Youtuber is not a bad choice. You are the super star of open source now although not good fame. But it's not important. Someone is willing to watch someone they don't like or just curious to see what are you going to say or comment.

[rakker91]

lol--you could just record yourself writing code for MOQ and post that as your youtube channel . . . Works for the author Brandon Sanderson . . .

[stakx]

IIRC @kzu has done something like that before, there's a multi-part series where he developped a DI container (Funq)... nice material. Those videos deserved many more views than they got IMHO. I for one really enjoy such "hands-on" content.

[kzu]

You folks are too bullish on folks wanting to listen to me 😅. https://www.youtube.com/watch?v=qjbKANpGep4&t=1411s a massive 14 views in a week 😂.

Thanks for the throwback to Funq times @stakx. Case in point: 9 videos, 2.150 views.

[duki994]

@kzu

You refer to OpenCollective and similar initiatives (don't know which issue it was where this was posted):
"Open Collective is a legal and financial toolbox for grassroots groups. It’s a fundraising + legal status + money management platform for your community"

How is SponsorLink legal? What's the financial toolbox?
Why were there "extortion" mechanisms such as pausing builds, sending any type of data etc.?

How is this model exactly solving problems of OSS community that GitHub Sponsors, Patreon, OpenCollective and others don't solve? You do reiterate several statements which are already solved by most of them, except maybe profit sharing between contributors. Why does it need to be connected to git when there are other large projects using Helix Core, Mercurial and some even with SVN?

About the bounty model: What stops me from doing nothing until I get money (i.e someone prefers paper-money/cash)? Or demo a solution which works and not open PR or anything until I get money? This way increases competition between small teams.

About project sponsorship visibility: SponsorLink won't help this one. Just look at entire NPM ecosystem to see how they tried to do it in myriad of ways. In time all the workarounds will be found.

Also, how does SponsorLink solve these problems outside of .NET projects (those who cannot use Roslyn APIs)? For example I have several custom Android Linux Kernel projects I'd like to potentially sponsor? GH Sponsors, Patreon and others are also doing fully legal transactions with auditability that my country needs. Does SponsorLink do that too?

What I see here is that you are solving your own problem and framing it as an OSS community problem.
I watched that video, but it's full of opinions and half-based solutions to a very specific context sensitive problems that aren't even oriented towards OSS.

[kzu]

SponsorLink is a way to link your GH Sponsors contributions, with code that a package author can use to do something with that information. It can be displaying an info message (or not), lighting-up some functionality, or whatever. SponsorLink is as legal as GH Sponsors is, I suppose.

The "sending any type of data" was not extortion. It was a bad implementation of email hashing which seemed really convenient and easy to implement but had issues as many pointed out. That is being fixed.

SL is not a different model. It just brings GH Sponsors to code-level checks, so a package author can do more with the information that a user is sponsoring (or not). What they decide to do is not up to SL. Personally, I'll attempt to offer additional features based on that that would hopefully offset the convenience of not sponsoring any of the OSS projects you use.

bounty model

Yeah no idea how folks will react. I guess if GH itself implemented this as a button on every issue, we'd quickly see what happens. If anything, if you see a project not "doing anything unless they get money", you could just switch to another project that has folks doing it for free and more actively.

About project sponsorship visibility: SponsorLink won't help this one.

NPM guys have ZERO integration with IDE-level features. I'm not willing to discard that aspect just yet and equate it to a message in a build log.

GH Sponsors, Patreon and others are also doing fully legal transactions with auditability that my country needs. Does SponsorLink do that too?

You seem to be quite confused about what SL is even about. You can read more about the idea on my blog.

About other other non-.NET projects: as I'm moving to a GH CLI-based approach, users on any platform/language can run:

> gh extension install devlooped/gh-sponsors
> gh sponsors

And that will generate a JWT manifest, which can easily be checked using standard JWT libraries and base64+sha256 hashing, all local and offline. See the built-in check command implementation as an example.

What I see here is that you are solving your own problem and framing it as an OSS community problem.

Well, I am an OSS developer (so, part of the "community" I suppose?). And obviously, I'm solving this for me too. The "OSS community" at large can just ignore what I'm doing and move on, just like they can ignore any OSS developer's code/projects they deem not useful. My hope is that "my problem" is not something unique to me and therefore others might find my solution useful for them too.

Time will tell.

aren't even oriented towards OSS.

The two folks that talked most in the video are OSS developers and maintainers of two fairly large OSS projects: WiX and Akka.NET. So I'd say their opinions were very relevant.

[duki994]

NPM guys have ZERO integration with IDE-level features. I'm not willing to discard that aspect just yet and equate it to a message in a build log.

That zero integration is quite an advantage. Not just for NPM, but many other ecosystems.
I strongly disagree with any IDE meddling, and would never do that. However, I see why you don't want not to discard this aspect.

The two folks that talked most in the video are OSS developers and maintainers of two fairly large OSS projects: WiX and Akka.NET. So I'd say their opinions were very relevant.

I understand you (and naturally them) being .NET oriented. I'll ask some people I know personally working on mainline Linux Kernel and some Linux FOSS driver maintainers to add their inputs here. It'll be nice to have inputs from other ecosystems that didn't have entire closed-source to open-source model changing like .NET and are in OSS arena for much longer.

[kzu]

The "IDE meddling" is precisely what makes smart libraries possible and amazing.

[duki994]

The "IDE meddling" is precisely what makes smart libraries possible and amazing.

Perhaps. Same things exist in other ecosystems with easier configuration.
JS (and NodeJS) ecosystem has ESLint (and rome as newer alternative) that could do that too regardless of IDE long time before .NET Core and .NET 5+. IDE integration is then just an extension away - VS Code, JetBrains IDEs, Visual Studio, Eclipse etc. Or just use any editor and ESLint via CLI if you want.

jest, jasmine, mocha, react, angular (etc.) - all these libraries and frameworks are falling under smart library definition by you. All analyzed via ESLint (or via TSLint in older days). It's not tied in any way to build process or IDE, unless you manually do that yourself. Can completely disable specific analyzer via easy configuration file, unlike suppress-only Roslyn analyzers and code fixers.

And if I have too many Roslyn analyzers, my IDE, or any other code editor communication to Roslyn via LSP can lock up due to too many resources used? Even when analyzers are "suppressed" because they run in background?

It's just that I'm baffled that there's capability of intentionally pausing build(s) even when you suppress specific analyzer, simply because all analyzers are run on all source files. I've just tested the hypothesis using one. Roslyn APIs were intentionally designed this way for some reason MSFT knows (cross-platform telemetry?).

Of course, there is always a (hacky) way to disable specific analyzer. A convoluted approach via MSBuild target running before compile target could probably be used to remove specific analyzer reference.

[kzu]

IDE integration is then just an extension away - VS Code, JetBrains IDEs, Visual Studio, Eclipse etc.

As a long-time VS (and some VSCode) extension developer myself, I can assure you there is no such thing as "just an extension" away.

The power you get for very low effort via code fixers and source generators in Roslyn is immense. It's a game-changer in productivity and best-practices. It's not the analysis that is the game changer, but the ability to provide one/many code fixes as suggestions, with full diff/preview, etc. And the codegen (but that could also be done via MSBuild).

I'm not sure why anyone would be baffled when the compiler itself is extensible and invokes .NET code, basically. It would as if you were baffled that you could pause the build in an MSBuild task, say.

[duki994]

The power you get for very low effort via code fixers and source generators in Roslyn is immense. It's a game-changer in productivity and best-practices. It's not the analysis that is the game changer, but the ability to provide one/many code fixes as suggestions, with full diff/preview, etc. And the codegen (but that could also be done via MSBuild).

As ESLint does too, except code generation. Code diff/preview is an IDE level feature that leverages Roslyn APIs. Can be made for Rider, VSCode, VIM etc.

I'm not baffled by Roslyn capabilities. Many other platforms I've worked on have similar capabilities.

I'm baffled just by the simple fact that you cannot disable execution of specific analyzers or code fix via configuration "knob" or something similarly simple. And I mean disabling execution, not just suppressing it via .editorconfig or pragma and similar stuff.

Say someone creates a package with 200 analyzers and 500 code fixes that are very popular. After some time, a malicious analyzer (or code fix) that can read sensitive private data somehow (such as credit cards) and send it over the wire is added. How can end user disable it easily as immediate fix when found without stopping rest of 200 analyzers and 499 code fixes that aren't malicious?

ESLint and similar tools do this quite easily via configuration files - actually disable code diagnostic/fix execution
Roslyn - suppresses code diagnostic/fix while actual code diagnostic logic runs

I might explore if this can be achieved via custom made MSBuild Task.

EDIT: There's a need for custom solution for Design-time / Live analysis. Most probably IDE extension unless Roslyn adds support for this

[kzu]

Looking for feedback on the v2 implementation at https://github.com/devlooped/SponsorLink as well as the privacy statement/policy at devlooped/SponsorLink#73 🙏

[DermotMurphy]

I am interested in how SponsorLink will work when a corporation pay the sponsorship. How will you determine that developers from that company will be recognised?

[kzu]

Devs on that org are linked to the org sponsorship via their email domain, which will match the orgy's verified domain (see https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization).

Example:

• User has Microsoft among the organization he belongs to
• One of his emails is foo@microsoft.com
• Orgs domain is microsoft.com (see https://github.com/microsoft/)
• When generating the manifest, we see MS sponsoring X, so we record @microsoft.com > X

When checking the hashes on the manifest, in addition to checking foo@microsoft.com, we look also for @microsoft.com and find a match. Ergo, user is sponsoring (indirectly in that case).

[kzu]

I'd appreciate it if you could take a moment to help me understand the feedback better by answering the poll at https://github.com/moq/moq/discussions/1414 🙏

[kzu]

Got good feedback on this. Closing for now. Further SL discussion should happen over at the https://github.com/devlooped/SponsorLink repo. Thanks!

[tonyqus]

I kicked off a discussion about changing OSS license . Please join if you are interested.