Hiểu cho đúng quy định giấy phép Creative Commons trong Quyết định số 1878/QĐ-BGDĐT ngày 02/06/2016 về việc ban hành thể lệ cuộc thi quốc gia thiết kế bài giảng e-Learning lần thứ 4 của Bộ Giáo dục và Đào tạo

Cập nhật: Video dành cho cuộc thi e-Learning lần thứ 4 nêu bên dưới đây. 

Ngày 02/06/2016, Bộ Giáo dục và Đào tạo đã ra Quyết định số 1878/QĐ-BGDĐT về việc ban hành thể lệ cuộc thi quốc gia thiết kế bài giảng e-Learning lần thứ tư, lần đầu tiên đưa vào yêu cầu giấy phép các bài dự thi phải là Creative Commons Ghi công - CC BY (Creative Commons Attribution) hoặc Creative Commons Ghi công - Chia sẻ tương tự - CC BY-SA (Creative Commons Attribution - ShareAlike) phiên bản 4.0 với một trong các mục đích của cuộc thi, như được nêu trong Điều 1 khoản c, là để xây dựng nguồn tài nguyên giáo dục mở - OER (Open Educational Resources) phục vụ dạy, học trong và ngoài nhà trường, phục vụ mục đích học tập suốt đời, học qua mạng, đào tạo từ xa qua mạng.

Trước hết, phải khẳng định rằng, đây là một bước đi rất mới, rất tích cực của Bộ Giáo dục và Đào tạo, đúng theo xu thế của thế giới hướng tới giáo dục mở - tài nguyên giáo dục mở vì sự phát triển và bình đẳng xã hội và nhiều lợi ích khác mà giáo dục mở - tài nguyên giáo dục mở có khả năng đem lại cho giáo dục nước nhà. Tuy nhiên, việc chỉ nêu chung chung yêu cầu giấy phép các bài dự thi phải là CC BY hoặc CC BY-SA có lẽ là điều kiện rất cần thiết, nhưng chưa đủ. Nội dung bên dưới sẽ giải thích cho điều này và đưa ra các cách thức để khắc phục.

A. Nguyên tắc 5R của tài nguyên giáo dục mở (OER)

Tài nguyên giáo dục mở - OER (Open Educational Resources) tuân thủ nguyên tắc 5R, bao gồm:

1. Reuse - Sử dụng lại: mức cơ bản nhất về tính mở. Mọi người được phép sử dụng tất cả hoặc một phần tác phẩm cho các mục đích của riêng họ (ví dụ, tải về video giáo dục để xem vào thời gian rỗi);
2. Redistribute - Phân phối lại: mọi người có thể chia sẻ tác phẩm với những người khác (ví dụ, gửi một bài báo số bằng thư điện tử cho đồng nghiệp);
3. Rivise - Làm lại: mọi người có thể tùy biến thích nghi, sửa đổi, dịch, hoặc thay đổi tác phẩm (ví dụ, lấy một cuốn sách tiếng Anh và dịch nó sang tiếng Việt);
4. Remix - Pha trộn: lấy 2 hoặc nhiều tài nguyên đang tồn tại và kết hợp chúng để tạo ra 1 tài nguyên mới (ví dụ, lấy các bài giảng tiếng nói từ khóa học này và kết hợp chúng với các slide từ khóa học khác để tạo ra tác phẩm phái sinh mới);
5. Retain - Giữ lại: Không có các hạn chế quản lý các quyền số - DRM (Digital Rights Management); nội dung là của bạn để giữ, bất kể bạn là tác giả, giáo viên hay sinh viên đang sử dụng tư liệu.

Từ nguyên tắc 5R trên, có thể thấy rằng, OER sẽ là hợp lệ, nếu:

1. Thí sinh tự tạo ra tất cả các thành phần của OER; và/hoặc
2. Thí sinh làm lại và/hoặc pha trộn - kết hợp các OER và/hoặc các tài nguyên hợp pháp khác do các tác giả khác tạo ra để tạo thành một sản phẩm OER phái sinh mà thí sinh là người tổng hợp, sưu tập và/hoặc biên tập các OER đã có sẵn trước đó. Để ngắn gọn, ta gọi trường hợp này là: kết hợp các OER

B. Các dạng thí sinh của cuộc thi

B.1. Thí sinh tự tạo ra tất cả các thành phần của OER

Trong trường hợp này, thí sinh có khả năng chọn bất kỳ giấy phép Creative Commons nào cho sản phẩm OER của mình. Để tuân thủ với thể lệ của cuộc thi như được nêu trong Quyết định số 1878/QĐ-BGDĐT, các thí sinh sẽ phải chọn hoặc giấy phép CC BY hoặc CC BY-SA và tác phẩm của thí sinh sẽ trở thành OER hợp lệ, không vi phạm bản quyền của bất kỳ ai.

B.2. Thí sinh kết hợp các OER của các tác giả khác

Không giống như trong trường hợp thí sinh tự tạo ra tất cả các thành phần của OER, trường hợp này là phức tạp hơn, đòi hỏi không chỉ các thí sinh, mà các giám khảo và ban tổ chức cuộc thi phải phải nắm rõ được khi nào thì một tác phẩm OER phái sinh là hợp lệ, và khi nào thì không, dựa vào thể lệ của cuộc thi mà trong trường hợp này, OER phái sinh của thí sinh được tạo ra là kết quả của sự kết hợp từ 2 OER trở lên của (các) tác giả khác, phải được cấp phép theo CC BY hoặc CC BY-SA.

Để có thể thực hiện được điều này, tất cả các bên tham gia trong cuộc thi cần nắm được và hiểu được bản chất của tất cả các loại giấy phép Creative Commons và sự kết hợp giữa các giấy phép đó với nhau, tránh trường hợp các thành phần tạo nên tác phẩm phái sinh đó mang các giấy phép Creative Commons không tương thích với nhau, điều sẽ làm cho tác phẩm phái sinh của thí sinh trở nên không hợp lệ, vì nó chắc chắn vi phạm (các) quyền của tác giả của (các) tác phẩm OER tạo nên sản phẩm phái sinh đó.

C. Các loại giấy phép Creative Commons và công cụ trợ giúp

C.1. Giới thiệu ngắn gọn các loại giấy phép Creative Commons

Hệ thống giấy phép Creative Commons (CC) có 4 yếu tố tùy chọn, gồm:

1. Ghi công - Attribution (BY): đây là yếu tố bắt buộc cho tất cả các giấy phép CC
2. Phi thương mại - NonCommercial (NC): không sử dụng tác phẩm vào mục đích thương mại
3. Không có phái sinh - NoDerivative (ND): không cho phép sửa đổi tác phẩm gốc
4. Chia sẻ tương tự - ShareAlike (SA): tác phẩm phái sinh phải mang giấy phép như tác phẩm gốc ban đầu

Dựa vào 4 yếu tố tùy chọn, hệ thống Creative Commons có 6 giấy phép tiêu chuẩn, bao gồm:

1. Ghi công - Creative Commons Attribution (CC BY)
2. Ghi công - Chia sẻ tương tự - Creative Commons Attribution ShareAlike (CC BY-SA)
3. Ghi công - Phi thương mại - Creative Commons Attribution NonCommercial (CC BY-NC)
4. Ghi công - Phi thương mại - Chia sẻ tương tự - Creative Commons Attribution NonCommercial ShareAlike (CC BY-NC-SA)
5. Ghi công - Không có phái sinh - Creative Commons Attribution NoDerivative (CC BY-ND)
6. Ghi công - Phi thương mại - Không có phái sinh - Creative Commons Attribution NonCommercial NoDerivative (CC BY-NC-ND)

Dễ thấy là tất cả các giấy phép Creative Commons được nêu ở trên đều có yêu cầu bắt buộc 'Ghi công'. Việc ghi công cho tác giả tác phẩm OER là quan trọng, thường được (các) tác giả thực hiện khi phát hành tác phẩm của mình với mục đích để các độc giả tôn trọng BẢN QUYỀN tác giả.

Câu hỏi đặt ra là: Ghi công cho tác giả của tác phẩm OER như thế nào là đúng, đặc biệt khi thí sinh kết hợp (các) OER của (các) tác giả khác?

C.2. Công cụ hỗ trợ cấp phép và ghi công cho tác giả

Ở đây sẽ lần lượt đề cập tới vài công cụ hỗ trợ cấp phép và ghi công cho tác giả các tác phẩm được cấp giấy phép Creative Commons.

C.2.1. Công cụ hỗ trợ cấp phép của Creative Commons

Hãy tới địa chỉ: https://creativecommons.org/choose/ để thấy công cụ hỗ trợ cấp phép CC với 4 phần dạng như trong hình sau:

Hình 1. Công cụ hỗ trợ cấp phép và ghi công tác giả tác phẩm được cấp phép CC

