دليل المطور لتراخيص مفتوحة المصدر

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

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

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

المصدر المفتوح أم البرمجيات الحرة؟

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

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

الخصائص العامة للبرامج مفتوحة المصدر

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

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

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

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

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

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

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

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

هناك نوعان من الحقوق المتروكة حسب قوتها:

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

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

سماح

حسب السماح ، يمكن أيضًا تصنيف التراخيص في:

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

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

اختلافات تراخيص مفتوحة المصدر

توجد العديد من التراخيص مفتوحة المصدر. وقد وافقت مبادرة المصدر المفتوح بالفعل على أكثر من 80 منها. بعضها زائدة عن الحاجة ويمكن اعتبارها معادلة لغيرها. البعض الآخر خاص بمصالح ناشر البرنامج (مثل ترخيص NASA) ، أو لبيئة أو غرض معين (مثل ترخيص المجتمع التعليمي ، أو ترخيص Open Font).

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

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

مشكلة خلط كود مع تراخيص مختلفة

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

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

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

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

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

الميزات التفاضلية لتراخيص البرامج مفتوحة المصدر

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

رخصة جنو العمومية العامة (جي بي إل)

GPL هي أشهر ترخيص مفتوح المصدر. تم إنشاؤه بواسطة FSF كترخيص لمشروع GNU ، وهو أيضًا ترخيص Linux kernel.

خصائصها التفاضلية:

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

عادة ، يتضمن نص الترخيص المستخدم النص الذي يفيد بأن البرنامج موزع بموجب شروط إصدار GPL N (أو أي إصدار لاحق).

يوجد حاليًا إصداران من ترخيص GPL قيد الاستخدام: v2 و v3. تم إصدار الإصدار 3 في عام 2007 لمعالجة بعض المشاكل التي ظهرت منذ إصدار الإصدار 2 في عام 1991.

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

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

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

هذا الترخيص شائع جدًا ، ويستخدمه العديد من المشاريع مثل نظام X Window أو Ruby on Rails أو jQuery أو Node.js.

إنه متوافق مع GPL ، لذا يمكنك دمج التعليمات البرمجية المرخصة من MIT في برنامج GPL.

رخصة أباتشي 2.0

تم إنشاء ترخيص Apache بواسطة Apache Software Foundation (ASF) كترخيص لخادم Apache HTTP الخاص بها.

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

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

هذا الترخيص مثير للاهتمام بسبب ترخيص براءة الاختراع التلقائي ، والبند الخاص بتقديم المساهمة.

إنه متوافق مع GPL ، لذا يمكنك دمج كود Apache المرخص في برنامج GPL.

رخصة بي إس دي

هناك 3 رخص مختلفة BSD. كلهم تراخيص متساهلة للغاية بدون حقوق متروكة.

رخصة BSD المكونة من فقرتين (أو رخصة BSD المبسطة) تعادل تمامًا رخصة MIT التي تم شرحها من قبل.

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

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

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

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

يمكنك ربط كود مغلق المصدر بمكتبة أو برنامج LGPL وتوزيع النتائج النهائية طالما:

• أنت تقدم الكود المصدري لجزء LGPLed ، مع كل التعديلات التي أجريتها عليه.
• أي مستخدم لديه معرفة كافية قادر على استبدال جزء LGPLed من البرنامج بنسخة معدلة. يمكن القيام بذلك بتوزيع جزء LGPLed من البرنامج كمكتبة ديناميكية (DLL في Windows ، كذلك في Linux / Unix) ، أو توفير رمز كائن للجزء غير LGPLed من البرنامج.

يتوافق LGPL v3 مع GPLv3 ، لذا يمكنك إدخال رمز LGPLv3 في برنامج GPL.

رخصة فنية

الترخيص الفني ، في نسخته الحالية 2.0 ، هو ترخيص مفتوح المصدر بدون حقوق متروكة مماثلة لترخيص معهد ماساتشوستس للتكنولوجيا.

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

يتم استخدام هذا الترخيص بشكل حصري تقريبًا في مجتمع Perl.

الترخيص الفني الحالي 2.0 متوافق مع GPL: يمكنك مزج كود Artistic-Licensed في برنامج GPL.

رخصة مايكروسوفت العامة (MS-PL)

تم إنشاء الترخيص العام لـ Microsoft في عام 2008 بواسطة هذه الشركة كأحد تراخيص مفتوحة المصدر تم إنشاؤها بواسطة مبادرة المصدر المشترك.

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

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

MS-PL غير متوافق مع GPL.

رخصة Eclipse Public (EPL)

رخصة Eclipse Public License هي الترخيص الذي أنشأته Eclipse Foundation لبيئة التطوير المتكاملة الخاصة بهم. إنها رخصة حقوق متروكة مقيدة وضعيفة ، تشبه من نواح كثيرة LGPL. كما يتضمن بنودًا لمنح ترخيص براءات الاختراع تلقائيًا.

EPL غير متوافق مع GPL.

رخصة Mozilla العامة (MPL)

