Thursday, June 27, 2013

Should the Accredited Investor definition be revised?

As you have all undoubtedly heard or read, yesterday the Supreme Court ruled to invalidate key provisions of the Defense Against Marriage Act (DOMA).

The 1996 DOMA, signed into law by President Clinton, denied federal recognition of same-sex marriages for the purposes of receiving federal benefits, such as Social Security survivor's benefits, insurance benefits, immigration and tax filing. Section 3 of DOMA defined marriage as "a legal union between one man and one woman, as husband and wife" and a spouse was defined as "a person of the opposite sex who is a husband or a wife". The Supreme Court's decision means that now same-sex couples, who are legally married, are entitled to the same benefits as opposite sex married couples.

For some securities attorneys, this raises an interesting question that relates to the definition of an "accredited investor" under Rule 501(a) of the Securities Act. According to the Rule, the definition of an "accredited investor" includes (a) "any natural person whose individual net worth, or join net worth with that person's spouse, exceeds $1,000,000" and (b) "any natural person who had an individual income in excess of $200,000 in each of the two most recent years or joint income with that person's spouse in excess of $300,000 in each of those years and has a reasonable expectation of reaching the same income level in the current year."

Although the term "spouse" is not defined in the Securities Act, it is reasonable to assume, in my opinion, that the definition of a "spouse" also includes a spouse in a same-sex marriage, so long as the couple is legally married.  The definition does not, however, currently extend to domestic partners or partners in a civil union.  Such change, however, is unlikely to come.  Given the delay in the SEC rule-making process (we are still waiting for the final rules regarding the ban on general solicitation and advertising and proposed rules on crowdfunding), expansion of the definition of a "spouse" will hardly be ever viewed as a priority.  

This article is not a legal advice, and was written for general informational purposes only. If you have questions or comments about the article or are interested in learning more about this topic, feel free to contact its author, Arina Shulga. Ms. Shulga is the founder of Shulga Law Firm, P.C., a New York-based boutique law firm specializing in advising individual and corporate clients on aspects of business, corporate, securities, and intellectual property law.

The Tech Contracts Handbook: What You Need to Know about Indemnification and Limitation of Liability in Software Agreements

I recently received my copy of The Tech Contracts Handbook by David W. Tollen and I have to tell you, - I am grateful to have it. The book immediately proved useful, - I was just in the process of revising a master services agreement and looked up the book’s sections on limitations of liability and indemnification exclusions. Below are some highlights.

It is helpful to understand the rationale behind the limitations of liability because at first glance they may appear to be unjustified. After all, why would you agree to limit liability for defective software if you lost millions of dollars as a result of its defects? As Mr. Tollen explains, it is all about scalability. According to him, a $5,000-dollar software may be used to design and operate a much more expensive product (like a multi-billion dollar asset portfolio), and if the software provider were to be held liable for all potential damages on every $5,000 sale, it would not be in business. A single malfunction would bankrupt the entire software company. In fact, there would be no software companies around since such exposure to liability would render this business unprofitable. So, limitations of liability are common in IT contracts. There are two typical limitations: dollar caps and exclusions of consequential damages. Mostly, you will find both. A dollar cap is an arbitrary number (it can be, for example, $5 or $5,000 or the amount of annual license fees the amount payable in the most recent three-month period). This is definitely up for negotiation (unless of course you are dealing with a clickwrap or a shrinkwrap agreement). Exclusion of consequential damages is very standard. Here, the focus is on limiting the type of liability, not the amount, but both clauses overlap. Consequential damages include all damages other than direct costs and can include special, incidental, punitive damages, damages to the reputation, loss of time and business opportunities, etc. Mr. Tollen also includes certain “magic” language that should be part of the liability limitation clause to ensure its enforceability.

However, the limitation of liability in an IT contract has its limits: the parties typically agree that it does not apply to certain sections of the contract, such as indemnification (discussed below). Negotiating these limits can get quite heated. For example, providers of IT services would want limitation of liability to apply to the indemnification clauses as well, whereas the company that is receiving the IT services from the provider would want to ensure that indemnification is excluded, especially when it comes to the obligation to indemnify for IP infringement claims that can cost millions of dollars. The bottom line is: it can get complicated, so there are clear advantages to being represented by an experienced attorney who can competently negotiate this for you.