Để có được ví dụ minh họa cụ thể, giả thiết có thí sinh đã dịch một tác phẩm từ tiếng Anh mang giấy phép CC BY-SA sang tiếng Việt với các đặc tính sau đây:

1. Tên tác phẩm phái sinh tiếng Việt: 'Tài nguyên giáo dục mở: chính sách, các chi phí và sự biến đổi'
2. Tên thí sinh đã dịch tác phẩm đó sang tiếng Việt: Lê Trung Nghĩa
3. Đường dẫn tới tác phẩm phái sinh tiếng Việt:

https://www.dropbox.com/s/rsweet9lr2j50i5/244365e-Vi-20072016.pdf?dl=0

4. Đường dẫn tới tác phẩm gốc tiếng Anh:

http://unesdoc.unesco.org/images/0024/002443/244365e.pdf

5. Giấy phép của tác phẩm phái sinh: do giấy phép của tác phẩm gốc là CC BY-SA, nên giấy phép của tác phẩm phái sinh cũng phải là CC BY-SA vì mệnh đề 'chia sẻ tương tự' SA.

Quay lại với công cụ như trên Hình 1 với 4 phần như sau:

1. 'License Features' (Các đặc tính của giấy phép): Hãy chọn các đặc tính giấy phép trong phần này để chọn giấy phép bạn muốn và bạn sẽ thấy các giấy phép tương ứng được tự động thay đổi theo và được hiển thị trong phần 'Selected License' (Giấy phép được chọn).

Ví dụ: Chọn các lựa chọn trong phần 'License Features' như trong Hình 1 để có được giấy phép CC BY-SA

2. 'Selected License' (Giấy phép được chọn). Nội dung phần này sẽ được tự động biến đổi theo các lựa chọn ở phần 'License Features' được nêu ở trên. Trong trường hợp cụ thể này, ta sẽ thấy giấy phép CC BY-SA được chọn.
3. 'Help others attribute you!' (Hãy giúp những người khác ghi công cho bạn!): Phần này là để giúp những người sử dụng tác phẩm của bạn ghi công cho chính bạn - tác giả tác phẩm. Phần này là tùy chọn, nghĩa là bạn có thể điền hay không điền các thông tin để giúp những người sử dụng ghi công cho bạn như là tác giả của tác phẩm OER.

• Trong trường hợp bạn quyết định điền các thông tin vào phần này, hãy xem mục 'Giúp những người khác ghi công cho bạn!' ở bên dưới.
• Trong trường hợp bạn không điền gì vào phần này, hãy đi tiếp xuống phần 'Have a webpage?' (Có trang web chứ?).

4. 'Have a webpage?' (Có trang web chứ?): Phần này có các thông tin được sinh ra tự động từ các thông tin ở các phần trên. Trong trường hợp bạn không điền gì ở phần 'Help others attribute you!', hãy sao chép tất cả các thông tin được tự động sinh ra bên trên dòng 'Copy this code to let your visitors know!' (Hãy sao chép mã để cho phép các khách viếng thăm biết!) rồi dán vào bài viết trên trang web của bạn và/hoặc (các) trang web có liên quan tới tác phẩm OER được cấp phép CC của bạn. Bạn sẽ thấy các nội dung ở phần này như sau:

work này được chia sẻ với các điều khoản của giấy phép Creative Commons Attribution-ShareAlike 4.0 Quốc tế .

Hãy sửa nội dung này cho phù hợp. Ví dụ bạn có thể sửa cụm từ ở trên thành:

Tác phẩm này được chia sẻ với các điều khoản của giấy phép Creative Commons Attribution-ShareAlike 4.0 Quốc tế .

Nếu bạn thành thạo ngôn ngữ đánh dấu siêu văn bản HTML, thì bạn có thể sử dụng phần nội dung trong hộp liệt kê bên dưới dòng 'Copy this code to let your visitors know!' (Hãy sao chép mã để cho phép các khách viếng thăm biết!) bằng cách sao chép toàn bộ các mã HTML trong hộp liệt để bên dưới rồi dán vào trang web của bạn và/hoặc (các) trang web có liên quan tới tác phẩm OER được cấp phép CC của bạn và có hỗ trợ HTML trong trình soạn thảo của chúng. Cũng nên sửa nội dung cho phù hợp với ngữ cảnh tiếng Việt.

Có 2 núm radio ở đáy của phần 'Have a webpage?' này giúp bạn chọn theo ý của bạn dạng biểu tượng của giấy phép CC, hoặc dạng 'Normal icon' (Biểu tượng thông thường) hoặc 'Compact icon' (Biểu tượng rút gọn).

C.2.2. Công cụ giúp những người khác ghi công cho bạn

Theo các từ tiếng Anh, nguyên tắc ghi công cho tác phẩm OER được cấp phép CC, tối thiểu gồm cụm từ viết tắt với 4 chữ cái đầu từ là TASL, có nghĩa là:

1. Title: Tên tác phẩm
2. Author: Tên (các) tác giả
3. Source: Nguồn của tác phẩm (thường là đường liên kết tới tác phẩm)
4. License: Giấy phép của tác phẩm

TASL là yêu cầu ghi công tối thiểu cho tác phẩm OER được cấp phép CC, điều ngụ ý là có thể đưa thêm các yếu tố khác vào khi ghi công, ngoài các thông tin tối thiểu đó.

Thực tế cho thấy, việc ghi công thường gây lúng túng khi bạn tạo ra và/hoặc kết hợp để tạo ra (các) tác phẩm, vì thế, có các công cụ để giúp cho việc ghi công được dễ dàng cho bất kỳ (các) tác giả/ đồng tác giả của bất kỳ phẩm OER nào, bao gồm cả các thí sinh trong cuộc thi được đề cập tới trong bài viết này.

Trong trường hợp bạn muốn bổ sung các thông tin để giúp những người sử dụng tác phẩm ghi công cho bạn được dễ dàng, đặc biệt khi những người sử dụng đó tạo các tham chiếu tới tác phẩm của bạn, hãy nháy vào đường link trong phần 'Help others attribute you!' như được nêu ở Hình 1 ở trên, để mở ra hộp thoại ghi công đầy đủ, như được chỉ ra trong Hình 2.

Vì giả thiết bạn là thí sinh cuộc thi và là tác giả của tác phẩm OER, vì thế hãy làm các bước sau:

1. Thí sinh gõ tiêu đề tác phẩm của mình vào trường 'Tiêu đề của tác phẩm'.

Ví dụ: 'Tài nguyên giáo dục mở: chính sách, các chi phí và sự biến đổi'

2. Thí sinh gõ tên của mình hoặc các đồng tác giả với mình vào trường 'Gắn với tên'

Ví dụ: Lê Trung Nghĩa biên dịch

3. Thí sinh gõ đường dẫn tới tác phẩm cần được ghi công của mình vào trường 'Gắn với URL'

Ví dụ: https://www.dropbox.com/s/rsweet9lr2j50i5/244365e-Vi-20072016.pdf?dl=0 (là địa chỉ dẫn tới tác phẩm và/hoặc để tải về tác phẩm của thí sinh)

Hình 2. Phần trợ giúp ghi công cho tác phẩm được cấp phép CC của Creative Commons

4. Thí sinh gõ đường dẫn tới tác phẩm OER nguồn của (các) tác giả khác, dựa vào đó thí sinh tạo ra tác phẩm phái sinh của mình vào trường 'Tác phẩm nguồn'

Ví dụ: http://unesdoc.unesco.org/images/0024/002443/244365e.pdf

5. Thí sinh gõ vào đường dẫn tới các quyền khác (nếu có) được gắn tới tác phẩm của mình vào trường 'More Permissions URL' (URL của nhiều sự cho phép hơn)

Ví dụ: trong trường hợp này không có thêm URL nào, vì thế trường này được bỏ trống.

6. Thí sinh mở hộp combo 'Format of work' (Định dạng tác phẩm) để chọn các dạng tác phẩm của thí sinh, như: (1) Văn bản; (2) Hình ảnh; (3) Âm thanh; (4) Video; (5) Tập hợp dữ liệu; và/hoặc các định dạng khác.

Ví dụ, chọn: Văn bản.

7. Thí sinh mở hộp combo 'License mark' (Dấu của Giấy phép) để chọn các dạng dấu giấy phép Creative Commons theo sở thích của thí sinh.

Ví dụ: để nguyên giá trị mặc định.

Sau khi hoàn thành việc ghi công cho tác phẩm, thí sinh hãy di chuyển tới phần 'Have a webpage?' (Có trang web chứ?) rồi thực hiện các hành động sau:

Hãy sao chép toàn bộ nội dung phần trên của cụm từ 'Copy this code to let your visitors know!' (Hãy sao chép mã này để cho phép những người viếng thăm của bạn biết!) rồi dán nội dung được sao chép đó vào bài viết (ví dụ bài giới thiệu về tác phẩm của bạn) trên trang web của bạn và/hoặc (các) trang web có liên quan tới tác phẩm OER được cấp phép CC của bạn. Bạn sẽ thấy các nội dung ở phần này như sau:

