इस पेज पर, योगदान देने वाले लोगों के दो अहम टास्क के बारे में बताया गया है: योगदान देने वाले लोगों के लाइसेंस समझौतों पर हस्ताक्षर करना और अपने कोड में लाइसेंस हेडर का सही इस्तेमाल करना.
योगदान देने वाले के लाइसेंस के कानूनी समझौतों पर हस्ताक्षर करना
Android Open Source Project (AOSP) में अपने आइडिया, कोड या दस्तावेज़ों का योगदान देने वाले सभी लोगों को, योगदान देने वाले व्यक्ति का लाइसेंस समझौता भरना होगा, उस पर हस्ताक्षर करना होगा, और उसे सबमिट करना होगा. कोड की समीक्षा करने वाले टूल की मदद से, इस कानूनी समझौते को ऑनलाइन किया जा सकता है. इस कानूनी समझौते में, AOSP में बौद्धिक संपत्ति का योगदान देने की शर्तें बताई गई हैं. यह लाइसेंस, योगदान देने वाले के तौर पर आपकी और प्रोजेक्ट की सुरक्षा के लिए है. इससे, किसी दूसरे मकसद के लिए अपने योगदान का इस्तेमाल करने के आपके अधिकारों पर कोई असर नहीं पड़ता.
कॉर्पोरेट योगदानकर्ता का लाइसेंस समझौता, किसी ऐसे कॉर्पोरेशन (या अन्य इकाई) के लिए उपलब्ध है जिसके कर्मचारी AOSP पर काम करते हैं. इस कानूनी समझौते के तहत, कंपनी अपने चुने गए कर्मचारियों के योगदान को अनुमति दे सकती है. साथ ही, कॉपीराइट और पेटेंट के लाइसेंस भी दे सकती है.
Google, योगदान देने वाले लोगों के लाइसेंस समझौतों को Apache Software Foundation के लाइसेंस समझौतों के आधार पर बनाता है. इन समझौतों के बारे में Apache की वेबसाइट पर जानकारी मिल सकती है.
लाइसेंस हेडर शामिल करना
Android Open Source Project (AOSP), हमारे सॉफ़्टवेयर के लिए, ओपन सोर्स इनिशिएटिव से मंज़ूरी पा चुके कुछ ओपन सोर्स लाइसेंस का इस्तेमाल करता है.
Apache License, वर्शन 2.0 (Apache 2.0), AOSP का पसंदीदा लाइसेंस है. साथ ही, ज़्यादातर Android सॉफ़्टवेयर के पास Apache 2.0 का लाइसेंस है. प्रोजेक्ट, पसंदीदा लाइसेंस का पालन करने की कोशिश करता है. हालांकि, कुछ अपवाद भी होते हैं. इन्हें हर मामले के हिसाब से हैंडल किया जाता है. उदाहरण के लिए, Linux kernel के पैच, GPLv2 लाइसेंस के तहत आते हैं. हालांकि, इनमें सिस्टम से जुड़े अपवाद भी शामिल हैं. इन अपवादों के बारे में The Linux Kernel Archives पर जानकारी मिल सकती है.
Google, यूज़रस्पेस (नॉन-कर्नल) सॉफ़्टवेयर के लिए, GNU Lesser General Public License (LGPL) जैसे अन्य लाइसेंस के बजाय, Apache 2.0 (और BSD और MIT जैसे मिलते-जुलते लाइसेंस) को प्राथमिकता देता है. ऐसा इन वजहों से हो सकता है:
Android, उपयोगकर्ताओं को कई विकल्प और स्वतंत्रता देता है. Android का मकसद मोबाइल दुनिया में सबके लिए खुलेपन को बढ़ावा देना है और Google हमारे सॉफ़्टवेयर के सभी इस्तेमाल का अनुमान नहीं लगा सकता या उनके लिए कोई निर्देश नहीं दे सकता. इसलिए, Google सभी लोगों को खुले और बदलाव करने लायक डिवाइस बनाने के लिए प्रोत्साहित करता है, लेकिन हमें नहीं लगता कि उन्हें ऐसा करने के लिए बाध्य करना हमारी ज़िम्मेदारी है. LGPL लाइब्रेरी का इस्तेमाल करना प्रतिबंधित हो सकता है. यहां कुछ खास समस्याओं के बारे में बताया गया है:
आसान शब्दों में, एलजीपीएल के तहत, ऐप्लिकेशन में सोर्स को शिप करना ज़रूरी है. इसके अलावा, सोर्स के लिए लिखित ऑफ़र देना या एलजीपीएल लाइब्रेरी को डाइनैमिक तौर पर लिंक करना और उपयोगकर्ताओं को लाइब्रेरी को मैन्युअल तरीके से अपग्रेड या बदलने की अनुमति देना भी ज़रूरी है. आम तौर पर, Android सॉफ़्टवेयर को स्टैटिक सिस्टम इमेज के तौर पर शिप किया जाता है. इसलिए, इन ज़रूरी शर्तों का पालन करने से, डिवाइस बनाने वाली कंपनी के डिज़ाइन पर पाबंदी लगती है. उदाहरण के लिए, किसी उपयोगकर्ता के लिए रीड-ओनली फ़्लैश स्टोरेज पर मौजूद लाइब्रेरी को बदलना मुश्किल होता है.
एलजीएलपी के तहत, ग्राहक को बदलाव करने की अनुमति होनी चाहिए. साथ ही, उन बदलावों को डीबग करने के लिए, रिवर्स इंजीनियरिंग की अनुमति भी होनी चाहिए. ज़्यादातर डिवाइस निर्माता इन शर्तों से बाध्य नहीं होना चाहिए.
आम तौर पर, एलजीपीएल लाइब्रेरी, डिवाइस बनाने वाली कंपनियों और ऐप्लिकेशन डेवलपर के लिए, नीतियों का पालन करने से जुड़ी कई समस्याओं का सोर्स रही हैं. इन समस्याओं के बारे में इंजीनियरों को बताना मुश्किल और समय लेने वाला काम है. Android को सफल बनाने के लिए, यह ज़रूरी है कि डिवाइस बनाने वाली कंपनियां लाइसेंस का आसानी से पालन कर सकें.
इन समस्याओं की वजह से, LGPL या दूसरे लाइसेंस की आलोचना नहीं की जा सकती. Google सभी मुफ़्त और ओपन सोर्स लाइसेंस की सराहना करता है. साथ ही, दूसरों की लाइसेंस प्राथमिकताओं का सम्मान करता है. Google ने फ़ैसला लिया है कि Apache 2.0 हमारे लक्ष्यों के लिए सबसे सही है.
AOSP में शामिल किए जाने के लिए कोड सबमिट करते समय, आपको लाइसेंस हेडर का सही इस्तेमाल करना होगा. नीचे दिए गए सेक्शन में, नई फ़ाइलों और मौजूदा कोड के लिए, लाइसेंस हेडर को मैनेज करने का तरीका बताया गया है.
लाइसेंस और कॉपीराइट के सबसे सही तरीकों का पालन करना
कॉपीराइट और लाइसेंस हेडर के लिए, ये सबसे सही तरीके अपनाएं:
किसी मौजूदा कॉपीराइट में बदलाव न करें. उदाहरण के लिए, अगर आपको AOSP में ऐसी फ़ाइल का योगदान देना है जिसमें ऐसा कोड शामिल है जो किसी ऐसी फ़ाइल से लिया गया है जिसमें कॉपीराइट नोटिस मौजूद है, तो आपको ओरिजनल फ़ाइल से उस कॉपीराइट नोटिस को बरकरार रखना होगा.
पूरी तरह से नई सोर्स फ़ाइल जोड़ने पर, डिफ़ॉल्ट एओएसपी कॉपीराइट और यहां दिए गए लाइसेंस हेडर का इस्तेमाल करें. ऐसा तब तक करें, जब तक कि जिस प्रोजेक्ट में योगदान दिया जा रहा है उसके लिए पहले से तय किया गया कोई अलग लाइसेंस न हो:
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.