zh-cn/setup/licenses.html - platform/docs/source.android.com - Git at Google

 <html devsite><head>
     <title>内容许可</title>
     <meta name="project_path" value="/_project.yaml"/>
     <meta name="book_path" value="/_book.yaml"/>
   </head>
   <body>
   <!--
       Copyright 2017 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.
   -->

 <p>在 Android 开源项目中，我们的软件使用<a href="http://www.opensource.org/">开放源代码促进会</a>批准的一些开放源代码许可。</p>
 <h2 id="android-open-source-project-license">Android 开放源代码项目许可</h2>
 <p>Android 开源项目的首选许可是 <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache Software License 2.0 版</a>（“Apache 2.0”），Android 软件的大部分内容都是根据 Apache 2.0 授权用户使用。尽管该项目将尽可能遵循此首选许可，但也可能存在将根据具体情况处理的例外情况。例如，与系统使用的许可不同，Linux 内核补丁程序使用的是 GPLv2 许可，您可以在 <a href="http://www.kernel.org/pub/linux/kernel/COPYING">kernel.org</a> 上找到相关信息。</p>
 <h2 id="contributor-license-grants">贡献者许可协议</h2>
 <p><em></em>为 Android 开源项目提供想法、代码或文档的所有个人贡献者（即仅以个人名义做贡献的贡献者）都需要填写、签署并提交《<a href="https://cla.developers.google.com/about/google-individual">个人贡献者许可协议</a>》。该协议可通过<a href="https://android-review.googlesource.com/#/settings/agreements">代码审核工具</a>在线签署。该协议明确规定了他们为 Android 开放源代码项目贡献知识产权内容时遵循的条款。该许可既是为了保护贡献者，也是为了保护该项目；它不会影响贡献者将贡献内容用于任何其他用途的权利。</p>
 <p><em></em>对于已指派员工参与 Android 开源项目的企业（或其他实体），则需要签署《<a href="https://cla.developers.google.com/about/google-corporate">企业贡献者许可协议</a>》。该版本的协议中规定，企业可以对其指派的员工提交的贡献内容进行授权，并可以授予版权和专利许可。请注意，签署《企业贡献者许可协议》并不意味着任何开发者无需再以个人名义签署《个人贡献者许可协议》。所有开发者都必须签署个人协议，以涵盖他们贡献的任何不归签署《企业贡献者许可协议》的企业所有的内容。<em></em></p>
 <p>请注意，我们的协议是根据 <a href="http://www.apache.org">Apache 软件基金会</a>所用的协议（可在 <a href="http://www.apache.org/licenses/">Apache 网站</a>上找到）制定的。</p>
 <h2 id="why-apache-software-license">为什么使用 Apache Software License？</h2>
 <p>有时候，有人会问我们，为什么 Apache Software License 2.0 是 Android 的首选许可。对于用户空间（即非内核）软件，相比其他许可（例如 LGPL），我们确实更倾向于 ASL2.0（以及 BSD、MIT 等类似许可）。</p>
 <p>Android 的宗旨是自由和选择。Android 旨在促进移动世界的开放性，我们不认为我们能够预测出或规定用户希望将我们的软件应用到的所有用途。因此，虽然我们鼓励每个人打造开放且可修改的设备，但我们并不认为我们有权利强制他们这样做。使用 LGPL 库则往往会强制他们这样做。</p>
 <p>以下是我们关心的一些具体问题：</p>
 <ul>
 <li>
 <p>LGPL（简化条款形式）要求：将源代码植入到应用中；书面提供源代码；或者动态关联 LGPL-ed 库，并允许用户手动升级或替换该库。由于 Android 软件通常是以静态系统映像的形式植入的，因此遵守这些要求最终会限制原始设备制造商 (OEM) 的设计。（例如，用户很难在只读闪存中替换库。）</p>
 </li>
 <li>
 <p>LGPL 要求允许用户进行修改，并要求允许用户进行逆向工程以便调试这些修改。大多数设备制造商都不希望受到这些条款的约束。因此，为了尽量减轻这些公司的负担，我们会最大限度地减少在用户空间中使用 LGPL 软件。</p></li><p></p>

 <li>
 <p>过去，LGPL 库是下游设备制造商和应用开发者面临的大量合规问题的根源。遗憾的是，就这些问题对工程师提供指导非常困难而且进展缓慢。设备制造商能够尽可能轻松地遵守许可对于 Android 的成功至关重要。鉴于过去在遵守 LGPL 方面遇到的困难，最明智的做法就是，如果我们能够避免使用 LGPL 库，便不使用它们。</p>
 </li>
 </ul>
 <p>上面讨论的问题是我们为自己的代码首选 ASL2.0 的原因。它们并不是批判 LGPL 或其他许可。我们非常热衷于这一主题，甚至不厌其烦地想方设法确保尽可能多的代码根据 ASL2.0 授权用户使用。不过，我们喜欢各种免费的开放源代码许可，并尊重其他人的意见和偏好。我们只是认定 ASL2.0 是适合我们目标的许可而已。</p>

 </body></html>
	<html devsite><head>
	<title>内容许可</title>
	<meta name="project_path" value="/_project.yaml"/>
	<meta name="book_path" value="/_book.yaml"/>
	</head>
	<body>
	<!--
	Copyright 2017 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.
	-->

	<p>在 Android 开源项目中，我们的软件使用<a href="http://www.opensource.org/">开放源代码促进会</a>批准的一些开放源代码许可。</p>
	<h2 id="android-open-source-project-license">Android 开放源代码项目许可</h2>
	<p>Android 开源项目的首选许可是 <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache Software License 2.0 版</a>（“Apache 2.0”），Android 软件的大部分内容都是根据 Apache 2.0 授权用户使用。尽管该项目将尽可能遵循此首选许可，但也可能存在将根据具体情况处理的例外情况。例如，与系统使用的许可不同，Linux 内核补丁程序使用的是 GPLv2 许可，您可以在 <a href="http://www.kernel.org/pub/linux/kernel/COPYING">kernel.org</a> 上找到相关信息。</p>
	<h2 id="contributor-license-grants">贡献者许可协议</h2>
	<p><em></em>为 Android 开源项目提供想法、代码或文档的所有个人贡献者（即仅以个人名义做贡献的贡献者）都需要填写、签署并提交《<a href="https://cla.developers.google.com/about/google-individual">个人贡献者许可协议</a>》。该协议可通过<a href="https://android-review.googlesource.com/#/settings/agreements">代码审核工具</a>在线签署。该协议明确规定了他们为 Android 开放源代码项目贡献知识产权内容时遵循的条款。该许可既是为了保护贡献者，也是为了保护该项目；它不会影响贡献者将贡献内容用于任何其他用途的权利。</p>
	<p><em></em>对于已指派员工参与 Android 开源项目的企业（或其他实体），则需要签署《<a href="https://cla.developers.google.com/about/google-corporate">企业贡献者许可协议</a>》。该版本的协议中规定，企业可以对其指派的员工提交的贡献内容进行授权，并可以授予版权和专利许可。请注意，签署《企业贡献者许可协议》并不意味着任何开发者无需再以个人名义签署《个人贡献者许可协议》。所有开发者都必须签署个人协议，以涵盖他们贡献的任何不归签署《企业贡献者许可协议》的企业所有的内容。<em></em></p>
	<p>请注意，我们的协议是根据 <a href="http://www.apache.org">Apache 软件基金会</a>所用的协议（可在 <a href="http://www.apache.org/licenses/">Apache 网站</a>上找到）制定的。</p>
	<h2 id="why-apache-software-license">为什么使用 Apache Software License？</h2>
	<p>有时候，有人会问我们，为什么 Apache Software License 2.0 是 Android 的首选许可。对于用户空间（即非内核）软件，相比其他许可（例如 LGPL），我们确实更倾向于 ASL2.0（以及 BSD、MIT 等类似许可）。</p>
	<p>Android 的宗旨是自由和选择。Android 旨在促进移动世界的开放性，我们不认为我们能够预测出或规定用户希望将我们的软件应用到的所有用途。因此，虽然我们鼓励每个人打造开放且可修改的设备，但我们并不认为我们有权利强制他们这样做。使用 LGPL 库则往往会强制他们这样做。</p>
	<p>以下是我们关心的一些具体问题：</p>
	<ul>
	<li>
	<p>LGPL（简化条款形式）要求：将源代码植入到应用中；书面提供源代码；或者动态关联 LGPL-ed 库，并允许用户手动升级或替换该库。由于 Android 软件通常是以静态系统映像的形式植入的，因此遵守这些要求最终会限制原始设备制造商 (OEM) 的设计。（例如，用户很难在只读闪存中替换库。）</p>
	</li>
	<li>
	<p>LGPL 要求允许用户进行修改，并要求允许用户进行逆向工程以便调试这些修改。大多数设备制造商都不希望受到这些条款的约束。因此，为了尽量减轻这些公司的负担，我们会最大限度地减少在用户空间中使用 LGPL 软件。</p></li><p></p>

	<li>
	<p>过去，LGPL 库是下游设备制造商和应用开发者面临的大量合规问题的根源。遗憾的是，就这些问题对工程师提供指导非常困难而且进展缓慢。设备制造商能够尽可能轻松地遵守许可对于 Android 的成功至关重要。鉴于过去在遵守 LGPL 方面遇到的困难，最明智的做法就是，如果我们能够避免使用 LGPL 库，便不使用它们。</p>
	</li>
	</ul>
	<p>上面讨论的问题是我们为自己的代码首选 ASL2.0 的原因。它们并不是批判 LGPL 或其他许可。我们非常热衷于这一主题，甚至不厌其烦地想方设法确保尽可能多的代码根据 ASL2.0 授权用户使用。不过，我们喜欢各种免费的开放源代码许可，并尊重其他人的意见和偏好。我们只是认定 ASL2.0 是适合我们目标的许可而已。</p>

	</body></html>