'Tài nguyên giáo dục mở: chính sách, các chi phí và sự biến đổi' của Lê Trung Nghĩa biên dịch được chia sẻ với các điều khoản có trong giấy phép Creative Commons Attribution-ShareAlike 4.0 Quốc tế .
Based on a work at http://unesdoc.unesco.org/images/0024/002443/244365e.pdf.

Hãy sửa nội dung này cho phù hợp. Ví dụ bạn có thể sửa cụm từ ở trên thành:

'Tài nguyên giáo dục mở: chính sách, các chi phí và sự biến đổi' của Lê Trung Nghĩa biên dịch được chia sẻ với các điều khoản có trong giấy phép Creative Commons Attribution-ShareAlike 4.0 Quốc tế .
Dựa vào tác phẩm tại http://unesdoc.unesco.org/images/0024/002443/244365e.pdf.

C.2.3. Công cụ hỗ trợ cấp phép và ghi công tác giả của dự án Washington Mở

Giống như với công cụ hỗ trợ cấp phép và ghi công tác giả của Creative Commons, bạn có thể sử dụng công cụ hỗ trợ tương tự của dự án Washington Mở (Open Washington) bằng việc đi tới địa chỉ: http://www.openwa.org/attrib-builder/ để thấy công cụ hỗ trợ cấp phép CC và ghi công tác giả của Open Washington như trong Hình 3.

Hình 3. Công cụ hỗ trợ cấp phép CC và ghi công tác giả của Open Washington

Điền các thông tin sau đây vào các trường tương ứng như sau:

1. Gõ tiêu đề tác phẩm vào trường 'Title' (Tiêu đề).

Ví dụ: Tài nguyên giáo dục mở: chính sách, các chi phí và sự biến đổi

2. Gõ vào URL của tác phẩm hoặc nơi tải về tác phẩm

Ví dụ: https://www.dropbox.com/s/rsweet9lr2j50i5/244365e-Vi-20072016.pdf?dl=0

3. Gõ tên tác giả của tác phẩm vào trường 'Author' (Tác giả)

Ví dụ: Lê Trung Nghĩa biên dịch

4. Gõ vào URL trang web của tác giả

Ví dụ: http://vnfoss.blogspot.com/

5. Gõ tên tổ chức của tác giả vào trường 'Organization'

Ví dụ: Trung tâm Nghiên cứu và Phát triển Quốc gia về Công nghệ Mở, Bộ KHCN

6. Gõ vào URL trang web của tổ chức của tác giả

Ví dụ: https://www.facebook.com/rdotvn/

7. Gõ tên dự án (nếu có) vào trường 'Project'

Ví dụ: Bản dịch tài liệu không nằm trong dự án nào, vì thế trường này được bỏ trống

8. Chọn giấy phép của tác phẩm trong hộp liệt kê 'License' (Giấy phép)

Ví dụ: chọn giấy phép Attribution-ShareAlike (CC BY-SA)

9. Chọn phiên bản giấy phép Creative Commons

Ví dụ: chọn phiên bản - version 4.0

10. Chọn ô 'This work is derivative' (Tác phẩm này là phái sinh)

Ví dụ: Vì đây là bản dịch nên chắc chắn là tác phẩm phái sinh, nên phải chọn ô này

11. Gõ vào URL của tác phẩm gốc - bản gốc tiếng Anh của tài liệu

Ví dụ: http://unesdoc.unesco.org/images/0024/002443/244365e.pdf

Sau khi hoàn thành việc ghi công cho tác phẩm, thí sinh hãy di chuyển tới phần 'Attribution' (Ghi công) rồi thực hiện các hành động sau: Hãy sao chép toàn bộ nội dung ở trường bên trên rồi dán nội dung được sao chép đó vào bài viết (ví dụ bài giới thiệu về tác phẩm của bạn) trên trang web của bạn và/hoặc (các) trang web có liên quan tới tác phẩm OER được cấp phép CC của bạn. Bạn sẽ thấy các nội dung ở phần này như sau:

"Tài nguyên giáo dục mở: chính sách, các chi phí và sự biến đổi" by Lê Trung Nghĩa biên dịch, Trung tâm Nghiên cứu và Phát triển Quốc gia về Công nghệ Mở, Bộ KHCN is licensed under CC BY-SA 4.0 / A derivative from the original work

Hãy sửa nội dung này cho phù hợp. Ví dụ bạn có thể sửa cụm từ ở trên thành:

"Tài nguyên giáo dục mở: chính sách, các chi phí và sự biến đổi" do Lê Trung Nghĩa biên dịch, từ Trung tâm Nghiên cứu và Phát triển Quốc gia về Công nghệ Mở, Bộ KHCN và được cấp giấy phép CC BY-SA 4.0 / Đây là phái sinh của tác phẩm gốc ở đây

Đây là trường hợp ghi công theo nguyên tắc TASL có cộng thêm các thông tin bổ sung khác.

C.2.4. Công cụ để kết hợp từ 2 tác phẩm OER được cấp phép Creative Commons trở lên và tính tương thích giữa các giấy phép Creative Commons khi kết hợp với nhau

Trường hợp thí sinh kết hợp các OER được cấp phép Creative Commons để tạo thành tác phẩm phái sinh, điều quan trọng là thí sinh nên sử dụng công cụ để kết hợp các OER đó, chứ không 'tưởng tượng' hoặc làm bằng tay, vì khả năng sẽ mắc lỗi vi phạm các quyền tác giả của các tác phẩm gốc OER đó là không nhỏ.

Hãy tới địa chỉ: http://www.openaccesstextbooks.org/cc_tool/license_generator.html để thấy công cụ hỗ trợ cấp phép CC và ghi công cho tác phẩm OER phái sinh của thí sinh được tạo ra từ sự kết hợp từ 2 (hoặc lớn hơn) tài nguyên được cấp phép mở CC khác nhau, như trên Hình 4a.

Trên Hình 4a có 4 phần:

