Sunday, September 17, 2017

Why Small Businesses Need Buy-Sell Agreements

One of the agreements that comes up time over time in my practice is a buy-sell agreement.  These are contracts between shareholders of a corporation, partners of a partnership or members of a limited liability company and the business entity itself (although, as you will see, this is optional).  The buy-sell agreements ensure that the business interest of either deceased, disabled or departing owner is transferred to the entity or the co-owner(s) according to the predetermined and agreed upon guidelines.

Why Do You Need a Buy-Sell Agreement

In the absence of a buy-sell agreement in the case of death, the decedent's business interest will pass by the terms of his or her will or the laws of intestacy. This means that the remaining owner could become business partners with people who have little or no interest in running the business or the necessary skills to do so.  Alternatively, the heirs could sell the decedent's interest in the company to an unknown outside buyer who may not unfriendly to the remaining owner.  A buy-sell ensures business continuity while providing the needed cash to the deceased partner's family to handle estate tax and funeral expenses.

A buy-sell agreement can also resolve issues surrounding a business owner's disability.  Imagine a business owner who is critical to the business' operations but becomes disabled.  This could potentially be devastating for the business.  The remaining owner would be left alone to handle business operations while trying to figure out for how long to pay the disabled partner and from what source.  The disabled partner may want to be bought out, or his or her spouse and children may want to step in to run the business instead.  The disability buy-sell addresses the issue of the purchase of the disabled owner's interest, continued salary payments and management continuity.

Buy-sell agreements are also used in the cases of:
  • termination for cause (such as when the owner stops performing his or her duties or becomes convicted of a crime)
  • personal bankruptcy 
  • divorce
  • voluntary retirement
  • loss of professional license.
Funding Buy-Sell Agreements

There are four different ways to fund a buy-sell.

One way is to put aside cash from earnings and create a savings plan, often referred to as the sinking fund.  The danger here is that the fund could get diverted to pay for urgent business-related expenses, leaving the buy-sell underfunded.

Another way is to borrow the money.  However, not all businesses can obtain good terms on a loan.  Also, loan repayment would decrease the company's cash flow and impact credit availability.

The third way is to pay the buyout price over an installment period that is agreed to ahead of time in the buy-sell agreement.  Here, it is the departing owner who faces most of the risk.  He or she risks not getting the full buyout price if the business fails, since the ability to grow the business is now in the hands of the remaining partner(s).

The fourth and final way is to buy life or disability insurance on the lives of the owners.  A permanent insurance policy can also be used for retirement buyouts. However, insurance is not available for all types of buyout scenarios outlined above.  So, some combination of the payment methods is needed to fund a  comprehensive buy-sell agreement.

Entity or Cross-Purchase Buy-Sell

One last thing that I'd like to mention is that sometimes it makes more sense for the owners to buy insurance on each other (a cross-purchase arrangement) than for the company to do so (stock redemption).  In such cases, the company itself is not a party to the agreement.  Each individual partner is the owner, beneficiary and premium payor of the policy on the life of the co-owner.  This may make sense from the tax planning perspective.  I am not a tax specialist, so I encourage to consult with one about this.

If, for example, there are two owners, each of whom has invested $100,000 in the business and holds 50% of its stock.  The company is currently valued at $700,000.  Owner A dies.  The company uses its death insurance proceeds to buy out A's shares.  A's shares become treasury stock.  B remains the sole owner of the corporation.  B's shares are now valued at $700,000 - the full value of the corporation.  B's basis in the stock is $50,000.  When he sells his shares, he realizes taxable gain of $650,000.  On the other hand, if A and B cross-insured each other, then upon A's death, B would pay $350,000 to A in insurance proceeds to purchase A's stock.  B's basis in the stock would then be $400,000.  So, his realized taxable gain on the sale of this stock would be much smaller, $250,000.  In this oversimplified scenario, using a cross-over arrangement results in significant tax savings for the surviving partner.

In conclusion, I recommend for all small and closely held businesses to consider entering into buy-sell agreements or including buy-sell provisions in their shareholder, partnership or operating agreements.  Drafting buy-sell agreements requires not just legal, but also financial and tax expertise.  It is worth the investment of time and money to ensure successful business continuation.

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 co-founder of Ross & Shulga PLLC, a New York-based boutique law firm specializing in advising individual and corporate clients on aspects of corporate and securities law.


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 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 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.