मेरे insulin pump को नियंत्रित करने वाला डिवाइस Linux kernel का उपयोग करता है, लेकिन GPL का उल्लंघन करता है

• insulin pump को नियंत्रित करने वाला medical device controller Linux kernel पर आधारित होकर काम करता है
• संबंधित डिवाइस GPL (General Public License) की शर्तों का पालन नहीं कर रहा, इसलिए यह license violation की स्थिति में है
• उपयोगकर्ताओं ने इस बात पर आपत्ति जताई कि source code सार्वजनिक करने की बाध्यता पूरी नहीं की जा रही है
• कम्युनिटी में open source software की transparency और medical device reliability पर साथ-साथ चर्चा हो रही है
• यह GPL violation medical device क्षेत्र में open source के उपयोग की सीमाओं को दिखाने वाले एक उदाहरण के रूप में ध्यान खींच रहा है

---

Linux kernel आधारित insulin pump controller

• insulin pump को नियंत्रित करने वाला डिवाइस Linux kernel का उपयोग कर रहा है
  • यह डिवाइस insulin delivery को अपने-आप समायोजित करने का काम करता है
  • उपयोगकर्ताओं ने पुष्टि की है कि इसमें Linux kernel embedded है
• यह डिवाइस GPL license की शर्तों का उल्लंघन कर रहा है
  • GPL के अनुसार kernel का उपयोग करने वाले products पर source code सार्वजनिक करने की बाध्यता होती है
  • लेकिन यह डिवाइस source code की पहुंच दिए बिना बेचा जा रहा है

GPL violation और open source transparency

• उपयोगकर्ताओं ने GPL violation की ओर इशारा करते हुए source code जारी करने की मांग उठाई
  • kernel का उपयोग स्पष्ट होने के बावजूद निर्माता code उपलब्ध नहीं करा रहा है
• कम्युनिटी ने medical device manufacturers द्वारा open source obligations की अनदेखी की आलोचना की
  • GPL violation केवल कानूनी मुद्दा नहीं है, यह user safety और reliability को भी प्रभावित करता है

Medical devices और open source का टकराव

• medical device industry में closed firmware policies आम हैं
  • इसके कारण open source community के साथ कानूनी और नैतिक टकराव पैदा होते हैं
• Linux kernel का उपयोग करने वाले medical devices में GPL violation को transparency की कमी के एक प्रमुख उदाहरण के रूप में देखा जा रहा है
  • जब open source आधारित तकनीक medical devices में लागू की जाती है, तब disclosure obligations का पालन महत्वपूर्ण होता है

Community प्रतिक्रिया

• कुछ उपयोगकर्ताओं ने GPL compliance को लागू कराने के कदम उठाने की मांग की
  • उनका कहना है कि निर्माता को kernel source सार्वजनिक करना चाहिए
• अन्य उपयोगकर्ताओं ने medical device safety और कानूनी जिम्मेदारी के मुद्दों पर भी चर्चा की
  • medical devices में open source software के उपयोग के समय मौजूद regulatory gap की ओर ध्यान दिलाया गया

निहितार्थ

• यह मामला वास्तविक medical device में GPL violation के एक दुर्लभ उदाहरण के रूप में देखा जा रहा है
• यह open source community और medical device industry के बीच कानूनी और नैतिक संतुलन की आवश्यकता को दिखाता है
• आगे चलकर Linux kernel का उपयोग करने वाले products में license compliance को मजबूत करने की मांग बढ़ सकती है

[GN⁺]

Hacker News की राय

