التدقيق في الامتثال للترخيص من خلال تحليل التبعية

يصل طلب التدقيق اللازم لعمليات الاندماج والاستحواذ صباح يوم الثلاثاء: تقرير شامل عن امتثال تراخيص المصادر المفتوحة لجميع البرامج، يُستحق تقديمه يوم الجمعة. أمام الفريق القانوني ثلاثة أيام لإعداد قائمة بكل مكون من مكونات المصادر المفتوحة في قاعدة بيانات المنتج، وكل ترخيص ينطبق، وكل التزام يجب الوفاء به قبل المراجعة القانونية من قبل الجهة المستحوذة. بالنسبة للمؤسسات التي تتعامل مع الامتثال للتراخيص كعملية مراجعة يدوية دورية، يبدأ صباح الثلاثاء هذا أحد أكثر عمليات التدقيق المكلفة في مجال برامج المؤسسات. أما بالنسبة للمؤسسات التي تمتلك بنية تحتية متطورة لتحليل التبعيات، فيبدأ الأمر بإعداد تقرير.

يتم تجميع البرمجيات في الغالب، وليس كتابتها. وقد وجد تقرير بلاك داك لعام 2026 الصادر عن مكتب مراجعة البرمجيات مفتوحة المصدر (OSSRA) أن 98% من قواعد البيانات البرمجية التجارية تحتوي على مكونات مفتوحة المصدر، وأن 87% منها تحتوي على ثغرة أمنية واحدة على الأقل معروفة، وأن متوسط ​​عدد الثغرات الأمنية لكل قاعدة بيانات برمجية قد تضاعف أكثر من مرتين سنويًا. وتُعد مراجعة الامتثال للترخيص مجالًا يُجيب على سؤال مختلف ولكنه ذو صلة: ليس فقط ما هي المكونات التي تحتوي على ثغرات أمنية، بل ما هي المكونات التي تفرض التزامات قانونية على كيفية توزيع البرمجيات أو تعديلها أو تسويقها. إن عدم تضمين تبعية GPL-2.0 في منتج تجاري احتكاري ليس حادثًا أمنيًا، بل هو انتهاك للترخيص قد يستوجب الكشف عن شفرة المصدر، أو تسوية قانونية، أو سحب المنتج.

يرتكز تدقيق الامتثال للترخيص على تحليل التبعيات، وهو تحديد منهجي لكل مكون برمجي يعتمد عليه البرنامج بشكل مباشر أو غير مباشر، مع تحديد كامل للترخيص الذي يحكم كل مكون. لا يقتصر تحليل التبعيات على مجرد فحص ملف تعريف الحزمة، بل هو فحص هيكلي شامل لما يتضمنه البرنامج فعليًا أثناء عملية البناء والتشغيل، بغض النظر عما إذا كانت هذه المكونات مُعلنة، أو متعدية، أو مُضمنة، أو ضمنية.

لماذا يُعد تحليل التبعية أساسًا؟

يُعدّ الامتثال للترخيص مشكلةً تتعلق بالتبعيات قبل أن تصبح مشكلةً قانونية. لا يُمكن تقييم التزامات ترخيص منتج برمجي دون معرفة مكوناته أولًا، كل عنصر، كل مكتبة، كل جزء منسوخ. يأتي تحليل الترخيص بعد حصر التبعيات. فإذا كان هذا الحصر خاطئًا، سيُبنى تحليل الترخيص على صورة غير مكتملة.

ثلاثة أسئلة يجب أن يجيب عليها تحليل التبعية لضمان الامتثال للترخيص:

ما هي المكونات المضمنة؟ ليس فقط التبعيات المباشرة المعلنة في package.json or pom.xmlلكن كل تبعية متعدية يتم إدخالها، وكل مكتبة مُورَّدة يتم نسخها إلى شجرة المصدر، وكل مكون مرتبط بشكل ثابت يتم تجميعه في الملف التنفيذي، وكل وحدة يتم تحميلها ديناميكيًا ويتم استدعاؤها أثناء التشغيل. يقوم محرك تحليل الثغرات الأمنية الجيد بمقارنة هذه المكونات بقواعد بيانات الثغرات الأمنية مثل NVD، ويتحقق من بيانات تعريف الترخيص، ويُشير إلى الثغرات المعروفة أو المخاطر القانونية قبل أن تؤثر على مسار التسليم. يجب أن يكون المحرك نفسه دقيقًا أيضًا على مستوى المخزون، أي ما هو موجود فعليًا في البرنامج، قبل أن يُمكن الوثوق بتحليل الترخيص.

