Monday, March 13, 2017

SaaS Contracts vs Software License Agreements

Just like technology itself, technology contracts are becoming more and more complex.  Yet, the legal theories that apply to them remain the same. Understanding the technological aspects of the transaction allows attorneys to apply correct legal terms.  Here is an example that I have encountered in my practice.

Software license agreements are used when a proprietary software is being licensed by the licensor to a licensee.  The licensor has an interest in copyrights, patents, trade secrets and other IP rights in the software and related documentation.  A license is a limited grant of those rights.  A software license can be exclusive or non-exclusive, may be limited to a specific geographic territory, with or without a right to sublicense and transfer, with or without a right to make and store copies, and with a limited scope of access and use.  All this assumes that the software needs to be downloaded or installed on the licensee's platform/network/computer.

A traditional software license described above does not apply to software-as-a-service (SaaS) contracts because the customer does not download or install copies of the software.  The customer remotely logs into the vendor's system to access and use the software, usually through the Internet.  The vendor (or its provider) hosts the software either on its server or in the cloud.  So, essentially the vendor provides a service to the customer, which consists of hosting its software and performing services to support the hosted software and granting access to the hosted software.  This is the reason why SaaS contracts do not typically have a license grant, but talk about authorization to access.  There is very limited, if any, customer customization because the software configuration is mostly uniform throughout the vendor's customer base.  Maintenance and service of the software become very important.  Typically, there are multiple service levels that are carefully negotiated.  Fees are based either on a subscription model or the volume of customer's use.  

So, why would a SaaS vendor prefer to grant a license rather than an authorization to access the SaaS services?  One reason is because in the case there is unauthorized access or use of the SaaS services, the vendors will not be able to claim an IP infringement unless there was a previous license grant.  It could still have a claim for theft of service, trespass to chattels, or a violation of the Computer Fraud and Abuse Act, but not an IP infringement.

However, a grant of an IP license creates an additional risk which probably outweighs the point I just made.  In the case of bankruptcy, the vendor may stop performing its contractual obligations, including SaaS services.  However, the Bankruptcy Court may compel the vendor to keep on performing the services if they are provided under an IP license because Section 365(n) of the Bankruptcy Code protects the right to continue to use "licensed intellectual property" but not the services.  The customer could also get a copy of the software's code and self-host it.

Now, let's complicate things a bit.  If the customer hosts the software (as opposed to the vendor or a third-party provider), the customer would need a software license (not an authorization) because it would need to make copies of the software.

As you can see, the only way to draft a correct agreement is to understand the technological aspects of the deal.

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 corporate, securities, and intellectual property law.

Saturday, March 11, 2017

Deconstructing Open Source Software Licenses

When drafting and negotiating software license agreements, I frequently come across open source licenses.  This blog post is to clarify some of the myths that exist around the definition and use of open source software.

First, I want to distinguish open source software from software that is in public domain.  Public domain software is absolutely without any copyright or other intellectual property restrictions.  Anyone can modify it, distribute it, and use as they see fit.  Open source software, on the other hand, is licensed.  It may, but doesn't have to be free. Typically, licensors of open source software charge for providing support, consulting, and other professional services in connection with their open source software.  They cannot charge royalty for the source code itself or the right to modify and redistribute it.

Next, let's investigate the reasons for licensing software under one of the open source licenses.  The main reason for opting to license software under an open source license is the opportunity to get the software noticed, used, improved, and revised by developers anywhere on a continuous basis.  The result is software of high quality that is free of bugs, frequently used, and is current.  Of course, it comes at a price. Since developers can download, modify and redistribute open source software, licensor of such software is unlikely to get rich of the software license fees.  It needs to be able to provide support, consulting, maintenance and other related services to compensate for the loss in license royalties.

And now let's zero in on the terms of the open source software licenses.  They generally fall under two categories: copyleft (restrictive) and permissive.  The existence of copyleft open source licenses is probably the main reason why software developers are suspicious of open source software in general and may be reluctant to use it in their own software.  A copyleft license requires all software recipients to redistribute it under an open source license.  So, if a developer incorporates a part of copyleft open source software into its own larger software program or creates a derivative work based on it, then the entire program or derivative work would have to be distributed under an open source license (i.e., a copyleft open source license "infects" the entire work).  This is the reason why, when negotiating software license agreements on behalf of a licensee that has the right to create derivate works and redistribute the software, it is important to understand whether the licensor has used any open source software and if yes, then under which license.  It is then a good idea to ask for a warranty from the licensor that it has not used any copyleft open source software and for indemnification.  On the other hand, if licensee does not intend to redistribute the software but only intends to use it, then having a copyleft open source software should not be a big concern.