• मैंने Insulet से GPLv2 के तहत लाइसेंस किए गए kernel source code की मांग करने की कोशिश की थी
  लेकिन सिर्फ यह कहना कि “GPL है, इसलिए source देना ही होगा” एक गलतफहमी है
  असल में कंपनी को उपयोगकर्ता को ‘written offer’ भेजना होता है, और उपयोगकर्ता उसी ऑफ़र के आधार पर source code मांग सकता है
  अगर कंपनी ने ऑफ़र भेजा लेकिन उसे पूरा नहीं किया, तो वह contract breach हो सकता है, लेकिन अगर शुरुआत में ऑफ़र भेजा ही नहीं गया, तो वह GPL violation होगा (मैं कानूनी विशेषज्ञ नहीं हूँ)
  • यह अभी भी कानूनी रूप से पूरी तरह स्पष्ट न हुआ मुद्दा है
    Conservancy v Vizio मामले में इस बात पर विवाद है कि क्या उपभोक्ता GPL को सीधे enforce करने का अधिकार रखते हैं
  • written offer की 3 साल की वैधता कई distribution तरीकों में से सिर्फ एक है
    अगर ऑफ़र था ही नहीं, तो उस clause की protection नहीं मिलेगी और GPL compliance किसी दूसरे तरीके से करना होगा
  • “क्या written offer का मामला contract breach है?” इस सवाल पर कुछ लोगों की राय है कि सिर्फ एक offer, contract से अलग चीज़ है
  • अमेरिका में ऐसी व्याख्या संभव हो सकती है, लेकिन जर्मनी में end user भी सीधे source code मांगकर मुकदमा कर सकता है
  • GPL खुद एक contract है, इसलिए यहाँ फर्क licensor–licensee contract और licensee–user relationship के बीच करना होगा
• मैं ज़रूर सलाह दूँगा कि कंपनी के अंदरूनी व्यक्ति द्वारा लिखा गया top comment पढ़ें
  hardware development को अक्सर cost center मानकर outsource कर दिया जाता है, इसलिए कई बार GPL request संभालने वाला कोई बचता ही नहीं
  frontline support team के पास ऐसे अनुरोध संभालने की क्षमता नहीं होती, और ईमेल अंदर घूमते-घूमते भूल जाना आम बात है
  जब मामला legal team तक पहुँचता है, तो वे हिसाब लगाते हैं कि “क्या इसमें सच में कोई legal risk है?” और ज़्यादातर मामलों में उसे नज़रअंदाज़ कर देते हैं
  पहले जब मैं एक ऐसी कंपनी में काम करता था जहाँ GPL से जुड़े issues बहुत आते थे, तो मैंने हर release के लिए GPL tarball सुरक्षित रखने और support team को training देने की व्यवस्था की थी
  requests का 70% हिस्सा इस गलतफहमी से उपजे गुस्से का था कि “पूरा source क्यों नहीं दिया जा रहा”
  इसी अनुभव से मुझे समझ आया कि support team GPL requests से कतराती क्यों है
  • लेकिन अगर non-GPL code, GPL code के साथ सीधे link किया गया था, तो उन उपयोगकर्ताओं की शिकायतें जायज़ भी हो सकती थीं
• ऐसे मामलों में legal team के ज़रिए वकील के रास्ते संपर्क करना सही तरीका है
  engineer या support team कंपनी की assets सौंपने का कानूनी फैसला नहीं लेंगे
  अगर FSF कानूनी आधार और damages claim प्रक्रिया के साथ एक demand letter template सार्वजनिक करे, तो वह बहुत मददगार होगा
  • इस पर यह जवाब भी आता है कि “वह कंपनी की asset नहीं है”
• अगर GPL लागू होने वाला हिस्सा सिर्फ Linux kernel ही है, तो शायद किसी खास source code को पाने का अधिकार बहुत सीमित होगा
  सिर्फ kernel इस्तेमाल करने से userspace programs पर GPL obligations नहीं लगते
  संभव है कि यह बिना customization वाले kernel और open source userspace programs का संयोजन हो
  • तब source code उपलब्ध कराना बहुत आसान काम होना चाहिए
  • और GPL shim इस्तेमाल करने वाले driver modules (जैसे: NVIDIA driver) GPL के दायरे में नहीं आते, इसलिए लेखक इसे violation क्यों मान रहा है, यह मुझे समझ नहीं आता
• ऐसी license violation बहसें सच में बहुत तनाव देती हैं
  अगर violation है, तो बस मुकदमा दायर कीजिए और अदालत को फैसला करने दीजिए
  medical device हो, तो कुछ सौ डॉलर के खर्च पर भी इसे आज़माना उचित लग सकता है
  • लेकिन संभव है कि OP Linux kernel का copyright holder न हो
  • और वैसे भी मुकदमा कुछ सौ डॉलर में खत्म होने वाला नहीं है
