اوپن سورس لائسنس کی تعمیل: سافٹ ویئر کمپنیوں کے لیے ایک عملی گائیڈ

اوسط کمرشل ایپلیکیشن میں 77% اوپن سورس کوڈ ہوتا ہے، جو کہ 500+ انحصار پر پھیلا ہوا ہے۔ ہر انحصار مخصوص ذمہ داریوں کے ساتھ اپنا لائسنس رکھتا ہے۔ ان ذمہ داریوں کی خلاف ورزی آپ کی کمپنی کو قانونی چارہ جوئی، جبری کوڈ افشاء، اور شہرت کو نقصان پہنچاتی ہے۔ اس کے باوجود زیادہ تر کمپنیوں کے پاس اوپن سورس لائسنسوں سے باخبر رہنے یا ان کی تعمیل کرنے کا کوئی عمل نہیں ہے۔

یہ گائیڈ اوپن سورس لائسنس کی تعمیل کے لیے ایک عملی فریم ورک فراہم کرتا ہے، لائسنس کی درجہ بندی سے لے کر خودکار اسکیننگ اور SBOM جنریشن تک۔

اہم ٹیک ویز

• تمام اوپن سورس لائسنس ایک جیسے نہیں ہیں: اجازت دینے والے لائسنس تقریباً کسی بھی چیز کی اجازت دیتے ہیں، کاپی لیفٹ لائسنس آپ سے ترمیمات کا اشتراک کرنے کا تقاضا کرتے ہیں۔
• ایک سافٹ ویئر بل آف میٹریلز (SBOM) حکومت کی خریداری میں قانونی ضرورت بنتا جا رہا ہے (US Executive Order 14028)
• CI/CD میں خودکار لائسنس سکیننگ آپ کے کوڈ بیس میں داخل ہونے سے غیر تعمیل انحصار کو روکتی ہے
• کاپی لیفٹ "انفیکشن" کا خطرہ حقیقی ہے: ایک GPL انحصار آپ کو اپنی پوری درخواست کو اوپن سورس کرنے کا پابند کر سکتا ہے۔

---

لائسنس کے زمرے

اجازت دینے والے لائسنس (کم خطرہ)

تجارتی استعمال کے لیے محفوظ۔ اپنی تقسیم میں لائسنس کا متن اور کاپی رائٹ نوٹس شامل کریں۔ اپاچی 2.0 کو اصل کوڈ میں کسی بھی تبدیلی کو نوٹ کرنے کی ضرورت ہے اور اس میں پیٹنٹ لائسنس بھی شامل ہے۔

کمزور کاپی لیفٹ (درمیانے خطرہ)

احتیاط کے ساتھ استعمال کریں۔ LGPL لائبریریوں کو مشترکہ (متحرک) لائبریریوں کے طور پر رکھیں، مستحکم طور پر منسلک نہیں۔ MPL لائسنس یافتہ کوڈ کو اپنے ملکیتی کوڈ سے الگ فائلوں میں رکھیں۔

مضبوط کاپی لیفٹ (ہائی رسک)

تجارتی سافٹ ویئر کے لیے سب سے زیادہ خطرہ۔ اپنی درخواست میں GPL کوڈ استعمال کرنے سے آپ کو اپنی پوری درخواست کو GPL کے تحت جاری کرنے کی ضرورت پڑ سکتی ہے۔ AGPL اسے سرور سائیڈ سافٹ ویئر تک بڑھاتا ہے --- یہاں تک کہ اگر آپ کبھی بائنریز تقسیم نہیں کرتے ہیں، سافٹ ویئر کو بطور ویب سروس فراہم کرنا کاپی لیفٹ ذمہ داری کو متحرک کرتا ہے۔

---

تعمیل ورک فلو

مرحلہ 1: ایک SBOM بنائیں

# For Node.js projects (using CycloneDX)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json --spec-version 1.5

# For Python projects
pip install cyclonedx-bom
cyclonedx-py environment --output sbom.json

# For multi-language projects (using Syft)
syft . -o cyclonedx-json > sbom.json

مرحلہ 2: لائسنس کی تعمیل کے لیے اسکین کریں۔

# Using license-checker for Node.js
npx license-checker --production --json --out licenses.json

# Using scancode-toolkit (comprehensive, all languages)
scancode --license --copyright --output-json scan-results.json .

مرحلہ 3: درجہ بندی کریں اور منظور کریں۔

منظور شدہ لائسنس کی فہرست بنائیں:

{
  "approved": [
    "MIT", "BSD-2-Clause", "BSD-3-Clause", "Apache-2.0",
    "ISC", "0BSD", "Unlicense", "CC0-1.0"
  ],
  "conditional": [
    "LGPL-2.1", "LGPL-3.0", "MPL-2.0", "EPL-2.0"
  ],
  "prohibited": [
    "GPL-2.0", "GPL-3.0", "AGPL-3.0", "SSPL-1.0",
    "EUPL-1.2", "OSL-3.0"
  ]
}

