مجوز ابزار تست متن‌باز؛ از Artifact تا Obligation

استفاده از ابزار تست متن‌باز با برچسب «رایگان»، «Permissive» یا «GPL» تصمیم حقوقی کاملی نمی‌سازد. باید Artifact دقیق، Version/Digest، متن و Expression مجوز، شیوهٔ تعامل، تغییرات، خروجی، گیرنده و نوع تحویل مشخص شود. یک Runner که فقط در CI اجرا می‌شود با Library لینک‌شده، Plugin توزیع‌شده یا Container تحویلی یک سناریو نیست.

این راهنما Open-Source Test Tool Use Record را می‌سازد: Inventory و License evidence، `AND/OR/WITH`، Interaction/Delivery، Obligation matrix، Notice/Source bundle، Contribution، Patent/Trademark، Automation limits، Review/Decision و Remediation. این Record جای تفسیر License یا نظر حقوقی صلاحیت‌دار نیست و مجوز توزیع صادر نمی‌کند.

مالکیت این مقاله و مرز موضوع

این صفحه فقط «مجوز استفادهٔ موردی از یک Artifact ابزار تست متن‌باز» را مالک است. برای انتخاب OSS یا Commercial، امنیت پروژه، TCO، Support و Exit به راهنمای ابزار تست متن‌باز یا تجاری بروید. برای Component inventory و قالب‌های SPDX/CycloneDX، راهنمای SBOM مالک است. برای اجرای SCA و Triage یافته، راهنمای SAST/DAST/SCA را ببینید.

برای Control/Evidence خط لوله از DevSecOps در CI/CD، برای معماری و PoC فریم‌ورک از انتخاب فریم‌ورک اتوماسیون، برای مقایسهٔ Runner/Driver از انتخاب ابزار اتوماسیون تست، برای Connector/Artifact flow از یکپارچه‌سازی ابزارهای تست و برای اشتراک با پیمانکار/Crowdtester از قرارداد همکاری تست برون‌سازمانی استفاده کنید.

Open Source، Source available، رایگان و Commercial

Open Source فقط دیدن Source نیست؛ نرم‌افزار تحت مجوزی است که معیارهای Open Source را برآورده می‌کند. رایگان‌بودن قیمت، نوع License را تعیین نمی‌کند. Commercial به کسب‌وکار/فروش مربوط است و Proprietary به حقوق و محدودیت‌های دریافت‌کننده؛ این دو مترادف نیستند. Open-core، Community edition، Plugin marketplace و SaaS ممکن است Terms متفاوت داشته باشند.

پشتوانهٔ رسمی و حد استفاده

فهرست رسمی مجوزهای تأییدشدهٔ OSI هویت Open Source و License text را فراهم می‌کند؛ تأیید OSI به معنی تأیید Usage خاص سازمان نیست. مشخصات رسمی SPDX License Expression نمایش Licenseها/Exceptionها را استاندارد می‌کند. FAQ رسمی GNU دربارهٔ مجوزهای GPL نشان می‌دهد اجرای ابزار، Output، Linking، Plugin و Conveying پرسش‌های جدا دارند. FAQ رسمی OpenChain ISO/IEC ۵۲۳۰ صریحاً می‌گوید برنامهٔ Compliance، تفسیر هر License یا تضمین رعایت نیست و Legal expert لازم است. این منابع چارچوب می‌دهند؛ مقاله نظر حقوقی دربارهٔ پروندهٔ شما نیست.

چرخهٔ OSS Test Tool Use Record

1. Request: Purpose، Product، recipients و Delivery plan.
2. Identify: Package/Source/Binary/Container با Version و Digest.
3. Inventory: Direct/Transitive/Plugin/Asset/Generated artifact.
4. Conclude: متن واقعی License و SPDX expression.
5. Model: Execute/Link/Plugin/Modify/Generate/Embed.
6. Map: Internal/Contractor/Customer/SaaS/Public delivery.
7. Analyze: Boundary/Trigger با Legal expert.
8. Build: Obligation/Notice/Source/Offer/Instruction pack.
9. Review: Engineering/Security/Procurement/Legal/Release.
10. Decide: Allow/Condition/Hold/Reject با Expiry.
11. Verify: Artifact و Bundle واقعی Release.
12. Monitor/Repair: Upgrade/License/Delivery change و Remediation.