ما هي التراخيص التي تخضع لها هذه المكونات؟ قد يكون للمكون ترخيص واحد مُعلن، أو ترخيص مزدوج مع خيارات، أو تراخيص متعددة تُطبق على ملفات مختلفة، أو ترخيص تغير عبر الإصدارات. يدّعي محرك كشف التراخيص الخاص بـ FOSSA دقة تصل إلى 99.8%، وهو أمر بالغ الأهمية عندما يحتاج فريقك القانوني إلى التحقق من التزامات المصادر المفتوحة إلى جانب جرد الأمان. يُعد تحديد الترخيص على مستوى المكون ضروريًا ولكنه غير كافٍ، إذ يتطلب الأمر تحديده على مستوى الملف أو المقتطف البرمجي للمكونات التي تحمل ملفاتها المختلفة تراخيص مختلفة.

ما هي الالتزامات التي تفرضها هذه التراخيص؟ يفرض الترخيص المتساهل (مثل MIT وApache-2.0) متطلبات الإسناد. أما ترخيص النسخ المفتوح الضعيف (LGPL) فيفرض التزامات مختلفة بحسب ما إذا كان المكون مرتبطًا ديناميكيًا أم ثابتًا. وقد يتطلب ترخيص النسخ المفتوح القوي (مثل GPL-2.0 وGPL-3.0) توزيع الشفرة المصدرية للعمل المدمج بأكمله. يتطلب فهم الالتزامات فهم شروط الترخيص، وليس فقط مُعرِّف الترخيص.

الأنواع الأربعة من التبعيات التي تُعرّض الترخيص للخطر

لا تكون جميع التبعيات مرئية بنفس القدر أو خاضعة لنفس القدر من التحكم بواسطة الأدوات الحالية. ينشأ التعرض للترخيص من أربعة أنواع متميزة من التبعيات، يتطلب كل منها أساليب اكتشاف مختلفة:

1. تبعيات مدير الحزم (المعلنة والمتعدية)

الطبقة الأكثر وضوحًا: التبعيات المُعلنة في ملفات البيان (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) والتبعيات المتعدية التي تحلها أثناء عملية البناء. تُعد تبعيات مدير الحزم الفئة الأكثر تغطية، حيث تقوم أدوات تحليل التبعيات الهيكلية (SCA) بفحص ملفات البيانات الوصفية وملفات القفل ومخرجات البناء لحصرها.

يكمن الفرق الجوهري بين التبعية المباشرة والتبعية المتعدية. التبعية المباشرة هي التي يختارها المطور، بينما التبعية المتعدية هي ما تتطلبه التبعية المباشرة. على سبيل المثال، المطور الذي يضيف تبعية واحدة react-data-grid قد تستورد حزمةٌ لمشروع Node.js عشرات التبعيات المتعدية، لكل منها ترخيصها الخاص. لم يختر المطور هذه التراخيص، فهي موجودة في شجرة التبعيات على أي حال.

جسون

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

فخ الترخيص المتعدي: لا يكمن خطر الترخيص فيما أعلنته أنت، بل فيما أعلنته تبعياتك، وما أعلنته تبعياتها. قد تخفي شجرة تبعيات مباشرة نظيفة ذات تراخيص متساهلة تبعية متعدية مرخصة بموجب رخصة جنو العمومية (GPL) على عمق ثلاثة مستويات، تفرض التزامات حقوق النسخ على التوزيعة بأكملها.

2. شفرة المصدر الموردة والمنسوخة

