Category: Technology

Data Destruction Contract Clauses Are a Hot Topic

Morgan Stanley’s recent payment of $60M to settle a civil proceeding for failing to properly dispose of customer data is a reminder of the importance of knowing applicable data disposal laws and drafting appropriate data destruction clauses in technology agreements.

Sources of Obligations

The sources of obligations to destroy or dispose of personal data are myriad. Direct and indirect federal requirements include the Gramm-Leach-Bliley (“GLB”) Interagency Guidelines Establishing Information Security Standards, the GLB Safeguards Rule, the Health Insurance Portability and Accountability Act (“HIPAA”) Privacy Rule, the HIPAA Security Rule, and the Fair and Accurate Credit Transactions Act Disposal Rule. Unfair and deceptive acts and practices laws, both federal and state, may also apply. In addition, at least 35 states have unique data disposal laws.

Common law negligence, invasion of privacy, and unjust enrichment are just a few other claims that may be brought against companies failing to properly destroy personal information. And, apart from these requirements, technology agreements typically include provisions requiring deletion or return of confidential information.

The data disposal requirements are not simple or easy to navigate, either. Numerous companies besides Morgan Stanley have suffered lapses, including, for example, American United Mortgage Company, Cornell Prescription Pharmacy, FileFax, CVS Pharmacy, Searchtec, Home Depot, and RadioShack.

Data Destruction Tips for Technology Customers

That said, for customers contracting for technology services or products that require the use or availability of personal data, several steps are available to reduce  data disposal risks.

  • Know what personal information destruction and disposal laws apply. Must the destruction efforts be reasonable or must the data be rendered unreadable or undecipherable? Must the data also be unusable?
  • Include agreement provisions requiring the vendor to destroy (or return) the data upon request and, in all cases, upon termination or expiration of the agreement. Add that, upon request, the vendor certify or acknowledge the destruction. Follow through on this requirement.
  • Contractually require the vendor to qualitatively destroy the information so that it is permanently irretrievable, unreadable, inaccessible, and indecipherable. Mandate that paper media be shredded, disintegrated, incinerated, pulverized, or pulped.
  • Include in the contract a right to audit the vendor’s data disposal or destruction and ensure that the vendor’s obligation to establish and implement reasonable security measures aligns with the data destruction requirements.

Data Disposal Tips for Technology Vendors

For technology vendors, which may also have legal obligations to destroy or dispose of data, contractual and operational mitigations also exist.

  • Before contracting, know the personal information destruction and disposal laws that apply. For example, is the vendor a business associate under HIPAA?
  • Proactively include language in the agreement permitting vendor destruction or disposal of the data.
  • Utilize best industry practices to destroy or erase the data – even if the technology agreement does not require it.
  • Segregate each customer’s personal data from other customers’ data, to facilitate discrete and expedient destruction or disposal.

These mitigations for technology customers and vendors are even more important, given the volume and dynamic nature of data destruction and disposal requirements and corresponding challenges for these companies.

Is Your Technology Non-Compete Enforceable?

Frequently, software license agreements, cloud agreements, and other technology contracts include restrictive covenants or non-compete clauses that prohibit a customer from using the vendor’s technology to develop competitive or substantially similar products or services. The court in Triage Logic Management and Consulting v. Innovative Triage Services examined the issue and provided a road map for saving such provisions. Hint: Like online terms and conditions, careful contracting is critical.

Triage Logic Case

In Triage Logic, the software vendor sued the customer for contracting with a third party to develop software similar to the vendor’s licensed product. The vendor-customer agreement prohibited the customer from “develop[ing] similar software, services or product offerings substantially similar to the System” described in the agreement. The clause expressly survived the termination of the agreement.

The court concluded that the non-compete provision contradicted state antitrust law and, thus, was unenforceable, based on the particular restraint being indefinite and perpetual. Applicable state law barred the court from reforming the restrictive covenant to make it enforceable.

State Law Does Matter

Because the Triage Logic case was decided under North Carolina law, it invites comparison to other state laws. For example, under the Texas Free Enterprise and Antitrust Act of 1983, a covenant not to compete is enforceable if it is ancillary to or part of an otherwise enforceable agreement and contains reasonable and limited parameters as to time, geography, and scope. Unlike North Carolina law, the Texas statute requires courts to reform covenants that are not reasonable and limited.

