Buy now from:

• Amazon.com
• Barnes and Noble
• iUniverse

SPEAKING ENGAGEMENTS:
Author David Tollen speaks on technology legal issues.

Sample Text

Table of Contents
Introduction
Sample Chapter: Standard End-User Software License
Sample Chapter: Warranty

Table of Contents

Introduction	1
Software, Services, and IT	2
Three Lessons about Contracting	3
The Structure of a Contract and of this Book	5
Using This Book	6
I. Transactional Clauses	11
A. Standard End-User Software License	12
1. End-User Rights	13
2. End-User Restrictions	14
B. Standard Distributor Software License	16
1. Distribution Rights	17
2. Distribution Restrictions	18
C. Software Licenses in General	20
1. Copyright License Rights	21
2. Scope Terms	25
3. Unrestricted License	29
4. Open Source License	29
D. Software Ownership: Assignment and Work-for-Hire	32
1. Assignments	33
2. Work-for-Hire	35
E. Promise of Professional Services	39
1. Defining the Service	40
2. Change Orders and Midstream Terminations	41
3. Multiple Statements of Work	43
4. Experience and Qualifications	46
F. Promise of Machine-Based Services	47
G. Payment	49
II. General Clauses	52
A. Technical Specifications	53
1. The Importance of Specifications	55
2. Responsibility for Specifications	55
3. Editing Specifications	56
B. Service Level Agreements	57
1. SLA Remedies	57
2. Refunds after Termination	59
3. The Material Breach Issue	60
C. Warranty	61
1. Warranty of Function	61
2. Infringement/Ownership Warranty	63
3. Other Warranties	63
4. Exclusion of Warranties	65
5. Remedies for Breach of Warranty	67
D. Schedule and Milestones	70
E. Delivery, Acceptance, and Rejection	72
F. Indemnity	75
G. Limitation of Liability	78
1. Dollar Cap	79
2. Exclusion of Consequential Damages	80
3. Exceptions: Liability That's Not Limited	81
H. Confidentiality / Nondisclosure	83
1. What's Confidential?	83
2. Restrictions on Use	85
3. Injunction Remedy	86
4. Termination and Return	87
I. Technology Escrow	88
1. Deposit and Verification	89
2. License and Confidentiality	90
3. Release and Other Issues	91
J. Software Audits	93
K. Updates and Upgrades	94
L. Documentation	96
M. Use of Trademarks	97
N. Training	99
O. Non-Compete Clauses	100
P. Liquidated Damages	104
Q. Dispute Resolution	107
R. Term and Termination	110
1. Term	110
2. Termination for Cause	111
3. Termination for Convenience	112
4. Effects of Termination	113
S. Everything Else	115
III. Supporting Clauses	116
A. Introduction and Recitals	117
B. Definitions	117
C. Time Is of the Essence	118
D. Independent Contractors	118
E. Choice of Law and Jurisdiction	118
E Notices	119
G. Government Restricted Rights	119
H. Technology Export	121
I. Assignment	121
J. Force Majeure	122
K. Severability	122
L. No Waiver	122
M. Conflicts among Attachments	122
N. Construction	123
O. Entire Agreement	123
Appendix: Contract Form	125
Index	137

[↑] Back to top

Introduction

This book will help you negotiate, write, and understand information technology contracts. Specifically, it will help you with software licenses and other software transfers, as well as technology services agreements. It focuses on business deals, rather than consumer contracts.

This book is for both lawyers and non-lawyers. The text doesn’t use any technical jargon—any “legalese,” “engineerese,” or “programmerese.” It’s written in simple English, like a good contract.

You can use this book as a training manual or as a reference guide, or both. If you’re training, read this book cover-to-cover. It provides an overview of the key technology contracting concepts. A cover-to-cover review will be particularly useful if you’re new to the field.

If you need a reference guide, on the other hand, you can pick and choose the sections to read. If you’re negotiating a contract, or reading or writing one, look up the various clauses to learn what they mean and what’s at stake. You can also use this book as a source of sample contract language. Each listing includes one or more example clauses. And the appendix, starting on page 125, contains a full-length contract form. (Currently, you can download that form, free of charge, at this book’s website: www.TechContracts.net.) Finally, you can use this book—particularly the table of contents—as a check-list for clauses to consider.

