Building an API Product: Design,

implement, and release API products

that meet user needs Pedro
Visit to download the full and correct content document:
https://ebookmass.com/product/building-an-api-product-design-implement-and-releas
e-api-products-that-meet-user-needs-pedro/
Building an API Product
Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or
transmitted in any form or by any means, without the prior written permission of the publisher,
except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information
presented. However, the information contained in this book is sold without warranty, either express or
implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for
any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and
products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot
guarantee the accuracy of this information.

Group Product Manager: Kunal Sawant

Senior Editor: Kinnari Chohan

Technical Editor: Vidhisha Patidar

Copy Editor: Safis Editing

Project Coordinator: Prajakta Naik

Indexer: Subalakshmi Govindhan

Production Designer: Prashant Ghare

Marketing DevRel Coordinator: Sonia Chauhan

First published: January 2024

Production reference: 1110124

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-83763-044-8

www.packtpub.com
 To my wife, Vânia, and my two sons, Bernat and Enric. Without their ongoing love and support,
I wouldn’t have been able to write this book.

Contributors

About the author

Bruno Pedro is a computer science professional with over 25 years of experience in the industry.
Throughout his career, he has worked on a variety of projects, including internet traffic analysis, API
backends and integrations, and web applications. He has also managed teams of developers and
founded several companies, including Tarpipe, an iPaaS, in 2008, and the API Changelog in 2015. In
addition to his work experience, Bruno has also made contributions to the API industry through his
written work, including two published books on API-related topics and numerous technical magazine
and web articles. He has also been a speaker at numerous API industry conferences and events since
2013.

About the reviewers

David Roldán Martínez is currently the Head of APIs at Shaper by atmira. He also holds the
position of Associate Professor at the Universitat Politècnica de València (Spain) and is actively
involved as a researcher at VRAIN (Valencian Research of Artificial Intelligence Network).

Professionally, David is a Business and Solutions architect with over 25 years of experience in
software systems architecture. He holds a Ph.D. in Telecommunications Engineering and has a strong
educational background, including master’s degrees and extensive technological training.
Additionally, he is a scientific-technical evangelist, having authored more than thirty books.

David’s areas of expertise encompass APIs and their applications in various markets such as Banking,
Insurance, and Retail. He is well-versed in Artificial Intelligence, Digital Transformation, and the API
and Open Economy.

Christos Gkoros is a seasoned software engineer and architect with over 13 years of experience in
the industry. He has worked on a variety of projects in different technologies and industries, always
striving to find the best possible solution. With a focus on APIs, he is currently exploring ways to
help engineers in areas like API Design, API Management, and Strategy.

Christos has a proven track record of transforming complex challenges into streamlined, secure
systems, having spearheaded API design at Postman and microservice architecture at Vodafone. He is
passionate about mentorship and education and is committed to helping future talent grow and
succeed in the field.
Table of Contents

Preface
Part 1: The API Product

What Are APIs?

The different types of APIs
Local APIs
Remote APIs
The history of APIs
Unix
Network APIs
The web
Available technologies and protocols
Communication protocols
Implementation technologies
Tools
Summary

API User Experience

Who uses APIs?
Branchen
Personas
Developer experience
Second-degree user experience
API friction
Summary
3

API-as-a-Product
Business value
Monetization models
The freemium model
Tiered model
PAYG model
Support and documentation
Security
Logging and monitoring
Rate-limiting
Authentication and authorization
Summary

API Life Cycle

Design
Implementation
Release
Maintenance
Summary
Part 2: Designing an API Product

Elements of API Product Design

Technical requirements
Ideation
Strategy
Definition
Validation
Specification
Summary

Identifying an API Strategy

The meaning of strategy
Stakeholders
Business objectives
Personas
Behaviors
Summary

Defining and Validating an API Design

Technical requirements
API capabilities
Use case analysis
Functional requirements
Integration needs
Security and access control
Compliance with laws and regulations
Documentation
API mock
Prototyping an API integration with a UI
Design iterations
Summary

Specifying an API
Technical requirements
Choosing the type of API to build
Different types of APIs
API specification formats
OpenAPI
IDL (protocol buffers)
GraphQL
WSDL
AsyncAPI
Creating a machine-readable API definition
Following API governance rules
API design
API life cycle management
Summary
Part 3: Implementing an API Product

Development Techniques
Technical requirements
Prototyping an API
Choosing a programming language and framework
Factors to consider
Popular languages for building APIs
Node.js
Python
Ruby
Java
Go
Rust
Comparing programming languages
Generating server code from a specification
Generating server code using Postman
Generating server code using OpenAPI Generator
Summary

10

API Security
What is API security?
Security testing
Authentication
API key management
Token management
Authorization
RBAC
OAuth scopes
Summary

11

API Testing
Contract testing
Performance testing
Acceptance testing
Summary

12

API Quality Assurance

Defining QA
Test planning and execution
Behavioral testing
Regression testing
API monitoring
Summary
Part 4: Releasing an API Product

13

Deploying the API

Continuous integration
API versioning
Incremental API versioning
Semantic API versioning
Calendar-based API versioning
Choosing an API gateway
Summary

14

Observing API Behavior

