الخلاصة

  • كان تعهد HP المسجل في RFC 1988 نافذاً تلقائياً للتطبيقات المؤهلة من وحدات MIB في مسار معايير IETF، من دون طلب أو توقيع أو رخصة مكتوبة.
  • اقتصر التعهد على عائلة براءات واستعمال معيّن، واستبعد وحدات MIB الخاصة، وكان يمكن لادعاء براءة يطابق الشرط المنشور أن ينهي المنفعة نهائياً للطرف المعني.

في الترتيب المعتاد تبدأ الحقوق بعد الورقة. أما في RFC 1988 فكانت الورقة الاختيارية تأتي بعد الحق. أعلنت Hewlett-Packard أن تعهدها بعدم إنفاذ براءات محددة يصبح نافذاً تلقائياً متى استوفى التطبيق الشروط. وكان من الممكن طلب تأكيد مكتوب، لكنه لم يكن مفتاح الدخول.

بهذا نُقلت معاملة متكررة من التفاوض الثنائي إلى سجل علني قابل لإعادة الاستخدام. غير أن السرعة عند المدخل لم تلغِ ضرورة فحص الحدود.

حدود لا تختصرها كلمة «تلقائي»

بدأ النطاق بعائلة البراءات. سمّى النص البراءتين الأميركيتين 5,293,635 و5,421,024، وأدرج الامتدادات والانقسامات والاستمرارات الجزئية والنظائر غير الأميركية التي وصفها. ولم يشمل كل براءات HP؛ فالحقوق تحت براءات أخرى بقيت خاضعة لشروط الشركة وأسعارها السارية آنذاك.

ثم جاء وضع الوحدة. كان التطبيق المطلوب لوحدة MIB في مسار معايير IETF، على أن تحتوي تقنية البحث عن العناوين التي ساهمت بها HP أو مشتقاتها. التشابه الوظيفي وحده لا يثبت هذا الوضع.

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

وأخيراً نص RFC صراحة على أن وحدات MIB الخاصة غير مشمولة. استطاع التعهد أن يرافق المساهمة داخل الطبقة المشتركة المحددة، لكنه لم ينتقل تلقائياً إلى امتداد مغلق. لذلك كانت قابلية النقل معيارية وليست عامة.

شرط يعمل بعد بدء المنفعة

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

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

هكذا اختلف البدء عن الاستمرار. لم يحتج البدء إلى تفاوض، لكن قراراً لاحقاً في استراتيجية البراءات قد يمحو المنفعة بصورة لا رجعة فيها. التلقائية خفّضت الاحتكاك، ولم تمنح حصانة من العواقب.

انتقال الإشعار بين الوثائق

صدر RFC 2108 سنة 1997 بصفة Proposed Standard، وحدّث MIB لمكررات IEEE 802.3 وأضاف البحث عن العناوين ورسم الطوبولوجيا. وأوضح قسم تتبع العناوين أن التعريفات تقوم على تقنية حاصلة على براءة لـ HP، وسجّل منح حقوق لمنفذي ذلك MIB، وأحال إلى RFC 1988 والبراءتين. وبالمقارنة مع RFC 1516 السابق، عرض RFC 2108 هاتين الوظيفتين كقدرات جديدة.

ثم تضمّن RFC 2266، وهو Proposed Standard سنة 1998 لمكررات IEEE 802.12، تعريفات لتتبع العناوين وأعاد الإحالة إلى التعهد وأرقام البراءات.

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

ما تستطيع الوثيقة إثباته

RFC 1988 وثيقة Informational وتقول إنها لا تحدد أي معيار للإنترنت. هي مصدر أولي للتعهد المنشور وشروطه، وليست حكماً قضائياً أو فحصاً حديثاً لحالة البراءات أو رأياً عالمياً في حرية التشغيل أو مسحاً للانتشار. كما أنها لا تناقش مسائل الأمن.

لذلك لا يستنتج هذا المقال مدة البراءات اليوم أو مالكها أو قابليتها للإنفاذ في ولاية قضائية بعينها. ولا يصنّف MIB لمنتج غير مسمى. تحتاج تلك الأسئلة إلى أدلة راهنة ومحددة.

توضح عدسة «Minimum Initial Specification» لدى Lu Heng قيمة التنسيق: قاعدة عامة قابلة لإعادة الاستخدام تستطيع إزالة تفاوض متكرر من الطبقة المشتركة من دون أن توحّد كل القرارات المستقبلية. أما «Running-Code Primacy» فتمنع القفزة من النشر إلى الواقع؛ فالنشر والإحالة والتنفيذ والتشغيل والتبني وقائع مختلفة.

إرث RFC 1988 إذن ليس فتحاً بلا قيد، بل هندسة إذن محدد: بداية تلقائية، فرع خاص مستبعد، وشرط قد يقطع المنفعة نهائياً.

المصادر