مرحلہ 4: CI/CD انٹیگریشن

# .github/workflows/license-check.yml
name: License Compliance
on: [pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: pnpm install --frozen-lockfile

      - name: Check licenses
        run: |
          npx license-checker --production --excludePackages "" \
            --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0" \
            --summary

---

SBOM (سافٹ ویئر بل آف میٹریلز)

SBOMs کیوں اہم ہیں۔

• US Executive Order 14028 امریکی حکومت کو فروخت کیے گئے سافٹ ویئر کے لیے SBOMs کی ضرورت ہے
• EU Cyber Resilience Act EU میں فروخت ہونے والے سافٹ ویئر کے لیے SBOMs کی ضرورت ہوگی۔
• سپلائی چین سیکیورٹی: SBOMs تیزی سے خطرے کے ردعمل کو قابل بناتے ہیں (جب log4j ہوتا ہے، آپ کو معلوم ہوتا ہے کہ آیا آپ متاثر ہوئے ہیں)
• کسٹمر کا اعتماد: انٹرپرائز کے خریدار خریداری کے دوران تیزی سے SBOMs کی درخواست کرتے ہیں۔

SBOM معیارات

تجویز: زیادہ تر سافٹ ویئر کمپنیوں کے لیے CycloneDX۔ یہ آسان ہے، بہتر ٹولنگ سپورٹ ہے، اور انڈسٹری ڈیفالٹ بن رہی ہے۔

---

عام تعمیل کے منظرنامے۔

منظر نامہ 1: Node.js ویب ایپلیکیشن

عام node_modules ڈائریکٹری میں 500-2,000 پیکجز ہوتے ہیں۔ اکثریت MIT یا ISC لائسنس استعمال کرتی ہے۔ عام مسائل:

• GPL کا استعمال کرتے ہوئے عبوری انحصار (آپ نے انہیں براہ راست شامل نہیں کیا)
• UNKNOWN لائسنس کے فیلڈز جن میں دستی تفتیش کی ضرورت ہوتی ہے۔
• ایک پیکج پر ایک سے زیادہ لائسنس (مثال کے طور پر، "MIT یا Apache-2.0")

کارروائی: npx license-checker --production ہفتہ وار چلائیں۔ کسی بھی غیر اجازت یافتہ لائسنس کی چھان بین کریں۔ اجازت دینے والے متبادل کے ساتھ GPL انحصار کو تبدیل کریں۔

منظر نامہ 2: اوڈو ماڈیول کی ترقی

Odoo کمیونٹی ایڈیشن LGPL v3 ہے۔ اوڈو انٹرپرائز ملکیتی ہے۔ آپ کے حسب ضرورت ماڈیولز:

• کمیونٹی ماڈیول: LGPL v3 یا ہم آہنگ ہونا چاہیے (اگر تقسیم کیا گیا ہو)
• نجی اندرونی ماڈیول: تقسیم نہیں کیا گیا، لہذا LGPL لاگو نہیں ہوتا ہے۔
• انٹرپرائز ایڈ آنس: Odoo انٹرپرائز لائسنسنگ شرائط کی تعمیل کرنا ضروری ہے

منظر نامہ 3: AGPL انحصار کے ساتھ SaaS

اگر آپ کی SaaS ایپلیکیشن AGPL لائسنس یافتہ کوڈ استعمال کرتی ہے (مثال کے طور پر، MongoDB اس سے پہلے کہ وہ SSPL میں جائیں)، آپ کو یا تو:

1. اپنا پورا ایپلیکیشن سورس کوڈ AGPL کے تحت جاری کریں۔
2. AGPL انحصار کو ہٹا دیں اور متبادل استعمال کریں۔
3. AGPL پروجیکٹ سے تجارتی لائسنس حاصل کریں (اگر دستیاب ہو)

AGPL کوڈ کا سرور سائیڈ استعمال کاپی لیفٹ ذمہ داری کو متحرک کرتا ہے حالانکہ آپ کبھی بھی بائنریز کو "تقسیم" نہیں کرتے ہیں۔

---

اکثر پوچھے گئے سوالات

کیا ہمارے API میں GPL لائبریری کا استعمال ہمیں اپنے API کو اوپن سورس کرنے پر مجبور کرتا ہے؟

یہ اس بات پر منحصر ہے کہ آپ اسے کیسے استعمال کرتے ہیں۔ اگر GPL لائبریری آپ کی درخواست سے منسلک ہے (متحرک طور پر یا متحرک طور پر)، FSF کی پوزیشن یہ ہے کہ آپ کی درخواست ایک "ماخوذ کام" ہے اور اسے GPL کے تحت لائسنس یافتہ ہونا چاہیے۔ اگر آپ نیٹ ورک API کے ذریعے GPL سافٹ ویئر کے ساتھ بات چیت کرتے ہیں (مثال کے طور پر، GPL لائسنس یافتہ ڈیٹا بیس سرور کا استعمال کرتے ہوئے)، تو اسے عام طور پر مشتق کام نہیں سمجھا جاتا ہے۔ اپنے مخصوص کیس کے لیے وکیل سے مشورہ کریں۔

کیا ہوگا اگر کوئی انحصار اپنا لائسنس بدلتا ہے؟

آپ اس لائسنس کے پابند ہیں جس کے تحت آپ نے کوڈ حاصل کیا ہے، نہ کہ مستقبل میں لائسنس کی تبدیلیاں۔ تاہم، اگر آپ نئے لائسنس کے ساتھ نئے ورژن میں اپ ڈیٹ کرتے ہیں، تو نیا لائسنس اس ورژن پر لاگو ہوتا ہے۔ یہی وجہ ہے کہ ورژن پننگ کے ساتھ SBOMs اہم ہیں --- وہ بالکل دستاویز کرتے ہیں کہ آپ کون سا ورژن (اور لائسنس) استعمال کر رہے ہیں۔

ہم "UNKNOWN" لائسنس کے ساتھ انحصار کو کیسے ہینڈل کرتے ہیں؟

لائسنس فائل کے لیے پیکیج کا ذخیرہ چیک کریں۔ اگر کوئی لائسنس متعین نہیں کیا گیا ہے، تو کوڈ تکنیکی طور پر کاپی رائٹ کے مکمل تحفظ کے تحت ہے --- آپ کو اسے استعمال کرنے، اس میں ترمیم کرنے یا تقسیم کرنے کا کوئی حق نہیں ہے۔ یا تو لائسنس تلاش کریں (یہ ایک غیر معیاری جگہ پر ہو سکتا ہے)، مصنف سے ایک شامل کرنے کی درخواست کریں، یا انحصار کو واضح طور پر لائسنس یافتہ متبادل سے تبدیل کریں۔

کیا ہمیں MIT کے لائسنس یافتہ پیکجوں کے لیے انتساب فراہم کرنے کی ضرورت ہے؟

جی ہاں MIT اور سب سے زیادہ اجازت دینے والے لائسنس کے لیے آپ کو سافٹ ویئر تقسیم کرتے وقت کاپی رائٹ نوٹس اور لائسنس کا متن شامل کرنے کی ضرورت ہوتی ہے۔ ویب ایپلیکیشنز کے لیے، اس کا عام طور پر مطلب ہوتا ہے ایک تھرڈ پارٹی نوٹس فائل یا ایک صفحہ جس میں تمام اوپن سورس اجزاء اور ان کے لائسنس شامل ہوتے ہیں۔

---

تعمیل پروگرام بنانا

سہ ماہی تعمیل کا جائزہ

1. تمام منصوبوں کے لیے SBOM کو دوبارہ بنائیں
2. نئی انحصار کے لیے اسکین آخری جائزے کے بعد شامل کیا گیا۔
3. اپ ڈیٹ شدہ پیکجز میں **لائسنس کی تبدیلیوں کو چیک کریں۔
4. کسی بھی "نامعلوم" لائسنسوں کا جائزہ لیں جو ظاہر ہوئے ہیں۔
5. منظور شدہ لائسنس کی فہرست کو اپ ڈیٹ کریں اگر نئے لائسنسوں کا سامنا ہو۔
6. آڈٹ ٹریل کے لیے **SBOM سنیپ شاٹس کو آرکائیو کریں۔

تعمیل کے کردار

ایک ہلکا پھلکا کمپلائنس پروگرام ایک چھوٹی ٹیم کے لیے 2-4 گھنٹے فی سہ ماہی لیتا ہے اور پروڈکٹ کے آغاز کے بعد یا مناسب محنت کے دوران تعمیل کے مسئلے کو دریافت کرنے کی بہت بڑی لاگت کو روکتا ہے۔

---

آگے کیا آتا ہے۔

لائسنس کی تعمیل سافٹ ویئر گورننس کا ایک پہلو ہے۔ اسے اپنے کوڈ کے لیے IP تحفظ، وینڈر سافٹ ویئر کے لیے SaaS معاہدے کی ضروریات اور سیکیورٹی کی تعمیل کے لیے سائبرسیکیوریٹی ریگولیٹری تقاضے کے ساتھ جوڑیں۔

اوپن سورس کمپلائنس آڈیٹنگ اور SBOM جنریشن سروسز کے لیے ECOSIRE سے رابطہ کریں۔

---

ECOSIRE کے ذریعہ شائع کیا گیا -- کاروباروں کو اوپن سورس کو ذمہ داری سے استعمال کرنے میں مدد کرنا۔