Detecting and Fixing Violations of Modification Terms in Open Source Licenses during Forking

तकनीकी सारांश: फोर्किंग के दौरान ओपन सोर्स लाइसेंसों में संशोधन शर्तों (Modification Terms) के उल्लंघन का पता लगाना और उन्हें ठीक करना

समस्या विवरण
ओपन सोर्स सॉफ्टवेयर (OSS) विकास फोर्किंग पर बहुत अधिक निर्भर करता है, जहाँ डेवलपर्स एक नया, स्वतंत्र रूप से संशोधित संस्करण बनाने के लिए एक मूल रिपॉजिटरी की प्रतिलिपि बनाते हैं। जबकि यह नवाचार को बढ़ावा देता है, यह तब महत्वपूर्ण कानूनी जोखिम पैदा करता है जब डेवलपर्स लाइसेंस संबंधी दायित्वों का पालन करने में विफल रहते हैं। मौजूदा शोध लाइसेंसों की पहचान करने, डिपेंडेंसीज़ के बीच असंगतता का पता लगाने और फ़ाइल लाइसेंसिंग में विसंगतियों को खोजने पर केंद्रित रहा है। हालाँकि, संशोधन शर्तों (Modification Terms - MTs) के संबंध में एक महत्वपूर्ण अंतर बना हुआ है। MTs ओपन सोर्स लाइसेंसों में विशिष्ट क्लॉज (clauses) हैं जो यह निर्धारित करते हैं कि उपयोगकर्ता मूल कार्य को कैसे संशोधित कर सकते हैं और संशोधन करने पर उन्हें किन दायित्वों को पूरा करना होगा। एक प्रमुख उदाहरण Apache-2.0 जैसे लाइसेंसों में "प्रॉमिनेंट नोटिस" (prominent notices) शामिल करने की आवश्यकता है, जो यह बताता है कि फ़ाइलों को बदला गया है। लेखकों की जानकारी के अनुसार, किसी भी पूर्व कार्य ने व्यवस्थित रूप से इन शर्तों को चित्रित नहीं किया है या फोर्किंग प्रक्रिया के दौरान MTs के उल्लंघन का पता लगाने और उन्हें ठीक करने के लिए स्वचालित तंत्र प्रदान नहीं किया है।

कार्यप्रणाली
लेखक एक दो-चरणीय दृष्टिकोण प्रस्तावित करते हैं: MTs को चित्रित करने के लिए एक अनुभवजन्य अध्ययन (empirical study), और उसके बाद LiVo नामक एक स्वचालित उपकरण का विकास।

1. संशोधन शर्तों का अनुभवजन्य लक्षण वर्णन (Empirical Characterization)
लेखकों ने ओपन सोर्स इनिशिएटिव (OSI) द्वारा अनुमोदित 107 लाइसेंसों पर एक अनुभवजन्य अध्ययन किया। उन्होंने 47 ऐसे लाइसेंसों की पहचान की जो स्पष्ट रूप से संशोधनों का वर्णन करने के लिए विशिष्ट प्रकार के "नोटिस" की आवश्यकता वाले MTs घोषित करते हैं। इन दायित्वों को मॉडल करने के लिए, लेखकों ने तीन आयामों में लाइसेंसों का विश्लेषण किया:

• संशोधन का दायरा ($S_g$): उन फ़ाइलों के प्रकार जिन पर संशोधन दायित्व लागू होते हैं (जैसे, सोर्स कोड, दस्तावेज़ीकरण, कॉन्फ़िगरेशन फ़ाइलें, स्क्रिप्ट)। उन्होंने इन्हें आठ समूहों में वर्गीकृत किया, यह नोट करते हुए कि लगभग आधे लाइसेंस (44.7%) किसी भी फ़ाइल प्रकार पर लागू होते हैं।
• नोटिस की सामग्री ($C_g$): नोटिस में आवश्यक जानकारी। इसे चार तत्वों में वर्गीकृत किया गया: तिथि (Date), लेखक (Author), संक्षिप्त विवरण (यह बताना कि फ़ाइलें बदली गई हैं), और सूचनात्मक विवरण (यह विस्तार से बताना कि कैसे/क्यों)। लाइसेंसों को इन आवश्यकताओं के आधार पर छह श्रेणियों में समूहबद्ध किया गया।
• नोटिस का स्थान ($L_g$): वह स्थान जहाँ नोटिस रखा जाना चाहिए। इसे दो तत्वों में वर्गीकृत किया गया: एक अलग दस्तावेज़ (जैसे, CHANGELOG) या प्रत्येक संशोधित फ़ाइल। लाइसेंसों को चार श्रेणियों में समूहबद्ध किया गया।

