لیست زبان ها و پایگاه های داده ای که OpenShift می تواند برای شما به عنوان PaaS پشتیبانی کند. @iranopensource 🐧

دعوت به همکاری لینوکس ادمین ـ شرکت پیشرو فن‌آوری هماپی

شرکت پیشرو فن آوری هماپی در نظر دارد جهت تقویت توان تخصصی خود در حوزه تولید اپلیکیشن های پرداخت، با عنوان شغلی زیر از نیروهای متخصص دعوت به همکاری نماید:

لینوکس ادمین:

Linux Admin

We are looking for a Linux administrator who will be responsible for designing, implementing, and monitoring the infrastructure; also, to collaborate with other team members to develop automation strategies and deployment processes. You will become an integral part of the team, making every problem of the platform a problem of your own, and solving them accordingly.



Responsibilities

Help tune performance and ensure high availability of infrastructure
Design and develop infrastructure monitoring and reporting tools
Develop and maintain configuration management solutions
Develop test automation frameworks in collaboration with rest of the team
Create tools to help teams make the most out of the available infrastructure



Skills

Experience with Linux servers in virtualized environments
Familiarity with the fundamentals of Linux scripting languages
Experience installing, configuring, and maintaining services such as Bind, Apache, MySQL, nginx, etc.
Strong grasp on configuration management tools, such as Puppet and Chef Familiarity with load balancing, firewalls, etc.
Proficient with network tools such as iptables, Linux IPVS, HAProxy, nginx etc.
Experience with virtualization technologies, such as Xen
Ability to build and monitor services on production servers
Knowledge of servers and switches
Knowledge of monitoring tools such as Zabbix



معرفی شرکت

«هما‌پی» یک شرکت نوبنیاد ناب (Lean Startup) است که پس از چندین سال فعالیت در حوزه خدمات الکترونیک، یک روش نوین پرداختی به نام « هم‌پی» را به بازار ارایه داده است.

این شرکت متشکل از تیمی با تجربه‌ است که سال‌ها در زمینه خدمات الکترونیک در حوزه بین الملل است فعالیت داشته‌اند و امروز تحت حمایت شرکت سراوا پارس، فصل جدیدی از تجربه پرداخت الکترونیک را پیش روی کاربر ایرانی قرار داده‌اند.

علاقه‌مکندان می‌توانند رزومه خود را به ادرس ایمیل [email protected] ارسال کنند.

#jobs #linux

#خراسان_رضوی - مشهد | #python # C# # C #java # g#
💼 شرکتی دانش بنیان در مشهد جهت تکمیل کادر فنی خود از افراد واجد شرایط زیر دعوت به همکاری می نماید:
📃 عنوان شغلی: برنامه نویس
شرایط احراز:مسلط به یکی از زبانهای
python/C#/C/go/java/ruby

محل کار:مشهد
حقوق و مزایا: مناسب با توانایی و تجربه ی فرد
بیمه و بیمه تکملی دارد

📞علاقه مندان می توانند رزومه ی خود را به آدرس ایمیل زیر ارسال نمایند:
[email protected]

@iranopensource 🐧

