کدهالیک | codehalic
3.47K subscribers
319 photos
8 videos
66 files
359 links
دوره های آموزشیمون رو از داخل سایت ببینید

https://codehalic.ir
Download Telegram
کدهالیک | codehalic
امروز می‌خوام ادامه قوانین مهندسی نرم‌افزار رو ببرم سراغ یکی از خطرناک‌ترین باگ‌های ذهنی که حتی از باگ‌های کد هم بدتره؛ اثر Confirmation Bias یا سوگیری تأییدی. مغز ما دنبال حقیقت نیست، دنبال تأیید چیزیه که از قبل بهش باور داریم. وقتی یه فرض تو ذهنمون شکل می‌گیره…
قبل تر ها هم اینو بررسی کردیم اما امروز برای اینکه صحه بزارم رو صحبت دوست عزیزمون دوباره با بیان خودش بیانش کردم
اونروز یادم رفت از خاطرات خودم راجب بایاس بگم
تقریبا اگر بخوام بگم یکی از مهم ترین چیز هایی ک یه تیم نرم افزاری رو از هم میپاشونه چیه دقیقا میگم همین کانفرمیشن بایاس عه اس !
از اون سمت پروداکت میگه من درست میگم تو برنامه نویس میگی نه من درست میگم یکی دیگ میگه نه من درست میگم میزنید تو سر کله هم دیگ !

حالا سوال پیش میاد دوست دارم که جواب بدید فرض کن یه تیمی همشون دچار این بایاسه شدن و هیچ جوره حل نمیشه داستانت باهاشون رفتار تو نسبت به این داستان چیه ؟!

feel free to explain your idea in comment :

@codehalics | کدهالیک
1
کدهالیک | codehalic
قبل تر ها هم اینو بررسی کردیم اما امروز برای اینکه صحه بزارم رو صحبت دوست عزیزمون دوباره با بیان خودش بیانش کردم اونروز یادم رفت از خاطرات خودم راجب بایاس بگم تقریبا اگر بخوام بگم یکی از مهم ترین چیز هایی ک یه تیم نرم افزاری رو از هم میپاشونه چیه دقیقا میگم…
چهار مدل این سوال در مصاحبه ها همیشه پرسیده میشه من توی 4 تیپ آوردمش جواب این سوال با جواب سوالای پایین تقریبا یکیه

فرض کن در یک موقعیت کاری، نسبت به درست بودن یک تصمیم یا راه‌حل اطمینان داری، اما مدیر یا فرد بالادستی‌ات نظر متفاوتی دارد و روی تصمیم خودش پافشاری می‌کند. در چنین شرایطی چطور رفتار می‌کنی؟


فرض کن توی تیم، تو مطمئنی یک راه‌حل درست‌تره، ولی مدیرت یا کسی که از تو ارشدتره میگه نه، نظر من درسته. تو توی این موقعیت چطور برخورد می‌کنی؟

اگر در محیط کار با موقعیتی مواجه شوی که بر اساس دانش، تجربه یا داده‌هایی که داری، فکر می‌کنی یک تصمیم درست نیست، اما مدیر یا فرد بالادستی‌ات با تو مخالف است، چطور موضوع را مطرح و مدیریت می‌کنی؟

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


پس در نهایت دوست دارم نظرتونو بدونم ! بعد امشب راجبش صحبت میکنیم حتما حتی اگر نظری ندادید من نظر و تجربه شخصیم توی جواب این سوال رو میگم


@codehalics | کدهالیک
3🙏1
Forwarded from تهلاگ / Tehlug
بیش از دو ماهه که اینترنت توی ایران قطع شده.

توی این شرایط سخت، برنامه‌نویس ها، DevOpsها و هر کسی که به ریپوها و میرورهای Docker, Linux, NPM, Golang, Python, Java و ... نیاز داره، واقعاً به مشکل خورده.

برای همین ما پروژه «میراوا» رو ساختیم.