This book can’t replace a lawyer—or a colleague with more IT contracts experience, if you are a lawyer. But it can help you understand your lawyer—or colleague. And whether you have legal help or not, the better you understand your contracts, the more effective you will be.

I’m a technology lawyer, and this book grew out of a seminar I teach, for both attorneys and non-attorneys. At the end of the program, students would often ask where they can learn more—if there’s a good book on software and services contracts. Most of the books I knew were massive tomes on intellectual property or contract law. They’re written for lawyers only, and their more practical lessons are spread across hundreds or thousands of pages. I had learned much of my trade on the job, rather than from a book. I’ve served as a technology lawyer with a global firm, as general counsel for a publicly traded software company, and as vice president of business development for an Internet start-up. I now practice through my own technology-focused law firm in San Francisco. The material for my seminar came from the contracts I’ve negotiated and written in those positions. I’d never seen a really concise outline of the issues, except my seminar agendas and instructor’s notes (the latter only half legible, even to me). So I wrote this book.

The rest of this introduction provides more detail about the types of contracts this book covers. It also teaches three lessons about contracting in general. Finally, it explains the structure of a contract and of this book, and it offers a few explanations that will help you get the most out of your reading.

Software, Services, and IT

This book covers (1) software contracts, (2) information technology services contracts, and (3) combination contracts, which include both software and services. The text calls the parties to all these agreements the “provider” and the “recipient.”

Software contracts include end-user licenses, assignments, work-for-hire agreements, and distribution agreements (including value-added reseller and original equipment manufacturer licenses). In all of these deals, the provider transfers intellectual property (“IP”) rights to the recipient. Those rights might be limited, like the right to copy or distribute software. Or the recipient might receive all IP rights and become the software’s new owner.

Services contracts call on the provider to help the recipient, rather than to provide software or IP. The provider is going to do something. In the information technology (“IT”) industry, that help generally has something to do with software and computers. IT services include data management, network management, technology maintenance, system integration, and integrated circuit design, to name just a few. IT also includes the computer-related activities of both the Internet and the telecommunications industry. So IT services include website development and provision of Internet access.

Finally, in a combination contract, the provider agrees to provide both software and services. Computer programming contracts, for instance, usually call on the provider to write software, a service, and to transfer IP rights in that software. Technology integration agreements often work the same way: the provider licenses or sells software to the recipient, and also provides a service by integrating all those applications into a computer system. A combination contract works like two contracts in one. It needs terms appropriate for both software and services.

Three Lessons about Contracting

1. Good fences make good neighbors.

Why do we sign contracts? It’s not because we want to win a lawsuit later. It’s not because we don’t trust each other. It’s not even because we’re afraid lawyers will stir up trouble if they’re not kept busy.

We sign contracts because good fences make good neighbors.

The best way to avoid arguments in a business relationship is to write down the parties’ expectations ahead of time. That list becomes a boundary-marker—like a fence between neighboring yards—explaining who is responsible for what. If the parties disagree, they can look at the list for guidance. Usually, that list becomes a contract.

In other words, contracts prevent disputes—at least, good ones do. They prevent lawsuits.

Even if the parties never look back at the contract once it’s signed, it still has probably played a vital role. When people put their business expectations on paper, they often find those expectations don’t match. Just the act of negotiating a written(1) contract will uncover many mismatched expectations. The parties can address them before starting work.

Yes, it is true that we sometimes fight over contracts in lawsuits. And yes, in interpreting a contract, we often talk about what a judge would say it means. But that’s only because courts have the ultimate say, if the parties can’t agree. Job number one for the contract is to keep the parties out of court.

2. There is no such thing as “legalese” or “technicalese.”

You may feel uncomfortable with contracts because of the unfamiliar language they use. Don’t be intimidated. You can understand most contracts.

There really is no such thing as legalese. American contracts are written in English (or Spanish or Vietnamese or whatever language the parties speak). But contracts do sometimes use special shorthand—terms lawyers have developed to save time. And some IT contracts use “technical shorthand.” Finally, contracts sometimes use formal, stilted language with long run-on sentences. Don’t let shorthand or stilted language bother you.

If you run into an unfamiliar term in a contract—unfamiliar shorthand— don’t worry. Look it up. If it’s legal shorthand, you can probably find the definition in a standard dictionary, or online, or in Black’s Law Dictionary,(2) found in many libraries. Or, better yet, ask a lawyer. Treat technical terms the same way. Look them up in a dictionary or technical manual or online. Or ask someone with the right expertise.