Use Record identity

`RecordID`، Version، Status، Supersedes، Owner، CreatedAt، AsOf، ReviewAt و ExpiresAt را ثبت کنید. وضعیت‌ها می‌توانند `PROPOSED / HOLD / CONDITIONALLY_APPROVED / APPROVED_FOR_SCOPED_USE / REVOKED / EXPIRED / SUPERSEDED` باشند. Approval برای v1.۴ داخلی، خودکار v2.۰ یا Image مشتری را پوشش نمی‌دهد.

RecordID: OSS-USE-SYN-IR-023
Version: 1.0
Status: PROPOSED
Purpose: اجرای Runner ساختگی در CI آفلاین
Artifact: pkg:generic/fake-test-runner@1.4.2
Digest: sha256:SYNTHETIC_NOT_A_REAL_DIGEST
Delivery: INTERNAL_CI_ONLY
Decision: NOT_YET_APPROVED

Request قبل از Download

Purpose، Test use، Product/Project، Business model، Recipients، Release، Service model، Jurisdictions و Out-of-scope را روشن کنید. «برای Automation لازم است» کافی نیست. آیا Tool فقط اجرا می‌شود، بخشی از Product است، Image آن تحویل می‌شود، Code تولید می‌کند یا کاربران از Network با نسخهٔ اصلاح‌شده سرویس می‌گیرند؟

Artifact را با نام پروژه یکی نکنید

نام، Supplier/Publisher، Repository، Version، Commit، Tag، Package URL، Source digest، Binary/Image digest، Download source و Build provenance لازم است. Package همنام، Fork، Community/Enterprise edition یا Binary mirror ممکن است License/contents دیگری داشته باشد. Homepage Evidence نسخهٔ مصرفی نیست.

Source و Binary را به هم وصل کنید

Source tree دارای License با Binary تحویلی برابر فرض نمی‌شود. Build recipe، resolved graph، vendored code، generated files، assets، fonts و Container layers را به Digest خروجی وصل کنید. اگر Reproducible build ندارید، Provenance و تفاوت‌های شناخته‌شده را ثبت کنید.

Inventory فراتر از Dependency مستقیم

Direct/Transitive dependency، Plugin/Extension، Browser binary/Driver، Container layer، Test reporter، Template، Generated runtime، Asset، Documentation، Font، Dataset و Model را ببینید. یک Test tool می‌تواند خودش ده‌ها Artifact را Download کند؛ Lockfile ناقص یا Runtime download باید Unknown بماند.

Declared license با Concluded license فرق دارد

Declared expression از Metadata می‌آید؛ Concluded expression حاصل بررسی متن/Header/File/Exception در Artifact دقیق است. `NOASSERTION`، `LicenseRef-*` و Unknown file را به «MIT» تبدیل نکنید. Repository root license ممکن است Third-party directory یا Asset را پوشش ندهد.

SPDX expression را دقیق بخوانید

Expression	معنای داده‌ای	کار بعدی
MIT	یک شناسه	متن و Obligation همان Artifact
MIT OR Apache-2.0	انتخاب مجوز	Choice و Authority ثبت شود
MIT AND Apache-2.0	مجموعه شرایط	هر دو در Matrix بررسی شوند
GPL-2.0-only WITH Classpath-exception-2.0	License همراه Exception	Exception text/Scope خوانده شود
LicenseRef-Custom	متن غیر استاندارد	متن Pin و Review تخصصی

SPDX ID یا Expression تفسیر حقوقی و Compatibility verdict نیست؛ هویت قابل‌ماشین‌خواندن است. `-only` و `-or-later`، Parenthesis و Exception را حذف نکنید. انتخاب در `OR` باید پیش از Release ثبت شود.

Permissive به معنی بدون تعهد نیست

