لماذا يجب أن تكون البرمجيات حرة؟

مقالة بقلم ريتشارد ستالمن

مقدمة

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

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

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

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

في هذا المقال، سوف أقدم وصفاً للآثار الناجمة عن وجود مالكي البرامج وعرض النتائج الضارة المترتبة عن ذلك. استنتاجي هو أن من واجب المبرمجين تشجيع الآخرين على تشارك، توزيع، دراسة وتحسين البرمجيات التي نكتبها. أو بعبارة أخرى، كتابة البرمجيات ”الحرة“.(1)

كيف يبرر المالكون سلطتهم؟

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

الحجة العاطفية تصاغ كما يلي: ”لقد وضعت عرقي وقلبي وروحي في هذا البرنامج, لقد نبع هذا البرنامج من داخلي، إنه لي!“

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

أما الحجة الإقتصادية، فإنها تصاغ كما يلي: ”أريد ان أصبح غنياً (عادة ما يوصف هذا المفهوم بشكل غير دقيق من خلال اعتباره ’كسباً للعيش‘ )، وإذا لم تسمح لي بالوصول للثراء عبر البرمجة فإنني لن أبرمج. وبما أن الجميع مثلي، فإنك لن تجد أحداً يبرمج، ولن تجد أي برنامج على الإطلاق! عادة ما يكون هذا التهديد بمثابة نصيحة ودية من صديق حكيم.

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

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

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

الحجة ضد وجوب وجود مالكين

السؤال المطروح هو : ”هل يجب أن يكون تطوير البرمجيات مرتبطاً بمالك يقيد استخدامها؟“

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

بعبارة أخرى، إذا كان تقييد توزيع البرنامج ضاراً للمجتمع ككل, فإن المبرمج الأخلاقي ملزم بالامتناع عن المساهمة في هذا التقييد.

لتحديد الأثر الناجم عن تقييد التشارك، يجب أن نقارن قيمة البرنامج المقيد (الاحتكاري) بالنسبة للمجتمع مع قيمته عنما يكون متاحاً للجميع, وهذا يعني المقارنة بين عالمين ممكنين.

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

لتوضيح هذه الحجة، دعونا نطبقها في مجال آخر: ألا وهو شق الطرق.

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

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

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

بطبيعة الحال, فإن إنشاء الطرق المجانية أمر له تكلفته المادية، والتي يتحملها المجتمع بشكل معين. ومع ذلك, فإن هذا لا يعني حتمية مقصورات اﻷداء. نحن الذين نتحمل مصاريف شق الطرقات بشتى أنواعها نستفيد بشكل أكبر من الطرق المجانية.

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

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

الضرر المترتب عن عرقلة البرامج

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

إن فرض قيود على توزيع وتعديل البرامج لا يسهل استخدامها، بل يتعارض معه، حيث يكون التأثير سلبياً بشكل حتمي. و لكن، كم هو حجم هذا التأثير؟ وما نوعه؟

هناك ثلاث مستويات مختلفة من الضرر المادي الناتج عن هذا التقييد:

• عدد أقل من المستخدمين.
• استحالة تكييف أو إصلاح البرنامج من قبل المستخدمين.
• عدم تمكن المطورين الآخرين من التعلم من البرنامج, أو الارتكاز عليه لإنجاز عمل جديد.

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

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

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

عرقلة استخدام البرامج

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

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

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

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

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

لكن فرض سعر على شيء من الممكن أن يكون مجانياً هو تغيير نوعي. فالرسوم المركزية المفروضة على توزيع البرمجيات ستصبح عقبة قوية أمامها.

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

الضرر بالتماسك الإجتماعي

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

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

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

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

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

عرقلة المواءمة الشخصية للبرامج

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

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

عادة ما يستخدم المبرمجون ”الكود المصدري“ للبرنامج الذي يكون مكتوباً بلغة برمجة معينة مثل فورتران أو سي. يستخدم الكود المصدري أسماء محددة للدلالة على البيانات المستخدمة والأجزاء المكونة للبرنامج، وتُمثّل العمليات بواسطة رموز مثل ‘+’ للجمع و‘–’ للطرح. وهو مصمم لمساعدة المبرمجين على قراءة البرمجيات وتعديلها. فيما يلي مثال لبرنامج يحسب المسافة بين نقطتين في طائرة:

     float
     distance (p0, p1)
          struct point p0, p1;
     {
       float xdist = p1.x - p0.x;
       float ydist = p1.y - p0.y;
       return sqrt (xdist * xdist + ydist * ydist);
     }

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

     1314258944      -232267772      -231844864      1634862
     1411907592      -231844736      2159150         1420296208
     -234880989      -234879837      -234879966      -232295424
     1644167167      -3214848        1090581031      1962942495
     572518958       -803143692      1314803317

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

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

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

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

