Andrew Leahey

Software as a Service - Service Level Agreement Template

If you have specific questions regarding the hosted services provision, or any aspect of a Software as a Service Contract, please don’t hesitate to get in touch.

A service level agreement (“SLA”) is a contract between a service provider or vendor and a client or customer. It outlines what the customer can expect in terms of quality of service from the vendor, and outlines what remedies the customer will be entitled to if that service level is not maintained. SLAs are a crucial aspect of a Software as a Service (“SaaS”) contract as, as the name implies, in SaaS the software is the service. In a traditional software licensing scheme a customer would not need promises from the vendor that the software would be available and accessible — Microsoft sells you a copy of Windows 10, you in stall it, and it will always be available as long as your hardware is functioning (maybe using Windows as an example for uptime was a mistake). However, for software that requires a continuing provision of service from the original vendor, customers typically want a guarantee that the service will remain available as long as they continue to make payments to the vendor.

An SLA is not intended to be a whitepaper outlining how the service is provided, nor is it a user manual for the customer to reference if they have a question. It is merely a contractual representation of what the vendor promises to provide to the customer.

Typically an SLA will include:

  • Introduction. A section outlining what the SLA is, who it is by and between (defining the vendor and, sometimes, the customer), where the terms of service might be accessed, etc.

  • Scope. The scope section of the SLA will define the parties involved, the time period the SLA will run for, the services that are covered, the services that are not covered and any other exclusions. Typically this section will read as outlining what is covered and broadly disclaiming any ancillary services not outlined.

  • Responsibilities. The vendor has responsibilities, the customer has responsibilities, both need to be outlined. Vendor responsibilities include the provision of the service that the SLA contemplates, responding to support requests, resolving issues, etc. The customer may be tasked with ensuring their hardware remains functional and up to date, and notifying the vendor of any issues.

  • Uptime Guarantees. This is the crux of the SLA. The vendor will guarantee some level of uptime (99.99%, 99.999%, etc.) and outline how that will be measured. This section may also outline what remedies the customer has if these levels are not maintained.

  • Response Times. Just as the SLA outlines uptime guarantees, it may outline response times for service requests. Customer service has always been an important aspect of software sales, but in a SaaS situation doubly so. You want Microsoft to respond to your support requests quickly when your printer isn’t working, imagine how important their response would be if the answer to the printer problem might be on their end.

  • Resolution Times. A resolution time section is optional, but can help put customers mind’s at ease. To the extent that a vendor can, they may want to make guarantees or set goalposts for the total amount of time it might take to resolve a support issue. This is obviously not always possible, but where possible it is an extra level of guarantee.

  • Signatures.

The exact combination or permutation of the above sections may differ between SLAs, but the overarching structure will remain the same. An SLA will outline how consistently the service will remain available, what will happen if it is not made available, how quickly support requests will be responded to, and what will happen if those requests are not responded to. They will all outline what the vendor can guarantee, what they can’t guarantee, and what they disclaim.

The level of detail and precision necessary in an SLA will vary based on the type of service being made available and how much of the service is in the vendor’s hands.

Service Level Agreement Template

Download my boilerplate SaaS Service Level Agreement Template

I have provided a SaaS Service Level Agreement Template as an example, and as a jumping off point. Please note, this is a boilerplate — that means it is not tailored at all to your specific needs. It should not be taken and used without thought, nor should sections be lifted from it and used unless you know their meaning and utility. Please get in touch if you want to discuss any of the ramifications for your business.

GDPR Special Category Data

If you’d like to discuss the GDPR and how it impacts your business, get in contact.

The General Data Protection Regulation (GDPR) of the European Union (EU) has been shaking up the web in terms of privacy policies and procedures for some time now — I have written at some length on the general best practices for a GDPR compliant privacy policy and the potential “loophole” of the legitimate interests exception.

The GDPR requires a heightened level of protection for certain sensitive data categories. The categories are:

  • Health Data (including genetic data);

  • Biometric data;

  • Trade union memberships;

  • Political opinions;

  • Religious or philosophical beliefs;

  • Race and ethnicity; and

  • Data related to sexual preference or orientation.

The directive takes a policy position that these particular data are of a uniquely sensitive nature and, thus, a business must have a specific, legitimate reason for collecting the individual data type.

The GDPR restricts the collection and processing of the data unless one of the following circumstances are met:

  • The data subject has given explicit consent for the collection or processing of that particular data AND the EU or the Member State of the data subject has not explicitly prohibited the collection or processing of that data type;

  • Processing is necessary for carrying out the obligations and exercising specific rights of the controller or the data subject in the field of employment, social security, and social protection law;

  • Processing is necessary to protect the vital interests of the data subject or another natural person;

  • Processing is carried out in the course of the legitimate activities of a foundation, association, or other not-for-profit body with a political, philosophical, religious or trade union aim;

  • Processing relates to personal data which is made public by the data subject — i.e. a published materials exception;

  • Processing is necessary for the exercise or defense of legal claims;

  • There is a substantial public interest in the data;

  • Processing is necessary for public health; AND

  • Processing is necessary for archiving purposes as it relates to subjects with a substantial public interest — i.e. an historical record exception.

Importantly, these special categories are not exhaustive, and act more as a floor than a ceiling — individual member states can define other categories of data as being “special categories” for purposes of data collection and processing. Care must be taken to not only ensure compliance with the EU through the GDPR, but to ensure you are compliant with any individual member state laws, when your business entails handling especially sensitive data.

Please get in touch if you want to discuss any of the ramifications for your business.

GDPR Compliant Privacy Policy Template

The GDPR is complex and can have serious ramifications for your business. If you’d like to discuss the GDPR and how it impacts your business, get in contact.

