Add license acceptance and some explanation on telemetry? #34
Comments
kzu
added
documentation
|
Setting an envvar to disable this is not an acceptable solution. That's opt-out, and EU law is explicit that this has to be opt-in. The licence acceptance check is also not acceptable under EU law, because that will cause dependent libraries to fail if consent is not given. Also, this suffers from the problem that you still think this is somehow a good idea. |
|
Telemetry need to be disabled by default and it should be opt-in. It is also discussed that dotnet telemtry is also against GDPR. Only because other companies are doing this, it is not safe to do this here. Also in dotnet/sdk#8794 (comment) it says, Telemetry in dotnet is now opt in since .NET 7. |
|
As others mention, this is against the GDPR. That is a bigger problem than you think. Particularly problematic is that GDPR States: "For consent to be freely given the individual must have a free choice and must be able to refuse or withdraw consent without being at a disadvantage. " and "it is possible to withdraw consent and that fact is explained (for example an unsubscribe link at the end of an electronic newsletter email)." Here is a list of countries where using this package directly and indirectly without ensuring enformed consent leads to problems, for both the creator of this package and potentially those installing it or updating packages that use it!:
Here are some other countries where you are not allowed to collect mail addresses without informed consent. The total population of these countries combined is over 753 million. This runs afoul of at least 10% of the world population, probably significantly more as most countries require there to be consent on the part of those receiving mails/having their address collected. I request with the upmost urgency that you abandon all automatic and involuntary collection and instead request (through a message in a console?) That people submit the information voluntarily in a manual fashion. If you do not do so, you will by my estimation permanently lose trust and confidence from the community, and me. Furthermore, effective immediately it will not be possible for me to do anything but to cease all use of MoQ which I have used for over 10 years, as the act of willingly using it, or updating it will cause ME PERSONALLY to be responsible for collecting/having collected these mail addresses. I recommend anyone else reading this to take their responsibility as developers serious, before they suffer potential legal consequences. |
Not an expert, but I disagree. If you want to sign up for an email service but don't give consent to processing private data the email service won't sign you up. If you want to use the data for license validation purpose, it's a valid reason for refusing service to someone who disagrees their data to be processed - without the data, we can't validate your license.
While I'm a vocal critic of what happened last week, I personally think the underlying mechanism is definitely a really good idea. |
Cool. Debate club is two doors down on the left. GDPR is no longer new. The law on necessity and consent are now well-established and settled. (Let it never be said that nothing good ever came out of Facebook.) |
|
@cmjdiff nowhere does gdpr state an obligation to provide service without accepting terms and conditions / license. These might require processing personal information necessary to provide the service itself. If license verification is needed, it is a valid case for "free consent" as defined by gdpr, not requiring any extra "checkbox" for you and in such case processing email address is a valid scope of PII. Gender or meal preference wouldn't, email - or other unique ID tying you to the license - is. Gdpr is not just established but often also demonized by those trying to assert wannabe dominance over Americans in internet discussion such as this one. In its nature it's way less evil than it's portrayed to be. |
|
@cmjdiff Btw, technically speaking, in its current implementation the email hash is really used to check whether you provided consent to further process it through other means or not (check the code to see yourself). Can you explain how is that "not acceptable under EU law" in combination with EULA saying "we will check, if you don't like it set environment variable X to Y"? I mean, you clearly feel to be an expert in these things so maybe you can shed some light upon us... |
Spoiler: I am no expert and no lawyer either. But what I have read on this topic of GDPR and my knowledge atm is: You are not allowed to send the hash at all to some server/service before the user consented. So you must ask beforehand and if the user accepts, you are allowed to send the information to the server. I thing your case describes something different. If you need to login to Sponsorlink, you give consent to collect your email just by logging in or registering. If I'm wrong, please correct me. I'm happy if somebody knows better than me. |
Exactly. This is where you accepting the EULA / License that states it comes in - if it says it'll do that and you agree to it you provide the consent. Which you however claimed was not acceptable. The only thing that is up for discussion is what scope of PIIs is essential/required to provide a product or service. A nuget package probably doesn't need to know your gender or age - that would require a separate consent that you could refuse to give and still be entitled to use it, because this data is not required for its functionality. It is reasonable for it to process a unique ID (be it email or whatever else) that ties you to the license of the package, especially if it unlocks features or validates eligibility. In such case the package doesn't need a separate consent to process that unique ID and embedding it in EULA is sufficient - that's the "free consent" concept defined by gdpr. So: the original state where the email was processed (though in pretty innocent way) was highly debatable and probably not compliant with gdpr. Adding the consent to the license solves the issue. |
|
@psimsa Can you just stop substituting your legal fanfic for actual established and settled law? SponsorLink would need consent, and blocking access to the underlying library would be forced consent. Necessity is not applicable. End of story. |
|
How is it established when the documentation from EC says otherwise? Reference please. |
|
Sorry, the full explanation is a sponsor-exclusive feature. But the short version is that the document doesn't say what you think it says. |
|
Very creative way of getting out of responding, kudos. |
|
This is OSS, remember? I don't owe you anything. The full explanation took time (and therefore money) to create. It's been explained multiple times in multiple threads why you need consent, and why the contract necessity grounds wouldn't apply. If you want to ignore those and just continue writing legal fanfic, that's on you. Saying "what about email providers" and "what about airlines" doesn't change the law, and the law is clear. In the case of forced consent, it's literally there in GDPR itself in black and white. |
|
"Random guy somewhere on the internet said something else that better suits my beliefs so clearly you're wrong." But if it helps you sleep at night, whatever. I got better things to do than argue with someone on the internet whose argument is based on "other people somewhere else said." |
Yes, that's precisely what you're doing. I'm glad we've got to being honest at least. The facts and law are clear: SponsorLink needs explicit consent at both ends. You can't bundle it into the licence agreement if it causes the dependent library to fail. End of story. The document you found doesn't support your argument to the contrary. |
|
No telemetry will be further collected (for now? ever?). I've raised the issue of more relevant and accurate usage information from NuGet/VS itself with the MS folks (i.e. ACTIVE users' is FAR more useful than generic "downloads" which nobody knows how they are calculated). So for now, I'll remove this entirely. Sponsorship checking is another matter altogether. This issue was specific for telemetry. So, no longer relevant. |
As a side-effect of the querying for the sponsorship, we do get to know who's using a package (however imperfectly anonymized due to #31). Down the road, I don't think more properly anonymized telemetry is a bad thing in itself.
Just like dotnet where you have to manually set an envvar to disable this, we could either honor that flag or add our own, but otherwise, default telemetry collection is a valuable feature that SponsorLink can also offer to library authors.
The text was updated successfully, but these errors were encountered: