خلفية ظهور البرمجيات الاحتكارية في السبعينيات
بدايةً من الخمسينيات، كان الحاسوب شيء غريب عند الكثيرين. رغم ذلك، لم تكن البرمجيات وقتها سلعة مستقلة كما نراها الآن. في تلك الفترة، الشركات المصنعة مثل آي بي إم تقدم الشيفرة مع الجهاز دون قيد. بمعنى آخر، كل من اشترى جهازاً كبيراً حصل على البرنامج ومصدره بسهولة. لم يكن هناك تمييز واضح بين الآلة وما يعمل عليها حينئذٍ. فالفكرة الحديثة عن البرمجيات الخاصة لم تظهر بعد في السوق. بدلاً من البيع المنفصل للبرامج، كانت تُعتبر دعماً تقنياً طبيعياً. حتى السبعينيات، هذا النموذج ظل هو القاعدة في الصناعة. مع التطور، بدأت الأمور بالتغير رويداً رويداً. لكن قبل أي تحوّل، كان الواقع مختلفاً تماماً عمّا نعرفه اليوم.
في تلك الحقبة انتشرت ثقافة غير رسمية بين المبرمجين في الجامعات ومعاهد البحث. هؤلاء المطورون كانوا يشارك بعضهم الشيفرات دون قيود. التبادل يحدث بشكل طبيعي كأنه جزء من العمل اليومي. الإصلاحات البرمجية تنتقل من شخص لآخر مثل أفكار عابرة. التطوير يتم بالتدرج عبر مساهمات صغيرة. أحد المهندسين يصلح خطأ، ثم يرسل التعديل للآخرين. التعاون لا يحتاج إلى أوامر مركزية. البرنامج ينمو مع الوقت بفضل تدخلات متعددة. ربما بدأ الأمر بلعبة بسيطة، لكنها أثّرت على طريقة العمل التقنية. لم يكن هناك هيمنة لمؤسسة واحدة. الأفكار تتدفق حرّة كالمياه. كل مستخدم يمكنه أن يضيف تعديلاً إن وجده ضرورياً. هذه العادة بدأت تشبه توارث الطبخ المنزلي أكثر مما تشبه الصناعة الرقمية الحديثة.
في منتصف السبعينات، بدأت الأمور تنقلب رأساً على عقب. لم يعد الأمر كما كان بسبب أسباب كثيرة دفعت بالبرمجيات بعيداً عن المشاركة الحرة. شيئاً فشيئاً أصبحت البرمجة سلعة يُشترى ويُباع استخدامها. ما كان معرفة متداولة بين المهتمين صار تحت قفل وملكية خاصة. حدث هذا التحوّل ببطء لكنه كان حاسماً. مع الوقت، غابت الفكرة القديمة عن التعاون المفتوح أمام انتشار النموذج التجاري
عام 1969 كان نقطة تحوّل. تحت وطأة دعوى ضد الممارسات الاحتكارية، قررت آي بي إم فصل برنامجها عن أجهزتها. منذ ذلك الحين، صار للبرامج سعر مستقل لا يُحسب مع الجهاز. هذا التغيير البسيط فتح المجال أمام نشوء شركات جديدة تركّز فقط على البرمجيات. لم تعد الحاجة مرتبطة بالعتاد كي تحصل على برنامج يعمل.
في عام 1976، أرسل بيل غيتس رسالة موجهة لهواة الحاسوب. الرسالة انتشرت بشكل واسع، وأصبح لها وزن كبير حينها. لم يكتبها بلغة رسمية جافة، بل بصوت حاد نوعاً ما. كانت تنبع من شعور بالإحباط تجاه توزيع نسخ من برنامج باسم "Altair BASIC". المستخدمون كانوا يحصلون عليها دون مقابل. هو لم يصف الأمر بأنه مجرد تقاسم. بل وضع الكلمة الأخيرة: هذا سلوك يشبه السرقة. قبل تلك الرسالة، اعتُبرت البرمجيات كأداة بحث أو مشروع تعاوني. بعد ظهور النص، بدأ التفكير يتغير رويداً. صار البرنامج شيئاً يمكن امتلاكه قانونياً. الفكرة الجديدة بدأت تترسخ: لا شيء مجاني للأبد. ما كان يبدو طبيعياً بين الهواة أصبح مطروحاً على المحك. الأمر لم يعد فقط حول الكود، بل عن القيمة والجهد. منذ ذلك الوقت، دخلت الصناعة مرحلة مختلفة. الحماية القانونية للبرامج صارت أمراً مفروغاً منه لدى الكثيرين. النقاش الذي فتحه لم يغلق تماماً حتى اليوم.
بعدما كانت البرمجيات في مهب الريح، أصبح لها وجه حقوقي. دخل قانون 1976 حيز التنفيذ ليصنّف الشفرات كنصٍ محمي. لم يعد من الممكن ببساطة أخذ ما تم إنشاؤه دون إذن. الحماية تحولت إلى سياج حول الكود. أي نسخ بعد ذلك يعتبر انتهاكًا واضحًا. الشركات بدأت تشعر بأن لديها حق الدفاع عن عملها. التغيير لم يكن صاخبًا لكنه كان فارقًا.
بدأت بعض الشركات بالتراجع عن إتاحة الشيفرة المصدرية. بدل ذلك، تقدّم فقط النسخ القابلة للتشغيل. الراغبون في رؤية الكود الأصلي يحتاجون إلى توقيع وثيقة قانونية مشددة. تلك الوثيقة تحظر نقل أي تعديلات أُجريَت. التحدث حول طريقة عمل البرنامج أيضًا يكون ممنوعًا غالبًا. كل هذا يحدث تحت ضغط الالتزام بالسرية التامة.
في قلب هذا التحوّل نشأت أجواء تسيطر عليها القيود، سادتها السرية كعادة لا تُناقش. دخل المطوّرون مرحلة شعروا فيها بالجمود، لم يعودوا قادرين على لمس أكوادهم الخاصة لإصلاح عللها. البعض بدأ يلاحظ التغير وكأن شيئاً ما انكسر من الداخل. تلك اللحظات جعلت الفكرة تتسلل بهدوء: ربما الحرية ضرورة وليس اختياراً. صدمة هزّت الطريقة التي كان الجميع يتقبلها دون نقاش. ومن رحم هذه الهزة ولدت فكرة مختلفة تماماً، كانت بدايتها صغيرة لكنها لم تمت.
2.. بيئة العمل في مختبر MIT وتأثيرها على ستالمان
بداية من السبعينات، دخل ريتشارد ستالمان عالمَ مختبر الذكاء الاصطناعي في معهد ماساتشوستس للتكنولوجيا. ليس مكاناً تقليدياً للعمل فقط، بل حُلمٌ تحوّل إلى واقع أمام المطورين حينها. هنا، بين الشاشات والأكواد، نشأت أفكاره الخاصة بطريقة مختلفة تماماً عن السابق. التجربة هناك لم تمنحه عملاً فحسب، بل صقلت طريقة تفكيره برمتها بفعل الحرية التي سادت البيئة آنذاك. ما بدأ كوظيفة تحول شيئاً فشيئاً إلى مشروع حياتي بسبب الأجواء الاستثنائية المنتشرة في كل زاوية.
في زمن كان فيه الشاشات خافتة، اشتغل الفريق على مشروع غريب اسمه ITS. النظام هذا ما بنى للمنافسة لا للربح. دخل أي أحد يريد التعديل، بدون قيود تقف حائط بين المستخدمين. التعاون هنا لم يكن فكرة نظرية فقط، طال كل تفصيلة في الكود. ظهرت ثقافة مختلفة جذرياً، حيث الأفضل هو من يضيف قيمة فعلية. حتى أبسط تغيير ممكن يؤثر، إذا كان ذا معنى.
بدون كلمات سر، دخل الناس الحسابات بسهولة. من يرى غلطة في الكود، عدّله مباشرة. كل واحد يصل إلى ما يريد دون قيود. الدخول كان مفتوحًا للجميع بلا استثناء. إذا لاحظت خللًا، صححته فورًا بدون إذن. ما فيش حاجز أمام من أراد التعديل. الحسابات كانت متاحة لكل من يطلبها. أي أحد يستخدم النظام كما يشاء. مافيش رقابة على الدخول أو التغيير. التصحيح يتم بلمسة واحدة من أي مستخدم.
في هذا السياق، كان المقصود بالقرصنة هو الابتكار في البرمجة. حلّ المشكلات بطريقة ذكية كان جزءًا منها. لم يكن الأمر متعلقًا بالإضرار بأحد. بل عكس ذلك تمامًا. تجلّى المعنى الحقيقي في التفكير خارج النطاق المألوف. أحيانًا كانت الحلول تظهر من حيث لا يُتوقع. الذكاء الحاد كان سيد الموقف دائمًا.
كان العرف السائد هو: "إذا كتبت برنامجاً مفيداً، فمن واجبك مشاركته مع الجميع لتحسينه".
في قرية صغيرة عاش ستالمان سنين طويلة. البرمجيات حينها لم تكن للبيع، بل يصنعها الباحثون بعضهم لبعض. كان الدافع وراء العمل هو التقدم في الفِهم، وليس جمع المال. كل ما يُنتج كان متاحًا للجميع دون سؤال عن مقابل. الفكرة ببساطة: نشارك لننمو معًا، لا لنحصد ربحًا فرديًا. هكذا كانت الأمور قبل أن تتغير شيئًا فشيئًا.
في لحظة ما، بدأ كل شيء يتغير. شركات كبرى دخلت المشهد فجأة. لم يعد الأمر كما كان. واحد من أغرب المواقف حصل في بداية الثمانينيات. جهاز طباعة ليزر صنعه زيروكس غيّر نظرة ستالمان للعالم. الحادث اتسم بتفاصيل لا يُمكن نسيانها. الجهاز كان متطورًا لكنه مقفل أمام المستخدم. هذا أثار استغراب ريتشارد. لم يكن مجرد عطل تقني. بل نوع من الحرمان. منذ تلك اللحظة، أصبح قراره واضحًا. حرية البرمجيات لم تعد فكرة مجردة.
قبل زمنٍ ليس بعيداً، كلما تعثّرت الطابعة العتيقة في منتصف عملها، اضطر ستالمان وفريقه إلى إعادة ضبط التعليمات البرمجية الخاصة بالمشغِّل. ذلك التعديل الصغير كان يُفعَّل تنبيهاً للناس حين يتوقف الورق في الداخل. لم يكن هناك حلول جاهزة، فقط تدخل يدوي دقيق. النظام لم يستطع التعرّف على المشكلة لوحده، فكان لا بد من لمسة بشرية لتوصيل الرسالة. أبسط عطل طارئ استدعى وقتاً وجهداً كبيراً. لم تكن الأتمتة قد بلغت ما هي عليه اليوم.
ستالمان كان ينوي التصرف مثل ما فعل مع الطابعات القديمة. غير أن Xerox رفضت تسليم الكود المصدري هذه المرة. السبب؟ بحسب قولهم، يعتبر معلومة سرية تخص العمل. لم يُسمح له بالوصول إليها تحت أي ظرف. رغم طلبه المتكرر، بقي الجواب نفسه. الشركة تمترس خلف وصفها كملكية فكرية. لذلك، لم يستطع استنساخ التجربة السابقة.
في جامعة كارنيغي ميلون، واجه مشكلة حين طلب الكود من زميل له. الرجل امتنع عن التسليم رغم وجود العلاقة بينهما. سبب الرفض كان الالتزام بوثيقة سرية تم توقيعها قبل ذلك. لم يكن بمقدوره نقل أي شيء حتى لو بدى الأمر غريباً للطرف الآخر. الاتفاق أوقف التواصل حول المشروع تماماً دون استثناءات. حتى المعلومات البسيطة لم تُنقل خشية الوقوع في المخالفة. الأمر لا يتعلق بالثقة بل بالنظام الذي فُرض وقت العمل. ما بدا طبيعياً عند الأول أصبح حاجزاً غير قابل للاختراق. القوانين الجامعية جعلت التعاون أمراً مستحيلاً رغم القرب الجغرافي. في النهاية ظل كل جانب يعمل ضمن حدود ما هو مصرح به فقط.
فجأة، أصبح ستالمان وحيداً في المختبر. معظم زملائه غادروا، لكن ليس بأيديهم فارغة. انتقلوا إلى إنشاء شركات مثل Symbolics ولشركة أخرى اسمها Lisp Machines Inc. أخذوا معهم البرمجيات التي طُورت داخل المعامل. البرامج لم تعد حرة بعد الآن، بل صارت ملكية خاصة ومغلقة أمام الآخرين. لم يعد بوسعه تعديل أنظمة الحواسيب من حوله. حتى الأشخاص الذين كان يعمل معهم يوماً رفضوا مشاركة الشيفرة معه. كان يقف بين أجهزة لا يمكنه التحكم بها تقنياً. كل شيء تغير دون تحذير. ما بنوه سوياً أصبح عقبة في طريقه.
بدأ ينظر إلى البرمجيات الخاصة بعين مختلفة تمامًا. لم يعد يراها مجرد نموذج اقتصادي عادي. أصبحت في نظره شيئًا لا يتسم بالنزاهة. تحوّلت في رؤيته إلى بنية تتعدى على التضامن بين البشر. قد تقسم المجتمعات بدل أن تجمعها. أحد الأسباب؟ أنها تحول دون قدرة المستخدمين على دعم الآخرين. فكرة المشاركة تُقصَف بمجرد استخدام هذا النوع من البرامج.
3. صدام ستالمان مع قيود الشركات على الكود المصدري
رغم أن الخلاف بدأ بطباعة خطأ ما، إلا أنه سرعان ما صار توتراً كبيراً حول من يملك الحق في المعرفة. لم يعد الأمر يتعلق بشخص واحد فقط، بل بات صراعاً واضحاً على حرية الوصول للمعلومات. في قلب هذه الأزمة، برزت مواجهة حادة بين ريتشارد ستالمان ومؤسسة "سيمبوليكس". كانت الشركة تخزن الشيفرات ولا تريد مشاركتها. بينما كان ستالمان يرى أن الكود يجب ألا يكون أسيراً لأحد. هكذا، بدأت جولة طويلة من الرفض والتحدي.
انفصل فريق من مختبر MIT للذكاء الاصطناعي في أوائل الثمانينات. بدأ بعضهم مشروعاً جديداً يحمل اسم سيمبولكس. كان معهم نظام تشغيل عملوا عليه سابقاً، أُطلق عليه اسم آلة لِسْب. تحول المشروع إلى شركة كبيرة بعد فترة قصيرة. لم يعد النظام متاحاً بشكل حر كما في السابق. أصبح الوصول إليه مقيداً بشروط صارمة. التعديل على الكود بات أمراً مستحيلاً للمستخدمين العاديين. الحماية القانونية زادت حدتها تدريجياً. حتى الأشخاص الذين ساهموا فيه سابقاً استُبعدوا لاحقاً.
في قلب التجربة، اصطدم ستالمان بحاجز من نوع خاص. ليس مجرد عقد، بل التزام صارم يُعرف باسم "اتفاقية عدم الإفshare". الشركات تفرضها على المطورين كشرط أساسي للعمل لديها. كل سطر كود يكتبه الفرد لا يمكن ذكره أمام غيرهم. حتى الحديث البسيط مع زميل سابق يصبح أمراً مستحيلاً. بالنسبة له، هذه القاعدة تحولت إلى إهانة للمشاعر أكثر من كونها مجرد وثيقة قانونية. كأن توقيع الورقة هو دفن لشيء ما بداخلك. الفكرة أن تقفل فمك بينما الآخرون يستفيدون من علمك - ذلك أشبه بالخذلان. لم يعد الشعور بالمسؤولية تجاه الرفاق في الحقل مجرد اختيار. كان الصمت المفروض جبراً انقطاعاً عن الجذر الذي نما منه كل شيء.
رغم أن الجميع ترك المكان، ظل ستالمان هناك. في معزل تام عن زملائه، لم يلن موقفه أمام ضغوط الانضمام إلى شركة.Symbolics كان المشهد فارغاً تقريباً في مختبر MIT حين بدأ التحدي الحقيقي. طوال سنتين متتاليتين، بين عامي 1982 و1983 بالتحديد، تحول إلى كيان كامل يعمل دون انقطاع. ما فعله لم يكن مجرد عمل عادي بل خطوة نادرة في زمن تسارع فيه الآخرون نحو الربح. كل يوم من تلك الفترة حمل نوعاً من الصمود التقني الفردي
في كل مرة، كان يتتبع ما تُصدره Symbolics من إضافات لبرمجياتها الخاصة. أحيانًا كانت التحديثات بسيطة، في بعض الأحيان معقدة. لم يكن يفوت شيئًا منهم. النظام ظل محدود الوصول دائمًا. هو واصل المتابعة دون انقطاع.
بعد ذلك يبدأ في صنع نسخة جديدة تمامًا لكنها تعمل مثل الأصلية. أحيانًا يستخدم طريقة مختلفة لبناء ما يشبه الوظيفة نفسها. قد يُعيد التفكير بالطريقة التي يعمل بها الشيء ثم يبنيه خطوة بخطوة. ليس تقليدًا، بل إعادة إنتاج بأساليب خاصة به. النتيجة تبدو مألوفة، رغم أن الطريقة لم تكن واحدة من قبل.
النسخة المفتوحة من النظام تُنشر هنا علناً كي يقدر أي واحد يستخدمها بدون ما يدفع. حصلت الفكرة من مبدأ إن البرمجيات يجب تنفع للكل بالتساوي.
بدأ يطمح في تقويض السيطرة التي تمتعت بها المؤسسة وحدها. لم يكن فقط يريد اختراق الحواجز، بل إظهار قدرات الشيفرة المفتوحة أمام النماذج المغلقة. ببطء أثبت أن الأداء لا يتطلب سراً تجارياً.
في النهاية، وبعدما حقق ستالمان نجاحاً تقنياً بمحاكاة نظام Symbolics، بدأ يشعر أن الطريق الذي يسلكه لن يؤدي إلى شيء. استمراره في ملاحقة الشركات وإصلاح الأنظمة المقفلة لم يكن خياراً مستداماً. لم يعد يرى الجذور في مؤسسة واحدة فقط. السبب الحقيقي كان أوسع: قوانين وتقنيات ترسخ احتكار البرمجيات وتُبقي عليه.
فجأة، أدرك أن الصيانة لن تنفع. بدل ذلك، يحتاج الأمر لشيء من البداية. شيء لا يعود ل corporation واحدة. حرّ في كل سطر فيه.
4. مفهوم "البرمجيات الحرة" قبل تأسيس GNU
في الزمن الذي سبق إعلان ريتشارد ستالمان لمشروع غنو، لم تكن عبارة البرمجيات الحرة تحمل تعريفاً واضحاً أو إطاراً قانونياً محدداً. تلك العبارة ببساطة وصفت ما اعتاد عليه المطورون عبر سنين طويلة من العمل. حالة طبيعية نشأت تلقائياً دون تنظيم رسمي. كانت مجرد جزء من البيئة التقنية السائدة آنذاك. لا أحد فكر في وضع حدود لها أو تصنيفها بدقة. كل ما في الأمر أنها مثلت الشكل الأصلي للتفاعل بين المهندسين والبرامج. وجودها كان أمراً مسلماً به، كشيء موجود منذ البداية.
في السبعينات وأوائلها، لم تكن الحاجة إلى كلمة "حرية" ملحة بين المبرمجين داخل الحرم الجامعي أو الأقسام البحثية. من الطبيعي أن يتشارك الباحثون الشيفرات دون قيود، هكذا جرت العادة منذ بدء العمل بالحواسيب الكبيرة. مصدر الفكرة يعود إلى النموذج الأكاديمي القديم، حيث المعرفة لا تخضع لملكية فردية. شبه الخوارزميات بالمعادلات جاء ليس من باب التمثيل فقط، بل لأنه انعكاس للواقع حينها. فرض السيطرة على برنامج كان يبدو غير معقول، كأن تحاول امتلاك عدد باي. هكذا كانت الصورة قبل أن تتغير الأولويات بالتدرج مع دخول الشركات مجال التطوير.
في فترة 1982–1983، مع بداية تطبيق الشركات لقيود جديدة، برز موقف ستالمان من الحدث ليس باعتباره تبادل سلع أو خدمات. إنما رآه ضمن إطار يخص السلوك والتأثير المجتمعي. تشكل عنده حينها فهم جديد، مفاده أن:
من الطبيعي أن يبدو اختباء الرمز وكأنه سلوك انطواوي، إذ يقف حجر عثرة أمام التعاون بين الأفراد.
من الطبيعي أن يتوقع المرء المعاملة الحسنة حين يقدمها. تظهر العلاقة بين الأفعال عندما يُعامَل الشخص بالطريقة التي يحب أن يُعامَ بها. يحدث التبادل الصغير دون ضجة حين تقدم ما لديك بدل الانتظار دوماً. ربما بدأ كل شيء من رغبة بسيطة في المشاركة. الشعور بأن ما عندك قد يفيد غيرك يجعل الخطوة الأولى أهون.
بينما تقدم له العقد، ظهر التردد في عينيه. بدلاً من القبول الفوري، فكّر في العواقب بعيدًا عن الم immediate gain. رفض أن يُلزم نفسه بسرية قد تقيد حريته لاحقًا. في اللحظة التي كان فيها الطريق السلس متاحًا، اختار المسار الذي لا يضمن الأمان. ليس لأنه أراد المعاناة، بل لأن الصمت لم يعد خيارًا مقبولًا لديه. حين طُلب منه التوقيع، قرر أن صوته أهم من الوظيفة المستقرة. على الرغم من الجاذبية الكبيرة للراتب العالي، فقدّم نزاهته كأولوية عليا. القرار لم يكن انفعاليًا، إنما جاء بعد أسابيع من التأمل العميق. بعدها، بدأ خطواته الأولى نحو ما سمي لاحقًا بالمعارضة الهادئة.
في تلك اللحظة، بدأ ستالمان يرى أن البرمجيات الحرة المنفصلة لا تكفي إن عملت ضمن نظام احتكاري مثل يونكس التجاري آنذاك. رغم توافر الأدوات هنا وهناك، إلا أن التحكم الكامل يتطلب حرية في كل طبقة تقريباً. من دون قاعدة حرة تحتها، تصبح الحرية الجزئية بلا معنى حقيقي على المدى الطويل. الاعتماد على نواة غير حرة يجعل باقي النظام عرضة للتقييد والسيطرة من الخارج. هكذا وُلدت فكرة ضرورة بناء كامل البنية السفلية بذاتها، خطوة بعد أخرى. ليس فقط التطبيقات ما يحتاج إلى استقلال، بل القلب التقني للجهاز بأسره. freedom لم تعد ممكنة ما لم تمتد من أسفل الشاشة إلى أعماق المعالج.
من هنا، بدأ التفكير يتغير تدريجيًا بعيدًا عن فكرة «مشاركة الشيفرة بين المعارف» نحو إدراك أن وجود بيئة عمل مستقلة أصبح أمرًا لا غنى عنه. بالتالي، لم يعد الكود الحر مجرد خيار تقني، بل شرط أساسي لاستمرار المجتمع دون الاعتماد على قرار مؤسسة ما. لهذا السبب، ظهرت الفكرة التي سبقت إطلاق مشروع جنو بشكل مباشر. في النهاية، كان هذا الفهم العميق هو العامل الحاسم في تشكيل الخطوة القادمة. على الرغم من ذلك، لم يكن الأمر متعلقًا بالتكنولوجيا فقط، بل بالاستقلالية الجماعية. وهكذا، دخل المبدأ حيز التطبيق عبر إعلان رسمي غير متوقع آنذاك.
5. إعلان مشروع GNU عام 1983
بدأت القصة في سبعٍ وعشرين من سبتمبر عام ألف تسعمائة ثلاثة وتسعين. أرسل ريتشارد ستالمان رسالة إلكترونية إلى مجموعة نت يونكس-ويزاردز. النشر تمّ أيضاً على منبر آخر هو نت يو سوفت. تلك الخطوة لم تكن عابرة. كان الهدف واضحًا منذ اللحظات الأولى. ظهر الحدث كمعلَم في تاريخ البرمجيات. استخدم الوسيلة المتاحة حينها للتواصل مع المطوِّرين. لم يكن هناك صخب حول القرار آنذاك. رُسمت بداية طريق مختلف من تلك الرسالة. اختار التاريخ ليكون شاهدًا على التحوّل.
في البدء، كتب ستالمان كلمات أصبحت مرجعًا: تلك الجملة كانت الشرارة.
ترجمتها: "يونكس حر! سأبدأ في عيد الشكر القادم بكتابة نظام برمجيات كامل متوافق مع يونكس، وسأطلق عليه اسم GNU (اختصاراً لـ Gnu's Not Unix)، وسأوزعه مجاناً لكل من يستطيع استخدامه."
بسبب ماذا تم اختيار التوافق مع يونكس؟ لم يقم ستيالمن ببناء هيكل مختلف بالكامل منذ البداية، بدلًا من ذلك اتجه نحو التطابق الكامل مع يونكس. ذلك التوجه جاء مدفوعًا بعدد من العوامل الواقعية، وليس فقط تفكيرًا تقنيًا. في المقام الأول، وُجدت أنظمة كثيرة قائمة على يونكس آنذاك. نتيجة لذلك، أصبح من المنطقي دعم البيئة الموجودة بدل خلق واحدة جديدة. بالإضافة إلى ذلك، توافر عدد كبير من البرامج والمستخدمين الذين يعرفون النظام. لهذا السبب، ظهر التصميم كحل عملي أكثر منه طموحًا ثوريًا. على الناحية الأخرى، لم يكن الانقطاع عن القاعدة الحالية خيارًا حكيمًا وقتئذٍ. ما حدث في النهاية كان نتيجة حسابات دقيقة لا عاطفة نحو الأنظمة السابقة
من السهل التنقل بين الأنظمة عند تشابهها. انتشارُ يونِكس في المؤسسات التعليمية والصناعية جعل منه خياراً مألوفاً لدى المهندسين. استخدام بيئة شبيهة يقلل من الوقت اللازم للتأقلم. ذلك يعني أن التعديل على العادات القديمة يحدث دون عوائق كبيرة.
بفضل هيكله المرن، استطاع النظام التشغيلي يونكس العمل عبر أجهزة متنوعة. من خلال هذا التصميم، تمكن ستالمان من توسيع فكرة الحرية التقنية خطوة بخطوة. أصبح بالإمكان استخدام البرنامج دون قيود مرتبطة بالعتاد المستخدم. التنقل بين المنصات المختلفة لم يعد عقبة أمام الانتشار الفعلي للمشروع. على نحو غير متوقع، ساهمت هذه السمة في دعم الرؤية الأوسع للتطوير المجتمعي.
رغم الإعلان فقط، اختار ستالمان أن يفتح الباب أمام الآخرين. بدل التحفظ، دعا مباشرة إلى الدعم عبر المال، الأجهزة، أو الجهد البرمجي. ليس عبر كلمات عابرة، بل رسالة حاسمة شكّلت نقطة تحول. بعيداً عن الهيمنة المؤسسية، أصبح الصوت انطلاقة حقيقية لرؤية جديدة. دون ضجة، بدأت خطوات مشروع GNU تأخذ شكلها الفعلي.
معنى اسم GNU وفلسفته
اسم المشروع الذي اختره ريتشارد ستالمان لم يأتِ من فراغ. تجذر هذا الاختيار في بيئة معهد ماساتشوستس للتكنولوجيا، حيث الميل إلى العبث اللفظي جزء من النسيج اليومي. تلك الثقافة الهوكرية وجدت صداها في التسمية، لا في الصدفة.
بدايةً، الاسم GNU يعني "GNU's Not Unix"، أي أن جنو ليست يونكس. من جهة أخرى، يستخدم المصطلح لوصف حالة تكون فيها الإشارة إلى الذات واضحة. في مثل هذه الحالات، الحرف الأول من الاسم يتضمن الكلمة كلها. على نحو مختلف، يُعرف هذا الأسلوب باسم الاختصار المتكرر. بعض المطورين اعتمدوا الفكرة مستوحاة من مفهوم الدوال التي تستدعي نفسها. بطريقة غير تقليدية، تصبح العلاقة بين الجزء والكل غامضة قليلًا. أحيانًا، يكون القصد سلوكًا فكاهيًا ضمن ثقافة البرمجة. أخيرًا، لا يوجد معنى حرفي صارم خلف العبارة.
لماذا "ليس يونكس"؟ الاسم يحمل رسالة تقنية وسياسية مزدوجة:
من الناحية التقنية، تم بناء النظام وفق مبادئ تشبه أنظمة يونكس. عبر هذا التصميم، يصبح الوصول إليه سهلاً لأي شخص اعتاد العمل على بيئات كهذه. طريقة التشغيل لا تتطلب إعادة تعلم كبيرة من المستخدمين القادمين من تلك الأنظمة.
من الناحية الفلسفية، هذا النظام ليس يونِكس بالمعنى التقليدي. إذ لا تخضع له قيود الملكية القانونية التي فرضتها سابقاً شركة AT&T. قد يبدو للعيان مشابهاً من حيث التصميم والأداء. لكن في الجوهر الحر، يقف في اتجاه معاكس تماماً. اختلافه جوهري رغم ما بينهما من أوجه تطابق خارجية.
أكد ستالمان مراراً على نطق الاسم بحرف الجيم الساكن القوي، ليكون «جنو» وليس «نو». من جهة أخرى، تباين هذا الشكل اللساني مع طريقة نطق اسم حيوان الغنو الأفريقي. في هذه الأثناء، دخل رأس الحيوان تصميماً فنياً عبر قلم الرسام إتيان سوفاسا. بعد ذلك، ارتبط التصميم ارتباطاً وثيقاً بمفهوم الاستقلال في البرمجيات. على نحو غير متوقع، تحول الرمز إلى مكوّن بصري أساسي في هوية المشروع. في المقابل، لم يعد مجرد صورة، بل دلالة بصرية على خلفية تقنية وأخلاقية. بالتالي، ظل النطق الدقيق جزءاً من الهوية منذ بدايتها الأولى.
ابتداءً بالمعنى، تُفهم الفلسفة الأساسية من خلال عبارة ستالمان المألوفة التي تميز نوعي كلمة "Free"
في هذا السياق، المقصود بالحُرّية ليس التكلفة المجانية. بل يدور حول إتاحة الفرصة لفهم كيفية عمل البرنامج. من جانب آخر، الفلسفة التي تعتمدها منظمة جنو لا تمثل اعتراضًا على بيع البرمجيات مقابل مبلغ مالي. ما ترفضه بالمقابل هو حرمان المستخدم من التعديل أو النسخ أو التوزيع. الوصول إلى الشيفرة لا يُعتبر خيارًا ثانويًا عندهم.
7. الهدف: إنشاء نظام تشغيل حر متكامل شبيه بـ UNIX
في الحقيقة، لم يقتصر هدف ريتشارد ستالمان على تطوير برنامج تحرير نصوص أو حتى أداة تحويل تعليمات برمجية. لكن ما دفعه إلى الأمام كان تصوّرًا أكثر ضخامة من ذلك بكثير. تمديد نطاق الحرية في البرمجيات شكّل الأساس الذي انطلق منه. بينما كانت الأنظمة المغلقة تتقدّم حينها، اختار السير في اتجاه مختلف تمامًا. النتيجة ليست فقط كودًا قابلاً للتعديل، بل مشروع إعادة تعريف العلاقة بين المستخدم والبرمجيات. الأمر لا يتعلق بأداة واحدة، بل بمكوّنات نظام كامل قادر على العمل دون التقيّد بالملكية. من هذا المنطلق، بدأ البناء خطوة بعد أخرى نحو استقلالية رقمية حقيقية.
بدايةً من فكرة حرية كاملة، لم يُرَ أن تكون البرمجيات نصف حرة. رؤية ستالمان امتدّت إلى ما هو أبعد: استخدام برنامج مفتوح مع نظام خاضع للملكية يبدو كقيود مستمرة. إذ، حين يعمل تطبيق حر على نظام مثل ويندوز أو ماك، فالتحكم الحقيقي ليس بين يدي المستخدم. يحدث التحرر الكامل فقط عندما تتسم جميع الطبقات بالحرية. من داخل الجهاز، حيث تعمل النواة المشرفة على الواجهات الفيزيائية، وحتى الأدوات التي يستخدمها الشخص يومياً، تحتاج لأن تكون تحت سلطته دون شروط. هكذا، لا تقاس الحرية بعدد التطبيقات بل بنوع النظام بأسره.
بسبب بساطته، كان هذا التصميم خياراً منطقياً. رغم تعقيد الأنظمة الأخرى، وُجد أن نهج يونيكس أكثر كفاءة. على عكس النماذج التقليدية، اعتمد على هيكل مرِن منذ البداية. من حيث الصيانة، تفوّق بسبب تنظيمه الداخلي الواضح. عند المقارنة مع بدائل متعددة، برز لأسباب تتعلق بالاستقرار. منذ إدخاله، حافظ على ميزات جعلت منه خياراً دائمًا
تُبنى بنية يونِكس على فكرة تجزئة المهام إلى وحدات مستقلة. أداة واحدة لكل مهمة، دون ازدواج في الوظائف. عدد هذه الأدوات يبلغ مئات العناصر القابلة للتبديل الفردي. كل عنصر يعمل بدقة ضمن نطاقه الضيق. لا تحتاج التحديثات إلى تعديل كامل النظام. إمكانية الاستبدال الجزئي تمكّن من التعديل دون انهيار البنية. التواصل بين القطع يتم عبر قواعد بسيطة ومباشرة. النتيجة: هيكل مرِن لا يعتمد على كيان واحد. استمرارية العمل لا تتوقف عند خلل محلي. philosophy of separation guides how components interact internally.
في الجامعات ومعاهد البحث، هيمن يونِكس على البيئة التقنية. تبنّي تصميم يشبه ذلك النظام جعل التحول نحو جنو أمراً مألوفاً للمطورين. بدلاً من تعلُّم أدوات جديدة، استخدم المهندسون أوامر اعتادوها سابقاً. التجربة السابقة مع يونِكس ساعدت في تقليص الوقت الضائع في التكيُّف. باستثناء بعض الفروقات البسيطة، بقي الشكل العام مشابهاً لما عُرف قبل ذلك. على هذا النحو، انتقل المستخدمون دون حاجة إلى إعادة تأهيل كامل.
رغم التحديات الكبيرة، بدأت العملية بإعادة تطوير عدد ضخم من الأدوات والبرامج السابقة على نظام يونيكس. تم الاعتماد على بناء كل عنصر جديد منذ البداية، دون استخدام الشيفرات القديمة. من ناحية أخرى، اشترط المشروع أن تكون الرخصة مفتوحة المصدر بشكل كامل. شمل النطاق برامج متعددة كان لها دور أساسي في النظام الأساسي. بعضها كان مرتبطاً مباشرة بالوظائف الأساسية للنظام. على العكس مما يُفترض أحياناً، لم يتم استنساخ أي جزء من الشيفرة الأصلية. النتيجة كانت مجموعة مستقلة تعمل بكفاءة وشفافية عالية
تُعَد النواة مسؤولة عن تنظيم استخدام الموارد داخل النظام.
المترجمات (Compilers): لتحويل الكود المصدري لبرامج تنفيذية.
المحررات (Editors): لكتابة الكود.
تُستخدم الصدفة كوسيلة لإدخال التعليمات.
تُعد المكتبات وسيلة تستخدم لدمج البرمجيات ببعضها. من خلالها تتاح إمكانية التفاعل بين التطبيقات المختلفة دون الحاجة إلى بناء كل وظيفة من الصفر.
من بين ما يحتويه النظام، تظهر أدوات إدارة الملفات كأحد العناصر الأساسية. تتضمن هذه الحزمة برمجيات خاصة بالنقل التلقائي للبيانات إلى الطابعات. الربط مع الشبكات يتم عبر واجهات مخصصة داخلية. بعض الوظائف تنفذ عمليات دعم مباشرة دون الحاجة لتدخل المستخدم.
بدا الوصول إلى ذلك الهدف بعيد المنال حينما كان يُنظر إليه كمهمة فردية أو حتى جماعية محدودة. غير أن ستالمان وضع ثقته في اشتراك مجتمعي تدريجي. بمرور الوقت، أصبحت المساهمات الصغيرة لبنات متصلة. لم يكن هناك وعود بالسرعة. بل تماسك العملية نشأ من التكرار والانتباه البسيط.
8. إعلان وثيقة جنو
على الرغم من مرور سنتين على الجهد الشخصي المكثف، إلا أن ستالمان بدأ يرى ضرورة الاعتماد على تعاون جماعي أوسع. مع حلول مارس 1985، ظهر النص التأسيسي عبر مجلة Dr. Dobb's Journal بوصفه خطاباً واضحاً حول أهداف النظام الجديد. لم يكن ذلك مجرد إعلان تقني، بل كان دعوة فكرية تحت اسم "بيان جنو".
من غير الممكن تقييد الفكرة بورقة تقنية فقط. لم يتوقف نص ستالمان عند كونه خارطة طريق للبرمجيات، بل توسع ليشكل حجة مبنية على الفلسفة والاقتصاد. في هذا النص، بيّن بالتدقيق سبب رؤيته للاحتكار البرمجي كمُعوِّق أخلاقي أمام التقدم التقني. التعاون في كتابة الشفرات، من وجهة نظره، ليس اختياراً إنما ضرورة تماثل طريقة الباحثين في تبادل الاكتشافات. تلك المشاركة الحرة تُعد الأسلوب الأنسب والأكثر إنتاجية في بناء الأنظمة الرقمية.
بشكل غير متوقع، تضمّن البيان تحليلاً دقيقاً. لم ينتظر ستالمان طرح التساؤلات بل سبق إليها بنفسه. من ضمن ما عالجه بوضوح، المسألة المالية. كانت هذه النقطة محورية في الردود المُعدَّة مسبقاً. عبر أسلوب استباقي، غطى الجوانب التي قد تثير الشكوك. التركيز جاء على الأمور العملية دون إسهاب. كل ذلك حدث قبل أن يطرح أي ناقد سؤال واحد
"ألا يجب أن يأكل المبرمجون؟"بالطبع، تأتي الحرية في البرمجيات دون أن تتطلب التضحية بالدخل. من خلال تقديم الخدمات التقنية، يجد المطورون وسيلة للحصول على عائد مالي. التكييف حسب الحاجة يُعد خياراً متاحاً لكسب لقمة العيش. التعليم والتدريب على الاستخدام الفعلي يشكلان مصدر دخل بديل. توزيع النسخ الفعلية يبقى من الطرق القائمة حتى الآن. ليس الاحتكار بالمعرفة هو السبيل الوحيد لتحقيق الإيرادات. تقييد استخدامات البرنامج لا يعد شرطاً ضرورياً لأي مشروع تقني.
بالطبع، تأتي الحرية في البرمجيات دون أن تتطلب التضحية بالدخل. من خلال تقديم الخدمات التقنية، يجد المطورون وسيلة للحصول على عائد مالي. التكييف حسب الحاجة يُعد خياراً متاحاً لكسب لقمة العيش. التعليم والتدريب على الاستخدام الفعلي يشكلان مصدر دخل بديل. توزيع النسخ الفعلية يبقى من الطرق القائمة حتى الآن. ليس الاحتكار بالمعرفة هو السبيل الوحيد لتحقيق الإيرادات. تقييد استخدامات البرنامج لا يعد شرطاً ضرورياً لأي مشروع تقني.
"ألا يحق للشركات استرداد تكاليفها؟"يُذكر أن الدعم المجتمعي للبرنامج يحدث فقط عند فائدته الحقيقية. من جهة أخرى، تأتي القيود المفروضة على الاستخدام أو التعديل بثمن اجتماعي مرتفع. هذه القيود لا تستهدف الفرد بل تؤثر على الجماعة برمتها. في المقابل، الشركات الخاصة تحصل على مكاسب مادية. التوازن بين المنفعة العامة والخاصة يبدو غير متكافئ في هذا السياق.
يُذكر أن الدعم المجتمعي للبرنامج يحدث فقط عند فائدته الحقيقية. من جهة أخرى، تأتي القيود المفروضة على الاستخدام أو التعديل بثمن اجتماعي مرتفع. هذه القيود لا تستهدف الفرد بل تؤثر على الجماعة برمتها. في المقابل، الشركات الخاصة تحصل على مكاسب مادية. التوازن بين المنفعة العامة والخاصة يبدو غير متكافئ في هذا السياق.
من دون تحفظ، جاء في النهاية نداءً للانخراط. لم يقتصر الأمر على كتابة السطور البرمجية، بل امتد ليشمل دعمًا ماديًا أو تبرعًا بأجهزة. كانت هناك إشارة مباشرة إلى عجزٍ عن توفير حواسب، مع الحاجة الملحة لوظائف تقنية تتطلب تمويلًا. بهذا الشكل، بدأ المشروع يبدو كشيء أكبر من مجرد فكرة فردية. تحولت الصورة التدريجية نحو هوية جماعية تحمل رؤى ثابتة. سرعان ما لاقى ذلك استجابة من عدد لا بأس به عبر القارات.
9. تأسيس مؤسسة البرمجيات الحرة FSF عام 1985
عقب إعلان البيان وبدء الحديث عنه، برزت أمام ريتشارد ستالمان مسألة تنفيذية: طريقة التعامل مع المساهمات المالية والمعدات الواردة. من جهة أخرى، ظهر تساؤل حول السبل القانونية لحماية هذا الجهد الجماعي من أي تهديد مستقبلي.
بِتاريخ الرابع من أكتوبر عام 1985، بدأت فكرة تأسيس مؤسسة البرمجيات الحرة على يد ستالمان. هذه المنشأة تم إنشاؤها في ولاية ماساتشوستس باعتبارها جهة لا تهدف إلى الربح. الدافع وراء ذلك كان رغبة في دعم نوع معين من البرمجيات. الشكل القانوني اعتمد عليه بعد دراسة متأنية للحاجة المجتمعية. المؤسس اختار هذا التاريخ تحديدًا دون غيره لبداية المشروع. النتائج الأولى ظهرت ببطء لكن بشكل ثابت منذ اليوم الأول.
مؤسسة FSF لم تُنشأ كشركة تقنية عادية. من خلال دعم مشروع GNU، اتخذت شكل هيكل تنظيمي خاص. أسست هذه المبادرة لتوفير إطار يدعم التطوير المستقل للبرمجيات. بدلاً من التركيز على الربح، ركزت على بناء بيئة رقمية مفتوحة. وظيفتها الأساسية ظلت مرتبطة بإدارة وتنسيق الجهد المجتمعي حول النظام. باتت بذلك مركزاً لجمع الموارد وتوجيه الدعم الفني والقانوني. على الرغم من غياب النموذج التجاري، حافظت على استمرارية العمل عبر سنوات طويلة.
بدأت عملية إقامة الهيكل الأساسي بالاعتماد على تبرعات مالية. من خلالها، تم تعيين مطورين للعمل في المشروع - وكان ستالمان ينضم إليهم بين حين وآخر. شمل الدعم أيضاً اقتناء التقنيات الضرورية لإنشاء نظام GNU خطوة بخطوة.
الحماية القانونية: الدفاع عن رخص البرمجيات الحرة والتأكد من عدم انتهاكها.
نشر الفلسفة: الترويج لمفهوم البرمجيات الحرة عالمياً.
من خلال نموذج فريد يعتمد على بيع الخدمات المرتبطة بالبرمجيات الحرة، تبين أن الجدل حول عدم إمكانية تحقيق دخل لم يكن دقيقاً. في المراحل الأولية، اعتمدت المؤسسة على مصادر متعددة للتمويل. بدلاً من الاعتماد على التبرعات فقط، لجأت إلى تقديم الدعم الفني كوسيلة رئيسية لتحقيق الاستقرار المالي. مع مرور الوقت، أصبح هذا الأسلوب جزءاً من هيكلها التشغيلي. رغم الشكوك المبدئية، فقد سارت قدماً في تطبيق الفكرة. نتيجة لذلك، ظهرت صورة مختلفة لما يمكن أن تكون عليه مؤسسة رقمية مستقلة
تُباع الأشرطة المغناطيسية التي تحتوي نسخاً من أدوات-gnu مثل محول gcc أو محرر emacs بسعر مئة وخمسين دولاراً. يأتي السعر نتيجة تكلفة النسخ والنقل الجسدي، لا مقابل الكود - فالمصدر يبقى حراً لكل من يصل إليه دون دفع. من لديه القدرة على الاستلام الإلكتروني، يتجنب التكلفة تماماً. الخدمة تقدمها جهة تنظّم التوزيع بعيداً عن الشبكة. الفكرة ليست بيع البرمجيات، بل تحصيل عائد لقاء جهد التجهيز والتوصيل. النسخ المطبوعة تتطلب وقتاً ومواد فيقرّر البعض الدفع للحصول عليها. في تلك الحالة، المال ليس للبرنامج، إنما للموارد المستهلكة أثناء إعداد الشريط. نُشِرت القواعد منذ البداية لتوضيح أن الحرية لا تعني غياب التكلفة عند وجود جهد مشترك. بعض الناس يفضلون الحصول على المواد عبر البريد بسبب قلة سرعات الإنترنت حينها. الدفع الطوعي يغطي الطباعة، العلب، الشحن، والوقت المنفق في المعالجة.
تم تقديم نسخ مطبوعة من الكتيبات التقنية للعملاء. توزيع الأدلة يجري عبر قنوات البيع المباشر. بعض الزبائن يطلبون النصوص التوضيحية بعد الشراء. توفر المنشورات شرحاً دقيقاً للاستخدام العملي. تسليم المواد الورقية يتم بلغة واضحة ومباشرة.
رغم بساطته، شكّل هذا الأسلوب الاقتصادي تحوّلاً ملموساً في الفهم. من خلاله، ظهر جلياً أن المعنى الحقيقي للحرية لا يرتبط فقط بعدم الدفع. الكثير من الأفراد اختاروا المساهمة المالية حين شعروا بأن خياراتهم محترمة. ما بدا سابقاً غير عملي أصبح قابلاً للتطبيق عبر الوعي الجماعي. قيمة الشفافية برزت كعامل مؤثر دون الحاجة لتبريرات معقدة. استجابة الجمهور جاءت نتيجة تقدير واضح لاستقلالية القرار. ليس كل ما هو متاح بدون مقابل يحتاج إلى دعم عيني. لكن عندما تتداخل الحقوق بالمسؤوليات، يتغير نمط التفاعل. تجربة المستخدم لم تعد مجرد عنصر ثانوي بل جوهر العملية. النتائج أظهرت أن الثقة تمثل رأس المال الأكثر استدامة.
10. تعريف الحريات الأربع للبرمجيات
بهدف التوضيح التام لما قصده ريتشارد ستالمان بعبارة "حر"، اعتمد نهجاً دقيقاً في الصياغة. لتجنب أي غموض، وضع معياراً واضحاً يحدد به البرمجيات الحرة. منعاً لأي تأويل خاطئ من قبل الجهات التجارية، سعى إلى ضبط المفهوم بدقة عالية.
ليس فقط قال "برمجيات مفتوحة". حدد أربع متطلبات – تُسمى حريات – يجب توافرها كلها كي يُصنّف البرنامج على أنه حر. من الجدير بالإشارة في بيئة المطورين أن العد غالبًا ما يبدأ من الرقم صفر. السبب وراء ذلك يعود إلى استخدام لغات برمجية مثل سي. هذا الأسلوب في الترقيم ليس اعتباطياً، بل نتاج عادة تقنية راسخة.
الحريات الأربع
بدون قيود في الاستخدام: يُمكن التشغيل وفق الرغبة لأجل أي هدف.ممنوع على المطوّر تقييد استخدامك للبرنامج بشروط مثل «تعليمي فقط». استعماله في السياقات التجارية، أو حتى العسكرية، ليس خاضعًا لقيود. التشغيل يتم وفق ما تراه دون التزام بموافقة مسبقة. حرية كاملة في التعامل مع الأداة بأي شكل يناسب الحاجة. الاختيار بيده المستخدم دائمًا، وليس لدى المصمم أي سلطة حظر.
ممنوع على المطوّر تقييد استخدامك للبرنامج بشروط مثل «تعليمي فقط». استعماله في السياقات التجارية، أو حتى العسكرية، ليس خاضعًا لقيود. التشغيل يتم وفق ما تراه دون التزام بموافقة مسبقة. حرية كاملة في التعامل مع الأداة بأي شكل يناسب الحاجة. الاختيار بيده المستخدم دائمًا، وليس لدى المصمم أي سلطة حظر.
مسموح لك بفحص الشيفرة البرمجية عن قرب. قد تُعدّل الأداء حسب الحاجة دون قيود مفروضة من الخارج. التحكم الكامل يبدأ من الفهم الداخلي للبرنامج نفسه. أي تعديل تقوم به يجب أن يكون واضح الغرض. الوصول إلى التفاصيل لا يأتي دائمًا مع ضمانات جاهزة. القدرة على التعديل تنبع من الحرية في القراءة والفهم أولاً.من البديهي أن توفر الشيفرة المصدرية أمر ضروري، إذ يصبح تحليل البرمجيات مستحيلاً في حال غياب الكود.
من البديهي أن توفر الشيفرة المصدرية أمر ضروري، إذ يصبح تحليل البرمجيات مستحيلاً في حال غياب الكود.
تُعدّ الحرية الثانية ممكنة عندما يُعاد توزيع النسخ بسهولة. من خلال المشاركة، يصبح الدعم المتواصل بين الأفراد واقعًا. بإمكان أي شخص تقديم نسخة إلى آخر دون عوائق. التبادل يحدث بشكل طبيعي حينما تكون الحقوق واضحة. انتشار البرمجيات بهذا الشكل لا يحتاج إذنًا مسبقًا.من الممكن أن تُعيد استخدام البرمجية كما يحلو لك. التحويل إلى الأصدقاء يحدث بدون طلب موافقة رسمية. البعض يوزعها دون مقابل، آخرون يأخذون رسوماً صغيرة لتغطية الجهد. الإذن لا يُطلب في هذه العملية أبداً.
من الممكن أن تُعيد استخدام البرمجية كما يحلو لك. التحويل إلى الأصدقاء يحدث بدون طلب موافقة رسمية. البعض يوزعها دون مقابل، آخرون يأخذون رسوماً صغيرة لتغطية الجهد. الإذن لا يُطلب في هذه العملية أبداً.
الحرية 3 (Freedom 3): حرية توزيع نسخك المعدلة للآخرين.من خلال هذا، يُتاح لكل أفراد المجتمع الفرصة للانتفاع مما قمتَ بتحسينه أو تعديله. الوصول إلى الكود المصدري يُعد شرطاً مصاحباً لذلك.
من خلال هذا، يُتاح لكل أفراد المجتمع الفرصة للانتفاع مما قمتَ بتحسينه أو تعديله. الوصول إلى الكود المصدري يُعد شرطاً مصاحباً لذلك.
في حال فقدان برنامجٍ لحرية واحدة من المذكورة، تصنفه مؤسسة البرمجيات الحرة كبرنامج غير حر أو احتكاري. على هذا الأساس استقر الحكم حول التراخيص البرمجية منذ ذلك الوقت وحتى الآن.
11. ظهور رخصة GPL ودورها القانوني
في وقت مبكر، لاحظ ريتشارد ستالمان تحدياً قانونياً يتعلق بحقوق الملكية الرقمية. رغم ذلك، كان من الممكن أن يؤدي نشر الشيفرة دون ضوابط إلى استغلالها من قبل شركات تقنية. هذه المؤسسات قد تُدخل تعديلات طفيفة على العمل الأصلي. مع الوقت، أصبح بالإمكان تحويل البرمجيات المفتوحة إلى منتجات مقفلة للبيع الحصري. بالتالي، لم يعد المشروع أداة لتقويض النظام الاحتكاري، بل مصدر دعم له سيراً غير مقصود.
ابتدع ستالمان سنة 1989 فكرة "الحقوق المتروكة"، كوسيلة للتعامل مع هذا التعقيد. في تلك الوثيقة القانونية المعروفة باسم "رخصة جنو العمومية"، تم صياغة الفكرة بشكل رسمي. ظهر المفهوم متزامنًا مع وضع النص القانوني الذي ينظمه. منذ ذلك الحين، أصبحت الرخصة أداة تنظيمية واضحة. تم التعبير عن الفكرة بأسلوب قانوني دقيق، بعيدًا عن الغموض. سنة الإصدار كانت نقطة تحول في كيفية إدارة الحقوق الرقمية. ليس مجرد نص قانوني عادي، بل إطار عمل خاص بالبرمجيات. كان الهدف الأساسي هو ضمان حرية الوصول إلى الكود. لم يكن الابتكار تقنيًا فقط، بل فكريًا أيضًا. أُدخل المبدأ ضمن بيئة رقمية تتطلب حلولاً غير تقليدية.
من خلال ماذا تُدار الخدعة القانونية؟ لم يتنازل عن الملكية، بل وجّه ستالمان نظام الحماية العقلية نحو مسار مختلف تمامًا. بدل أن يمنع الاستخدام، جعل القاعدة أداة للإتاحة. كيف حدث ذلك؟ باستخدام الآلية نفسها كوسيلة عكسية. لا حذف للحقوق، لكن إعادة توجيهها داخليًا. النتيجة ليست حرية مطلقة، بل ضوابط جديدة داخل النظام القديم.
في البرمجيات الاحتكارية: يقول المؤلف: "هذا البرنامج ملكي، ويُمنع نسخه أو تعديله".
في رخصة GPL: يقول المؤلف: "هذا البرنامج ملكي، وأنا أسمح لك بنسخه وتعديله وبيعه، بشرط واحد: أن تمنح نفس هذه الحريات لأي شخص تعطيه البرنامج".
ما يجعل الرخصة العامة جناح قوية حقاً هو القاعدة التي تتطلب الإفصاح عن التعديلات. في حال استخدامك للشفرة المصدرية المرتبطة بهذه الرخصة ثم عدلتها، يُشترط نشر النتيجة المحسّنة بنفس الشروط عند التوزيع. بالتالي، حين تبدأ شركة باستخدام مشروع مفتوح المصدر مثل تلك التي تابعة لمجموعة جنو، لا يمكنها دمج هذه الشفرة في نظام مغلق - مثل ويندوز أو ماك أو أس - وتمنع الآخرين من الاطلاع على الكود الخاص بها. مجرد محاولة حجب النسخة المنقحة تعني انتهاكاً واضحاً لأحكام الترخيص. وهذا الضغط القانوني البسيط يحمي استمرارية الوصول الجماعي إلى أي عمل مستنِد إلى الأساس الحر.
من خلال هذه الآلية، تحقَّق استمرار حرية البرمجيات بموجب رخصة GPL للأبد. تطوير أي عنصر جديد يتبع نفس المبدأ دون استثناء. الجهود المشتركة بين المطورين لا تُستغل بشكل حصري من طرف واحد أبداً. .Microsoft وصفت الرخصة ذات يوم بأنها مشابهة للمرض المنتشر فرض التوزيع المجاني يتعارض مع النماذج التقليدية في بعض الشركات الكبرى. استخدام الشيفرات المصدر مفتوح قد يغيّر موازين القوة في السوق تقنياً.
12. تطوير مترجم GCC
يبدأ كل برنامج حاسوبي برؤية بسيطة: تحويل فكرة إلى تعليمات يفهمها الجهاز. من بين الخطوات الضرورية، يأتي دور جسر غير مرئي لكنه أساسي. هذا الجسر لا يعمل بالكتابة العادية، بل يحتاج إلى وسيط دقيق. في بعض الأحيان، تكون اللغة التي نستخدمها بعيدة تمامًا عن طريقة تفكير الحواسيب. لذلك يتطلب الأمر عملية معقدة خلف الكواليس. تلك العملية تقوم بها أداة مخصصة، ليست مجرد برنامج عادي. وظيفتها الأساسية هي إعادة صياغة التعليمات بلغة مختلفة تمامًا. هذه اللغة الجديدة تتكون من سلاسل من الأصفار والواحدات. يحدث التحويل عندما يتم تنفيذ خطوة دقيقة بعد أخرى. النتيجة النهائية تكون قابلة للتشغيل مباشرة على المعالج. بدون وجود هذه الأداة، لن تتحرك أي برمجيات متقدمة. اسم هذه الوظيفة هو المُجمّع.
مع انطلاق ريتشارد ستالمان في مشروعة غنو، برزت أمامه إشكالية قديمة بلغة جديدة: بناء مترجم حر دون توفر أداة ترجمة حرة أساسية للبدء بها. ابتداءً من هذه النقطة، صار التساؤل هو المدخل: كيف يُمكن توليد برنامج ترجمة إذا لم يكن موجوداً منذ البداية؟ من هنا، دخل المشروع في حلقة تتطلب اختراقاً تقنياً غير مباشر. الطريق الوحيد كان عبر كتابة كود يعمل على نظام افتراضي قبل أن يصبح مستقلاً. بعد ذلك فقط، أصبح بالإمكان استخدام الأجزاء الأولى لتطوير بيئة كاملة. النتيجة نشأت خطوة بخطوة، بعيداً عن الحلول الجاهزة أو المعتمدة سابقاً.
بدأت المحاولة مع برنامج ترجمة قديم. استخدم ستالمان أداة من جامعة لورانس ليفرمور تُعرف باسم "Pastel Compiler". لكن العقبة ظهرت حين طلب البرنامج موارد ذاكرة أكبر بكثير مما توفره أنظمة يونكس آنذاك. أمام هذه المشكلة، بدا واضحاً أن الحل الوحيد هو بناء نسخة جديدة تماماً. لم يكن هناك طريق آخر متاح سوى البدء من نقطة الصفر.
من عام 1987، عمل ستالمان على تطوير أداة سُميت فيما بعد "مترجم جنو للغة سي". مع ذلك، لم يكن هذا المشروع نسخة معدلة فحسب، بل تفوّق على الأدوات المستخدمة آنذاك. النتيجة جاءت نتيجة رؤية تقنية مختلفة تمامًا عن الاتجاه السائد في السوق حينها.
يُعرف GCC بأدائه الفعّال في توليد تعليمات قصيرة وسريعة. ما يميّزه هو التفوق التقني مقارنةً ببرامج الترجمة السائدة ذات الأسعار العالية. الكفاءة الظاهرة ناتجة عن خوارزميات متقدمة تعمل داخلياً دون ظهور. الأداء لا يأتي من الصدفة بل من تصميم هندسي دقيق يتبع أساليب غير تقليدية. الحجم المضغوط للإخراج كان نتيجة سنوات من التعديل المتواصل. لم يكن هذا المستوى شائعاً بين البرمجيات التجارية وقتها. بعض النتائج جاءت مفاجئة حتى للمطوّرين الأوائل. المقارنات الموضوعية أظهرت فارقاً كبيراً لصالح الأداة المفتوحة المصدر. الدقة في التنفيذ جعلت منه اختياراً طبيعياً للمهام المعتمدة على السرعة. التجربة العملية أكدت التفوّق عبر استخدامات حقيقية في بيئات مختلفة.
من خلال دعم متعدد الأنظمة، تم تطوير ستالمان كي يعمل باختلاف وحدات المعالجة المركزية. سرعان ما أصبح مرجعاً مشتركاً في المجال التقني.
لحظة الانعطاف الكبرى حدثت مع إصدار مترجم غَي سي-سي. من دون سابق إنذار، أصبح المشروع جزءاً من المشهد البرمجي الجاد. رغم تجاهل بعض الخبراء لمفاهيم الحرية أول الأمر، فإن ما دفعهم للتبني هو الكفاءة العالية. الأمر لا يتعلق بأيديولوجيا؛ بل بالعمل الفعّال. في المعامل وفي غرف التطوير، بدأت الأدوات تُستخدم بصمت. حتى قبل أن يكون هناك نظام تشغيل كامل، كانت البذور قد زُرعت. قوة الأداء فتحت الأبواب حيث تعثر الخطاب النظري. ليس التوزيع المجاني سبب الانتشار الوحيد. ما يحدث خلف الكواليس غالباً ما يقود التحوّلات الكبرى. استقرار الأداء حوّل المستخدمين إلى ناقلين غير مباشر. لم يكن أحد يتوقع أن نقطة الدخول ستكون مترجماً.
بعد ذلك، دُمجت أطر عمل جديدة تدريجيًا لتضم صيغ برمجة متعددة منها C++ ثم Fortran. بمرور الوقت، أُعيد تصنيف الاسم إلى "مجموعة مترجمات جنو". أصبح النظام حجر الأساس في بناء نواة Linux. عدد كبير من أدوات الشبكة تعتمد عليه حالياً دون إشارات مباشرة. التحوّل لم يكن سريعًا بل جاء عبر تحديثات متتابعة على مدى أعوام طويلة. كانت النتيجة هي انتشار واسع خلف الكواليس بعيداً عن الأضواء. لا يزال هذا الإطار يعمل بصمت داخل معظم الخوادم النشطة حول العالم اليوم.
13. إنشاء أدوات GNU الأساسية (Coreutils)
مع إتمام عمل المُجمّع (GCC)، برزت أمام ريتشارد ستالمان وفريقه مهمة روتينية، رغم أهميتها البالغة: التعامل مع عدد كبير من الأوامر القصيرة التي تمثل الوسيلة الأساسية للتفاعل مع النظام.
ما هي Coreutils؟ هي الحزمة التي تحتوي على الأوامر الأساسية لإدارة الملفات والنصوص، مثل:
ls (لعرض الملفات).
cp (للنسخ).
mv (للنقل).
rm (للحذف).
cat (لقراءة الملفات).
mkdir (لإنشاء المجلدات).
لولا تلك الوسائل، يفقد الحاسوب القوي قيمته أمام الشخص المعتاد. إذ يعجز عن تنفيذ أمر بسيط كنقل وثيقة بين موقعين.
في استراتيجية تحمل اسم "أفضل من النسخة الأولى"، بدأ المطورون التابعون لمشروع جنو إعادة إنتاج الأدوات التقليدية. قاد هذا الجهد ديفيد ماكنزي مع آخرين. لم يكن الهدف مجرد نسخ أدوات يونيكس القديمة. تم تجاوز الشكل الأصلي بوضوح في العديد من الجوانب. التغييرات جاءت متراكمة عبر خطوات غير مباشرة
في البداية، اتسمت أدوات يونكس القديمة بحدود ثابتة في الكود. بالتالي، كان طول السطر أو حجم الملف يواجه سقوفا لا يمكن تجاوزها. على العكس، تم بناء أدوات جنو لتتكيف مع كمية الذاكرة المتاحة فعليًا. نتيجة لذلك، أصبح التعامل مع البيانات الكبيرة أكثر سلاسة واعتمادية. هذا التصميم جعل النظام أقل عرضة للانقطاع عند المعالجة. من ناحية أخرى، اختفى الحاجز البرمجي الذي قيد الاستخدام السابق. بطريقة مختلفة تمامًا، ركز المهندسون على المرونة بدل الجمود التقني. في النهاية، لم يعد الحجم عائقا أمام تنفيذ الأوامر الأساسية.
تم دمج نظام الموافقة الموحدة. ظهرت خاصية جديدة تُعرف باسم "الخيارات الطويلة"، وتظهر هذه بالبدء بخطافين متتاليين، كمثال على ذلك ما يظهر في --help أو --version. من خلال هذا التغيير، أصبح الفهم البصري للتعليمات أوضح بشكل ملحوظ. لم يعد المستخدمون الجدد بحاجة إلى حفظ رموز يونكس القديمة والمعقدة. الانتقال نحو التنسيق الجديد حدث بتدرّج هادئ دون إحداث اضطراب كبير.
تُظهر الاضافات الجديدة إمكاناتٍ سابقة الغياب، كاستخدام الألوان في عرض ملفات الأمر ls؛ لتوضيح الفرق بين المجلدات والعناصر الأخرى. يُنظر إليها الآن وكأنها جزء طبيعي من التجربة.
في صمتٍ تام، دخلت أدوات GNU Coreutils إلى المختبرات والإدارات. رغم انتشار أنظمة Unix التقليدية، اختار المسؤولون عنها الانتقال إليها. الأداء الرصين جعلها خياراً طبيعياً في بيئات العمل المعقدة. حتى على منصات مثل Solaris وHP-UX، بدأت تتسلل دون ضجة. السبب؟ كفاءتها العالية وعدم تعثرها في المهام المتكررة. لم يكن هناك إعلان رسمي، فقط استخدام يومي يتوسع ببطء. ما كان يبدو تحديثاً تقنياً بسيطاً أصبح تحولاً تحت السطح. الموثوقية وحدها كفيلة بإحداث هذا النوع من التغيير. بمرور الوقت، صارت الحزمة الجديدة هي الأساس غير المعلن. الاحتياج العملي فرض نفسه، بعيداً عن الضوضاء الإعلامية.
بفضل هذا الإنجاز، أصبح المشروع مرجعًا في مجال الجودة. لم يعد يُنظر إليه على أنه عمل تطوعي بحت. من خلال الأداء المتميز، دخل مرحلة جديدة من الاعتراف المهني. مع الوقت، تحول إلى إطار يُقاس عليه الآخرون. رغم بداياته المتواضعة، حقق مكانة ثابتة بين المشاريع الكبرى.
14. تطوير محرر Emacs
بدأ العام 1984 وما زال المشروع الجانبي مجرد فكرة على الأوراق. حينها أدرك ستالمان أن الحاجة تتجه نحو نتيجة واضحة سريعاً. شيء يمكن رؤيته والاستفادة منه فوراً لشد انتباه المهتمين بالبرمجة. كان من غير المعقول طلب استخدام نظام تشغيل لم يُبنَ بعد. لذلك تم اختيار نقطة بداية عملية: أداة كتابة نصوص برمجية يومية الاستخدام. اختير المحرر كخطوة أولى، ليس لأنها الأسهل، بل لأنها الأكثر حاجة. كل مطور تقريباً يستخدم محرراً نصياً في عمله اليومي. من هذا التصرف البسيط بدأ البناء التدريجي للرؤية الأوسع.
ليس فقط أداة كتابة. مع إصدار ستالمن لنسخة GNU إيماكس سنة 1985، ظهر تطبيق يتجاوز وظيفة المفكرة البسيطة ليصبح بيئة حاسوبية قائمة بذاتها تعمل ضمن النظام. ما يجعل إيماكس مختلفا هو قدرته على التكيف الكبير عبر الأوامر القابلة للتخصيص. بعض المستخدمين يستمرون فيه لسنوات دون الحاجة إلى مغادرة الواجهة الرئيسية. يتسم بالعمق الوظيفي الذي لا يبدو واضحا منذ اللحظات الأولى. عند النظر عن كثب، يُلاحظ تنوع أدواته التي تشمل إدارة البريد والشفرة والمجلدات. رغم تعقيده الظاهري، فإن كل دالة نشطة لها سبب وجودها. لم يتم بناؤه للإبهار، إنما للاستمرارية والاستقرار خلال الزمن الطويل
من الممكن تعديل البرنامج عبر لغة تُعرف بلسبي، وهي متوفرة داخل النظام. بالتالي يصبح من السهل تغيير طريقة عمل الأدوات حال التفاعل معها مباشرة. أثناء الاستخدام العادي، يمكن إدخال تعديلات جديدة دون مقاطعة الجلسة الحالية بأي شكل. تتم كل هذه العمليات من دون اللجوء إلى إنهاء التشغيل أو بدء عملية ثانية.
باستخدام لغة Lisp، أنشأ المبرمجون إضافات تمكّن Emacs من تنفيذ مهام متعددة. عبر هذه الإضافات، يُستخدم البرنامج في إدارة الملفات بشكل مباشر. الرسائل الإلكترونية يمكن قراءتها من داخله أيضاً. التصفح النصي للويب أصبح ضمن الإمكانيات المتاحة. بعض التطبيقات تتيح تشغيل الموسيقى أو بدء ألعاب بسيطة. الخروج من الواجهة لم يعد ضرورياً لأداء تلك الوظائف.
من بين الأدوات الأولى التي قدّمتها المبادرة، برز تطبيق GNU Emacs بشكل لافت. لم يكتفِ باستخدامه داخل المجتمع المفتوح فقط، بل دخل مكاتب من يستخدمون أنظمة تشغيل تجارية خاصة. عبر عنه الكثيرون كخيارهم الأساسي دونما ضجة إعلامية أو دعاية. بدت هذه الخطوة وكأنها نقطة تحول هادئة في الرؤية التي وضعها ستالمان منذ البداية
من خلال برنامج باسم إماس، دخل مفهوم-gnu وفكرته حول البرمجيات المفتوحة إلى مؤسسات تعليمية وكبيرة. في البداية لم يُلاحظ ذلك الدخول، لكن التأثير بدأ يتسلل ببطء. هذا البرنامج كان الوسيلة التي حملت الفكرة بعيداً عن الأوساط التقنية الضيقة. تدريجياً، أصبح جزءاً من البيئة الرقمية اليومية هناك. رغم بساطة بدايته، إلا أن النتيجة كانت انتشاراً غير متوقعاً للفلسفة خلفه.
في تلك الفترة، دخل إيماسس ضمن إطار الترخيص جي بي أل حديث النشأة، ما أسهم في توسيع الفكرة القانونية المرتبطة بها.
15. إنشاء Bash كواجهة أوامر حرة
بالنسبة لأنظمة يونكس، الجهاز اللي يتلقّى الأوامر من الشخص ويُشغّلها له اسمه "ال-shell". في تلك الفترة تحديدًا، كان برنامج بورن شيل (sh) هو الشكل الشائع. استيفان بورن طوّره داخل معامل بيل. من ناحية الملكية، كان هذا البرنامج مصنف كبرمجيات مقيدة بحقوق استخدام.
بدون غلاف برمجي حرّ، ما بيكونش النظام مكتمل. مهم يكون في برنامج بديل علشان تقدر تستخدم النظام. الواجهات أمر ضروري، وإلا التفاعل مش هيكون موجود. عشان الشغل يبدأ لازم تكون الأدوات الأساسية متاحة. ما حدش يستخدم نظام بدون طريقة لإدخال الأوامر.
مشروع GNU دوماً ما يحب أن يلعب بالكلمات. اسمه هذا ليس استثناء، بل مزحة لغوية بذكاء خفي.
الصدفة القديمة كانت تسمى Bourne Shell.
الصدفة الجديدة سميت "Bourne Again Shell" (التي تُختصر إلى Bash).
الاسم بيضاهي باللفظ كلمات "من بدري"، وده يرمز لفكرة إن الحاجة القديمة اتحجّت تاني بطريقة أكتر انطلاقاً.
ابتدأ العمل على بَشّ عام 1989، حين اختار ريتشارد ستالمان مُبرمجًا يُدعى براين فوكس للانضمام لمؤسسة البرمجيات الحرة. لم يكن الهدف نسخ شيء موجود، بل بناء أداة جديدة تمامًا. دخلت النسخة التجريبية الأولى حيّز التوزيع في نفس العام تقريبًا. منذ ذلك الحين، أصبح هذا المشروع جزءًا أساسيًّا من كثير أنظمة التشغيل.
ما الذي جعل باش تتقدّم؟ لم يقف فوكس عند حد توافقها مع الشيل القديم فقط كي تعمل النصوص الجاهزة. دمج إليها خصائص جديدة مستوحاة من أطراف أخرى مثل سي شيل وكاي شيل. هذه الإضافات غيّرت طريقة العمل اليومية للمطورين دون عناء كبير.
من الممكن أن تعود للأوامر القديمة بسهولة، فقط اضغط على السهم إلى الأعلى. ليس شرطاً أن تكتب كل شيء من جديد، النظام يحفظ ما سبق استخدامه. ظهر هذا الخيار لأول مرة في نسخ لاحقة، بينما كان غائباً في shell الأولي. كل أمر تُدخله يبقى محفوظاً تلقائياً للوصول إليه لاحقاً. الفكرة بدأت بتحسينات صغيرة، ثم أصبحت جزءاً أساسياً من التجربة. السهم الأعلى يقوم بشيء بسيط لكنه مهم جداً حين تحتاجه. ما كان موجوداً قديماً في البيئة الأساسية اختفى هنا، وحل محله حل أذكى.
مجرد ضغطة على مفتاح Tab، واسم الملف أو الأمر يكمل نفسه مباشرة.
بدون ما تضغط إنتر، يقدر المستخدم ينقل المؤشر ويغير الأوامر. حرك المؤشر كيفما شت وغيّر الجملة قبل التأكيد. لو بدك تعديل، ما تحتاج غير التنقل بالسهم وتبدأ التعديل فوراً. التحكم كامل طالما لم يتم تنفيذ الأمر بعد. استعمال الأسهم ممكن في أي لحظة لإعادة الصياغة.
رغم مرور الزمن، ما زالت بَشْ تسيطر على مشهد السكربتات. السبب؟ اعتمدتها أغلب نسخ لينكس الجديدة منذ التسعينيات. قوة هذه الأداة جعلت منها خياراً طبيعياً للإدارة التقنية. أحياناً لا تحتاج إلى تعقيد - فقط تنفيذ مباشر وفوري. لذلك يستخدمها المدراء التقنيون في كل مكان دون استثناء. ليست الوحيدة، لكنها الأكثر انتشاراً بلا منازع. تطور النظام لم يقلل من استخدامها يوماً. بدلاً من الاستغناء عنها، بنى الآخرون فوق أساسها. حتى الآن، تسري عبارات الأوامر عبر نفس النمط القديم. ما بدأت كأداة بسيطة تحولت إلى معيار صامت.
16. تطوير محاولة لنواة جنو هيرد
بحلول سنة 1990، أنتج فريق GNU شيئاً يشبه المعجزة في عالم التكنولوجيا. كل الأدوات تقريباً كانت جاهزة حينها.
مترجم قوي (GCC).
محرر نصوص متطور (Emacs).
واجهة أوامر (Bash).
مكتبات أساسية (Glibc).
أدوات النظام (Coreutils).
نَجِد أن النظام كان شبه جاهز، رغم هذا لم تكن له روح حقيقية. السبب؟ غياب الشيء الأساسي - النواة. تأتي هذه النقطة كقلب يعمل بصمت خلف الكواليس. هي التي تنظم كيف يستخدم الحاسوب وحدته المركزية أو ذاكرته أو أقراصه. كل ما بُني قبلها يتوقف عن العمل لو انعدمت تلك الوظيفة. ملفات متراكمة بلا معنى، هكذا يكون الوضع من دونها.
اختار ريتشارد ستالمان مع فريقه طريقة غير مألوفة حينها. ليس فقط تجنبوا النواة الواحدية البسيطة كنظام يونيكس. بالتالي اتجهوا إلى فكرة مختلفة تمامًا في بناء النظام. رغم التعقيد الزائد، لجأوا إلى هيكل النوية الصغرية. كانت خطوة جريئة، لكنها حملت أيضًا خطر الفشل.
أطلقوا على النواة اسم GNU Hurd. (الاسم كالعادة اختصار متكرر مزدوج: Hurd تعني Hird of Unix-Replacing Daemons، و Hird تعني Hurd of Interfaces Representing Depth).
فلسفة التصميم (نظرياً رائعة):
برنامج النواة العادي... مثل اللي بنظام يونيكس أو لينكس. كل شي متجمع بداخله: الشبكات، الملفات، السواقة. يعمل ككتلة وحيدة كبيرة، وكلها تشتغل بصلاحيات كاملة من الأعلى. خرق بسيط بأي زاوية؟ النظام يتوقف فجأة بدون إنذار. تعطل واحد في مكان بعيد قد يقتل الجهاز كله دفعة واحدة.
في تصميم هورد ذي النواة الصغيرة، تتولى النواة مجرد إرسال الرسائل بين الأجزاء. من ناحية أخرى، تُنفَّذ مهام مثل الشبكة أو إدارة الملفات خارج النواة تمامًا. هذه الوظائف تعمل كخدمات مستقلة، شبيهة بالبرامج العادية. بدل أن تكون جزءاً من النظام الأساسي، تعيش هذه الخدمات في طبقات أعلى. كل واحدة منها تنفذ مهمتها دون اتصال مباشر بالنواة. التواصل معها يتم عبر قنوات مرتبطة بسيطة. هكذا يصبح الهيكل أكثر انفتاحًا على التعديل. رغم ذلك، لا يعني هذا أنه أسرع دائمًا. بعض العمليات تستغرق وقتًا أطول بسبب التكرار في الإرسال. لكن الفكرة الأساسية تبقى: أقل ما يمكن داخل النواة.متى ما توقف البرنامج عن العمل، أعد تشغيله مباشرةً من دون الحاجة إلى إيقاف الجهاز كاملاً.من الصعب أحيانًا فهم ما يجري بين هذه الأجزاء المتباعدة. رغم بساطتها، تصبح الأمور معقدة عندما تحاول ربطها بعضها ببعض. يحدث سوء فهم دومًا تقريبًا بسبب البُعد أو التباعد في العمل. كل جزء يعمل بطريقته، مما يجعل التنسيق أمرًا بالغ الصعوبة دائمًا.
متى ما توقف البرنامج عن العمل، أعد تشغيله مباشرةً من دون الحاجة إلى إيقاف الجهاز كاملاً.
من الصعب أحيانًا فهم ما يجري بين هذه الأجزاء المتباعدة. رغم بساطتها، تصبح الأمور معقدة عندما تحاول ربطها بعضها ببعض. يحدث سوء فهم دومًا تقريبًا بسبب البُعد أو التباعد في العمل. كل جزء يعمل بطريقته، مما يجعل التنسيق أمرًا بالغ الصعوبة دائمًا.
team GNU قرر الاعتماد على نواة بحث اسمها Mach، جايين من جامعة كارنيغي ميلون. في الحقيقة كانوا يحسبون إن الرحلة راح تكون أسرع. لكن المفاجأة؟ وجدوا نفسهم غارقين في تعقيدات لا حد لها. الطريق اللي بدا مباشرًا تحول لدرب معتم ومليان عقبات تقنية. ما كانش في بالهم إن الخيار هاذا غادي يودي بهم لهنا.
17. صعوبات مشروع Hurd وتأخره
في البداية، ظنّ ريتشارد ستالمان وبعض أعضاء الفريق أن بناء نواة GNU Hurd لن يحتاج سوى سنة أو سنتين كأقصى حد. لكن ما إن مر الوقت حتى غرق المشروع في تعقيدات لا نهاية لها. سنوات طويلة قُضِيَتْ في المحاولة، ومع ذلك لم يصلوا إلى إصدار يمكن الاعتماد عليه فعليًا.
البداية كانت مع النواة المصغرة. رغم أن الفكرة بدت ممتازة على الورق إلا أنها تحولت إلى مشكلة حقيقية أثناء الاختبارات. كل مرة يظهر فيها خطأ صعب تتبعه. لم يكن الأمر مجرد تأخير بل تعثر فعلي في الإصلاح. الحلم الهندسي أصبح عبئاً تقنياً. التصحيح استغرق وقتاً طويلاً أكثر من المتوقع بكثير. الأناقة النظرية لا تنقذ المشروع حين تفشل التجربة. بعض الحلول الذكية تنهار أمام الواقع. ما بدا واضحاً في الرسوم البيانية اختفى في التنفيذ. الجميل نظرياً ليس دائماً قابلاً للتطبيق.
بلاش ما نصوص طويلة، داخل النواة التقليدية، لو حاب يتفاعل جزء مع ثاني، يستدعي الدالة مباشرة. طريقة العمل؟ بسيطة. السرعة تهمنا هنا أكثر من أي شيء. مباشرة بعد الطلب، تنفذ العملية فورًا بدون تأخير. ما فيش حاجة اسمها انتظار، كل خطوة متصلة بالأخرى بشكل لحظي. الربط بين الأجزاء صار عبر استدعاء واحد فقط، مش أكتر. كل عملية تشغّل اللي بعدها بلمسة واحدة على الكود. سرعة التنفيذ تعني إن النظام كله يمشي بسلاسة. ما يحتاجش وقت طويل علشان يوصل الرسالة من مكان لمكان. استدعاء الدالة هو الحل القريب لكل طلب داخلي. الطريق المختصر دايمًا موجود لما يتواصل أي جزئين.
بدءًا من حُزم صغيرة، تعمل كل وحدة في هيرد كخدمة قائمة بذاتها. التواصل بينها يحدث حين تُرسل البيانات بشكل متسلسل.
كانت هناك معضلات فنية خطيرة. ظهرت للعمال تحديات ما كانوا يروها من قبل في البيئات القديمة. بعض العقبات بدأت تطفو ببطء. النظام الجديد كشف عن تعقيدات غريبة. أشياء لم تُحسب لها حساب بدأ صعوبتها تتزايد. كلما تم حل أمر، برز آخر مختلف تمامًا. التحولات جلبت معها سلسلة من المفاجآت غير السارة
أحيانًا تظهر مشاكل غريبة لا يمكن التنبؤ بها. السبب؟ الرسائل لا تصل بالترتيب ذاته دائمًا. مجرد اختلاف بسيط في توقيت وصول الإشارات يؤدي إلى نتائج مختلفة. لا شيء ثابت هنا، كل جولة لها شكل مختلف. يصعب اكتشاف ما الذي حدث فعلاً بعد فوات الأوان. كل مرة تتغير الصورة بدون قاعدة واضحة. ليس هناك خطأ واحد يتكرر لنفهم السبب. ما يحدث اليوم قد لا يحدث غدًا بنفس الشكل. التسلسل العشوائي للإشارات هو الجاني الخفي غالبًا. شيء ما يفلت من الضبط ولا أحد يلحظه في اللحظة المناسبة.
تعطل الحركة: يتوقف الخادم المسؤول عن الملفات لأنه ينتظر ردّ من نظام الذاكرة. في الأثناء، نظام الذاكرة لا يعمل إلا بعد استلام إشارة من خادم الملفات. كل شيء يجمد فجأة دون تحذير. التفاعل البسيط بينهما يتحول إلى شلل كامل. النظام كله يتوقف عن الاستجابة بسبب هذه الحلقة الصامتة.
كانت المشكلة في التصحيح صعبة. عندما تحاول إصلاح عطلٍ في نظام الرسائل، لكن الأداة التي تعتمد عليها للبحث عن الخطأ تستخدم نفس النظام المتعطل. مشهد كأنك تنظف محرك سيارة وأنت تقودها بسرعة كبيرة لا يمكن السيطرة عليها.
مما زاد الأمور سوءاً أن النظام بُني على نواة Mach، التي صُممت في جامعة كارنيغي ميلون. لكن تبين بعد حين أن هذه النواة معقدة أكثر مما ظنوا. كانت تعمل ببطء ملحوظ. حتى إنها أعاقت التقدم بسبب ثغرات غامضة في التعامل مع الذاكرة. رغم ذلك، وجهد المطورون في مشروع GNU يذهب جزء كبير منه لإصلاح عيوب Mach. بدل التركيز على بناء نظام Hurd كما خططوا. وهكذا استهلكت الصعوبات التقنية وقتاً طويلاً لم يكن في الحسبان.
مرت سنين التسعينيات واحدة تلو الأخرى. لم تكن النواة جاهزة بعد للعمل اليومي. انهيار النظام المتكرر صار أمرا عاديا. سرعة العمل كانت بالكاد تحتمل. بينما ذلك، بدأ الناس حول الأرض يتطلعون لنظام حر حقيقي. الفجوة بين الحلم والواقع كبرت كثيرا. تلك المساحة الشاسعة من الحاجة فتحت الباب أمام طالب من فنلندا. مشروعه الهوائي البسيط وجد طريقه للعالم دون ضجة.
18. ظهور نواة Linux عام 1991
في الوقت الذي انشغل فيه مهندسوا مشروع جنو بأحجية النوى الصغيرة، من ناحية أخرى، بدأ شاب من هلسنكي لا يزال في العقد الثالث من العمر رحلة تجريبية مع جهاز كمبيوتر جديد. كان هذا الشاب اسمه لينوس تورفالدس. على الجانب الآخر، لم يكن هدفه إحداث ثورة تقنية أو بناء نظام تشغيل كامل منذ البداية. بدلاً من ذلك، دفعه الفضول إلى اختبار أداء المعالج من نوع إنتل 386. رغم أن عمله بدا متواضعًا في الظاهر، فقد أصبح نقطة تحول غير مقصودة. بعد فترة قصيرة، بدأت الأحداث تتسلسل بشكل غير متوقع.
بدأت الرحلة كتجربة شخصية. ليس من أجل التفوق على شركات كبيرة. بل رغبة في استكشاف طريقة عمل المعالج 386. عبر خطوة تلو الأخرى، نما المشروع بهدوء. الاهتمام بالتفاصيل جعل الفكرة تتقدم. التواصل المباشر مع العتاد أضحى ممكناً. النظام التعليمي السابق لم يعد كافياً. الحاجة إلى الأداء الحر دفعت نحو التجريب. كتابة برنامج إدارة المهام أصبح الهدف الأول. لا خطط ضخمة وُضعت حينها. مجرد فضول تقني تحول بمرور الوقت.
في الخامس والعشرين من شهر آب عام ألف تسعمئة وواحد وتسعين، تمَّ إرسال رسالة على يد لينوس إلى منتدى النقاش الخاص بنظام مينيكس. تلك الكلمات تُصنف اليوم كنصٍ ذا أهمية بالغة في السجلات التقنية. عبر عنها بصيغة هادئة جدًا، دونما أي زخرفة أو بهرجة
ترجمتها: "مرحباً بكل مستخدمي مينيكس. أقوم حالياً بتطوير نظام تشغيل (حر) (مجرد هواية، ولن يكون كبيراً واحترافياً مثل GNU) لأجهزة 386..."
ربما كان الفرق بين نجاح لينوس وإخفاق هيرد كامناً في اختلاف النهج. من جهة، تأتي المرونة لتفسر ما عجزت عنه الرؤى الثابتة. طريقة التعامل مع التحديات شكّلت نقطة تحول بارزة. بينما ركز البعض على الكمال، سلك آخرون طريق التجريب المتدرج. هذا النموذج العملي أثبت فاعليته مع الوقت. النتائج ظهرت حيث أولِي الاهتمام للواقع لا للمثالي. ببساطة، الصورة تتضح حين تُترك الأطر النظرية جانباً
من غير المألوف أن يتجه المهندس نحو الأسلوب القديم، لكن لينوس فضل الهيكل الموحّد للنواة. رغم رفض الجامعيين له نظراً لاعتباره بدائياً من الناحية النظرية، إلا أنه عملي. ما يجعله مباشراً في التطوير هو الربط الداخلي الكامل بين الوحدات. السرعة العالية في التشغيل تأتي نتيجة للتداخل الكثيف للمكونات داخل كتلة واحدة. لا وجود للتفصيل المعقد هنا، بل تنفيذ مباشر دون طبقات وسيطة.
ليس من قبيل الصدفة أن تبنّى لينوس وحدات المعالجة Intel 386 الشائعة، بل لأنها كانت في متناول اليد. بينما ظل هيرد يسير نحو بنية تحتية تقنية متقدمة، مرتبطة ببيئة جامعية. استند التصميم الأول إلى ما هو موجود فعلياً في الأسواق. أما الثاني فقد نشأ داخل بيئات بحثية لا تتشارك نفس الأولويات.
بمجرد توفر نسخة أولية، عرضها على المهتمين دون تأخير. حينها، بدأ لينوس في مشاركة الإصدار رقم 0.01 بدون انتظار إنهاء العمل بالكامل. نتيجة لذلك، انضم إليه عدد كبير من المطورين عبر الدول. هؤلاء الأشخاص اختبروا النظام بشكل مباشر. مع الوقت، أصبحت عمليات التصحيح أسرع بكثير مما كان متوقعاً.
مع انتهاء العام 1991، وُجدت نواة عاملة حول العالم، تظهر على شكل سطور نصية في محيط أسود. قدِمت الحاجة حينها إلى هيكل يحمل هذه النواة كي تؤدي عملها. من هذا الموضع، دخل مشروع جنو الصورة تقريباً من غير متوقع.
19. أدوات جنو تعمل مع نواة لينكس
بالكاد بدأ العام 1992، والتقنيات تبدو حينها مختلفة تماماً عن المعتاد. خلال الأشهر الأخيرة من 1991، كانت الصورة العامة غير مألوفة إلى حدٍ ما. في تلك الفترة تحديداً، لم تكن الأمور التكنولوجية كما اعتدنا رؤيتها لاحقاً. بداية التسعينيات شهدت ظروفاً تقنية استثنائية بعض الشيء. نحو نهاية 1991، بدا المشهد الرقمي وكأنه خارج الإطار المعروف
رغم اكتمال هياكل مشروع جنو - كالمترجمات والمحررات - تبقى النواة بطيئة التطور. لم تُحل مشكلة القلب التقني بعد، حتى مع توفر الأطر الأخرى. من الجدير بالذكر أن الواجهات وأدوات التشغيل تعمل بكفاءة نسبية. بينما تتوقف خطط التطوير الأساسية عند عقدة في النظام الداخلي. لا يمكن إغفال حقيقة أن غياب قلب فعّال يؤثر على الاستقرار العام. ما زالت المساعي قائمة لإيجاد حل للنواة العالقة. رغم هذا الخلل المركزي، يستمر المشروع في تقديم أدوات متعددة.
في قلب لينوس تورفالدس، نواة حية تنبض كأنها شرارة مستمرة. من دون أن تعتمد على أدوات خارجية، لا يمكن لتلك النواة أن تمتد في الفعل. بداية من فكرة بسيطة، ظهر نظام بلا ذراعين ليحمله إلى الاستخدام. بينما كانت البنية الأساسية قائمة، غابت التطبيقات التي تُسند إليها الحركة. ليس هناك واجهة تنفس لها سوى ما يولده المطورون من حولها. النتيجة؟ هيكل يعمل داخلياً، لكنه عاجز عن التفاعل مع العالم.
في لحظة غير متوقعة، دارت المواجهة. ليس عبر توقيع وثيقة ولا باللقاء الوجهي بين ستالمان وتورفالدس. من دون تنسيق مسبق، ظهر الاختلاف. تقنية النقاش كانت الوسيلة الوحيدة. بشكل تلقائي تمامًا، بدأت التفاعلات. الحوار نشأ من داخل السياقات البرمجية فقط
من أجل كتابة لينوس للنواة، احتاج إلى أداة ترجمة خاصة بلغة السي. في ذلك الوقت، لم يكن هناك سوى برنامج واحد حر وقوي متاح، وهو GCC التابع لمشروع جنو. بسبب هذا الواقع، استخدمت النواة أدوات جنو منذ أول سطر كود تم إنشاؤه.
حين أتمَّ لينوس تطوير النواة، برزت ضرورة وجود واجهة للتواصل معها. من دون تأخير، بدأ بتعديل برنامج بص الصدفة كي يعمل فوق النظام الجديد. بذلك أصبح بالإمكان تنفيذ الأوامر عبر هذا البرنامج المُعاد هيكلته. كانت الخطوة التالية طبيعية بعد إنجاز القلب التقني للنظام. هكذا دخل باش حيز التشغيل المتزامن مع النواة الوليدة.
بشكل مفاجئ، لاحظ الخبراء في مجال البرمجة أن دمج النواة القادمة من فنلندا مع مجموعة الأدوات المطورة في بوسطن أنتج كياناً رقمياً مستقلاً بالكامل. هذا التزاوج التقني بين العناصر سمح بإطلاق نظام لا يحتاج إلى ترخيص مدفوع. لم يكن هناك تنسيقاً مركزياً لهذه العملية، ومع ذلك تحقق الانتهاء عبر جهود متفرقة. النتيجة كانت ظهور بنية قابلة للعمل دون قيود ملكية. بعض التعديلات البسيطة جعلت العمل متكاملاً رغم غياب التخطيط المشترك.
من داخلها، تنبع أوامر التشغيل الخاصة بالعتاد عبر نظام لينكس.
تُنفَّذ الطلبات في بيئة الصدفة عبر نظام أوامر يعتمد على GNU Bash.
المترجم يبني البرامج (GNU GCC).
تُستخدم الأدوات في التعامل مع الملفات من خلال حزمة GNU الأساسية.
في العام 1992، دخلت فكرة جديدة حيز التنفيذ: عمل جهاز حاسوبي كامل بدون الاعتماد على تعليمات برمجية من مؤسسات كبيرة مثل مايكروسوفت أو AT&T. كانت تلك اللحظة تتويجاً لما طرحه ستالمان منذ سنة 1983. رغم ذلك، لم يأتِ الشكل النهائي كما تخيله هو أو غيره. كان الناتج نقيضاً لما رسمه في مخططاته الأولى. بدلاً من إعادة بناء النظام القديم، برز شيء آخر تماماً. ظهرت البنية الجديدة من زاوية لم تكن في الحسبان.
من خلال هذا الربط المتناغم، أصبح النظام عملياً في الاستخدام الفعلي. لم يعد يقتصر على كونه محاولة نظرية بحتة.
20. ولادة مصطلح GNU/Linux
بانتهاء بنية المنظومة، ودخول أدوات جنو إلى نواة لينكس، برز تساؤل لم يتوقعه أحد: كيف يُسمّى هذا المزيج التقني؟
اسمُ "لينكس" هيمنَ سريعاً. بدايةً، أخذ الناس يسمّون النظام بأكمله بهذا الاسم دون تخطيط مسبق. السبب؟ النواة كانت العنصر الحاسوبِي المفقود الذي أنجز العمل. في تلك الأثناء، صار الاسم شائعاً لكونه مختصراً وسهل الصدور من اللسان. رغم ذلك، لم يكن اختياراً رسمياً بل حدث طبيعياً مع انتشار الاستخدام.
بمجرد أن عارض ريتشارد ستالمان الأمر. ظهر عدم ارتياحه كمؤسس لمشروع غنو. من وجهة نظره، أُطلق على المنظومة اسم «لينكس» فقط. في الحقيقة، رأى فيها مغالطة كبيرة من الناحية التاريخية والتقنية
رغم أهميته، يبقى حجم النواة (Linux) ضئيلاً مقارنة ببقية عناصر النظام. من جهة أخرى، تشكل المكتبات والأدوات وبيئات العمل إرثاً طويلاً لمشروع GNU امتد عبر سنوات طويلة. هذا التوزيع في المساحات التطويرية يبرز كيف أن الجزء التقني لا يستأثر بالكامل في الصورة العامة. بدون هذا الدعم التنظيمي، لما استطاع النظام أن يصل إلى هذه المرحلة المتقدمة. في المحصلة، تتضافر المكونات المختلفة لتُكوّن نظاماً يعمل بكفاءة داخل هيكل معقد.
من غير المهم إن كانت النظرة الأخلاقية للحرية تمثل جوهر اهتمام لينوس تورفالدس أم لا. الأداء العملي يسبق المبادئ عند التقييم. استخدام اسمه في وصف النظام قد يجعل المبدأ الذي بُني عليه المشروع أقل وضوحاً مع الوقت. ما يبدو واضحاً الآن يمكن أن يتلاشى بالتسميات الجديدة.
في منتصف التسعينات، انطلق ستالمن مع مؤسسة البرمجيات الحرة في مسعى لتوضيح الاسم الصحيح. استخدموا تعبيرًا جديدًا يجمع بين اسمَي النظام: "GNU/Linux"، ويُقال له إما "جنو سلاش لينكس" أو "جنو لينكس". هذا الشكل انتشر ببطء ضمن الدوائر التقنية بعد ذلك.
GNU: تمثل البنية التحتية، الأدوات، والمكتبات وفلسفة الحرية.
Linux: تمثل النواة التي تدير العتاد.
ليس القصد من الاسم إبراز الذات. بدلاً منه، كان بمثابة توضيح يومي أن الحرية التي يملكها المستخدم ليست وليدة المصادفة. رغم ظهور النواة كجزء تقني، إلا أن الجذر الحقيقي يعود إلى بيئة عمل ممنهجة. بفضل جنو، أصبح بالإمكان الوصول لتلك الاستقلالية التقنية. كل استخدام للنظام يحمل في طياته رسالة واضحة: لا حرية دون بنية داعمة مدروسة.
بعد تلك اللحظة، بدأ التجزؤ يظهر في نسيج الجماعة
يُفضّل معظم الناس، إلى جانب وسائل الإعلام، استخدام مصطلح "Linux".
يُفضّل مَن يتبنّى فلسفة الحريات التسمية «جِنو/لينكس» لمراعاة الدقّة. البعض في مجتمع دبيان يرى أن الاسم التقني يجب أن يعكس المساهمات الأصلية. تظهر هذه الصيغة كتعبير عن موقف أخلاقي أكثر منه تقني بحت.
21. الجدل حول تسمية النظام
لمّا أعلن ريتشارد ستالمان عن التعبير «جِنُو/لينكس»، بدأت تجزئة بين الدائرة التقنية. لم يمض وقت طويل قبل أن تستفحل الخلافات حول الاسم. منذ تلك اللحظة، ظل الجدل حيًّا داخل الندوات الإلكترونية وأماكن الحوار المهني. بعض المجموعات احتفظت بالتعبير كما هو. آخرون فضّلوه أن يكون خاليًا من أي دلالات جماعية. النقاش ما زال موجودًا، لكن بأسلوب أكثر هدوءًا الآن.
من منظور ستالمان، يُعدّ تجاهل إسهامات نظام الإدخال/الإخراج أمرًا مشوِّشًا للوقائع. عبر رؤيته، لا يمكن الفصل بين الأداء والاستقرار دون الاعتراف بالأساس الذي بُنِيَ عليه. بعض المراقبين يرون أن التسمية الموحّدة تحجب تعقيدات التطوير الطويل. في سياق آخر، قد يبدو التركيز على اسم واحد كأنه تهميش لجهود متراكمة. وجهة نظر المؤيدين تنبع من ملاحظة دقيقة حول كيفية عمل الأجزاء معاً. أحياناً يتم التعامل مع المساهمات غير المرئية وكأنها غير موجودة. من زاوية تقنية، التشغيل يتطلّب أكثر من مجرد النواة ليكون فعّالاً
من غير الدقيق وصف السيارة كلّها بالمحرّك وحده. يرى ستالمان أن تسمية النظام كاملاً بناءً على النواة - مثل لينكس - يحمل تشويشاً في المعنى. المكوّن الأساسي قد يكون محورياً. مع ذلك، لا يمكن له العمل بمعزل عن باقي الأجزاء المساعدة. تتطلّب العمليةُ اشتغالَ عناصر داعمة كالهيكل أو العجلات. هذه الوظائف تنجز عبر أدوات جنو، مثلاً. الاعتماد عليها ليس اختيارياً.
لم يكن حجم مساهمة نواة لينكس في الشيفرة المصدرية كبيرًا خلال الإصدارات الأولانية بالمقارنة مع ما قدمه مشروع جنو. بدلاً من ذلك، تفوّق المشروع الأخير بوضوح في عدد الأسطر المتاحة آنذاك. على الرغم من ذلك، لم يبدأ التوازن بالتغير إلا بعد سنوات قليلة. منذ البداية، اعتمد التوزيع التقني على عناصر متباينة لا تتشابه في الأصل ولا في الطريقة. رغم هذا التنوع، ظل جزء جنو هو الغالب في التركيبة العامة.
من زاوية فكرية، ما يخشاه ستالمان حقًا هو ضياع مفهوم "الحرية" من الذهن الجماعي. عندما يُنطق باسم "لينكس"، يرتبط النظام بأحد الأفراد – لينوس تورفالدس – الذي لا يولِ أولوية للقيم المرتبطة بالبرمجيات المفتوحة، إنما يعمل وفق معطيات الأداء. بينما استخدام اسم "جنو" يحمل في طياته إشارة مستمرة إلى البعد الأخلاقي في التعامل مع البرمجيات.
من جهة، هناك من يعتبر أن التمسك بالصيغة الكاملة مجرد نقاش لا طائل منه. في المقابل، يُنظر إلى هذا الإلحاح أحيانًا كمجرد علامة على الجدل العقيم. بعض الأطراف تراه تفصيلًا هامشيًّا لا يستحق كل هذا السجال. أما بالنسبة للعديد من الشركات، فالاستخدام البسيط اسمه كافي. قد يبدو الأمر تحفظًا شكليًّا، لكنه في الجوهر خلاف حول الكفاءة. غالبًا ما يتم التعامل مع المسألة باعتبارها إشكالية تقنية أكثر منها سياسية
تُلفَظ "لينكس" ببساطة، كونها اسمًا مختصرًا وواضح الصوت. من ناحية أخرى، يصعب نطق "جنو/لينكس" أثناء الحديث العادي. الكلمة القصيرة تسير بسلاسة في الحوار. بينما تتسبب التعابير الطويلة في تعثّر غير متوقع أحيانًا. يُفضل الاسم البسيط عند التحدث دون تحضير. في الجمل المنطوقة، الخفة مهمة أكثر مما يبدو.
في الحقيقة، الاسم موجود منذ فترة طويلة. من الطبيعي أن يرتبط به الجمهور تدريجيًا. التفكير في استبداله اليوم يبدو غير عملي إلى حد ما. مجرد محاولة التبديل قد لا تؤتي أي نتيجة فعلية.
في إحدى المرات، أبدى لينوس تعليقًا بنبرة ساخرة خفيفة. رغم أنه لم يعترض على التسمية المزدوجة، ظل موقفه واضحًا من الناحية العملية. اختياره الشخصي كان ولا يزال استخدام اسم «لينكس» فقط. الطريقة التي عبّر بها كانت محايدة لكنها حاسمة في الوقت نفسه. اللافت أن لهجة الحديث لم تكن جادة تمامًا، بل اقتربت من السخرية الهادئة دون وقوعه في الجفاء.
من غير المقبول أن تُدمج الأسماء بشكل عشوائي. اسم مثل "ليجنوكس" ظهر ذات مرة كحل وسط، لم يدم طويلاً أمام ردود فعل سلبية. الصيغة الجديدة بدت متكلفة بعض الشيء عند النطق. القبول بها كان ضعيفاً منذ البداية. شكل الكلمة أثار استغراب الكثيرين. لم يكن هناك مجال للجدل بعد انتشار السخرية.
لم يُكتب لها سوى أن تصل إلى حالة من التوقف الضمني
رسمياً وتقنياً (في أوساط Debian و FSF): يتم استخدام GNU/Linux.
شعبياً وتجارياً (في الإعلام والشركات): يكتفون بـ Linux.
من غير المعتاد أن يُجمع كل الأطراف صراحة، لكن الإقرار الضمني قائم بغض النظر عن أسماء التصنيفات. النظامَ لا يمكن فصله عن الاندماج بين المسارين، مهما تعددت الصيغ التعبيرية.