يتم نسخ شفرة المصدر من مشاريع خارجية مباشرةً إلى المستودع، وهو نمط شائع في مشاريع C/C++، ومشاريع Go التي لا تحتوي على وحدات، وقواعد البيانات القديمة. لا تظهر الشفرة المُضمّنة في بيانات مدير الحزم لأنها أُضيفت عبر النسخ واللصق بدلاً من استخدام مدير التبعيات.

يتجاوز فحص SCANOSS على مستوى المقتطفات الكشفَ القائم على بيانات البيان، إذ يطابق أجزاء الشفرة المصدرية مع أكثر من 100 مليون ملف مفتوح المصدر في قاعدة بيانات البرمجيات مفتوحة المصدر (OSSKB). يُعدّ فحص المقتطفات ضروريًا لتحديد الشفرة المضمنة والوظائف المنسوخة، وهي أساليب لا تُعلن عن أي تبعية في بيانات البيان، ولكنها تخضع لالتزامات الترخيص الكاملة كما لو كان المكون مُضمّنًا بشكل صريح.

إن دالة مساعدة مضمنة منسوخة من إجابة على Stack Overflow نشأت في كود مرخص بموجب GPL تحمل نفس التزام حقوق النسخ مثل تبعية GPL مباشرة، ولكنها لا تظهر في أي مكان في بيان الحزمة أو ملف القفل أو أي فحص آلي يقرأ التبعيات المعلنة فقط.

3. المكتبات المرتبطة بشكل ثابت