Licenseهای Permissive معمولاً حقوق گسترده می‌دهند، اما Copyright/permission notice، License copy، Disclaimer، Attribution/NOTICE، modification notice، Patent یا Trademark boundary می‌تواند مهم باشد. «کم‌تعهد‌تر» یک طبقه‌بندی عملی است؛ برای Artifact/Delivery واقعی Matrix لازم است.

MIT را از متن بخوانید

متن OSI برای MIT حقوق use/copy/modify/merge/publish/distribute/sublicense/sell را همراه شرط درج Copyright notice و Permission notice در copies/substantial portions می‌آورد و Warranty disclaimer دارد. اینکه Product شما «substantial portion» یا Bundle خاص چگونه است، از یک پاراگراف فارسی قطعی نمی‌شود؛ Artifact و Release توسط Reviewer بررسی شود.

Apache-۲.۰ فقط MIT طولانی‌تر نیست

License text و NOTICE موجود، Copyright، تغییرات، Attribution، Patent grant/termination و Trademark boundary را بررسی کنید. هر Apache project ممکن است Third-party works در LICENSE/NOTICE داشته باشد. «Apache پس تجاری کاملاً امن» Patent clearance، Compatibility یا رعایت Bundle را ثابت نمی‌کند.

Copyleft را «ویروسی» ننامید

این واژه فنی/حقوقی دقیق نیست و تصمیم را با ترس جایگزین می‌کند. سؤال درست: کدام License/version/exception، کدام Work boundary، چه Interaction، چه Modification و چه Convey/Distribution/Network use رخ می‌دهد و Recipient چه حقوقی باید دریافت کند؟ پاسخ از متن و Legal review می‌آید.

GPL همیشه کل سورس شرکت را منتشر نمی‌کند

صرف وجود Tool GPL روی همان سیستم، اجرای Compiler/Test runner یا تولید Report لزوماً حکم «همهٔ کد Proprietary باید GPL شود» نمی‌سازد. Linking/Combining/Modification/Distribution و Output containing covered code مهم‌اند. FAQ رسمی GNU نیز این سناریوها را جدا پرسش می‌کند. Boundary خاص را Legal expert تعیین کند.

Internal use با Delivery یکی نیست

استفاده صرفاً داخل یک سازمان، اشتراک با Affiliate، Contractor، مشتری، Device، Container registry، CI artifact، App store یا Public download یکسان فرض نشود. هویت Recipient و حق دسترسی/کپی مهم است. «فایل رایگان بود» Obligation تحویل شما را حذف نمی‌کند.

SaaS و Network use را جدا ثبت کنید

کاربر ممکن است Binary دریافت نکند ولی از سرویس Network استفاده کند. Licenseهای مختلف Triggerهای متفاوت دارند؛ نام «Copyleft» کافی نیست. AGPL یا Custom terms، Modified server و Corresponding source route باید توسط Review تخصصی بررسی شود. این مقاله حکم دربارهٔ Service خاص نمی‌دهد.

Container و CI artifact می‌توانند Delivery باشند

اگر Image، Cache، Test appliance، Debug bundle یا Runner package به مشتری/پیمانکار داده می‌شود، Tool و Transitive components ممکن است همراه آن منتقل شوند. Registry خصوصی همیشه Internal-use proof نیست. Manifest گیرنده/Artifact/Digest/Channel را ثبت کنید.

Execute، Link، Plugin و IPC را مدل کنید

Interaction	Evidence فنی	پرسش Review
Separate execution	Process/CLI/input-output	Output covered material دارد؟
Static/Dynamic link	Build graph/Binary symbols	Work boundary/obligation چیست؟
Plugin	API/ABI/data structures/lifecycle	Combined work یا separate؟
IPC/Network API	Protocol/schema/deployment	Separation و service trigger؟
Embed/Snippet	Files/lines/provenance	License/notice/source scope؟
Code generation	Template/runtime/output diff	Output covered content دارد؟

