On what grounds can a government delegalise the use of specific software and is that compliant with international laws? As I read in the "Government use" section in the VPN blocking article on Wikipedia. It seems that Iran and China (used to) block access to use VPN software. I'd like to widen the scope of the question and apply it on any type of software, not specifically VPN or encryption software. On what grounds can a government delegalise the use of specific software? And is delegalization of (specific) software compliant with international laws (human rights)?
Governments have power to do whatever their constitutions (written or unwritten) allow them to do. For example, the constitution of Australia provides: The federal Parliament can make laws only on certain matters. These include: ... post and telecommunications; ... The telecommunications power covers VPN and any software that uses the Internet for delivery or communication (i.e. virtually all modern software). In addition the federal government has power over inter-state and international trade (any software that crosses state or international borders) and corporations (any software made, sold or used by companies). If they want to ban a piece of software they have pretty strong constitutional power to do so.
As you, the data controller, are from the EU, all your processing activities must comply with the GDPR, regardless of where the users are from. Since the EU–US Privacy Shield was invalidated in the 2020 Schrems II decision, it is no longer straightforward to use US-based services as your data processors. You have a variety of options to consider. Accept the ~77ms latency from an EU data center. This is the easiest solution from a compliance perspective. Depending on the application, this really might not be a problem. Use services based in a nearby country that is covered by an EU adequacy decision, such as Canada. E.g. the AWS Canada-Central region near Montreal is about 10ms away from NYC. Digital Ocean's Toronto region is about 20ms away. I would choose this approach if you're very concerned about latency and want GDPR compliance with reasonable effort. Handle non-EU data processing activities through a non-EU subsidiary entity. However, that entity would have to actually determine the purposes and means of processing. Setting up a non-EU office with non-EU staff would be costly. You couldn't work remotely for that entity from within the EU without defeating its purpose. Sign standard contractual clauses (SCCs) that serve as a legal basis for data processing activities in the US, after performing an analysis that indicates that the specific concerns as in the Schrems II case do not apply in your case, and potentially after identifying and implementing measures such as end-to-end encryption as explained by the EDPB Recommendations 01/2020 on supplementary transfer measures. Most companies end up relying on SCCs, since otherwise the use of US-based services is impossible. But it's doubtful whether the necessary analysis has been properly performed. The supplementary measures suggested by the EDPB are sometimes feasible in specific use cases (e.g. encrypted backups), but are generally impossible to fulfill for typical cloud services. So even though this is a popular option, it comes with substantial risk for your compliance efforts.
It really depends on what "services" you are providing, but generally speaking you would be in violation of the Department of Treasury, Office of Foreign Assets Control (OFAC). These regulations are spelled out in 31 CFR §560.205 and 560.420 and apply to US citizens and residents wherever located. Specifically, the action that is prohibited is the "exportation, reexportation, sale or supply of goods, technology, or services to Iran. Here "Services" is broadly construed to mean anything of value even if no money is exchanged, including providing technical assistance to an Iranian national or Iranian institution. See See § 560.204; §560.410. The civil penalty for violation of these sanctions would be $250,000 or an amount "equal to twice the amount that is the basis of the violation". Criminal penalties may include fines up to $1 million and 20 years in prison. Now there are some exempt transactions outlined by § 560.210 (c) which may be applicable here, however it would be up to you to prove that these are "information or informational materials" as defined by § 560.315. For more information, 31 CFR Part 560, Subpart B refers to the prohibited transactions with Iran. Since you are not specifically spelling out what services you intend to provide, it is difficult to say for sure you would be in violation of them. It should be noted though that the US Government uses publicly funded money to run a proxy server through which Iranians can access otherwise blocked websites such as social media in Iran.
You seem to have a solid understanding of the ePrivacy implications, but lack a fundamental insight: your organization does not have a right to achieve its mission or a right to disseminate unwanted marketing. But other people do have a right to not be subject to excessive marketing. Of course, reality is more complex, so it's probably not entirely impossible to do marketing. In your point 1, you note that some EU/EEA/UK countries distinguish ePrivacy protections between consumer and business subscribers. You can research the exact rules in the potential customer's country. This may allow you to email corporate/business accounts. I would strongly advise against messaging via Linkedin if there is a chance that the person is using that account for personal purposes like networking or hunting jobs, not just for conducting official company business. ePrivacy has markedly different rules for email marketing vs phone marketing. Whereas there are pretty strict rules for electronic messages and robocalls, manual cold calling can be OK from an ePrivacy perspective. However, many EU/EEA/UK countries have rules that go beyond ePrivacy, and may have a kind of do-not-call registry that you must respect. Of course manual calls take more effort than spamming emails, but recall the above point that you don't have a right to spam other people. Phone calls are probably the most appropriate approach when the company lists individuals' phone numbers on its website. This will at least give you a few seconds of attention with a real human, more than you can expect from an email that is likely to be caught by spam filters. Marketing via physical mail tends to have very lax rules. Note that every company/business that has a website will have to disclose its contact details including an address there, so this information is easy to acquire. However, chances are low that anyone would seriously engage with that marketing. You can consider alternatives to direct marketing, so that interested companies eventually come to you. Things like press releases, writing guest articles in industry publications, speaking at relevant conferences, working on search engine optimization, buying ads. On the GPDR aspects: GDPR and ePrivacy overlap, and it is necessary to comply with both sets of rules (GDPR likely applies here via Art 3(2)(a)). But where they potentially contradict each other, ePrivacy as the more specific law has precedence. For example, ePrivacy overrides the default GDPR legal basis rules when it comes to email marketing to existing customers (opt-out basis, no consent needed) or to using cookies (needs consent unless strictly necessary). Information that relates to corporations is not personal data, but information that relates to individual employees or to sole proprietors would typically be personal data. Since you are unlikely to obtain consent for using this data, you would need an alternative GDPR legal basis such as a &quot;legitimate interest&quot;. Relying on a legitimate interest requires that you conduct a balancing test, weighing your interests like marketing against the recipient's interests, rights, and freedoms. Core question in this context is whether the data subject can reasonably expect their personal data to be used like this, taking into account the nature of their relationship with you. Since there is no pre-existing relationship, claims of a legitimate interest are weak to start with. However, it may be possible to argue that when a company makes employee contact details available via its website (not LinkedIn!) then relevant marketing can be reasonably expected. I would rather not rely on such arguments, though.
No Governments have sovereign power. Subject to constitutional and legislative constraints, governments can change laws as they wish. That includes legislative changes and administrative policies. Most governments tend not to use this power arbitrarily because it tends to make investors wary - economists call this sovereign risk. Like any other risk, the higher it is, the greater return an investor expects - countries with high sovereign risk get less foreign investment and pay more for it. Further, most governments don’t make laws that are retrospective but unless there is a constitutional prohibition (like there is in the United States, for example), they can. So Ireland could not only change the rules going forward, they could change the rules that applied in the past (assuming the Irish constitution doesn’t prohibit this, which I don’t know enough about). If Ireland were to change this law, it’s likely there would be plenty of forward notice. The arrangement you spell out between mother and son is not enforceable unless it’s a contract and the presumption is that such familial agreements are not contracts. Such a presumption can be overcome by an explicit declaration by the mother and the son that they intend for it to be legally binding, preferably in writing. Now, governments can and do enter contracts which are enforceable by the courts but that is a one-on-one relationship between a government and a contractor; not a decree that must be followed by everyone. Unless, of course, they are the sort of government that doesn’t follow their own laws - I’m sure you can think of some - but they are huge sovereign risk.
An EULA, or "End User License Agreement", is a contract between the software user and the software publisher. It usually protects the interest of the software publisher, e.g. you can only use it on one computer; you may not alter it or distribute it without written agreement etc. In this case, the EULA specifies that: The software may be harmful to the user's computer The user's personal data may be sent to third parties The software may used to aid or perform illegal activities The software publisher is not responsible for any damage caused by using this software First thing first, is this a valid contract? Let's take a look at the essential elements of a contract: Offer and Acceptance Intention Consideration Capacity Consent Legality Possibility of performance The Legality element specifies that the contract must not be something disapproved by law. Botnets are used for attacking other computers, i.e. an unlawful act. Installing botnets may violate the Section 3A of the Computer Misuse Act 1990 in the UK. Sharing user's personal data may also violate data privacy laws. Let us, for the moment, assume the contract is valid. Item number 4 still causes a problem: an overly broad liability waiver. While liability waivers are common and normal, one can argue that the said waiver in this case seems to cover intentional or reckless acts. Such items in a contract are deemed as unenforceable. Parental control systems and remote observation systems are different. They can be used legally, and this legal use is common. Thus, distribution of these systems is legal. Needless to say, it is very difficult to argue that virus and botnets share the same. Of course, one can still use a remote observation system in an illegal way. In this case, the software user is liable, but the software publisher is not liable because the user's behavior is beyond their control.
IANAL, just a programmer with an interest in legal rules. Due to the very permissive nature of the MIT license, no, it does not appear that anything illegal has been done. Specifically, the section to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software (emphasis mine) grants everyone the right to modify your code and share those modifications, provided one includes the license. Since this person has included your license (including your copyright notice), they have followed the conditions of the license and are able to share your stuff. Legally. Ethically, I still think its ****. This might be a good starting point in selecting a license (note the Modification column). https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses The CC-BY-SA license family, as mentioned by Ron Beyer in comments is on this list, for example. TL;DR: You unfortunately granted a more permissive license than what you wanted/needed to. This was a BadThing(TM), analogous to giving too broad of access rights to a method or class. Determine your desired permissions, then select a license that matches what you'd like to grant.
This is a super complex question and no one really knows the answer yet. Orin Kerr is probably the leading scholar on this question, and he generally argues that forced decryption of one's own device is not a Fifth Amendment violation. As I understand it (and oversimplifying by a lot), one key piece of his position is that requiring you to put in your password is a statement about your knowledge of the password itself, not about the contents of the machine into which you are entering it. And because your knowledge of the password for your own devices is presumed, an exception for "foregone conclusions" would leave this compulsion unprotected by the Fifth Amendment. You can read one of his explanations here. The Eleventh Circuit disagreed with that approach, but a California judge recently reached a conclusion similar to Kerr's. This will probably by a question for SCOTUS before too long.