Once you understand a term, feel free to use it in your own contracts. But you should also feel free not to use it. Shorthand is optional. If you do use shorthand, be sure the contract defines each technical term. Definitions can vary for IT terms like “RGB” and “bot,”(3) so the contract needs an agreed definition, unless there really can’t be any doubt. (See The Structure of a Contract and of this Book, on page 5, for more on defined terms.) Legal terms, on the other hand, often have widely-accepted definitions, so you usually don’t need to define them in the contract.

As for long sentences, just take a deep breath and read slowly. The same goes for formal language. There really is no reason to use terms like “heretofore” and “ipso facto.” That sort of language often appears in form contracts from the olden days, when formal writing was more popular. It does crop up in modern contracts—often because someone wants to show off a big vocabulary. Be suitably impressed. Then take out your dictionary if necessary, and figure out what each sentence says. And avoid terms like that in your own writing.

3. Leverage is everything; “fairness” is nothing.

A lot of people who negotiate contracts get tied up in knots over what is fair. They feel outraged if they’re “forced” to sign an “unfair” contract. That’s a bad way to look at contracts. You will do better if you think about leverage, not fairness.

In general, no one has to sign a contract. So if you do agree to terms you dislike, terms that seem “unfair,” you probably are getting something worthwhile. Obviously, you’re not getting as much as you wanted, but you wouldn’t have agreed if the exchange wasn’t better than nothing—better than not doing business at all. So long as no one’s pointing a gun at your head (or otherwise forcing you through illegal “duress”), whatever terms you accept are probably fair.(4)

So if considerations of fairness aren’t decisive, how do the parties resolve differences of opinion during negotiations? What guides the arguing and negotiating, and the eventual compromise or knuckling-under that leads to a contract? The principle in question is leverage.

If you need the deal more than the other party, you will probably give more. And visa-versa. It’s that simple. Don’t get upset about it, and when you’re in the power position, don’t take advantage of it too much. You never know when positions will reverse.

Footnotes

1 Many contracts can be oral rather than written, but some can’t. And oral contracts have serious disadvantages. Without a clear recording of the terms, the parties have to rely on memories, so the contract won’t serve as much of a roadmap. And oral contracts usually cover only high-level issues, leaving doubt about whether the parties actually agree on vital details.

2 From the West Publishing Company.

3 “RGB”: red-green-blue, a term used for computer screen technology. “Bot”: a soft
ware program that mimics human behavior, in that it’s automated, (short for
”robot”).

4 OK, that’s not entirely true, at least as far as the law is concerned. There are some
terms courts won’t enforce because they’re “opposed to public policy.”

[↑] Back to top

Sample Chapter: Standard End-User Software License

End-User Rights
End-User Restrictions

A copyright license grants the recipient rights to copy software or to exploit it in other ways. It leaves ownership with the provider. A license works like a rental agreement. The provider/landlord still owns the house, but the recipient/tenant gets to use it.

This section looks at standard end-user licenses. It doesn’t go far into the mechanics of copyright licensing, because that kind of knowledge isn’t always necessary to understand a standard license. But if you want a deeper understanding of licensing, or if your license isn’t standard, see Software Licenses in General, Section I.C, on page 20.

In a standard end-user license, the recipient will run the software for internal business purposes, like word processing, data management, etc. The recipient won’t share the software with third parties: it won’t rent software out to its own customers, for instance. Therefore, the contract doesn’t need a lot of detail about how the recipient can run the software.

Before turning to the terms of an end-user license, ask yourself: what is being licensed? The contract should clearly define the “Software” or “Licensed Product”—in the license clause itself, or in a separate definitions section. In a standard license, it’s usually enough to give the software’s name and version number, and specify object code: ”’Software’ refers to Provider’s GlitchMaster software application, version 3.0, in object code format.”(1) But if the software has multiple modules or libraries or whatever, or if you see any chance of dispute about what’s included, list the necessary elements—and involve someone with a technical background if necessary. “’Licensed Product’ refers to Provider’s VacuumEx for the PC software application, version 4.05, in object code format, including the following modules: VacuumManager, Client Controller, and Rug Stopwatch.” You might also specify the platform: Windows, Macintosh, Linux, etc. Finally, if the recipient needs to reproduce user manuals and other documentation, the definition should include them: “The Licensed Product includes Provider’s standard user manuals and other documentation for such software.”(2)