इन आयामों के आधार पर, 47 लाइसेंसों को 2-टुपल्स $\langle lic, O \rangle$ के रूप में मॉडल किया गया, जहाँ $O$ एक 3-टुपल $\langle S_g, C_g, L_g \rangle$ है जो विशिष्ट दायित्व का प्रतिनिधित्व करता है।

2. LiVo दृष्टिकोण
LiVo एक स्वचालित उपकरण है जिसे फोर्किंग के दौरान MT उल्लंघन का पता लगाने और उन्हें ठीक करने के लिए डिज़ाइन किया गया है। यह एक बेस रिपॉजिटरी और एक फोर्क रिपॉजिटरी को इनपुट के रूप में लेता है और तीन चरणों में कार्य करता है:

• चरण 1: बाध्यकारी संशोधन का पता लगाना (Obligating Modification Detection)

  • फ़ाइल मैपिंग: LiVo पुन: उपयोग की पहचान करने के लिए बेस और फोर्क रिपॉजिटरी के बीच फ़ाइलों के बीच मैपिंग स्थापित करता है। यह उन परिदृश्यों को संभालता है जहाँ फ़ाइलों का नाम बदला गया हो, उन्हें स्थानांतरित किया गया हो, या कॉपी किया गया हो (JGit और Saga जैसे टूल का उपयोग करके)।
  • लाइसेंस डिटेक्शन: यह प्रत्येक फ़ाइल के लाइसेंस का पता लगाने के लिए Ninka का उपयोग करता है।
  • बाध्यकारी फ़ाइलें और कमिट्स: यह फोर्क रिपॉजिटरी में "बाध्यकारी फ़ाइलों" (वे फ़ाइलें जो पता लगाए गए लाइसेंस के संशोधन दायरे के भीतर आती हैं) और उन "बाध्यकारी कमिट्स" की पहचान करता है जो इन फ़ाइलों को संशोधित करते हैं। यह उन कमिट्स को फ़िल्टर करता है जो बेस रिपॉजिटरी से लिए गए हैं (जो पहले से ही अनुपालन में हैं) और रिवर्ट किए गए कमिट्स को हटा देता है।

• चरण 2: नोटिस निष्कर्षण (Notice Extraction)

  • LiVo फोर्क रिपॉजिटरी में संभावित नोटिस फ़ाइलों (जैसे, CHANGELOG, RELEASE.txt) का पता लगाता है।
  • यह इन फ़ाइलों से "चेंज लॉग्स" निकालता है। निष्कर्षण तर्क अर्ध-संरचित टेक्स्ट (semi-structured text) को संभालता है, जो विशिष्ट तिथि श्रेणियों और लेखकों से जुड़े परिवर्तनों के ब्लॉक्स की पहचान करता है।
  • प्रत्येक निकाले गए चेंज लॉग को टुपल $\langle msg, d_s, d_e, a \rangle$ (संदेश, प्रारंभ तिथि, समाप्ति तिथि, लेखक) के रूप में मॉडल किया जाता है।

• चरण 3: उल्लंघन का पता लगाना और सुधारना (Violation Detection and Fixing)

  • मिलान (Matching): प्रत्येक बाध्यकारी कमिट के लिए, LiVo निकाले गए सेट में एक चेंज लॉग के साथ मिलान करने का प्रयास करता है।
  • समानता जाँच (Similarity Check): यह कमिट संदेश और चेंज लॉग संदेश के बीच सिमेंटिक समानता मापने के लिए TF-IDF का उपयोग करता है। यदि समानता एक थ्रेशोल्ड (अनुभवजन्य रूप से 0.3 निर्धारित) से अधिक है, तो सामग्री की आवश्यकता को पूरा माना जाता है।
  • विशेषता सत्यापन (Attribute Verification): यह सत्यापित करता है कि क्या कमिट की तिथि चेंज लॉग की तिथि सीमा के भीतर आती है और क्या कमिट का लेखक चेंज लॉग के लेखक से मेल खाता है।
  • वर्गीकरण (Classification): कमिट को वर्गीकृत किया जाता है:
    • OB (पूर्णतः बाध्यकारी - Fully Obligated): सभी आवश्यकताएं पूरी।
    • VN (उल्लंघन - नोटिस गायब है - Violated - Missing Notice): कोई मिलान करने वाला चेंज लॉग नहीं मिला।
    • VD (उल्लंघन - तिथि गायब है - Violated - Missing Date): तिथि सीमा बेमेल।
    • VA (उल्लंघन - लेखक गायब है - Violated - Missing Author): लेखक बेमेल।
  • सुधारना (Fixing): उल्लंघनों के लिए, LiVo सही संदेश, तिथि और लेखक के साथ एक नया चेंज लॉग प्रविष्टि बनाकर या अपडेट करके एक सुधार उत्पन्न करता है, और इसे उपयुक्त नोटिस फ़ाइल में लिखता है।

