Contributor-Lizenzvereinbarungen und -Header

Auf dieser Seite werden zwei wichtige Aufgaben für Beitragende behandelt: die Lizenz für Mitwirkende unterzeichnen. Vereinbarungen und die korrekte Verwendung von Lizenzierungsheadern in deinem Code.

Lizenzvereinbarungen für Beitragende 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) senden. erforderlich, um ein Lizenzvereinbarung für Beitragende: Sie können diese Vereinbarung online über die Tool zur Codeüberprüfung an. Die Vereinbarung legt die Bedingungen für den Beitrag geistigen Eigentums fest. an AOSP. Diese Lizenz dient Ihrem Schutz als Beitragender sowie dem den Schutz des Projekts; Ihre Rechte, Ihre eigenen zu verwenden, bleiben davon unberührt. für jegliche andere Zwecke.

Die Lizenzvereinbarung für Mitwirkende in Unternehmen ist für ein Unternehmen (oder ein anderes Rechtssubjekt) mit Mitarbeitern verfügbar, die bei 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 basieren auf den 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.

Apache-Lizenz, Version 2.0 (Apache 2.0) ist die bevorzugte Lizenz für AOSP. Die meisten von Android ist unter Apache 2.0 lizenziert. Während das Projekt darauf abzielt, die bevorzugte Lizenz erhalten, gibt es Ausnahmen, die von Fall zu Fall gehandhabt werden. zu verstehen. 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 dreht sich alles um Freiheit und Wahlmöglichkeiten. Der Zweck von Android ist es, Offenheit in der mobilen Welt und Google kann nicht alle Maßnahmen vorhersagen oder für unsere Software. Während Google jeden dazu ermutigt, modifizierbare Geräte haben, denken wir nicht, dass wir sie dazu zwingen müssen. Mit LGPL-Bibliotheken könnten restriktiv sein. Hier sind einige unserer speziellen Bedenken:

    • Vereinfacht ausgedrückt, verlangt LGPL die Übermittlung der Quelle an die Anwendung. eine schriftliches Quellangebot oder die LGPL-ed-Bibliothek dynamisch verknüpfen sodass Nutzer die Bibliothek manuell aktualisieren oder ersetzen können. Android-Software ist in der Regel als statisches System-Image versendet. Die Einhaltung dieser die Designs von Geräteherstellern einschränken. Zum Beispiel ist es für einen Nutzer schwierig, eine Bibliothek auf einem schreibgeschützten 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 respektieren die Lizenzeinstellungen. Wir haben beschlossen, dass Apache 2.0 am besten zu unseren Zielen passt.

Wenn Sie Code zur Aufnahme in AOSP einreichen, müssen Sie sicherstellen, Lizenz-Headern. In den folgenden Abschnitten wird erläutert, wie Sie Lizenz-Header für neue Dateien und vorhandenem Code.

Beachte die folgenden Best Practices für die Überschrift in Bezug auf Urheberrecht und Lizenz:

  • Ändern Sie kein vorhandenes Urheberrecht. Wenn Sie zum Beispiel in AOSP, die Code enthält, der aus einer Datei mit einer eigenen müssen Sie den Urheberrechtshinweis aus der Originaldatei beibehalten.

  • Wenn Sie eine völlig neue Quelldatei hinzufügen, verwenden Sie das Standard-AOSP-Urheberrecht und den Lizenz-Header verwenden, es sei denn, das Projekt, zu dem Sie beitragen 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.