A covenant not to compete is enforceable under Delaware law if it meets general contract law requirements, is reasonable in scope and duration, advances a legitimate economic interest, and balances equities. Delaware courts may, but are not required to, reform otherwise unenforceable provisions. New York law imposes a “simple rule of reason” analysis to non-compete provisions in ordinary commercial contracts (such as license agreements). New York permits blue-penciling of non-compete provisions only when the unenforceable portion of the provision is not essential, among other requirements.

Help is Available

When negotiating a non-compete clause in a technology agreement, technology vendors should consider the following drafting tips to increase the likelihood that the restrictive covenant is upheld.

  • Duration. A perpetual or otherwise excessive duration for a non-compete provision is unlikely to be enforced, whether the duration is identified in the clause, itself, or the provision expressly survives agreement termination.
  • Pencil Color. If the governing state law does not afford blue-penciling or equitable reformation, the non-compete provision may be salvageable if the contract includes a clear and permissive severability clause. Even if the governing law favors reformation, avoid a severability clause that merely instructs deletion of the offending provision.
  • Express Rescue. To seek to save a non-compete clause from unenforceability, include express fallback positions in the contract to operate if primary terms (such as those regarding duration, scope, and geography) are held invalid.
  • Purpose. A restrictive covenant stating a blanket prohibition, rather than one being specifically limited to competitive conduct, is less likely to be held enforceable.

On the other hand, customers seeking to defeat the application of a non-compete clause should do the opposite….

Browse-Wrap, Click-Wrap, and In-Between

For decades, online service providers and web and mobile site owners and operators have sought to bind their users to contractual terms and conditions by way of click-wrap, browse-wrap, and similar methods. For nearly as long, these parties have fought over the enforceability of such online contracting efforts. The path to an enforceable online contract should be clear by now, right?

You’d think so. Yet, even today, the formation of these agreements continues to be litigated.

Click-Wrap Enforceability: Winners and Losers

The keys to binding click-wrap and browse-wrap agreements include notice, clarity, and assent. Generally speaking, a “click-wrap” agreement is one where the user must expressly manifest assent, typically by affirmatively ticking an “I agree” tick-box. A “browse-wrap” agreement, on the other hand, is one purporting to bind the user merely by being posted to the site or online service the user is accessing or using.

In Dohrmann v. Intuit (9th Cir. 2020), Intuit successfully defended the enforceability of its TurboTax click-wrap terms. The terms were conspicuously hyperlinked from the TurboTax online sign-in page, which required the user to click a sign-in button to proceed to use the service. There were three hyperlinked sets of terms, each of which appeared immediately below the sign-in button and was in a different color than the surrounding text. 

In other cases decided in the past two years, some online vendors have been equally successful (see Skillz, GoSmith, and United Parcel Service), while others have not (see Huuuge and SquareTrade).

Clear Your Path to Enforceability

What can make an online agreement easier to enforce?

  • Choose click-wrap over browse-wrap, requiring the user to affirmatively tick a box to manifest assent to the terms. Require the user to scroll through the terms or visit the pages where any hyperlinked terms appear, before the user is able to manifest assent.
  • Conspicuously call out the existence and effect of the online terms. Do not require the user to scroll down the page to see the call-out. Use a font size that is no smaller than, and has a different color than, the surrounding text.
  • State the existence of any hyperlinked terms in close proximity to any “I agree” button or other tool for manifestation of user assent. Avoid hyperlinks within hyperlinked terms, and do not require the user to proceed through multiple web pages to ultimately get to the actual terms.
  • Require assent to the terms when the user is first engaged by the site or online service, rather than after the user sets up an online account or receives online services. Don’t just ask the user to read the terms – mandate that the user read them.
  • Maintain back-office technology that reliably and accurately records each user’s assent to the online terms, including the date of assent and the form of terms assented to.

Thank goodness no one said shrink-wrap terms….

Contracting Conundrum: “Reasonable Security Measures”

In technology contracts between customers and vendors, it is common to obligate one or both parties to implement “reasonable security measures” to protect applicable data and information. Typically, the obligation is a function of risk allocation or legal requirements. The recently enacted (and more recently amended) California Consumer Privacy Act’s authorization of a private right of action against businesses that fail to implement reasonable security procedures and practices highlights the issue. But, what are “reasonable security measures?” And, which contracting party decides?