1. End-User Rights

A license is a grant of rights. A standard end-user license grants the right to “reproduce” software, the right to “use” it, or both.(3)

The license should specify the number of copies the recipient can make and use (even if that’s “1”). The clearest way is to list a number, as in the first example in the clause box above. Sometimes, however, the provider isn’t concerned with the number of copies, and the parties agree on an “enterprise license,” as in the second example above. A provider should only grant an enterprise licenses if it knows the size of the recipient’s business and knows it won’t expand much—or if the fees are high enough to cover any likely expansion. Also, providers—particularly of enterprise licenses—should consider restricting the software to the recipient itself and forbidding use by subsidiaries, parent companies, and other affiliates. Again, see the second example.

A standard end-user license should also specify that the recipient can use the software only for “internal business purposes,” as in both examples in the clause box above.

Finally, every license should confirm that the recipient receives no ownership rights. See both examples in the clause box.

2. End-User Restrictions

A key restriction in any end-user license is time: when do the recipient’s rights expire? If the license clause says nothing on the subject, the rights expire when the contract terminates.(4) The clause can also specify its own date: “Provider hereby grants Recipient, during the two (2) years following the Effective Date, a license to….”

End-user licenses generally limit the recipient’s use of software in other ways.

The provider should make sure the recipient receives only those rights specifically granted, as in the example in the clause box above.

An end-user license should also list certain rights not granted. Copyright law grants several exclusive rights to copyright owners. Providers should make sure the license doesn’t grant any of these except the right to reproduce (along with the right to use, which isn’t actually mentioned in the copyright statute). That’s why the example in the clause box provides that the recipient can’t exercise the other rights of copyright holders. It can’t distribute, modify (create derivative works from), or publicly display or perform the software. The recipient also can’t sublicense its rights to anyone else. Of course, if the clause is silent on restrictions, a court will probably consider the license limited to the rights specifically granted. But why take chances?

The provider should also clarify that the recipient gets no time-sharing or service bureau rights, or any other rights to share the software with third parties.

“Time-sharing” means sharing an application with customers or other third parties: letting them use the software too. “Service bureau” usage involves another type of sharing: the recipient keeps the software, but it uses it to process third party data, instead of its own internal data. Either could cost the provider sales.

Finally, the provider should be sure the license forbids reverse engineering and any other attempt to derive source code from the software.(6)

Footnotes

1 “Object code” generally refers to code a computer can read. It’s also sometimes called “machine-readable code.” Object code is contrasted with “source code”: code a human programmer can read, which gets “compiled” or translated into object code. Those are simplified definitions though, so consider doing some research or getting technical help if you need to understand code types better.

2 For more on documentation, see Documentation, Section II.L, on page 96.

3 IP lawyers debate the value of “use” rights in copyright licenses, but they’re fine for
purposes of this Section. If you’d like to know more about the debate, see Software
Licenses in General, Copyright License Rights, Subsection I.C.1, discussion of Use (a
pseudo-right) on page 24.

4 See Term and Termination, Section II.R, on page 110.

5 “Without limiting the generality of the foregoing” is a quick way to say: “The last
sentence gave the general rule. This sentence gives examples of that rule in action,
but they’re not the only examples possible.” In the clause above, the phrase means
the recipient only gets the rights specified. The fact that the next sentence lists certain rights withheld doesn’t mean the recipient gets all other rights not specifically
withheld.

6 “See the footnote on page 12 for a definition of "source code."

[↑] Back to top

Sample Chapter: Warranty

Warranty of Function
Infringement/Ownership Warranty
Other Warranties
Exclusion of Warranties
Remedies for Breach of Warranty

A warranty promises that something is true. It’s a guaranty. A warranty can cover any topic, and it can come from either the recipient or the provider, though provider warranties are more common. Providers often warrant that software or other goods will work, at least for a certain period. They also often warrant their right to transfer intellectual property. Warranty clauses may also list remedies for breach of warranty.

Warranty clauses are appropriate for most end-user software licenses. They’re also appropriate for distribution agreements, if the distributor needs the sort of protections a recipient would get. Warranties are less common in services contracts, though not uncommon. (The examples below, however, all relate to software agreements.)