تُجمَّع المكتبات مباشرةً في الملف التنفيذي للتطبيق أثناء عملية البناء. على عكس المكتبات المرتبطة ديناميكيًا التي توجد كملفات منفصلة أثناء التشغيل، فإن المكتبات المرتبطة ثابتًا تكون مضمنة في الملف التنفيذي. وهي غير مرئية في بيانات مدير الحزم، ولكنها تظهر في إعدادات البناء (Makefile, CMakeLists.txt(برامج الربط) وفي الملف الثنائي المُجمَّع نفسه.

بالنسبة للمكتبات المرخصة بموجب رخصة LGPL تحديدًا، يُحدد التمييز بين الربط الثابت والربط الديناميكي التزامات الترخيص. تسمح رخصة LGPL بالربط الديناميكي دون نشر حقوق النسخ، بينما قد يُفعّل الربط الثابت متطلبات حقوق النسخ على العمل المُدمج. لذا، يلزم استخدام أداة تحليل ثنائية تفحص الناتج المُجمّع، وليس فقط بيان المصدر، لتحديد المكونات المرتبطة بشكل ثابت وتراخيصها.

4. التبعيات المحملة أثناء التشغيل

يتم تحميل المكتبات ديناميكيًا أثناء التشغيل من خلال بنى المكونات الإضافية، أو الربط المتأخر، أو تكاملات محرك البرمجة النصية. قد لا يمكن تحديد هذه التبعيات من خلال تحليل شفرة المصدر وحدها، إذ تعتمد على بيئة التشغيل، والتكوين، ومسار التنفيذ. تُعد برامج تشغيل قواعد البيانات المحملة عبر الانعكاس، ومكونات المحلل اللغوي الإضافية المكتشفة من خلال آليات تحميل الخدمات، وامتدادات البرمجة النصية المحملة من مسارات نظام الملفات عند بدء التشغيل، جميعها تبعيات تشغيلية ذات آثار محتملة على الترخيص.

فئات مخاطر الترخيص والتزاماتها

تتراوح تراخيص المصادر المفتوحة بين التراخيص المتساهلة والتراخيص المقيدة. ويحدد فهم موقع كل ترخيص على هذا الطيف مدى الالتزام الذي يترتب عليه.

التراخيص المتساهلة (MIT، Apache-2.0، BSD-2-Clause، BSD-3-Clause، ISC)

الالتزام: يجب ذكر المصدر، وتضمين نص الترخيص وإشعار حقوق النشر في التوزيعات. لا يُشترط الكشف عن شفرة المصدر. يُسمح بالاستخدام التجاري دون قيود. يُسمح بالدمج في المنتجات المملوكة.

مستوى المخاطر للبرامج التجارية: منخفض. ويمكن تحقيق الإسناد بسهولة وبشكل تلقائي.

تراخيص حقوق النشر الضعيفة (LGPL-2.0، LGPL-2.1، LGPL-3.0، MPL-2.0، EUPL-1.2)

الالتزام: يجب ذكر المصدر بالإضافة إلى أي تعديلات على المكون المرخص. بالنسبة لرخصة LGPL تحديدًا: عادةً ما يفي الربط الديناميكي بشروط الرخصة دون أن يؤدي إلى انتهاك حقوق النسخ على الكود المُستدعي؛ بينما قد لا يفي الربط الثابت بذلك.

مستوى المخاطر للبرامج التجارية: متوسط. يعتمد على طريقة الربط. الربط الديناميكي آمن عادةً؛ أما الربط الثابت فيتطلب مراجعة قانونية دقيقة.

تراخيص قوية لحقوق النشر (GPL-2.0، GPL-3.0، AGPL-3.0)

الالتزام: يجب إتاحة الإسناد بالإضافة إلى العمل الكامل المدمج الذي يتضمن مكون رخصة جنو العمومية (GPL) بموجب شروط رخصة جنو العمومية (الكشف عن شفرة المصدر). وتوسع رخصة جنو العمومية المتقدمة (AGPL) هذا ليشمل البرامج التي يتم الوصول إليها عبر الشبكة.

مستوى المخاطرة للبرمجيات التجارية: مرتفع. قد يتطلب استخدام مكون مرخص بموجب رخصة جنو العمومية (GPL) مرتبط بشكل ثابت بمنتج تجاري مملوك أو مشتق منه، الكشف عن شفرة المصدر الخاصة به. هذه هي مخاطرة الترخيص التي تُؤدي إلى أكبر التسويات القانونية.

حقوق النشر على الشبكة (AGPL-3.0)

الالتزام: جميع التزامات GPL-3.0، بالإضافة إلى: يعتبر المستخدمون الذين يتفاعلون مع البرنامج عبر الشبكة متلقين للبرنامج، مما يؤدي إلى تفعيل التزام الكشف عن المصدر حتى بالنسبة لمنتجات SaaS التي لا توزع الملفات الثنائية أبدًا.

مستوى المخاطر لمنتجات البرمجيات كخدمة (SaaS): مرتفع للغاية. صُممت رخصة AGPL خصيصًا لسد "ثغرة SaaS" في رخصة GPL. يجب على أي منتج SaaS تجاري يتضمن مكونًا مرخصًا بموجب AGPL الكشف عن مصدره لأي مستخدم يتفاعل معه عبر الشبكة.

التراخيص الملكية والتجارية

الالتزام: يتم تحديده بموجب اتفاقية الترخيص، ويتراوح من "عدم إعادة التوزيع" إلى "رسوم لكل وحدة" إلى "ترخيص مقعد المؤسسة". هذه ليست مفتوحة المصدر ولكنها تظهر في أشجار التبعية عند استخدام المكونات التجارية.

مستوى المخاطرة: يختلف باختلاف الشروط. غالباً ما يتم اكتشافه أثناء عملية التدقيق النافي للجهالة في عمليات الاندماج والاستحواذ عند حصر التزامات رسوم الترخيص للمنتجات المكتسبة.

توافق التراخيص: المصفوفة التي تهم

عند دمج مكونات ذات تراخيص مختلفة في منتج برمجي واحد، يجب أن تكون التراخيص متوافقة. تُشكل التراخيص غير المتوافقة مخاطر قانونية لا يمكن حلها بمجرد تحديد المسؤولية، إذ قد ينتهك الدمج نفسه أحد الترخيصين أو كليهما.

مدموج مع	معهد ماساتشوستس للتكنولوجيا	أباتشي-2.0	LGPL-2.1	جي بي إل 2.0	جي بي إل 3.0	PLFA-3.0
معهد ماساتشوستس للتكنولوجيا
أباتشي-2.0				غير متوافق
LGPL-2.1					غير متوافق	غير متوافق
جي بي إل 2.0		غير متوافق			غير متوافق	غير متوافق
جي بي إل 3.0			غير متوافق	غير متوافق
الملكية			الحذر	غير متوافق	غير متوافق	غير متوافق

أهمّ أوجه عدم التوافق بالنسبة للبرمجيات التجارية هو عدم توافق رخصة Apache 2.0 مع رخصة GPL 2.0. فلا يمكن دمج مكتبة مرخصة برخصة Apache 2.0 مع مكوّن مرخص برخصة GPL 2.0 في نفس العمل. ونظرًا لأن العديد من مكوّنات المصادر المفتوحة الأساسية (مثل وحدات نواة لينكس وبعض مكتبات جافا القديمة) مرخصة برخصة GPL 2.0 وليست GPL 3.0، فإن هذا التناقض يُشكّل خطرًا حقيقيًا على الامتثال في هياكل التبعيات المختلطة.

يُعدّ بند AGPL-3.0 الأكثر تقييدًا لبرامج SaaS: لا يوجد شيء تقريبًا يتوافق بسلاسة مع AGPL-3.0 في منتج تجاري دون التسبب في الالتزام بحقوق النسخ على الشبكة.

تطبيق سياسة الترخيص في التكامل المستمر/التسليم المستمر

إنّ الالتزام بالترخيص الذي يعتمد على عمليات تدقيق دورية يفشل لحظة إدخاله: فمثلاً، تبقى تبعية رخصة جنو العمومية (GPL) التي أضافها أحدهم في آخر دورة تطوير قيد التشغيل لمدة ثلاثة أسابيع قبل أن يكتشفها التدقيق الفصلي. إنّ تطبيق الرخصة باستمرار عند دمجها هو النهج الوحيد الذي يمنع دخول التبعيات غير المتوافقة إلى قاعدة التعليمات البرمجية.

يامل

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.json

تنبيه: تختلف سياسة الترخيص من مؤسسة لأخرى. تعكس قائمة الممنوعات في المثال أعلاه سياسة تجارية عامة، ولكن يجب على الفريق القانوني في مؤسستك تحديد التراخيص المسموح بها، والتراخيص التي تستدعي المراجعة، والتراخيص الممنوعة، وذلك وفقًا لنوع منتجك، ونموذج التوزيع، واتفاقيات العملاء. قد تكون مكتبة مسموح بها في أداة داخلية ممنوعة في منتج يُوزع على العملاء.

معايير إنشاء وتنسيق قائمة مكونات المنتج

قائمة مكونات البرمجيات (SBOM) هي وثيقة منظمة تجعل الامتثال للترخيص قابلاً للتدقيق والمشاركة والتحقق الآلي. يمكن لفرق الامتثال تأكيد التزامات الترخيص دون الحاجة إلى عمليات تدقيق يدوية عندما توفر قائمة مكونات البرمجيات هذه البيانات. يهيمن نوعان من هذه القوائم على السوق:

CycloneDX ، الذي طورته OWASP، مصمم خصيصًا لحالات استخدام الأمن وسلاسل التوريد. يدعم قوائم مكونات المنتجات والخدمات والثغرات الأمنية (VEX) والصيغ ونماذج التعلم الآلي. وهو التنسيق المفضل لقوائم مكونات المنتجات التي تركز على الأمن، والتنسيق المطلوب لمعظم عمليات تكامل أدوات تحليل سلسلة التوريد الحديثة.

سبدكسمعيار ISO/IEC (ISO 5962:2021)، الذي تتولى مؤسسة لينكس صيانته. وهو مطلوب بموجب بعض معايير المشتريات الحكومية، بما في ذلك جوانب من الأمر التنفيذي 14028. ويركز هذا المعيار بشكل أكبر على الامتثال للترخيص أكثر من تركيزه على الأمن، ويتميز بلغة تعبيرات ترخيص أكثر ثراءً (يمكن لتعبيرات SPDX استيعاب سيناريوهات التراخيص المتعددة المعقدة). GPL-2.0-only AND MIT OR Apache-2.0).