كان بإمكان المبرمجين في مختبر الذكاء الاصطناعي إصلاح هذه الأعطاب. ومن المحتمل أنهم كانوا قادرين على القيام بذلك تماماً كما لو قام بذلك المطورون اﻷصليون للبرنامج. لكن شركة Xerox لم تكن مهتمة بإصلاحها، كما اختارت الحيلولة دون قيامنا بذلك، مما أجبرنا على قبول هذا اﻷعطاب التي لم تصلح أبداً.

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

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

تخيل ما سيكون عليه اﻷمر إذا طبقنا ما يجري على البرامج على وجبات الطعام. قد تتساءل: ”كيف يمكن تغيير وجبة الطعام هذه لتكون من دون ملح؟“ وكبير الطباخين سيرد عليك: ”كيف تجرؤ على إهانة وجبتي، هذه الوجبة نتاج تفكيري وذوقي، وأنت تحاول العبث بها؟ ليس لديك الحق في الحكم على وجبتي وجعلها تعمل بشكل صحيح!“

ستضيف: ”لكن طبيبي يقول أنه ليس من المفترض أن آكل الملح! ما الذي يمكنني عمله؟ هل يمكنني تحضيرها دون ملح؟“

سيرد كبير الطباخين: ”سيسعدني القيام بذلك، لن يكلفك اﻷمر إلا 50000$“ طالما احتكر المالك التغيير، فإن الأجر يميل لأن يكون كبيراً. ”لكن، ليس لدي وقت اﻵن. إنني مشغول مع لجنة لتصميم وصفة بسكويت جديدة للسفن التابعة للخطوط البحرية. قد أستطيع القيام بذلك بعد حوالي عامين.“

عرقلة تطوير البرمجيات

المستوى الثالث من الضرر المادي يؤثر على تطوير البرمجيات. لقد كان تطوير البرمجيات بمثابة عملية ثورية، حيث كان بإمكان شخص ما أن يأخذ برنامجاً موجوداً و إعادة كتابة أجزاء منه لإضافة ميزة جديدة, ثم يأتي شخص آخر بعده لإعادة كتابة أجزاء معينة وإضافة ميزة أخرى. في بعض الحالات، قد تستغرق عملية كهذه 20 سنة. في غضون ذلك، قد تفكك بعض ”أجزاء“ البرامج لتكون إنطلاقة لبرامج أخرى.

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

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

في أي مجال فكري، يمكن للمرء أن يصل الى مستويات أعلى من خلال الاعتماد على مجهودات السابقين. لكن هذا الأمر لم يعد ممكناً بشكل عام في مجال البرمجيات—لا يمكنك الاعتماد إلا على أناس آخرين داخل شركتك الخاصة.

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

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

لا يهم كيف يتم تقييد التشارك

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

يعتبر المستخدمون بعض هذه الأساليب أبغض من غيرها. في اعتقادي، فإن أبغض الاساليب هي تلك التي تحقق هدفها.

يجب أن تكون البرمجيات حرة

لقد أوضحت أن ملكية البرمجيات—السلطة لتقييد التعديل و النسخ—تعتبر حاجزاً تمتد آثاره السلبية على نطاق واسع و مهم. و بناء على ذلك، ينبغي للبرمجيات أن تكون من دون مالك.

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

فاكفال هافل نصحنا ”بأن نعمل من أجل أشياء معينة ﻷنها جيدة، وليس فقط ﻷنها قد تتوفر على فرصة للنجاح“ إن تطوير البرمجيات الاحتكارية أمامه فرصة للنجاح ضمن شروط ضيقة، لكنه ليس الأمر الجيد للمجتمع.

لماذا يطور الناس البرمجيات

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

البرمجة متعة

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

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

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

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

”كيف يمكننا تسديد أجر المبرمجين؟“، تسهل الإجابة على هذا السؤال عندما ندرك بأن اﻷمر لا يتعلق بمنحهم ثروة مقابل ذلك، بل بتوفير سبل كسب العيش لهم.

تمويل البرمجيات الحرة

المؤسسات التي تدفع أجوراً للمبرمجين ليست بالضرورة شركات لتطوير البرمجيات. هناك العديد من المؤسسات الأخرى التي يمكنها القيام بذلك.

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

تدير الجامعات العديد من المشاريع المعنية بالبرمجة وتبيع الكثير من نتاجها في الوقت الحالي، لكن اﻷمر لم يكن كذلك في سبعينيات القرن الماضي. هل هناك من شك في أن الجامعات ستطور برمجيات حرة إذا لم يسمح لها ببيع البرامج؟ يمكن دعم هذه المشاريع من قبل الحكومة نفسها التي تمنح العقود التي تدعم تطوير البرامج الاحتكارية.

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