این پروژه یک لیست از ریپوزیتوری‌ها و میرورهای داخلی و قابل دسترس هست که تو این وضعیت کمک می‌کنه بهمون

شما می‌تونین توی سایت، راحت سرچ کنین

مثلاً ریپو برای Kali Linux رو جست‌وجو می‌کنین و دقیقاً می‌بینین که کدوم ریپو فعال هست، کدوم در دسترسه و به راحتی به منابع مورد نیازتون دست پیدا می‌کنین.

سایت پروژه:
https://miravaorg.ir/

کانال اطلاع رسانی میراوا:
https://xn--r1a.website/miravaorg

گیت‌هاب:
https://github.com/MiravaOrg/Mirava

@TehranLUG
🙏2
کدهالیک | codehalic
چهار مدل این سوال در مصاحبه ها همیشه پرسیده میشه من توی 4 تیپ آوردمش جواب این سوال با جواب سوالای پایین تقریبا یکیه فرض کن در یک موقعیت کاری، نسبت به درست بودن یک تصمیم یا راه‌حل اطمینان داری، اما مدیر یا فرد بالادستی‌ات نظر متفاوتی دارد و روی تصمیم خودش…
من اگر بخوام جواب این سوال رو بدم، میگم:

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

بعد اگر همچنان فکر کنم تصمیم اشتباهه، مخالفت رو شخصی نمی‌کنم. می‌گم نگرانی من اینه که این تصمیم ممکنه این پیامدها رو داشته باشه؛ مثلاً روی زمان، کیفیت، هزینه، تجربه کاربر یا ریسک فنی اثر بذاره. ترجیح می‌دم به‌جای اینکه بگم «این غلطه»، بگم «من این ریسک‌ها رو می‌بینم و پیشنهاد جایگزینم اینه». حتی اگر لازم باشه، سعی می‌کنم یک تست کوچک، دیتای بیشتر، نمونه واقعی یا راه‌حل میانی پیشنهاد بدم تا بحث از حالت سلیقه‌ای خارج بشه.

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

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

@codehalics | کدهالیک
6👍3
کدهالیک | codehalic
من اگر بخوام جواب این سوال رو بدم، میگم: به‌نظرم اولین واکنش درست این نیست که سریع وارد جنگ «من درست می‌گم، تو اشتباه می‌گی» بشم. چون خیلی وقت‌ها ما فکر می‌کنیم مطمئنیم، ولی بخشی از اطلاعات، محدودیت‌ها یا ملاحظات مدیریتی رو نمی‌دونیم. برای همین اول سعی می‌کنم…
این هفته یه کاری کردم که از نظر خودم درست بود. براش یه دمو آماده کردم که شنبه با مدیرعامل شرکت مطرحش کنیم. شاید قبول بشه، شاید هم رد بشه. اگر رد بشه، طبیعتاً ناراحت می‌شم، چون برای چیزی که بهش باور داشتم وقت گذاشتم؛ ولی خب حتماً دلایلی وجود داره که باید بشنوم، همون‌طور که من هم دلایلی دارم که باید شنیده بشه.

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

@codehalics | کدهالیک
👍32
🚨 یه آسیب‌پذیری خیلی جدی توی Next.js پیدا شده (CVSS 8.6) که نسخه‌های 13.4.13 به بعد، سری 14 و 15، و همینطور 16.0.0 تا 16.2.4 رو درگیر کرده.

این باگ از نوع SSRF ـه و مهاجم می‌تونه فقط با یه request ساده و بدون لاگین، به سرویس‌های داخلی، API Keyها، credentialهای cloud و حتی پنل‌های ادمین دسترسی پیدا کنه

گفته میشه الان حدود ۷۹ هزار instance آسیب‌پذیر روی اینترنت وجود داره.
البته اپ‌هایی که روی Vercel هستن امن اعلام شدن و بیشتر self-hostedها در خطرن.

