Barry O’Donovan: دور CRA يتغير بحسب المنتج

الخلاصة

ينظر CRA إلى طريقة إتاحة منتج محدد والجهة التي تدعمه باستمرار. ويقول Barry O’Donovan إن المؤسسة قد تكون جهة مشرفة على البرمجيات مفتوحة المصدر (open-source software steward في نص CRA) للإصدار المجاني ومصنّعًا للإصدار المدفوع.
صفة «غير ربحي» لا تحسم التصنيف. يحتاج المشغّلون إلى سجل لكل منتج، وجهة لتلقي بلاغات الثغرات، ومسار واضح لإصدار الإصلاحات.

قد ينشر مشروع شيفرة مفتوحة بلا مقابل، ثم يبيع نسخة موسعة بميزات إضافية. وقد يمنح CRA كل نسخة دورًا مختلفًا. هذه خلاصة Barry O’Donovan العملية: الدور يتبع المنتج، لا الاسم المسجل للمؤسسة.

يتولى O’Donovan تطوير IXP Manager في INEX. وفي RIPE 93، خلال عرض عن سلسلة توريد البرمجيات، طرح السؤال الذي يهم المشغّلين: عندما يعتمد مركز تبادل أو مشغّل شبكة على برنامج مفتوح المصدر، ما العمل الأمني الذي يمكنه توقعه من المشروع الذي يطوره؟

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

استخدم O’Donovan مثال مشروع يقدم نسخته المفتوحة مجانًا ويبيع نسخة تضم ميزات أخرى. ووفق شرحه، يمكن للمؤسسة أن تكون الجهة المشرفة على النسخة المفتوحة ومصنّعًا للنسخة المدفوعة. كما تربط إرشادات المفوضية القواعد بمنتجات محددة وبطريقة توفيرها. وهذا أدق من وضع تصنيف CRA واحد ودائم على مؤسسة أو شركة أو فريق تطوير.

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

استشهد O’Donovan ببرنامج IXP Manager. وقال إن INEX ترى أن المشروع يندرج ضمن فئة الجهة المشرفة على البرمجيات مفتوحة المصدر، وإنها نشرت سياسة للتطوير الآمن وسياسة للإفصاح عن الثغرات بعد أن طلبت مراكز تبادل أخرى معلومات عن سلسلة التوريد. وذكر أيضًا أن INEX مؤسسة غير ربحية تتقاضى رسومًا على منافذ الربط. هذا تفسير تشغيلي من المؤسسة، وليس قرارًا تنظيميًا بشأن IXP Manager. وتظل القاعدة المنشورة مرتبطة بالمنتج وبالدور الفعلي للجهة.

أما المشغّلون الخاضعون لـNIS2، فتظل عليهم إدارة سلسلة التوريد الخاصة بهم. فالمادة 21 تتناول أمن الموردين واكتساب الأنظمة وتطويرها وصيانتها، بما في ذلك التعامل مع الثغرات والإفصاح عنها. ونصح O’Donovan بإنشاء سجل للبرمجيات، ومتابعة الثغرات، ووضع سياسة لإصدار الإصلاحات في الوقت المناسب.

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