Understanding electronic mail marketing under the UK&#39;s Privacy and Electronic Communications Regulations (PECR) From ICO's guide for electronic mail marketing under PECR: ... you must not send electronic mail marketing to individuals, unless: they have specifically consented to electronic mail from you; or they are an existing customer who bought (or negotiated to buy) a similar product or service from you in the past, and you gave them a simple way to opt out both when you first collected their details and in every message you have sent. Doesn't this clip entrepreneurs' wings? It looks like the effect of this regulation is to prohibit entrepreneurs from marketing their service or product via cold emailing (or any other types of electronic messages, for that matter). I find this greatly confusing. How can a new business (especially a tech business) find its first few customers if not by cold texting in some way or another? Does PECR force new businesses to market themselves strictly in the public domain, e.g. on social media?
How can a new business (especially a tech business) find its first few customers if not by cold texting in some way or another? Don’t know, don’t care. This is Law SE, not Marketing SE. Does PECR force new businesses to market themselves strictly in the public domain, e.g. on social media? Not at all. It prevents spam and is in line with similar laws in most of the World. You can call or SMS people (unless they are in a do not call list), use conventional marketing like radio, TV, direct post but you cannot send spam email.
The second paragraph is an invitation for people who don't want to follow the terms of the GPL (e.g. who want to incorporate it into a larger closed-source work, or make closed-source modifications) to contact XXX for a less onerous (but more expensive) license. That would require that XXX have full rights to the software, that they did not for instance incorporate others' GPLed code. It would be a stretch to read the second paragraph as attempting to limit the first paragraph, particularly given the &quot;please&quot;.
Does Amazon prohibit a family of adults from sharing a single Amazon account? No, or at least it seems unlikely. As outlined in my answer &amp; comments on Law Meta, a domestic or family-oriented character is palpable in the clause. That weakens the notion that Amazon's intent is to preclude scenarios which are of a personal-domestic nature and short of commercial/sublicensed use. The language &quot;You are responsible for [...] restricting access to your account&quot; seems more permissive than something akin to &quot;only you are allowed to access your account&quot;. The former language is consistent with the term &quot;non-exclusive&quot;, which otherwise seems to have no relevance or purpose in the clause. Users' ability (if any) to enter multiple payment methods with different names (i.e., card holder name) could be an additional indication that the scenario you have in mind is acceptable to Amazon. It is easy for a company to implement a validation for the purpose of identifying significant discrepancies of holder names and/or to have the user confirm that all payment methods refer to one same owner. The latter approach is more conclusive for scenarios where a woman has changed names as a result of getting married or divorced. The fact (?) that Amazon declined to include that simple validation weakens the notion that the company is genuinely interested in sticking to a rule of one-person per account.
If the website containing the GDPR-wall processes any personal data of users who hit the GDPR-wall, the GDPR applies to that website. This can be as simple as writing a logfile of all visits to the website. In this case it will be illegal if the website owner does not comply with the GDPR. However a supervisory authority would probably not spent any time on such a minor violation. As long as the the website with the GDPR-wall does not process any personal data, the GDPR does not apply, so nothing in the GDPR can forbid the GDPR-wall. Some related remarks: The GDPR does not require a "privacy policy" on the website if the website does not process any personal data. If personal data is processed based on consent, that consent must be freely given. Also it may not be disruptive. So a cookie wall asking for consent would be illegal. But the GDPR does not care about any other disruptive popups, as long as they are not related to asking for consent. Using GeoIP is a perfect way to implement such a GDPR-Wall, because it would block everyone from within the EU, but nobody else. So it blocks exactly those for who the GDPR would apply. In such a case it would not be reasonable to expect anything more from a website owner. A user which uses a proxy, can not expect to be protected by the GDPR, because it bypasses a restriction set by the owner of the website. A webserver does use the IP-address of all incoming requests, to send the reply back. That could be considered a processing of personal data, but everybody seems to agree it is not. I am not sure why. But I do agree that it would be very impractical if that is considered processing of personal data. I added an example from the Washington Post So you have to pay $9/month for a GDPR compliant subscription. Because the price you have to pay is not unacceptable high, I think it would be valid to offer the premium version this way. This does not force you to choose one of the other subscriptions. In december 2018, the Austrian DPA (DSB) has confirmed that a similar offer is lawful. On derstandard.at you get a choice between free access with tracking and advertising, or pay 6 Euro/Month for tracking free access. Because 6 Euro/Month is cheaper than subscribing to the printed edition, the DSB accepted that as a valid choice. More information can be found on noyb.eu or, (with more details but in German), on wbs-law.de.
In the general case, it seems unlikely, based on the wording (which is convoluted). In certain cases, if the president of Russia posts "My name is Vladimir Putin", that post is personal data. On the other hand, you might, based on my writing, conclude that I am from the US, and you might even conclude that I'm in Washington state, but that doesn't distinguish me from 7.5 million others, so on those grounds that is not personal data. Eventually, though, you might identify me specifically from other things that I may have said on SE. The definition depends on two parts. First, personal data is "information relating to an identified or identifiable natural person". Any "information" provided by a natural person is "related to" that person (as is any "information" that is about such a person). The second part defines "identifiable natural person", that is, who is an "identifiable person"? Every person can, in principle, be identified by reference to some label or description of fact about them, so every person is an identifiable person, under this definition. This means that every piece of text that refers to an individual (not even text which can identify the person) is "personal data". Obviously, any individual can be uniquely identified by some collection of identifiers; the problem is that the wording of the law does not explicitly say "using that supposed personal data". If I mention that I have a relative named Knudt, that would technically be personal data: I've given information that relates to a person, though you have no idea (and could not possibly figure out) who that person is. Another term that the regulation defines and uses in a few places is "pseudonymization", which is defined as the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person The point of interest here is that this says that "personal data" which cannot be attributed to an individual is, nevertheless, still personal data. I think the most important part of the regulation is art. 6, which defines lawfulness of processing, especially para 4., which allows consideration to be given to safeguards such as pseudonymization.
There is nothing illegal with doing this (absent specific contractual terms or industry regulations to the contrary in particular cases, e.g. in the case of export controlled high technology products). This is called operating a wholesale business or operating as a broker. Lots of legitimate legal businesses have this business model.
What Big Tech is doing is spending a lot of money on lawyers and appeals – doesn't matter if it costs millions if you can make money in the meanwhile. Facebook stores a lot of user data in the US. Initially, this was allowed because the US was recognized as offering an adequate level of data protection under the Safe Harbor and later the Privacy Shield Framework. Then Schrems I and Schrems II happened and the adequacy recognition was ruled to be invalid. Does Facebook pull back their user data? No. The GDPR offers alternative reasons why you might process data in foreign countries, such as “standard contractual clauses” (SCCs) or “binding corporate rules” (BCRs). Now, Facebook claims that they are using SCCs. Is this valid? Almost certainly not due to the issues of US law analyzed in the Schrems II case, but it can take years for the next round of court cases to work its way through the system. And when Facebook's use of SCCs is ruled invalid they will probably try BCRs next, and once that is over a decade will have passed and the US might actually have achieved an adequate privacy level by then. You do not have Facebook-style money to spend on lawyers and endless rounds of appeals, so you should avoid legally risky things such as outsourcing data processing activities to companies in the US (this doesn't mean you can't be compliant if you are a US entity). I mentioned adequacy decision previously. There is a list of countries that the EU considers to be sufficiently safe. Currently, the more notable countries involve Canada, Israel, Japan, New Zealand, Republic of Korea, Switzerland, and the United Kingdom, in addition to EU/EEA countries of course. If you want to process data in a location that is OK for both the UK and the US, then looking at companies in one of these countries is a good idea. For example, if most of your users are in the US but you would like your servers to be in a country with an EU adequacy decision, then looking at Canada could make sense. Even outside of this list, you can process data if you implement additional safeguards via SCCs. However, this requires a case by case analysis of the legal environment in that country. One problem with the US is that it has national security laws that impose requirements on companies in a manner that is incompatible with SCCs. A company bound by these US laws cannot enter into such a contract where it guarantees the privacy of your user's data. Countries other than the EU have much more tedious data residency laws. The GDPR does not impose any data residency requirements in the sense that data must not leave a particular country – you just have to ensure that the data is properly protected. In contrast, Russia and China have real data residency requirements that are fundamentally incompatible with the GDPR.
Building off @DigitalFire's answer, I looked into the TOS related requirements that Google Analytics puts out and I found this on Google Analytic's TOS: You will have and abide by an appropriate privacy policy and will comply with all applicable laws relating to the collection of information from visitors to Your websites. You must post a privacy policy and that policy must provide notice of your use of a cookie that collects anonymous traffic data. Apparently, Google themselves also requires you to notify users when you are using their service to track people (That's pretty good of Google). Here is a simple example of what a privacy policy would look like. There doesn't appear to be any issues with laws in other countries either. For my purposes, I'll just implement an agreement that pops up during installation that users will have to accept.