اگر از Next.js استفاده می‌کنید، سریعاً به نسخه‌های زیر آپدیت کنید:
15.5.16
16.2.5+

https://hadrian.io/blog/next-js-websocket-ssrf-unauthenticated-access-to-internal-resources-cve-2026-44578-2-


@codehalics | کدهالیک
😢4👍21
هر روز اینترنتو باز می‌کنی:
«اینو هک کردیم»، «اونو اکسپلویت کردیم»، «اون‌ور بک‌دور کشف شد»...

آقا این چه وضعشه؟ یکی دوتا خبر درست‌وحسابی و امیدوارکننده بدید، شاید تو این بی‌اینترنتی یه ذره حالمون خوب شد :)))))))

من دیگه حتی حوصله ندارم بگم nginx هم امروز از گزند داسِ دروگر در امان نبوده و دوباره ترکوندنش...

exploit for CVE-2026-42945

https://github.com/DepthFirstDisclosures/Nginx-Rift

@codehalics | کدهالیک
👨‍💻3👍1😁1
۳ تا مدل معروف برای reorder کردن لیست‌ها وجود داره، مخصوصا جاهایی مثل تسک‌های جیرا که مدام drag & drop انجام میشه:

* ساده‌ترین و بدترین حالت اینه که هر آیتم یه عدد ترتیبی داشته باشه (۱،۲،۳،۴...). مشکلش اینه که اگر یه آیتم وسط لیست جابه‌جا بشه، باید position کلی آیتم بعدش آپدیت بشه که روی دیتاست بزرگ عملاً فاجعه‌ست و complexity میره سمت O(N).

* مدل بهتر اینه که بین اعداد gap بذاری. مثلا به جای ۱،۲،۳ از ۱۰،۲۰،۳۰ استفاده کنی. اینجوری اگر بخوای یه آیتم بین ۲۰ و ۳۰ بذاری، میتونی راحت ۲۵ بدی و اکثر مواقع بدون reorder کار انجام میشه. مشکلش اینه که بعد از مدتی gap ها پر میشن و مجبوری کل sequence رو دوباره rebuild کنی.

* حرفه‌ای‌ترین مدل هم چیزیه که Jira استفاده میکنه؛ یعنی LexoRank. اینجا به جای عدد، از string های sortable استفاده میشه (مثل a ،ab ،acz و …). مزیتش اینه که همیشه میشه بین دو آیتم یه مقدار جدید ساخت بدون اینکه بقیه آیتم‌ها تغییر کنن.


سورس این پست از لینکدین پوریا فرامرزی

@codehalics | کدهالیک
5👍32
کدهالیک | codehalic
۳ تا مدل معروف برای reorder کردن لیست‌ها وجود داره، مخصوصا جاهایی مثل تسک‌های جیرا که مدام drag & drop انجام میشه: * ساده‌ترین و بدترین حالت اینه که هر آیتم یه عدد ترتیبی داشته باشه (۱،۲،۳،۴...). مشکلش اینه که اگر یه آیتم وسط لیست جابه‌جا بشه، باید position…
لکسو‌رنک دقیقا برای حل مشکل reorder کردن لیست‌های خیلی بزرگه. مثلا توی جیرا وقتی یه تسک رو drag میکنی بین دوتا تسک دیگه، نمیاد position صد هزار تا رکورد رو آپدیت کنه چون از نظر دیتابیسی فاجعه‌ست. به جاش هر تسک یه rank استرینگی داره که sortable ـه و الگوریتم میتونه همیشه بین دو تا rank یه rank جدید بسازه. مثلا اگه داشته باشیم:


ali_1210
ali_1211


و بخوای یه تسک بین این دوتا بیاد، میتونه یه چیزی مثل ali_1210V تولید کنه که وقتی sort الفبایی انجام بشه دقیقا بین اون دوتا بشینه، بدون اینکه بقیه آیتم‌ها reorder بشن.