✨✨آیا #DevOps بیش از یک عنوان است؟ (بخش اول)
عنوان مهندسی DevOps بیش از پنج سال است که به طور مداوم در حال حرکت به جلو ست. این در حالیست که به نظر میرسد، این مهندسان، با مهندسان سیستم (Administrator's) برابری می کنند. اما تفاوت های ظریفی بین این دو وجود دارد.
وجود DevOps عمدتا در نتیجه وجود ابر است و نیاز به توانایی خودکارسازی بسیاری از وظایف انجام شده توسط مدیر سیستم سنتی بود که تکامل نقش DevOps شکل گرفت.
امروزه از سیستم ادمین سنتی خواسته می شود تا با تیم های توسعه نرم افزار و مدیریت محصول برای اطمینان از کارآیی فرآیند انتشار نرم افزار همکاری کند در حالیکه این همکاری، نیازمند دانش DevOps است.
به طور خلاصه، یک مهندس DevOps می تواند به طور کلی هر کاری را که مدیر سیستم می تواند انجام دهد را انجام دهد، اما نه برعکس.
بنابراین زمانی که شرکت ها به دنبال نیروی متخصص هستند، این سوال مطرح میشود که
چرا استعداد هایی که دارای مهارت های گسترده تر هستند را جذب نکنیم حتی اگر در روز اول لزوما مورد نیاز نباشد؟

DevOps vs System Administration

✨✨آیا #DevOps بیش از یک عنوان است؟ (بخش دوم)
آنچه مسلم است، اعداد نشان دهنده رشد قوی در تقاضای عنوان DevOps است. در 18 ماه گذشته تعداد آگهی هایی که شامل عنوان مهندسی DevOps هستند، بیش از 50 درصد افزایش یافته است.
تغییر واقعی است؛
شرکت ها بیش از آن که به دنبال سیستم ادمین ها یا مدیران سیستم (Administrator's) باشند، به دنبال مهندسان DevOps هستند.
و همانطور که اشاره شد، تفاوت های مشخصی در وظایفی که برای تکمیل هر یک از آن ها خواسته شده، وجود دارد
بله. DevOps آینده است.
بنابراین، بیشتر از یک نام است. سوال واقعی این است که آیا شرکت ها به آن بیش از یک نام می پردازند؟

اخیرا اصطلاح #microservices را در گپ و گفت های فناوری زیاد می شنویم. در این پست تلاش می کنیم که مفهوم و محاسن و معایب آنرا بررسی کنیم.

در حقیقت Microservices روشی برای توسعه برنامه های کاربری است که در آن یک برنامه بزرگ و پیچیده به مجموعه ای از سرویس های کوچکتر و مستقل از یکدیگر تقسیم می شود. هر یک از سرویس ها هدف مستقلی را دنبال میکند و با استفاده از رابط های بسیار سبک و سریعی با سایر سرویس ها تعامل دارد، همچنین عموما از API ها با منبع HTTP در توسعه آن ها استفاده شده است. به طور مثال یک برنامه فروش یا حسابرسی را می توانیم با ساختارMicroservices به گونه ای توسعه داد که در آن یک سرویس مسئول احراز هویت باشد، سرویس دیگر مسئول نگهداری داده ها، سرویس دیگر انجام پردازش ها و به همین ترتیب در آینده نیز با توسعه سرویس های مستقلی میتوان آنرا به صورت کاملا ماژولار توسعه داد.

محاسن Microservice ها:

🔻 گسترش و توسعه آسان در مقایسه با روش های کلاسیک
🔻افزایش قابل توجه سرعت و چابکی در تولید
🔻مقیاس پذیری و انعطاف پذیری برنامه ها
🔻 قابلیت استفاده مجدد از سرویس ها در سایر پروژه ها
🔻 قابلیت استفاده تحت زیرساخت های مبتنی بر رایانش ابری
🔻قابلیت بالا در کار با تکنولوژی کانتینرها مانند #docker

در حالی که استفاده از Microservices مزایای قابل توجهی دارد اما از طرف دیگر با چالش هایی هم مواجه می شویم:

▫️ استفاده از تعداد زیادی جزء کوچک در عملکرد با یکدیگر این پتانسیل را دارد که ساختاری در پیش روی ما قرار دهد که رفع خطا یا بهبود عمکلرد کلی برنامه را با دشواری مواجه کند.
▫️ امکان بروز مشکل Latency زیاد است
▫️تست برنامه فرآیند ساده ای نخواهد بود

@iranopensource 🐧

5 قانون ساده برای امن ماندن در فضای آنلاین

آشنایی با انواع مجوزهای نرم افزاری و قانون کپی رایت

آشنایی با انواع مجوز نرم‌افزاری و قانون کپی-رایت

این روزها نوشتن یک برنامه‌ی کاربردی، بدون استفاده از انوع کتابخانه‌ها (libraries) و کدهایی که دیگران نوشته‌اند، تقریباً غیرممکن است. شما چه برنامه‌نویسی باشید که می‌خواهد از قطعه‌کدهای دیگران استفاده کند و چه برنامه‌نویسی که در اندیشه‌ی تولید این کتابخانه‌هاست، باید با جنبه‌های قانونی استفاده از کدهای سورس یا کامپایل‌شده آشنا باشید تا در ورطه‌ی دردسرهای پیش‌بینی‌نشده و ناخواسته سقوط نکنید.
مهم‌ترین چیزی که پیش از دست زدن به کدها و تصاویر آماده‌ی گرافیکی، یا استفاده از کتابخانه‌ها باید بررسی کنید، مجوز، یا به‌اصطلاح لایسنسی است که اثر را تحت آن توزیع کرده‌اند. برای اطلاع از آن، معمولاً باید به دنبال فایلی با نام license.txt بگردید یا صفحه‌ی مربوط به مجوزها (Legal/Licensing) را در سایت اصلی بیابید.

مجوز
انواع اصلی لایسنس‌ها را چهار دسته تقسیم می‌کنیم:

یکم ـ مجوز آزاد یا permissive/copyfree

کدهایی که تحت این نوع مجوز توزیع می‌شوند، هیچ محدودیتی بر برنامه‌ی نهایی شما ایجاد نمی‌کنند. شما آزادید که هر تغییری در آن‌ها ایجاد کنید و لزومی ندارد کدهای تغییریافته یا استفاده‌شده را بازنشر دهید. حتی منعی برای استفاده‌ی تجاری از این کدها نیز وجود ندارد.
انواع اصلی این لایسنس‌ها عبارتند از Apache، BSD، MIT/X11 و Academic Free Licence.
لایسنس‌های BSD و MIT بسیار مختصر هستند و تنها به مثابه‌ی اعلامیه‌ای برای سلب مسئولیت از نویسنده به کار می‌روند و گزینه‌ی مناسبی برای کامپوننت‌ها و کدهای کوچک قلمداد می‌شوند. در حالی که Apache و AFL، متن‌های حقوقی و کاملی هستند که تکلیف مسائلی نظیر سرنوشت پتنت‌ها را نیز مشخص کرده‌اند. برنامه‌های کامل، ترجیحا با لایسنس Apache عرضه می‌شوند.
به عنوان مثال، برنامه‌های معروفی که از این نوع لایسنس‌ها استفاده می‌کنند، می‌توان به LLVM/Clang، X11، FreeBSD، OpenSSL، Apache Server، اپل وب‌کیت و کرومیوم، و قسمت‌های یوزرلند اندروید اشاره نمود.

دوم ـ مجوز تجاری / کپی‌رایت‌شده (Copyrighted/Proprietary)

همه‌ی برنامه‌های تجاری با این عنوان عرضه می‌شوند. این کدها بدون تهیه‌ی مجوز لازم از توزیع‌کننده، در کدهای شما قابل استفاده نیستند. استفاده از این کدها یا لینک کردن به آن‌ها، معمولاً در ازای پرداخت پول مجاز است. پس از دریافت مجوز، ممکن است فایل‌های کامپایل‌شده (سورس‌بسته) یا کدهای اصلی (همراه سورس) را در اختیار شما قرار دهند، اما به شما اجازه‌ی توزیع آن کدها را نخواهند داد.
از گروه سورس‌بسته می‌توان به ویندوز و مایکروسافت آفیس، و از گروه همراه با سورس می‌توان به vBulletin، Unix و کامپوننت‌های DevExpress اشاره کرد
بر خلاف مجوز‌های متن‌باز 1، استاندارد رایجی برای مجوزهای کپی‌رایت تجاری وجود ندارد و توصیه می‌شود فایل لایسنس، به‌دقت مطالعه شود.

سوم ـ مجوزهای کپی‌لفت قوی (Strong Copylefted)

کدهایی که تحت این عنوان توزیع می‌شوند، لایسنس خود را به برنامه‌ی شما تحمیل می‌نمایند. حتی اگر یک خط از آن‌ها را وارد برنامه‌ی خود کنید، ناچار خواهید بود کل برنامه‌تان را به صورت کپی‌لفت، در اختیار سایرین قرار دهید. این مجوزها به شما اجازه‌ی تجاری‌سازی یا فروش برنامه و کدتان را نمی‌دهند. سخت‌گیری مجوزهای کپی‌لفت تنها به استفاده از کدها ختم نمی‌شود. حتی لینک کردن به نسخه‌ی کامپایل‌شده‌ی آن‌ها نیز، چه به صورت استاتیک انجام شود و چه به صورت دینامیک، همه‌ی کدهایتان تحت این مجوزها قرار خواهد گرفت. بنابراین اگر قصد ندارید بدون انتشار همه‌ی کدهای خود برنامه‌تان را توزیع کنید و یا از فروش آن کسب درآمد نمایید 2، عطای کتابخانه‌های دارای این دسته از مجوزها را به لقایشان ببخشید.
البته کسب درآمد از طریق ارائه‌ی خدمات پشتیبانی و نصب و راه‌انداری قانونی‌ست و مدل تجاری شرکت‌های بزرگی همچون ردهت بر این اساس بنا نهاده شده است.
انواع اصلی این لایسنس‌ها GPL و AGPL هستند که هر کدام چندین نسخه دارند. در میان برنامه‌های معروفی که با این نوع لایسنس عرضه می‌شوند، می‌توان به لینوکس (کرنل) و یوزرلند اصلی آن، GNU، و همچنین MySQL، وردپرس، جوملا، لیبرآفیس(LibreOffice)، کامپایلر GCC، فریمورک Qt و… اشاره نمود.
معدودی از این برنامه‌ها و کدها، هم‌زمان با لایسنس تجاری هم عرضه شده‌اند که اگر بخواهید از برنامه‌ای که نوشته‌اید، از طریق فروش نرم‌افزار و بدون انتشار سورس کد کسب درآمد کنید، می‌بایست نسخه‌ی تجاری آن‌ها را خریداری نمایید. فریمورک Qt و بانک اطلاعاتی MySQL از این دسته برنامه‌ها هستند.

چهارم ـ مجوزهای کپی‌لفت ضعیف (Weak Copylefted)

تنها تفاوت انواع ضعیف مجوزهای کپی‌لفت با انواع قوی آن،‌ در این است که اجازه‌ی لینک دینامیک به کتابخانه‌های کامپایل‌شده با این لایسنس را می‌دهد. برای مثال، Glibc، کتابخانه‌ی پوزیکس و زبان سی 3 در لینوکس، که عملاً دروازه‌ی هسته‌ی لینوکس برای همه‌ی برنامه‌های کاربردیست، با این مجوز توزیع شده است و اگر به خاطر همین مجوز کپی‌لفت ضعیف نبود، اساساً امکان عرضه‌ی برنامه‌های تجاری برای لینوکس وجود نداشت.
به عنوان انواع اصلی این مجوز ها، می‌توان به LGPL و MPL (موزیلا) اشاره کرد.
برنامه‌ها‌ی Firefox و VLC و کتابخانه‌ی معروف FFmpeg نیز نمونه‌ی دیگری از این گروه مجوزهاست. اگرچه برخی اجزای کتابخانه FFmpeg تحت لیسانس GPL منتشر شده‌اند. در صورت فعال شدن همان اجزا، کل کتابخانه تحت GPL قرار خواهد گرفت.
در سیستم عامل اندروید، برای آن که کوچک‌ترین نگرانی برای برنامه‌سازان تجاری باقی نماند و از سرایت لایسنس هسته‌ی اصلی لینوکس به بقیه‌ی نرم‌افزارها جلوگیری شود، کتابخانه‌ی پوزیکس/سی اختصاصی آن به نام Bionic، با لایسنس BSD عرضه شده است.

توضیح ـ مجوزهای کرییتیو کامنز (Creative Commons, CC)

نوعی مجوز آزاد و رایگان که برای آثار گرافیکی و نوشتاری رایج است و بر اساس ویژگی (Types) آن می‌توانند مجاز یا ممنوع برای استفاده‌ی تجاری باشند. اگر برنامه‌ی تجاری می‌نویسید، تنها از کارهای گرافیکی استفاده کنید که استفاده‌ی تجاری را آزاد گذاشته‌اند.
این مجوز می‌تواند ویژگی‌های دیگری نظیر عدم اجازه‌ی تغییر در کار اصلی را همراه خود داشته باشد که باید به آن‌ها نیز توجه نمایید.

بحث و نتیجه‌گیری

سخن به گزافه نگفته‌ایم اگر بگوییم تنوع لایسنس‌ها و دعواهای حقوقی شرکت‌های نرم‌افزاری، مطابق قانون کپی‌رایت مصوب ۱۹۷۶ آمریکا 4، یکی از اصلی‌ترین عوامل تأثیرگذار بر دنیای کنونی نرم‌افزارها و یکی از عوامل پیچیدگی و توسعه‌ی آن‌هاست. هر کدام از این مجوزها، توسط فلسفه‌ای پشتیبانی می‌شود و همین تفاوت فلسفه‌هاست که که به دنیای برنامه‌نویسی چهره‌ای انسانی، فارغ از کدهای رایانه‌ای بخشیده است.
یکی از عوارض این تفاوت‌ها، ناسازگاری میان برخی مجوزهاست. مثلا شما نمی‌توانید در یک برنامه، هم‌زمان از کدهای با مجوز GPL و تجاری استفاده کنید، حتی اگر دو فایل مجزا باشند. حتی اگر هر دو مجوز متن‌باز باشند نیز لزوماً با هم سازگار نیستند. برای مثال، BSD چهار بندی، با GPL سازگار نیست. حتی GPL نسخه‌ی ۲ با LGPL نسخه‌ی ۳ سازگار نیست؛ با این که هر دو کپی‌لفت هستند. یعنی نمی‌توان برنامه‌ای داشت که یک قسمت از آن تحت LPG v2.1 و قسمتی دیگر تحت GPL v3 توزیع شده باشد.
یکی از دلایل ماندگاری سیستم‌عامل‌های FreeBSD و OpenBSD در مقابل لینوکس، مجوز آزاد نسخه‌های BSD است. در واقع بسیاری از پروژه‌ها نظیر LLVM/Clang (در مقابل کامپایلر GCC)، وب‌کیت (در مقابل Gecko ـ موتور رندرر فایرفاکس) یا ToyBox (در مقابل BusyBox ـ تجمیع ابزارهای خط فرمان لینوکس)، به همین دلیل به وجود آمده یا حمایت شده‌اند که امکان مقابله‌ی شرکت‌های تجاری (در دو مورد نخست اپل و مورد سوم سونی) با طبیعت تهاجمی مجوزهای کپی‌لفت را به وجود بیاورند.
توجه داشته باشید که مجوزهای LGPL/GPL با استور اپل (آیتونز) سازگار نیستند و در میان لایسنس‌های کپی‌لفت، می‌توانید از MPL استفاده کنید.
بدون شک، هر کدام از این مجوزها و هر کدام از عنوان‌هایی که ذکر آن‌ها رفت، برای خود به‌تنهایی مقاله‌ای مستقل می‌طلبند که در حوصله‌ی خوانندگان چنین مقاله‌ی مختصری نیست. توجه داشته باشید که نویسنده‌ی مقاله، نه یک حقوقدان و نه حتی یک مهندس کامپیوتر، بلکه پزشکی است که به خاطر علاقه به این مباحث مطالعاتی را در این زمینه انجام داده و آنچه نگاشته، تنها می‌تواند انگیزه‌ای برای مطالعه‌ی بیشتر فراهم کند تا آن که به عنوان یک متن حقوقی مورد استناد قرار گیرد.
…
شاید بهتر باشد برای درک بهتر تأثیر این مجوزها در کار یک برنامه‌نویس، به چند پرسش رایج در این زمینه پاسخ گوییم.

آیا می‌توانم با نرم‌افزارهای کپی‌لفت، محتوای تجاری تولید کنم؟

جامعه‌ی متن‌باز، مراقب این موضوع بوده که لایسنس برنامه‌هایشان محتوای شما را تحت تأثیر قرار ندهند و در صورت لزوم این موضوع را به صراحت نیز قید کرده‌اند. بنابراین می‌توانید با برنامه‌ای نظیر LibreOffice که تحت GPL توزیع شده، محتوای تجاری تولید کنید، یا برنامه‌ی تجاری خود را توسط GCC کامپایل نمایید. اطلاعات سایت‌هایی که تحت نرم‌افزارهای کپی‌لفت هستند تحت تأثیر این لایسنس قرار نخواهند داشت (چرایی آن از نظر حقوقی خود یک مقاله است). در واقع، سایت‌های خبررسانی زیادی نظیر CNN از این سرویس‌ها استفاده می‌کنند.

از نرم‌افزاری با مجوز GPL (مثل وردپرس) برای راه‌اندازی سایت خود استفاده کرده‌ام. تکلیف چیست؟

این گونه برنامه‌ها همراه سورس هست و آزادید آن‌ها را تغییر بدهید. خیالتان راحت باشد که محتوای سایت شما تحت این نوع مجوز قرار نخواهد گرفت و تنها کدهاست که شامل لایسنس می‌شوند. حتی اگر چیزی به سورس آن اضافه کنید یا تغییر دهید، ولی قصد توزیع آن را نداشته باشید، به این کار مجبور نمی‌شوید. ولی توجه داشته باشید که پلاگین‌ها و تم‌های وردپرسی که شما تهیه می‌کنید، یا تغییراتی که به‌اصطلاح هاردکد می‌کنید، تحت مجوز GPL قرار می‌گیرند و تنها در صورتی که بخواهید آن‌ها را به فرد دیگری بدهید، حتی یک نفر دیگر، مجبورید سورسشان را به رایگان برای همه منتشر کنید. در واقع این موضوع، یکی از بزرگ‌ترین معضلات حقوقیست که تهیه‌کنندگان پلاگین‌ها و تم‌های تجاری وردپرس با آن درگیرند. 5
گرچه مجوز GPL شما را مجبور نمی‌کند که تغییراتی که برای استفاده‌ی شخصی داده‌اید منتشر کنید، اما این مجوز خواهرخوانده‌ای به نام AGPL دارد که در صورتی که کد تغییر یافته را روی سرور اجرا کنید، باید منتشرش نمایید.

در ایران که قانون کپی‌رایت وجود ندارد، باز هم ملزم به رعایت و توجه به این موارد هستیم؟

صرف نظر از مسائل اخلاقی که ما را ناگزیر از رعایت این موارد می‌کنند، باید توجه داشته باشیم که اگر بخواهیم برنامه‌ی خود را در اپ‌استورهایی همچون آیتونز یا گوگل پلی منتشر کنیم، رعایت این موارد ضروریست چرا که در صورت عدم رعایت، برنامه‌های شما را از فروشگاه حذف می‌شود. همچنین، گرچه جامعه‌ی متن‌باز اهل شکایت و دادگاه نیستند، ولی از فردای روزی که ایران به سازمان تجارت جهانی بپیوندد، مسائل حقوقی ناشی از آن، همچون شمشیر داموکلس، بر سر کدهای شما خواهند بود.
متاسفانه اپ‌استورهای معروف ایرانی تعهدی از توسعه‌دهنده درباره‌ی عدم استقاده از کدهای بدون مجوز اخذ نمی‌کنند و رویه‌ای برای شکایت از ناقضین ندارند و علاوه بر آن، خود نیز رأساً اقدام به بازتوزیع برنامه‌های خارجی، بدون اخذ رضایت از صاحب اثر می‌نمایند و اگر این رویه‌ی خود را مورد بازبینی قرار ندهند، ممکن است در آینده‌ای نزدیک مجبور به پرداخت خسارت‌های هنگفتی شوند.
باید توجه داشت که توزیع رایگان یک برنامه، به این معنا نیست که دریافت‌کننده حق توزیع مجدد آن را، حتی به صورت رایگان، داشته باشد. نمونه‌ی بارز آن یونیکس است که به همراه سورس توزیع شود و برای دانشگاهها رایگان است، اما این قبیل استفاده از آن بدون پرداخت هزینه‌های مربوطه ممکن نیست. بنابراین حتی بازتوزیع نرم‌افزارهای رایگان خارجی در استورهای ایرانی نیز احتمالاً بدون عواقب نیست.

آیا می‌توانم کدی که تحت مجوز MIT یا BSD منتشر شده را در برنامه‌ی تحت GPL استفاده کنم؟

احتمال زیادی وجود دارد که هر قسمت از یک پروژه‌ی بزرگ، تحت لایسنس جداگانه‌ای توزیع شده باشد. مثلاً در اندروید، هسته‌ی لینوکس تحت GPL، بیونیک (کتابخانه‌ی پوزیکس/سی) تحت BSD و بقیه‌ی قسمت‌ها عمدتاً بر اساس آپاچی منتشر شده‌اند. در سیستم عامل MacOSX، هسته‌ی Darwin و برخی اجزا تحت BSD و بقیه به صورت تجاری و سورس بسته هستند.
بنا بر یک قاعده‌ی کلی، شما می‌توانید مجوز یک کد را از یک لایسنس بازتر نظیر MIT، به لایسنس محدودتر نظیر GPL تغییر دهید، حتی اگر صاحب آن نباشید. ولی روند معکوس آن تنها برای صاحب اصلی اثر امکان‌پذیر است 6.
به عنوان مثال، با این که مجوز آپاچی همانند MIT آزاد است، ولی از نوع محدودتر قلمداد می‌شود،‌ پس نمی‌توان کدهای تحت آپاچی را با مجوز MIT بازنشر کرد.
به طور مختصر ترتیب مجوزهای متن‌باز، از بازترین به محدودترین، به شکل زیر است:
Public Domain -> MIT/X11 -> BSD -> Apache -> LGPL/MPL -> GPL -> AGPL

آیا برنامه‌ی تحت ویندوز، شامل لیسانس تجاری مایکروسافت خواهد شد؟

مایکروسافت به شما این اجازه را می‌دهد که در چارچوب سیستم عامل ویندوز، به dllهای سیستم‌عامل لینک دهید و از آن‌ها استفاده نمایید، اما این بدان معنا نیست که شما اجازه داشته باشید dllها را به برنامه‌ی خود اضافه نمایید. بنابراین استفاده از dllهای خود ویندوز، در سیستم‌عامل‌ها و شبیه‌سازهای غیرمایکروسافتی (نظیر ReactOS یا Wine)، غیرقانونی است و این‌ها به طور مستقل، پیاده‌سازی کدهایی را انجام داده‌اند که با اینترفیس برنامه‌نویسی ویندوز (Win32 API) سازگار هستند.

نویسنده: امیرعباس موسویان. پزشکی

@iranopensource 🐧

@iranopensource 🐧

سرویس ابری سیسکو Cisco Meraki Cloud-Managed MDM

آشنایی با سرویس ابری سیسکو Cisco Meraki Cloud-Managed MDM
آشنایی با سرویس ابری سیسکو Mobile device management

سیسکو شرکت جدیدی که فراهم کننده، MDM مدیریت شده از طریق ابر، ابزارهای بیسیم مدیریت شده از طریق ابر و سایر ادوات امنیتی است، را تاسیس کرده است. مدیریت پویای سازمانی مبتنی بر ابر سیسکو Meraki قابلیت پیش ثبت نام و یا ثبت دینامیک کاربران در شبکه سازمانی در زمان اتصال آن ها به شبکه را برای مدیران شبکه ها فراهم می آورد؛ مدیران شبکه امکان کنترل دسترسی به شبکه و بازنشانی نرم افزارهای و محدودسازی دسترسی به محتوای آن ها را براساس گروه های کاربری خواهند داشت.

پیش خوان مدیریتی وب محور سیسکو Meraki امکان تعیین، پایش، ردیابی و مدیریت تمامی کاربران و ابزارهای سیار را از هرنقطه جهان فراهم می آورد.

برای دریافت اطلاعات بیشتر به آدرس زیر مراجعه فرمایید:

https://meraki.cisco.com/products/systems-manager



ابزارهای امنیتی کنترل پذیر از طریق سیسکو Meraki

سیسکو Meraki ابزارهای امنیتی کنترل پذیر از طریق ابر با قابلیت های زیر را فراهم می آورد:

Identity-based firewall که به اعمال سیاست گذاری های شبکه و قوانین کنترل ترافیک، VLAN tags و کنترل پهنای باند براساس نوع کابران، می پردازد.
حفاظت در برابر نفوذ جهت شناسایی نفوذ و محافظت شبکه در برابر آن
قابلیت های VPN جهت اتصال امن به شعب دور با استفاده از توپولوژی mesh و یا hub-and-spoke
قابلیت های فیلترینگ محتوا، مقابله با بدافزارها و فیشینگ
دسترس پذیر بالا و Failover
برای کسب اطلاعات بیشتر در مورد راهکارهای سیسکو Meraki MDM به آدرس https://meraki.cisco.com/products مراجعه فرمایید.

راهکارهای VPN در فایروال سیسکو

شرکت های متعددی از VPN به منظور حفظ یکپارچگی اطلاعات، اعتبارسنجی و رمزنگاری داده ها به منظور حفظ محرمانگی پکت های ارسال شده در اینترنت استفاده می کنند. بسیاری از پروتکل ها برای پیاده سازی VPN استفاده می شوند مانند:

PPTP، L2F، L2TP، GRE، MPLS، IPsec، SSL

پیاده سازی VPN می تواند به دو شکل صورت گیرد:

ارتبا Site-To-Site VPNs : در این شرکت ها امکان پیاده ساز ی VPN ، در دو یا چند ابزار زیرساختی در محل های مختلف که با هم از طریق یک محیط اشترکی مانند اینترنت در ارتباط هستند، وجود دارد. بسیاری از شرکت ها از IPsec, GRE, or MPLS VPN به عنوان پروتکل site-to-site VPN استفاده می کنند.
ارتباط Remote-access VPNs : چنانچه امکان اتصال مستقیم به شبکه داخلی شرکت وجود داشته باشد به کاربران قابلیت دسترسی از راه دور با آن را برقرار می کند ( مانند منزل، هتل و ..). بسیاری از شرکت ها از IPsec و SSL VPN جهت remote-access VPNs استفاده می کنند.
سیسکو مجموعه جامعی از نمونه های VPN شامل site-to-site VPNs در سیستم عامل اداوات خود و همچنین سیسکو ASA ، فراهم آورده است. Remote-access VPN شامل clientless SSL VPN و در ارتباطات میان کلاینت ها از طریق Cisco AnyConnect Secure Mobility

فایل Fortinet Product Matrix جهت Device Selection در پروژه های شبکه و امنیت

مفهوم Correlation در SIEM چیست؟