I have written on privacy policies a bit before and covered in some detail the rise of the General Data Protection Regulation (GDPR) in the European Union (EU) and the various GDPR “loopholes.” It is real, it is here, and any business that may be doing business with a person or entity in the EU needs to comply.

To catch you up, the GDPR is a privacy regulation from the EU that took effect in 2018. It aimed to create a unified data privacy legal framework in the EU and to codify EU resident’s rights to data protection. It broadly applies to people and businesses that interface with EU residents — that is to say, you need not have an office in the EU for the GDPR to apply to you.

What does the GDPR require?

In short, it requires that you have a privacy policy and you abide by that policy. You need to lay out your policy in plain language and make it readily available to anyone you could plausibly collect information from — i.e. visitors to your site, customers on your online store, etc. Your policy should lay out at least the following points:

  • The identity of the data controller and data processor;

  • if you have a data protection officer, the contact information for that officer;

  • for what purpose you are utilizing collected data — legitimate interest;

  • how data is being processed;

  • where consent is required and how it is obtained;

  • data subject rights;

  • any vendors or subsidiaries you share data with and assurances they will comply with the GDPR;

  • whether and where you will transfer data across jurisdictions — especially out of the EU;

  • your data retention policies; and

  • how an individual can request their data be removed.

Generally speaking your GDPR privacy policy will be placed prominently on your website. Best practice now is to request users to read and agree to it using an overlay upon first visiting the site. You should also refer users to it any time they are providing you with new information — e.g. submitting a form, signing up for a mailing list, etc.

Please note, this list is not exhaustive. The GDPR applies in different ways and to different degrees depending on the kind of data collecting and processing you are doing, where you are doing it, and why you are doing it. Simply reading off the above list (or any broad list you find on the internet) and comparing it against your privacy policy is almost certainly not enough.

GDPR Compliant Privacy Policy Template

Download my boilerplate GDPR Compliant Privacy Policy Template (PDF)

Please note, this is a boilerplate — that means it is not tailored at all to your specific needs. It should not be taken and used without thought, nor should sections be lifted from it and used unless you know their meaning and utility. Please get in touch if you want to discuss any of the ramifications for your business.

TCPA Compliance Guide

This is for informational purposes only. If you want to discuss your specific situation, get tailored guidance, or if you have any questions about the TCPA or its effect on your practices, please get in touch.

The Telephone Consumer Protection Act (TCPA) was originall enacted by Congress in 1991. Since its inception the TCPA has authorized the Federal Communications Commission (FCC) to enact and enforce regulations that curtail how telemarketers can make calls to consumers and, later, the type of telephones that can be contacted.

The TCPA was enacted chiefly to restrict the rising use of automatic telephone dialing systems (ATDS) which were capable of calling phone numbers sequentially in perpetuity and around the clock, playing prerecorded messages to consumers or connecting them to live representatives when the receiver was picked up. Similarly, Congress sought to restrict expensive fax machine spamming, which was on the rise.

What does the TCPA cover?

The TCPA regulates the use of ATDS and the playback of recorded messages to consumers and the contacting of landline, wireless or cellular, and fax lines.

How to Comply with the TCPA

First, and foremost, businesses can create a formal, written, and abided-by compliance policy. The policy should lay out, in detail, the procedures that employees, independent contractors acting on behalf of the business, and vendors and contractors, will adhere to when using the telephone system to market to consumers. Here is an example of a very broad, very basic TCPA compliance policy template that can give you an idea of starting points.

To be sure, the TCPA compliance policy must be drafted with care, but equally important is adherence. The business should train employees where possible, disseminate the policy to independent contractors and vendors, and keep the policy updated as the law changes. Most of the movement in TCPA compliance comes from the circuit courts and FCC guidance materials. Staying on top of these changes is vital to avoiding liability.

Second, a business needs to create a distinct and separate database of consumers based on the type of telephone line they have contact information for — in short, make a separate list for all the wireless phone numbers, or numbers you suspect might be tied to wireless phones. The restrictions against contacting wireless consumers are significantly higher than landline telephones - most importantly, you need to receive “prior express consent” before you can call a wireless number using an ATDS or use a pre-recorded voice.

This is good practice in general — express written or verbal consent following a “clear and conspicuous disclosure” should be obtained wherever possible. The consent may be provided electronically in compliance with the E-SIGN act, but it must be obtained following a clear statement to the consumer that they will be authorizing the business to contact them in the future. With number portability and the decline of the landline telephone, many consumers will port their landline number to a wireless account. They may have provided you with their number presenting it as a landline number, and it may have been one when they did, but this will be no bar to your liability — and fines are steep.

Third, a business needs to strictly adhere to the National Do Not Call Registry (DNC) and maintain their own do not call list. A business is said to have notice of a number being added to the DNC after it has been listed for thirty-one (31) days. Additionally, a business should maintain their own list of consumers that have requested to be placed on the business’ do not call list, as those consumers may not be on the DNC.

Other Materials

See also, the manual put out by the FCC for TCPA compliance.

My TCPA compliance policy template (PDF).

New Jersey Blockchain Initiative Task Force

On March 13, 2018 Senators Thomas Kean and James Beach introduced in to the New Jersey Senate, NJ S2297, an act to create the New Jersey Blockchain Initiative Task Force. S2297 was referred to the Senate Budget and Appropriations Committee on September 27 of the same year.

The task force would be created to study whether “State, county, and municipal governments can benefit from a transition to a Blockchain-based system for recordkeeping and service delivery.” The bill expounds upon the ways in which blockchain technology can increase efficiency while reducing overhead and issues of interdepartmental compatibility.