نام تکنیک Verdict نیست. Plugin با API ساده یا دسترسی عمیق داخلی، Wrapper، Shared memory یا Generated runtime می‌تواند تحلیل متفاوتی بخواهد. نمودار معماری و Build artifact را به Reviewer بدهید، نه فقط نام Package.

Output ابزار را فرضاً متعلق به خود ندانید

Test report، Screenshot، Recording، Generated test code، Template، Fixture، Runtime helper و Embedded asset را Inventory کنید. Output معمولاً صرف اجرای Program نیست، اما ممکن است covered code/template/asset یا دادهٔ شخصی/محرمانه را حمل کند. `outputContainsCode` و Redistributable status نیاز Evidence دارند.

Modification و Fork

Patch، configuration، build flag، vendoring، backport، generated file و fork را جدا ثبت کنید. Modification marking، Source provision و notice scope به License/Delivery وابسته است. Patch داخلی ممکن است بعداً در Image مشتری وارد شود؛ Change log و Affected-use search لازم است.

Obligation Matrix را از Label نسازید

Artifact/Digest | License expression | Interaction | Modification
Recipient/Delivery | Copyright/License/Attribution/NOTICE
Source/Offer/Relinking/Installation information | State changes
Patent/Trademark | Output/generated content | Due evidence
Owner | Reviewer | Condition | Status | Expiry
Unknown/Legal question | Not claimed

Matrix باید Requirement text/ref، Trigger assumption، Action، Owner، Evidence و Status داشته باشد. Whitelist/Blacklist ساده برای Intake مفید است اما Use-specific determination نیست. یک License در سناریوی جدا ممکن است Conditionهای دیگری داشته باشد.

Notice Bundle قابل‌بازتولید

Copyright notice، License texts، Attribution، NOTICE propagation، Modification markers و Third-party notices را از resolved Release graph بسازید. Bundle باید با Digest Release و Manifest گیرنده وصل باشد. فایل قدیمی Notices از Branch دیگر Evidence نیست.

Source Bundle و Written Offer

اگر Review الزام Source/Corresponding source/Offer را نتیجه داد، Scope، Build scripts، Installation information، delivery method، retention و Recipient instructions را Pin کنید. یک URL موقت یا Source نسخهٔ دیگر کافی نیست. این الزام را مقاله استنتاج نمی‌کند؛ Matrix تأییدشده آن را حمل می‌کند.

Patent با Copyright یکی نیست

Patent grant، Scope، termination، litigation clause و Risk مستقل‌اند. وجود Patent language در License، Freedom-to-operate یا نبود Patent شخص ثالث را تضمین نمی‌کند. Patent clearance کار Reviewer صلاحیت‌دار است؛ SCA یا SBOM نمی‌تواند آن را سبز کند.

Trademark و Logo مجوز جدا می‌خواهند

Open Source license معمولاً نام/Logo/Endorsement را خودکار مجاز نمی‌کند. نام Product در Documentation سازگاری، استفاده در Marketing، تغییر Logo یا ادعای «Certified/Official» یکسان نیست. Trademark policy و Permission را جدا ثبت کنید.

Contribution ownership را حدس نزنید

Employee/Contractor authority، Employer policy، Project contribution guide، DCO/CLA، Copyright assignment، Patent contribution، Sign-off identity، Secret scan و Third-party code را بررسی کنید. CLA همیشه Copyright را منتقل نمی‌کند؛ DCO هم CLA نیست. متن دقیق و سیاست کارفرما/پروژه تعیین‌کننده است.

Pull Request خودکار مجوز مشارکت نیست

قبل از ارسال Patch، مشخص شود نویسنده حق مشارکت دارد، Secret/Customer code/AI output نامشخص وارد نشده، Sign-off درست است و پروژه چه Termsی دارد. Maintainer merge، به‌تنهایی مالکیت یا Patent clearance شما را اثبات نمی‌کند.

کد تولیدشده با AI هم Provenance می‌خواهد

