Closed kzu closed 1 year ago
No nefarious purpose, I promise
Privacy Statement:
Trust me, bro
@jakoss fair point. So org-wide sponsoring should be an option. ๐
@sgtwilko GUID: chicken-egg. You install the lib, how do I know you're already a sponsor? Generate a local GUID: how to match against a server-side GH app that's completely decoupled from your machine? ๐ค
@mason-bially "(or you know, you could pay the developer for their work)." ๐น
You install the lib, how do I know you're already a sponsor?
@kzu no matter what you want, you have to obey the law(s). What you do with personal data, SponsorLink and Moq is forbidden - at least in Europe.
@sgtwilko GUID: chicken-egg. You install the lib, how do I know you're already a sponsor? Generate a local GUID: how to match against a server-side GH app that's completely decoupled from your machine? ๐ค
@kzu Is there really a requirement to be able to check if someone is a sponsor though? If the mechanism for alerting users was as simple as a console message then people wouldn't need to "turn it off". Of course it would be less obtrusive, but that's the trade off to keep users feeling confident in your tools.
Someone said you could have a "private" package if anyone is a verified sponsor, that could be an approach? You could start creating new features that you have to use the "private" package if you want to access.
using the work of unpaid volunteers with no consideration for how they are compensated for their time and labor
I don't think you understand the concept of volunteering if you think compensation is involved. The beauty of OSS is that it's at-will and nobody is forced to do or provide anything. If a maintainer decides to stop supporting a project one day, nobody can reasonably complain about it - they still have the option of forking and maintaining themselves.
While it's nice to have some form of income from your efforts, I don't think it's a necessity. Shoving it down people's throats while violating their rights (GDPR requires users to actively consent, the license disclaimer does not count) then there is a problem. If you want remunerated that badly, then move to a paid product or freemium model.
@DanielCordell I looked at how others (i.e. node) do this "just beg in the console". I haven't seen anyone say it's a success for OSS sustainability. Also, we all build in IDEs nowadays. The only one who will see the console output is the CI server ๐.
More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example
@sgtwilko GUID: chicken-egg. You install the lib, how do I know you're already a sponsor? Generate a local GUID: how to match against a server-side GH app that's completely decoupled from your machine? ๐ค
@kzu Didn't I read that part of the process was signing up using an app linked to Github? That should be able to provide the guid.
While it's nice to have some form of income from your efforts, I don't think it's a necessity
I think this is ignoring a real problem that a lot of projects have become unknowingly taken for granted, I hope nobody believes that people shouldn't be be paid for "work".
he beauty of OSS is that it's at-will and nobody is forced to do or provide anything.
The downside of OSS is that what starts out as volunteering can eventually turn into a job, but one that you didn't apply for and that you have much more of a stronger emotional investment in, making it harder to break away from a project you've worked on for many years. "Just abandon it" is going to be a last resort for anyone with a significant time or emotional investment in what they're making.
The "app" is a GitHub App: basically you give the app permission to read your email, and the app gets a webbhook call after you authorize (simplified). This all happens on the backend. All you have on that end is the user's id/login/email(s).
On the client, someone just installed your lib. The tricky part is mapping the two. And you don't know if GH is even involved (all you "see" is the source, its location, therefore if it's a git repo and that's about it).
More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example
@kzu all you need afaik is a private feed and that when you purchase a "licence" for moq premium it gives you instructions/setup necessary to use the premium one.
@DanielCordell I looked at how others (i.e. node) do this "just beg in the console". I haven't seen anyone say it's a success for OSS sustainability. Also, we all build in IDEs nowadays. The only one who will see the console output is the CI server ๐.
More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example
Imo getting paid for open source software is a solved issue and the solution is not sponsorships. They simply do not work, sponsoring is not a sustainable model to get paid for open source work no matter how much you nag them. They will either ignore it, or stop using your package. What does work is paid support contracts + paid licensed features. People will find the correct package because they will contact you to buy it.
@DanielCordell what about CI? Users will have to configure that private feed themselves too?
@kzu Is there really a requirement to be able to check if someone is a sponsor though? If the mechanism for alerting users was as simple as a console message then people wouldn't need to "turn it off". Of course it would be less obtrusive, but that's the trade off to keep users feeling confident in your tools.
@kzu @DanielCordell There's VSColorOutput64 Visual Studio addon - which does exactly that. It prints additional message to output. When you donate, you can suppress that message by checkbox in settings. (Of course you can check it anyway, but it still make user think)
Why not going this way instead of sending data such sneaky way?
@rouke-broersma I don't think it's as simple as that. Otherwise, GitHub wouldn't have spent time and effort in providing the GH Sponsors feature in the first place.
@thaumanovic
Shoving it down people's throats while violating their rights (GDPR requires users to actively consent, the license disclaimer does not count) then there is a problem.
The license does disclaim it. This isn't a website passively running code on your machine. You downloaded and built the software, and somewhere along there you actively accepted the license. Because otherwise you are violating the author's rights. The only legal way you have any right to have a copy of this software in the first place is if you disclaimed all liability of it's use. That's the active acceptance you went through.
I don't think you understand the concept of volunteering if you think compensation is involved.
Plenty of volunteers are paid. Volunteers do necessary community work, giving their time and labor. That doesn't mean they aren't compensated in some way for undertaking tasks others wouldn't for far more money. But if it helps, then I misspoke, I more meant, "for how they survive while giving away their time and labor".
You're basically sending peoples data to a shady endpoint without asking any kind of permission (I'm not even talking about unsolicited fake warning which is breaking builds). That's illegal in many countries. Also, you've destroyed all trust in your library by sneaking in this change without any consultation with community.
It's not easy to monetize OSS project and sneaking in spyware in your lib is certainly not the way to do it.
@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.
More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example
take a look at the kickstarter-like backer tier list on the graphile maintainer's sponsorship page: https://github.com/sponsors/benjie It's essentially laid out exactly what supporters get. Yes, it's more work on the backend for you (private repos, discord/slack servers, manual verification of supporters on github tickets etc) but that's the case for the "business" side of coding. you need to either be an employee, or you need to act like a business and do business-y things. not just expect people to donate out of free will. you need some stick to go with your carrot. but the stick has to be worth it or you'll just lose all the sponsors you have even now
(In case my carrot/stick reference is too culturally specific, there is an old trope of leading a donkey by riding it holding a stick with a carrot dangling from it just in front of the donkey's face. the donkey walks forward to try and get the carrot but as he does so, the carrot continuously moves out of reach as it is being held by the rider. - if you make the "stick" too much a pain point, the donkey will just give up and not continue walking)
@kzu The only thing you need is a change in the license, to target large companies. So if a company has a revenue more than a million let's say, they are required to pay a license of your liking in order to use the library. There are no need for anything else, a lot of companies will comply, and that's the end of the story.
Even the hash of the email is PII, if you do that in EU you are in a very big trouble, remove this code ASAP.
@abrugsch "manual verification of supporters on github tickets", that's ONE major thing GitHub could implement for us.
@rouke-broersma I don't think it's as simple as that. Otherwise, GitHub wouldn't have spent time and effort in providing the GH Sponsors feature in the first place.
You're under the impression GitHub introduced this to help the open source community but GitHub is a corporation, they mostly only do things that are to their benefit. I'm not saying the donation feature is unused, I am saying that it is not a sustainable way to get funding from OSS work. If it worked you wouldn't have this issue in the first place. And nagging people to donate does nothing but cause backlash as you can clearly see.
@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.
can I review code doing that? Is it included as source I can review?
@abrugsch so I take it the stick being an annoying build message (and eventually a build pause) is too much?
@abrugsch "manual verification of supporters on github tickets", that's ONE major thing GitHub could implement for us.
how does github verify supporters from patreon, paypal, ko-fi
I'm also a open source maintainer. I have to admit the method that SponsorLink introduced is really creative although it's a bit aggressive.
Lack of Sponsorship is not a problem only Moq has. It's a common problem for most .NET open source projects. And .NET foundation also doesn't help much on this although it labels itself as foundation of promoting .NET projects and ecosystem.
Compared with Java ecosystem with Apache Foundation support, a few big companies are sponsoring not only talent but also money to different top level projects. While most .NET projects are maintained by individuals.
I do appreciate @kzu is putting efforts on encouraging sponsorship for open source projects.
Sometimes, making troubles for users of open source projects (not on purpose) can definitely help increase the chance of getting sponsorship or extra consulting money from users. I've been maintaining NPOI for almost 14 years. Every time I makes money from NPOI users is because they have troubles (even some are bugs). Too smooth experience of open source projects totally doesn't help on increase sponsorship. This is my experience.
For commercial projects, the company provides post-sale support because users pre-pay money for support service. It's not free. The sustainablity of open source projects I understand should be
However, most open source users doesn't agree on this and they don't wanna pay at all. They wanna everything free.
@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.
It's not the case. It's just that you can compare it with a list of mails obtained somewhere else e.g. from a leak and this way identitfy someone. That's why hashed mail can be considered as a PII. If I was selling products to dotnet developers I would love to have a list of hashed mails of users of Moq and a huge set of mails obtained somehere else to target my campaign ;).
there's no sneaky sending of data
How can adding a closed-source assembly that is obfuscated in any way not be considered sneaky?
And even if you changed it now (making it open source and not obfuscated), your intention there is very clear that you wanted this to be sneaky. Thatโs a heavy trust lost on your part.
I looked at how others (i.e. node) do this "just beg in the console". I haven't seen anyone say it's a success for OSS sustainability.
I think this is a funny statement. With SponsorLink, you have invented a new approach. So letโs find out whether anyone will say in a few months whether that was a success for OSS sustainability. The feedback you are getting doesnโt look great, and I still think itโs very concerning that you donโt understand the underlying issue and continue defending how SponsorLink works.
@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.
I don't get this at all. The discussion about sponsorship is one thing but no one can see what you're doing in your library. Are we just supposed to trust you? How anyone can think this is ok is beyond me. You could be doing anything in your closed source obfuscated SponsorLink code.
@wdolek trivial to verify if you use Fiddler to look at the URL I'm GETing, and grabing the blob-looking segment and SHA256 hashing your git email. It will match.
@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.
@kzu Hash your email address (from your public gh profile) with SHA265 - https://emn178.github.io/online-tools/sha256.html Now search for the hash on https://gist.github.com See the problem?
@abrugsch they don't. There are NO FEATURES in GitHub that allow you to say "this should only be possible if you're a sponsor" (like opening an Issue).
@abrugsch they don't. There are NO FEATURES in GitHub that allow you to say "this should only be possible if you're a sponsor" (like opening an Issue).
I think that's simply because GitHub is about OSS, and that simply is not in the nature of OSS.
@abrugsch so I take it the stick being an annoying build message (and eventually a build pause) is too much?
not the message, but the GDPR breaking dependency and security scan failing process. my company is now scrambling to pin the version in all projects and find alternatives because the next round of nessus scans will fail (let alone the "warnings as errors" flag they require that broke everyone's builds last night)
@abrugsch they don't. There are NO FEATURES in GitHub that allow you to say "this should only be possible if you're a sponsor" (like opening an Issue).
no you misunderstood my comment. That was a hypothetical "how WOULD github verify those donators if they implemented sponsor marking for you" sorry I wasn't specific enough
@abrugsch so I take it the stick being an annoying build message (and eventually a build pause) is too much?
Just imagine what will happen when 20 different packages decide to pause my build to nag for sponsorship. People will start developing extensions to block this and you'll be back where you started.
@wdolek trivial to verify if you use Fiddler to look at the URL I'm GETing, and grabing the blob-looking segment and SHA256 hashing your git email. It will match.
We shouldn't do this, SponsorLink can change at any moment without any warnings and 0 scrutiny, because it's closed source. (and it being obfuscated is another major red flag)
@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.
This is easily reversible with a rainbow table. Also we can't see what the code is doing! That's the key point here. Also I'd hate for any program to try to scrape any data from my PC.. There are plenty of other good ways to establish some user identity or license. (like asking!)
OSS is hard to monetize, but not impossible. This is just not the correct way. With a name as big as Moq you could even create some unit testing 101 packs for example. Most revenue for OSS is in side businesses and corporate licensing/support unfortunately.
OSS is hard to monetize, but not impossible. This is just not the correct way. With a name as big as Moq you could even create some unit testing 101 packs for example. Most revenue for OSS is in side businesses and corporate licensing/support unfortunately.
essentially: if you want business benefits (i.e. getting regularly paid) you have to do more business-y things not just "build it and they will come/pay me"
@kzu Maybe I've missed it, but I haven't seen you answer what is in my opinion the biggest problem here, why does this Open Source project inject closed source software that is obfuscated, into the released version?
Why is SponsorLink not open-source? And why is it obfuscated?
This is the blocker for me, before even getting to GDPR issues, you are asking individuals and companies to trust you when you are injecting closed sourced, obfuscated software into an open-source project. I'm confused how you don't understand how this might be a problem.
I have an assumption: What if @kzu open source the source code of SponsorLink? Do you guys still have concerns? I think the major problem in the discussion is no trust on closed source nuget package.
@Minmoose
Why is SponsorLink not open-source? And why is it obfuscated?
he has answered this in GH issues raised against SponsorLink and that is that he believes closed source obfuscation is the only way to protect the code from being reverse engineered/blocked/circumvented...
I have an assumption: What if @kzu open source the source code of SponsorLink? Do you guys still have concerns? I think the major problem in the discussion is no trust on closed source nuget package.
The backend is still closed source, and it would still be collecting PII and sending it to a third party with which no business has an agreement for data collection and for which no one can verify how they use the data they received.
I have an assumption: What if @kzu open source the source code of SponsorLink? Do you guys still have concerns? I think the major problem in the discussion is no trust on closed source nuget package.
No. Like, what is even the purpose of adding SponsorLink here? The SponsorLink library says it could be used to add paid features for sponsers... Ok, so what premium / paid features does Moq offer that requires SponsorLink in the first place?
Worst case scenario: this is malicious... Best case scenario: this is unnecessary bloatware
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.
Definately cant mess with GDPR, a fine up to โฌ10 million or up to 2% of the annual worldwide turnover of the preceding financial year in case of an enterprise, whichever is greater, if there has been an infringement.
I'm an outsider to this, but let me toss my hat in against the apparent prevailing opinions. Because I think they are wrong. .... Let's start here. People apparently did not read this project's license before using it. Here allow me to quote the relevant section, (ALL CAPS in original for EMPHASIS, I have further BOLDED IT):
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
saying you're not liable is not enough to not be liable, what is required by GDPR etc is to be clear about what is collected, for what and how it's processed plus to have clear permission from the user to do so AND let users have insight into this data and allow to modify/remove them. There is nothing that the author has done in thie direction
Chapter V of the GDPR forbids the transfer of the personal data of EU data subjects to countries outside of the EEA โ known as third countries โ unless appropriate safeguards are imposed, or the third country's data protection regulations are formally considered adequate by the European Commission. Where is @kzu based ?
Chapter V of the GDPR forbids the transfer of the personal data of EU data subjects to countries outside of the EEA โ known as third countries โ unless appropriate safeguards are imposed, or the third country's data protection regulations are formally considered adequate by the European Commission. Where is @kzu based ?
if you would care about all of this you could just read centered h3 text on the authors profile which says so
Why is SponsorLink not open-source? And why is it obfuscated?
he has answered this in GH issues raised against SponsorLink and that is that he believes closed source obfuscation is the only way to protect the code from being reverse engineered/blocked/circumvented...
If that's all it would take, the biggest companies in the games industry wouldn't need to invest billions of dollars a year in their attempts to accomplish the same goal.
@abrugsch
Why is SponsorLink not open-source? And why is it obfuscated?
he has answered this in GH issues raised against SponsorLink and that is that he believes closed source obfuscation is the only way to protect the code from being reverse engineered/blocked/circumvented...
That is truly stunning, makes the problem worse tbh, to think that someone feels the need to obfuscate 'nag' code is truly something to behold.
Assuming I support SponsorLink, is there a solution to use it that does not depend on a GitHub account?
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