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 Mitwirkenden (d. h. diejenigen, die nur eigene Beiträge leisten) im Namen) von Ideen, Codes oder Dokumentationen an das Android Open Source Project (AOSP) weitergeben. erforderlich, um ein Lizenzvereinbarung als Mitwirkender: Sie können diese Vereinbarung online über die Tool zur Codeüberprüfung an. Die Vereinbarung definiert die Bedingungen für die Einbringung von geistigem Eigentum in das AOSP. Diese Lizenz dient Ihrem Schutz als Beitragender sowie dem den Schutz des Projekts; Ihre Rechte, Ihre eigenen zu verwenden, werden dadurch nicht geändert. für jegliche andere Zwecke.
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 Spendenzahlungen autorisieren von seinen benannten Mitarbeitern eingereicht und Urheberrechte und Patente Lizenzen.
Die Lizenzvereinbarungen mit Mitwirkenden beruhen auf den Lizenzvereinbarungen, die von den Apache Software Foundation, die auf der Apache-Website
Lizenzheader einschließen
Das Android Open Source Project (AOSP) verwendet einige Von Open-Source-Initiative genehmigtes Open-Source-Programm 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 sind z. B. unter der Lizenz v2 mit Systemausnahmen zu finden, die unter Die Linux-Kernel-Archive.
Für Userspace-Software (Nicht-Kernel-Software) bevorzugt Google Apache 2.0 (und ähnliche wie BSD und MIT) gegenüber anderen Lizenzen wie GNU Lesser General Public License (LGPL). Aus folgenden Gründen:
Bei Android geht es 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 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 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.
LGPL schreibt kundenseitige Änderungen und Reverse Engineering vor. für das Debugging dieser Änderungen. Die meisten Gerätehersteller möchten Nutzungsbedingungen gelten.
In der Vergangenheit waren LGPL-Bibliotheken die Quelle vieler Compliance-Bibliotheken für nachgelagerte Gerätehersteller und App-Entwickler. Bildung Entwickelnden mit diesen Problemen schwierig und zeitaufwändig ist. Es ist wichtig, Der Erfolg von Android, dass Gerätehersteller die Lizenzen einfach 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 beschrieben, wie Sie Lizenzheader für neue Dateien und vorhandenen Code behandeln.
Best Practices für Lizenzen und Urheberrechte beachten
Beachte die folgenden Best Practices für die Überschrift in Bezug auf Urheberrecht und Lizenz:
Ä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.