The bill focuses on the advantages of using blockchain for “medical records, land records, banking, and property auctions” but makes no specific mention of potential tax implications such as integration with sales tax point-of-sale (POS) systems or general record keeping. Time will tell if there exists the political will to move the project forward at the government level.

GDPR and the "Legitimate Interests" Loophole

If you’d like to discuss the GDPR and how it impacts your business, get in contact.

The General Data Protection Regulation (GDPR) is a European Union (EU) regulation outlining new policies for data privacy and protection for individuals within the EU. The regulation's stated aim is to protect a natural person's "fundamental right" of protection in relation to processing of personal data. In sum, the GDPR applies broadly to any entity controlling, collecting or processing data containing personal information regarding a person in the EU -- they need not be a resident of the EU or any member country. "Personal information" is defined broadly as well and includes names, photographs, addresses, email addresses, social media handles and posts and even an IP address. In essence, if you have a web presence or in any way process any data and you aren't explicitly excluding the EU from it, the GDPR applies to you.

However, as broad as the GDPR is, it contains a potential rule-swallowed exception:

The legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overriding, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller. Such legitimate interest could exist for example where there is a relevant and appropriate relationship between the data subject and the controller in situations such as where the data subject is a client or in the service of the controller. At any rate the existence of a legitimate interest would need careful assessment including whether a data subject can reasonably expect at the time and in the context of the collection of the personal data that processing for that purpose may take place. ... The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned. The processing of personal data for direct marketing purposes may be regarded as carried out for a legitimate interest.

Regulation (EU) 2016/679 (47)

In essence, processing of personal information for a "legitimate interest," as long as it does not explicitly contravene the interests or expectations of the owner of the personal information, is permissible. The regulation explicitly calls out direct marketing as a potential legitimate interest of the data processor (note the "may be regarded" language). 

In addition to direct marketing, the GDPR outlines several more "legitimate interests" for processing, including: processing and transmitting data between affiliated data controllers for internal administrative purposes; processing data to the extent strictly necessary for the purposes of ensuring network and information security; and processing personal data for purposes compatible with those purposes for which the personal data were initially collected. Compatible purposes include archiving, processing for purposes in the public interest, and scientific, historic or statistical research. Additional potential compatible purposes should be evaluated by the data controller by balancing "any link between those purposes and the purposes of the intended further processing; the context in which the personal data have been collected, in particular the reasonable expectations of data subjects based on their relationship with the controller as to their further use; the nature of the personal data; the consequences of the intended further processing for data subjects; and the existence of appropriate safeguards in both the original and intended further processing operations."

In sum, the GDPR is almost certain to upend the balance of power between consumers and corporations the world over. While the GDPR largely does away with the "disclaim game" in privacy policies, its scope is undercut by its exceptions. As businesses scramble to comply by the May 25, 2018 enforceability deadline, time will tell how much of a game changer this latest move by the EU will be. 

India Tax Overhaul and Cryptocurrency

It seems as part of the tax overhaul, the Modi government is looking in to taxing bitcoin and other cryptocurrency. Some time ago the Indian government announced the creation of an interdisciplinary committee to prepare a report and recommend policies for cryptocurrency. 

The impact of the GST on cryptocurrency remains to be seen. The main question will be whether it is deemed a currency -- which would mean indirect taxes don't apply -- or essentially assets being used for bartering. 

The attraction of the latter option appears to be the relative simplicity. Rather than integrating and regulating bitcoin, it would merely be taxed under the new goods and services tax schema. Cryptocurrencies would be traded like gold, on registered exchanges monitored for illegal activity. The line that is being walked appears to be between blanket legalization with the preservation of the anonymity of distributed ledger cryptocurrencies and blanket illegalization, an unpopular option. 

The list of countries in which cryptocurrencies are illegal is not a long one: Bangladesh, Kyrgyzstan, Ecuador, Bolivia, and a few others. If India opted to illegalize cryptocurrencies, it would be the largest market to do so. 

The Benefits Of The New Indian Goods And Services Tax (GST) For Startups

As previously discussed, the Modi government of India is overhauling the country's tax code -- replacing taxes levied on businesses by the central government as well as the individual states with one unified GST.

The GST is a massive tax reform, indeed likely the largest since India gained independent in 1947. India is comprised of 29 states and 7 union territories. Previous to the GST, each state and union territory had an independent tax schema that any would-be national startup would have to contend with. So, placing yourself in the shoes of a national Indian startup, you would need to consider how to pay:

  • Union Government Sales Tax
  • State Government Sales Tax
  • Service Tax
  • Value Added Tax
  • Custom duty & Octroi
  • Excise Duty
  • Anti Dumping Duty
  • Professional Tax
  • Municipal Tax
  • Entertainment Tax
  • Stamp Duty, Transfer Tax
  • Education Cess Surcharge
  • Gift Tax
  • Wealth Tax
  • Toll Tax
  • Swachh Bharat Cess (Service tax)
  • Krishi Kalyan Cess (Service tax)
  • Infrastructure Cess
  • Entry Tax

Under the GST, there is one consolidated tax for state and national governments, akin to that found in France, which would subsume most of the above. The GST will be payable at the point of consumption (point of sale, essentially) and, as previously mentioned, falls along a schedule with brackets ranging from 5% to 28%. 

The GST will assist startups in that it will permit entrepreneurs transacting with multiple states to calculate one tax rate for the State-GST and the Central-GST. The transaction costs for a startup in expanding from a single state to multiple, at least at the tax level, are thus substantially reduced. Additionally, unifying the tax system will permit India to explore new technologies, such as blockchain

India Tax Overhaul

