本頁面將介紹兩項重要的貢獻者工作：簽署貢獻者授權協議，以及確保在程式碼中正確使用授權標頭。
簽署協作者授權協議
所有個別貢獻者 (僅代表自己貢獻想法、程式碼或文件的貢獻者) 都必須完成、簽署並提交個別貢獻者授權協議。您可以透過 程式碼審查工具。 這項協議會定義貢獻至 AOSP 的智慧財產權條款。此授權旨在保護您作為貢獻者的權利，以及保護專案；但不會影響您將自己的貢獻內容用於其他用途的權利。
企業貢獻者授權協議適用於有員工在 AOSP 上工作的公司 (或其他實體)。這份協議版本可讓企業授權指定員工提交的貢獻內容，並授予版權和專利授權。
Google 的貢獻者授權協議是以 Apache Software Foundation 使用的協議為基礎，您可以在 Apache 網站上找到這類協議。
包含授權標頭
Android 開放原始碼計畫 (AOSP) 會為軟體使用幾個開放原始碼計畫核准的開放原始碼授權。
Apache 授權 2.0 版 (Apache 2.0) 是 Android 開放原始碼計畫的偏好授權，也是大多數 Android 應用程式的首選授權 軟體係由 Apache 2.0 授權提供。這個專案則會盡力遵循 偏好授權，有些例外情況會視個案情況處理 。舉例來說，Linux kernel 修補程式在 GPLv2 授權中屬於 系統例外狀況，請前往 Linux 核心封存檔。
針對使用者空間 (非核心) 軟體，Google 偏好使用 Apache 2.0 (及類似網站) BSD 和 MIT) 的授權) 相較於 GNU Lesser General 等其他授權 公共授權 (LGPL)。原因如下：
Android 強調自由和選擇。Android 的目標是 且 Google 無法預測或決定所有 採用的 AI 開發原則因此，雖然 Google 鼓勵所有人打造開放且可修改的裝置，但我們不認為這是強迫他們這麼做的好方法。使用 LGPL 程式庫可能會受到限制。以下是我們的一些具體疑慮：
簡單來說，LGPL 要求將原始檔提供給應用程式、提供原始檔的書面說明，或是動態連結 LGPL 程式庫，並允許使用者手動升級或取代程式庫。Android 軟體通常會以靜態系統映像檔形式提供，因此遵循這些規定會限制裝置製造商的設計。舉例來說，使用者很難在唯讀快閃儲存空間上取代程式庫。
LGPL 要求客戶必須能夠修改客戶及進行反向工程 以便對這些修改內容進行偵錯大多數裝置製造商都不想受這些條款約束。
以往，LGPL 程式庫一直是許多下游裝置製造商和應用程式開發人員遇到法規遵循問題的來源。向工程師說明這些問題既困難又耗時。裝置製造商能輕鬆遵守授權條款，對 Android 的成功至關重要。
這些疑慮並非對 LGPL 或其他授權的批評。Google 歡迎所有免費開放原始碼授權，並尊重他人的授權偏好設定。Google 已判定 Apache 2.0 最適合用於我們的目標。
提交加入 Android 開放原始碼計畫的程式碼時，請務必正確使用 授權標頭。以下各節將說明如何處理新檔案和現有程式碼的授權標頭。
遵循授權和著作權最佳做法
處理版權和授權標題時，請採用下列最佳做法：
請勿修改現有的版權聲明。舉例來說，如果您想將檔案提交至 AOSP，而該檔案含有來自含有專屬版權聲明的檔案的程式碼，您必須保留原始檔案中的版權聲明。
如果您新增完全新的來源檔案，請使用預設的 AOSP 版權聲明和下列授權標頭，除非您要貢獻的專案有不同的預先定義授權：
Copyright (C) yyyy The Android Open Source Project Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.