1. Phần 1: 'Select License #1' (Chọn giấy phép #1 - cho OER đầu tiên sẽ được kết hợp).
2. Phần 2: 'Select License #2' (Chọn giấy phép #2 - cho OER thứ 2 sẽ được kết hợp).
3. Phần 3: 'Select A License For Your Derivative Work' (Chọn giấy phép cho tác phẩm phái sinh của bạn). Tại đây, bất kỳ khi nào chọn lại các cặp giấy phép, bạn phải bấm vào 'Reset' (Thiết lập lại) để bắt đầu việc lựa chọn lại từ đầu. Sau khi bạn đã chọn các giấy phép tương ứng cho các OER ở 2 phần trên để kết hợp với nhau, hãy nhấn vào 'See available combined license' (Xem giấy phép có sẵn sau khi [các OER] được kết hợp) và bạn sẽ thấy kết quả của việc kết hợp 2 OER với các giấy phép được lựa chọn ở 2 bước trên cho tác phẩm phái sinh của bạn, có thể với các kết quả rất khác nhau như sau:
   1. Tác phẩm phái sinh có vài khả năng lựa chọn giấy phép khi kết hợp 2 OER với các giấy phép được chọn, như trên Hình 4b. Hãy tùy chọn 1 trong các giấy phép đó.
   2. Tác phẩm phái sinh chỉ có 1 khả năng duy nhất chọn giấy phép khi kết hợp 2 OER với các giấy phép được chọn, như trên Hình 4c. Hãy chọn giấy phép đó.
   3. Tác phẩm phái sinh không có giấy phép hợp lệ khi kết hợp 2 OER với các giấy phép được chọn, như trên Hình 4c. Thay vì (các) giấy phép kết quả có thể lựa chọn như trên các Hình 4b và Hình 4c, bạn sẽ thấy trên Hình 4d có dòng chữ: 'The licenses can not be combined. Click “Reset” and try again' (Các giấy phép không thể kết hợp được. Hãy nháy “Thiết lập lại” và thử lại một lần nữa). Khi này ta nói 2 giấy phép được chọn cho các OER ở các bước 1 và 2 là không tương thích với nhau.
4. Phần 4: 'Incorporate into your document or webpage' (Hãy kết hợp vào tài liệu hoặc trang web của bạn). Khi bạn thực hiện xong 3 bước ở trên, thì văn bản giấy phép được chọn cho tác phẩm phái sinh của bạn từ việc kết hợp 2 OER ở các bước trên sẽ tự động xuất hiện trong Phần 4 này (đối với các trường hợp 2 OER với các giấy phép được chọn tương thích nhau), và bạn sẽ sao chép và dán văn vào tài liệu hoặc trang web của bạn như bạn mong muốn, hoặc ở dạng văn bản thường, hoặc ở dạng HTML, hệt như những ví dụ đã được nêu.

Trong trường hợp 2 giấy phép là không tương thích nhau, đồng nghĩa với việc 2 OER với các giấy phép được chọn không thể tạo ra một tác phẩm phái sinh với giấy phép hợp lệ được. Khi này, cách duy nhất bạn có thể làm, là lên Internet để chọn lại các OER với các giấy phép CC sao cho các giấy phép của các OER đó là tương thích với nhau, và vì thế mới có thể cho kết quả tác phẩm OER phái sinh của bạn giấy phép hợp lệ được. May thay, cho tới đầu năm 2015, đã có hơn 1 tỷ tài nguyên được cấp phép CC trên Internet và vì thế khả năng bạn chọn được các OER như ý để kết hợp là không hề nhỏ.

Hình 4a. Công cụ trợ giúp cấp phép CC cho tác phẩm phái sinh khi kết hợp từ 2 OER trở lên	Hình 4b. Trường hợp tác phẩm phái sinh có vài khả năng chọn giấy phép khi kết hợp các OER
Hình 4c. Trường hợp tác phẩm phái sinh chỉ có 1 khả năng chọn giấy phép khi kết hợp các OER	Hình 4d. Trường hợp tác phẩm phái sinh không thể có giấy phép hợp lệ khi kết hợp các OER

Bằng cách thử chọn tất cả các khả năng kết hợp giữa 2 giấy phép cho 2 OER ở các bước 1 và 2 ở trên, có thể cho chúng ta bảng về tính tương thích của các giấy phép Creative Commons tiêu chuẩn khi được kết hợp với nhau như trên Hình 5.

Hình 5. Tính tương thích của các giấy phép CC tiêu chuẩn

D. Những điều các thí sinh phải lưu ý khi kết hợp các tài nguyên được cấp phép Creative Commons

Bằng cách thử kết hợp tất cả các cặp giấy phép CC có tương thích với nhau như trên Hình 5, ta có thể đi tới kết luận rằng, các giấy phép CC BY và CC BY-SA là phù hợp với thể lệ của cuộc thi như theo Quyết định số 1878/QĐ-BGDĐT khi và chỉ khi có những kết hợp từ 2 OER trở lên với các giấy phép CC được chọn để có giấy phép CC hợp lệ cho tác phẩm phái sinh là như sau:

1. CC BY với CC BY cho kết quả tác phẩm phái sinh là CC BY, nhưng nếu thí sinh gán giấy phép CC BY-SA cho tác phẩm phái sinh thì cũng không sai, dù trong thực tế ít ai làm thế vì mức độ tự do của CC BY là lớn hơn của CC BY-SA.
2. CC BY với CC BY-SA hoặc ngược lại cho kết quả tác phẩm phái sinh là CC BY-SA.
3. CC BY-SA với CC BY-SA cho kết quả tác phẩm phái sinh là CC BY-SA.
4. Tất cả các trường hợp còn lại đều không thỏa mãn yêu cầu thể lệ cuộc thi.

E. Kết luận

Để tuân thủ với thể lệ của cuộc thi với các bài thi phải có giấy phép CC BY hoặc CC BY-SA, và phù hợp với nguyên tắc 5R của OER, các bài thi của các thí sinh sẽ là hợp lệ nếu:

1. Tự tạo ra các tài nguyên với tất cả các nội dung thành phần đều do thí sinh đó là tác giả gốc ban đầu và thí sinh có thể tùy ý gán giấy phép CC BY hoặc CC BY-SA cho tài nguyên đó.
2. Kết hợp và/hoặc tùy biến thích nghi từ 2 OER trở lên (bao gồm cả trường hợp thí sinh có một phần nội dung do mình tự tạo ra được cấp giấy phép CC BY hoặc CC BY-SA rồi kết hợp với 1 OER khác trở lên) được cấp phép CC BY và/hoặc CC BY-SA của các tác giả khác để tạo thành tác phẩm OER phái sinh với các điều kiện như sau:
   1. CC BY kết hợp với CC BY cho kết quả tác phẩm phái sinh có giấy phép là CC BY
   2. CC BY kết hợp với CC BY-SA hoặc CC BY-SA kết hợp với CC BY-SA đều cho kết quả tác phẩm phải sinh có giấy phép là CC BY-SA.
   3. Tất cả các trường hợp kết hợp còn lại là không hợp lệ.

Để cuộc thi có thể thành công tốt đẹp, mọi thí sinh và ban giám khảo rất cần được tập huấn trước để hiểu rõ tất cả những vấn đề liên quan tới cấp phép Creative Commons được nêu ở trên.

Tài liệu này mang giấy phép Creative Commons Attribution (CC BY) phiên bản v4.0 Quốc tế.

Thành phố Hồ Chí Minh, ngày 24/07/2016

Lê Trung Nghĩa

letrungnghia.foss@gmail.com

PS: Bạn có thể tải về tài liệu này ở định dạng PDF tại địa chỉ:

https://www.dropbox.com/s/af6eaq579nigwme/OER-Article-For-QD-1878.pdf?dl=0

Ngăn ngừa vụ Heartbleed tiếp sau và làm cho FOSS an toàn hơn

Preventing the next Heartbleed and making FOSS more secure

Posted 22 Jul 2016 by Mark Bohannon

Theo: https://opensource.com/life/16/7/interview-david-wheeler-making-foss-more-secure

Bài được đưa lên Internet ngày: 22/07/2016

Lời người dịch: Bài viết này trước hết dành cho bất kỳ ai, bất kỳ công ty phần mềm nguồn mở nào muốn làm việc được trong môi trường CNTT chính phủ. Nó cũng dành cho bất kỳ quan chức chính phủ nào có trách nhiệm về mua sắm phần mềm và/hoặc ra các chính sách về phần mềm của quốc gia để hiểu về các vấn đề có liên quan tới phần mềm nguồn mở.

David Wheeler là lãnh đạo lâu năm trong việc tư vấn và làm việc với chính phủ Mỹ về các vấn đề có liên quan tới phần mềm nguồn mở (PMNM). Trang web của cá nhân ông thường xuyên trích dẫn nguồn về các tiêu chuẩn mở, PMNM, và an toàn máy tính. David đang lãnh đạo một dự án mới, dự án Huy hiệu Thực hành Tốt nhất CII, nó là một phần của Sáng kiến Hạ tầng Cốt lõi - CII (Core Infrastructure Initiative) của Quỹ Linux Foundation cho việc thúc đẩy an toàn các PMNM. Trong phỏng vấn này ông nói về điều này ngụ ý gì cho cả chính phủ và những người sử dụng khác.

Hỏi và Đáp

Hãy bắt đầu với vài điều cơ bản. Dự án huy hiệu là gì và nó đã ra đời như thế nào?

Vào năm 2014, chỗ bị tổn thương Heartbleed đã được thấy trong OpenSSL, thư viện mật mã. Đáp lại, Quỹ Linux Foundation đã tạo ra Sáng kiến Hạ tầng Cốt lõi (CII) để cấp vốn và hỗ trợ cho PMNM mà chúng là các yếu tố sống còn của hạ tầng thông tin toàn cầu. CII đã nhận diện và cấp vốn cho các dự án quan trọng nhất định, nhưng nó không thể cấp vốn cho tất cả các dự án PMNM. Vì thế, CII cũng đang cấp vốn cho một vài tiếp cận để cải thiện chung an toàn của PMNM.

Dự án mới nhất CII tập trung vào việc cải thiện sự an toàn nói chung, là dự án được gắn huy hiệu các thực tiễn tốt nhất. Tôi là lãnh đạo kỹ thuật của dự án này. Chúng tôi nghĩa rằng các dự án PMNM tuân theo các thực tiễn tốt nhất có khả năng nhiều hơn là lành mạnh và để tạo ra phần mềm tốt hơn, bao gồm cả việc có sự an toàn tốt hơn. Nhưng điều đó đòi hỏi là mọi người biết những thực tiễn tốt nhất đó là gì, và liệu có hay không một dự án được đưa ra là tuân theo chúng.

Để giải quyết điều này, chúng tôi trước hết đã xem xét nhiều tài liệu và dự án PMNM để nhận diện được tập hợp các thực tiễn tốt nhất về PMNM được thừa nhận rộng rãi. Chúng tôi sau đó đã phát triển một website nơi mà các dự án PMNM có thể báo cáo liệu có hay không chúng áp dụng các thực tiễn tốt nhất đó. Trong một số trường hợp chúng tôi có thể xem xét website dự án và tự động điền vào vài thông tin. Chúng tôi sử dụng thông tin đó (dù tự động hay không) để xác định liệu dự án đó có tuân thủ đúng các thực tiễn tốt nhất hay không. Nếu dự án đó đang tuân thủ đúng các thực tiễn tốt nhất, thì dự án đó nhận được một huy hiệu “qua được kiểm tra”.

Tôi sẽ lưu ý ở đây rằng dự án gắn huy hiệu bản thân nó là một dự án PMNM. thấy Bạn có thể site của dự án đó. Chúng tôi muốn có thậm chí nhiều sự tham gia hơn, nên hãy ra nhập với chúng tôi! Để trả lời cho câuhỏi rõ ràng, vâng, nó giành được huy hiệu của riêng nó. Các dự án PMNM khác mà đã giành được huy hhiệu bao gồm nhân Linux, curl, Node.js, GitLab, OpenBlox, OpenSSL, và Zephyr. Ngược lại, OpenSSL trước khi có Heartbleed đã không qua được nhiều tiêu chí, gợi ý rằng các tiêu chí đang nắm bắt được các yếu tố quan trọng về các dự án.

Nếu bạn tham gia trong một dự án PMNM, tôi khuyến khích bạn có một huy hiệu. Nếu bạn đang nghĩ về việc sử dụng một dự án PMNM, tôi khuyến khích bạn xem liệu dự án đó có huy hiệu hay không. Bạn có thể thấy nhiều thông tin hơn ở Chương trình Huy hiệu các Thực hành Tốt nhất CII.

Bạn có thể nói cho tôi nhiều hơn về các tiêu chí của huy hiệu?

Chắc rồi. Tất nhiên, không tập hợp các thực tiễn nào có thể đảm bảo rằng các phần mềm sẽ không bao giờ có lỗi hoặc chỗ bị tổn thương. Nhưng vài thực tiễn khuyến khích sự phát triển tốt, điều tới lượt nó làm gia tăng khả năng có chất lượng tốt, và đó là những gì chúng tôi hướng tới.

Để tạo ra các tiêu chí chúng tôi đã rà soát lại nhiều tài liệu về các dự án nào nên làm; nguồn có ảnh hưởng nhiều nhất và duy nhất, có lẽ là cuốn sách của Karl Fogel: Sản xuất PMNM (Producing Open Source Software). Chúng tôi cũng đã xem một số dự án thành công đang tồn tại. Chúng tôi cũng nhận được các chỉ trích rất hữu ích bản phác thảo các tiêu chí từ nhiều người, bao gồm cả Karl Fogel, Greg Kroah-Hartman (dự án nhân Linux), Rich Salz (OpenSSL), và Daniel Stenberg (curl).

Một khi các tiêu chí ban đầu đã được xác định, chúng đã được nhóm thành các tiêu chí sau: cơ bản, kiểm soát thay đổi, báo cáo, chất lượng, an toàn, và phân tích (basics, change control, reporting, quality, security, and analysis). Chúng tôi kết thúc với 66 tiêu chí. Mỗi tiêu chí có một mã nhận diện và văn bản. Ví dụ, tiêu chí floss_license đòi hỏi rằng, “phần mềm PHẢI được phát hành như là phần mềm tự do nguồn mở (PMTDNM)”. Tiêu chí know_common_errors đòi hỏi rằng, “Ít nhất một trong các lập trình viên ban đầu PHẢI biết các dạng lỗi chung dẫn tới các chỗ bị tổn thương ở dạng này của phần mềm, cũng như ít nhất một phương pháp được tính tới hoặc làm giảm nhẹ từng trong số chúng”. Các tiêu chí là có sẵn trên trực tuyến, và một bài báo trên LWN.net thảo luận về các tiêu chí đó chi tiết hơn. Chỉ cần bỏ ra khoảng 1 giờ đồng hồ đối với một dự án điển hình PMNM để điền vào mẫu, một phần vì chúng tôi tự động điền vào vài thông tin. Nhiều trợ giúp hơn trong việc tự động hóa này được đánh giá cao.

Các tiêu chí sẽ thay đổi chậm, có lẽ theo hàng năm, khi dự án gắn huy hiệu có được nhiều hơn phản hồi và tập hợp các thực tiễn tốt nhất đang sử dụng thay đổi. Chúng tôi cũng có ý định bổ sung thêm các mức huy hiệu cao hơn vượt ra khỏi mức “qua được kiểm tra” như hiện nay, dự kiến có các mức “vàng” và “bạch kim”. Tuy nhiên, đội dự án đã quyết định tạo ra các tiêu chí theo các giai đoạn; nhiều khả năng hơn chúng tôi sẽ tạo ra các tiêu chí tốt một khi chúng tôi có kinh nghiệm với tập hợp các tiêu chí hiện hành. Một danh sách vài tiêu chí mức cao hơn được đề xuất đã được đưa lên rồi; nếu bạn có các ý tưởng, xin hãy đưa lên một ví dụ hoặc ra nhập danh sách thư dự án gắn huy hiệu của chúng tôi.

Khi đào sâu vào lĩnh vực này, điều gì đã gây ngạc nhiên nhất cho bạn trong những phát hiện của chúng tôi?

Có lẽ điều gây ngạc nhiên nhất là nhiều dự án PMNM không mô tả cách báo cáo các chỗ bị tổn thương về an toàn. Tất nhiên, cũng có nhiều dự án có làm. Nhiều dự án, như Mozilla Firefox, mô tả cách báo cáo các chỗ bị tổn thương tới một địa chỉ thư điện tử chuyên dùng và đưa ra một khóa PGP để gửi thư điện tử được mã hóa. Vài dự án, như Cygwin, có chính sách rõ ràng rằng tất cả các báo cáo lỗi phải được nêu công khai (trong trường hợp của họ thông qua một danh sách thư), và họ rõ ràng cấm báo cáo qua thư riêng tư. Tôi không phải là fan hâm mộ của các chính sách “mọi điều đều công khai” (vì chúng có thể trao cho những kẻ tấn công một sự khởi đầu), nhưng khi mọi người biết các quy định đó, là dễ dàng hơn để giải quyết các chỗ bị tổn thương. Tuy nhiên, nhiều dự án hoàn toàn không nói cho mọi người làm thế nào để báo cáo các chỗ bị tổn thương. Điều đó dẫn tới nhiều câu hỏi. Liệu báo cáo của một nhà nghiên cứu về an toàn về một chỗ bị tổn thương bằng việc sử dụng trình theo dõi vấn đề hoặc danh sách thư một cách công khai, hay có làm thứ gì đó khác hay không? Nếu dự án muốn nhận được các báo cáo riêng tư bằng việc sử dụng mã hóa, làm thế nào thông tin đó được mã hóa? CÁc khóa nào sẽ được sử dụng? Báo cáo và xử lý chỗ bị tổn thương có thể bị chậm lại nếu dự án không nghĩ về nó trước.

Có vài lý do gây ngạc nhiên về điều này. Trước hết, là đáng ngạc nhiên rằng các lập trình viên không biết trước sẽ có các chỗ bị tổn thương trong mã của họ và rằng họ nên được chuẩn bị để giải quyết chúng. Tin tức được làm đầy với các báo cáo về các chỗ bị tổn thương! Thứ 2, là ngạc nhiên dễ giải quyết vấn đề này trước về thời gian; hãy giải thích trên website dự án cách báo cáo các chỗ bị tổn thương. Điều đó chỉ mất 3 câu! Tất nhiên, việc viết điều đó xuống đòi hỏi các thành viên của dự án nghĩ về cách học sẽ xử lý các chỗ bị tổn thương, và điều đó là có giá trị. Là tốt hơn nhiều để quyết định cách xử lý các chỗ bị tổn thương trước khi chúng được báo cáo.

Điều gì không làm bạn ngạc nhiên, nhưng có thể gây ngạc nhiên cho những người khác?

Vài điều có thể gây ngạc nhiên cho bạn là:

1. Vẫn còn có các dự án (hầu hết là các dự án cũ) không hỗ trợ kho phiên bản được kiểm soát công khai (như, việc sử dụng Git), gây khó khăn cho những người khác để theo dõi những thay đổi hoặc cộng tác.
2. Vẫn có những dự án (hầu hết là các dự án cũ) không có bộ kiểm tra (hữu dụng) được tự động hóa hoặc được xây dựng tự động. Điều này làm khó hơn nhiều để thực hiện các cải tiến, và dễ dàng hơn nhiều cho các lỗi bị bỏ qua không được dò tìm ra. Nó cũng là khó để nâng cấp các phụ thuộc khi một chỗ bị tổn thương được tìm thấy trong chúng, vì không có cách dễ dàng nào để thẩm định rằng sự thay đổi đó hầu như chắc chắn vô hại.
3. Có nhiều dự án (hầu hết là các dự án cũ) mà nhiều người nghĩ là PMNM, nhưng chúng không hợp pháp để sử dụng vì chúng không có giấy phép nào cả. Phần mềm không có giấy phép hoặc đánh dấu nào khác thường là không hợp pháp để sử dụng, phân phối, hoặc sửa đổi ở hầu hết các quốc gia. Điều này đặc biệt là vấn đề trên GitHub. Bài trình bày năm 2015 của Ben Balter: Open source licensing by the numbers (Cấp phép nguồn mở theo các con số) đã thấy rằng trên GitHub, 23% các dự án với 1.000 hoặc nhiều sao hơn đã không có giấy phép hoàn toàn. Đúng là trước năm 1976, các tác phẩm ở Mỹ không có các dấu bản quyền được gắn vào từng không bị hạn chế bới bản quyền, nhưng điều đó từng lâu lắm rồi. Ngày nay, luật ở hầu hết tất cả các nước đòi hỏi rằng các lập trình viên cấp phép cho phần mềm trước khi nó có thể được những người khác sử dụng hợp pháp, và điều đó có lẽ không thay đổi. Thậm chí nếu bạn nghĩ luật không áp dụng cho bạn, thì việc bỏ qua giấy phép của PMTDNM có xu hướng ngăn cấm sự sử dụng, đồng phát triển, và rà soát lại dự án (bao gồm cả rà soát lại an toàn).
4. Hầu hết các lập trình viên vẫn còn không biết các nguyên lý cơ bản của việc phát triển phần mềm an toàn, hoặc những sai lầm phổ biến dẫn tới các chỗ bị tổn thương là gì.

Chúng tôi hy vọng rằng chương trình gắn huy hiệu sẽ giúp giải quyết các vấn đề như vậy.

Đối tới các chính phủ đang vật lộn với sử dụng PMNM, có các bài học nào từ sáng kiến này không?

Có 2 dạng các tổ chức lớn: các tổ chức mà biết họ đang sử dụng PMNM, và các tổ chức không biết họ đang sử dụng PMNM. Không có dạng thứ 3. Nếu bạn trả tiền cho các giấy phép phần mềm sở hữu độc quyền, nếu bạn nhìn vào bên trong, bạn sẽ thấy nhiều PMNM trong hầu hết tất cả các phần mềm sở hữu độc quyền. Các phần mềm tùy biến thường được xây dựng trên đỉnh và bởi PMNM.

Nhiều nhà quản lý vật lộn vì họ không hiểu sự thay đổi đã xảy ra rồi trong nền công nghiệp máy tính, ấy là, PMNM là lực lượng chính trong điện toán và nằm ở đây. Thay vì ôm lấy sự thay đổi, vẫn còn có những nhà quản lý muốn giả vờ rằng sự thay đổi còn chưa xảy ra, hoặc đang cố gắng quay lại vài “những ngày xưa tốt lành” hoang đường mà thực sự không từng tốt lành như vậy. Đối với những ai đang cố cản trở tất cả sử dụng PMNM, tôi khuyến cáo một liều thuốc bổ: Hãy dừng cố gắng quay ngược kim đồng hồ, và thay vào đó, hãy ôm lấy sự thay đổi đã xảy ra rồi.

Sự vật lộn khác nhau là những người mà chấp nhận một phần thực tế này, nhưng muốn quản lý rủi ro và không biết làm thế nào. Mục tiêu là đúng, nhưng các tiếp cận của họ thường lạc hướng. Tôi thường xuyên nghe thấy “nhưng bạn không biết ai đã phát triển PMNM”, ví dụ thế. Trong hầu hết các trường hợp điều này là sai, vì những người đã viết từng dòng lện thường là vấn đề của hồ sơ công khai (nó được đưa vào dữ liệu của hệ thống kiểm soát phiên bản). Thật ngớ ngẩn, cũng chính những người đó hạnh phúc để lấy các phần mềm sở hữu độc quyền thậm chí dù họ không có bất kfy ý tưởng nào về ai đã viết các dòng mã lệnh đó. Vấn đề có liên quan là nhiều người muốn sử dụng ự đăng ký vị trí của một công ty như là biện pháp rủi ro duy nhất đối với mã độc, và đó là mộti sai lầm. Ví dụ, một công ty có thể được đăng ký ở Mỹ, nhưng điều đó không có nghĩa là các lập trình viên và những người kiểm thử của nó nằm ở Mỹ hoặc là các công dân Mỹ. Đăng ký của công ty giống như đăng ký của con thuyền; điều này là viễn tưởng không có liên quan gì tới thực tế cả. Ngoài ra, bạn có thể là một công dân của một quốc gia và vẫn tạo ra mã độc để tấn công chính phủ nước đó. Những kiểm thử đơn giản như “điều này là từ công ty ở nước tôi” sẽ rất không hữu ích cho việc quản lý rủi ro; chúng ta cần các cách thức tốt hơn.

Đối với những người đang xem xét mang PMNM vào, nhưng cũng muốn quản lý rủi ro của chúng, thì sáng kiến này chắc chắn sẽ đưa ra vài điều giúp họ. Chúng tôi thay vì tập trung vào các thực tiễn tốt nhất khác nhau mà có khả năng nhiều hơn là để sản xuất các phần mềm tốt, thay vì tập trung vào những điều hoang đường về pháp lý như đăng ký quốc gia. Những người sử dụng tiềm nưng có thể thấy, qua dự án cấp huy hiệu, các thực tiễn tốt nhất và cách một dự án nhất định đang làm.

Tất nhiên, dự án cấp huy hiệu cho các thực tiễn tốt nhất không thể giải quyết được tất cả các vấn đề. Chúng tôi không thể nói cho bạn liệu vài PMNM nào đó sẽ giải quyết được vấn đề bạn có hay không; chỉ bạn có thể hiểu các nhu cầu của bạn. Có nhiều mô hình hỗ trợ PMNM khác nhau; trong một số trường hợp sự tải về đơn giản và sự phụ thuộc vào cộng đồng là một tiếp cận tốt, trong khi trong các trường hợp khác, bạn thực sự nên sử dụng một công ty mà cung cấp sự hỗ trợ chuyên nghiệp. Chúng tôi đang làm việc để cung cấp vài thông tin mọi người cần để đưa ra các quyết định tốt hơn.

Trong 1 lưu ý khác, khi chúng tôi đã nói lần trước, bạn đã chỉ ra rằng rủi ro của các dự án rẽ nhánh của chính phủ Mỹ từng là một vấn đề lớn. Các anh thấy tình trạng đó bây giờ thế nào?

Trước hết, sự làm rõ nhanh. Tôi sử dụng khái niệm “rẽ nhánh” để ngụ ý bất kỳ việc sao chép nào một dự án với ý định sửa đổi nó. Việc rẽ nhánh là tốt nếu bạn có kế hoạch đệ trình sửa đổi ngược về dự án chính. Vấn đề là một “rẽ nhánh dự án”, nó là một rẽ nhánh với ý định để tạo ra một dự án mới độc lập. Các rẽ nhánh dự án cản trở tới mức ngăn cấm sự cộng tác, thay vì khuyến khích nó, và điều đó giải thích vì sao các rẽ nhánh dự án là vấn đề.

Chính phủ Mỹ không theo dõi các rẽ nhánh dự án nó cấp vốn, nên tôi không thể trả lời câu hỏi đó với sự tin cậy. Nói đùa, tôi nghĩ vấn đề đó đã giảm đôi chút, nhưng vẫn còn là vấn đề lớn. Một điều mà đã giúp làm giảm việc rẽ nhánh dự án trong các dự án chính phủ cấp vốn là việc gia tăng sử dụng các kho công khai, đặc biệt là GitHub. Các kho công khai, và kỳ vọng là một kho sẽ được sử dụng, gia tăng đáng kể sự minh bạch. Nếu một công ty biết rằng nó sẽ bị ép buộc phải làm cho rẽ nhánh dự án của nó nhìn thấy được công khai, thì nó sẽ lo ngại đúng là nó có thể bị yêu cầu bảo vệ điều không thể bảo vệ được. Để giải thích chân lý này, Louis Dembitz Brandeis cho rằng, sự minh bạch thường là thuốc trừ độc tốt nhất. Hơn nữa, nếu chính phủ ép một công ty làm cho rẽ nhánh của họ sẵn sàng như là PMNM, thì vài sáng kiến kinh tế cho việc rẽ nhánh dự án sẽ biến mất, và những cải thiện của nó có thể được trộn ngược trở lại vào dự án chính (một quy trình được gọi là “chữa” bệnh rẽ nhánh).

Tuy vậy, vẫn có quá nhiều sáng kiến ngoan cố trong chính phủ. Một ví dụ rõ ràng là các nhà thầu kiếm được lợi nhuận cao hơn đáng kể nếu họ phát triển các phần mềm từ không có gì thay vì việc sử dụng lại phần mềm đang có. Nhiều dự án tái tạo lại cái bánh xe, vì chúng được trả tiền để làm như thế, và những người đóng thuế sẽ phải trả cho hóa đơn đó.

Thậm chí chính xác hơn, các nhà cung cấp biết rằng họ có thể moi được các hợp đồng hàng đống tiền nhiều hơn nếu học có thể khóa các khách hàng của họ vào các sản phẩm của họ. Nếu không có cách gì để thoát ra khỏi sản phẩm hoặc dịch vụ đó, thì nhà cung cấp có thể cứ nâng giá mà không có khó khăn gì, và nhà cung cấp không có sự khuyến khích nào để cung cấp công nghệ mới hoặc hỗ trợ tốt cả. Toàn bộ hệ thống mua sắm của chính phủ được cho là là có sự cạnh tranh mở cho công việc và công việc trong tương lai, và về lý thuyết đưa ra một lực đối kháng. Trong thực tế, điều đó thường không tồn tại.

Trong điện toán, các quyền dữ liệu (là các quyền sở hữu trí tuệ hoặc các quyền dữ liệu kỹ thuật) là đồng nghĩa với sức mạnh. Bạn không thể thay đổi phần mềm, hoặc có đấu thầu cạnh tranh cho người duy trì lựa chọn thay thế trong tương lai, trừ phi bạn có các quyền dữ liệu, thậm chí nếu bạn ban đầu đã trả tiền rồi cho sự phát triển của phần mềm đó. Vâng nhiều nhân viên chính phủ không hiểu điều đó. Các nhà thầu không hiểu điều đó, và được khuyến khích khai thác các nhân viên ngây thơ của chính phủ không hiểu điều đó. Các quyền dữ liệu được coi là quan trọng hơn nhiều so với các yêu cầu, vì các yêu cầu luôn thay đổi, trong khi các quyền dữ liệu xác định ai có thể sửa phần mềm để đáp ứng cho các yêu cầu mới đó. Các nhà thầu sẽ yêu cầu các quyền độc quyền đối với phần mềm thậm chí dù họ đã không trả tiền cho hầu hết sự phát triển của nó, hoặc sử dụng mánh khóe như tạo ra “các tuyến giao tiếp” sở hữu độc quyền mà mục đích đầu tiên của chúng là để khóa chính phủ vào nhà thầu đó. Nếu một nhà thầu có được các quyền độc quyền, thì chính phủ đánh mất vĩnh viễn khả năng của mình để có được sự cạnh tranh có hiệu quả cho sự duy trì của nó. Tương tự, các nhà cung cấp phần mềm bên thứ 3 thường có các giao diện sở hữu độc quyền, hoặc tạo ra các mở rộng sở hữu độc quyền cho các giao diện tiêu chuẩn, để cấm những người sử dụng khỏi việc thay đổi sang một nhà cung cấp cạnh tranh khác. Điều đó không để nói rằng tất cả các nhà thầu hoặc các nhà cung cấp bên thứ 3 là quỷ dữ, hoặc rằng tất cả các nhân viên chính phủ là không hiểu gì; còn lâu mới thế. Chính phủ cần những người đó! Nhưng các khuyến khích cố chấp, kết hợp với sự ngây ngô ở phía chính phủ, thường dẫn tới các tình huống ở đó chính phủ bị khóa trói vào một nhà thầu hoặc nhà cung cấp bên thứ 3, những người có thể sau đó lấy giá tùy thích cho các kết quả tồi. Gợi ý của tôi là nếu chính phủ thực sự có thể có sự cạnh tranh mở và đầy đủ về phần mềm, thì nó có thể tiết kiệm được hàng chục tỷ USD mỗi năm. Con số chính xác là ít có vấn đề hơn bản thân vấn đề đó; chúng ta rõ ràng có vấn đề cần sửa.

Tôi nghĩ sự trợ giúp lớn cho điều này có thể là yêu cầu phần mềm được phát triển bằng việc sử dụng nguồn cấp vốn của chính phủ sẽ phải được phát hành công khai như PMNM, trừ phi có nhu cầu thuyết phục để làm khác. Điều đó có thể làm giảm đáng kể sự khuyến khích tái tạo ra mọi điều từ đầu, hoặc việc cố khóa trói chính phủ vào một nhà thầu duy nhất. Chúng ta cũng có thể đặt ra các khoản phạt về tài chính lên những ai không nghiên cứu thị trường để tìm ra các lựa chọn thay thế; điều này được luật và hợp đồng yêu cầu, nhưng thường không được thực hiện. Tôi chắc chắn có những điều khác sẽ phải làm; mấu chốt là hệ thống hiện hành có nhiều vấn đề.

Những điều nào khác mà mọi người có liên quan tới chính phủ Mỹ nên biết?

Như tôi đã nêu lần trước, một trong những vấn đề lớn nhất là hầu hết các nhân viên mua sắm không hiểu rằng thực tế tất cả các PMNM là phần mềm thương mại. Theo luật Mỹ, Quy định Mua sắm của Liên bang - FAR (Federal Acquisition Regulation), và Bổ sung FAR của Bộ Quốc phòng - DFARS (DoD FAR Supplement), thì phần mềm là thương mại nếu nó có sử dụng phi chính phủ và được cấp phép cho công chúng. Đặc biệt, xem Tiêu đề 41 Phần 103 Luật Mỹ (U.S. Code Title 41 Section 103), nó định nghĩa khái niệm “khoản thương mại”.

Vì gần như tất cả các PMNM đáp ứng được định nghĩa về phần mềm thương mại, gần như tất cả PMNM là phần mềm thương mại. Một khi bạn hiểu được điều này, thì bạn hiểu rằng sử dụng PMNM bạn cũng tuân theo các quy định về phần mềm thương mại y hệt, và rằng ưu tiên của luật Mỹ cho các khoản thương mại (10 USC 2377) bao gồm cả PMNM. Sự hiểu biết này làm cho nhiều quyết định rất thẳng, nhưng nó vẫn còn chưa được hiểu rộng rãi.

David A. Wheeler làm việc cho Viện Phân tích Quốc phòng - IDA (Institute for Defense Analyses), nhưng trong cuộc phỏng vấn này ông không nói về IDA, chính phủ Mỹ, hay Quỹ Linux Foundation.

David Wheeler is a long-time leader in advising and working with the U.S. government on issues related to open source software. His personal webpage is a frequently cited source on open standards, open source software, and computer security. David is leading a new project, the CII Best Practices Badging project, which is part of the Linux Foundation's Core Infrastructure Initiative (CII) for strengthening the security of open source software. In this interview he talks about what it means for both government and other users.

Q&A

Let's start with some basics. What is the badging project and how did it come about?

In 2014, the Heartbleed vulnerability was found in the OpenSSL cryptographic library. In response, the Linux Foundation created the Core Infrastructure Initiative (CII) to fund and support open source software (OSS) that are critical elements of the global information infrastructure. The CII has identified and funded specific important projects, but it cannot fund all OSS projects. So the CII is also funding some approaches to generally improve the security of OSS.

The latest CII project, which focuses on improving security in general, is the best practices badge project. I'm the technical lead of this project. We think that OSS projects that follow best practices are more likely to be healthy and to produce better software, including having better security. But that requires that people know what those best practices are, and whether or not a given project is following them.

To solve this, we first examined a lot of literature and OSS projects to identify a set of widely accepted OSS best practices. We then developed a website where OSS projects can report whether or not they apply those best practices. In some cases we can examine the website of a project and automatically fill in some information. We use that information (automatic and not) to determine whether the project is adequately following best practices. If the project is adequately following best practices, the project gets a "passing" badge.

I should note here that the badging project is itself an OSS project. You can see its project site. We'd love to have even more participation, so please join us! To answer the obvious question, yes, it does earn its own badge. Other OSS projects that have earned a badge include the Linux kernel, curl, Node.js, GitLab, OpenBlox, OpenSSL, and Zephyr. In contrast, OpenSSL before Heartbleed fails many criteria, which suggests that the criteria are capturing important factors about projects.

If you participate in an OSS project, I encourage you to get a badge. If you're thinking about using an OSS project, I encourage you to see if that project has a badge. You can see more information at CII Best Practices Badge Program.

Can you tell me more about the badge criteria?

Sure. Of course, no set of practices can guarantee that software will never have defects or vulnerabilities. But some practices encourage good development, which in turn increases the likelihood of good quality, and that's what we focused on.

To create the criteria we reviewed many documents about what FLOSS projects should do; the single most influential source, was probably Karl Fogel's book Producing Open Source Software. We also looked at a number of existing successful projects. We also got very helpful critiques of the draft criteria from a large number of people including Karl Fogel, Greg Kroah-Hartman (the Linux kernel), Rich Salz (OpenSSL), and Daniel Stenberg (curl).

Once the initial criteria were identified, they were grouped into the following categories: basics, change control, reporting, quality, security, and analysis. We ended up with 66 criteria. Each criterion has an identifier and text. For example, criterion floss_license requires that, "the software MUST be released as FLOSS." Criterion know_common_errors requires that, "At least one of the primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them." The criteria are available online, and an LWN.net article discusses the criteria in more detail. It only takes about an hour for a typical OSS project to fill in the form, in part because we automatically fill in some information. More help in automating this would be appreciated.

The criteria will change slowly, probably annually, as the badging project gets more feedback and the set of best practices in use changes. We also intend to add higher badge levels beyond the current "passing" level, tentatively named the "gold" and "platinum" levels. However, the project team decided to create the criteria in stages; we're more likely to create good criteria once we have experience with the current set. A list of some proposed higher-level criteria is already posted; if you have thoughts, please post an issue or join the badging project mailing list.

In digging into this area, what surprised you the most in your findings?

Perhaps most surprising is that many OSS projects do not describe how to report security vulnerabilities. Many do, of course. Many projects, like Mozilla Firefox, describe how to report vulnerabilities to a dedicated email address and provide a PGP key for sending encrypted email. Some projects, like Cygwin, have a clear policy that all defect reports must be publicly reported (in their case via a mailing list), and they expressly forbid reporting via private email. I'm not a fan of "everything public" policies (because they can give attackers a head start), but when everyone knows the rules it's easier to handle vulnerabilities. However, many projects don't tell people how to report vulnerabilities at all. That leads to a lot of questions. Should a security researcher report a vulnerability using a public issue tracker or mailing list, or do something else? If the project wants to receive private reports using encryption, how should the information be encrypted? What keys should be used? Vulnerability reporting and handling can be slowed down if a project hasn't thought about it ahead of time.

There are several reasons to be surprised about this. First, it should be surprising that developers don't anticipate that there are vulnerabilities in their code and that they should be prepared to address them. The news is filled with vulnerability reports! Second, it's surprisingly easy to solve this problem ahead of time; just explain on a project website how to report vulnerabilities. It only takes one to three sentences! Of course, writing that down requires project members to think about how they will handle vulnerabilities, and that's valuable. It's much better to decide how to handle vulnerabilities before they are reported.

What didn't surprise you, but might surprise others?

Some things that might surprise you are:

1. There are still projects (mostly older ones) that don't support a public version-controlled repository (e.g., using Git), making it difficult for others to track changes or collaborate.

2. There are still projects (mostly older ones) that don't have a (useful) automated build or automated test suite. This makes it much harder to make improvements, and much easier for defects to slip through undetected. It also makes it hard to upgrade dependencies when a vulnerability is found in them, because there's no easy to way to verify that the change is almost certainly harmless.

3. There are many projects (mostly newer ones) that many people think are OSS, but they aren't legal to use because they have no license at all. Software without a license or other marking isn't normally legal to use, distribute, or modify in most countries. This is especially a problem on GitHub. Ben Balter's 2015 presentation Open source licensing by the numbers found that on GitHub, 23% of the projects with 1,000 or more stars had no license at all. It's true that before 1976, works in the U.S. without affixed copyright markings were not restricted by copyright, but that was a long time ago. Today, law in almost all countries requires that developers license software before it can be legally used by others, and that is unlikely to change. Even if you think the law doesn't apply to you, omitting a FLOSS license tends to inhibit project use, co-development, and review (including security reviews).

4. Most developers still don't know the basic principles of developing secure software, or what the common mistakes that lead to vulnerabilities are.

We're hoping that the badging program will help counter problems like these.

For governments struggling with the use of open source software, are there lessons from this initiative?

There are two kinds of large organizations: those who know they're using OSS, and those who don't know they're using OSS. There is no third kind. If you pay for proprietary software licenses, if you look inside, you'll find a lot of OSS in almost all proprietary software. Custom software is usually built on top of, and by, OSS.

Many managers struggle because they don't understand the change that has already happened in the computer industry, namely, that OSS is a major force in computing and here to stay. Instead of embracing change, there are still managers who want to pretend that the change hasn't happened, or are trying to return to some mythical "good old days" that really weren't that good. For those trying to prevent all use of OSS, I recommend a simple tonic: Stop trying to turn back the clock, and instead, embrace the change that's already happened.

A different struggle is people who partly accept this reality, but want to manage risk and don't know how. The goal is right, but their approaches are often misguided. I repeatedly hear "but you don't know who developed the OSS," for example. In most cases this is false, since who wrote each line is often a matter of public record (it's included in the version control system data). Absurdly, these same people are happy to take proprietary software even though they do not have any idea who wrote the code. A related problem is that many people want to use a company's location registration as the sole risk measure for malicious code, and that's a mistake. For example, a company may be registered in the U.S., but that doesn't mean that its developers and testers are in the U.S. or are U.S. citizens. Company registration is like ship registration; it's a legal fiction unrelated to reality. Besides, you can be a citizen of a country and still create malicious code to attack that country's government. Simple tests like "is this from a company in my country" aren't very helpful for managing risk; we need better ways.

For people who are looking at bringing in OSS, but also want to manage their risk, this initiative should definitely provide some help. We instead focus on various best practices that are more likely to produce good software, instead of focusing on legal fictions like country registration. Potential users can see, through the badging project, the best practices and how well a particular project is doing.

Of course, the best practices badging project can't solve all problems. We can't tell you if some given OSS will solve the problem you have; only you can understand your needs. There are many different OSS support models; in some cases a simple download and depending on community is a good approach, while in others, you really should be using a company that provides professional support. We're working to provide some of the information people need to make better decisions.

On a different note, when we last spoke, you indicated that the risk of the U.S. government forking projects was still a big problem. What's your take on the state of this today?

First, a quick clarification. I use the term "fork" to mean any copying of a project with the intent to modify it. Forking is great if you plan to submit the modification back to the main project. The problem is a "project fork," which is a fork with the intent to create a new independent project. Project forks inhibit collaboration, instead of encouraging it, and that's why project forks are a problem.

The U.S. government doesn't track project forks it funds, so I can't answer that question with confidence. Anecdotally, I think the problem has slightly reduced, but it's still a big problem. One thing that's helped reduce project forking in government-funded projects is the increasing use of public repositories, particularly on GitHub. Public repositories, and the expectation that one will be used, greatly increase transparency. If a company knows that it will be compelled to make its project fork publicly visible, it will correctly worry that it might be asked to defend the indefensible. To paraphrase Justice Louis Dembitz Brandeis, transparency is often the best disinfectant. In addition, if the government forces a company to make their project fork available as OSS, some of the economic incentives for project forking disappear, and its improvements might be merged back into the main project (a process called "healing" a fork).

That said, there are still too many perverse incentives in the government. An obvious one example is that the contractors get significantly higher profits if they develop software from scratch instead of reusing existing software. Many projects reinvent the wheel, because they're paid to do so, and taxpayers pick up the bill.

Even more seriously, suppliers know that they can extort orders of magnitude more money if they can lock their customers into their products. If there's no way to escape the product or service, the supplier can just keep raising prices without restraint, and the supplier has no incentive to provide new technology or good support. The government's entire acquisition system presumes that there's open competition for work and future work, and in theory that provides a countervailing force. In practice, it often doesn't.

In computing, data rights (aka intellectual rights or technical data rights) are a synonym for power. You can't change software, or have a competitive bid for an alternative future maintainer, unless you have the data rights , even if you originally paid for the development of that software. Yet many government employees don't understand that. Contractors do understand that, and are incentivized to exploit the naïve government employees who don't. Data rights are arguably much more important than requirements, because requirements constantly change, while data rights determine who can modify the software to respond to the new requirements. Contractors will ask for exclusive rights to software even though they didn't pay for most of its development, or use tricks like creating proprietary "communication buses" whose primary purpose is to lock the government into that contractor. If a contractor gets exclusive rights, then the government loses forever its ability to have effective competition for its maintenance. Similarly, third-party software suppliers often have proprietary interfaces, or create proprietary extensions to standard interfaces, to inhibit users from changing to a competing supplier. That's not to say that all contractors or third-party suppliers are evil, or that all government employees are clueless; far from it. The government needs these people! But perverse incentives, combined with naiveté on the government side, often leads to situations in which the government is locked into a contractor or third-party supplier, who can then charge arbitrary prices for poor results. My guess is that if the government could actually have full and open competition on software, it would save at least tens of billions of dollars a year. The exact number matters less than the problem; we clearly have a problem that needs fixing.

I think a big help to this would be to require software developed using government funding to be released to the public as open source software, unless there's a compelling need to do otherwise. That would greatly reduce the incentive to recreate everything from scratch, or trying to lock the government into a single contractor. We might also want to impose financial penalties on those who fail to do market research to find alternatives; this is required by law and contract, but often not done. I'm sure there are other things that should be done; the key is that the current system has many problems.

What are other things that people involved with the U.S. government should know?

As I mentioned last time, one of the biggest problems is that most acquisition personnel don't understand that practically all OSS is commercial software. Under U.S. law, the Federal Acquisition Regulation (FAR), and the DoD FAR Supplement (DFARS), software is commercial if it has a non-government use and is licensed to the public. In particular, see U.S. Code Title 41 Section 103 which defines the term "commercial item."

Because nearly all OSS meets the definition for commercial software, nearly all OSS is commercial software. Once you understand this, you understand that to use OSS you just follow the rules for commercial software, and that the U.S. law's preference for commercial items (10 USC 2377) includes OSS. This understanding makes a lot of decisions very straightforward, but it's still not widely understood.

David A. Wheeler works for the Institute for Defense Analyses (IDA), but in this interview he is not speaking for IDA, the U.S. government, or the Linux Foundation.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com