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.