The best-known copyleft license is the GNU General Public License (the "GPL"), provided by the Free Software Foundation.  The current version 3 is available here.  The key terms are in Sections 2, 4-6, and 10.  Version 2 is still widely used (actually more so than the recent version 3).  The key provision in Version 2 is Section 2(b) that says:
"2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work… provided that you also meet all of these conditions:....
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this license."
Other copyleft licenses include GNU Lesser General Public License (LGPL) versions 2.1 and 3.0, GNU Affero General Public License, Artistic License (Pearl), Mozilla Public License (MPL) 1.1 (requires modified versions of the software to be distributed using open source model but doesn't apply to all derivative works, just to the modifications of original code), and Eclipse Public License (EPL).

Overall, according to an open source software provider Black Duck, the use of copyleft or restrictive licenses is declining.  In 2010, about two-thirds of open source software was under copyleft licenses.  In 2017, no more than 37% of open source software use was under copyleft licenses, with GPL version 2 use declining from 48.5% in 2010 to only 18% in 2017.    

Permissive open source licenses let the licensee include open source software into their larger program and then distribute the program under any license it wants.  Most frequently used permissive open source licenses are Apache License 2.0, and Open Source Initiative's MIT License and BSD 2.0.  Sections 2 and 4 of the Apache license allow licensee to reproduce, prepare derivative works of, publicly display, perform, sublicense, and distribute the open source software so long as a copy of the Apache license and certain notices are included.  The licensee may provide additional or different license terms governing the use, reproduction or distribution of any derivative works, provided it continues to comply with the Apache license.  Apache license is the preferred open source license for Android.  The MIT and BSD licenses are probably the least restrictive of all open source licenses because they do not have any IP-specific restriction on redistribution of software.  

According to Black Duck Software, the use of Apache license rose from 4% in 2010 to 14% in 2017.  The use of the MIT license rose from 4% to 32% in 2017, while the use of the BSD license remained at approximately 6% during the same period of time. Currently, MIT license is ranked as #1 open source software license in use.

In conclusion, it is important for software developers and their attorneys to understand the different open source licenses.  Using open source software is beneficial to all, but the license for it needs to correspond to the intended use of the software in the hands of the licensee.

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 corporate, securities, and intellectual property law.


Monday, February 6, 2017

Are Terms of Use and Other Online Agreements Real and Binding Contracts?

It used to be that people would enter into binding agreements by manually signing them. A signature manifested the two required aspects of forming a binding contract: a notice and an assent, i.e., the signatory has read the agreement and agrees to its terms.  No matter that the signatory didn't really understand what he or she has read: the signature created a presumption that the person read the terms and agreed to them.

The Internet, of course, changed all that by enabling people to enter into agreements online, without the use of signatures to show notice and assent.  So, are the online agreements really binding and enforceable?

Types of Online Agreements

First, let's take a look at some types of agreements that do not require a signature.

You have probably heard about a shrinkwrap agreement.  It is a printed form that typically appears on the outside of a box containing software.  Opening the box typically means that you have agreed to the terms of the agreement.  You don't really have ways to negotiate it, but you should be able to return the software if you disagree with the terms and have not yet opened the box.  Sometimes, the software provider cannot fit all of the terms on the outside of the package.  Then, opening the package does not mean that you consent to the terms, but installing the software does.

An online version of a shrinkwrap agreement is a clickwrap agreement.  It is an online contract that typically requires the user to click the "I Agree" button to show consent with the terms of the agreement.  The user cannot download the app or install the software until he or she clicks the "I Agree" button.  Some agreements require the user to scroll down to the end of the agreement before they can click the "I Agree" button.  These are sometimes referred to as scrollwrap agreements and are a subset of clickwrap agreements.

Some internet contracts do not require the user to click the "I Agree" button to show acceptance.  The users are notified of the existence of these contracts and the applicability of the website's terms of use when they proceed through the website's sign-in or login process.  These contracts are referred to as sign-in-wrap contracts.

Online agreements that do not have the "I Agree" button are called browsewrap agreements.  A good example of a browsewrap agreement is a website terms of use or privacy policy.  It typically begins with something like this:

This Terms of Use (together with our Privacy Policy, incorporated herein by reference, the “Agreement”) is a legal agreement between you and [ ] (“[ ]” or “we”). By accessing our website [ ].com (the “Site”), you agree to comply with and be legally bound by the Agreement. If you do not agree, please do not access our Site.      
Users do not have to take any affirmative steps to show their acceptance of a browsewrap agreement.  They give assent by simply continuing to use the site.   However, it is much more difficult to prove notice and assent in a browsewrap agreements because users of a website might not notice the terms of use policy that is hidden in the bottom of the screen.  For this reason, courts have not always deemed them to be enforceable.

A hybrid version of a clickwrap and a browsewrap agreement may be used by some websites if they have two types of users: those who use the information on the website without creating an account, and those who create an account to access enhanced features.  So, a clickwrap terms of use would be used for those creating an account (by asking to click "I Agree" button before the users can create it) and also placing the browsewarp version of same terms of use on the website for those users who chose not to create accounts.

Enforceability of Online Agreements

Now, let's discuss some of the legal issues involved with the enforceability of browsewrap and clickwrap agreements.  As I mentioned before, the two things that courts look at are (i) whether the user had sufficient notice of the terms and (ii) whether the user really consented to these terms.

Clickwrap agreements.  The main problem here revolves around the consent requirement.  Recently, courts have been paying particular attention to the potential of altering terms in the clickwrap contracts.  So, be ready that the court may ask to prove that the user clicked "I Agree" button to a particular version of the agreement or terms of use.  To avoid any problems, companies need to keep records of all versions of their online policies or agreements and be able to prove when each user actually consented to the terms.  The best way would be to have the users consent again after each modification of the agreement.   Recent cases about clickwrap contracts include Dillon v. BMO Harris Bank, N.A., 2016 WL 117513  (M.D.N.C. Mar. 23, 2016)Handy v. LogMeIn, Inc., 2015 WL 4508669 (E.D. Cal. July 24, 2015); Resorb Networks, Inc. v., 30 N.Y.S.3d 506 (Sup. Ct. 2016) and Berkson v. Gogo LLC, 97 F. Supp. 3d 359 (E.D.N.Y. 2015).

Browsewrap agreements.  Enforceability of browsewrap agreements is much more difficult to establish because they don't require any particular action on the part of the user to manifest assent.  So, here the courts have been battling with both issues of whether the users were put on sufficient notice of the terms and whether they actually agreed to them.  Because of the passive nature of "assent", courts focus on the circumstances of customers' use and the question of whether the user had actual or constructive knowledge of the website's policies.  The Court in Nguyen v. Barnes & Noble Inc., 763 F.3d 1171 (9th Cir. 2014) said "Whether a user has inquiry notice of a browsewrap agreement, in turn, depends on the design and content of the website and the agreement’s webpage."  In the past, browsewrap contracts have not been enforced where the link to them was buried at the bottom of the page, or put somewhere in a corner where it was hard to find, or was visible only if you had to scroll down to the next screen, or could access it only after a multi-step process of clicking though non-obvious links.  On the other hand, courts liked websites that had "explicit textual notice that continued use will act as a manifestation of the user's intent to be bound" by the online agreements".

Sign-in-wrap agreements.  These contracts will generally be held enforceable so long as the users have clear unambiguous notice of the terms and an effective opportunity to access those terms at the time they are signing in / logging into the site.

Practical Steps

To summarize, below is my list of recommendations regarding online contracts:

1.  It is best to use clickwrap / scrollwrap / sign-in-wrap agreements rather than browsewrap ones.  This means adding an "I agree" or "I accept" button.

2.  Have users agree to any change to your online policies when they next log in / sign into your website.  For browsewrap version, clearly state in bold on the first page the date when the agreement was last modified.

3.  A hyperlink to the terms of use and other policies should be in large font, all caps or in bold (i.e., not hidden, clearly visible).

4.  A hyperlink to the policies should appear on every page of the website.  As the court in Berkson v. Gogo said, it should not be "buried at the bottom of a webpage or tucked away in obscure corners of the website."

5.  The online policies should be easy to download and print.

6.  It is a good idea to have the users scroll through the agreement before accepting it.

7.  A website with a browsewrap terms of use should have a conspicuous notice appearing on every screen that by using this site, user agrees to the site's term of use.

8.  For clickwrap contracts, - keep records of all versions of the online agreements and policies, and know when each user consented and to which version.  It is best to ask users to consent to each modification of the policies.

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 corporate, securities, and intellectual property law.