Fixing 2 of the remaining broken links.
Change-Id: I5cdfb83be4fa30574c807eff668f95e26a1cba8c
diff --git a/src/about/index.md b/src/about/index.md
index f247561..0a51b7d 100644
--- a/src/about/index.md
+++ b/src/about/index.md
@@ -15,11 +15,11 @@
- [Our Project Philosophy and Goals](philosophy.html)
-- [People and Roles](roles.html)
+- [People and Roles](/source/roles.html)
- [Interacting with the Project](/source/index.html)
- [Android Compatibility](/compatibility/index.html)
-- [Licensing Information](licenses.html)
+- [Licensing Information](/source/licenses.html)
diff --git a/src/about/licenses.md b/src/about/licenses.md
deleted file mode 100644
index 677abcc..0000000
--- a/src/about/licenses.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# Licenses #
-
-The Android Open Source Project uses a few [open source initiative](http://www.opensource.org/)
-approved open source licenses for our software.
-
-## Android Open Source Project license ##
-
-The preferred license for the Android Open Source Project is the [Apache
-Software License, 2.0](http://www.apache.org/licenses/LICENSE-2.0) ("Apache 2.0"),
-and the majority of the Android software is licensed
-with Apache 2.0. While the project will strive to adhere to the preferred
-license, there may be exceptions which will be handled on a case-by-case
-basis. For example, the Linux kernel patches are under the GPLv2 license with
-system exceptions, which can be found on [kernel.org](http://www.kernel.org/pub/linux/kernel/COPYING).
-
-## Contributor License Grants ##
-
-All *individual* contributors (that is, contributors making contributions
-only on their own behalf) of ideas, code, or documentation to the Android Open
-Source Project will be required to complete, sign, and submit an [Individual
-Contributor License Grant](cla-individual.html). The grant can be executed online through the
-[code review tool](https://review.source.android.com/#settings,agreements).
-The grant clearly defines the terms under which intellectual
-property has been contributed to the Android Open Source Project. This license
-is for your protection as a contributor as well as the protection of the
-project; it does not change your rights to use your own contributions for any
-other purpose.
-
-For a *corporation* (or other entity) that has assigned employees to
-work on the Android Open Source Project, a [Corporate
-Contributor License Grant](cla-corporate.html) is available.
-This version of the grant allows a
-corporation to authorize contributions submitted by its designated employees
-and to grant copyright and patent licenses. Note that a Corporate Contributor
-License Grant does not remove the need for any developer to sign their own
-Individual Contributor License Grant as an individual, to cover any of their
-contributions which are *not* owned by the corporation signing the
-Corporate Contributor License Grant.
-
-Please note that we based our grants on the ones that the
-[Apache Software Foundation](http://www.apache.org) uses, which can
-be found on [the Apache web site](http://www.apache.org/licenses/).
-
-## Why Apache Software License? ##
-
-We are sometimes asked why Apache Software License 2.0 is the preferred
-license for Android. For userspace (that is, non-kernel) software, we do in
-fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other
-licenses such as LGPL.
-
-Android is about freedom and choice. The purpose of Android is promote
-openness in the mobile world, but we don't believe it's possible to predict or
-dictate all the uses to which people will want to put our software. So, while
-we encourage everyone to make devices that are open and modifiable, we don't
-believe it is our place to force them to do so. Using LGPL libraries would
-often force them to do so.
-
-Here are some of our specific concerns:
-
-- LGPL (in simplified terms) requires either: shipping of source to the
-application; a written offer for source; or linking the LGPL-ed library
-dynamically and allowing users to manually upgrade or replace the library.
-Since Android software is typically shipped in the form of a static system
-image, complying with these requirements ends up restricting OEMs' designs.
-(For instance, it's difficult for a user to replace a library on read-only
-flash storage.)
-
-- LGPL requires allowance of customer modification and reverse
-engineering for debugging those modifications. Most device makers do
-not want to have to be bound by these terms, so to minimize the burden on
-these companies we minimize usage of LGPL software in userspace.</li>
-
-- Historically, LGPL libraries have been the source of a large number
-of compliance problems for downstream device makers and application
-developers. Educating engineers on these issues is difficult and slow-going,
-unfortunately. It's critical to Android's success that it be as easy as
-possible for device makers to comply with the licenses. Given the
-difficulties with complying with LGPL in the past, it is most prudent to
-simply not use LGPL libraries if we can avoid it.
-
-The issues discussed above are our reasons for preferring ASL2.0 for
-our own code. They aren't criticisms of LGPL or other licenses. We do
-feel strongly on this topic, even to the point where we've gone out of our
-way to make sure as much code as possible is ASL2.0. However, we love all free
-and open source licenses, and respect others' opinions and preferences. We've
-simply decided that ASL2.0 is the right license for our goals.
-
diff --git a/src/about/roles.md b/src/about/roles.md
deleted file mode 100644
index 1badf26..0000000
--- a/src/about/roles.md
+++ /dev/null
@@ -1,79 +0,0 @@
-# People and Roles #
-
-The Android Open Source Project (AOSP) includes individuals working in a variety
-of roles. As noted in [Our Philosophy](about/philosophy.html), Google is responsible for Android product management
-and the engineering process for the core framework and platform; however,
-the project considers contributions from any source, not just Google. This
-page describes the kinds of roles that interested parties can take on.
-
-Anyone who is interested in exploring and contributing to Android can use the
-Android Open Source Project resources. Anyone can join the mailing lists, ask
-questions, contribute patches, report bugs, look at submitted patches, and use
-the tools. To get started with the Android code, see [Get Involved](source/index.html).
-
-## Contributor ##
-
-A "Contributor" is anyone making contributions to the AOSP source code,
-including both employees of Google or other companies, as well as external
-developers who are contributing to Android on their own behalf. There is no
-distinction between Contributors who are employed by Google, and those who are
-not: all engineers use the same tools (git, repo, and gerrit),
-follow the same code review process, and are subject
-to the same requirements on code style and so on.
-
-## Developer ##
-
-A "Developer" is an engineer writing applications that run on Android
-devices. There is, of course, no difference in skillset between a "Developer"
-and a "Contributor", but AOSP uses "Developer" to distinguish between
-engineers using the platform and those contributing to it. Developers are
-(along with end users) the "customers" of the platform that the Contributors
-create. As such, we talk about Developers a lot, though this isn't technically
-a separate role in the AOSP per se.
-
-## Verifier ##
-
-"Verifiers" are responsible for testing change requests. After individuals
-have submitted a significant amount of high-quality code to the project, the
-Project Leads might invite them to become Verifiers. *Note: at this
-time, generally Verifiers are the same as Approvers.*
-
-## Approver ##
-
-"Approvers" are experienced members of the project who have demonstrated their
-design skills and have made significant technical contributions to the
-project. In the code-review process, an Approver decides whether to include or
-exclude a change. Project Leads (who are typically employed by Google) choose
-the Approvers, sometimes promoting to this position Verifiers who have
-demonstrated their expertise within a specific project.
-
-## Project Leads ##
-
-Android consists of a number of sub-projects; you can see these in the git
-repository, as individual .git files. Tech Leads are senior Contributors who
-oversee the engineering for individual Android projects. Typically these tech
-leads will be Google employees. A Project Lead for an individual project is
-responsible for the following:
-
-- Lead all technical aspects of the project; for example, the project roadmap,
- development, release cycles, versioning, and QA.
-
-- Ensure that the project is QA-ed in time for scheduled Android platform
- releases.
-
-- Designate Verifiers and Approvers for submitted patches.
-
-- Be fair and unbiased while reviewing changes. Accept or reject patches
- based on technical merit and alignment with the Android strategy.
-
-- Review changes in a timely manner and make best efforts to communicate
- when changes are not accepted.
-
-- Optionally maintain a web site for the project for information and
- documents specific to the project.
-
-- Act as a facilitator in resolving technical conflicts.
-
-- Be a public face for the project and the go-to person for questions
- related to the project.
-
diff --git a/src/about/sidebar.md b/src/about/sidebar.md
index acc32cf..f9f0c6e 100644
--- a/src/about/sidebar.md
+++ b/src/about/sidebar.md
@@ -1,8 +1,8 @@
# Links #
- [Project Philosophy](philosophy.html)
-- [People and Roles](roles.html)
+- [People and Roles](/source/roles.html)
- [Getting Involved](/source/index.html)
- [Compatibility](/compatibility/index.html)
-- [Licensing Information](licenses.html)
+- [Licensing Information](/source/licenses.html)