Mr. Tollen breaks down the hard to follow and dense indemnification section so well that it starts making sense even for non-lawyers. It is actually quite simple: the provider of IT services and/or software promises to protect the client from lawsuits or claims by third parties. The negotiation then centers around what kind of claims should be covered. Claims related to IP infringement (claims saying that provider’s software infringes on someone else’s patent or copyright) most definitely will get covered since they present the biggest risk in IT contracts. Sometimes, the indemnified claims also include personal injury or injury to property (if the provider compromises someone’s data or sexually harasses someone). It is also possible for the provider to get indemnification from the client. Importantly, indemnification by the provider should contain restrictions that say that the provider is off the hook if the claim arose as a result of the client’s violation of the agreement, revisions to the software made without the provider’s consent, or client’s failure to install updates, among others.

The book goes on and on, deciphering for us the complicated IT contracts. The easy to understand language of the book makes it accessible to lawyers and non-lawyers alike. To use a legal term, the book is written in “plain English”. Mr. Tollen also provides access to multiple contract models found on his website, techcontractshandbook.com. What else would you need?? Go, buy the book and get on with the drafting and negotiation of IT contracts.

This article is not a legal advice, and was written for general informational purposes only.  If you have questions or comments about the article or are interested in learning more about this topic, feel free to contact its author, Arina Shulga.  Ms. Shulga is the founder of Shulga Law Firm, P.C., a New York-based boutique law firm specializing in advising individual and corporate clients on aspects of business, corporate, securities, and intellectual property law.

Wednesday, June 26, 2013

New COPPA Rules Take Effect on July 1, 2013

Only four more days are left until the new rules promulgated under the Children’s Online Privacy Protection Act (COPPA) go into effect. I have previously blogged about the amended rules here. The FTC passed the rules in December 2012, making July 1st the effective date. The new rules make it more difficult to collect and share personally identifiable information from children under the age of 13. They require obtaining prior parental consent and expand the definition of what is children's personal information to include photos, videos, recording of a child's voice, geolocation, persistent identifiers, screen name or user name. Mobile apps in particular will come under the FTC scrutiny. In December 2012, the FTC issued its second report on privacy disclosures and practices in mobile apps, where it warned apps developers that it was launching multiple investigations into the mobile app marketplace regarding potential COPPA violations. I discussed the report in greater detail in my previous blog.

So, what should kids' apps developers do to comply with the new COPPA rules? 

1. Educate yourself. Developers should start by reading the FTC Q&A. Also, read this letter sent by the FTC to certain apps developers in May of this year regarding the use of persistent identifiers in the apps and this letter regarding the use of photos, videos and sound recordings of children. Last but not least, read Scott Weiner's notes from the webinar on COPPA compliance which are a great resource for learning about the new rules.

2. Understand the new expanded definition of "personal information". Note in particular that as of July 1, the definition of "personal information" will include persistent identifiers, such as cookies, IP addresses and mobile device IDs, that can recognize users over time and across different websites or online services, as well as kids' videos, photographs and voice recordings.

3. Adopt a privacy policy and make it easily seen and accessible to parents on the app’s store page so that parents can access it prior to purchasing the app.

4. Determine whether the COPPA rules apply to you. This depends on whether you collect children's personal information that you share with third parties. If in doubt, assume that the rules apply.

5. Give notice and get verifiable parental consent before collecting personal information on your applications that you share with third parties. The good news is that no consent is needed if you collect personal information for internal purposes such as maintaining or analyzing the functioning of the application, performing network communications, authenticating users of the app, serving contextual advertising, or conducting other specific activities defined as “support for internal operations”.

6. Take reasonable steps to release children’s personal information only to companies that are capable of keeping it secure and confidential.

7. Learn, understand and implement the new data retention and deletion requirements.

Although time is running out, thankfully there are multiple resources available to the apps developers to help them comply with the new COPPA rules. Remember: if your app is not in compliance by July 1st, it does not mean that you have to pull the app from the market. Simply stop collecting and sharing any children's personal information until you are 100% certain that you are in full compliance with the rule.

This article is not a legal advice, and was written for general informational purposes only. If you have questions or comments about the article or are interested in learning more about this topic, feel free to contact its author, Arina Shulga. Ms. Shulga is the founder of Shulga Law Firm, P.C., a New York-based boutique law firm specializing in advising individual and corporate clients on aspects of business, corporate, securities, and intellectual property law.