"Now, [the Modi government] is instituting the country’s biggest tax overhaul since independence. On Saturday, a nationwide sales tax replaces the current hodgepodge of business taxes that vary from state to state and are seen as an impediment to growth. It is expected to unify in a single market 1.3 billion people spread over 29 states and seven union territories in India’s $2 trillion economy."


The new tax system, the Goods & Services Tax (GST) is intended to simplify business taxes and spur growth, replacing taxes levied on businesses by the central government as well as the individual states. The GST will be divided in to Central Goods & Services Tax, State Goods & Services Tax and Integrated Goods & Services Tax. A constitutional amendment has already been passed by Parliament and approvals have been ascertained by India's 29 states. The current rate schedule includes 5, 12, 18 and 28% and a host of exceptions, subsuming dozens of brackets in to four. 

Ahead of the roll out, the Indian government developed a technology portal, the GST Network, which is intended to allow business owners to register their companies and pay their taxes online. While the system and the portal is not without its detractors, it does appear to have had at least some positive economic effect. Hyundai and Nissan have announced a decrease in automobile prices to pass on savings under the GST -- 5.9% and 3%, respectively. 

Update 2:43PM: There is a video session in which the Revenue Secretary, Ministry of Finance, Government of India answers questions regarding the GST roll out. 

Delaware Senate Advances Distributed Ledger Bill

The Delaware Senate has voted Senate Bill 69 out of Committee, moving a step closer to permitting the use of networks of electronic databases ("distributed ledgers") for the creation and maintenance of corporate records.

I have previously discussed the concept of distributed ledgers. The Senate bill would permit corporations to authorize, issue, transfer and redeem shares through distributed ledgers. This would ensure that, in the eyes of the state of Delaware, corporations issuing shares through blockchain are not breaching their fiduciary duty by doing so. 

Software as a Service - Crucial Contract Terms

If you have specific questions regarding the hosted services provision, or any aspect of a Software as a Service Contract, please don’t hesitate to get in touch.

As we have discussed previously, drafting software as a service ("SaaS") contracts brings with it numerous contractual complexities that in many ways mirror the complexity of the underlying technology. Providers give customers access to software and cloud services, allowing remote access and off-site data storage and shifting the risk of downtime and data corruption or loss to the provider. Of course, the amount of risk the provider wishes to assume in the arrangement is entirely up to the parties to the contract -- but both parties must take care to avoid assuming risk through ambiguous drafting and ensure what is in the contract truly reflects the bargain struck.

Just as lines of code cannot be cut and pasted reflexively from one project to another, so too is the case with contract language. Boilerplate should be used a heuristic - a quick way to see a list of provisions and clauses that you may want to consider negotiating for your current transaction. This post can be considered a boilerplate of the heuristic variety: some common SaaS provisions that you may want to consider. It is neither complete nor exhaustive and the entire list will likely be neither necessary nor sufficient for any individual transaction. They are provided merely as a list of provisions to get you thinking. 

Virtual Point of Demarcation

When goods are shipped internationally, parties to a sale agreement need to negotiate when title to the goods transfers from the seller to the purchaser. If Amazon sells you a box of crystal juggling pins and they are dropped on the warehouse floor, we have a pretty good understanding of who will bear the cost of replacement. Perhaps the answer remains clear if the pins are lost in transit. But what if Amazon sees them safely all the way to your doorstep where they are trampled and broken? Intuitively we have an understanding that the title and the risk of loss for those pins has now shifted to you - they were delivered safely to your door and were broken while in your possession. 

In the digital world, as is so often the case, the situation becomes murkier. Take for instance a voice over internet protocol ("VOIP") provider that sells a telephone service to a mid-sized business that has its own existing telephony infrastructure. If the VOIP service goes down on the provider's end, we understand that the outage is their responsibility. What if, however, an outage occurs and it becomes clear that it was owing to a misconfigured piece of equipment owned by the business? Without a virtual point of demarcation, the answer may need to be provided through litigation. 

Virtual points of demarcation make clear where a service provider's obligations end and the customer's begin. They are, conceptually, linked to the service level agreement -- they draw thick lines around the boundaries of the service level warranties. In essence, the service provider promises that X, Y and Z will not happen, but makes no additionally unenumerated assurances. 


Most businesses' needs are in flux. When a customer first signs a service agreement they can only do so based on their requirements (users, devices, licenses, etc.) at the time of signing. While it seems obvious, care should be taken to ensure that there is a transactionally cost effective way for a customer to expand or contract the number of users, devices or licenses that they are licensing. Placing undue transactional costs here, such as requiring them to renegotiate a new license, may cost the provider a customer when it comes time to expand - the cost effectiveness of staying with an existing provider is wiped out if new terms will need to be renegotiated as though they were a new customer. Make the path to expansion or contraction clear and as painless as possible. 


A number of years ago, cloud photo hosting service Flickr, now owned by Yahoo, ran in to some issues regarding the ownership of user photos uploaded to their service. Their Terms of Service, ambiguously worded, gave some users pause and caused them to wonder if Flickr was attempting to retain copyright ownership of all photos hosted on their service. Flickr responded, clarified their Terms of Service, reassured their users, and the furor died down. However, it really is impossible to say how much the debacle effected their growth, customer satisfaction, and even valuation. 

Providers: don't be like Flickr, make it clear from the start. For many modern businesses, their most valuable asset is their data. While service uptime and data security and privacy provisions may go over the heads of everyone save for the nerds in the basement in IT, the concept of who "owns" the data that is stored with your service will be crystal clear to techies and Luddites alike. Make clear who owns the data, who can use the data, if the data can be used or sold in the aggregate by the provider. If you were leasing warehouse space and the leasing agreement left who would own the items kept in the warehouse ambiguous, wouldn't you want to make sure it was cleared up before pen met paper? 

