Hiểu phạm vi copyleft, GPLv2/v3, điều khoản mạng của AGPLv3, liên kết LGPL và tệp MPL; tập lập hồ sơ source, notice và chuyển giao qua bốn ca DEMO.
Một đơn vị bàn giao bộ cài có thành phần copyleft. Nhân viên chỉ gửi đường dẫn trang chủ upstream rồi cho rằng đã hoàn tất nghĩa vụ source. Nhưng bộ cài chứa thay đổi riêng, phiên bản thư viện khác và script build chưa được lưu. Vấn đề lúc này không nằm ở việc phần mềm có thu phí; nhóm cần xác định chính xác bản đã chuyển và điều kiện đi kèm.
Bài 052.2, Giấy phép phần mềm copyleft, tham chiếu Open Source Essentials 050-100 trang in 71–87, viết độc lập và đối chiếu ngày 23/10/2026. Bạn cần hiểu các khái niệm license, source, linking và phân phối ở hai bài trước. Sau bài, bạn nên nhận biết phạm vi tương hỗ của các nhóm license, đọc đúng phiên bản và lập hồ sơ chuyển giao. Nội dung nhập môn không thay thế đánh giá pháp lý về một sản phẩm cụ thể.
Copyleft là cách cấp quyền kèm điều kiện bảo toàn những quyền tương ứng cho người nhận trong phạm vi tác phẩm và hành vi mà giấy phép quy định. Nó không phải từ bỏ bản quyền. Cũng không có nghĩa mọi tệp nằm cùng ổ đĩa đều tự chuyển license hoặc mọi sửa đổi riêng đều phải công bố ngay cho cả thế giới.
“Strong” và “weak” là cách mô tả phạm vi tương hỗ, không phải thang điểm chất lượng. GPL thường được mô tả là copyleft mạnh; LGPL, MPL và EPL có những ranh giới hoặc quyền bổ sung khác. Một chữ “yếu” không có nghĩa được bỏ qua notice, source hoặc điều kiện phân phối. Cần đọc văn bản thay vì dùng nhãn làm quyết định.
Giá bán và quyền người nhận là hai vấn đề khác nhau. Có thể phân phối có thu phí trong phạm vi license cho phép. Người nhận vẫn có các quyền tương ứng theo điều kiện áp dụng. Bài tập sẽ kiểm tra hồ sơ cho hành vi chuyển bản sao; không suy ra một mô hình kinh doanh cụ thể đã phù hợp chỉ từ việc có hoặc không thu tiền.
Văn bản GPLv2 nêu điều kiện đối với việc phân phối source đã sửa, bản thực thi và source tương ứng. Source liên quan đến dạng ưu tiên để sửa, cùng các phần cần thiết theo định nghĩa của giấy phép, không chỉ một tệp bất kỳ có đuôi .c. Văn bản cũng phân biệt việc đặt các tác phẩm độc lập cùng phương tiện với tác phẩm thuộc phạm vi của nó.
Khi nhận binary đã sửa, hãy hỏi ref nào tạo ra nó, phần nào thay đổi, script build ở đâu và cách cung cấp source nào đang được áp dụng. Đường dẫn upstream mới nhất có thể không phản ánh bản đã giao. Việc giữ source chỉ có ích nếu nối được nó với artifact và điều kiện cung cấp thực tế.
Thông báo GPL-2.0-only khác GPL-2.0-or-later. Trường hợp “only” không tự cho lựa chọn GPLv3 vì bạn thích phiên bản mới hơn. Ngoại lệ nếu có cũng cần được ghi đầy đủ. Không rút gọn mọi thứ thành “GPL” trong inventory rồi mong công cụ kiểm tra suy ra chính xác quyền của bản đã nhận.
GPLv3 định nghĩa conveying là hành vi cho bên khác tạo hoặc nhận bản sao; chỉ tương tác mạng mà không chuyển bản sao không phải conveying. Khi đánh giá, ghi hành vi thực tế thay vì mặc định mọi request đều là phân phối.
Điều khoản về User Product có thể yêu cầu Installation Information trong các điều kiện của mục 6 để người nhận cài và chạy bản sửa. Đây là cơ chế liên quan vấn đề thường gọi tivoization. Không diễn giải thành quyền chung để vượt mọi DRM hoặc nghĩa vụ hỗ trợ mọi bản sửa. GPLv3 còn có điều khoản bằng sáng chế cần đọc theo phạm vi cụ thể.
Khi lập hồ sơ thiết bị, cần ghi có chuyển quyền chiếm hữu/sử dụng sản phẩm hay không, chương trình nào nằm trong đó và ai còn khả năng cài bản sửa. Những dữ kiện này giúp người đánh giá xác định điều khoản nào liên quan. Chỉ nhìn tên thiết bị hoặc nhãn nguồn mở chưa đủ để đưa kết luận.
Mục 13 của GNU AGPLv3 yêu cầu, khi bạn sửa chương trình và phiên bản đó hỗ trợ tương tác mạng từ xa, cung cấp nổi bật cho người tương tác cơ hội nhận Corresponding Source của phiên bản đó qua cơ chế mạng phù hợp, không thu phí. Đó là điểm cần phân biệt với GPLv3; không dạy rằng GPLv3 tự có cùng nghĩa vụ mạng.
AGPLv3 thuộc nhóm copyleft mạnh, khác nhãn “yếu” trong một đáp án PDF tham chiếu. Nó cũng không chỉ dành cho chương trình chạy cloud: hành vi sửa, tương tác và chuyển bản sao cần được xem theo văn bản ở từng ca. Đưa dữ liệu người dùng vào hệ thống không đồng nghĩa phải công khai dữ liệu đó như source của chương trình.
LGPLv2.1 và LGPLv3 là các phiên bản riêng cần nhận diện đúng. LGPLv3 bổ sung các quyền trên nền GPLv3; mục Combined Works có điều kiện về notice, văn bản license, khả năng kết hợp lại hoặc cơ chế shared library phù hợp, cùng các yêu cầu liên quan.
Điều đó không tương đương “link động thì tự động tuân thủ, link tĩnh luôn bị cấm”. Với phương án kỹ thuật cụ thể, cần xác định người nhận có thể thay phần thư viện theo cách yêu cầu hay không và gói bàn giao cung cấp gì. Thư viện bị sửa cũng cần được đánh giá riêng, không chỉ xem license của ứng dụng gọi nó.
Nhớ lại bài build: executable đã tạo không tự đổi khi source thay đổi. Vì vậy hồ sơ cần liên kết source thư viện, object hoặc dữ liệu kết hợp lại nếu phương án yêu cầu, lệnh build và artifact cuối. Chạy thành công trên máy người bàn giao không xác nhận người nhận có đủ tài liệu và quyền cần thiết.
Mozilla mô tả MPL 2.0 là copyleft cấp tệp. Khi phân phối, cần đọc các điều kiện đối với Covered Software và source của nó. Có thể kết hợp với mã khác theo điều kiện giấy phép, nhưng không dùng câu “mã ở tệp khác” làm mẹo để xóa nghĩa vụ của phần được bao phủ.
Đọc MPL 2.0 để nhận diện Modifications, Larger Work và cơ chế Secondary Licenses. Cơ chế này có điều kiện, gồm trường hợp Incompatible With Secondary Licenses; không được tự đổi giấy phép mọi tệp MPL sang một license khác chỉ vì có mục tương thích trong văn bản.
EPL 1.0 và EPL 2.0 không phải cùng một văn bản. EPL 2.0 định nghĩa Modified Works, quy định cung cấp source và có cơ chế Secondary License với các điều kiện, thông báo tương ứng. Không xếp nó thành “thân thiện doanh nghiệp nhất” như một kết luận khách quan cho mọi nhu cầu. Tương thích cần xét license, phiên bản và cách kết hợp cụ thể.
Dùng hồ sơ giả định, không tải hoặc phân phối sản phẩm thật. Tạo bốn cột: hành vi, thành phần, bằng chứng đang có và câu hỏi còn mở. Mục tiêu là tìm điều cần kiểm tra, không tự cấp giấy chứng nhận tuân thủ. Mỗi ca bên dưới độc lập; không giả định các thành phần đã được kết hợp với nhau.
Giả định nhóm định chuyển chương trình GPL-2.0-only đã sửa cho một đối tác. Hồ sơ hiện chỉ có binary và URL trang chủ upstream. Ghi phần thiếu: ref bản gốc, patch của nhóm, source tương ứng, script liên quan, notice và cách cung cấp source được chọn. Người học cần chỉ ra vì sao URL chung chưa đủ liên kết tới bản sửa đã giao.
Kết quả mong đợi là một danh sách công việc có người phụ trách và tài sản cần giữ. Chưa có source tương ứng thì đánh dấu chưa hoàn tất đánh giá trước khi chuyển gói. Không tự đổi dòng license sang GPLv3 để làm biểu mẫu hợp lệ, vì thông báo đang giả định là only.
Giả định phiên bản sửa hỗ trợ người dùng tương tác từ xa. Người quản trị nói không gửi binary nên không cần xem tiếp. Ghi câu hỏi về mục 13: cơ hội nhận source được thể hiện ở đâu, source nào khớp phiên bản vận hành và cách truy cập có phù hợp không. Không gộp database nghiệp vụ vào source chỉ vì nó ở cùng server.
Kết quả mong đợi là nhận biết nghĩa vụ mạng cần xem, không kết luận tất cả dịch vụ web đều phải áp dụng AGPL. Nếu đổi thông báo sang GPLv3, cần đánh giá lại theo chính văn bản đó; không giữ nguyên kết luận chỉ vì tên hai giấy phép gần giống nhau.
Giả định nhóm chọn shared library nhưng chưa ghi khả năng thay thư viện. Liệt kê điều cần chứng minh về cơ chế liên kết, phiên bản tương thích giao diện, notice và các tài sản được yêu cầu. Nếu chỉ có một ảnh chụp ứng dụng đang chạy, đánh dấu chưa đủ bằng chứng về khả năng thay thế trong gói nhận được.
Tiếp theo giả định chuyển sang static linking. Ghi lại phương án và tài sản cần xem xét cho việc kết hợp lại theo license áp dụng, không tự kết luận cấm tuyệt đối. Bài tập chưa build một ứng dụng LGPL thật; kết quả là hồ sơ kỹ thuật cần giao cho người đánh giá, không phải thử nghiệm relink đã thành công.
Giả định một tệp Covered Software theo MPL-2.0 đã được sửa và gói được phân phối. Ghi tệp, diff và source của phần được bao phủ, cùng notice và cách người nhận lấy source. Kiểm tra riêng các tệp mới chứa mã được sao chép từ phần đó, không chỉ những tệp giữ nguyên tên.
Sau khi rà soát bốn ca, thêm mục “đã xác nhận” và “cần xác minh”. Hồ sơ đạt khi mọi câu hỏi gắn với tài sản và người xử lý cụ thể, đồng thời không có kết luận pháp lý vượt bằng chứng. Không gửi thư, tải gói hoặc sửa license của một repository bên ngoài trong bài tập này.
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.