The Market Speaks

Often, technology contracts merely reference, but do not explain, reasonable security measures. A contract may require a party simply to “implement reasonable security measures” to safeguard applicable information. Alternatively, a contract may obligate the party to “implement reasonable security measures as required by applicable law” or to “comply with applicable data privacy and security laws, including those regarding security measures.” Both customers and vendors can find these examples appealing.

Pushing the Envelope

Less often, but frequently when the technology transaction involves financial services companies, the contract may impose more stringent requirements based on statute or regulation. For example, the vendor may be obligated to “implement administrative, technical, and physical safeguards to insure the security and confidentiality of customer records and information, to protect against any anticipated threats or hazards to the security or integrity of such records, and to protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.”

Similarly, technology contracts involving healthcare information can mirror applicable federal regulations and obligate a party to “implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of the information.” For EU personal data, the Standard Contract Clauses (which will likely soon change) may be invoked.

Although usually advocated by technology customers, because these more specifically stated obligations track legal requirements, they are often acceptable to the customers’ vendors.

Breaking the Envelope

In a few cases, customers or vendors may choose to sidestep the vagueness of the above options. For example, agreements with ties to California may explicitly reference the 2016 California Data Breach Report, which specifically states that an organization’s failure to implement all twenty controls in the Center for Internet Security’s Critical Security Controls constitutes a lack of reasonable security. When payment card information is in scope, the contracting vendor may be directed to comply with the PCI Data Security Standards.

Increasingly more common, a technology customer – or vendor – may expressly set out detailed, bespoke security measures. The contractual statement of these measures can range from one, to three, to five or more pages.

Clearly, there are many ways for contracting parties to reach agreement on applicable security measures to be implemented under a technology contract. Be sure that what you sign up for works best for your company – all costs, risks, and consequences considered.

Blockchain: Mind Your Contract Terms

As noted in a recent BBC article, the distributed ledger technology known as blockchain has been hyped for many years as the solution to countless transaction ills. However, to date, its principal purpose has been to support cryptocurrencies. That said, there are valuable, non-cryptocurrency uses for the technology, including to manage supply chains, to track inventory, and to establish and maintain verifiable transaction records. Businesses are increasingly considering and adopting blockchain – thus requiring their legal counsel to prepare to contract for this burgeoning technology.

As more fully discussed in a previous blog post, there are several key issues to consider when contracting for blockchain technology.

  • Because many blockchain technologies are based on open source software, and users of technologies built using open source software can be subject to various restrictions and requirements, take care to identify and review all applicable open source license terms.
  • Blockchain products are still new, which means that they may not be as well-tested or debugged as mature technologies. For blockchain vendors and customers, consider appropriate contract terms addressing support, maintenance, and performance warranties for early-stage products.
  • Blockchain’s purported unparalleled ability to protect the integrity and confidentiality of data and records does not abrogate the needs to carefully examine how the technology treats data and records and to review applicable privacy and security obligations.
  • Blockchain is technology – with a unique spin. Technology contracting expertise is wholly relevant when drafting, reviewing, and negotiating blockchain technology agreements, particularly terms regarding technology rights and obligations, intellectual property, representations and warranties, indemnities, and limitations of liability.

One Technology Agreement + One Separate Non-Disclosure Agreement = One Mess

The current COVID-19/coronavirus crisis has forced many companies to buy or sell new technology under a previously unseen sense of urgency. While this speed is critical – and absolutely understandable – take care to ensure that today’s deal structure does not undo tomorrow’s benefit. This is especially true as to non-disclosure and confidentiality issues.

If your corporate contracting practice involves establishing a non-disclosure agreement (or confidentiality agreement or NDA) with a potential technology customer or supplier, and then later contracting under a different agreement for the actual business you wish to transact with the other party, now is the time to examine whether that practice is achieving its objectives. As recently learned by one technology supplier, in these cases the terms of the NDA may be rendered ineffective by the subsequent technology contract. iSentium v. Bloomberg Finance (S.D.N.Y. 2020).