اگر Assistant کد/Template/License suggestion می‌دهد، Tool/model/version، Prompt inputs، Source policy، Review و Similarity/Provenance limits را ثبت کنید. AI نباید License را از روی Style حدس بزند یا Legal conclusion بدهد. Unknown code وارد Contribution/Release نمی‌شود.

SCA Finding حکم حقوقی نیست

Scanner name/version، License database version، Scope، Lockfile/resolved graph، Vendored/Binary scan، Unknown handling، False-positive review و False-negative probe را ثبت کنید. SCA می‌تواند Evidence جمع کند؛ Interaction، Work boundary، Choice یا Obligation نهایی نیاز بررسی دارد.

SBOM مجوز استفاده نیست

SBOM Inventory را منتقل می‌کند؛ کامل‌بودن، License compliance، Security یا Provenance را خودکار ثابت نمی‌کند. Component→Artifact→Digest→License evidence→Interaction→Delivery→Obligation→Decision زنجیرهٔ کامل‌تر است. `NOASSERTION` باید قابل Route باشد.

License و Security را مخلوط نکنید

License approval، Vulnerability exposure، Provenance/Signature، Malware، Secret، Maintenance و Support تصمیم‌های جدا هستند. Artifact می‌تواند License-cleared ولی آسیب‌پذیر، یا امن از نظر Scan ولی License-unknown باشد. Release هر Gate لازم را جدا می‌خواهد.

Roles و حق تصمیم

Requester، Artifact owner، OSS program owner، Engineering/Security/Procurement reviewer، Legal expert، Release owner و Approver را جدا کنید. QA می‌تواند Artifact/Interaction/Delivery evidence و Verification pack بسازد؛ نباید تفسیر حقوقی یا Patent clearance را به نام خود صادر کند.

Decision Record محدود

Decision: HOLD | REJECT | CONDITIONALLY_APPROVE | APPROVE_SCOPED_USE
Scope: Artifact digest + interaction + recipients + delivery + jurisdictions
Conditions: obligation pack + verification + due owner
Prohibited uses: explicit
Exception/Dissent: retained
Authority/Reviewers/DecisionAt/Expiry: pinned
NotProof: legal advice | universal license interpretation | future versions

Exception و Risk acceptance

Deadline یا «همه استفاده می‌کنند» Obligation را حذف نمی‌کند. Exception باید Finding، Scope، Alternative، Consequence، Authority، Condition، Expiry و Remediation داشته باشد؛ برخی حقوق/تعهدها قابل Risk-accept کردن سازمانی نیستند و Legal route تعیین می‌کند. Suppression Scanner با Permission فرق دارد.

Release verification روی Artifact واقعی

Digest، resolved graph، Interaction، Delivery manifest، Notice/Source/Offer bundle و Recipient route را بعد از Build بررسی کنید. Approval روی Design یا Source branch به Binary نهایی منتقل خودکار نمی‌شود. Gate باید Unknown/Changed artifact را Hold کند.

Upgrade و License change

Version/Commit/Digest، License expression/text، Dependency graph، Exception، Maintainer/Supplier، Interaction یا Delivery change Re-review را Trigger می‌کند. Auto-update بدون Policy می‌تواند Approved artifact را با Artifact دیگری جایگزین کند. Diff و affected releases ثبت شود.

ملاحظات ایران را جدا Route کنید

Access path، sanctions/export-control applicability، Vendor terms، Payment، Mirror، Offline update و Support constraint می‌تواند جدا از OSS License مطرح باشد. این مقاله دربارهٔ مجازبودن کشور/معامله حکم نمی‌دهد. از Reviewer صلاحیت‌دار استفاده و Mirror/Digest/Provenance را Pin کنید؛ «Open Source است پس هیچ محدودیت دیگری ندارد» ادعای نادرست است.

Remediation وقتی Finding دیر کشف شد

FindingID، Affected artifacts/releases/recipients، Stop-use/Quarantine، Notice repair، Source/Offer repair، Recipient notice، Rebuild/Redistribute، Legal route و Closure evidence را ثبت کنید. حذف Package از Branch فعلی، Releaseهای قبلی یا Recipient obligation را خودکار اصلاح نمی‌کند.