मुख्य परिणाम
लेखकों ने 178 बेस और फोर्क रिपॉजिटरी जोड़ों (जो अत्यधिक स्टार प्राप्त किए गए GitHub प्रोजेक्ट्स से चुने गए थे) का उपयोग करके LiVo का मूल्यांकन किया।

• व्यापकता (Prevalence): विश्लेषण किए गए फोर्क्ड रिपॉजिटरीज़ में से 21.9% में MTs की आवश्यकता थी।
• उल्लंघन की गंभीरता (Violation Severity): विश्लेषण किए गए 51.1% फोर्क्ड रिपॉजिटरीज़ ने MTs का उल्लंघन किया। अधिक महत्वपूर्ण बात यह है कि 95.3% बाध्यकारी कमिट्स (वे कमिट जो संरक्षित फ़ाइलों को संशोधित करते हैं) में MTs का उल्लंघन पाया गया। सबसे आम उल्लंघन 'नोटिस गायब होना' (VN) था, जिसके बाद 'तिथि गायब होना' (VD) आया।
• सटीकता (Accuracy): LiVo ने उल्लंघनों का पता लगाने और उन्हें वर्गीकृत करने में 0.82 का मैक्रो-प्रिसिजन (macro-precision) और 0.80 का मैक्रो-रिकॉल (macro-recall) प्राप्त किया। त्रुटि का प्राथमिक स्रोत कमिट संदेशों को चेंज लॉग से मिलाने के दौरान TF-IDF की सिमेंटिक अनभिज्ञता (semantic unawareness) थी।
• दक्षता (Efficiency): टूल ने प्रति रिपॉजिटरी जोड़ा औसतन 229.8 सेकंड का समय लिया, जिसमें संशोधन का पता लगाने वाला चरण ~92% रनटाइम के लिए जिम्मेदार था।
• वास्तविक दुनिया का प्रभाव (Real-world Impact): लेखकों ने उल्लंघन वाली रिपॉजिटियों में 91 पुल रिक्वेस्ट (pull requests) सबमिट कीं। 18 को सकारात्मक प्रतिक्रिया मिली, और 8 को मुख्य शाखाओं में मर्ज किया गया। कुछ डेवलपरों ने शुरू में विरोध किया, यह तर्क देते हुए कि कमिट हिस्ट्री ही नोटिस के रूप में कार्य करती है या वे मूल लेखक होने का दावा करते हैं, लेकिन टूल ने सफलतापूर्वक अधिकांश मामलों में सुधारों की पहचान की और प्रस्तावित किए।

महत्व और दावे
पेपर का दावा है कि यह पहला कार्य है जो:

1. ओपन सोर्स लाइसेंसों के एक बड़े सेट में संशोधन शर्तों (MTs) को अनुभवजन्य रूप से चित्रित करता है।
2. फोर्किंग के दौरान इन विशिष्ट शर्तों के उल्लंघन का पता लगाने और उन्हें ठीक करने के लिए एक स्वचालित दृष्टिकोण (LiVo) प्रस्तावित करता है।

लेखक इस बात पर जोर देते हैं कि जबकि लाइसेंस पहचान और असंगतता का पता लगाना परिपक्व क्षेत्र हैं, संशोधन के लिए "नोटिस" प्रदान करने का विशिष्ट दायित्व अनदेखा रहा है। इन विषयों को संबोधित करके, LiVo गैर-अनुपालन से जुड़े कानूनी जोखिमों जैसे कि मुकदमों और वित्तीय नुकसान को कम करने में मदद करता है। पेपर निष्कर्ष निकालता है कि वास्तविक दुनिया के परिदृश्यों में MT उल्लंघन गंभीर हैं, और स्वचालित पहचान तथा सुधार संभव और प्रभावी हैं, हालांकि फॉल्स पॉजिटिव और फॉल्स नेगेटिव को और कम करने के लिए सिमेंटिक मैचिंग (जैसे, डीप लर्निंग) में सुधार की आवश्यकता है।