تراخيص مفتوحة المصدر: كل ما تحتاج إلى معرفته

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

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

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

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

متساهل

معهد ماساتشوستس للتكنولوجيا

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

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

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

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

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

ترخيص أباتشي 2.0

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

سيكون معظم الأشخاص على دراية بعلامة Google التجارية لنظام التشغيل Android، المليئة بمتجر التطبيقات ومجموعة الأدوات والخدمات المحلية. لكن مشروع Android مفتوح المصدر الأساسي (AOSP) متاح بشكل كبير بموجب ترخيص Apache 2.0، وهي خطوة متعمدة من قبل Google في عام 2008 لمكافحة Apple وتشجيع الشركات المصنعة للهواتف على استخدام Android مقابل الشركات الأخرى المملوكة (مثل Symbian) في ذلك الوقت. وقد نجحت. قفزت Samsung وHTC وLG وجميع الشركات الأخرى إلى Android.

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

التراخيص المسموح بها الأخرى

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

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

الحقوق المتروكة

رخصة جنو العامة (GPL) الإصدار 2.0 و3.0

نشرت مؤسسة البرمجيات الحرة (FSF) رخصة جنو العامة (GPL) في عام 1989، وكانت واحدة من أولى تراخيص الحقوق المتروكة للاستخدام العام.

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

تم إطلاق GPL 3.0 في عام 2007، وهو ثالث أكثر التراخيص شيوعًا، وفقًا لبيانات GitHub. أدى الترخيص إلى تحديثات ملحوظة على GPL 2.0، بما في ذلك أحكام منح براءات الاختراع وتحسين التوافق مع التراخيص الأخرى مفتوحة المصدر. كما أنه يحظر ما أصبح يعرف باسم “Tivoization”، حيث يمنع صانعو الأجهزة الذين يستفيدون من البرامج المرخصة بـ GPL المستخدمين من تثبيت إصدارات معدلة من ذلك البرنامج، باستخدام آليات إدارة الحقوق الرقمية (DRM).

من بين مستخدمي GPL البارزين WordPress، المتوفر بموجب ترخيص GPL 2.0 “أو الأحدث”، مما يترك الأمر للمطور ليقرر الترخيص الذي يوزع أي تعديل بموجبه.

يعد Linux، من جانبه، من بين أكثر المشاريع مفتوحة المصدر نجاحًا على الإطلاق، حيث يتم استخدامه في الخوادم والبنية التحتية السحابية والأنظمة المدمجة وحتى Android. ومع ذلك، فإن نواة Linux الأساسية متاحة فقط بموجب ترخيص GPL 2.0، نظرًا لأن منشئ Linux Linus Torvalds يعارض بعض الأحكام المضافة في الإصدار 3.0 من الترخيص – بما في ذلك شرط Tivoization.

رخصة جنو أفيرو العامة (AGPL) 3.0

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

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

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

رخصة جنو العامة الصغرى (LGPL)

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

رخصة موزيلا العامة 2.0

تعد رخصة موزيلا العامة (MPL) 2.0، التي نشرتها مؤسسة موزيلا في عام 2012، عاشر أكثر تراخيص المصادر المفتوحة شيوعًا اليوم وفقًا لمقياس تراخيص GitHub. يعد MPL أيضًا ترخيصًا ضعيفًا للحقوق المتروكة مصممًا لحماية كود الملكية مع تمكين المطورين من الاستفادة من البرامج مفتوحة المصدر.

ومع ذلك، بينما تركز LGPL على مستوى المكتبة، وGPL على مستوى المشروع، تعمل MPL على مستوى ملف فردي يتطلب من المستخدم مشاركة مجموعة أضيق من التعليمات البرمجية.

المجال العام والمشاعات الإبداعية

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

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

تم تصميم Unlicense خصيصًا للبرامج، وهو الترخيص التاسع الأكثر شيوعًا على GitHub (على الرغم من أن إمكانية تسميته بـ “الترخيص” أمر قابل للنقاش). على الرغم من أن OSI وافقت عليه كترخيص في عام 2020، فقد لاحظت أن الوثيقة “سيئة الصياغة” وشككت في فعاليتها القانونية في الولايات القضائية (مثل ألمانيا) حيث لا يمكن التبرع بالعمل للملك العام.

مثل Unlicense، تعد CC0-1.0 من Creative Commons أيضًا أداة تخصيص للملكية العامة، على الرغم من أنها تركز على نطاق أوسع على الأعمال الإبداعية. فهو يستخدم لغة قانونية أكثر وضوحًا واحترافية قد تكون أكثر انسجامًا مع القانون الدولي. تجدر الإشارة إلى أن منظمة المشاع الإبداعي تقدمت بطلب للحصول على الموافقة على CC0-1.0 باعتباره ترخيصًا متوافقًا مع المصدر المفتوح في عام 2012، لكنها سحبت الطلب بعد أن أثار OSI مخاوف من أنه يستبعد بشكل صريح منح براءات الاختراع.

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

مصدر “القلم الزائف”.

هناك عدد لا يحصى من نماذج الترخيص الأخرى عبر طيف البرامج.

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

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

في عام 2018، انتقلت عملاقة قواعد البيانات MongoDB من ترخيص الحقوق المتروكة AGPL إلى الترخيص العام من جانب الخادم (SSPL)، وهو ترخيص من إنشاء MongoDB. في حين أن SSPL لا يزال “مفتوحًا” إلى حد ما، فهو ما يُعرف باسم “المصدر المتاح”، حيث يمكن الوصول إلى الكود ولكن به قيود تجارية كبيرة، وهو أمر محظور كبير فيما يتعلق بـ OSI.

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

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