VOL89: Software Licenses Explained
أهلًا وسهلا بكم في العدد التاسع والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸🇸🇩
أهلًا وسهلا بكم في العدد التاسع والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف،نشرتنا تساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع, هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات مقالات مختارة من اقرأ-تِك.
مواضيع النشرة لهذا الأسبوع:
All About Software Licenses
Serverless Architecture
How Meta Leverages AI For Efficient Incident Response
All about Software Licenses
في كل مشروع / مكتبة أو حتي لغة بنلاقي ال License file, أغلبنا مش بيهتم واللي بيهتم و بينشر مشاريع بشكل دوري غالبًا بيستخدم MIT بدون تفكير, النهارده هنشرح دور الرخصة وفايدتها وإزاي تقدر تختار أي License لمشاريعك من أشهر 5 رخص موجودة حاليًا.
الـ Software License هو الاتفاق القانوني اللي بيقول الناس مسموحلها تعمل إيه بالكود بتاعك وممنوع تعمل إيه؟
فايدة ال License بتكمن في نقطتين:
بترّخص للناس استخدام الكود
بتحمي “الملكية الفكرية” لل Code Owners وبتوضح ازاي الناس تقدر تستخدم ال Source code بدون التعدي علي حقوقهم.
أنواع رُخص البرمجيات
الرخص كلها بتقع في واحد من التصنيفات دي و احنا مرتبينها من الأكثر سماحية للأقل
Public Domain Licenses
الرخص من النوع دا معناها إن الكود متاح للاستخدام من الجميع وبدون أي Copyrights بتقيده فالناس تقدر تستخدمه, التعديل فيه وبيعه كمان مسموح و أشهر هذه الرخص هي ال CC0
Open Source (Permissive) Licenses
رخصة ال Open Source كذلك بتسمح بالاستخدام والتعديل والمشاركة وكمان البيع ولكن لازم تحافظ علي اسم ال Code owners الأساسين في ال License أشهر مثال علي هذه الرخص هي ال MIT License
CopyLeft Licenses
النوع دا من الرخص يُعد أيضًا Open Source ولكن الهدف منه هو الحماية من إعادة البيع أو إعادة التوزيع, بمعني إنك تقدر تستخدم الكود بحرية ولكن مينفعش تغير فيه وتبيعه, أي كود مُشتق من الكود الأصلي لازم يتنشر تحت نفس الرخصة عشان نضمن “مجانية” الكود دايمًا. أشهر هذه الرخص هي ال GNU General Public License
Proprietary Licenses
النوع دا من الرخص بتستخدمه الشركات وفيه بتتيح استخدام الكود أو الSoftware بمقابل مادي للمستخدمين وبتحد من التعديل في الكود أو توزيعه أو بيعه و بتحتفظ فيه بالحقوق دي لل Code Owners الأساسين فقط.
MIT License
تعتبر أبسط وأقصر وأشهر الرخص و بتتيح للمبرمجين استخدام وتعديل وحتي بيع المنتجات اللي بتعتمد عليها ولكن لازم تسيب اسم صاحب الكود والـ license في المشروع. من أكبر مميزاتها إنها بتشجع الناس تستخدم و تتبني الكود وتطوره ك Open Source Project و دا بيساعد يتبني Community قوي لل .tool/Software, أكبر عيب ليها إن حد ممكن ياخد كودك ويعمله منتج مقفول ويبيعه وميديكش credit غير في license.
نستخدمها إمتى؟
Libraries
Open Source toolsSide projects
Startups
أشهر مشاريع بتستخدمها هي React، Next.js، Vue، Express
بتوضع غالبًا في ملف بعنوان LICENSE بدون بدون Extension في ال Root Directory بهذه الصياغة
MIT License
Copyright (c) <YEAR> >CODE OWNER NAME>
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.Apache License 2.0
الرخصة دي كمان من رخص ال Open Source وهي زي MIT بس أطول وأعقد شوية, الفرق الأساسي بينهم إن فيها Patent protection وإنها واضحة أكتر قانونيًا. من أكبر مميزاتها إنها آمنة للشركات عشان يتفادوا مشاكل ال Patent أو براءة الاختراع.
بنستخدمها إمتى؟
في المشاريع الكبيرة لأنها Overkill لو المشروع بالفعل صغير
مشاريع الشركات
ال Tools اللي ممكن تدخل في نزاعات patents
أشهر مشاريع بتستخدمها هي Kubernetes، Kafka، Android
GPL (GNU General Public License)
الرخصة دي من رخص ال Copyleft فهي بردو رخصة Open source ولكن مع تشديد علي جزئية إعادة البيع أو التوزيع. لأنها بتنص إنك لو هتستخدم ال Source code/ Software في إنتاج Code / Software جديد لازم الكود أو البرنامج الجديد يخضع لنفس الرخصة يعني بمعني أصح يكون هو كمان Open Source . ودي بتبقي مشكلة كبيرة وميزة كبيرة في نفس الوقت
هي عيب أو مشكلة لو أنت عاوز تبيع أو تعمل Paid Subscriptions علي الخدمة الجديدة, ولذلك الشركات بتهرب منها. وكمان لو أنت عاوز أكبر عدد من الناس يتبني الكود فدا بيحدهم ويخليهم يفكروا قبل استخدامه.
و هي ميزة كبيرة لأنها بتجبر أي حد يعمل أي تعديل إنه يرجعه لل Community و بتحافظ علي إن الكود يكون Open Source للأبد
باختصار لو استخدمت الكود بتاعي = مشروعك كله لازم يبقى Open Source
بنستخدمها إمتى؟
استخدمها في المشاريع التعليمية
Anti-corporate misuse
أشهر مشاريع بتستخدمها هي Linux Kernel
في نسخة أكثر تساهلاً منها وهي LGPL (Lesser General Public License ) وبيها تقدر تستخدم المكتبة في مشروع مقفول بس لو عدّلت المكتبة/ الكود نفسه لازم افتح التعديلات للكل و دي بتكون مناسبة أكثر لو هتعمل Plugin لأنك عاوز الناس تستخدمه في مشاريعها ولكن لو في تعديل في كود ال Plugin نفسه لازم الCommunity يطلع عليه.
Proprietary License
ودي هي الرخص المقفولة وفي منها صياغات كثيرة أشهرهم الEnd User License Agreement (EULA) و ال Subscription License و بيها بتدي الناس حق الاستخدام فقط, وبتحتفظ بكامل حقوق التعديل والنشر والبيع.
أغلب ال Software اللي بتستخدم الرخصة دي الكود بتاعها بيكون Private ومش باين للناس اللي الناس تقدر توصله هي الخدمة أو ال Software بس مش ال Source code نفسه. ولكن في حالات خاصة زي ال SDKs مثلاً فالكود بيكون ظاهر لأن اللي هيستخدمه Developers لكن ميقدروش يعدلوه أو يعيدوا استخدامه وتوزيعه.
في الختام
فهم ال Software License أساسي لكل مبرمج بينشر تطبيقات لأنه مش بس بينظم استخدام الناس للكود بتاعك وبيخلي فيه شفافية في موضوع حقوق ملكية الكود. ولكنه كمان بيأثر علي مدى انتشار و تبني الكود من ال Community فزي ما شوفنا في مبرمجين و Engineering leads كتير بتبعد عن استخدام بعض الأدوات بس بسبب ال License المنشورة تحتها واللي ممكن تحدهم من نشر تطبيقاتهم. استخدام الرخصة المناسبة كمان بيحمي أهدافك من المشروع فال proprietary licenses بتحمي جزء ربحيتك من الكود و ال Open Source Licenses بتحمي انتشار ونفع الكود دا للمجتمع التقني بشكل عام و الاتنين هتحتاجهم في وقت من الأوقات.
روابط مفيدة
موقع Choose a License يقدم قائمة كاملة بكل الرخص المتاحة لل Open Source
Serverless Architecture
من زمان والناس نفسها انه تتيح للـ Developers الفرصة أنهم يركزوا على جزء الـ Development وانهم يكونوا قادرين على بناء Services قوية ويبدعوا فيها بدون عوائق الـ Infrastructure أو التفكير فيها ..
بحيث يركزوا على الـ Core Product أو المنتج اللي مهتمين بيه بمعنى أصح ، من غير ما يهتموا بازاي هيديروا البنية التحتية للـ Product ده
💡وعشان كده ظهر الـ Serverless Architecture كطريقة أو نمط للتصميم يسمح للـ Developers بتحقيق الأمنية دي , وإن هم يبقوا قادرين على بناء الـ Software بدون الاهتمام بالبنية التحتية واداراتها
ازاي Serverless Architecture بتشتغل ؟
كلنا عارفين أن الـ Servers عشان تسمح للـ Users بإنهم يتواصلوا مع أي تطبيق والـ Business Logic بتاعه , ده هيتطلب Resources وبنية تحتية هتطلب موارد واهتمام وادارة زي :
Server Hardware
Security Updates
Backups
Resources Management
ومن خلال اتباع الـ Serverless Architecture احنا بنشيل العبء ده كله وبنخلي الـ Developers يهتموا بس بجزء الـ Business Logic / Core Product وانهم يكتبوا الـ Application Code وبنشيل عبء البنية التحتية ونخليها مسئولية Third Party Provider زي الـ Cloud Services اللي موجودة دلوقتي ومن أشهرهم AWS , Google Cloud , Microsoft Azure
أحد أشهر الـ Serverless Architecture هي الـ FaaS واللي هي اختصار لـ Function as a Service , واللي من خلالها الـ Developers بيكتبوا الـ Application بتاعهم والـ Core Product اكنه بالظبط عبارة عن مجموعة محددة من الـ Functions اللي بتتنفذ واللي بيحصلها Triggering من خلال الـ Events زي مثلا ان حد يبعت رسالة لحد , أو ان يتبعت Email أو ان يحصل HTTP Request بشكل معين.
وبالشكل ده انت كـ Developer مسئول عن :
How Meta Leverages AI For Efficient Incident Response
هنشوف في المقال ده ازاي فريق المهندسين في Meta اشتغلوا على انهم يسرعوا من عملية التحقيق في مشاكل الـ System Reliability باستخدام نظام جديد مدعوم بالـ AI عشان يحددوا الـ Root Cause بتاع المشكلة.
النظام ده بيستخدم خليط ما بين “heuristic-based retrieval” و “large language model-based ranking” عشان يسرع عملية تحديد السبب الجذري أثناء التحقيقات. ومن خلال اختبار النظام، فريق المهندسين في Meta لقى إنه وصل لدقة بتوصل لـ 42% في تحديد الأسباب الجذرية للتحقيقات وقت ما بتبدأ علطول، خصوصًا المشاكل المتعلقة بالـ “web monorepo”.
والـ الـ heuristic-based retrieval هو أسلوب بيستخدم قواعد وإرشادات معينة، أو ما يُسمى بالـ “heuristics”، عشان يسهل عملية البحث والتصفية في كميات كبيرة من البيانات أو التغييرات. الفكرة الأساسية في الـ “heuristics” هي إنها مش بتعتمد على الدقة المطلقة، ولكنها بتعتمد على تقنيات سريعة وفعالة لتقليل مساحة البحث بشكل كبير، حتى لو أدى ده لتقليل دقة بسيطة في النتائج.
فالتحقيق في المشاكل حاجة أساسية عشان نضمن استقرار النظام، وده ضروري عشان نحل المشاكل بسرعة. فعشان كده Meta بتستثمر في تطوير أدوات التحقيق بتاعتها زي أداة “Hawkeye” اللي بيستعملوها داخليًا عشان يعملوا “debugging” للـ Workflows الخاصة بالـ machine learning.
شكل الـ Investigations في Meta
كل تحقيق بيكون مختلف عن التاني، ولكن مما لاشك فيه أن تحديد السبب الجذري للمشكلة هو ضروري جدًا عشان نعرف نحل المشكلة بطريقة صحيحة وسليمة. فالتحقيق في المشاكل اللي بتحصل في أنظمة معتمدة على الـ “monolithic repositories” بيكون صعب من ناحية الـ Scalability بكل تأكيد، وده عشان بيبقى فيه عدد كبير من التغييرات من فرق مختلفة. بالإضافة لكده، الأشخاص اللي بيحلوا المشكلة محتاجين يبنوا فكرة عن المشكلة عشان يبدأوا يشتغلوا عليها، زي إيه اللي اتعطل، الأنظمة اللي متأثرة، والناس اللي ممكن تتأثر بالمشكلة. فلازم يكون معاهم Context واضح عشان يقدروا يفهموا طبيعة المشكلة اللي بيتعاملوا معاها.
التحديات دي بتخلي عملية التحقيق في الـ (anomalies) معقدة وممكن تاخد وقت طويل. فالـ AI بيوفر فرصة لتبسيط العملية دي، وتقليل الوقت اللي محتاجينه، وكمان مساعدة الأشخاص اللي بيحققوا في المشكلة يقدروا ياخدوا قرارات بشكل أفضل. فهم ركزوا على بناء نظام قادر على تحديد التغييرات في الكود اللي ممكن تكون السبب الجذري لمشكلة معينة.
بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
