60-second brief
This is an original IROSG editorial analysis based on the cited primary source.
- قابلیت Open source license compliance برای مشتریان GitHub Enterprise Cloud با GitHub Code Security به GA رسیده است.
- سیاست مجوز می‌تواند در سطح Enterprise تعریف و با Ruleset روی Repositoryها اعمال شود.
- شرط «Require license compliance results before merging» می‌تواند نتیجهٔ بررسی dependencyهای تازه یا تغییرکرده را وارد مسیر Merge کند.
What changed?
خبر مهم فقط اضافه‌شدن یک Check جدید نیست؛ GitHub می‌خواهد تصمیم حقوقی و فنی دربارهٔ مجوز dependencyها از فایل‌های پراکنده و review دستی، به یک Policy مرکزی و قابل ممیزی نزدیک شود. برای سازمانی که ده‌ها یا صدها Repository دارد، تفاوت واقعی اینجاست: مجوز یک کتابخانه دیگر صرفاً مسئلهٔ تیم حقوقی در انتهای پروژه نیست و می‌تواند همان جایی دیده شود که dependency وارد کد می‌شود.
Technical view
این قابلیت روی سازوکار Dependency Review سوار می‌شود و سیاست سازمانی را با Ruleset ترکیب می‌کند. وقتی Pull Request dependency تازه‌ای اضافه یا نسخهٔ موجودی را عوض می‌کند، GitHub می‌تواند مجوز آن را با Policy سازمان مقایسه کند و نتیجه را در PR نشان دهد. از دید معماری DevSecOps، این یعنی License Governance به همان نقطه‌ای نزدیک می‌شود که Code Scanning، Branch Protection و Approvalها قرار دارند؛ البته کیفیت نتیجه همچنان به شناسایی درست dependency و metadata مجوز وابسته است.
Who should care?
تیم‌های Platform Engineering، AppSec، Open Source Program Office، حقوقی و مالکانی که Rulesetهای GitHub را مدیریت می‌کنند باید این تغییر را ببینند. توسعه‌دهنده هم باید بداند Fail شدن این Check الزاماً به معنی «کتابخانه ناامن» نیست؛ موضوع می‌تواند صرفاً ناسازگاری مجوز با Policy تجاری سازمان باشد.
Before adopting
قبل از فعال‌سازی سراسری، فهرست مجوزهای مجاز/ممنوع را با تیم حقوقی نهایی کنید، روی چند Repository آزمایشی Ruleset بسازید، false positiveها و dependencyهای بدون metadata را ثبت کنید و مسیر Exception را مشخص کنید. Policy بدون Exception process معمولاً یا دور زده می‌شود یا تیم‌ها را به pin کردن dependencyهای قدیمی سوق می‌دهد.
Caveat
مجوز نرم‌افزار مسئله‌ای حقوقی است و Check خودکار جای تحلیل حقوقی را نمی‌گیرد. همچنین نام مجوز در package metadata همیشه تمام تعهدات واقعی یک dependency یا کد vendored را توضیح نمی‌دهد. این ابزار را Gate اولیه و ابزار Governance ببینید، نه مشاور حقوقی خودکار.
What to watch
در هفته‌های بعد باید دید APIها، audit log، مدیریت Exception و پوشش ecosystemها چقدر برای سازمان‌های بزرگ کامل می‌شود. برای تیم IROSG، مهم‌ترین سؤال این است که آیا می‌توان خروجی این Policy را با SBOM و فرایند Release Management یکپارچه کرد یا نه.