قالب کامل OSS Test Tool Use Record

Identity: record/version/status/owner/supersedes/asOf/review/expiry
Request: purpose/use/product/project/business/recipients/release/service/jurisdictions
Artifact: supplier/repo/version/commit/tag/purl/digests/source/build provenance
Inventory: direct/transitive/bundled/plugins/container/generated/assets/docs/fonts/data/models
License: declared/concluded expression/SPDX/texts/headers/metadata/notices/exceptions/custom/unknown
Expression: AND/OR/WITH/only-later/LicenseRef/choice/authority/compatibility
Interaction: execute/link/plugin/IPC/API/embed/snippet/modify/fork/generate/output code
Delivery: internal/affiliate/contractor/customer/device/container/CI/source/binary/SaaS/public/store
Boundaries: work/combined/aggregate/derivative/recipient/source/corresponding/network/output
Obligations: copyright/license/attribution/NOTICE/changes/source/offer/relink/install/same-license
Patent/trademark: grant/termination/risk/name/logo/endorsement
Contribution: authority/policy/guide/DCO/CLA/assignment/patent/signoff/secrets/third party
Output: generated/template/runtime/report/media/fixture/redistribution
Artifacts: matrix/notice/source/offer/instructions/review/release/distribution manifest
Automation: scanner/version/database/scope/graph/vendor/binary/unknown/FP/FN
Security: vulnerability/provenance/signature/malware/secret/maintenance/support separately
Roles/Decision: reviewers/legal/release/approver/conditions/prohibited/exception/dissent/expiry
Lifecycle/Repair/Region: triggers/revoke/archive/affected/repair/access/export/mirror/offline
Limits: no legal/compliance/ownership/patent/trademark/security/all-source/person proof

آزمایشگاه آفلاین Checkout ایرانی

Lab کاملاً ساختگی و قطع از شبکه است: یک Fake test runner، Fake reporter و Fake plugin روی Checkout جعلی با Order/PaymentAttempt/PSP Stub/Callback/Ledger/Reconciliation/notification؛ timeout/retry/duplicate/late/reordered events. Tenant/Order/Attempt/Event/Run/Build/Artifact/Record/Decision شناسه‌های ساختگی‌اند. هیچ Package/License conclusion/شرکت/فرد واقعی مدل نشده است.

پول canonical فقط IRR خیالی و «تومان» Presentation برچسب‌خورده است؛ ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ/RTL-LTR/Bidi، UTC و `Asia/Tehran`/جلالی نمایشی آزمون می‌شوند. هیچ شبکه/Production/Repository/Vendor/شخص/کاربر/سفارش/پرداخت/PSP/بانک/پول/PII/نام/ایمیل/IP/Credential/Token/کد اختصاصی واقعی یا توصیهٔ حقوقی/Patent/Trademark/تحریم/Export وجود ندارد.

Checker سطحی چگونه فریب می‌خورد؟

Fixture فقط OSI-approved، Permissive label، SCA passed، SBOM present و NOTICE present دارد. Checker نام‌محور بدون Artifact/Interaction/Delivery می‌گوید:

fixture: SYN-OSS-TEST-TOOL-USE-01
superficial: OSS_USE_LEGALLY_SAFE

ممیزی ساختاری چه یافت؟

Validator بدون وابستگی خارجی، ۲۲۴ کنترل یکتای Identity، Request، Artifact، Inventory، License evidence/expression، Interaction، Delivery، Boundaries، Obligations، Patent/Trademark، Contribution، Output، Compliance artifacts، Automation، Security separation، Roles/Decision، Lifecycle/Remediation، Region و Limits را بررسی کرد. همه در Fixture سطحی غایب بودند:

uniqueStructuralControls: 224
audit: HOLD-224
independentNoLegalOpinionRule: PASS

قاعدهٔ ۲۲۵ام مستقل بود: `legalOpinionClaimed=false` و Pass شد. پس ۲۲۴ Finding واقعی‌اند؛ Duplicate برای بزرگ‌کردن عدد وجود ندارد.