Indemnification and Insurance

Consideration should always be given on either side of a SaaS contract as to whether one or both parties should be compelled to carry insurance. Most obviously, a provider should carry insurance to cover data and privacy breaches, data loss, and service downtime. Less obviously, however, is the insurance carriage requirements of the customer. If the customer will be indemnifying the provider for any liability, the provider will want to ensure the customer carries sufficient insurance to cover the cost of liability. 

Downtime Allotments for Updates and Maintenance

99.9%, 99.999%, the minimum acceptable level of uptime is getting more 9s after the period every year. Owing to virtual servers and data redundancy, the need for downtime for updates or maintenance is becoming less and less common. However, there remain some technologies that still may require data or services to be unavailable for a period of time - and there is always the dreaded DNS issue. If required downtime may be a factor that needs to be considered by a provider in a SaaS agreement, care should be taken to also consider whether that downtime needs to be provided for separate and apart from the service level provision. In other words, a provider may want to guarantee 99.999% uptime as pertains to nonscheduled maintenance outages, but provide for a certain amount of downtime for upgrades an maintenance. 

Closing Thoughts

A solid understanding of the underlying technology, if not a technical mastery, is really a prerequisite for properly negotiating a SaaS agreement. As is the case with any contract, the drafter needs to be able to imagine all the potential scenarios that might present in the course of performance and account for them. If you were drafting a service agreement for the provision of transportation services for nuclear waste, you would engage experts to help ensure you were considering all of the potential risks - you wouldn't rely on your own reckoning just because you have seen Atomic Train. The same should be true for SaaS contracts: engage technical personnel and be realistic about your own understanding of the technology. Posting a meme on Facebook may not be sufficient technical savvy to negotiate the terms alone!

Delaware - Distributed Ledger or Blockchain Transactions in the Delaware General Corporation Law (DGCL)

If you haven't already heard of the Delaware Blockchain Initiative, you soon will. A proposed amendment to the Delaware General Corporation Law (DGCL) could revolutionize the way corporate finance is handled in Delaware and, as Delaware is the state of incorporation for more than three-quarters of the Fortune 500, the country at large.

What is a Blockchain?

A blockchain, in its use in finance, is essentially a decentralized and distributed ledger. In systems where physical pieces of currency aren't being handed back and forth like gold doubloons, the most pressing problem is keeping track of transactions. As digital currency is, at base, an electronic file that can be replicated without limit, the issue of double-spending becomes a concern. Double-spending occurs when one unit of currency is both spent and retained by the spender. With physical currency, this is not a significant problem – if there are 100 pennies in a system and, at the end of the day after all trading has completed, everyone counts their pennies, there will only be 100 pennies distributed amongst the traders. Individual traders may feel that they should have more pennies than they do, and indeed some thievery may have occurred between them, but the system itself will not be fooled. Thus digital currency must first tackle the problem of ensuring an accurate accounting of not only individual participant holdings, but the amount of currency in the system as a whole.

A blockchain can be most accurately described as a distributed or decentralized ledger. Digital currency that utilize blockchain systems take advantage of the same technologies as peer-to-peer file sharing systems. A peer-to-peer file sharing system has no centralized server that houses all of the data that is being shared. Instead, the data on the individual users' systems is shared with all of the other users of the system. For file sharing, this makes it difficult for law enforcement to crack down on copyright infringement. For digital currency, this ensures that there is no one source of data that, first, needs to be maintained by some oversight entity and, second, can be compromised.

When a transaction occurs, a transmission is made from the sending and receiving parties' currency system of choice, to the rest of the nodes, or users, on the system. It essentially transmits a message stating "Party A has paid Party B X amount." Individual nodes then confirm that this data is accurate – at base, that Party A has the funds to transfer to Party B and confirms the new amounts held by each party. Once confirmed, groups of these transactions are bundled together in to "blockchains" and distributed to the nodes of the system. In essence, imagine a blockchain as a notebook in which transactions are continually scrawled. When a notebook is filled, millions of copies of it are instantly made and distributed to all of the users of the currency. This ensures that, if someone tampers with a transaction in their notebook, the tampering comes out the next time the notebook is compared with all of the copied notebooks – the next time there is a transaction.

In addition to this distribution system, the innovation inherent in many digital currencies that use a blockchain system is that the units of currency exist only in the blockchains. In other words, whereas in a traditional ledger you would be writing down Party X gave $10 to Party Y and, after that writing, there would exist both the ledger and the $10 in Party Y's pocket, in most digital currency systems there is no currency that exists separate from the blockchain. Rather than opening your wallet to retrieve $10 to hand over to a seller for an item, with these digital currency systems you merely indicate to the distributed and decentralized ledger, the blockchain, that the 10 units that were attributed to you are now attributed to the seller.

How Can Blockchain Technology Impact Business?

In addition to the obvious potential for a shift in the way currency is handled, two exciting potential avenues for blockchain technology are distributed ledger shares and smart contracts.

Distributed ledger shares operate in much the same way that blockchain currency does. All participants in a particular market for shares share a single, decentralized database. Trades can be executed instantly and at any time, as there is no third party oversight. The added security and operational efficiency can substantially reduce transaction costs and, as a result, change the entire face of investment.

