فهم الآثار القانونية للبرمجيات مفتوحة المصدر

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

لماذا يهتم الناس كثيراً حول الجانب القانوني للبرمجيات مفتوحة المصدر ؟

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

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

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

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

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

هل مشاريع GitHub العامة مفتوحة المصدر؟

عند إنشاء مشروع جديد على GitHub، لديك الخيار لجعل المستودع خاص أو عام.

إنشاء مستودع

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

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

فقط أعطني ملخصاً سريعاً عن ما أحتاجه لحماية مشروعي

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

MIT، Apache 2.0، و GPLv3 هي رخص مفتوحة المصدر شائعة، لكن هناك خيارات أخرى يمكن الاختيار منها. يمكنك العثور على النص الكامل لهذه الرخص، والتعليمات حول كيفية استخدامها، على choosealicense.com.

عند إنشاء مشروع جديد على GitHub، سيُطلب منك إضافة ترخيص.

أي ترخيص مفتوح المصدر مناسب لمشروعي؟

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

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

من المرجح أن يحتوي مشروعك (أو سيحتوي) على dependencies، كل منها سيكون له ترخيص مفتوح المصدر خاص به مع شروط عليك احترامها. على سبيل المثال، إذا كنت تفتح مصدر مشروع Node.js، فربما ستستخدم مكتبات من Node Package Manager (npm).

تسمح dependencies ذات permissive licenses مثل MIT، Apache 2.0، ISC، و BSD لك بترخيص مشروعك بالطريقة التي تريدها.

تتطلب dependencies ذات copyleft licenses اهتمامًا أكبر. تضمين أي مكتبة ذات ترخيص strong copyleft مثل GPLv2، GPLv3، أو AGPLv3 يتطلب منك اختيار ترخيص مطابق أو متوافق لمشروعك. أما المكتبات ذات الترخيص limited أو weak copyleft مثل MPL 2.0 و LGPL فيمكن تضمينها في مشاريع بأي ترخيص، بشرط الالتزام بـ القواعد الإضافية التي تحددها.

تتضمن dependencies ذات source-available licenses، مثل Business Source License BSL أو Server Side Public License SSPL، قيودًا على الاستخدام ونموذج العمل قد تجعلها تبدو كأنها تحت تراخيص مفتوحة المصدر، لكنها قد تمنع مشروعك من أن يُعتبر Open Source كما تحدده Open Source Initiative (OSI).

تعتمد المشاريع غالبًا على محتوى غير برمجي مثل الصور أو الأيقونات أو مقاطع الفيديو أو الخطوط أو ملفات البيانات أو مواد أخرى، والتي تخضع لتراخيصها الخاصة. وكما هو الحال مع تبعيات البرمجيات التقليدية، تتراوح تراخيص هذه المواد من تجارية إلى مرنة إلى كوبيلفت. أنشأت منظمة Creative Commons، وهي منظمة غير ربحية، سلسلة من التراخيص الشائعة للمحتوى غير البرمجي تتدرج من CC0 إلى CC-BY إلى CC-SA، ويمكنها أحيانًا تقييد الاستخدام التجاري بإضافة خيار (NC) إلى هذه التراخيص. قد ترغبين أيضًا في أخذ communities التي تأملين أن تستخدم مشروعك وتساهم فيه بعين الاعتبار.

  • هل تريد أن يُستخدم مشروعك كـ dependency من قبل مشاريع أخرى؟ من الأفضل على الأرجح استخدام الترخيص الأكثر شيوعًا في المجتمع ذي الصلة. على سبيل المثال، MIT هو الترخيص الأكثر شيوعًا لمكتبات npm.
  • هل تريد أن يجذب مشروعك الشركات الكبيرة؟ قد تشعر الشركة الكبيرة بالراحة عند وجود ترخيص براءة اختراع صريح من جميع المساهمين. في هذه الحالة، يغطيك Apache 2.0 (ويغطيهم أيضًا).
  • هل تريد أن يجذب مشروعك المساهمين الذين لا يرغبون في أن تُستخدم مساهماتهم في برامج مغلقة المصدر؟ سيكون GPLv3 أو (إذا لم يرغبوا أيضًا في المساهمة في خدمات مغلقة المصدر) AGPLv3 مناسبًا لهم.

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

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

ماذا لو أردت تغيير ترخيص مشروعي؟

معظم المشاريع لا تحتاج أبداً إلى تغيير التراخيص. لكن في بعض الأحيان تتغير الظروف

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

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

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