iSentium, a technology vendor, entered into a pre-transaction NDA with Bloomberg, pursuant to which Bloomberg considered whether it was interested in iSentium’s artificial intelligence technology. The parties later entered into a technology contract covering Bloomberg’s purchase and use of iSentium’s technology. Both the NDA and the commercial contract included confidentiality terms. iSentium later sued Bloomberg for misappropriation of iSentium’s confidential information. The district court dismissed iSentium’s action based on a one-year limitations period stated in the commercial contract, despite that the NDA included no such limitation. In reaching its decision, the court highlighted the merger provision and precedence language in the commercial contract.

Read the Technology Agreement and Non-Disclosure Agreement

It is not uncommon for a company to have a pre-transaction non-disclosure agreement and a separate commercial agreement with a business partner. However, in many cases, the two agreements are not carefully read together and end up including inconsistencies that are not clearly addressed in the later commercial agreement. Sometimes the commercial agreement is wholly silent as to the existence of the NDA. Other times, the commercial agreement incorporates by reference the inconsistent NDA. In still other cases, like in iSentium, the commercial agreement expressly merges the inconsistent separate NDA.

Inconsistencies between the NDA and commercial agreement can reach matters such as, for example, specific confidentiality requirements, governing law, indemnification, limitations of liability, representations and warranties, disclaimers, and dispute resolution. Often, the inconsistencies may arise after having had to negotiate a suboptimal NDA, as discussed in an earlier blog post.

The inconsistencies frequently create ambiguities or vagueness that can impair or deny a party’s ability to enforce the deal or the rights it thought it had. They also can require significant expense and executive and management time to address, and they can unnecessarily occupy the energy and efforts of internal Legal resources to resolve.

Make Sure the Technology Agreement and Non-Disclosure Agreement are Consistent

There are several ways to address the problems created by inconsistencies between a separate technology agreement and non-disclosure agreement. A few include:

  • Don’t be silent. Include in the technology agreement language explicitly stating that all inconsistencies, ambiguities, and conflicts between it and the NDA will be resolved in favor of the technology agreement – whether or not the NDA is integrated into or merged with the technology agreement. Identify silence on a matter in the NDA as a conflict.
  • Set a clear path. Specifically provide in the technology agreement which confidential information is controlled by the terms and conditions of the technology agreement and call out which confidential information is governed by the NDA.
  • Terminate the NDA. Ensure that the technology agreement addresses, in all respects, the relevant confidentiality and other terms, and then include language in the technology agreement that terminates the NDA’s prospective effect.
  • Apply all terms. State in the technology agreement that its applicable terms (including, for example, limitations of liability, governing law, and dispute resolution) apply to the NDA and the exchange of confidential information under the NDA, despite anything different in the NDA.

This is not an exhaustive list of options. Which (and whether any) alternative works for you may depend on any number of factors or considerations.

Most importantly, to avoid a situation where (1) you have an NDA and a separate, later technology agreement covering the same subject matter, but (2) you might not be able to enforce the agreement you want to enforce due to conflicting or inconsistent terms, carefully read the two agreements and clearly and unequivocally state the resolution of the conflict or inconsistency in the later technology agreement.

License Restrictions: Covenants or Conditions?

The focus of the First Circuit Court’s opinion in Photographic Illustrators v. Orgill (1st Cir. 2020) was whether a sublicense may be granted by implication and whether, under the facts of the case, the sublicensor (Osram Sylvania, Inc.) actually granted an implied license to the sublicensee (Orgill, Inc.). However, the foundation of the case hinged on whether the sublicensable license granted to Sylvania by the principal licensor (Photographic Illustrators (“PIC”)) was subject to a covenant or a condition.

In the applicable license agreement, PIC expressly granted Sylvania a sublicensable license to use certain PIC photographs to market Sylvania’s lightbulbs. A separate agreement provision required Sylvania to include an attribution notice when publishing the licensed photos. Sylvania granted Orgill, one of its distributors, the right to use certain PIC photos, but Orgill did not include the requisite notice when publishing the photographs. Critically, if the notice requirement was a condition, Sylvania’s grant of the license to Orgill exceeded the scope of PIC’s license to Sylvania, and Sylvania would be exposed to copyright infringement claims for its grant to Orgill. On the other hand, if the notice requirement was a covenant, Sylvania’s grant to Orgill would be a breach of contract, instead of copyright infringement. This covenant-versus-condition issue applies beyond copyright licenses and includes software licenses, technology agreements, and countless other contracts under which use rights are granted.

