Licenses
라이센스
The Android Open Source Project uses a few open source initiative approved open source licenses for our software.
안드로이드 오픈소스 프로젝트는 오픈소스 이니셔티브에 인증된 오픈소스 라이센스를 사용한다.
Android Open Source Project Licenses
안드로이드 오픈소스 라이센스
The preferred license for the Android Open Source Project is the Apache Software License, Version 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 that 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.
안드로이드 오픈소스 프로젝트는 아파치 소프트웨어 라이센스, 버전2.0 ("아파치 2.0")을 따른다. 그리고 많은 안드로이드 소프트웨어는 아파지 2.0에 허가된다. 프로젝트가 라이센스에 따르도록 하는 동안, 각 상황별로 다루어지게 될 것이다. 예를 들어 리눅스 커널 패치는 system exceptions(시스템 익셉션)과 GPLv2 라이센스를 따른다. kernel.org에서 찾을 수 있다.
Contributor License Agreement
컨티리뷰터 라이센스 동의
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 Agreement. The agreement can be executed online through the code review tool. The agreement 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 Agreement is available. This version of the agreement allows a corporation to authorize contributions submitted by its designated employees and to grant copyright and patent licenses. Note that a Corporate Contributor License Agreement does not remove the need for any developer to sign their own Individual Contributor License Agreement as an individual. The individual agreement is needed to cover any of their contributions that are not owned by the corporation signing the Corporate Contributor License Agreement.
안드로이드 오픈소스 프로젝트에 일을 할 직원을 할당한 기업(또는 다른 독립체)은 기업 컨트리뷰터 라이센스 동의서를 작성해야한다. 이 버전의 동의서는 기업의 지정된 직원이 기여(코드, 문서 기타 등등) 제출을 허락하고, 저작권과 특허권을 허가한다. 기업 컨트리뷰터 라이센스 동의서는 모든 개발자들의 개별 컨트리뷰터 라이센스 동의서를 개인적으로 서명할 필요를 제거하지 않는다. 개별 동의서는 기업에 의한 기여를 그들이 포함하도록 필요하다.
Please note we based our agreements on the ones the Apache Software Foundation uses, which can be found on the Apache web site.
우리들의 동의서는 아파치 웹사이트에서 찾을수 있는 아파치 소프트웨어 재단을 사용한다.
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.
우리는 종종 왜 아파치 소프트웨어 라이센스 2.0이 안드로이드 라이센스에 우선시 되는 라이센스인지 질문을 받는다. 사용자공간(커널이 아닌) 소프트웨어에서, 우리는 ASL2.0(그리고 BSD, MIT 등과 같은 비슷한 라이센스)를 LGPL과 같은 다른 라이센스보다 선호한다.
Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, and 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 just that.
안드로이드는 자유와 선택에 관한 것이다. 안드로이드의 목적은 모바일 세계에서의 솔직함을 지향하는 것이다. 우리는 사용자들이 우리의 소프트웨어를 사용하는 것을 예측하고, 영향을 미치는 것을 불가능 하다고 믿는다. 즉, 우리가 모두에게 공개되고 변경가능한 기기들을 만들도록 하는 동안 그들을 그렇게 하도록 하는 것이 우리들의 역활이라고 생각하지 않는다. LGPL 라이브러리를 사용하는 것은 종종 그들을 단지 그것을 하게 만든다.
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.
- 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.
- 간단히 LGPL는 : 어플리케이션으로 소스코드 배송, 제공하기 위해 작성된 소스코드, 또는 동적으로 LGPL라이브러리에 연결하고, 유저가 수동으로 업그레이드 또는 라이브러리를 바꾸는 것을 허락하는 것중 하나를 요구한다. 안드로이드 소프트웨어가 일반적으로 고정된 시스템 이미지로부터 배송되었을 때 부터, OEM업체의 제한된 디자인 자격요건을 따른다.(대신, 읽기만 가능한 플레시 저장소에 라이브러리를 교체하기 어렵다.)
- LGPL은 사용자 수정사항과 리버스엔지니어링을 그들의 수정사항의 디버깅을 위해 필요로한다. 대부분의 기기 제조사들은 이러한 제약에 구속되기를 원치 않는다. 그래서 기업들의 짐을 최소화하고, 우리는 사용자공간의 LGPL소프트웨어 사용을 최소화한다.
- 지금까지 LGPL 라이브러리는 소규모기기 제조사와 어플리케이션 개발자들의 많은 수의 규정 준수 문제의 원인이 되었다. 불행하게도, 엔지니어링교육을 하기에는 이런 이슈들은 어렵고 느리다. 이것은 가능한 쉽게 기기 제조사들이 라이센스를 따르도록 할려는 안드로이드 성공의 위협적이다. 과거의 LGPL를 따르는 것이 어려운 것은, 만약 그것을 피할 수 있다면, 가장 신중하게 간단히 LGPL 라이브러리를 사용하지 않는 것이다.