يحظر الأمر التنفيذي رقم 14028 بالفعل على الموردين غير المدرجين في قائمة مكونات المنتج (SBOM) المشاركة في العقود الفيدرالية، وستبدأ وكالة الإيرادات الكندية (CRA) في تطبيق الإبلاغ عن الثغرات الأمنية في سبتمبر 2026، كما أن معيار PCI DSS 4.0 مُطبق بالفعل من قبل المدققين. إما أن تُقدم منتجاتك وفقًا لقائمة مكونات المنتج (SBOM) أو ستخسر الصفقات.

بالنسبة لمنتجات برامج المؤسسات، لا تتجاوز تكلفة إنتاج كلا الصيغتين تكلفة توليدها من تحليل التبعيات نفسه. ويختلف جمهور كل منهما: ففرق الأمن وسير عمل إدارة الثغرات الأمنية تستخدم CycloneDX؛ بينما تفضل الفرق القانونية وفرق المشتريات وسير عمل الامتثال التنظيمي عادةً SPDX.

مشكلة قاعدة التعليمات البرمجية القديمة: لا يوجد مدير حزم، ولا يوجد بيان

تعتمد أدوات تحليل التبعيات المذكورة أعلاه، مثل ماسحات SCA ومحللات ملفات القفل ومولدات SBOM، على افتراض أن تبعيات البرامج تُدار عبر مديري الحزم وتُعلن في ملفات البيان. ينطبق هذا الافتراض على مشاريع Java وJavaScript وPython وGo وRust الحديثة، ولكنه لا ينطبق على بيئات المؤسسات القديمة المبنية على COBOL وJCL ومنصات الحواسيب المركزية.

