So the wave of privacy laws originating in Europe has hit the United States. On June 28, 2018, the California Consumer Privacy Act of 2018 was signed into law (referred to in this post as the “Act” or the “Law”). It is both similar to, and distinct from, the GDPR. Companies should absolutely not assume that if they are GDPR compliant, that they would also compliant with the California law. The California law has broad out of state reach and violations carry serious monetary penalties, including actions from the Attorney General of the State of California, or individuals (either separately or as a class action). Companies should make sure they are out in front of this law. The date the Act is set to take effect is January 1, 2020. Read more
Any company that is subject to the GDPR, among other things, must ensure that it does and can timely comply with requests from any EU data subject with respect to the data subject’s rights under the GDPR, which are:
- Right of access – EU data subjects are entitled to know if their data is being processed and if so the terms of same.
- Right to rectification – EU data subjects have the right to correct information held by any controller.
- Right to erasure – Be ready to completely remove any EU data subject’s personal data from your systems (if anything cannot be removed they need to be told why) upon their request.
- Right to restriction of processing – Be ready to restrict certain EU data subject’s personal data from being processed in any manner in which a specific EU data subject states it no longer consents to (even if he/she provided consent for such processing earlier).
- Right to data portability – Be ready to provide a copy of each EU data subject’s personal data upon their request, and this can include sending it to the data subject or sending it to a third party. Your company should be able to comply with any request within 30 days at no charge to EU user.
- Right to object – Be ready to halt certain activities with respect to the personal data of any EU data subject if notice is provided to you by such EU data subject (this is in addition to the right to restricting processing and prior consent can be modified or taken away at EU data subject’s whim).
The GDPR requires consent as a basis for a company to transfer personal data. Prior to the GDPR, EU Directive 94/46/EC only required “opt out” consent, which could be implicit. The GDPR however, requires that the data subject agree to or make “a statement or clear affirmative action” granting such consent for use or transfer of personal data. Read more
So this is the question that is coming up more and more here in the United States – Does the GDPR apply to our company?
Remember that GDPR was put in place to protect individuals from improper use of their personal data and also to allow them to freely move same, and to enjoy certain other rights with respect to their personal data. While its reach is broad, the GDPR does not apply to processing of data if it falls outside the scope of EU law (processing for public safety, or government issues is not subject to it). If your company interacts with customers within the EU for purposes of trade, and you you store, process or share EU citizen’s personal data then the GDPR rules apply to your company. Read more
At the heart of it, the European Union’s new data privacy legislation, the General Data Protection Regulation (“GDPR”), restricts what the company’s that hold or manipulate personal data of individuals can do with it, and what type of consent is required for what acts. Like all regulations, there are a number of defined terms, which must be understood to grasp the coverage of the GDPR. In summary it covers a lot of activities that companies may not have thought would be regulated. Read more
So if you are a licensee of a software service or product, which you use internally or you sell (sub-license) to end users, you’ll want to be sure that there is no interruption in service for the term of the license provided you pay the license fees. Interruptions in access to the software can come in many forms, sometimes the licensor has issues with the software or its delivery (such as hosting provider’s downtime), and sometimes the licensor is acquired by a larger company that doesn’t pay as much attention to the particular software, or worse, the licensor has financial troubles and either ceases to operate as a going concern or files bankruptcy. You as a licensee, who needs the software to keep your operations steady or to keep your stream of revenue uninterrupted, will want to ensure that there is no break in the access to the software. Read more
We’ll be looking at the typical items addressed in a business to business software license agreement (as compared to an end user license agreement). The purpose of a software license between two companies are generally for the licensor, who has valuable software, to set forth how that software may be used by a licensee and the compensation and other items applicable to the licensee’s use. Read more
New York’s Department of Financial Services passed regulations which apply to virtual currencies, and require licensing of certain entities engaging in certain activities in connection with the state. It is referred to by the State as the “BitLicense”.
The State says that any individual or entity which is involved in the following is required to obtain a BitLicense:
- Virtual currency transmission
- Storing, holding, or maintaining custody or control of virtual currency on behalf of others
- Buying and selling virtual currency as a customer business
- Performing exchange services as a customer business
- Controlling, administering, or issuing a virtual currency.
Ricardian Contracts are really a stepping stone to Smart Contracts. They are a way to link a contract to another system, typically an accounting system. Ian Grigg came up with the Ricardian Contracts some time ago. He first published about it in Financial Cryptography in 7 Layers in 1998. Ricardian Contracts were initially used for Ricardo (hence their name), a bond platform.
They are a melding of a traditional contract with a contract that can be read and executed by machines. A Ricardian Contract can be defined as a single document that:
- is a contract offered by an issuer of some item of value (think of a bond, coin, token, currency, etc.) to a holder of such item;
- for a valuable right held by the holder, to be managed by the issuer;
- can be read in plain language by humans (so like a normal contract);
- can be read by programs (and is parsable like a database);
- digitally signed;
- carries the keys and server information; and
- is allied with a unique and secure identifier.
When dealing with online contracting, blockchain, clickwrap agreements, smart contracts, or just generally these days (and certainly in the future), you will come across the terms “hash” and “encryption.” Especially when discussing digital signatures. We’ll try to distill these a bit for you. These are all regularly used in the transmittal of electronic information and verification of the information, the sender and/or receiver. Read more