Whether a contractual use limitation or requirement is a covenant or a condition is important for several reasons:

  • If the limitation or requirement is a condition applicable to rights granted in respect of copyrights, trade secrets, or other intellectual property, failing to satisfy the condition potentially gives rise to an infringement or misappropriation claim, the damages for which often exceed the damages available for breach of a contract covenant.
  • If the limitation or requirement is a condition, the contract’s termination provisions may not provide an express right to cure the failure, thus likely giving the licensor greater termination rights than if the limitation or requirement is a contract covenant.
  • Contractual limitations of licensee liability frequently exclude licensee violations of the license grant, more so than licensee breaches of contract covenants.
  • Especially when the licensed material includes third-party intellectual property, licensors often require licensees to contractually indemnify the licensors for violations of the license grant. Less frequently do licensors extend these indemnification obligations to breaches of contract covenants.

Whether you are a licensor or licensee under a particular contract, be sure to consider if license conditions, or covenants, are in your best interest.

Eight Ways to Close Your Year-End Deals on Time

With less than four weeks until the end of the calendar year, many buyers and sellers of software, SaaS, cloud, cybersecurity, and other IT products and services have too many deals – and not enough time – to get everything done. Having been on both sides of year-end technology transactions, I’ve not yet seen a magic wand that provides the sales and procurement teams a stress-free year-end contracting experience.

That said, there are several different tactics to try to help technology buyers and sellers conclude year-end transactions that meet their needs and goals – despite the timing stress. The key is creativity. For example, requiring each party to set aside eight hours every day for team-to-team negotiations until the agreement is finalized – when each team has ten other deals they’re also trying to close by year-end – is impractical.

As you sprint toward the year-end finish line, consider whether one or more of the following contract approaches may help you to close a transaction that still reflects a good deal for your client or company:

Shorten the Term. If your year-end deal is troubling because your client’s or company’s obligations and responsibilities extend for three, five, or more years, shorten the duration of the contract and include optional renewals or extensions to get to the originally proposed longer term.

Extend Payments. If you are unsure whether the other party will perform its contractual obligations over the short-term, spread out the buyer’s payment obligations over a period of time. (The seller’s obligations to continue to provide technology products or services could be tied to the buyer’s extended payment obligations, as well.)

Termination Rights. To address uncertainty as to the other side’s near-term performance, build in to the agreement certain for-convenience termination rights that deal with unmet milestones or benchmarks that wouldn’t otherwise be material breaches of the agreement.

Aggressive Limitations of Liability. If you are not confident that your client or company will easily perform all of its obligations under the proposed year-end contract, aggressively limit your client’s or company’s liability under the agreement in the event of non-performance.

Current Scope Only. Some year-end deals try to accomplish too much – that is, they seek to include products or services that won’t be provided for many months or even years after signing. Limit the subject of the year-end deal to only those products and services that are immediately in scope, and temporarily postpone contracting for items that are to be provided separately, later.

Agree on Details Later. Some year-end transactions contemplate comprehensive professional services that are provided in stages, where the requirements of each later stage depend on the outputs from the earlier stages. Rather than trying to exhaustively detail each stage’s requirements and outputs all at once, expressly defer the details until later in the contract term – and build in to the contract appropriate mechanisms and outcomes if the details are not agreed.

Top Five Issues. Although rarely a favorite option of technology buyers or sellers, limiting one party or both parties to raising and negotiating only its top five contract issues will likely expedite the process of concluding the year-end deal.

Post-Signing Diligence. Allow one or both parties a short period of time after contract signing to perform deal diligence that they weren’t able to conclude before signing. If the diligence reveals material concerns with the signed agreement, permit the parties to renegotiate any impacted contract terms or to otherwise address the gaps.

Note: Several of the above tactics may be seen by technology sellers as untenable due to potential negative effects on their ability to recognize revenue for a particular deal. In some cases, however, whether in return for a larger or longer deal or otherwise, sellers may be willing to negotiate unique terms in order to close the year-end deal.

Good luck in your negotiations!

2019 Case Law Mash-Up: Can you assign exaggerated representations and warranties to a locked-in vendor?

Mash-up (noun): (slang) a creative combination of content or elements from different sources.

Several court cases in 2019 dealt with (or are still dealing with) key issues faced by parties to commercial contracts, including contracts for technology products and services. This post briefly discusses four of those cases and their corresponding issues of contract assignment, representations and warranties, and data security.