API usage analytics
Application performance monitoring
User feedback
Aggregating and categorizing feedback
Acting on feedback
Scaling user feedback
Summary

15

Distribution Channels
What is API distribution?
Pricing strategy
API portal
Community
Marketplaces
Documentation
Summary
Part 5: Maintaining an API Product

16

User Support
Helping users get their jobs done
Support channels
Prioritizing bugs and feature requests
Summary

17

API Versioning
Technical requirements
Managing multiple API versions
Breaking changes
Communicating changes
Summary

18

Planning for API Retirement

When should you retire an API?
Communicating API retirement
API product retrospective
Summary

Index
Other Books You May Enjoy
Preface
Building an API Product is a comprehensive guide that ranges from the fundamentals of APIs and
their inner workings to mastering the steps involved in building successful API products. With this
book, you will be able to confidently and effectively create cutting-edge API products that excel in
today’s competitive market.
Who this book is for
This is a book that helps product managers and software developers navigate the world of APIs to
build programmable products. You don’t have to be an experienced professional to learn from this
book, as long as you have a basic knowledge of internet technologies and an understanding of how
users interact with a product.
What this book covers
Chapter 1, What Are APIs?, introduces you to API fundamentals, origins, and types such as REST,
gRPC, AMQP, and MQTT.

Chapter 2, API User Experience, explores how the API user experience is vital, second-degree
experience, and the impact of friction on success.

Chapter 3, API as a Product, outlines an API as a standalone product, emphasizing business value,
monetization options, support, documentation, and crucial security.

Chapter 4, API Life Cycle, provides an overview of the API life cycle stages, covering design,
implementation, release, and maintenance, offering an opinionated approach to API product
management.

Chapter 5, Elements of API Product Design, introduces you to the key API product design stages,
connecting ideation, strategy, definition, validation, and specification, paving the way for an in-depth
exploration.

Chapter 6, Identifying an API Strategy, analyses the strategy stage of API design, emphasizing
identifying stakeholders, determining business objectives, and understanding user personas and
behaviors.

Chapter 7, Defining and Validating an API Design, covers the techniques for defining and validating
API design, starting with strategy-derived information and exploring API mocks, UI integration, and
stakeholder iteration.

Chapter 8, Specifying an API, guides you on how to select an API architectural type based on
behaviors and capabilities, refining the definition with constraints and industry practices and creating
a machine-readable representation with governance rules.

Chapter 9, Development Techniques, offers a beginner-friendly guide to API development, covering

language and framework selection, code generation from specifications, prototyping, and extending
with business logic,

Chapter 10, API Security, explores API security, emphasizing its importance, distinguishing between
authentication and authorization, and introducing a security testing technique called fuzzing.

Chapter 11, API Testing, introduces you to API testing methods, covering contract testing to ensure
specification compliance, performance testing execution, and the connection of acceptance testing to
user personas.
Chapter 12, API Quality Assurance, covers API quality assurance, introducing behavioral testing to
validate against identified behaviors and setting up API monitors for periodic testing.

Chapter 13, Deploying the API, provides an overview of the API deployment process, covering
continuous integration, agility, automated testing, deployment, and API gateway trade-offs.

Chapter 14, Observing API Behavior, introduces you to API usage analytics, APM, and user
feedback analysis to identify and measure important metrics, usage patterns, and behavior.

Chapter 15, Distribution Channels, covers API distribution strategies, including pricing, API portals,
marketplace listing, and documentation options to enhance user activation.

Chapter 16, User Support, delves into ways to ensure user success with an API, covering support
channels, forums, and prioritizing bug fixes and feature requests from user feedback.

Chapter 17, API Versioning, explores techniques for managing multiple API versions, handling
breaking changes effectively, and communicating changes to users using machine-readable methods.

Chapter 18, Planning API Retirement, discusses API retirement, covering its definition,
considerations, and communication to users and conducting a retrospective to document what you
have learned from the process.

Download the example code files

You can download the example code files for this book from GitHub at
https://github.com/PacktPublishing/Building-an-API-Product. If there’s an update to the code, it will
be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at
https://github.com/PacktPublishing/. Check them out!

Conventions used
There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file
extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “Mount
the downloaded WebStorm-10*.dmg disk image file as another disk in your system.”

A block of code is set as follows:

html, body, #map {

height: 100%;
margin: 0;
 padding: 0
}

When we wish to draw your attention to a particular part of a code block, the relevant lines or items
are set in bold:

[default]
exten => s,1,Dial(Zap/1|30)
exten => s,2,Voicemail(u100)
exten => s,102,Voicemail(b100)
exten => i,1,Voicemail(s0)

Any command-line input or output is written as follows:

$ mkdir css
$ cd css

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words
in menus or dialog boxes appear in bold. Here is an example: “Select System info from the
Administration panel.”

TIPS OR IMPORTANT NOTES

Appear like this.