حاملو حقوق الطبع والنشر الحاليون لمشروعك. إذا كنت المساهم الوحيد في مشروعك، فإما أنت أو شركتك هو المالك الوحيد لحقوق الطبع والنشر للمشروع، ويمكنك إضافة أو تغيير الترخيص كما تشاء أنت أو شركتك. أما إذا كان هناك أصحاب حقوق نشر آخرون، فستحتاج إلى موافقتهم لتغيير الترخيص. من هم؟ الأشخاص الذين لديهم مساهمات (commits) في مشروعك مكان جيد للبدء، ولكن في بعض الحالات تكون حقوق النشر مملوكة لأصحاب عمل هؤلاء الأشخاص. في حالات أخرى، قد تكون مساهماتهم بسيطة، لكن لا توجد قاعدة صارمة تنص على أن المساهمات الصغيرة لا تخضع لحقوق الطبع والنشر. ماذا تفعل؟ يعتمد ذلك على حجم المشروع وعمره؛ فبالنسبة للمشاريع الصغيرة والحديثة نسبيًا، يمكن الحصول على موافقة جميع المساهمين الحاليين على تغيير الترخيص عبر issue أو pull request، أما المشاريع الكبيرة والمستمرة منذ فترة طويلة، فقد تحتاج إلى التواصل مع العديد من المساهمين وحتى ورثتهم. استغرقت موزيلا سنوات (2001-2006) لإعادة ترخيص فايرفوكس وثندربرد والبرمجيات ذات الصلة.

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

هل يحتاج مشروعي إلى اتفاقية مساهم إضافية؟

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

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

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

بعض الحالات التي قد ترغب فيها في النظر في اتفاقية مساهم إضافية لمشروعك تشمل :

  • يريد محاموك من جميع المساهمين قبول شروط المساهمة صراحةً (sign، عبر الإنترنت أو خارجه)، ربما لأنهم يشعرون أن الترخيص مفتوح المصدر نفسه لا يكفي (حتى وإن كان يكفي!). إذا كان هذا هو القلق الوحيد، فستكون اتفاقية المساهم التي تؤكد على ترخيص المشروع مفتوح المصدر كافية. اتفاقية jQuery Individual Contributor License Agreement هي مثال جيد على اتفاقية مساهم إضافية خفيفة الوزن.
  • أنت أو محاموك تريدون من المطورين التصريح بأن كل commit يقومون به مُصرح به. مطلب Developer Certificate of Origin هو الطريقة التي تحقق بها العديد من المشاريع ذلك. على سبيل المثال، مجتمع Node.js يستخدم الـ DCO بدلاً من اتفاقية CLA السابقة. خيار بسيط لأتمتة فرض الـ DCO على مستودعك هو DCO Probot.
  • مشروعك يستخدم ترخيصًا مفتوح المصدر لا يتضمن منح براءة اختراع صريح (مثل MIT)، وتحتاج إلى منح براءة اختراع من جميع المساهمين، بعضهم قد يعمل في شركات لديها محافظ براءات اختراع كبيرة يمكن استخدامها لاستهدافك أو استهداف مساهمي ومستخدمي المشروع الآخرين. اتفاقية Apache Individual Contributor License Agreement هي اتفاقية مساهم إضافية شائعة الاستخدام تحتوي على منح براءة اختراع مماثل للذي يوجد في Apache License 2.0.
  • مشروعك تحت ترخيص copyleft، ولكنك تحتاج أيضًا لتوزيع نسخة مملوكة من المشروع. ستحتاج إلى أن يقوم كل مساهم بتخصيص حقوق الطبع والنشر لك أو منحك (وليس للجمهور) ترخيصًا permissive. اتفاقية MongoDB Contributor Agreement هي مثال على هذا النوع من الاتفاقيات.
  • تعتقد أن مشروعك قد يحتاج إلى تغيير التراخيص خلال عمره وتريد من المساهمين الموافقة مسبقًا على مثل هذه التغييرات لتقليل تشتت انتباه المساهمين.

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

ماذا يحتاج فريق الشؤون القانونية في شركتي لمعرفته؟

إذا كنت تطرح مشروعاً مفتوح المصدر كموظف في الشركة، يجب أولاً أن يعرف فريق الشؤون القانونية أنك تطرح مشروعاً مفتوح المصدر.

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

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

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

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

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

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

  • الخصوصية: هل يجمع مشروعك بيانات عن المستخدمين؟ هل يقوم “بالاتصال بخوادم الشركة”؟ يمكن لفريقك القانوني مساعدتك في الامتثال لسياسات الشركة واللوائح الخارجية.

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

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

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

  • سياسات مساهمة الموظفين: فكر في تطوير سياسة شركية تحدد كيف يساهم موظفوك في مشاريع مفتوحة المصدر. ستقلل سياسة واضحة من الالتباس بين الموظفين وتساعدهم على المساهمة في مشاريع مفتوحة المصدر بما يخدم مصلحة الشركة، سواء كجزء من وظائفهم أو في أوقات فراغهم. مثال جيد هو Model IP and Open Source Contribution Policy لشركة Rackspace.
  • ما الذي يجب إصداره: (تقريبًا) كل شيء؟ إذا كان فريقك القانوني يفهم ويشارك في استراتيجية شركتك للمصدر المفتوح، فسيكون أفضل من يساعدك بدلاً من عرقلة جهودك.
  • الامتثال: حتى إذا لم تصدر شركتك أي مشاريع مفتوحة المصدر، فهي تستخدم برمجيات مفتوحة المصدر للآخرين. يمكن أن تمنع الوعي والعمليات الصداع، وتأخير المنتجات، والدعاوى القضائية.