Smart contracts are contracts that can autonomously update, delete or otherwise be interfaced with when a specific condition is met, like an expiration or payout date. In essence, they are digital transaction protocols that can automatically execute the terms of a contract. The thought is that common contractual obligations can be handled automatically, without the need for human intervention, and thus substantially lower transaction costs. If an ordinary contract defines the rules of the road and outlines the penalties of violating them, a smart contract does the same but also automatically enforces the rules and reduces the likelihood of needing to pay penalties. Enforcement is decentralized through a blockchain in the same way that digital currency is: it is February 31, millions of people agree that it is February 31, and millions of people agree that our contract states you will pay me $50 on February 31; so on February 31, $50 is taken from your account and transferred to mine.

What is the Delaware Blockchain Initiative?

The Delaware Blockchain Initiative (DBI) is an attempt by the state to become more friendly to blockchain businesses and adapt its regulatory state to emerging technology. Then-Governor Markell launched the DBI in May of 2016, aiming to create a regulatory and legal environment for the development of blockchain technology and embrace its ability to reduce transaction costs. The Governor highlighted four facets of the state intiative.

First, to ensure that Delaware's regulatory environment is welcoming and enabling by observing the industry as it develops. The key here will be to walk the line between codifying an evolving and nascent industry at a point in time where it hasn't fully developed and failing to support an emerging technology. Best practices will need to be determined with the fully input of the community, industry, and consumer groups.

Second, to ensure that an appropriate legal infrastructure is in place for the oversight of a distributed ledger share system. Too much interference and innovation is stifled, too little interference and investors and companies are hesitant to get involved as they feel unprotected.

Third, an Ombudsperson, Andrea Tinianow, was named as the State Director of Corporate and International Development. A member of the Global Delaware Concierge Team, Ms. Tinianow is tasked with working with investors, entrepreneurs and executives to help ensure the DBI is a success.

Fourth, the Governor committed the state government to using blockchain technology, and announced that the Public Archives project would be the first entity on board. The Delaware Public Archives will use blockchain technology to archive and encrypt government archives. This will help not only ensure their security, but double as a backup and disaster recovery system.


Blockchain technology is promising, there is no doubt. All indications appear to be that it is gaining increased acceptance and adoption, and the important of Delaware throwing its weight behind the technology cannot be overstated. However, blockchain technology and the digital currency systems that use it are not without their detractors and black eyes. Bitcoin, the most famous digital currency, is viewed by many as the currency of the black market. Technology advances quickly, and it remains to be seen if blockchain technology can overcome its stigmas and gain widespread adoption before the next revolution in payment and ledger systems is developed. In either case, however, it appears Delaware is situating itself to be ready to cash in. 

Anatomy of a Software as a Service Contract - Hosted Services Provision

If you have specific questions regarding the hosted services provision, or any aspect of a Software as a Service Contract, please don’t hesitate to get in touch.

In the old days of software, deployment for a software company to a client entailed mailing a stack of floppy disks with a end user license agreement ("EULA") seal; the client broke the seal and the license agreement was agreed to. Maybe there was a prompt during the installation process for good measure. Internet connectivity was anything but ubiquitous and the idea of shipping software that heavily leaned on an internet connection, much less relied on connectivity, was anathema. The physical product being shipped was the software, true, but digital rights management ("DRM") was in its infancy, and making copies of the software was trivial. What was really being granted to the end user was a license to use that particular piece of intellectual property. 

Most work at the intersection of software and law revolved around the issuance of licenses and the formation of license agreements. Now, as internet connectivity has become all but a prerequisite for business (and, perhaps even more so, personal) life, there has been a rise in the use of software as a service at the enterprise level. Software as a service is an umbrella term for the concept of remotely hosted software, maintained and hosted by the software provider, licensed to users on a subscription basis.

Software as a service ("SaaS") brings unique challenges to the legal sphere. Chiefly, there is a shift from mostly license-driven agreements to what are in essence technology service agreements. (There are tax implications, as well -- but a topic for another day). Notwithstanding this shift of primacy, there are still elements in a SaaS agreement that call for relatively standard software license agreement language -- the license to use the hosted services, the permission to or restriction on sub-licensing, etc. In a series of posts, I am going to explore some of the main provisions and standard language in a SaaS contract, and outline some of the things to look out for and issues to consider. 

Hosted Services

The hosted services provision of a SaaS contract is, at its core, a grant of the right of the user to access the hosted software, a license to use the hosted software and all of the limitations therein, a service level agreement or promise of security and availability on the part of the software provider, and an agreement to an acceptable use policy on the part of the user. 

Grant of Access

"Software Co. shall create an Account for the End User and shall furnish the End User with the login username and password for that account on the Effective Date."

A license to use the hosted software platform without the actual technical instructions and ability to access the same would not be of much use to the end user -- leaving this provision out would be like shipping the EULA without an disks. In drafting, consideration must be given to the software platform: does the platform require someone to manually register a username and password for the new account? Is it done automatically as a process of the end user's agreeing to the contract? Being specific about the method by which the Account will be created lends more clarity to the contract and ensures all parties are aware of what to expect and what is expected of them.

Grant of License

"Software Co. grants to the End User a personal, limited, nontransferable, non-exclusive license to use the Services, through the use of their own Internet Access, for the Purposes outlined herein, for the duration of the Term. Software Co. retains all others rights to the Services, including those provided by copyright, trade secret and other intellectual property laws. You are only granted the right to use the Services for the Purposes for the duration of the Term."

A grant of a license to the hosted services is the flip side to the grant of access -- the grant of access provides the end user with the physical ability to access the software, and the grant of license outlines their permission to do so. 

