Auf dieser Seite werden zwei wichtige Aufgaben für Mitwirkende behandelt: das Unterzeichnen von Lizenzvereinbarungen für Mitwirkende und die korrekte Verwendung von Lizenzheadern in Ihrem Code.
Lizenzvereinbarungen für Mitwirkende unterzeichnen
Alle einzelnen Mitwirkenden (die nur in ihrem eigenen Namen Ideen, Code oder Dokumentation zum Android Open Source Project (AOSP) beitragen) müssen eine Individual Contributor License Agreement (Lizenzvereinbarung für einzelne Mitwirkende) ausfüllen, unterzeichnen und einreichen. Sie können diese Vereinbarung online über das Tool zur Code-Überprüfung abschließen. In der Vereinbarung werden die Bedingungen für die Bereitstellung von geistigem Eigentum für AOSP definiert. Diese Lizenz dient sowohl dem Schutz Ihrer Rechte als Mitwirkender als auch dem Schutz des Projekts. Sie ändert nichts an Ihren Rechten, Ihre eigenen Beiträge für andere Zwecke zu verwenden.
Die Corporate Contributor License Agreement ist für Unternehmen (oder andere Rechtssubjekte) verfügbar, deren Mitarbeiter an AOSP arbeiten. Mit dieser Version der Vereinbarung kann ein Unternehmen Beiträge autorisieren, die von seinen benannten Mitarbeitern eingereicht werden, und Urheberrechts- und Patentlizenzen erteilen.
Google stützt seine Mitwirkenden-Lizenzvereinbarungen auf die der Apache Software Foundation, die auf der Apache-Website zu finden sind.
Lizenzheader einfügen
Das Open-Source-Projekt für Android (Android Open Source Project, AOSP) verwendet 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 und die meisten Android-Softwareprodukte sind mit Apache 2.0 lizenziert. Das Projekt ist bestrebt, 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 in The Linux Kernel Archives zu finden sind.
Für Userspace-Software (nicht Kernel) bevorzugt Google die Apache-Lizenz 2.0 (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 die Offenheit in der mobilen Welt fördern. Google kann nicht alle Verwendungszwecke für unsere Software vorhersagen oder diktieren. Google empfiehlt zwar allen, offene und modifizierbare Geräte zu entwickeln, aber wir sind nicht der Meinung, dass wir sie dazu zwingen sollten. Die Verwendung von LGPL-Bibliotheken kann einschränkend sein. Hier sind einige unserer konkreten Bedenken:
Vereinfacht gesagt erfordert die LGPL, dass der Quellcode mit der Anwendung ausgeliefert wird, ein schriftliches Angebot für den Quellcode vorliegt oder die LGPL-Bibliothek dynamisch verknüpft wird und Nutzer die Bibliothek manuell aktualisieren oder ersetzen können. Android-Software wird in der Regel als statisches System-Image ausgeliefert. Die Einhaltung dieser Anforderungen schränkt daher die Designs der Gerätehersteller ein. So ist es für einen Nutzer beispielsweise schwierig, eine Bibliothek auf einem schreibgeschützten Flash-Speicher zu ersetzen.
Die LGPL erfordert, dass Kunden Änderungen vornehmen und Reverse Engineering zur Fehlersuche bei diesen Änderungen durchführen dürfen. Die meisten Gerätehersteller möchten nicht an diese Bedingungen gebunden sein.
In der Vergangenheit haben LGPL-Bibliotheken bei Geräteherstellern und App-Entwicklern oft zu Compliance-Problemen geführt. Es ist schwierig und zeitaufwendig, Entwickler über diese Probleme zu informieren. Es ist entscheidend für den Erfolg von Android, 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 Open-Source-Lizenzen und respektiert die Lizenzpräferenzen anderer. Google hat entschieden, dass die Apache 2.0-Lizenz am besten zu unseren Zielen passt.
Wenn Sie Code zur Aufnahme in AOSP einreichen, müssen Sie für eine ordnungsgemäße Verwendung von Lizenzheadern sorgen. In den folgenden Abschnitten wird beschrieben, wie Sie Lizenzheader für neue Dateien und vorhandenen Code verarbeiten.
Best Practices für Lizenzen und Urheberrecht
Beachten Sie die folgenden Best Practices für den Copyright- und Lizenzheader:
Ändern Sie keine bestehenden Urheberrechtsangaben. Wenn Sie beispielsweise eine Datei zu AOSP beitragen möchten, die Code aus einer Datei mit einem eigenen Copyright-Hinweis enthält, müssen Sie diesen Copyright-Hinweis aus der Originaldatei beibehalten.
Wenn Sie eine völlig neue Quelldatei hinzufügen, verwenden Sie das standardmäßige AOSP-Copyright und den folgenden Lizenzheader, sofern das Projekt, zu dem Sie beitragen, keine andere vordefinierte Lizenz hat:
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.