Auf dieser Seite werden zwei wichtige Aufgaben von Mitwirkenden behandelt: die Unterzeichnung von Lizenzvereinbarungen für Mitwirkende und die korrekte Verwendung von Lizenzheadern in Ihrem Code.
Lizenzvereinbarungen für Mitwirkende unterzeichnen
Alle Beitragenden, die nur eigene Beiträge zu Ideen, Codes oder Dokumentationen für das Android Open Source Project (AOSP) leisten, müssen eine Lizenzvereinbarung für Beitragende abschließen, unterzeichnen und einreichen. Sie können diese Vereinbarung online über das Code-Review-Tool unterzeichnen. Die Vereinbarung definiert die Bedingungen für die Einbringung von geistigem Eigentum in das AOSP. Diese Lizenz dient dem Schutz der Mitwirkenden und des Projekts. Sie ändert nichts an Ihren Rechten, Ihre eigenen Beiträge für andere Zwecke zu verwenden.
Die Lizenzvereinbarung für Corporate Contributor ist für Unternehmen (oder andere Rechtssubjekte) mit Mitarbeitern verfügbar, die bei AOSP arbeiten. Mit dieser Version der Vereinbarung kann ein Unternehmen Beiträge autorisieren, die von seinen benannten Mitarbeitern eingereicht wurden, und Urheberrechts- und Patentlizenzen gewähren.
Google stützt sich dabei auf die Lizenzvereinbarungen für Beitragende der Apache Software Foundation, die auf der Apache-Website zu finden ist.
Lizenzheader einschließen
Das Android Open Source Project (AOSP) nutzt einige von der Open-Source-Initiative genehmigte Open-Source-Lizenzen für unsere Software.
Die Apache-Lizenz Version 2.0 (Apache 2.0) ist die bevorzugte Lizenz für AOSP. Der Großteil der Android-Software ist mit Apache 2.0 lizenziert. Während das Projekt sich bemüht, die bevorzugte Lizenz einzuhalten, kann es Ausnahmen geben, die von Fall zu Fall behandelt werden. Die Linux-Kernel-Patches unterliegen beispielsweise der GPLv2-Lizenz mit Systemausnahmen, die im Linux Kernel Archives zu finden sind.
Für Userspace-Software (nicht Kernel-Software) bevorzugt Google die Apache 2.0-Lizenz (und ähnliche Lizenzen wie BSD und MIT) gegenüber anderen Lizenzen wie der GNU Lesser General Public License (LGPL). Aus folgenden Gründen:
Bei Android dreht sich alles um Freiheit und Wahlmöglichkeiten. Android soll für mehr Offenheit in der mobilen Welt sorgen. Google kann nicht alle Verwendungsmöglichkeiten unserer Software vorhersagen oder vorschreiben. Google empfiehlt zwar allen Nutzern, offene und modifizierbare Geräte zu entwickeln, aber wir sind nicht der Ansicht, dass wir sie dazu zwingen müssen. Die Nutzung von LGPL-Bibliotheken könnte eingeschränkt sein. Hier sind einige unserer speziellen Bedenken:
Vereinfacht ausgedrückt erfordert die LGPL die Bereitstellung der Quellcodes für die Anwendung, ein schriftliches Angebot für die Quellcodes oder die dynamische Verknüpfung der LGPL-Bibliothek und die Möglichkeit für Nutzer, die Bibliothek manuell zu aktualisieren oder zu ersetzen. Android-Software wird in der Regel als statisches System-Image ausgeliefert. Die Einhaltung dieser Anforderungen schränkt die Designs der Gerätehersteller ein. So ist es beispielsweise schwierig für einen Nutzer, eine Bibliothek auf einem nur lesbaren Flash-Speicher zu ersetzen.
Die LGPL erfordert die Zulassung von Kundenmodifikationen und Reverse-Engineering zum Debuggen dieser Änderungen. Die meisten Gerätehersteller möchten nicht an diese Bedingungen gebunden sein.
In der Vergangenheit waren LGPL-Bibliotheken die Ursache für viele Compliance-Probleme für Gerätehersteller und App-Entwickler. Es ist schwierig und zeitaufwendig, Entwickler über diese Probleme aufzuklären. Für den Erfolg von Android ist es entscheidend, dass Gerätehersteller die Lizenzen problemlos einhalten können.
Dabei handelt es sich nicht um Kritik an LGPL oder anderen Lizenzen. Google schätzt alle kostenlosen und Open-Source-Lizenzen und respektiert die Lizenzpräferenzen anderer. Google hat entschieden, dass Apache 2.0 am besten zu unseren Zielen passt.
Wenn Sie Code einreichen, der in AOSP aufgenommen werden soll, müssen Sie für die ordnungsgemäße Verwendung von Lizenzheadern sorgen. In den folgenden Abschnitten wird erläutert, wie mit Lizenzheadern für neue Dateien und vorhandener Code umgegangen wird.
Best Practices für Lizenzen und Urheberrechte beachten
Beachte die folgenden Best Practices für den Urheberrechts- und Lizenzheader:
Ändern Sie keine vorhandenen Urheberrechte. Wenn Sie beispielsweise eine Datei zu AOSP beitragen möchten, die Code aus einer Datei mit einer eigenen Urheberrechtsvermerk enthält, müssen Sie diesen Urheberrechtsvermerk aus der ursprünglichen Datei beibehalten.
Wenn Sie eine völlig neue Quelldatei hinzufügen, verwenden Sie das standardmäßige AOSP-Urheberrecht und die folgende Lizenzkopfzeile, es sei denn, das Projekt, an dem Sie mitwirken, hat eine andere vordefinierte Lizenz:
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.