An argument can be made that certain SaaS suites do not require a grant of a license to the software. A license grant to software is really only necessary when there is a copying or duplicating of the software. Thus, if a SaaS suite has some offline components (in other words it installs anything on the end user machine) it might still be wise to include a license grant. If, however, the software is entirely cloud-based, with no installation or "copying" for copyright purposes on the end user machine, then the omission of a license provision may be warranted. In such cases, it might be said that the software, housed and running on "Software Co." machines, is merely providing a service to the end user. In which case, just as an inventor of a special kind of wood splitter wouldn't need to grant a license to the customers he uses the chipper to split wood for, the SaaS company wouldn't need to grant a license to the software to the end user. Instead, the frame that the license should be viewed from is that it is a license to the service that the software provides

Scope of the Grant of License

"The license granted by Software Co. to End User in this section is subject to the following limitations: ..."

If a license is to be granted for the software, care will need to be taken to outline the scope of the license. Some things that need to be considered include: 1) is the license granted just to an individual user, or the employees of the user? 2) how many concurrent connections to the SaaS are permissible? are there technical reasons why one may want to limit the total number of users online at a given time? 3) will there be a schedule of permitted users, as in cases where there may be confidentiality concerns? 

Service Level Agreement

Service level agreements ("SLAs") outline the minimum service standards that are being guaranteed to the end user. Generally speaking, these include uptime guarantees (99.9%?), latency guarantees, and remedies available to end users should these standards not be met, or what sorts of force majeure events excuse all parties from performance. In addition, they may contain information regarding security and privacy, and time frames for service requests. 

Specific uptimes can be difficult to guarantee, and present their own challenges in drafting. For instance, will a third party service be used to monitor uptimes and report outages? What will constitute a loss of uptime? Complete software outage? Substantial? If 100% uptime and software availability is not something that can be guaranteed, it should be disclaimed. 

Latency is an even thornier subject, as the latency between any two servers on the internet can vary greatly based on regional issues and outages, network congestion, and other factors. Thus, having latency monitored by a third party may not be acceptable for an end user that isn't concerned with whether or not some neutral third party can reach the service. 

Perhaps most importantly, an SLA will typically contain a provision outlining the mean time to repair and the mean time to respond. In other words, how quickly Software Co. will respond to an issue, and how quickly they can guarantee and issue causing an outage will be remedied. Often time to repair and time to respond will be further sliced and distinguished according to issue severity -- so, for instance, a mean time to respond and repair to a complete outage might be substantially less than the time to respond to minor bugs and defects. Further still, enterprise SaaS SLAs will often contain another set of response times for certain specific users. The VP of Operations having an issue reading her email, then, may take precedence over the Associate Counsel whose calendar won't sync.

Finally, Saas SLAs will generally contain an outline of how service issues will be escalated. In other words, the name, number, and email address of someone on Software Co.'s side that will answer the phone when an issue presents itself that warrants more action than an ordinary support ticket system can muster.  

End User Policies

Finally, a Hosted Services provision will frequently contain an outline of what is and is not acceptable use for the end user. This often includes using reasonable methods and taking reasonable precautions to protect account details, not permit unauthorized access, and the like. This is a provision that will vary widely in length, complexity, and importance, based on the sort of software service being contemplated. The level of restriction can run the gamut from end users agreeing to only use the SaaS for the specific uses outlined in the agreement, to a simple "reasonable methods" boilerplate clause that holds the end user responsible for things done on the software using their access credentials.


In sum, the Hosted Services provision is among the most recognizable provisions in a SaaS agreement -- a holdover from days of yore. In future posts, I will go over provisions outlining support service, maintenance and updating, the licensing of the data put in to the SaaS by the end user to Software Co., and other considerations for data privacy and security. 

Note this post is for informational purposes only and nothing contained within should be construed or relied upon as legal advice. 

Telephone Consumer Protection Act (TCPA) -- New Decisions, Changes on the Horizon

The Telephone Consumer Protection Act 47 U.S.C. 227 (TCPA) has, for some time, been steadily increasing in inscrutability. In 2017 it appears set to continue this trend with new case law, even as FCC chairman and expansive-TCPA-interpreter Tom Wheeler cedes the agency's reins on January 20th, leaving the future of the act in new hands.

On the case law front, wasting no time in the new year, the Northern District of Ohio rendered a decision on January 3rd that, in effect, ensures manufacturers of products are not held liable for unsolicited (in this case, faxes) sent by third party entities, merely because the advertisement, if heeded by a consumer, would benefit the manufacturer's bottom line. To hold otherwise, the court was concerned, would give rise to "sabotage liability."

"By way of illustration, it would allow a rabid Tampa Bay Buccaneers fan – with a rhino helmet, red face paint, and an undying devotion to the organization – to trigger per se liability for the organization under the TCPA by gratuitously, and without directive from or notice to the organization, promoting season ticket sales via fax.  The same could be true of a random individual in Boston, mind brewing with scienter, who works to implicate the New York Yankees by advertising their season tickets.  Universal liability for complete inaction was not contemplated by Congress in passing the TCPA and does not appear to have been contemplated by the FCC in crafting and interpreting its regulations."

Thus, the pendulum that is the TCPA swings back, the definition of "sender" contracts -- if only in Ohio, if only for now. 

PrivacyAndrew Leaheytcpa, ohio
Privacy Policies for the Modern Web

