The Unified Process (UP), or Unified Software Development Process, is a iterative and incremental software development framework from which a customized process can be defined. The framework contains many components and has been modified a number of times to create several variations. The most popular variations include the Rational Unified Process (RUP) and the Open Unified Process (OpenUP). The framework has several key characteristics which seem to carry across all variations (as far as I can tell).
The key characteristics of the Unified Process are: 
In general, the Unified Process is built around the idea of incorporating six specific
best practices into a configurable process framework. Those best practices are:
Much of the concepts in the Unified Process began with work Ivar Jacobson did at Ericsson in the 1960's. Jacobson went out on his own in 1987, codified his earlier work into what became the Objectory Process, and started the Objectory AB company to sell the process. After a number of years further developing the Objectory process, Jacobson released the book Object-Oriented Software Engineering in 1995 which described the Objectory Process in detail.
In 1996 Rational Software acquired the Objectory Process and company. Jacobson worked at Rational and teamed up with Grady Booch and Jim Rumbaugh and together they spent the next several years further developing the Objectory Process (now known as the Rational Objectory Process) and the Unified Method (which later became UML). In 1998, Rational changed the name from the Rational Objectory Process to the Rational Unified Process. However, because RUP was the trademarked property of Rational, further work by the software and academic community usually referred to just the Unified Process in order to avoid trademark issues. And by 1999, the first book to describe the generic Unified Process was written by Jacobson, Booch, and Rumbaugh.
IBM acquired Rational Software in 2003, and in 2005 donated the core of the Rational Process to the Eclipse Foundation open-source community. 
There were originally just five Disciplines in the Unified Process, but over the years that has been expanded to where there are now up to nine.
The Unified Process framework is made up of the following components:
The disciplines are:
The four phases are:
Each cycle defines a new major version of the software being developed. Each cycle is broken into four different phases, which may have multiple iterations within the phase. Each iteration results in an incremental version of the software. Across the cycles, phases, and iterations; work from different disciplines is undertaken by Workers (think of these as project roles). This work takes the form of specific activities with a discipline that result in specific artifacts (for example, a
Create Work Breakdown Structure activity with the Project Management Discipline, which results in a WBS artifact).
Each phase is concluded when a measurable milestone has been reached and is followed by a
go / no-go decision by the project team on whether to move forward with the next phase.
It is important to note that although different amounts of work from each discipline may occur in each phase or iteration, work from all disciplines occurs in every phase.
The UP framework is commonly visualized in ways such as the graphic below (from the Wikimedia Commons).
The Business Modelling discipline focuses on efforts to understand the organization, its processes, and the problem domain. The discipline focuses on understanding the following factors and how they may impact or relate to the software being considered: 
The requirements discipline in RUP is like the requirements discipline in pretty much every other software process. The main difference is that RUP requirements are highly focused in the form of UML models and Use Cases (both diagrams and descriptions).
The Analysis and Design discipline would be better named the Solution Analysis and Design discipline in my opinion. This is because the requirements are analyzed from a solution design perspective, rather than a requirements analysis perspective. Specific activities that are part of this discipline include: 
The Implementation discipline consists of coding, unit testing, and integration of the software.
The Testing discipline is focused on quality assurance of the software being released in that cycle or iteration. It includes such activities as: 
The Deployment discipline is focused on planning the deployment of, and actually deploying, the software that is being completed that cycle, phase or iteration. It includes such activities as:
The Configuration and Change Management discipline is focused on managing change to the project’s work products. This includes such activities as: 
The Project Management discipline is focused on standard project management activities such as: 
The Environment discipline is focused on supporting the overall project and development efforts through managing environmental factors such as:
The Inception Phase is the part of the framework when the
why of the development effort is defined. This includes such activities as:
The milestones (that together comprise the Lifecycle Objectives Milestone) that show completion of the Inception phase are:
The Elaboration Phase is the part of the framework when more detailed analysis and planning are undertaken to better understand the problem domain, develop a more concrete project plan, identify and eliminate the high-risk elements of the effort, and to establish a solid architectural foundation for the software to be developed. The goal is to develop a "mile wide and inch deep" view of the system to be developed. 
The specific activities of this phase include:
The milestones (that together comprise the Lifecycle Architecture Milestone) that show completion of the Elaboration phase are:
The Construction Phase is the part of the framework where software development, integration, and testing takes place. Because of the emphasis on component-based architectures and the significant attention paid to the architectural plan in the Inception and Elaboration phases, it should be possible to initiate multiple Construction Phases within a single cycle if the software to be developed is complex enough to support multiple discreet components.
The specific activities of this phase include:
The milestones (that together comprise the Initial Operational Capability Milestone) that show completion of the Construction phase are:
The outcome of the construction phase should be a product that is ready to put into the hands of end-users in at least a
beta release state.
The Transition Phase of the framework is where the software is deployed to end users and is essentially a broad
beta test of the application. Users begin to use the new software, issues are identified and potentially corrected, and any features that were delayed are finished and deployed. The transition phase can include multiple iterations of the software, including beta releases, bug fixes, and enhancements.
The specific activities of this phase include:
user acceptance testingby end users to validate the new software against user expectations
The milestones (that together comprise the Product Release Milestone) that show completion of the Transition phase are:
In addition to the general Unified Process described above (which also covers the Rational Unified Process), the following are other UP variants I have come across. The main difference seems to be in the number of Disciplines each defines (some add, some subtract) and in the number and type of Activities and Artifacts.
The Agile Unified Process is a simplified version of RUP developed by Scott Ambler. It makes a number of changes to RUP, including: 
It is based on the following principles: 
You can download the entire Agile Unified Process documentation from Scott Ambler's Ambysoft web site.
The Enterprise Unified Process is an extension of the Rational Unified Process that was also developed by Scott Ambler. The main differences take the form of new phases and new disciplines.
The three new phases are:
The new Disciplines are: 
The Essential Unified Process was created by Ivar Jacobson as a refined of RUP with the idea of making the Disciplines (now called Practices) user selectable from a library of options so that the user can create a tailored process that meets their needs best. This was considered an improvement because the Disciplines in RUP are all intertwined and cannot be extracted from the overall framework. Jacobson took Practices from RUP, CMMI, and various agile development processes and included them within the option of EssUP.
This separation was undertaken in order to better support aspect-oriented thinking, or what Jacobson called
Separation of Concerns. The Practices were grouped into eight groupings, with five
Development and Technical Practices, and three
Social Engineering, Process, and other Supported Practices. These were:
Development and Technical Practices
Social Engineering, Process and other Supporting Practices
The EssUP web pages are no longer present on Jacobson's web site and development seems to have stopped.
OpenUP is based on the core of the Rational Unified Process that was donated by IBM to the Eclipse Foundation. That core was called the Basic Unified Process (BUP) by IBM, but was evolved into OpenUP. Most of the optional parts of RUP were excluded and some elements were merged.  One of the main differences is that the Eclipse Foundation starts with an
Agile core and then adds the framework on top. The goal was to refine RUP so that it included many of the best practices from the agile world, and so that it was highly suitable for small teams (3-6 people) and small projects (3-6 months effort).  However, the OpenUP process can be extended to make it usable in larger projects.
OpenUP is based on four mutually supporting core principles. These are: 
Because of it's design, OpenUp is thought to address the following issues: 
laundry listof features, requirements and change requests raised on the system.
architectureis not a separate
thing– it is the underlying organization and qualities of the system being built – and the executable architecture is just a state of the underlying design, implementation and test products. To create the right focus on the architectural concerns we prioritize those use cases and other requirements during the elaboration phase that involve the highest technical risks, as identified in the risk list.
just in time, and the project team is involved in the detailed estimation and planning activities: For each iteration the Iteration Plan is populated with the highest-prioritized work items from the work items list and risk list. The team is responsible for identifying and estimating tasks for each work item.
The entire OpenUP process is fully detailed and publicly accessible via the Eclipse Foundation web site. You can even download and customize the framework using the Eclipse Method Composer tool. 
typical RUP projects spend approximately 10% of time in Inception, 25% in Elaboration, 55% in Construction and 10% in Transition, although these figures vary from organization to organization and even from project to project.