Can You Assign?

According to the court in Barrow-Shaver Resources v. Carrizo Oil & Gas (Tex. 2019), the answer to the question, “Can you assign?” is “No.” Bottom line: Make sure your contract clauses are clear and unambiguous, and don’t plan to rely on prior negotiations, drafts, or margin comments to explain away terms you don’t like.

The contract in question included an unambiguous non-assignment clause that read, “The rights provided to [Barrow-Shaver] under this Letter Agreement may not be assigned, subleased or otherwise transferred in whole or in part, without the express written consent of Carrizo.”

The court concluded that Carrizo was within its contractual rights to simply refuse to provide consent to Barrow-Shaver’s requested assignment – without more. Neither the contract language nor applicable law required Carrizo, in withholding consent, to exercise good faith, to be reasonable, to satisfy certain conditions, or to provide a reason for withholding consent.

The court rejected arguments that, notwithstanding the contract language: industry custom and usage should be applied to interpret when consent may be withheld; prior to contracting, Carrizo assured Barrow-Shaver that Carrizo would provide its consent; and, the parties’ prior negotiations and an early draft of the contract should be considered.

Exaggerated Representations and Warranties

Two 2019 cases highlight the sales and contracting processes for big-ticket IT services. In IBM v. Lufkin Industries (Tex. 2019) (“Lufkin”), Lufkin Industries contracted with IBM for the provision and implementation of a new software solution to run Lufkin Industries’ operations systems. In Hertz v. Accenture (S.D.N.Y., not yet decided) (“Hertz”), Hertz contracted with Accenture to build a transformed web site and mobile application. A key takeaway from both cases is that well-drafted contractual disclaimers and integration clauses, absent explicit contractual representations or warranties, can defeat warranty breach, inducement, and misrepresentation claims.

In Lufkin, IBM made several pre-contractual representations regarding the timing and ease of implementation of the new software solution. Some representations were made orally, others appeared in sales materials. The project implementation process ultimately failed. In Hertz, Accenture is alleged to have delivered versions of contracted work product that failed to meet contractual timing requirements, specifications, and warranties. Hertz terminated Accenture’s contract before the project was completed.

In 2019, Hertz filed a lawsuit against Accenture for breach of contract and unfair and deceptive practices. In its motion to dismiss, Accenture specifically called out the contract’s integration clause and conspicuous warranty disclaimer provision. In Lufkin, IBM prevailed against Lufkin Industries’ claims for inducement and misrepresentation. The contract included clearly drafted language disclaiming IBM representations, disclaiming Lufkin Industries’ reliance on IBM representations, and establishing the contract as the entire agreement between the parties.

Contracting for large IT projects can be challenging. The projects are often complex and time-consuming and frequently involve developing or evolving parameters and requirements. Almost certainly, notable time is spent drafting contractual representations, warranties, disclaimers, and integration clauses. But, to address potential issues, also duly consider project scoping provisions and acceptance terms (including whether the RFP (if one) will be part of the contract). If possible, stay connected with your sales or procurement team throughout the sales process to ensure alignment and relevant project-specific contract terms.

Locked-In Vendor

Tightly drafted contracts are a valuable asset – but they are not the exclusive source of risk mitigation and avoidance. If you can, do more.

A class-action lawsuit was brought against Delta Air Lines following a data security breach affecting 800,000 Delta customers. See McGarry v. Delta Air Lines (C.D.Cal. 2019). The breach involved a hack of Delta’s service provider, 24[7] (a Philippines company). Delta subsequently sued 24[7] for damages arising from the breach.

The security terms in Delta-24[7] were robust and comprehensive. In addition, 24[7] represented that it had achieved five different industry-recognized privacy/security certifications. Although the contract terms and representations ultimately may be sufficient to award Delta damages, the contract doesn’t assure Delta’s full recovery. What other help is there?

For customers, even if it’s not required, pre-contract service provider diligence can be quite informative; for vendors, ensure that you can do what you contractually sign up for. When contracting with foreign companies, consider parent guarantees or other contractual mitigations. And, for customers and vendors, closely review your own insurance policies to evaluate coverage in the event of a security incident; also for customers, consider reviewing the service provider’s policies if you have coverage concerns.

Why Blockchain Matters to In-House Lawyers