Warranties pack more punch than other representations. The warrantor is held more strictly to its word. It’s not always clear, though, how to draw a line between warranties and garden-variety representations. The use of the term “warranty” or “warrant” helps establish warranty status, but it’s not strictly necessary. In general, if one party represents a fact, and the other decides to sign the contract in reliance on that fact, the representation is probably a warranty.

1. Warranty of Function

The warranty of function promises that software will “work.”

What does it mean to warrant that software or services will “work”? A clear warranty clause answers that by referring to the contract’s technical specifications, as in the first example in the clause box above. In other words, the warranty says that the software will perform as required in the technical specs attached to the contract.(1)

Unfortunately, warranties of function are often much less clear. For instance: “Provider represents and warrants that the Software will be in good working order.” Ugh. What does that mean? A slight improvement might read that the system will “perform according to its documentation.” But what is documentation? Brochures, e-mails from salespeople, ads posted online…? If you’re going to reference documentation not attached to the contract, state which documents you mean. For instance, the provider might put a label or stamp on official documentation, as in the second example above. That clause is more or less adequate, assuming the provider is careful to stamp “Official Product Documentation” in the appropriate places—and assuming there can be no doubt which documents qualify, those documents are clear, they explain what the product is supposed to do (like technical specs), and the recipient has reviewed them.

The provider can warrant just about anything in terms of functionality. Some warranties are customized and address the particular needs of the deal. For instance: “Provider warrants that no Deliverable, when installed, will impair the System’s ability to process purchase and sales transactions at the speeds set forth in Exhibit C.”

Providers often qualify warranties of function by requiring only “material” conformity with specs or with other requirements, as in the first example in the clause box. If every glitch counted as a breach of warranty, the provider would be in trouble. The use of “material” excludes unimportant errors.

Finally, warranties of function often have time limits, as in both examples above. If the goods stop working the day after the warranty expires (as required by Murphy’s Law), the provider is off the hook. But a time limit is not required. The provider could warrant the goods indefinitely or “during the term of this Agreement.”

2. Infringement/Ownership Warranty

The infringement or ownership warranty guarantees property rights, particularly rights in intellectual property. It promises that no third party will come along and keep the recipient from using the software or the rights transferred, through a claim to own them. In other words, the provider is saying, “We guarantee we have the authority to license these IP rights.” Infringement warranties are appropriate for nearly all software contracts.

Some providers balk at the IP side of this clause: “How can we guarantee that? There are millions of patents, covering all kinds of technologies. How can we possibly be sure our product doesn’t infringe one of them?” The answer is that the provider can’t be sure. Nor can most providers be sure their engineers didn’t illegally copy a few lines of code. But providers don’t need to be sure because this warranty isn’t about certainty. It’s about allocation of risk. The warranty provides that the provider, not the recipient, bears the legal risk that the goods infringe some third party’s IP. That’s usually appropriate because it’s the provider’s product. The provider is in a better position to create safeguards: to do a patent search, to hire engineers who are honest and careful, etc.

That’s not to say the provider has to accept that risk. If the provider has leverage, it can refuse to guarantee IP rights or general ownership rights.

3. Other Warranties

Warranties can cover almost any topic. The examples in the clause box below are common, but you should craft whatever language fits your deal.

The third example in the clause box protects software distributors against open source software provided with a “copyleft” or “viral” license.(2) The fourth promises that services will be “workmanlike”: a somewhat vague but common term meaning professional and skilled. The others should be self-explanatory.

Remember that warranties don’t truly promise a state of affairs. Rather, they shift legal risk. So the provider might not actually be able to guarantee that it won’t deliver a computer virus, or that its services comply with every conceivable law— as in the second and last examples above. But the provider can promise to take the blame for a virus or a broken law or anything else. It can accept the legal risk.

4. Exclusion of Warranties

The vast majority of software and services contracts include a disclaimer of implied warranties, like the first example in the clause box above. The laws of most states impose certain warranties on sales contracts, even if those warranties are not actually written down. The two of greatest concern are the implied warranty of merchantability and the implied warranty of fitness for a particular purpose. “Merchantability” warrants, among other things, that the goods will do what they’re supposed to do: they are fit for their ordinary purposes. That makes sense for cars and toasters, because everyone knows what they do. But software and IT services have many complex functions, and reasonable minds can differ about their ordinary purposes. So providers almost always disclaim the implied warranty of merchantability.