الإصدار 2.0 من رخصة Mozilla العامة هو ترخيص متساهل ومتروك الحقوق ضعيف أنشأته مؤسسة Mozilla لمنتجاتها.

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

MPL في نسخته الحالية 2.0 متوافق مع GPL. هذا ليس صحيحًا بالنسبة للإصدارات السابقة من MPL.

رخصة التطوير والتوزيع المشتركة (CDDL)

CDDL هو ترخيص متساهل ضعيف الحقوق تم إنشاؤه بواسطة Sun (الآن Oracle) استنادًا إلى الإصدار 1.1 من MPL. بشكل أساسي ، لها نفس خصائص MPL. تم توضيح شروطها ، ولكن لم يتم تغييرها بشكل جوهري.

CDDL هو ترخيص مفتوح المصدر تختاره Sun (الآن Oracle) للعديد من منتجاتها ، مثل OpenSolaris أو NetBeans ، من بين آخرين.

نظرًا لأن هذا الترخيص كان مستندًا إلى MPLv1.1 ، فإن هذا الترخيص غير متوافق مع GPL ، لذلك لا يمكنك دمج المصدر المرخص لـ CDDL مع برنامج مرخص لـ GPL. يقول الكثير من الناس أن هذا كان مقصودًا ، لذلك لا يمكن إدخال شفرة مصدر OpenSolaris في Linux kernel.

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

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

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

يتوافق AGPLv3 مع GPL3. يمكنك وضع كود AGPLv3 في كود GPLv3 ، طالما أن النتيجة النهائية مرخصة بموجب AGPLv3.

رخصة مركز الدراسات الدولي

ترخيص ISC هو ترخيص برمجيات مجاني مسموح به مكتوب بواسطة Internet Software Consortium (ISC). وهو يعادل وظيفيًا تراخيص BSD و MIT المكونة من فقرتين ، بعد إزالة بعض اللغة التي كانت تعتبر غير ضرورية.

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

إنه متوافق مع GPL: يمكنك مزج كود ISC المرخص في برنامج GPL.

ترخيص Microsoft المتبادل (MS-RL)

تم إنشاء ترخيص Microsoft Reciprocal في عام 2008 بواسطة هذه الشركة كأحد تراخيص مفتوحة المصدر تم إنشاؤها بواسطة مبادرة المصدر المشترك.

إنه مشابه لـ MS-PL الذي تم شرحه من قبل ، ولكنه يحتوي على حقوق متروكة أقوى قليلاً ، تشبه شروط LGPL و CDDL و EPL. يتطلب الأمر أنه إذا قمت بخلط التعليمات البرمجية الخاصة بك مع شفرة المصدر المرخصة من MS-RL وأردت توزيع النتائج النهائية ، فيجب أن يستمر ترخيص الجزء الأصلي المرخص من MS-RL بهذا الترخيص.

إنه غير متوافق مع GPL.

المجال العام (CC0)

وفقًا لـ Wikipedia ، "الأعمال الموجودة في المجال العام هي تلك التي انتهت حقوق ملكيتها الفكرية ، أو تمت مصادرتها ، أو أصبحت غير قابلة للتطبيق". بتكريس العمل للملك العام ، يتنازل المؤلف عن جميع حقوقه بموجب قانون حقوق النشر.

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

هناك العديد من الطرق لتخصيص جزء من البرنامج للملك العام. أنشأ المشاع الإبداعي CC0 Public Domain Dedication ، وهي طريقة عالمية للتخلي عن عمل في المجال العام. توصي FSF باستخدام هذا النص لتخصيص البرامج للملك العام.

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

تراخيص متعددة

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

هذه هي الحالة المعتادة لبعض المكتبات. على سبيل المثال ، NSS عبارة عن مكتبة أنشأتها Mozilla وتقوم بتنفيذ دعم SSL / TLS ، من بين الميزات الأخرى المتعلقة بالأمان. إنه مرخص ثلاثياً بموجب تراخيص MPL و GPL و LGPL.

من فضلك ، اختر رخصة

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

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

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

• إذا كنت تهتم بمشاركة التعديلات ولا تريد استخدام الرمز الخاص بك في التطويرات المغلقة (لا في منتجات البرامج المغلقة ولا في الأجهزة المغلقة) ، فاستخدم GPL v3.

  • إذا كنت لا تهتم بإمكانية استخدام برنامجك في جهاز مغلق ، فاستخدم GPL v2. ولكن من فضلك مع جملة "أو أي إصدار لاحق" ، لذلك يمكن أيضًا استخدام التعليمات البرمجية الخاصة بك في مشاريع GPLv3.
  • إذا كنت لا تهتم باحتمالية استخدام برنامجك في برنامج مغلق ، طالما أن برنامجك أو الجزء الذي يستخدمه يستمر في كونه مفتوح المصدر وفقًا للشروط نفسها ، فاستخدم LGPL v3.
  • إذا كنت تريد أن يكون لكل شخص يستخدم برنامجك عبر شبكة الحق في الحصول على كود المصدر الخاص به ، فاستخدم AGPL v3.

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