Today, news reports, academic articles, and corporate reports are flush with mentions of “blockchain,” “Bitcoin,” and “distributed ledger technology.” At first glance, many readers see the discussion as hype, generating a great deal of actionless attention, curiosity, and investment opportunities. However, on another level, some of the conversation regards developments in technology that may specifically shape or impact a company’s contract or legal risk profile – even for those companies that don’t have or deal in Bitcoin.

Blockchain technology is expected to have a broad and sweeping impact across industries worldwide, with one commentator identifying a financial impact of over $176 billion in the next several years. It is envisioned that countless companies (whether suspecting or unsuspecting) will deploy or utilize the technology in their businesses. This may happen in the form of an internally developed or deployed technology or system, through dealings with governments or government agencies, or by way of transactions with technology vendors or service providers, among others.

At a very high and general level, blockchain is a recently developed distributed ledger (or database) technology that facilitates secure records of transactions over time by electronically distributing and maintaining tens, hundreds, or thousands of identical, immutable, highly secure digital copies of the transaction record. Each of these copies is distributed to and held by a different computer node or site participating in the ledger. Blockchain is one kind of distributed ledger technology, and there are many different platforms for blockchain. Bitcoin is a form of cryptocurrency whose foundation is based on one of the blockchain platforms. (Numerous detailed explanations of blockchain and distributed ledger technology are available online, including the video, Ever wonder how Bitcoin (and other cryptocurrencies) actually work?, and a UK Government report on distributed ledger technology.)

Many sets of records that are maintained in an Excel spreadsheet, a company or vendor database, or government files, whether or not currently stored or maintained in the cloud, may be suitable for blockchain. A few examples include real estate purchase and sale transactions, shipping records, banking and financial transactions, inventory management, consumer auto-pay and auto-withdrawal transactions, product manufacturing, and customer subscription transactions.

Attorneys and contract professionals supporting companies’ encounters with blockchain technology should consider the following, among others:

Open Source Software. Currently, numerous distributed ledger technologies (including blockchain) are built using open source software. The Bitcoin program is distributed under the MIT License, aspects of Ethereum (another blockchain-based cryptocurrency) use the GNU General Public License, and OpenChain (another distributed ledger technology) is based on the Apache 2.0 license. Open source software licenses include many unique terms (and omit many standard commercial software licensing terms), and may, for example, dictate subsequent use and distribution of the software, as well as of company proprietary code related to the open source software.

New Software. Because distributed ledger technology like blockchain is new, in many cases the software underpinning the technology is not as well-tested and presents a notable possibility of serious errors and glitches. Consequently, traditional contractual recourses and remedies for software errors and bugs may not be wholly meaningful, when applied to blockchain, and typical software project deployment schedules and timelines may be difficult to adhere to.

Privacy. While one of the potential benefits of blockchain is stronger data security safeguards against loss, destruction, and unauthorized alteration of data and records, the nature of a distributed ledger is that the tens, hundreds, or thousands of ledger participants will have exact duplicates of the digital data and records. Even if the parties to a particular transaction do not consider the transaction record in the ledger to be confidential, it is possible that the underlying record data (especially if health, medical, or financial data) may be a material concern.

Technology Contracting. Blockchain is a technology, with its own open (as noted above) or proprietary platforms, software, and systems. Contracts for, or to use, blockchain technology, just as other company contracts for technology, are key vehicles to establish critical rights and obligations regarding representations and warranties, indemnities, limitations of liability, and intellectual property.

Bitcoin. Many companies will not typically have or deal in Bitcoin or other cryptocurrencies. The legal and regulatory landscape applicable to cryptocurrency is nascent and exceptionally dynamic and varies across U.S. and non-U.S. jurisdictions (and is beyond the scope of this post). Even for companies that merely or only occasionally transact business in cryptocurrency (and don’t issue, exchange, or administer cryptocurrency), potential issues can include how cryptocurrencies are treated and taxed (different legal authorities consider them to be “currencies,” “commodities,” or “property”), whether corporate insurance provides coverage or protection for cryptocurrency transactions, and whether the use of cryptocurrency is even legal.

Blockchain is an algorithm-intensive, complex technology that may provide great benefits, efficiencies, and cost savings to its users. While this post does not speak to many of its features, including smart contracts, permissioned versus unpermissioned ledgers, and cryptocurrency mining, hopefully it provides a “bit” of useful information.