في بيئة الحواسيب المركزية، يتجلى الاعتماد على برامج الطرف الثالث بثلاث طرق لا تستطيع أدوات تحليل البرمجيات القياسية اكتشافها:

منتجات الفرز والخدمات المرخصة. تستدعي مسارات وظائف JCL برامج الأدوات المساعدة، ومنتجات الفرز (DFSORT، وSyncSort/Syncsort المعروفة الآن باسم Precisely، وCA Sort)، وبرامج كتابة التقارير (SAS، وEASYTRIEVE)، وأدوات تحويل البيانات، وهي برامج تجارية مرخصة لها شروط ترخيص وعقود صيانة ومتطلبات امتثال خاصة بها. تظهر هذه البرامج في JCL على النحو التالي: PGM=SORT, PGM=IEBGENER, PGM=ICETOOLأسماء البرامج، وليس مُعرّفات الحزم. لا توجد أداة SCA تقرأ package.json or pom.xml سنجدهم.

ملفات تعريف COBOL المُقدمة من المورد. يُقدم موردو البرامج الخارجيون ملفات تعريف COBOL التي تُعد برامج مرخصة. قد يُقدم مورد برامج التكنولوجيا المالية الذي يوفر برامج COBOL لمعالجة المدفوعات ملفات تعريف تُحدد هياكل البيانات الخاصة به. كل برنامج COBOL يتضمن هذه الملفات يستخدم برنامجًا مرخصًا. التزامات الترخيص حقيقية؛ ولا يوجد إدخال في مدير الحزم.

قد تكون المؤسسات المالية التي تُشغّل أنظمة COBOL قد أدمجت خوارزميات مرخصة، وروتينات حسابية اكتوارية، وتطبيقات تشفير، ومكتبات تحليل عددي، مباشرةً في شفرة مصدر COBOL. وقد تكون هذه الخوارزميات قد نشأت كشفرة مصدرية مرخصة تم تجميعها في قاعدة الشفرة، ولا يمكن تحديدها من خلال برامج إدارة الحزم.

بالنسبة لهذه المكونات، تعتمد طريقة الاكتشاف على تحليل شفرة المصدر: تتبع عبارات الاستدعاء لتحديد البرامج المستدعاة، وفحص عبارات النسخ لتحديد الأعضاء المضمنة، ومطابقة أسماء البرامج مع سجل مكونات الطرف الثالث المعروفة. تُغذي المخرجات نفس سير عمل الامتثال للترخيص، ولكنها تتطلب أداة تفهم دلالات لغة كوبول ولغة التحكم في الوظائف (JCL)، وليس فقط تنسيقات بيانات الحزم الحديثة.