نسخهٔ اصلاح‌شده چه می‌گوید؟

با Pin کردن همهٔ قراردادهای کاملاً ساختگی، خروجی صفر شد:

corrected: READY_FOR_OSS_TEST_TOOL_USE_REVIEW-0
notProof: legal advice | license interpretation | compliance | ownership |
          patent clearance | trademark permission | security | distribution authorization

این فقط آمادگی ساختاری برای Review است؛ Legal advice، License interpretation، Compliance، Ownership، Patent clearance، Trademark permission، Security assurance یا اجازهٔ توزیع را ثابت نمی‌کند.

ضدالگوهای مجوز ابزار تست متن‌باز

• Open Source مساوی بدون مالک/Copyright.
• رایگان از نظر قیمت مساوی بدون تعهد.
• Commercial مساوی Proprietary.
• Source available مساوی OSI-approved.
• Homepage license برای هر Artifact.
• نام Package بدون Version/Digest.
• Source license برای Binary نامعلوم.
• فقط Direct dependency.
• نادیده‌گرفتن Plugin/Driver/Asset/Font/Model.
• Declared license مساوی Concluded.
• حذف `AND/OR/WITH/-only/-or-later`.
• Permissive مساوی بدون Notice/Patent/Trademark.
• Apache-۲.۰ مساوی Patent clearance.
• Copyleft به‌عنوان «ویروسی».
• GPL مساوی انتشار کل سورس شرکت در هر استفاده.
• اجرای Runner مساوی Linking.
• Internal registry مساوی عدم Delivery.
• Container/CI artifact خارج Distribution inventory.
• SaaS مساوی نبود هیچ Trigger.
• Plugin name به‌عنوان Work-boundary verdict.
• Output همیشه بدون covered content.
• Config/Patch/Fork ثبت‌نشده.
• Whitelist به‌عنوان Use approval.
• Notice bundle از Branch دیگر.
• Source URL موقت/نسخهٔ دیگر.
• Logo/name به‌عنوان حق خودکار.
• CLA مساوی Copyright assignment.
• PR merge مساوی Ownership clearance.
• AI code بدون Provenance.
• SCA Passed به‌عنوان Legal verdict.
• SBOM به‌عنوان Compliance proof.
• License approval به‌عنوان Security proof.
• Deadline به‌عنوان Exception.
• Approval v1 برای Upgrade v2.
• Open Source مساوی نبود تحریم/Export/Terms.
• حذف Package فعلی به‌عنوان Repair همهٔ Releaseها.
• امتیازدهی فرد با Findingهای License.

چک‌لیست Use Record Owner

• Record/Version/Status/Owner/Expiry روشن است.
• Purpose/Product/Recipient/Delivery/Jurisdiction محدود است.
• Artifact/Repository/Version/Commit/PURL/Digest Pin است.
• Source/Binary/Container به Build provenance وصل است.
• Direct/Transitive/Plugin/Asset/Generated inventory کامل است.
• Declared و Concluded expression جداست.
• License texts/headers/metadata/NOTICE/unknown حفظ شده است.
• `AND/OR/WITH/only/later/LicenseRef` دقیق است.
• Choice و Compatibility Review Authority دارد.
• Execute/Link/Plugin/IPC/Embed/Modify/Generate مدل شده است.
• Internal/Contractor/Customer/Container/SaaS/Public delivery روشن است.
• Work/Source/Output boundary به Legal question وصل است.
• Copyright/License/Attribution/NOTICE obligation ثبت است.
• Source/Offer/Relink/Install/Same-license بررسی شده است.
• Patent و Trademark جدا Review شده‌اند.
• Contribution authority/DCO/CLA/Assignment/Secrets روشن است.
• Generated code/report/media/fixture inventory شده است.
• Obligation/Notice/Source/Offer/Instruction packs Digest دارند.
• Scanner/version/database/scope/FP/FN ثبت است.
• License/Security/Provenance/Support decisions جداست.
• Engineering/Security/Procurement/Legal/Release roles جداست.
• Decision/Conditions/Prohibited/Exception/Dissent/Expiry روشن است.
• Release artifact واقعی Verification شده است.
• Upgrade/License/Interaction/Delivery change Re-review دارد.
• Affected Release/Recipient Remediation آماده است.
• Region/access/export/mirror به Reviewer صلاحیت‌دار Route شده است.
• NotProof و no-person-scoring صریح است.

