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 Einzelpersonen, die Ideen, Code oder Dokumentationen zum Android Open Source Project (AOSP) beitragen (nur in eigenem Namen), müssen eine Contributor License Agreement (Lizenzvereinbarung für Einzelpersonen) ausfüllen, 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 Unternehmensmitarbeiter ist für ein Unternehmen (oder eine andere Rechtspersönlichkeit) mit Mitarbeitern verfügbar, die an 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 orientiert sich bei seinen Mitwirkenden-Lizenzvereinbarungen an denen der Apache Software Foundation, die auf der Apache-Website zu finden sind.
Lizenzheader einschließen
Das Android Open Source Project (AOSP) verwendet für seine Software einige Open Source-Lizenzen, die von der Open Source Initiative genehmigt wurden.
Die Apache License, 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. Bei diesem Projekt wird zwar versucht, die bevorzugte Lizenz einzuhalten, es gibt jedoch Ausnahmen, 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:
Android steht für Freiheit und Auswahl. Android soll für mehr Offenheit in der mobilen Welt sorgen. Google kann nicht alle Verwendungsmöglichkeiten unserer Software vorhersagen oder vorschreiben. Google ermutigt zwar alle dazu, offene und modifizierbare Geräte herzustellen, wir sind aber der Meinung, dass wir sie nicht dazu zwingen sollten. Die Verwendung von LGPL-Bibliotheken könnte einschränkend sein. Hier sind einige unserer konkreten 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.
Diese Bedenken sind keine Kritik an der 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 beschrieben, wie Sie Lizenzheader für neue Dateien und vorhandenen Code behandeln.
Best Practices für Lizenzen und Urheberrecht 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.