Get in touch
Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at
[email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do
happen. If you have found a mistake in this book, we would be grateful if you would report this to us.
Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be
grateful if you would provide us with the location address or website name. Please contact us at
[email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you
are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Building an API Product, we’d love to hear your thoughts! Please click here to go
straight to the Amazon review page for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we’re delivering
excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical
books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free
content in your inbox daily

Follow these simple steps to get the benefits:

1. Scan the QR code or visit the link below

https://packt.link/free-ebook/9781837630448

2. Submit your proof of purchase

3. That’s it! We’ll send your free PDF and other benefits to your email directly
Part 1:The API Product
This part provides a comprehensive guide to API development and management, beginning with
fundamental concepts, types, and origins, followed by a focus on user experience and the significance
of the API as a standalone product. It then delves into the API life cycle stages, covering design,
implementation, release, and maintenance, with an opinionated approach for effective API product
management.

In this part, you’ll find the following chapters:

Chapter 1, What Are APIs?

Chapter 2, API User Experience

Chapter 3, API-as-a-Product

Chapter 4, API Life Cycle

1

What Are APIs?

APIs are the most powerful technology available today. While the API acronym can be deceitfully
simple, the concept it describes offers infinite possibilities. Welcome to the world of APIs, where
you’ll learn how to build an API product. Your first step in this expedition is to first learn what an
API is. In this chapter, you will understand the nature of APIs, looking back to their origins. You’ll
also get to know which technologies and tools are available for you to use.

The chapter begins by exploring different types of networks, such as the internet, and how APIs work
on them. You will then be guided through the history of APIs. You’ll see how APIs came to life and
understand how certain concepts in use today were born. Finally, you’ll see that there are different
technologies and tools that you can use to build an API product from scratch.

By the end of this chapter, you will know that APIs can exist on different types of networks. You will
understand what those networks are and what the most appropriate one for your API product is. You
will also know that there are synchronous and asynchronous APIs and what those terms mean. Most
importantly, you will know how to pick the right type of API and tools to build your API.

In this chapter, we’re going to cover the following main topics:

The different types of APIs

The history of APIs

Available technologies and protocols

The different types of APIs

This section gives you an overview of the different types of APIs that exist. APIs are split between
local and remote, and then by the protocols that they adhere to. You’ll start by understanding what an
API is at a high level and why it’s so important. Then, you’ll dive into the different types of APIs.
Let’s get started.

Application programming interfaces, or APIs, allow applications to be used programmatically.

They create an interface—a layer of abstraction—that opens applications to interactions from the
outside. The interface has the goal of standardizing any connection to the application. Suppose you
think about an interface as a common boundary between two entities. In that case, an API is a way to
let an application communicate with other entities in a programmatic fashion.
This type of interaction is what you can call an integration. Integrating different applications, or
different parts of the same application, lets you build products by putting together pieces that are
ready to be used. Instead of creating all the features of a product from scratch, you can utilize
functionality that is already available in the form of an API. That alone is a powerful tool to use.
Creating a product by using APIs can be done in a fraction of the time it would take if you develop all
the features yourself. That happens because you can reuse pieces of functionality that are
standardized and well understood. Those pieces of functionality can be a whole product, a single
feature, or a subset of a product represented by a selection of features. Different types of APIs
provide different types of interactions, as you’re about to learn.

Local APIs
Local interfaces are the most used type of API, even if they’re often seen as invisible. All the
applications that run on a device need to communicate with the hardware. Applications interact with
the device via local APIs. They offer the advantage of providing a standard method of programming
the device to behave according to what users want. POSIX is one such standard created by the IEEE
Computer Society. It stands for Portable Operating System Interface, and its goal is to establish a
layer of communication that is standard across different operating systems. Another similar standard
is the Single UNIX Specification (SUS). macOS, a popular operating system developed by Apple
Inc., is considered partly compliant with POSIX and fully compliant with the SUS. This means that
anyone that interacts with macOS knows that it follows certain rules and conventions that have been
standardized. In theory, an application that is built to run on macOS could also run on other systems
that are compliant with the same standards.

Another way of introducing a standardized local layer of communication is by using common

software libraries. Even if a system doesn’t follow a full standard, some of its parts can use
standardized libraries. Java offers a popular set of libraries and APIs that can be used across systems.
The programming language was created by Sun Microsystems—acquired by Oracle Corporation—
and has been used on almost all operating systems. Java fully embodies the goal of standardizing how
applications interact. Its slogan is Write once, run anywhere, and it symbolizes the importance that its
creators give to standardized interfaces. Java’s versatility is enormous. You can use Java to create
mobile applications that run on Android devices, desktop applications, and everything in between.

By now, it’s clear that operating systems’ standards and libraries offer a way of interacting with the
lowest layers of computing devices. Another form of abstraction that encapsulates reusability at a
higher level is available through software modules. Most modern scripting programming languages
have the ability to create and use modules. Modular software development has become a popular way
of building applications. Modules provide functionality that is ready to be used and increase the
speed at which applications are built.

A widespread module system exists for the JavaScript programming language. Its name is npm, the
Node Package Manager. Its authors claim that npm is the world’s largest software registry, with
over one million modules available to be used by anyone. According to GitHub, JavaScript is the
number one used programming language at the time of writing. In fact, JavaScript has been in the
first position for the last eight years at least. Because npm is used by applications written in
JavaScript, it’s the most used module system.

Other module systems exist for different programming languages, and they all share that they want to
facilitate the reuse of functionality and increase the speed of developing software. Python, the second
most popular programming language, has PyPI, the Python Package Index. The third most popular
programming language, Java, also has its package system, Maven. There are all kinds of modules
ready for anyone to use on their applications. The point is that anyone is free to create and publish
modules and also to reuse modules that other people have published. Hence, a vast ecosystem of
modular software development keeps growing.

While local interfaces deal with the interaction between different parts of a local system, some of
those parts let you communicate with the outside world. Communication with remote systems is also
abstracted and standardized in the form of APIs. Read on to learn more about the different remote
APIs and how they can enhance the features of an application.

Remote APIs
Most people think of APIs as a way to interact with software that is running remotely. They tend to
ignore all the local interfaces that you’ve read about before—not because local APIs aren’t important,
but because they feel invisible. The opposite happens with remote APIs. Instead of being invisible,
remote APIs feel like they’re the most critical part of an application. The act of starting a connection
to a system that is running on a different part of a computer network feels like something worth
paying attention to. Remote connectivity can be split according to the type of network being used.
Let’s focus on local area networks (LANs) and wide area networks (WANs) because that’s where
most APIs operate.

LANs connect devices that are physically in the same location. The types of applications that exist on
a LAN are meant to be accessed exclusively by devices that are connected to the same network. APIs
that operate on LANs are typically focused on supporting specific classes of applications and not on
providing generic services to consumers. In other words, LAN APIs offer a way for devices to
connect to applications running on the same network. As with local APIs, here, the goal is to
standardize how the same type of applications communicate on LANs.

Databases are one type of application that is widely used in local networks. The ODBC standard was
created to standardize communication between applications and databases. ODBC stands for Open
Database Connectivity and is a standard API for accessing databases. Applications that use ODBC
can be ported across different database systems without having to be rewritten. You can, for instance,
develop a warehouse stock application that uses the MySQL database system. Suppose that, at some
point, you decide to switch to Oracle or some other database system. You don’t have to rewrite your
application as long as the database system supports ODBC. In the same way, if you decide to change
the implementation of your application to a different programming language, you don’t have to
change the database system. As long as the programming language supports ODBC, you know that
you’ll be able to interact with your database.

Printing is another popular activity on local networks. As you would expect, there are APIs that
standardize the communication between printers and other devices in the same LAN. One such API is
the Line Printer Remote protocol, or LPR. This protocol lets you interact with a printer,
programming it to print documents and even changing the configuration options of the target printer.
Even though printing happens primarily in LANs, it’s a type of application that can also be carried
out across the internet. To make communication with printers work easily outside LANs, there is a
remote API called Internet Printing Protocol, or IPP. According to Michael Sweet from Apple Inc.,
“at least 98% of all printers sold since 2010 support IPP." It became so popular because it offers
features such as authentication, access control, and encryption of data transmitted to the printer. And
it’s not the only API that operates on the internet, as you’ll see if you keep reading.

When you hear the term API, you immediately think about services that run on the internet. That’s
because wide access to networked services helped popularize the creation of APIs. Externalizing
features of an application feels natural in an environment where all services are connected to the
same network. Many times, you can even confuse internet APIs with the services that they expose.
We often talk about the API as the offering rather than the interface. That indicates that the internet
has contributed to the fragmentation of the types of APIs that are available. There are API types that
are best suited for reading data while other types are better used for synchronously storing
information, and there are types that work well to asynchronously share information about events.

Let’s start by exploring API types that let you easily read data from a remote server on the internet.
You can say that the simplest way to read data remotely is to directly access a document. However,
you would only call that an API if there were some degree of programmability involved. In other
words, when you’re directly retrieving a document, you’re not sending any parameters to an API. To
make it programmable, there has to be something on the server that interprets the request parameters
and changes the returned output based on what is being requested. A remote procedure call, or
RPC, is an example of a type of API that lets the requester send parameters to a server and, in return,
receive information. In the same way that you can read information with it, you can also use it to
store information on a server. In that case, you’re sending parameters along with the information that
you want to store. Depending on the size of the data—what you call an API payload—you can
choose what type of API and which technology to use.

As a rule of thumb, anything that happens on the internet works better with short-lived connections.
The internet is an open network. Connections between different points on the internet can change
without notice, and that can affect the quality of communication. Communicating asynchronously is
also an option. There are types of APIs that focus specifically on letting you share information in an
asynchronous way. Usually, these are used for sharing information about events, but also for
receiving the result of long-running operations. You make a request that you know is going to take a
long time to finish. When the request is completed by the server, it will share the result with you. If
availability is what matters the most, then you decide the type of API based on what is reliable most
of the time. Many APIs end up running on top of the web because it’s the most widely used protocol,
and you accept it as having a high resilience. In fact, web APIs are what you’ll be working on most of
the time when you’re building API products.

Web APIs are a type of API that uses the internet and web-specific protocols to communicate. In the
same way that the remote APIs that you’ve read about before make remote resources appear as local,
web APIs offer the same functionality for resources available on the web. On the web, it’s a common
approach to identify the supported media types that can be transferred from the server to the client.
That is also the case for web APIs. Two of the most used media types are the Extensible Markup
Language, or XML, and the JavaScript Object Notation, or JSON. These media types can be
easily used and interpreted by API client software. The big advantage of web APIs over other types of
remote APIs is the features that the web offers. Just by using the web, you have access to content
caching, or the ability to temporarily store responses that can be reused between requests. You also
have access to authentication mechanisms that don’t require any specific implementation. Finally,
you become part of a vast ecosystem of server and client tools that are widely available for anyone to
use.

While there are different types of APIs, you’re reading this book most probably because you’re
interested in web APIs. As you’ve seen before, to most people, APIs are a synonym for something
such as a programmable interface running on the web. The API that you’ll build will probably run on
the web as well, so let’s use that as a guide throughout the rest of the book. Keeping in mind that
there are several types of APIs, let’s focus on how to build web APIs. To get there, let’s look now at
how APIs came to exist and how they have been evolving.

The history of APIs

By now, you already know that there are different types of APIs that you can use depending on what
you’re trying to achieve. It’s important to know how APIs were created and which events were the
key contributors to their evolution. Learning how we got to where we are now is the first step to
understanding how to build successful products on top of APIs.

To understand how APIs were invented, let’s go back in time to circa 1950. At that time, computing
was just getting started, and the first known mention of a software module was made by Herman
Goldstine and John von Neumann. The authors were referring to local APIs in the form of modules
or, as they called it, “subroutines.” In their Report on the Mathematical and Logical Aspects of an
Electronic Computing Instrument from 1947, they explain what a subroutine is. To the authors, a
subroutine is a special kind of routine—a set of program instructions that can be reused. They
describe that a subroutine has the purpose of being substituted inside any existing routine. It’s clear
that the authors were focusing on reusability, as you’ve read before in this chapter. In fact, from then
on, APIs have been used as a way to reduce the amount of programming required to build an
application.

However, the work of Goldstine and von Neumann was purely theoretical and couldn’t be put into
practice at that time. It was only when the Electronic Delay Storage Automatic Calculator, or
EDSAC, was created that software modules were actually used. In 1951, Maurice Wilkes, the creator
of EDSAC, was inspired by the work of Goldstine and von Neumann. Wilkes introduced the use of
modules as a way to reuse functionality and make it easier to write programs from scratch. Wilkes,
jointly with Wheeler and Gill, describes how subroutines could be used in their book The
Preparation of Programs for an Electronic Digital Computer. In this, they explain that with a library
of subroutines, it should be simple to program sophisticated calculations. You’d only have to write a
master routine that, in turn, calls the various subroutines where the different calculations are
executed.

Still, the first time the term “application program interface” (notice that the word used isn’t
“programming”) appeared was probably in the Data Structures and Techniques for Remote Computer
Graphics paper published in 1968. In this, its authors, Ira Walter Cotton and Frank S. Greatorex,
notice the importance of the reusability of code in the context of hardware replacement. The paper
mentions that even if you change the hardware, a “consistent application program interface could be
maintained.”
Another random document with
no related content on Scribd:
onneton, sillä hereillä tekee arvosteluni minut tyytymättömäksi, aina
kuiskaten minulle, että olen poissa ystäväni luota. Mutta lempeät
uneni öisin hyvittävät minua ja saavat minut uskomaan, että olen
hänen sylissään. Kiitän Jumalaa onnellisista unistani, samoin kuin
hyvästä levostanikin, sillä ne tarjoovat tyydytystä kohtuullisille
toiveille ja sellaisille ihmisille, jotka tyytyvät vähäänkin
onnellisuuteen. Eikä liene synkkämielinen se käsitys, että me kaikki
olemme kuin nukuksissa tässä maailmassa, että tämän elämän
käsitykset ovat pelkkiä unelmia verrattuina tulevaisen maailman
tajuntaan, niinkuin unihaaveet selvän päivän tajunnan rinnalla.
Molemmat ovat yhtä erehdyttäviä, ja toinen näyttää vain olevan
toisen vertauskuva. Me olemme vähän enemmän kuin oma itsemme
nukkuessamme, ja ruumiimme uinailu tuntuu aloittavan sielun
valveutumisen. Aistimemme ovat kyllä sidotut, mutta järkemme
vapautuu, eivätkä ajatuksemme valveilla ollessamme voi kilpailla
unessa saamiemme haaveiden kanssa.

Syntymämerkkini osui Skorpionin vetiseen tähtikuvioon;

syntymiseni tapahtui Saturnuksen kiertotunnilla, ja luulenpa itsessäni
olevan jonkun verran tämän kiertotähden lyijymäisyyttä. Minä en ole
lainkaan taipuvainen leikinlaskuun, eikä minulla ole lahjoja esiintyä
pilapuheilla ja sukkeluuksilla seurassa. Mutta yhdessä ainoassakin
unessa voin laatia kokonaisen huvinäytelmän, katsella sen
suorittamista, panna merkille pilapuheet ja nauraa itseni hereille sen
hullutuksista. Jos muistini olisi yhtä uskollinen kuin järkeni on silloin
tuottelias, harjoittaisin tutkimuksia vain unissani. Samoin valitsisin
sen ajan myöskin hartauteni harjoittamiseksi. Mutta karkealaatuinen
muistimme ei kykene pitämään tallella keveämmin liikkuvan älymme
vaikutuksia, vaan unohtaa ne ja herättyämme pystyy esittämään vain
epäselvän ja katkonaisen kertomuksen siitä, mitä on tapahtunut.
 Aristoteles, joka on kirjoittanut eri tutkielman unesta, ei mielestäni
ole tarkoin sitä määritellyt. Eikä Galenuskaan, vaikka hän näyttää
oikaisseen edellämainitun käsitystä. Sillä unissakävijöillä, vaikka he
liikkuessaan nukkuvatkin, on kuitenkin aistimien toiminta jäljellä.
Senvuoksi meidän täytyy sanoa, että meissä on jotakin, mikä ei ole
Morfeuksen vallassa, ja että hurmiotilaan joutuneet sielut vaeltelevat
omassa ruumiissaan niinkuin hengetkin asunnoikseen ottamissaan
ruumiissa, joihin pukeutuneina ne näyttävät kuulevan, näkevän ja
tuntevan, vaikka elimet ovat vailla aistimiskykyä. Niinpä huomataan
ihmisten joskus lähtöhetkellänsä puhuvan ja ajattelevan asioita, jotka
ovat heidän tavallisten kykyjensä yläpuolella; silloinhan näet sielu,
joka alkaa vapautua ruumiin kahleista, puhkeaa kuin itsekseen
toimimaan ja pääsee kuolevaisuuden rajojen ulkopuolelle. Me
nimitämme unta kuolemaksi, vaikkakin herääminen meidät tappaa ja
hävittää ne henget, jotka ovat elämän varsinaisena olinsijana.
Tosiaankin tuo elämän puoli parhaiten esittää kuolemaa. Sillä
jokainen ihminen elää todellisesti juuri niin kauan kuin hän saa
varsinaisen luontonsa toimimaan tai jollakin tavalla toteuttaa
kykyjänsä. Siksi Themistokles, joka surmasi erään sotilaistaan
tämän nukkuessa, oli lempeä pyöveli. Sentapaista rangaistusta ei
mikään laki ole lempeimmilläänkään ajatellut. Kummastelen, ettei
Lucanuksen eikä Senecan mielikuvitus sitä keksinyt. Sellaista
kuolemaa saattaa kirjaimellisesti sanoa meidän itse kokevan joka
päivä, ja sellaisen kuoleman alaiseksi Aatamikin joutui ennenkuin
hänestä tuli kuolevainen; sen kuoleman nojalla elämme elämän ja
kuoleman välisessä tasoittavassa tilassa, ja se on niin tosikuoleman
kaltainen, etten uskalla siihen antautua rukoilematta ja maailmalle
puoleksi hyvästi jättämättä. Puheluni Jumalan kanssa kelpaa minulle
hyväksi unilääkkeeksi. Muuta en kaipaa saadakseni hyvää unta, ja
sitten suljen silmäni turvallisesti tyytyen sanomaan jäähyväiset
auringolle, jos minun on nukuttava ylösnousemukseen asti.

Sitä menetelmää, jota minun olisi noudatettava tuomitessani,

käytän usein keskinäisissä asioissa ja sovitan siihen geometrisen
suhteen, jonka vuoksi, koettaessani olla toisille tasapuolinen, olen
puolueellinen itseäni kohtaan ja liioittelen noudattaessani sääntöä:
mitä tahdot ihmisten sinulle tekevän, tee se myöskin heille. En
syntynyt perittyihin rikkauksiin, eikä tähteni lie ennustanut minulle
varallisuutta. Tai jos olisikin niin ollut, niin sieluni vapaus ja mieleni
suoruus olisivat tehneet tyhjiksi kohtaloni määräykset. Sillä minusta
ahneus ei niin paljon tunnu paheelta kuin surkuteltavalta hulluudelta.
Se, että pidämme itseämme saviastioina tai uskomme olevamme
vainajia, ei ole niin naurettavaa eikä niin monta astetta aivastusyrtin
vaikutuksen ulkopuolella kuin tämä. Ihmisten teoreettiset mielipiteet
ja väittämät eivät ole niin järkeä vailla kuin heidän käytäntönsä
johtopäätökset. Jotkut ovat väittäneet, että lumi on mustaa, että maa
liikkuu ja että sielu on ilmaa, tulta, vettä; mutta kaikki tämä on
filosofiaa eikä siinä ole suorastaan hulluutta, kun sitävastoin
vähänkin ajatellen tajuamme, kuinka hupsua ja nurinkurista on himo
maanalaiseen jumalaan, kultaan.

Minun täytyy tunnustaa olevani siinä merkityksessä ateisti. En voi

suostuttaa itseäni kunnioittamaan sitä, mitä maailma palvelee. Mitä
hyvänsä sen vaikutus saaneekin aikaan ruumiissani, ei sillä ole
mitään tekemistä eikä vaikutusta sen ulkopuolella. Koko Intian
hinnasta en pitäisi mielessäni alhaista aietta tai suunnittelisi tekoa,
jonka vuoksi minua voitaisiin nimittää heittiöksi. Pelkästään tämän
takia rakastan ja kunnioitan omaa sieluani, ja minulta puuttuu toinen
pari käsivarsia syleilläkseni itseäni. Aristoteles on liian ankara, hän
kun ei myönnä meidän voivan olla todellisesti anteliaita ilman
rikkautta, onnettaren suopeaa kättä. Jos tämä on totta, niin
tunnustan olevani laupias vain anteliaissa aikeissani ja runsaissa
toivotuksissani. Mutta jos lesken ropo ei ollut vain kummastusta
herättävä teko, vaan mitä ylevimmän uhraavaisuuden osoitus, silloin
köyhätkin ihmiset saattavat rakentaa sairaaloita eivätkä rikkaat
yksinään kykene pystyttämään temppeleitä.

Minä noudatan omaa menettelytapaani, jota muut eivät käytä: otan

huomioon omat pienet tilaisuuteni hyvää tehdäkseni, supistan omia
välttämättömiä tarpeitani anteliaisuuden osoituksiin ja tyydytän
toisten puutetta silloin, kun itsekin enimmin kaipaan. Sillä rehellinen
sotajuoni on yllättää itsensä ja niin järjestää hyveiden ilmauksia, että
silloin, kun niitä puuttuu yhdessä kohdassa, ne voisivat saada
korvauksen toisessa. En toivo saavani Perun rikkauksia, vaan tyydyn
kohtuulliseen toimeentuloon ja kykyyn voida tehdä sitä hyvää, johon
Jumala on antanut minulle taipumuksia. Se, jolla on kyllin
voidakseen olla antelias, on rikas, ja vaikeaapa on olla niin köyhä,
ettei jalo mieli keksi keinoja toteuttaakseen hyvää tahtoansa. Joka
köyhää armahtaa, lainaa Herralle; siinä on lyhykäisesti enemmän
kaunopuheisuutta kuin saarnakokoelmassa. Ja jos todellakin lukija
ymmärtäisi tuollaiset lauseet niin vakavalta kannalta kuin ne on
lausuttu, emme tarvitsisi laveita opetuksia, vaan olisimme rehellisiä
pienen otteen kuultuamme.

Jo tämäkin syy vaikuttaa, etten voi nähdä kerjäläistä

huojentamatta hänen hätäänsä kukkarostani tai hänen sielunsa
taakkaa rukouksillani. Näennäiset ja satunnaiset eroavaisuudet
meidän välillämme eivät saata minua unohtamaan meissä
molemmissa olevaa yhteistä ja koskematonta. Ryysyisen puvun ja
viheliäisen ulkoasun alla, raajarikkoisen ja vajavaisen ruumiin
suojassa asuu sielu, joka on samaa sukua kuin omammekin,
Jumalasta kotoisin niinkuin meidänkin ja yhtä hyvin pelastettavaksi
aiottu. Kansantalousmiehen työskennellessään saadakseen aikaan
yhteiskunnan, jossa ei köyhyyttä olisi, poistavat tilaisuuden harjoittaa
armeliaisuutta eivätkä ymmärrä kristityn yhteiskunta-ajatusta,
unohtaen myös Kristuksen ennustuksen.

Mutta on toinenkin laupeuden puoli, joka on edellisen perustus ja

kulmakivi, nimittäin rakkaus Jumalaan, jonka nojassa voimme
rakastaa lähimmäistäkin. Sillä se minusta on oikeata laupeutta, että
rakastamme Jumalaa hänen itsensä vuoksi ja lähimmäistämme
Jumalan vuoksi. Kaikki, mikä on todella rakastettavaa, on Jumalaa
tai tavallaan osa hänestä, joka heijastaa ja kuvastaa häntä. Eikä ole
ihmeellistä, että rakkautemme kiintyy näkymättömään, sillä kaikki,
mitä todella rakastamme, on näkymätöntä. Se, mitä hellimme
aistimiemme vaikutelman takia, ei ansaitse niin puhdasta nimitystä.
Niinpä siis ihailemme hyvettä, vaikka emme aistimillamme voi sitä
havaita. Samoin ei se puoli, mitä ylevissä ystävissämme
rakastamme, ole käsin tavoiteltavissa, vaan se on jotakin sisäistä,
jota emme voi syleillä. Jumala, joka on itse hyvyys, ei voi rakastaa
muuta kuin sitä, mikä on hänestä. Hän rakastaa meissäkin sitä, mikä
on niin sanoaksemme häntä itseänsä ja hänen Pyhän Henkensä
vaikutusta. Jos tarkastamme todellisuuden mukaisesti vanhempain,
vaimon ja lasten rakkautta, niin se kaikki on tyhjää kuvitelmaa ja
unennäköä, vailla todellisuutta, totuutta ja pysyväisyyttä. Sillä vaikka
aluksi meidän ja vanhempien välillä on voimakas yhdysside, niin
kuinka helposti se katkeaakaan! Me kiinnymme vieraaseen naiseen
ja unohdamme vaimon takia oman äitimme ja sen kohdun, jossa
sikisimme, muistaen vain sitä, jossa oma kuvamme on sikiävä. Kun
tämä nainen lahjoittaa meille lapsia, ei rakkautemme enää pysy yhtä
korkealla, vaan laskee, siirtyen seuraamaan uutta sukupolvea, jossa
taas rakkaudella ei ole vakaata asuinsijaa. Kun lapset varttuvat,
toivovat he meidän jo lähtevän tieltä pois tai kiintyen johonkin
naiseen käyttävät laillista keinoa rakastaa vierasta ihmistä enemmän
kuin meitä. Näin ollen kuvittelen ihmisen joutuvan elävältä
haudatuksi ja näkevän hautansa omissa jälkeläisissään.

Niinpä siis lopettaakseni sanon, ettei auringon alla (tai niinkuin

Kopernikus tahtoisi sanoa: yllä) ole mitään onnellisuutta, eikä ole
perätön Salomon niin usein toistettu viisas lauselma: kaikki on
turhuutta ja hengen vaivaa. Ei ole mitään onnellisuutta siinä, mitä
maailma ihailee. Kun Aristoteles ponnistelee kumotakseen Platon
aatteita, joutuu hän itse samanlaiseen kumottavaan aatteeseen, sillä
hänen esittämänsä summum bonum, korkein hyvä, on vain
mielikuva, eikä ole olemassakaan sellaista, mitä hän pitää
onnellisuutena.

Se, missä Jumala itse on onnellinen ja enkelit autuaita ja minkä

puutteessa paholaiset ovat onnettomia, sitä vain uskallan nimittää
onnellisuudeksi. Mikä hyvänsä siihen johtaa, ansaitsee myös tuon
nimen, mutta sensijaan mikä muu hyvänsä, mitä maailma nimittää
onnellisuudeksi, on minusta vain kuin Pliniuksen tai Boccacion tai
Malizspinin juttuja, haavekuva tai harhanäky, jossa ei ole muuta
onnellisuutta kuin sen nimi. Siunaa minua, oi Herra, tässä elämässä
vain omantunnon rauhalla, tunteitteni hallinnalla, omalla ja
kalleimpien ystävieni rakkaudella, niin olen onnellinen Caesarin
kadehdittavaksi. Nämä ovat perin vaatimattoman kunnianhimoni
nöyrät toiveet, ja niihin sisältyy kaikki, mitä maan päällä uskallan
onnellisuudeksi nimittää. Siinä en tahdo panna mitään rajoja Sinun
kädellesi tai kaitselmuksellesi. Määrää kohtaloni oman
hyväksinäkemisesi viisauden mukaan. Tapahtukoon Sinun tahtosi,
vaikka se merkitsisi minun tuhoani.
 *** END OF THE PROJECT GUTENBERG EBOOK LÄÄKÄRIN
USKONTO ***

Updated editions will replace the previous one—the old editions will
be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying copyright
royalties. Special rules, set forth in the General Terms of Use part of
this license, apply to copying and distributing Project Gutenberg™
electronic works to protect the PROJECT GUTENBERG™ concept
and trademark. Project Gutenberg is a registered trademark, and
may not be used if you charge for an eBook, except by following the
terms of the trademark license, including paying royalties for use of
the Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is very
easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the free

distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund from
the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only be

used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law in
the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name
associated with the work. You can easily comply with the terms of
this agreement by keeping this work in the same format with its
attached full Project Gutenberg™ License when you share it without
charge with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the terms
of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.

1.E. Unless you have removed all references to Project Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears, or
with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:
 This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is derived

from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is posted

with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning of
this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute this

electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1 with
active links or immediate access to the full terms of the Project
Gutenberg™ License.
1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or expense
to the user, provide a copy, a means of exporting a copy, or a means
of obtaining a copy upon request, of the work in its original “Plain
Vanilla ASCII” or other form. Any alternate format must include the
full Project Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or providing

access to or distributing Project Gutenberg™ electronic works
provided that:

• You pay a royalty fee of 20% of the gross profits you derive from
the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt that
s/he does not agree to the terms of the full Project Gutenberg™
 License. You must require such a user to return or destroy all
copies of the works possessed in a physical medium and
discontinue all use of and all access to other copies of Project
Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™

electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or
damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in paragraph
1.F.3, the Project Gutenberg Literary Archive Foundation, the owner
of the Project Gutenberg™ trademark, and any other party
distributing a Project Gutenberg™ electronic work under this
agreement, disclaim all liability to you for damages, costs and
expenses, including legal fees. YOU AGREE THAT YOU HAVE NO
REMEDIES FOR NEGLIGENCE, STRICT LIABILITY, BREACH OF
WARRANTY OR BREACH OF CONTRACT EXCEPT THOSE
PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE THAT THE
FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of receiving it,
you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or entity
that provided you with the defective work may elect to provide a
replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.

1.F.4. Except for the limited right of replacement or refund set forth in
paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and distribution
of Project Gutenberg™ electronic works, harmless from all liability,
costs and expenses, including legal fees, that arise directly or
indirectly from any of the following which you do or cause to occur:
(a) distribution of this or any Project Gutenberg™ work, (b)
alteration, modification, or additions or deletions to any Project
Gutenberg™ work, and (c) any Defect you cause.

Section 2. Information about the Mission of

Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will
remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.
 Section 3. Information about the Project
Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.

The Foundation’s business office is located at 809 North 1500 West,

Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact

Section 4. Information about Donations to

the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many small
donations ($1 to $5,000) are particularly important to maintaining tax
exempt status with the IRS.

The Foundation is committed to complying with the laws regulating

charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states where

we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot make

any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.

Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.

Section 5. General Information About Project

Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.

Project Gutenberg™ eBooks are often created from several printed

editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.