“Fitness for a particular purpose” warrants that a product will be appropriate for the recipient’s unique needs. In the IT business, the provider often doesn’t fully understand the recipient’s needs, or know them at all. So providers specifically disclaim the implied warranty of fitness for a particular purpose.

Disclaimers of implied warranties are appropriate for both software and services contracts.(3) Courts are often receptive to arguments that the recipient didn’t understand the clause’s importance (particularly if the recipient is a consumer). So the disclaimer should be conspicuous, appearing in all caps.

Another common disclaimer relates to misuse of the Software. If the recipient modifies the software and that leads to a malfunction or a third party suit, the provider is not responsible. The same goes for the recipient’s use of the software on an unauthorized platform. See the third example in the clause box above.

Still another common disclaimer relates to third party components. A provider might design and sell a computer system that includes hardware and software from third parties, as well as its own software. Since the provider didn’t produce the third party components, it might not be able to trust them. Worse, the third parties might have given the provider a weak warranty, or none. So the provider could find itself on the hook alone. The solution is to pass through any third party warranties to the recipient and disclaim any other warranty on third party components, as in the last example in the clause box above.

Of course, this sort of pass-through causes problems for the recipient. If the system doesn’t work, the provider and third party manufacturer will likely blame each other. That’s why many recipients argue that, if the provider resells the third party component, it should take responsibility for it. Otherwise, why doesn’t the recipient purchase directly from the third party—for less, without the provider’s mark-up? Recipients also argue that the whole reason for hiring a single technology integrator (the provider) is to get a single point of contact: a single party responsible for the system. As with all contract negotiations, the resolution comes down to leverage: who needs the deal more?

Finally, providers often disclaim specific issues in the warranty clause. For instance: “Provider does not warrant the Software’s interoperability with any computer operating system other than the versions of Windows XP issued by Microsoft Corporation as of the Effective Date.” Craft whatever disclaimers fit your deal.

5. Remedies for Breach of Warranty

A contract doesn’t have to specify a remedy for breach of warranty. If it doesn’t, a court will impose money damages or other solutions. But by agreeing on the remedies in advance, the parties remove much of the element of chance.

Usually, the provider promises to repair or replace defective goods, as in the first example in the clause box above. And for infringement warranties, the provider promises it will get the recipient a license to keep using the goods, or replace them with something non-infringing, as in the second example.

But what if these strategies fail? What if the thing can’t be fixed, or the provider can’t afford a license and there’s no suitable replacement? For the provider, the best solution is often to refund the recipient’s money, take the product back, and walk away. The first example in the clause box gives the provider that right.

The refund and walk away solution may leave the recipient in the lurch. Imagine the product is an accounting computer system, and the recipient’s already thrown away the old system. If the recipient has to stop using the new one, it has nothing, and it’s in trouble—trouble a refund won’t solve. That’s why recipients prefer clauses like the second example in the clause box, which leaves the provider no way out other than fix or replace. That should motivate the provider to go the extra mile looking for a solution (or at least drag the provider down with the recipient).(4)

If the contract specifies remedies for breach of warranty, will those remedies be “exclusive”? In other words, once the provider has repaired or replaced the product, can the recipient still go after money damages or some other remedy? If the contract says nothing on the subject, there’s a good chance the recipient can. To make sure, recipients often include clauses like the last sentence in the second example above, providing that these remedies are not “exclusive.” The provider, of course, wants to limit its responsibility to the stated remedies. So the first example in the clause box provides that the remedies are exclusive.

Footnotes

1 See Technical Specifications, Section II.A, on page 53.

2 See Software Licenses in General, Open Source License, Subsection I.C.4, on page 29.

3 Technically speaking, the disclaimer isn’t necessary for services contracts, because most states’ laws don’t impose implied warranties on them. But the line between goods and services can be hazy in IT, so it’s best to include the disclaimer anyway. In some states, it’s harder to enforce a disclaimer, or an “as is” warranty, than in others.

4 Of course, if the contract has a strong limitation of liability clause, the provider still might not be very motivated to help. See Limitation of Liability, Section II. G, on page 78.

[↑] Back to top