يمكن للمبرمجين كتابة البرمجيات الحرة وكسب رزقهم عن طريق بيع الخدمات المرتبطة بالبرمجيات. لقد تم التعاقد معي لحمل مصرف GNU C إلى الأجهزة الجديدة، وتطوير واجهة استخدام لملحقات GNU Emacs. (أقدم هذه التحسينات للجمهور كلما أكملتها). كما أنني أمارس التدريس وأتلقى أجراً مقابل ذلك.

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

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

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

بما أن المؤسسة مؤسسة خيرية، فإن المبرمجين يعملون داخلها بنصف ما يمكن أن يتلقونه في مكان آخر. إنهم يفعلون ذلك لأن المؤسسة ليست بيروقراطية، ولأنهم يشعرون بالرضى، ذلك أن عملهم لن يخضع للمنع أو التقييد فيما بعد. أهم ما في اﻷمر أنهم يقومون بذلك لأن البرمجة نشاط ممتع. بالإضافة إلى ذلك، فقد كتب المتطوعون العديد من البرامج المفيدة لنا. (وحتى الكتاب التقنيون بدؤوا بالتطوع).

هذا يؤكد أن البرمجة تعد من أكثر اﻷنشطة إبهاراً في جميع الميادين، جنباً إلى جنب مع الموسيقى والفنون. ليس لدينا تخوف من عدم رغبة اﻵخرين في البرمجة.

ما الذي يدين به المستخدمون للمطورين؟

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

لكن هذا لا ينطبق على مطوري البرمجيات الاحتكارية، ذلك أن العرقلة تستحق العقاب بدل المكافأة.

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

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

ما هي إنتاجية البرامج؟

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

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

• الاستخدام الواسع لكل برنامج يتم تطويره.
• القدرة على تكييف البرامج بدل من البدء من نقطة الصفر.
• توفر تعليم أفضل للمبرمجين.
• القضاء على تكرار جهود البرمجة.

هؤلاء الذين يعارضون التعاون ويزعمون أن ذلك سيؤدي إلى توظيف عدد أقل من المبرمجين يتعارضون في حقيقة اﻷمر مع زيادة الإنتاجية. لكن نفس اﻷشخاص يقبلون الاعتقاد السائد بأن صناعة البرمجيات بحاجة لزيادة الانتاجية, كيف هذا؟

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

هل التنافس حتمي؟

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

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

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

تصبح المنافسة قتالية عندما يشرع المنافسين في عرقلة بعضهم البعض بدل تطوير أنفسهم—عندما نعوض مقولة ”دعوا الأفضل يفوز“ بمقولة ”اسمحوا لي بالفوز، سواء كنت الأفضل أو لا“. البرمجيات الاحتكارية ضارة، ليس لأنها شكل من أشكال المنافسة، وإنما لأنها شكل من أشكال الاقتتال بين المواطنين في مجتمعنا.

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

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

”لماذا لاترحلون الى روسيا؟”

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

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

النظام الأمريكي لحقوق مؤلفي البرمجيات يمارس سيطرة مركزية على توزيع البرمجيات، و يحرس معدات النسخ بواسطة مخططات حماية أوتوماتيكية لمنع النسخ الغير قانوني.

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

وبالتالي، إذا أردنا أن نحكم على وجهات النظر من حيث تشابهها مع الشيوعية السوفياتية، فإن مالكي البرمجيات هم الشيوعيون.

مسألة المسلّمات

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

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

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

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

من المهم أن يعرف هؤلاء الناس أن هذه الفرضية ليست جزءاً من التقاليد القانونية, وأنها لم تكن كذلك قط.

وهكذا, فإن الدستور ينص على أن الغرض من حقوق الملكية الفكرية هو ”تشجيع تطور العلوم و الفنون المفيدة“، والمحكمة العليا بلورت ذلك، وصرحت في قضية Fox Film v. Doyal بأن ”مصلحة الولايات المتحدة والهدف الأساسي من منح احتكار [حقوق الطبع] يتمثلان في الفوائد العامة التي تعود بها أعمال المؤلفين على الجمهور“.

لسنا مجبرين على الاتفاق مع ما يقوله الدستور أو المحكمة العليا (كلاهما تغاضيا عن العبودية في حقبة من الحقبات). وفي هذا السياق، فإن موقفهما لا يتعارض مع الفرضية القائمة على هيمنة المالك. لكنني أتمنى أن هذه الفرضية ستفقد بريقها عندما سيدرك الناس بأن اﻷمر لا يتعلق بفرضية تقليدية معترف بها، بل بفرضية تعكس موقف اليمين المتطرف.

استنتاج

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

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

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

هوامش

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

---

نُشرت هذه المقالة في برمجيات حرة، مجتمع حر: مقالات مختارة بقلم ريتشارد ستولمن.