Đọc điều kiện MIT, BSD-2/3-Clause và Apache 2.0; phân biệt MIT với X11, kiểm tra LICENSE, NOTICE, tệp sửa và hồ sơ dependency trong gói bàn giao DEMO.
Một công cụ nội bộ dùng ba thư viện nguồn mở rồi được đóng gói gửi khách hàng. Người đóng gói giữ mã chạy nhưng xóa thư mục giấy phép để “gọn hơn”. Các thành phần đều mang nhãn permissive, nhưng điều đó không làm các điều kiện về thông báo biến mất.
Bài 052.3, Giấy phép phần mềm linh hoạt, tham chiếu Open Source Essentials 050-100 trang in 88–104, viết độc lập và đối chiếu ngày 23/10/2026. Bạn cần phân biệt source/binary, giấy phép và phân phối. Sau bài, bạn nên nhận biết các điều kiện chính của MIT, BSD và Apache 2.0, kiểm tra nội dung gói và ghi câu hỏi tương thích đúng phạm vi. Bài học cung cấp kiến thức nhập môn; quyết định pháp lý cho sản phẩm cụ thể cần xem đầy đủ điều khoản và hoàn cảnh sử dụng.
Giấy phép permissive thường cho phép dùng, sửa và phân phối, gồm cả việc đưa thành phần vào sản phẩm có mã riêng không công khai, theo các điều kiện của văn bản. Khác biệt quan trọng với copyleft là không áp dụng cơ chế tương hỗ có cùng phạm vi. Điều đó không biến tác phẩm thành public domain và không xóa thông báo của tác giả gốc.
Không nên diễn giải “chỉ cần ghi công” như một công thức cho mọi license. Có văn bản quy định giữ điều kiện và disclaimer trong bản source, có văn bản nói tới tài liệu đi kèm binary; Apache 2.0 còn có các nội dung khác. Đọc giấy phép của đúng thành phần rồi chuyển thành công việc có thể kiểm tra trong gói cuối.
Đừng suy ra permissive luôn tốt hơn cho mọi dự án. Nhóm tác giả có thể muốn quyền tự do tiếp tục được bảo toàn theo copyleft, hoặc muốn thuận tiện tích hợp theo permissive. Khi tiếp nhận phần mềm, Help Desk không cần lựa chọn triết lý thay tác giả; cần nhận diện điều kiện hiện có và chuyển yêu cầu tới người phụ trách phát hành.
MIT trên OSI cấp quyền rộng như dùng, sao chép, sửa, phân phối và bán bản sao, kèm điều kiện giữ thông báo bản quyền cùng thông báo cấp quyền trong các bản sao hoặc phần đáng kể của phần mềm. Văn bản cũng có điều khoản không bảo đảm. Đừng thay nội dung này bằng một dòng cảm ơn tự viết rồi mặc định tương đương.
Có thể giữ văn bản cùng thông báo thực tế trong phần giấy phép bên thứ ba của gói, theo cách phù hợp với thành phần và quy trình phân phối. Cần kiểm tra file đó thật sự có mặt trong artifact đã xuất, không chỉ trong repository. Nếu pipeline loại bỏ thư mục tài liệu, cấu hình build đúng ở source vẫn chưa đảm bảo đầu ra đủ thông tin.
Giáo trình dùng tên MIT/X11 khá rộng, nhưng SPDX có định danh X11 riêng, với điều khoản bổ sung về dùng tên trong quảng bá. Khi lập inventory, ghi văn bản thực tế và mã định danh phù hợp; đừng tự chuẩn hóa mọi thứ có chữ MIT hoặc X11 thành cùng một chuỗi rồi bỏ phần khác biệt.
BSD-2-Clause phân biệt tái phân phối source với binary. Source cần giữ thông báo bản quyền, các điều kiện và disclaimer; binary cần tái hiện các nội dung đó trong tài liệu hoặc vật liệu đi kèm. Đây là lý do bộ cài chỉ có executable vẫn cần xét phần tài liệu được cung cấp cho người nhận.
BSD-3-Clause bổ sung điều kiện không dùng tên người giữ bản quyền hoặc người đóng góp để chứng thực, quảng bá sản phẩm phái sinh nếu chưa có cho phép cụ thể trước bằng văn bản. Ghi nhận nguồn và tuyên bố được tác giả bảo chứng là hai hành vi khác nhau.
Giả sử màn hình About ghi tên thư viện cùng license, còn trang bán hàng viết “được tác giả thư viện chứng nhận”. Câu thứ hai cần được xem riêng; việc gói đã kèm license chưa tự cấp quyền quảng bá kiểu đó. Ngược lại, bỏ tên tác giả khỏi thông báo để tránh điều khoản cũng không phải cách giải quyết phù hợp.
Apache License 2.0, mục 4, quy định cấp bản sao license, đánh dấu tệp đã sửa, giữ các notice liên quan trong source và xử lý attribution của NOTICE khi bản gốc có NOTICE. Văn bản có cấp quyền bằng sáng chế theo phạm vi đóng góp và điều khoản chấm dứt liên quan kiện bằng sáng chế; không phải bảo đảm miễn mọi khiếu nại.
Không đọc thành yêu cầu công bố tất cả phần chưa sửa dưới dạng source. Apache 2.0 cho phép phân phối Source hoặc Object theo điều kiện của nó. NOTICE cũng không phải nơi để âm thầm thêm hạn chế làm đổi giấy phép. Khi đóng gói, hãy xác định notice nào liên quan đến phần được nhận và cách cung cấp phù hợp.
FAQ của Apache giải thích gói dự án có thể chứa tác phẩm bên thứ ba với văn bản bổ sung trong LICENSE hoặc NOTICE. Vì vậy, thấy license chính Apache-2.0 chưa đủ để gán nó cho mọi dependency. Đọc cả tài sản đi kèm, nhất là khi bạn chỉ lấy một phần của bản phân phối hoặc đưa thêm phần mới.
Cũng theo FAQ, sửa phần mềm không đồng nghĩa bắt buộc gửi thay đổi về ASF. Nghĩa vụ phân phối và lựa chọn đóng góp upstream là hai câu hỏi khác nhau. Tên dự án và nhãn hiệu cần được xử lý theo phạm vi quyền liên quan; không dùng việc có source làm bằng chứng được mượn thương hiệu để quảng bá.
Apache giải thích quan hệ với GPL: mã Apache 2.0 có thể được đưa vào tác phẩm GPLv3 theo điều kiện phù hợp, còn GPLv2 không có cùng quan hệ tương thích. Không suy ngược rằng có thể đưa mã GPLv3 vào dự án phát hành chỉ theo Apache 2.0. Đây là ví dụ cần ghi hướng và phiên bản, không chỉ hai tên giấy phép.
Tương thích không phải giấy phép cho phép bỏ notice của phần gốc. Với một gói thực tế, xác định mã được chép, linking hay chương trình độc lập; đọc thông báo only/or-later và ngoại lệ. Nếu chưa biết cách kết hợp, ghi “cần xác minh” thay vì chọn một câu trả lời có vẻ an toàn cho mọi tình huống.
Dùng tài liệu riêng và dữ liệu giả định. Gói DEMO gồm app của nhóm, thư viện A theo MIT, thư viện B theo BSD-3-Clause và thành phần C theo Apache-2.0 có NOTICE. Không tải hoặc phát hành sản phẩm thật. Mục tiêu là lập danh sách kiểm tra có liên hệ tới từng tài sản và hành vi dự kiến.
Mỗi dòng có tên, phiên bản DEMO, phần được lấy, loại artifact, thông báo áp dụng và nơi lưu văn bản. Ghi A là thư viện, B là một thành phần binary được kèm tài liệu, C có một tệp nhóm đã sửa. Để trống những trường chưa biết rồi ghi câu hỏi, thay vì bịa URL hoặc hash để bảng trông hoàn chỉnh.
Kết quả mong đợi là ba dòng có phạm vi rõ. Thêm một ảnh giao diện chưa rõ quyền để thấy license của thư viện không giải quyết quyền của ảnh. Quy trình này chưa xác minh tác giả thật; nó giúp phát hiện thông tin thiếu trước khi người có trách nhiệm đánh giá gói.
Vẽ thư mục chứa chương trình, tài liệu sử dụng và một khu vực thông báo bên thứ ba. Ghi vị trí dự định giữ thông báo của A, các điều kiện và disclaimer của B, license cùng notice liên quan của C. Đây là sơ đồ tổ chức hồ sơ, chưa phải cây đã build hoặc chứng nhận bố trí đó phù hợp với mọi kênh phân phối.
Tạo thêm cột “đã thấy trong repository” và “đã thấy trong gói xuất”. Giả định A có giấy phép trong source nhưng bộ cài thiếu nó; đánh dấu trường thứ hai chưa đạt.
Với C, giả định bản gốc có NOTICE và nhóm đổi một tệp. Ghi cần xem marking của tệp sửa và notice liên quan. Đừng tự động chép toàn bộ tên mọi dự án không còn trong gói; cũng không xóa notice chỉ vì muốn màn hình ngắn hơn. Nếu chưa chắc nội dung nào áp dụng, giữ bằng chứng và đưa câu hỏi cho người phụ trách.
Với B, đặt hai câu mẫu: “có sử dụng thư viện B” và “được nhóm B chứng thực”. Đánh dấu câu thứ hai cần bằng chứng cho phép riêng theo điều kiện đang học.
Giả định phiên bản mới bỏ B và thêm một dependency D chưa có thông báo. Cập nhật inventory rồi đánh dấu các nội dung cần xem lại trong gói. Không xóa lịch sử của bản đã phát hành; hồ sơ bản cũ vẫn cần truy vết được. Tạo một bản ghi mới cho bản dự kiến, liên kết tới thay đổi cụ thể.
Tiếp theo giả định một dependency chuyển license ở phiên bản sau. Không kết luận ngược rằng mọi bản cũ đổi theo. Ghi version được nhận và văn bản tương ứng, rồi đánh giá nâng cấp. Nếu nguồn package metadata khác LICENSE của archive, lưu cả hai và chuyển phần bất nhất để xác minh, không chọn ngẫu nhiên trường dễ xử lý hơn.
Lỗi thứ nhất là xóa giấy phép để giảm kích thước gói. Hãy xem tài sản nào bị loại ở bước build và nghĩa vụ nào gắn với nó trước khi thay cấu hình. Lỗi thứ hai là đặt thông báo ở một URL không đi kèm bản phân phối rồi mặc định người nhận sẽ tìm được. Cần đối chiếu điều khoản và kênh cung cấp thật, thay vì chỉ kiểm tra link trang chủ còn sống.
Lỗi thứ ba là tin rằng license scanner đã giải quyết mọi thứ. Công cụ có thể hỗ trợ nhận diện nhưng vẫn cần review phạm vi, tệp bị bỏ sót và cách sản phẩm được dùng. Với mã do AI đề xuất, giữ yêu cầu review nguồn gốc và chất lượng như các phần tiếp nhận khác. Tự thêm SPDX identifier không biến một đoạn mã không rõ quyền thành thành phần đã xác minh.
Bài tập đã được rà soát theo các ca và kết quả mong đợi nêu trên. Chưa build gói, chạy scanner, xác minh chủ thể quyền hoặc kết luận một sản phẩm thực tế tuân thủ. Phần giá trị của hồ sơ là giúp tìm đúng bằng chứng và công việc còn thiếu trước quyết định 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.