اصل ایده‌ش اینه که به جای integer sequence از fractional string استفاده میکنه. یعنی همیشه میشه قبل یا بعد یه آیتم یه rank جدید ساخت و فقط همون رکورد آپدیت میشه. برای همین performance روی board های خیلی بزرگ عالی میمونه و drag & drop عملا O(1) میشه. فقط اگر سال‌ها هی بین دو آیتم insert انجام بشه، رشته‌ها ممکنه خیلی بلند بشن و سیستم هر از گاهی یه rebalance انجام بده تا rank ها normalize بشن.


@codehalics | کدهالیک
👏6👍2🤯21
Forwarded from کار باشه !
📢 فرصت همکاری ریموت (پروکسی)

- Django+React
- Node+React

شرایط: حداقل ۴ سال سابقه مرتبط، مکالمه انگلیسی عالی، اینترنت پایدار (ترجیحاً خارج از ایران؛ اگر داخل ایران هستید اینترنت ثابت و مطمئن لازمه).

حقوق: از ماهی ۲۰۰۰ دلار (پرداخت با USDT)

ارسال رزومه:
رزومه‌تون رو بفرستید به Yasaman.aboodi@gmail.com

فقط لطفاً عنوان موقعیت رو توی Subject ایمیل بنویسید.

منتظر رزومه هاتون هستیم.

#backend
#frontend


💬 @job_bashe | گروه کار باشه با دسته بندی شغلی
📢 @karbashe_ir | کانال کار باشه
👀3🥰1
بهم ریختگی فارسی تو ترمینال #vscode با این درست میشه:

"terminal.integrated.fontFamily": "Cascadia Mono, Vazirmatn FD, Consolas, Courier New, monospace",
"terminal.integrated.gpuAcceleration": "off",
"terminal.integrated.fontSize": 15,
"terminal.integrated.lineHeight": 1.1,

سورس پست

@codehalics | کدهالیک
🔥21🆒1
با این لایبری که نوشتم به راحتی و بدون بروزر و در یک ثانیه میتونید چلنج آروان رو (همون که مینویسه «در ﺣﺎل اﻧﺘﻘﺎل ﺑﻪ ﺳﺎﯾﺖ ﻣﻮرد ﻧﻈﺮ ﻫﺴﺘﯿﺪ...») که مثلاً برای جلوگیری از کراولر و روبات‌هاست رو دور بزنید.
سورس رایگان:
https://github.com/NabiKAZ/arvancloud-bypass

Source

@codehalics | کدهالیک
3🔥2🙏1
اثر سیگموئیدی خیلی ساده می‌گه هر چیزی که یه مدت رشد نمایی و انفجاری داره، بالاخره یه جایی به محدودیت می‌خوره و رشدش کند می‌شه؛ یعنی نمودارش از حالت «همین‌جوری می‌ره بالا» تبدیل می‌شه به یه منحنی S شکل که کم‌کم صاف می‌شه. نویسنده این مقاله می‌گه راجب هوش مصنوعی شاید این حرف درسته، اما مشکل اینجاست که بعضی‌ها ازش یه نتیجه اشتباه می‌گیرن: می‌گن چون هوش مصنوعی هم بالاخره یه روزی کند می‌شه، پس الان لازم نیست خیلی جدی نگران رشد سریعش باشیم. حرف اصلی متن اینه که «کند شدنِ یک روند» حتماً اتفاق می‌افته، ولی هیچ تضمینی نیست که همین الان یا همین یکی دو سال آینده اتفاق بیفته. درباره هوش مصنوعی هم می‌گه اگر کسی ادعا می‌کنه رشد AI قبل از رسیدن به سطح‌های خیلی جدی و خطرناک متوقف می‌شه، باید دقیق توضیح بده چرا؛ مثلاً به خاطر محدودیت دیتاسنتر، داده، هزینه، الگوریتم یا چیزهای واقعی دیگه. صرفاً گفتنِ «همه رشدها آخرش سیگموئیدی می‌شن» کافی نیست، چون ممکنه هوش مصنوعی قبل از اینکه کند بشه، چند سال دیگه هم با همین سرعت جلو بره.