Traditionally privacy policies have answered three general questions: (1) what user data is collected, (2) how that data is collected and (3) how that data is stored or used; generally, how that data is treated.  A privacy policy is a simple enough thing to draft when the entity directing the drafting is the sole party acting to collect and store data. In the case of the modern web, however, that is never the case. For the most part even the most basic of websites will utilize some content delivery network (CDN) to serve images and other larger files and embed code to track usage data. CDNs and analytics companies will, then, have access to non-personally identifiable information: internet protocol (IP) addresses, browser, operating system information, and display information, and in the latter case, referrer universal resource locators (URLs). More and more ecommerce sites are taking advantage of third party payment processors, rather than taking payments on-site and taking on the burden of security maintenance and all of the accompanying risk. In short, as more and more services are outsourced, the number of entities gaining access to some form of user information is directly correlated to the complexity of the website. Indeed, with the advent of third-party authentication services such as Facebook Authentication, Google OAuth and LinkedIn OAuth, user data is only becoming more removed from the control of the entity owning and operating even a relatively simple website.[1] This raises questions as to how one can best disclose the answers to the above three questions. 

What User Data is Collected

There are known-knowns, known-unknowns, and unknown-unknowns[2]. The data that is collected by the website owner is a known-known – you either do or do not offer a "Contact Us" form that collects and stores a user's name, email address and their comment. Without further investigation, the information obtained from a user choosing to use Facebook Authentication is a known-unknown – you are aware that user registration and login information is collected by a third party, but you don't know how that information is being stored. Unknown-unknown information is all of that information[3], potentially collected by a third party, that it is difficult or impossible to ascertain the storage and use of. For example, an analytics company that offers free user analytics services may be using the aggregated information in order to improve their other offerings. Their own privacy policies may only obliquely reference what aggregated information is used for and, as such, a privacy policy cannot in good conscience be drafted in a way that makes representations or warranties as to what information is collected by that third party.

How Data is Collected

Methods of collecting data is another area by which the complexity of a website significantly impacts the scope of the privacy concerns. The obvious first level collection schemes are all of those user-driven and user-chosen methods: contact forms, user registration, payment processing, email listserv subscriptions, etc. Second level collection schemes are those that can be ascertained by examining the website and its source – analytics and tracking scripts, calls to offsite-hosted images, cookies, etc. Third level collection schemes, which are the most difficult to know and thus disclose in a policy, are all those methods that are not either user driven or evident in the source of a website. For instance, an examination of the source of a website may indicate that a call is being made to a third party for a tracking script, but the source cannot and will not give guidance as to whether that third party is using data analytics on their own server logs to form a more complete picture of a user, or tracking the user across multiple websites.[4] How information is collected is more difficult to disclose, then, as the owner of the website can realistically only indicate how they think information is collected, what information is collected that they are privy to, and the identities of some of the entities that they have chosen to collect information.   

How Data is Stored or Used  

So-called "Right to be Forgotten" European Union laws aside, if there is one immutable fact about the internet, it is that anything that is on it, remains on it. In the early days of the web, a privacy policy could give users an accurate picture of how long information that is collected about them will remain – a quick call down to IT would be all that was required. In the modern web, a visit to a website is more akin to tossing a stone in to a pond. A rudimentary privacy policy can describe the splash, a well-drafted policy can predict some of the ripples, but no policy will be able to describe the effect on the shoreline. To abandon the metaphor, a privacy policy can be drafted to outline how long the website owner intends to hold on to user information and how long third-party services tied to the website claim to retain user information, but it can never tell a user with an accuracy how long it will be before their visit or use of the site is "forgotten." 


1. To the extent that you can, disclose.

The above may serve to discourage an individual from bothering to draft a policy at all, but this is not the intent. Information privacy was hardly in the public discourse twenty years ago. The first discussions of privacy mostly centered around personal healthy information, later turning to contact information, with the advent of do not call registries, and financial information, as identity theft has become more common. Moving forward, the trend line would appear to point squarely in the direction of privacy becoming more important and more relevant -- the European Union and the State of California have already adopted laws mandating as much.

As such, not surprisingly, the solution to privacy policies lagging behind the increasing complexity of the web is … increased disclosure. To the extent that you know what information is collected, stored and used, disclose it. To the extent that you know what information MIGHT be collected, store and used, disclose it. Where you aren't certain of anything, disclose the entities that you have contracted with to provide services that might be collecting information and link to their privacy policies. Don't work with entities that do not provide privacy policies that at least give some modicum of explanation as to how information is collected, stored and used. 

2. Offer an up to date list.

In your privacy policy, elect a Data Controller and allow users to reach out to them to obtain an updated list of all the companies (third party service providers, mail carriers, hosting services, IT companies, communications companies, analytics companies, advertisers, etc.) that may be processing user data. Maintain the list and, where possible, post it and link to it in your privacy policy.

3. Update your policy frequently.

The privacy policy of a website cannot be thought of as a set-it and forget-it static page -- just as the rest of your website is evolving, so too must your policy. At regular intervals have your policy reviewed and updated to reflect features added or removed from your site, third parties contracted with or released, and changes to third party's policies.

4. Demand more.

Think of yourself as a steward of your user's information. When you choose a new product, contract with a new party, or implement a new feature, call on the entity you are working with to provide you with answers to the aforementioned three questions: what information is collected, how that information is collected, and how that information is used. It is more than just a nice thing to do for your users, it helps ensure that, as privacy becomes more and more of a hot button issue, you remain ahead of the curve and needn't fear having to fix a problem that could have been prevented through good management.


[1] Indeed, to want to make use of a third-party authentication service the website owner need only wish to save user preferences with slightly more granularity and permanence than a traditional "cookie" can provide. The availability of free authentication services through Facebook, Google and LinkedIn, among others, creates a situation where the entities that are seeking the most cost effective and simple method to permit users to have an account on their website are the ones that need to draft the more sophisticated privacy policy.


[3] Generally speaking this will be non-personally identifiable information – IP addresses, regional location data and the like.

[4] The concern being, at some point, a certain order of magnitude of non-personally identifiable information is personally identifiable information – enough individual data points and the number of individuals that fit all of those points eventually drops to one.