Pilot سی‌روزه OSS Use Record

1. روز ۱–۷: یک Runner کم‌خطر، Artifact/Digest/graph و Delivery واقعی را Inventory کنید؛ هیچ License finding را خودسرانه تفسیر نکنید.
2. روز ۸–۱۵: Expression، Interaction، Obligation Matrix و Review route را روی Fixture ساختگی طراحی کنید.
3. روز ۱۶–۲۳: Notice/Source/Manifest generation را در Release آزمایشی آفلاین اجرا و Unknown/Failure را Hold کنید.
4. روز ۲۴–۳۰: Upgrade/Delivery-change و late-finding tabletop را تمرین؛ Completeness/latency/repair را مرور و `KEEP / ADAPT / STOP` ثبت کنید.

Metricهای سالم: درصد Artifact با Digest/Concluded expression، Unknown aging، Releaseهای دارای Notice/Source verification، Re-review overdue و Remediation latency. تعداد «مجوزهای سبز»، Finding هر فرد یا تعداد Package به‌تنهایی سلامت Program را ثابت نمی‌کند.

جمع‌بندی اجرایی

برای ابزار تست متن‌باز از Label به Record بروید: Artifact/Digest و Graph واقعی، License text/expression دقیق، Interaction/Modification/Output، Recipient/Delivery، Obligation/Notice/Source pack، Patent/Trademark/Contribution، Automation limits، نقش Legal و Release verification. OSS می‌تواند انتخاب عالی باشد؛ اما «رایگان، Permissive یا SCA سبز» مجوز استفادهٔ موردی نیست.

پرسش‌های متداول مجوز ابزار تست متن‌باز

آیا ابزار تست متن‌باز برای استفادهٔ تجاری رایگان است؟

Open Source می‌تواند برای Purpose تجاری استفاده شود، اما قیمت صفر، هزینهٔ عملیات/Support یا تعهد License را حذف نمی‌کند. Artifact، Interaction، Modification و Delivery را با متن مجوز و Review سازمان بسنجید؛ Commercial با Proprietary یکسان نیست.

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

پاسخ خودکار خیر/بله ندارد. اجرای جدا، Linking، Plugin، Modification، Output containing code و Convey/Distribution سناریوهای متفاوت‌اند. Artifact و معماری/تحویل دقیق را به Legal expert بدهید؛ از اصطلاح «ویروسی» و حکم کلی دوری کنید.

تفاوت MIT و Apache-۲.۰ برای تیم QA چیست؟

هر دو مجوزهای OSI-approved رایج با حقوق گسترده‌اند، اما متن/شرط‌ها یکسان نیست: Apache-۲.۰ ساختار صریح‌تری برای NOTICE، تغییرات، Patent و Trademark دارد؛ MIT شرط درج Notice و Disclaimer خود را دارد. Bundle واقعی و Third-party files بررسی شوند.

آیا SCA و SBOM رعایت License را تضمین می‌کنند؟

خیر. آن‌ها Inventory/Signal و License metadata می‌دهند؛ ممکن است Transitive/Vendored/Binary/Runtime download یا Custom terms را ناقص ببینند و Interaction/Delivery را تفسیر نمی‌کنند. Human/Legal review و Release verification لازم است.

اگر باگ ابزار متن‌باز را اصلاح و PR کنیم، مالک Patch کیست؟

پاسخ به قانون/قرارداد کار، متن License، Project guide و DCO/CLA/assignment بستگی دارد. CLA همیشه انتقال Copyright نیست. پیش از PR، Authority نویسنده، Third-party/AI provenance، Patent/Secret و Sign-off را با Reviewer صلاحیت‌دار بررسی کنید.