Lập danh mục thành phần và bằng chứng giấy phép; phân biệt SBOM, SCA với kết luận tuân thủ, hiểu vai trò OSPO và xử lý hồ sơ bàn giao DEMO còn thiếu.
Một nhóm chuẩn bị bàn giao ứng dụng cho khách hàng. Thư mục dự án có source, tệp khóa dependency, ảnh minh họa và một binary do nhà cung cấp gửi. Người phụ trách nói rằng đã quét thư viện, nên có thể phát hành. Tuy nhiên, kết quả quét chưa cho biết binary chứa gì, ảnh có quyền sử dụng nào và bản source nào tương ứng với gói bàn giao.
Bài 054.3, Tuân thủ và giảm thiểu rủi ro, tham chiếu Open Source Essentials 050-100 trang in 178–196, biên soạn độc lập và đối chiếu ngày 23/10/2026. Bạn cần hiểu giấy phép phần mềm, nội dung mở và các mô hình kinh doanh ở những bài trước. Môi trường thực hành là hồ sơ phát hành giả định, không cần tải hoặc phân phối sản phẩm thật.
Kết quả học tập là lập được danh mục thành phần có bằng chứng, phân biệt SBOM với kết luận tuân thủ, và giao câu hỏi cho đúng người xử lý. Đây là kiến thức nhập môn để làm việc cùng kỹ thuật, bảo mật và pháp chế; bài không đưa ra phán quyết pháp lý cho một sản phẩm cụ thể.
Không chỉ hỏi “dự án dùng license gì”. Hãy xác định sản phẩm, phiên bản, artifact và hành vi dự kiến: chạy nội bộ, cung cấp dịch vụ, chuyển binary, đưa vào thiết bị hay phát hành source. Những hành vi này có thể dẫn đến các điều kiện khác nhau, tùy văn bản và phiên bản giấy phép.
Không dùng khẩu quyết “nội bộ thì không có nghĩa vụ nào” hoặc “qua mạng thì không có điều kiện nào”. Phải đọc trường hợp cụ thể, kể cả bản sửa, quyền người dùng và điều khoản liên quan. Với copyleft, nguồn tương ứng cần khớp phần mềm được cung cấp; không suy ra mọi tình huống đều đòi công bố toàn bộ sản phẩm cho toàn Internet.
Danh mục nên tách mã tự viết, thư viện trực tiếp, dependency gián tiếp, binary, ảnh, font và dữ liệu. Một file LICENSE ở gốc chưa bao trùm các tài sản được lấy từ nguồn khác. Khi chưa biết nguồn hoặc quyền, ghi trạng thái chưa xác minh và giữ bước bàn giao liên quan ở trạng thái chờ.
Mỗi mục nên có tên, phiên bản hoặc revision, nguồn nhận, định danh artifact, license được khai báo, văn bản đi kèm và ghi chú thay đổi. Tách điều tác giả khai báo khỏi kết luận của người đánh giá. Nếu package metadata và tệp LICENSE khác nhau, đừng tự chọn thông tin thuận tiện hơn; lưu mâu thuẫn để xử lý.
Nghĩa vụ thông báo, ghi công, cung cấp source, ghi thay đổi hoặc điều kiện bằng sáng chế cần được xác định từ giấy phép tương ứng. Không phải mọi giấy phép đều yêu cầu tên tác giả trong mọi quảng cáo. Cũng không thể kết luận rằng dùng thư viện luôn nằm ngoài copyleft, hoặc cứ tách tiến trình là chắc chắn không có vấn đề.
Thông báo bản quyền và license cần được giữ ở vị trí theo yêu cầu áp dụng. Khi có NOTICE hoặc nội dung bổ sung, kiểm tra điều kiện của chính gói đó. Việc sao chép một mẫu attribution từ sản phẩm khác có thể bỏ sót tên, phiên bản hoặc phạm vi của thành phần thực tế.
SBOM, Software Bill of Materials, là hồ sơ có cấu trúc về thành phần phần mềm. Nó giúp trả lời sản phẩm chứa gì và quan hệ giữa các phần ra sao. Mức đầy đủ phụ thuộc phạm vi thu thập, công cụ và đầu vào. Không khẳng định mọi dự án nguồn mở đều đã có SBOM hoặc một lần xuất từ repository đã bao gồm toàn bộ binary bàn giao.
SPDX công bố các phiên bản đặc tả; nhánh ổn định được liên kết tới SPDX 3.0.1. SPDX có thể biểu diễn quan hệ giữa các phần tử, không nên giản lược thành một cây dependency duy nhất. Khi trao đổi hồ sơ, cần ghi phiên bản schema mà công cụ hai phía hỗ trợ.
Trang đặc tả CycloneDX ghi phiên bản hiện hành 1.7, phát hành 21/10/2025, và mô tả thành phần, dịch vụ, quan hệ cùng nhiều loại thông tin chuỗi cung ứng. Không xếp hai chuẩn bằng nhận định đơn giản rằng chuẩn nào luôn lớn hơn hoặc chỉ dành cho một ngành.
Có tên và phiên bản trong SBOM chưa chứng minh package đúng là phần đã chạy. Cần nối hồ sơ với artifact, thời điểm và quá trình tạo. Bài nhập môn chưa yêu cầu triển khai ký xác thực hoặc hệ thống provenance; trước hết hãy giữ được liên kết rõ giữa bản bàn giao và tài liệu của nó.
SCA, Software Composition Analysis, hỗ trợ nhận diện thành phần, giấy phép và thông tin lỗ hổng tùy công cụ. Một kết quả cần được xem cùng cơ sở dữ liệu, thời điểm quét và những phần bị bỏ qua. Không tìm thấy cảnh báo có thể do không nhận diện được thành phần, chứ chưa đủ chứng minh an toàn.
Thông tin license có thể thiếu hoặc mơ hồ. Thông tin lỗ hổng cũng cần xác nhận phiên bản, cách sử dụng và khả năng bị ảnh hưởng. Đội kỹ thuật kiểm tra hiện trạng; bảo mật đánh giá mức rủi ro; người phụ trách pháp lý xử lý câu hỏi quyền và nghĩa vụ. Một nhãn xanh trên dashboard không thay các công việc đó.
Khi thay dependency, cần xem lại cả artifact và hồ sơ. Giữ SBOM cũ rồi thay binary mới làm đứt liên kết bằng chứng. Nếu dùng mã do AI hỗ trợ tạo, người chịu trách nhiệm vẫn cần review nguồn, quyền sử dụng, dependency và hành vi của mã; đầu ra công cụ không tự cấp bảo đảm về nguồn gốc.
TODO Group mô tả OSPO như đầu mối cho hoạt động nguồn mở của tổ chức, có thể gồm chính sách, đào tạo, tuân thủ và cộng đồng. Một nhóm nhỏ có thể phân công chức năng này cho người phù hợp hoặc phối hợp bên ngoài; không nhất thiết lập một phòng ban lớn ngay từ đầu.
Một quy trình hữu ích chỉ rõ nơi lưu hồ sơ, người duyệt ngoại lệ, người trả lời câu hỏi license và người kiểm tra artifact trước bàn giao. Chính sách cần có đường xử lý khi công cụ không nhận diện được một gói, thay vì buộc nhân viên điền một license bất kỳ để vượt kiểm tra.
OpenChain phân biệt chương trình tuân thủ với bảo đảm tuyệt đối. Việc đáp ứng chuẩn quy trình không loại bỏ mọi khả năng sai sót trong từng sản phẩm. Mục tiêu thực tế là có khả năng nhận diện, giải quyết và lưu bằng chứng một cách lặp lại được.
Bản quyền, bằng sáng chế và nhãn hiệu không phải cùng một quyền. Có quyền sửa code chưa đủ kết luận có quyền dùng logo để quảng bá sản phẩm mới. Điều khoản bằng sáng chế cũng phải đọc đúng phạm vi cấp quyền, đối tượng và điều kiện; không diễn giải thành miễn mọi tranh chấp sáng chế.
Bảo hành, trách nhiệm sản phẩm và quy định xuất khẩu phụ thuộc hợp đồng, hoạt động và pháp luật áp dụng. Một dòng miễn trừ trong license không đủ để đội Help Desk quyết định mọi trách nhiệm của doanh nghiệp. Khi phát hành qua biên giới hoặc tích hợp chức năng mật mã, cần chuyển câu hỏi cho người có chuyên môn cùng thông tin sản phẩm cụ thể.
Rủi ro tài chính còn gồm chi phí sửa lỗi, thay thành phần, duy trì fork và chậm bàn giao. Khi mua lại hoặc kết hợp sản phẩm, hồ sơ từ hai nhóm có thể không cùng phạm vi. Không có cơ sở để khẳng định nguồn mở chỉ bền vững khi bán phần cứng, hoặc mọi trường hợp phát hiện copyleft đều dẫn tới cùng một cách khắc phục.
Ghi ba thành phần giả định: A là mã của nhóm có revision DEMO-7; B là thư viện bên ngoài với bản license đi kèm; C là binary nhận được nhưng chưa rõ source và license. Đây là dữ liệu bài tập, không đại diện cho package thật hoặc một SBOM hợp chuẩn SPDX/CycloneDX.
Với mỗi mục, thêm cột nguồn bằng chứng, artifact liên quan và người phụ trách. Bản ghi C phải thể hiện thông tin chưa biết. Đừng sao chép license của A vào C chỉ vì chúng được đặt trong cùng thư mục.
Giả định nhóm muốn chuyển một gói cài đặt cho khách hàng. Đặt câu hỏi: B có những thông báo nào phải đi cùng gói; C được quyền phân phối không; source cần thiết đã khớp artifact chưa? Chưa có văn bản của B thì bài tập không thể trả lời nghĩa vụ cụ thể cho nó.
Kết quả mong đợi là một danh sách việc cần xác minh. C chưa có quyền phân phối được chứng minh nên chưa thể đánh dấu sẵn sàng bàn giao. A có revision nhưng vẫn cần đối chiếu phần thật sự được đóng gói và thông báo phù hợp.
Đổi revision A thành DEMO-8 nhưng giữ hồ sơ cũ. Tìm điểm không khớp và ghi yêu cầu tạo lại hoặc cập nhật danh mục cho bản mới. Không được sửa ngày trên hồ sơ cũ rồi tuyên bố đã quét lại.
Bước này luyện tính nhất quán giữa tài liệu và sản phẩm. Nó chưa chạy một SCA scanner, chưa phát hiện lỗ hổng thật và chưa xác thực nguồn gốc bằng chữ ký. Khi dùng công cụ thật ở công việc, lưu tên, phiên bản, phạm vi và kết quả thay cho những tuyên bố chung.
Giao kỹ thuật xác định nội dung C và artifact A; người phụ trách license kiểm tra quyền và nghĩa vụ; người đóng gói đối chiếu tài liệu đi kèm. Một đầu việc chỉ hoàn tất khi có bằng chứng được lưu và người được phân công xác nhận theo quy trình của tổ chức.
Nếu thông tin vẫn thiếu, ghi lý do giữ bàn giao và phương án tiếp theo, chẳng hạn hỏi nhà cung cấp hoặc đánh giá thành phần thay thế. Bài tập kết thúc với hồ sơ có trạng thái rõ ràng, chưa tạo quyết định phát hành thật.
SBOM có phải giấy chứng nhận không vi phạm không? Không. Nó cung cấp thông tin cần được đối chiếu với phạm vi và quyền thực tế. Có cần giữ cùng một hồ sơ khi artifact đổi không? Cần cập nhật và giữ lịch sử để biết hồ sơ nào mô tả bản nào.
Nếu license chưa rõ, câu trả lời đúng là ghi nhận khoảng trống và chuyển xử lý, không đoán theo tên dự án. Nếu scanner không cảnh báo, hãy kiểm tra phạm vi trước khi suy luận. Một hồ sơ có mục chưa biết nhưng có người xử lý hữu ích hơn danh sách đầy đủ trên giấy với các giá trị không có bằng chứng.
Khung mục tiêu: LPI Open Source Essentials 054.3. SPDX, CycloneDX, TODO Group và OpenChain được dẫn trực tiếp ở phần tương ứng. Kiểm tra lại schema, khả năng công cụ và điều kiện áp dụng trước mỗi đợt phát hành.
Chọn chat, email, issue, ticket và tài liệu theo mục tiêu; hiểu federation, wiki, CMS, DMS, rồi lập báo cáo, ghi chú quyết định và dàn ý tài liệu DEMO.
Phân biệt Git với nền tảng hosting, working tree, index, commit, branch và tag; thực hành nhánh, fast-forward, tag và revert trong repository riêng.
Phân biệt IDE, build, linter, debugger, các loại test và môi trường CI/CD; chạy lab Node để thấy cú pháp hợp lệ vẫn có thể sai hành vi rồi khôi phục.
Nhận diện maintainer, contributor, quản trị và tài trợ; đọc DCO, CLA, quy tắc ứng xử, rồi soạn phản hồi đóng góp tài liệu qua tình huống DEMO riêng.