يجعل المصدر المفتوح عالم التكنولوجيا يدور، حيث يشكل ما يصل إلى 90% من بنية البرمجيات الحديثة عبر الأطر؛ المكتبات؛ قواعد البيانات؛ أنظمة التشغيل؛ وعدد لا يحصى من التطبيقات المستقلة.
فوائد البرمجيات مفتوحة المصدر مفهومة جيدًا، حيث تعد بتحكم أكبر وشفافية. ومع ذلك، هناك صراع دائم بين عالم المصدر المفتوح والعالم الاحتكاري، مما دفع العديد من الشركات إلى التراجع عن المصدر المفتوح لحماية مصالحها التجارية. في قلب كل هذا تكمن قضية الترخيص الشائكة.
هناك نوعان رئيسيان من التراخيص التي تلبي تعريف المصدر المفتوح الرسمي كما حددته مبادرة المصدر المفتوح (OSI). التراخيص “المتساهلة” تحمل قيودًا قليلة من حيث كيفية تعديل المستخدمين وتوزيع البرمجيات، مما يجعلها شائعة لدى الشركات التي ترغب في استخدامها تجاريًا. ثم هناك تراخيص “كوبي ليفت”، التي تقدم حريات مماثلة ولكن مع تحذير واحد ملحوظ: يجب توزيع أي نسخة معدلة من البرمجيات تحت نفس ترخيص الكوبي ليفت الأصلي. هذا ليس جذابًا للشركات التي ترغب في حماية أعمالها الاحتكارية.
ولكن هناك أكثر من ذلك، حيث توجد تراخيص مختلفة ضمن كل فئة. علاوة على ذلك، هناك عدد لا يحصى من التراخيص التي، على الرغم من أنها ليست مفتوحة المصدر بشكل صارم، إلا أنها تستحق المعرفة.
التراخيص المتساهلة
ترخيص MIT
نشأ ترخيص MIT في معهد ماساتشوستس للتكنولوجيا في الثمانينيات، ويحتل الترخيص المسمى بشكل مناسب MIT المرتبة الأولى كأكثر ترخيص مفتوح المصدر شعبية وفقًا لمعظم المقاييس، حيث يجلس في المركز الأول بين مجتمع تطوير GitHub لـ سنوات عديدة.
يستخدم هذا الترخيص في مشاريع مثل React (مكتبة جافا سكريبت للواجهة الأمامية) و Ruby (لغة برمجة عامة)، ويسمح ترخيص MIT للمطورين باستخدام البرمجيات كما يحلو لهم. كما هو الحال مع معظم هذه التراخيص، يتم توفيرها دون ضمانات، مما يعني أن المؤلفين معفيون من أي مسؤولية ناتجة عن الأضرار التي تسببها برمجياتهم (مثل فقدان البيانات). كل ما يحتاج المطورون إلى الاهتمام به هو تضمين إشعار حقوق النشر الأصلي وترخيص MIT في أي عمل مشتق.
ولكن ترخيص MIT له عيب واحد: فهو لا يمنح حقوق براءات الاختراع بشكل صريح. هذا يعني أنه إذا كانت قطعة معينة من البرمجيات تعتمد على تقنية محمية ببراءة اختراع، فقد يخلق ذلك عدم يقين قانوني للمطورين الذين ينشرون البرمجيات دون تأمين أذونات منفصلة لتلك التقنية المحمية ببراءة اختراع.
ومع ذلك، فإن هذا يؤكد أحد النقاط البارزة في ترخيص MIT: مع 200 كلمة فقط، فإن اللغة بسيطة وموجزة. تعقيد الأمور بنصوص براءات الاختراع الغامضة سيضيف تعقيدًا لا داعي له للمشاريع التي من غير المرجح أن تهتم ببراءات الاختراع، مثل لغات البرمجة عالية المستوى أو أطر الويب.
ولكن العديد من مشاريع المصدر المفتوح تتقاطع مع التقنيات المحمية ببراءات الاختراع، مثل البرمجيات المركزية على الأجهزة مثل Android.
ترخيص Apache 2.0
نشرت مؤسسة Apache Software Foundation ترخيص Apache 2.0 في عام 2004، وهو تحديث لترخيص سابق مع منح صريح لبراءات الاختراع لحماية المستخدمين من التقاضي. لذا، إذا قام مطور، على سبيل المثال، بمساهمة خوارزمية معالجة صور فريدة في مشروع مرخص تحت Apache 2.0، فإن أي براءات اختراع يحتفظ بها ذلك المطور على تلك الخوارزمية يتم ترخيصها تلقائيًا لجميع مستخدمي البرمجيات.
معظم الناس سيكونون على دراية بعلامة Android التجارية من Google، المليئة بمتجر التطبيقات ومجموعة من الأدوات والخدمات المطورة داخليًا. ولكن مشروع Android Open Source Project (AOSP) الأساسي متاح بشكل أساسي تحت ترخيص Apache 2.0، وهو خطوة متعمدة من Google في عام 2008 لمحاربة Apple وتشجيع مصنعي الهواتف على استخدام Android مقابل المنافسين الاحتكاريين الآخرين (مثل Symbian) في ذلك الوقت. وقد نجح ذلك. حيث قفزت Samsung وHTC وLG وغيرها على Android.
نتيجة لذلك، يحتوي ترخيص Apache 2.0 على حوالي خمسة أضعاف عدد الكلمات مقارنة بترخيص MIT، وذلك بسبب نص منح براءات الاختراع، بالإضافة إلى إضافات وتوضيحات أخرى. ولكن هذه هي المقايضة، وهي توضح الفروق الرئيسية بين ترخيصي المصدر المفتوح المتساهلين الأكثر شيوعًا.
تراخيص متساهلة أخرى
ترخيص BSD 2-Clause مشابه لترخيص MIT، ولكن مع اختلافات رئيسية من حيث اللغة المستخدمة. على سبيل المثال، يحدد أنه يجب تضمين نسخة من الترخيص مع كل من الكود المصدري والشكل الثنائي المترجم. ثم هناك ترخيص BSD 3-Clause، الذي يحتوي على بند إضافي “عدم الترويج” يحدد استخدام أسماء أصحاب حقوق النشر والمساهمين لأغراض ترويجية في أي مشروع مشتق.
هناك أيضًا ترخيص MIT بدون نسب (MIT-0)، وهو أبسط من ترخيص MIT، حيث لا يوجد شرط للنسب في البرمجيات المشتقة. استخدام هذا قريب من وضع البرمجيات في المجال العام، إلا أن المؤلف يحتفظ بحقوق النشر والقدرة على تغيير الأشياء في المستقبل.
كوبي ليفت
ترخيص GNU العام العام (GPL) الإصدار 2.0 و3.0
نشرت مؤسسة البرمجيات الحرة (FSF) ترخيص GNU العام العام (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 لينوس تورفالدز يعارض بعض الأحكام المضافة في الإصدار 3.0 من الترخيص — بما في ذلك بند Tivoization.
ترخيص GNU Affero العام العام (AGPL) 3.0
ترخيص Affero العام العام (AGPL) مشابه لترخيص GPL 3.0، حيث إنه ترخيص “قوي” للكوبي ليفت يعزز حريات البرمجيات ويضمن أن تظل الإصدارات المعدلة مفتوحة المصدر. ومع ذلك، فإن الفرق الرئيسي مع AGPL هو أنه يركز على الخدمات والتطبيقات القائمة على الويب، حيث يتم تشغيل البرمجيات من الخوادم بدلاً من توزيعها كملفات تنفيذية.
تحت ترخيص GPL 3.0، لا يطلب من المطورين إصدار الكود المصدري للبرمجيات المعدلة إذا تم تشغيلها عبر شبكة، كما هو الحال مع تطبيقات SaaS. يغلق ترخيص AGPL هذه الثغرة، ويطلب من الأطراف الثالثة جعل الكود المصدري متاحًا حتى إذا كانت البرمجيات المعدلة تعمل فقط من خادم.
تم نشر ترخيص AGPL 3.0 في عام 2007 من قبل مؤسسة البرمجيات الحرة، وقد ازدادت شعبيته إلى حد كبير بسبب صعود الحوسبة السحابية وSaaS، واليوم هو خامس أكثر ترخيص مفتوح المصدر شعبية.
ترخيص GNU الأقل عمومية العام (LGPL)
أيضًا من إنتاج مؤسسة البرمجيات الحرة، فإن ترخيص GNU الأقل عمومية العام (LGPL) هو ترخيص “ضعيف” للكوبي ليفت، حيث إنه أكثر ملاءمة للأعمال مع شروط أقل صرامة على ما يتم مشاركته. عادةً ما يستخدم LGPL لمكتبات البرمجيات حيث يرغب مؤلفو المشروع في تشجيع المساهمات من المجتمع، ولكنه يسمح للبرمجيات الاحتكارية بالارتباط بالمكتبات دون الحاجة إلى جعل كودها الاحتكاري بالكامل مفتوح المصدر. إذا قام شخص ما بتعديل مكتبة المصدر المفتوح نفسها، فإنه يحتاج فقط إلى إصدار تلك التعديلات تحت ترخيص LGPL.
ترخيص Mozilla العام 2.0
نشرت مؤسسة Mozilla ترخيص Mozilla العام (MPL) 2.0 في عام 2012، وهو اليوم عاشر أكثر ترخيص مفتوح المصدر شعبية وفقًا لمقاييس تراخيص GitHub. MPL هو أيضًا ترخيص كوبي ليفت ضعيف مصمم لحماية الكود الاحتكاري مع تمكين المطورين من الاستفادة من البرمجيات مفتوحة المصدر.
ومع ذلك، بينما يركز LGPL على مستوى المكتبة، وGPL على مستوى المشروع، يعمل MPL على مستوى الملف الفردي مما يتطلب من المستخدم مشاركة مجموعة أضيق من الكود.
المجال العام وCreative Commons
بينما يمنح “ترخيص المصدر المفتوح” حقوقًا محددة، هناك دائمًا شروط مرفقة. أولئك الذين يرغبون في وضع برمجياتهم بالكامل في المجال العام دون أي قيود، يمكنهم القيام بذلك من خلال وسائل أخرى.
ليس كافيًا مجرد نشر البرمجيات بدون ترخيص؛ حيث ينطبق قانون حقوق النشر افتراضيًا على معظم الأعمال الإبداعية، بما في ذلك البرمجيات. هذا هو المكان الذي يمكن أن يساعد فيه “التفاني في المجال العام”.
صمم خصيصًا للبرمجيات، Unlicense هو تاسع أكثر ترخيص شعبية على GitHub (على الرغم من أنه يمكن أن يسمى “ترخيص” هو أمر قابل للنقاش). على الرغم من أن OSI وافقت عليه كترخيص في عام 2020، إلا أنها لاحظت أن الوثيقة “مصاغة بشكل سيء” وتساءلت عن فعاليتها القانونية في الولايات القضائية (مثل ألمانيا) حيث لا يمكن التبرع بالعمل للمجال العام.
مثل Unlicense، فإن CC0-1.0 من Creative Commons هو أيضًا أداة تفاني في المجال العام، على الرغم من أنها تركز بشكل أوسع على الأعمال الإبداعية. تستخدم لغة قانونية أكثر وضوحًا واحترافية قد تكون أكثر انسجامًا مع القانون الدولي. من الجدير بالذكر أن Creative Commons تقدمت بطلب للحصول على موافقة على CC0-1.0 كترخيص متوافق مع المصدر المفتوح في عام 2012، ولكن سحبت الطلب بعد أن أثارت OSI مخاوف من أنه يستثني صراحة منح براءات الاختراع.
هناك أدوات تفاني أخرى في المجال العام، مثل Zero-Clause BSD، والتي قد تكون جذابة لأنها تستخدم لغة أبسط. ومع ذلك، لا يوجد إجماع على أفضل آلية للتخلي عن جميع الحقوق في قطعة معينة من البرمجيات.
“المصدر المفتوح الزائف”
هناك عدد لا يحصى من نماذج الترخيص الأخرى عبر طيف البرمجيات.
في بعض الحالات، ستقوم الشركات بإصدار البرمجيات تحت نموذج ترخيص مزدوج، حيث يمكن للمستخدم الاختيار بين ترخيص مفتوح المصدر معترف به وترخيص تجاري، اعتمادًا على نواياهم. ثم هناك “النواة المفتوحة”، التي تقدم البرمجيات تحت ترخيص مفتوح المصدر، ولكن مع ميزات رئيسية محمية بدفع. في حالات أخرى، قد تضيف شركة Commons Clause إضافة إلى ترخيص مفتوح المصدر المتساهل، مما يضع قيودًا تجارية.
هناك أيضًا العديد من التراخيص التي تبدو وتشبه المصدر المفتوح، ولكنها في النهاية غير متوافقة مع تعريف المصدر المفتوح.
في عام 2018، انتقلت عملاق قواعد البيانات MongoDB من ترخيص كوبي ليفت AGPL إلى ترخيص الخادم العام (SSPL)، وهو ترخيص من إنشاء MongoDB. بينما لا يزال SSPL “مفتوحًا” إلى حد ما، إلا أنه يعتبر “مصدرًا متاحًا”، حيث يكون الكود قابلًا للوصول ولكن به قيود تجارية كبيرة، وهو أمر غير مقبول بالنسبة لـ OSI.
سلك أشخاص MariaDB مسارًا مشابهًا مع ترخيص المصدر التجاري (BUSL)، الذي يفرض قيودًا تجارية قبل الانتقال إلى ترخيص مفتوح المصدر حقيقي بعد عدد محدد من السنوات. هناك أيضًا حركة مماثلة جارية تسعى لجعل “ترخيص المصدر العادل” أمرًا واقعًا. وهذا يشمل ترخيص المصدر الوظيفي، الذي يتم الترويج له كبديل أبسط لـ BUSL.
قد تصادف أيضًا ما يسمى بتراخيص “المصدر الأخلاقي” من وقت لآخر، مثل ترخيص Hippocratic، الذي يمنع استخدام البرمجيات في انتهاك لحقوق الإنسان المعترف بها دوليًا. وبالمثل، فإن تنسيق الملف JSON المفتوح لديه ترخيص متساهل للغاية، باستثناء بند واحد مضحك في النهاية: “يجب استخدام البرمجيات للخير، وليس للشر“.
