www.andrew.legal
architecture-1081912_1920.jpg

andrew.legal | Tax consultant, technology and law consultant

Infrastructure Bill - Carbon Dioxide Capture Facilities

The infrastructure bill that made it to the President’s desk earlier in the week contained a provision allowing for a new type of tax exempt private activity bond (Section 142(a)) for carbon dioxide capture facilities.

The bill allows for financing facilities and eligible components of facilities that are used for the purpose of capture, treatment and purification, compression, transportation, or on-site storage of carbon dioxide.

The general rule requires such a facility or component to have at least a 65% capture and storage percentage, but permits for an alternative calculation:

`(C) Capture and storage percentage.--

                ``(i) In general.--Subject to clause (ii), the capture 

            and storage percentage shall be an amount, expressed as a 

            percentage, equal to the quotient of--

                    ``(I) the total metric tons of carbon dioxide 

                designed to be annually captured, transported, and 

                injected into--

                        ``(aa) a facility for geologic storage, or

                        ``(bb) an enhanced oil or gas recovery well 

                    followed by geologic storage, divided by

                    ``(II) the total metric tons of carbon dioxide 

                which would otherwise be released into the atmosphere 

                each year as industrial emission of greenhouse gas if 

                the eligible components were not installed in the 

                industrial carbon dioxide facility.

This should provide a boost to carbon sequestration development.

Tax Law Listserv - TaxMailingLists.com

I try to keep self-promotion on this page to a minimum, keeping posts more of a general interest/practice point nature, but I have started a pair of new projects and wanted to share. First among them, TaxMailingList, which is exactly what it says on the tin: a tax law list serv. I try to keep the topics current and of a general tax nature, but they do tend to have a bent similar to my own and thus often revolve around tax and technology.

More to come (probably) on the other endeavor.

Andrew LeaheyComment
Draft Infrastructure Bill and "Qualified Broadband Expenses"

The House Ways and Means committee draft of the infrastructure bill is out, and it contains a number of provisions at the intersection of tax and technology. One such provision, the Credit for Operation and Maintenance Costs of Government-owned Broadband, provides for credits to governmental entities that incur costs for “qualified broadband expenses,” which are amounts paid or incurred for the provision of broadband services to qualified households. Qualified households being those low-income households (as defined under Section 45D(e)) that did not have access to said services prior to the start of the taxable year.

This reliance on Section 45D effectively ties the broadband program on to the New Market Tax Credits program. One potential issue here is that there have been several high profile examples of “low-income” tracts actually being anything but — the Blackstone Hotel in downtown Chicago comes to mind. Attention will need to be paid to the program moving forward to ensure it remains in line with its legislative purpose.

If you’re interested in matters at the intersection of tax, law, and technology consider signing up for our mailing list at TaxMailingList.com. No spam, we promise.

DPA Agreement Template - GDPR

DOWNLOAD OUR TEMPLATE HERE

If you have specific questions regarding the GDPR generally or data processing agreements specifically, please don’t hesitate to get in touch. This article should not be relied upon, and is not being presented as, legal advice. This is a complex area of privacy law and you cannot base your decisions on a cursory overview of the topic, such as this one.

A DPA agreement or Data Processing Agreement is one entered into between the data controller and data processors, under the GDPR. The purpose of a DPA agreement is to evidence the compliance of the data processor with relevant GDPR requirements.

Why do we need this?

It is a requirement under the GDPR if you contract out the processing of data.

What is required to be included in a DPA agreement?

Under Article 28(3) of the GDPR, a DPA must include, at least, provisions stating that the processor:

(a) processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the processor is subject; in such a case, the processor shall inform the controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest;
(b) ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
(c) takes all measures required pursuant to Article 32;
(d) respects the conditions referred to in paragraphs 2 and 4 for engaging another processor;
(e) taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III;
(f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor;
(g) at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data;
(h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller.
With regard to point (h) of the first subparagraph, the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions.

DOWNLOAD OUR TEMPLATE HERE

Crypto Mining Income Tax

TLDR: Bitcoin (or other cryptocurrency) mining is subject to income tax, typically as ordinary income. Your basis in the coin is the price of the coin at the time it was mined. There are no like-kind exchanges for coins, so selling one coin to buy another is a taxable transaction. Any gains over your basis are capital gains, and may be long term or short term depending on the period of time you held the coin for.

Mining

The Wall Street Journal recently reported the IRS is forcing cryptocurrency exchanges to give up names of customers in order to pursue unpaid taxes on mined and arbitraged coins. This reporting is, for many, likely the first they have heard of a tax on cryptocurrency. While there is no cryptocurrency-specific tax, you should consider mining the equivalent of a part-time independent contractor job for tax purposes – your employer is not taking taxes out of your paycheck, and it is your duty to report your earnings. Similarly, the buying and selling of coins is not dissimilar from the buying and selling of stocks. Taxes on ordinary income and capital gains, respectively, will apply. 

In 2014 the IRS issued IRS Notice 2014-21, which clarified that a taxpayer that mines crypto currency must take the value of the virtual currency as of the date of mining as gross income. A mined coin is a taxable event and thus carries with it income tax implications. Mining must be voluntarily reported as, in general, successfully mined coins are not reported to a taxing authority in the same way income via employment is.

Selling cryptocurrency, even to purchase another coin, gives rise to another taxable event. The difference between your basis in the original currency and what you sell it for will determine whether you have a capital gain or a capital loss. Capital gains can be either short term or long term, depending on the period of time the asset (here, the coin) had been held. Capital gains will be taxed at the capital gains rate, which differs from ordinary income, and capital losses can be used to offset capital gains with some limits and restrictions. 

Deductions can be taken, generally, for costs inherent in mining – things like electricity, equipment, and repairs. 

Care must be taken to keep accurate records and report income earned in mining on-time and precisely. This article is not tax advice and is not legal advice. If you reached this page just searching for information and you don’t have a tax issue, I hope it has been helpful. If you believe yourself to owe taxes, don’t rely on information you find on the internet. Consult a tax attorney. If you have any questions feel free to get in contact

Is SaaS Subject to Sales Tax?

First, it is worth outlining from a technology perspective what software as a service (“SaaS”) is. SaaS is a method of software delivery whereby the software is hosted in one place (on the “server”) and use is permitted by the customer during the payment period and with certain restrictions. You will often read references made to a “software license” for a SaaS product — this is a misnomer. As SaaS contemplates the provision of a service, there is no software being licensed but only a service being rendered.

Next, we need to outline (to the extent we can) what SaaS is from a legal and sales tax perspective. Unfortunately, this is where things get murky. While a SaaS product is indeed a service, and not a piece of tangible software, many states tax authorities have not woken up to that fact — some treat SaaS products as software products like any other. In those states, generally speaking, a SaaS product is considered a tangible good and is therefore subject to state taxation the same way it would be if the software was delivered on a physical disk (Washington state is an example of this treatment).

For those states that do not treat SaaS as a tangible good, the question is whether a service is subject to state taxation. If services are taxable, software as a service is taxable; if services are not, generally software as a service is not.

It can be a difficult task to navigate state tax law. If you have specific questions, I’m here to help. Otherwise, make sure you seek the guidance of an attorney before choosing to not charge sales tax, and don’t leave it up to a Google search.

If you’re interested in matters at the intersection of tax, law, and technology consider signing up for our mailing list at TaxMailingList.com. No spam, we promise.

CARES Act 401k Withdrawal - Permitted, But Avoid?

Everyone is feeling the pinch of COVID-19 financially. If you’ve been hit especially hard, you may be looking at ways to leverage savings and investments to bridge the gap. The CARES Act opened up one such avenue in to 401k savings — withdrawals of up to $100,000 will not be subject to the standard 10% early withdrawal penalty for individuals under 59 1/2 years of age provided the withdrawal is paid back within 36 months. With the future of the economy very much uncertain, each investor—borrower will need to consider carefully whether they expect to be in a financial position to repay their withdrawal in the next three years. Read my full article in April’s Tax Notes.

As always, if you have specific questions regarding 401k withdrawals, please don’t hesitate to get in touch. This is a complex area of tax law and you cannot base your decisions on a cursory overview of the topic, such as this one.

If you’re interested in matters at the intersection of tax, law, and technology consider signing up for our mailing list at TaxMailingList.com. No spam, we promise.

Checklist for Qualified Opportunity Zones - Real Estate-Only

If you have specific questions regarding the qualified opportunity zones, please don’t hesitate to get in touch. This “checklist” should not be relied upon, and is not being presented as, legal advice. This is a complex area of tax law and you cannot base your decisions on a cursory overview of the topic, such as this one.

Under the Tax Cuts and Jobs Act (Pub. L. No. 115-97 (2017)), additions were made to the Internal Revenue Code (the “Code”) to provide for tax benefits for investors that invest in Qualified Opportunity Zones (QOZs). These benefits include:

·         Deferred recognition of capital gains for Qualified Opportunity Funds (“QOFs”);

·         Reduction in amount of recognized deferred capital gains by an increase in basis; and

·         Exemptions from taxation of appreciation in QOFs if requirements are met.

In the attached we have outlined some of the pertinent aspects of QOZ regulations and requirements in order to more succinctly present a checklist of requirements for the creation of a real-estate only QOF.

For clarity, we have omitted any reference or analysis to forming and capitalizing a QOF with an eligible gain, as this is outside the scope of this paper series. We have also not outlined the process of offering QOF investments for sale, for the same reason. These will be the subject of future writing series.

Download the Checklist for Real Estate Only Qualified Opportunity Zones

TaxAndrew Leaheyqoz, qof, taxComment
Software as a Service - Service Level Agreement Template

Drafting a service level agreement or reviewing an existing one?
Let me do it for you for a flat $200 fee -
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 install 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 a 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. I charge a nominal fee for the form.

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

NYTimes

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. 

Adjustments

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. 

Ownership

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.

Conclusions

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.