• अगर kernel सीधे build किया गया था, तो सिर्फ official Linux kernel repository link बता देना भी काफी हो सकता है
  • लेकिन अगर कंपनी ने commercial purpose के लिए खुद build किया है, तो वह GPLv2 3(c) की दोनों शर्तें पूरी नहीं करती, इसलिए वह clause लागू नहीं होगा
• क्या यह Omnipod की बात नहीं है?
  recall भी बहुत हुए हैं, और उनके hardware·software quality पर भरोसा करना मुश्किल है
  उस कंपनी में काम कर चुके लोगों से माफ़ी, लेकिन उम्मीद है कि वे अब किसी बेहतर जगह काम कर रहे होंगे
• मैं insulin-dependent नहीं हूँ, लेकिन मेरी जिज्ञासा यह है कि insulin pump को मोबाइल फोन से control करने की ज़रूरत ही क्यों है
  Bluetooth controller से भी काम चल सकता है, फिर खास तौर पर सस्ता चीनी फोन इस्तेमाल करना data leak का जोखिम बढ़ाता हुआ लगता है
  • वजह security है। PDM पूरी तरह isolated है, और उस पर app install करना या Wi‑Fi से जुड़ना संभव नहीं है
    अगर control गलत हो जाए, तो घातक insulin overdose हो सकता है
    दिलचस्प बात यह है कि उसी कंपनी का Omnipod 5 अमेरिका में सामान्य smartphone से control किया जा सकता है
  • पहले pump को external device से control करने के लिए अनिवार्य रूप से dedicated controller देना पड़ता था
    इसलिए Insulet ने अलग device जारी किया
    Dexcom G7 जैसे CGM भी इसी वजह से ‘controller’ के साथ बेचे जाते हैं
    हाल के वर्षों में FDA ने यह requirement ढीली की है, इसलिए अब ऐसे products भी अनुमति पा रहे हैं जो उपयोगकर्ता के अपने phone को आधार मानते हैं
• असल में इस device का पहले से reverse engineering (RE) हो चुका है
  Loop, Trio, OpenAPS जैसे projects देखें तो पता चलता है
  Insulet ऐसे hacks को लेकर काफ़ी उदार रहा है
  अभी ज़रूरत Omnipod 5 के RE में मदद की है
  • मैं भी Omnipod 5 RE पर काम जानने वाले कुछ लोगों के संपर्क में हूँ
    अभी समस्या यह है कि PDM/app login के समय API से private key लेकर keychain में store करता है, और SSL pinning के कारण man-in-the-middle attack रुक जाता है
    अभी तक private key निकाली नहीं जा सकी है, इसलिए प्रगति धीमी है
  • मैं Minimed pump (780G) के blood glucose data पढ़ने के RE की कोशिश कर रहा हूँ, लेकिन अभी यह पूरी तरह हल नहीं हुआ है
    उम्मीद है कि कभी इसमें योगदान दे सकूँगा
• मैं सोच रहा था कि क्या ऐसे मामलों में FSF को petition करने की कोई प्रक्रिया है
  मैं जानना चाहता था कि वे किस आधार पर मामले चुनते हैं
  • व्यवहार में यह FSF नहीं बल्कि SFC(Software Freedom Conservancy) देखता है
    प्रमुख सिद्धांत यह है कि GPL को सिर्फ copyright holder ही enforce कर सकता है
    SFC, Vizio मुकदमे के ज़रिए यह स्थापित करना चाहता है कि end user भी GPL enforce करने वाले third-party beneficiary माने जाएँ
    FSF केवल उन मामलों में हस्तक्षेप कर सकता है जहाँ GNU project की तरह copyright assignment मिला हो
    GNU से जुड़े violations की रिपोर्ट [e-mail] पर की जा सकती है
    SFC, OpenWrt, Git, QEMU जैसे कई projects का legal representative भी है
    रिपोर्ट करने के लिए SFC के मार्गदर्शन पेज को देखें
    हालांकि SFC के resources सीमित हैं, इसलिए वह medical device जैसे बड़े सामाजिक प्रभाव वाले मामलों को प्राथमिकता देता है
    खास तौर पर Karen Sandler (दिल के defibrillator की उपयोगकर्ता) और Bradley Kühn (blood glucose monitor उपयोगकर्ता) जैसे लोग वहाँ हैं, इसलिए medical device मुद्दों में उनकी दिलचस्पी अधिक है