https://www.astralcodexten.com/p/the-sigmoids-wont-save-you

@codehalics | کدهالیک
2🤩1
خب امروز یکی دیگ از قوانین مهندسی نرم افزار که داره به KISS صحه میزاره رو قراره بررسی کنیم !
قانون کرنیگان می‌گه وقتی کدی رو زیادی پیچیده و هوشمندانه می‌نویسی، بعداً برای پیدا کردن باگ‌هاش چند برابر بیشتر اذیت می‌شی. موقع نوشتن کد، همه‌چیز توی ذهنت واضحه، ولی چند روز یا چند ماه بعد، همون کد می‌تونه برات تبدیل به یه معما بشه. پس بهتره کد رو ساده، خوانا و قابل‌فهم بنویسی؛ چون کدی که راحت فهمیده می‌شه، راحت‌تر هم درست و نگهداری می‌شه.

#lawsofsoftwareengineering

@codehalics | کدهالیک
2👍1
کدهالیک | codehalic
خب امروز یکی دیگ از قوانین مهندسی نرم افزار که داره به KISS صحه میزاره رو قراره بررسی کنیم ! قانون کرنیگان می‌گه وقتی کدی رو زیادی پیچیده و هوشمندانه می‌نویسی، بعداً برای پیدا کردن باگ‌هاش چند برابر بیشتر اذیت می‌شی. موقع نوشتن کد، همه‌چیز توی ذهنت واضحه،…
به طور مثال میگه یه روز پا میشی میای همچین کدی مینویسی میگی به به چه چه :

public string GetUserDisplay(User u) =>
u?.IsActive == true ? (u.Name ?? "").Trim() is var n && n.Length > 0
? n + (u.Role > 0 ? $" ({(Role)u.Role})" : "") : "Unknown" : "Inactive";

پس فردا یه باگ میخوری ولی نمیدونی از کدوم قسمتش ممکنه باشه چون بسیار خفن و پیچیده نوشتی ولی دیگ یه سال دیگ عقل امروزت که کدتو نوشتی رو نداری برمیگردی میگی این شتو کی نوشته بعد گیت لنز رو نگاه میکنی میبینی عه ایمیل خودته !

ولی میتونستی اینطوری بنویسیش

public string GetUserDisplay(User user)
{
if (user is null || !user.IsActive)
return "Inactive";

var name = user.Name?.Trim();

if (string.IsNullOrEmpty(name))
return "Unknown";

if (user.Role > 0)
return $"{name} ({(Role)user.Role})";

return name;
}

از نظر عملکرد کاملا مشابه هم دیگس ولی خوانایی این کد کجا اون کجا پس KISS مرد بزرگ !
@codehalics | کدهالیک
🆒1
کدهالیک | codehalic
خب امروز یکی دیگ از قوانین مهندسی نرم افزار که داره به KISS صحه میزاره رو قراره بررسی کنیم ! قانون کرنیگان می‌گه وقتی کدی رو زیادی پیچیده و هوشمندانه می‌نویسی، بعداً برای پیدا کردن باگ‌هاش چند برابر بیشتر اذیت می‌شی. موقع نوشتن کد، همه‌چیز توی ذهنت واضحه،…
این قانون یه پاراگراف طلایی داره که کرنیگان توی کتابش توی سال 1974(ببین دغدغه ملتو) نوشته که میگه :

The clever version might have taken 30 minutes to write, but debugging took 3 hours. Had the code been written clearly, it would’ve taken 45 minutes to write, but only 30 minutes to debug later.

@codehalics | کدهالیک
2
توی مک ابزار های زیادی برای وصل شدن به دیتابیس هست مثل navicat و datagrip و غیره که بعضا پولین
یه ابزار خیلی خوب که اوپن سورس و رایگانه و دیزاین شکیل و مک پسندی هم داره tablepro عه بنظرم ارزش نگاه کردن داره یه سر به ریپوش و سایتش بزنید !