إعداد حزمة الامتثال الجاهزة للتدقيق

عندما يطلب القسم القانوني أو قسم الامتثال أو مدقق حسابات خارجي أدلة على الامتثال للترخيص، فإن تقرير الفحص ضروري ولكنه غير كافٍ. تتضمن حزمة الامتثال الجاهزة للتدقيق ما يلي:

• جرد كامل للاعتماداتكل مكون وإصدار وترخيص، بما في ذلك التبعيات المتعدية، مُنظمة حسب المنتج والإصدار.
• مصفوفة التزامات الترخيصبالنسبة لكل فئة من فئات التراخيص الموجودة، الالتزامات المحددة (الإسناد، والكشف عن المصدر، وإشعار التعديل) وكيفية الوفاء بكل منها.
• ملف إشعارات الإسناد، تم تجميع الإشعارات القانونية لجميع المكونات التي تتطلب الإسناد، بالتنسيق المطلوب لكل ترخيص (ملف إشعار لـ Apache-2.0، ملف ترخيص لـ MIT، إلخ).
• تحليل عدم التوافق، وثائق تثبت عدم وجود أي مجموعات تراخيص غير متوافقة في المنتج المدمج، مع تقديم مبررات قانونية لأي حالات استثنائية
• قطعة أثرية من SBOMملف CycloneDX أو SPDX الحالي، موقع ومؤرخ، ويغطي جميع المكونات المشمولة.
• توثيق السياسةسياسة ترخيص المصادر المفتوحة المكتوبة للمنظمة، بما في ذلك عملية الموافقة على التراخيص الجديدة.
• سجلات الموافقةبالنسبة لأي ترخيص يتطلب مراجعة قانونية قبل إدراجه، يجب تقديم الموافقة الموثقة والتبرير التجاري.
• تاريخ المعالجةتوثيق أي انتهاكات تم تحديدها مسبقاً والإجراءات المتخذة لحلها

فيما يخصّ التدقيق النافي للجهالة في عمليات الاندماج والاستحواذ تحديدًا: يطلب المستحوذون بشكل متزايد هذه الحزمة كجزء من التدقيق الفني النافي للجهالة. تُسرّع حزمة الامتثال الخالية من أي انتهاكات عالقة عملية التدقيق. أما الحزمة التي تكشف عن انتهاكات غير محلولة لشروط ترخيص المنتج العام (GPL) في منتج مملوك، فعادةً ما تؤدي إلى تعديل السعر، أو اشتراطات الضمان، أو إجراءات تصحيحية كشرط لإتمام الصفقة، وكلها أكثر تكلفة من برنامج الامتثال الذي كان سيمنع حدوثها.

كيفية SMART TS XL يدعم الامتثال للترخيص في قواعد بيانات المؤسسة

SMART TS XLالصورة رسم خرائط تبعية التطبيق يوفر طبقة تحليل التبعية الهيكلية لقواعد بيانات المؤسسة، لا سيما في البيئة القديمة حيث تصل أدوات تحليل التبعية الهيكلية القياسية إلى حدودها.

في بيئات الحواسيب المركزية، تحدد خريطة التبعيات كل برنامج يستدعيه أي برنامج آخر (موضحةً استدعاءات الأدوات المساعدة الخارجية المضمنة في لغة التحكم في الوظائف (JCL) ولغة كوبول (COBOL))، وكل ملف نسخ مضمن في كل برنامج (موضحةً تبعيات ملفات النسخ المقدمة من المورد)، وكل مجموعة بيانات يتم الوصول إليها بواسطة كل برنامج (موضحةً تبعيات طبقة البيانات على منتجات قواعد البيانات المرخصة). ينتج عن هذا التحليل قائمة جرد المكونات التي تُعد شرطًا أساسيًا لتدقيق الامتثال للترخيص في البيئات التي لا يوجد بها مدير حزم.