https://tablepro.app/

https://github.com/TableProApp/TablePro

@codehalics | کدهالیک
👍2🆒1
خیلی دیدم آدما میشینن یه ابزار درست میکنن برای نوبت دهی و این چیزا یه پروژه اوپن سورسی که میتونی لوکالایزش کنی و بفروشیش همین پروژه cal.diy عه که خیلی تر تمیز و خفن با nextjs و trpc و اینا دولوپ شده میتونی سلف هاستد بیاری بالا بفروشیش به کلینیک های دندون پزشکی و آرایشگاها و اینا ! خیلی تر تمیزم هست واقعا و دیزاین خیلی خفنی داره بنظرم این ایده ها میتونه جذاب باشه ما که ایرانیزه میکنیم میتونیم اینارم بزنیم بفروشیم یه رزق حلالی ( ایشاله البته لایسنسش اجازه میده بهتون که حلال وار ازش پول درارید ) بزنید بر بدن !

https://github.com/calcom/cal.diy


@codehalics | کدهالیک
5🫡1
کدهالیک | codehalic
خیلی دیدم آدما میشینن یه ابزار درست میکنن برای نوبت دهی و این چیزا یه پروژه اوپن سورسی که میتونی لوکالایزش کنی و بفروشیش همین پروژه cal.diy عه که خیلی تر تمیز و خفن با nextjs و trpc و اینا دولوپ شده میتونی سلف هاستد بیاری بالا بفروشیش به کلینیک های دندون پزشکی…
فارسی نداره ولی arabic داره پس rtl داره و بعد il18n رو کانفیگ کرده کل داستانش اینه که یه فایل جیسون توش ترجمه کنین و ایزی ایزی تمام تمام
بعد بگردید دنبال مشتری و بفروشین بهش
ایده درآمد زیاده واقعا حتی همین n8n ام دیدم یکی داره میفروشه ( با اینکه نمیشه فروختش و لایسنسش میگه نباید بفروشی ! ) اما خب یه ترای کنین چیزای خوبی میشه ازش درآورد احتمالا

@codehalics | کدهالیک
1👏1🫡1
کدهالیک | codehalic
خیلی دیدم آدما میشینن یه ابزار درست میکنن برای نوبت دهی و این چیزا یه پروژه اوپن سورسی که میتونی لوکالایزش کنی و بفروشیش همین پروژه cal.diy عه که خیلی تر تمیز و خفن با nextjs و trpc و اینا دولوپ شده میتونی سلف هاستد بیاری بالا بفروشیش به کلینیک های دندون پزشکی…
اگه حلال و حروم سرتون میشه، قبل از استفاده از هر پروژه اوپن‌سورس، اول فایل LICENSE.md رو چک کنید. اینکه کد روی گیت‌هاب هست، یعنی قابل دیدنه، نه لزوماً قابل فروش یا استفاده تجاری.

به طور ساده، لایسنس‌هایی مثل MIT، Apache 2.0 و BSD معمولاً اجازه استفاده تجاری، تغییر و حتی فروش میدن، البته به شرط حفظ متن لایسنس و کپی‌رایت. GPL، AGPL و LGPL هم قابل استفاده تجاری هستن، ولی شرط دارن و ممکنه مجبور بشی سورس‌کد تغییراتت رو هم منتشر کنی. اما ریپوی بدون لایسنس، لایسنس‌های Non-Commercial و پروژه‌های Source-Available معمولاً مجوز واضحی برای فروش یا استفاده تجاری بهت نمی‌دن.

خلاصه اینکه: اوپن‌سورس بودن یعنی آزاد بودن طبق قانون لایسنس، نه آزاد بودن برای هر کاری.

@codehalics | کدهالیک
1👍1