تُحدد خاصية تحليل الشفرة الثابتة أنماط الشفرة المرتبطة بمكونات محددة من جهات خارجية: توقيعات استدعاء واجهة برمجة التطبيقات الخاصة، واتفاقيات بنية البيانات الخاصة بالمورد، وتطبيقات الخوارزميات المرخصة المضمنة في مصدر COBOL مخصص. تُكمل هذه النتائج قائمة الجرد المستندة إلى ملفات البيان بمعلومات عن التبعيات على مستوى الشفرة التي لا يمكن الوصول إليها من خلال فحص ملفات البيان.

تتيح خاصية تحليل الأثر إمكانية اتخاذ إجراءات بشأن تغييرات سياسة الترخيص: فإذا تغير ترخيص أحد المكونات، أو أُعيد ترخيص أحد التبعيات من ترخيص MIT إلى ترخيص AGPL-3.0، أو عدّل أحد الموردين شروطه، فإن تحليل الأثر يُحدد كل برنامج في المحفظة يعتمد على ذلك المكون، سواء بشكل مباشر أو غير مباشر. وهذا يحوّل حدث تغيير الترخيص من خطر غير معروف إلى نطاق معالجة محدد.

تتيح خاصية البحث المؤسسي إمكانية الاستعلام عن قائمة التبعيات لأغراض الامتثال: حيث يمكنك العثور على كل برنامج يستدعي أداة مساعدة محددة، وكل ملف نسخ يتضمن عنصرًا معينًا من مورد معين، وكل برنامج يعتمد على مكون مرخص محدد، وذلك في ثوانٍ معدودة، عبر جميع الأنظمة القديمة. تُعد خاصية البحث هذه أداة عملية لطلبات تدقيق عمليات الاندماج والاستحواذ التي تُجرى صباح الثلاثاء: فهي تُغني عن المراجعة اليدوية.

بالنسبة للمؤسسات التي تبني تغطية شاملة لقائمة مكونات الأعمال (SBOM) تشمل الأنظمة الحديثة والقديمة على حد سواء، SMART TS XL يوفر قائمة جرد المكونات القديمة التي لا تستطيع مولدات SBOM القياسية إنتاجها، مما يكمل أدوات مثل Syft وFOSSA وDependency-Track للبنية الحديثة.

التدقيق الذي لا ينبغي أن يكون مفاجئاً أبداً

يُعدّ تدقيق الامتثال لشروط الترخيص أحد المجالات التنظيمية القليلة التي غالبًا ما يُكتشف فيها الجزاء الناتج عن عدم الامتثال ليس من قِبل جهة تنظيمية، بل من قِبل شريك تجاري، أو جهة مستحوذة، أو الفريق القانوني للعميل، أو موزع يقرأ شروط الترخيص ويطلب دليلًا على الامتثال. وتتراوح تكلفة هذا الاكتشاف بين الإحراج الشديد والتكلفة الباهظة، وذلك بحسب جسامة المخالفة ومرحلة الصفقة.

برنامج تحليل التبعيات الذي يمنع هذا الاكتشاف المفاجئ ليس مكلفًا مقارنةً بالمخاطر التي يُخففها. يتطلب هذا البرنامج معرفة محتويات البرنامج، كل مكون، كل تبعية متعدية، كل جزء برمجي مُورّد، كل أداة مساعدة قديمة، والتحقق من كل منها باستمرار وفقًا لسياسة ترخيص المؤسسة، بدلًا من التحقق الدوري. الأدوات متوفرة، والمعايير (SBOM، SPDX، CycloneDX) متوفرة، والمتطلبات التنظيمية (EO 14028، CRA، PCI-DSS 4.0) متوفرة. العنصر الوحيد المفقود، بالنسبة لمعظم المؤسسات، هو الالتزام بتحليل التبعيات كجزء من البنية التحتية، وليس مجرد عملية تدقيق.

إن صباح الثلاثاء الذي يبدأ بتقرير بدلاً من تدريب على الإخلاء في حالة الحريق هو صباح الثلاثاء الذي أصبحت فيه بنية تحليل التبعية ممكنة.