Your SlideShare is downloading. ×
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Otd lessons-learned-and-best-practices-for-military-software-vi
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Otd lessons-learned-and-best-practices-for-military-software-vi

562

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
562
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Phát triển Công nghệ Mở Những bài học học được và những thực tiễn tốt nhất cho các phần mềm quân sựĐược Trợ lý Bộ trưởng Quốc phòng (Các mạng Tích hợp Thông tin)NII/DoD, Giám đốc Thông tin (CIO) và Thứ trưởng Bộ Quốc phòng về Mua sắm, Công nghệ và Hậu cần (AT&L) bảo trợ Dịch sang tiếng Việt: Lê Trung Nghĩa; letrungnghia.foss@gmail.com Dịch xong: 31/05/2011Bản tiếng Anh: http://www.oss-institute.org/OTD2011/OTD-lessons-learned-military-FinalV1.pdf Open Technology Development (OTD) Lessons Learned And Best Practices For Military Software Sponsored by the Assistant Secretary of Defence (Networks Information Integration) NII/DoD Chief Information Officer (CIO) and the Under Secretary of Defence for Aquisition, Technology and Logistics (AT&L)
  • 2. 2011 - Các bài học học được về công nghệ mở Phát triển Công nghệ Mở (OTD): Các bài học học được và các thực tiễn tốt nhất cho các phần mềm quân sự 16/05/2011 Được Trợ lý Bộ trưởng Quốc phòng (Các mạng Tích hợp Thông tin) NII/DoD, Giám đốc Thông tin (CIO) và Thứ trưởng Bộ Quốc phòng về Mua sắm, Công nghệ và Hậu cần (AT&L) bảo trợ.Tài liệu này được tung ra theo giấy phép Creative Commons Attribution ShareAlike 3.0 (CCBY-SA). Bạn được tự do để chia sẻ (để sao chép, phân phối và truyền tác phẩm) và để trộn (để s ửa tácphẩm cho phù hợp), theo điều kiện thẩm quyền được trao (bạn phải trao thẩm quyền tác phẩm nàytheo cách thức được tác giả hoặc người cấp phép chỉ định (nhưng không theo bất kỳ cách nào màgợi ý rằng họ chứng thực cho bạn hoặc việc sử dụng của bạn đối với tác phẩm)). Để có thêm thôngtin, hãy xem http://creativecommons.org/licenses/by/3.0/.Chính phủ Mỹ có các quyền không hạn chế đối với tài liệu này theo DFARS 252.227-7013.Các phần của tài liệu này ban đầu được xuất bản trong Thông tin Kỹ thuật Ph ần m ềm (SoftwareTech News), tập 14, số 1, tháng 01/2011. Xem See https://softwaretechnews.thedacs.com/ đ ể cóthêm thông tin. Phiên bản – 1.0Dịch sang tiếng Việt: Lê Trung Nghĩa, letrungnghia.foss@gmail.com; Dịch xong: 31/05/2011Bản tiếng Anh: http://www.oss-institute.org/OTD2011/OTD-lessons-learned-military-FinalV1.pdf Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software 2011-05-16 Sponsored by the Assistant Secretary of Defense (Networks & Information Integration) (NII) / DoD Chief Information Officer (CIO) and the Under Secretary of Defense for Acquisition, Technology, and Logistics (AT&L)This document is released under the Creative Commons Attribution ShareAlike 3.0 (CCBY-SA)License. You are free to share (to copy, distribute and transmit the work) and to remix (to adapt thework), under the condition of attribution (you must attribute the work in the manner specified by theauthor or licensor (but not in any way that suggests that they endorse you or your use of the work)).For more information, see http://creativecommons.org/licenses/by/3.0/ .The U.S. government has unlimited rights to this document per DFARS 252.227-7013.Portions of this document were originally published in the Software Tech News, Vol.14, No.1,January 2011. See https://softwaretechnews.thedacs.com/ for more information. Version - 1.0Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 2/77
  • 3. 2011 - Các bài học học được về công nghệ mởThừa nhậnSự phát triển của tài liệu này đã được Dan Risacher, Trợ lý Bộ trưởng Quốc phòng (Các mạng Tíchhợp Thông tin) NII/DoD, Giám đốc Thông tin (CIO) và Fritz Schulz, Thứ trưởng Bộ Quốc phòng vềMua sắm, Công nghệ và Hậu cần (AT&L), Ban Lãnh đạo Lĩnh vực hoạt động Nhanh, Nhóm Nghiêncứu Chéo AT&L và Heather Burke của Trung tâm các Hệ thống SPAWAR Đại Tây dương (SSCLANT) bảo trợ.Tác giả của tài liệu này là John Scott, David A. Wheeler, Mark Lucas, và J.C. Herz.Các tác giả mong muốn cảm ơn các nhóm và cá nhân sau vì s ự biên so ạn, cung c ấp thông tin đ ầuvào, trợ giúp và chỉ dẫn: John Weathersby, Kane McLean, Gunnar Hellekson, Josh Davis, DebBryant, Scott Goodwin, nhóm làm việc MIL-OSS (http://mil-oss.org &http://groups.google.com/group/mil-oss) và nhiều người khác.Người đệ trình: ________________________________________________Tên: John Scott, Ngày Hợp đồngChức danh: Sr. Kỹ sư Hệ thống & Lãnh đạo các Công nghệ Mở, RadiantBlue Technologies, Inc.Người phê chuẩn: ________________________________________________Tên: Fritz Schultz, Chính phủ Mỹ ngàyChức danh: Điều hành Giám sát, OASD Research & Engineering, Rapid Field DirectorateNgười phê chuẩn: ________________________________________________Tên: Dan Risacher, Chính phủ Mỹ ngàyChức danh: Giám đốc Liên kết, Văn phòng Giám đốc Thông tin (CIO) của Bộ Qu ốc phòng, Tíchhợp & các Dịch vụ Doanh nghiệpVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 3/77
  • 4. 2011 - Các bài học học được về công nghệ mởMục lụcChương 1. Giới thiệu............................................................................................................................6 1.1 Phần mềm là một tài nguyên có thể thay mới được của quân sự...............................................6 1.2 Phát triển Công nghệ Mở (OTD) là gì.......................................................................................9 1.3 Các tiếp cận phát triển phần mềm dùng ngay được OTS (Off-the-shelf), bao gồm cả OTS của Chính phủ Mở (OGOTS) và PMNM.............................................................................................10 1.4 Những điều kiện tiên quyết chủ chốt đối với OTD..................................................................11 1.4.1 Các quyền trí tuệ..............................................................................................................11 1.4.2 Tính đơn giản...................................................................................................................13Chương 2. Điều hành các dự án OTD................................................................................................14 2.1 Thiết lập một chương trình OTD.............................................................................................14 2.1.1 Bước 1: Xác định các lựa chọn sử dụng lại......................................................................14 2.1.2 Bước 2: Xác định dự án để thiết lập.................................................................................15 2.1.3 Bước 3: Chọn và áp dụng một giấy phép chung..............................................................16 2.1.4 Bước 4: Thiết lập sự điều hành........................................................................................16 2.1.4.1 Tính có thể rẽ nhánh.................................................................................................16 2.1.4.2 Các mô hình điều hành.............................................................................................17 2.1.5 Bước 5: Thiết lập sự cộng tác...........................................................................................18 2.1.6 Bước 6: Tạo ra đường lối kỹ thuật của dự án...................................................................18 2.1.7 Bước 7: Công bố..............................................................................................................19 2.1.8 Tiếp tục rà soát lại các bước từ 1-7..................................................................................19 2.2 Hạ tầng kỹ thuật cho sự cộng tác.............................................................................................19 2.2.1 Các chức năng mấu chốt..................................................................................................20 2.2.2 Truy cập, công khai, bí mật và kiểm soát xuất khẩu........................................................21 2.2.3 Hosting.............................................................................................................................22 2.3 Giao tiếp truyền thông.............................................................................................................23 2.3.1 Hãy là người tham gia......................................................................................................23 2.3.2 Tránh các thảo luật riêng tư.............................................................................................24 2.3.3 Sử dụng các cơ chế truyền thông hiệu quả......................................................................24 2.3.4 Thực tế rà soát mã nguồn dễ thấy.....................................................................................25 2.3.5 Sự khiếm nhã là không nên .............................................................................................25 2.3.6 Tính tới những người độc hại...........................................................................................25 2.3.7 Hãy nhận thức được về các vai trò...................................................................................25 2.4 Quản lý kỹ thuật/Các tiêu chí kỹ thuật....................................................................................26 2.4.1 Các mục tiêu.....................................................................................................................26 2.4.2 Sử dụng lại và cộng tác trong các thành phần OTD.........................................................27 2.4.3 Không rẽ nhành PMNM chỉ vì sử dụng của Chính phủ...................................................27 2.4.2 Các tiêu chuẩn mở............................................................................................................28 2.4.5 Quản lý các đóng góp......................................................................................................28 2.5 Đưa ra liên tục..........................................................................................................................29 2.5.1 Quản lý các quyền trí tuệ.................................................................................................29Chương 3. Lập trình OTD: Các chiến thuật, công cụ và thủ tục........................................................31 3.1 Khởi tạo và/hoặc chuyển sang OTD........................................................................................31 3.1.1 Phân tích các lựa chọn thay thế (AoA)............................................................................32 3.1.2 Yêu cầu thông tin (RFI)...................................................................................................33Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 4/77
  • 5. 2011 - Các bài học học được về công nghệ mở 3.2 Yêu cầu đề xuất (RFP).............................................................................................................34 3.2.1 Tuyên bố về các mục đích (SOO) & ý định.....................................................................34 3.2.2 Các quyền trí tuệ..............................................................................................................35 3.2.3 Các định dạng dữ liệu, các tiêu chuẩn & các giao diện...................................................35 3.2.4. Các công nghệ OTS........................................................................................................36 3.2.5 Các thực tiễn của OTD.....................................................................................................36 3.2.6 Các phân phối...................................................................................................................37 3.3 Lựa chọn nguồn: Đánh giá các đề xuất....................................................................................37 3.3.1 Đánh giá cách mà đề xuất tốt đáp ứng RFP.....................................................................38 3.3.2 Các tiêu chí chấp nhận/phê chuẩn đối với các phân phối................................................38 3.3.3 Các cạm bẫy phải tránh....................................................................................................39Chương 4. Phát triển & Phân phối liên tục.........................................................................................40 4.1 Các chu kỳ phát triển nhanh....................................................................................................40 4.2 Kiểm thử, chứng thực và làm cho tin tưởng.............................................................................40 4.3 Chuyển sang các hoạt động & duy trì......................................................................................41 4.4 Khả năng tìm kiếm..................................................................................................................41 4.5 Các bài học học được...............................................................................................................42 4.6 Danh sách chọn các thành công của OTD...............................................................................42Phụ lục A: Chính sách và chỉ dẫn của chính phủ Mỹ về tính mở.......................................................44 A.1 Các tiêu chuẩn và các giao diện mở (bao gồm các định dạng dữ liệu mở).............................45 A.1.1 Chính phủ Mỹ.................................................................................................................46 A.1.1.1 Các tiêu chuẩn đồng thuận tự nguyện.....................................................................46 A.1.1.2 Gắn thẻ (Biểu 70)....................................................................................................48 A.1.2 Bộ Quốc phòng...............................................................................................................48 A.2 PMNM....................................................................................................................................50 A.2.1 Gần như tất cả PMNM là thương mại và thương mại dùng được ngay (COTS)............51 A.2.2 PMNM không bị cấm vì các kiểm soát thông tin trong Freeware, Shareware và các đảm bảo....................................................................................................................................52 A.3 Văn hóa cộng tác/phân tán và các công cụ hỗ trợ trực tuyến..................................................53 A.4 Tính lanh lẹ của công nghệ (Các hệ thống mở và kiến trúc mở) ...........................................54Phụ lục B: Các yêu cầu pháp lý cho PMNM đưa ra cho công chúng của chính phủ hoặc các nhà thầu............................................................................................................................................................55Phụ lục C: Những điều cơ bản về PMNM.........................................................................................66 C.1 Định nghĩa PMNM..................................................................................................................66 C.2 Luật về các quyền trí tuệ.........................................................................................................68 C.2.1 Bản quyền & Giấy phép..................................................................................................68 C.2.2 Các bằng sáng chế...........................................................................................................68 C.2.3 Thương hiệu.....................................................................................................................69 C.3 Các dạng và các tổ hợp giấy phép của PMNM.......................................................................69Phụ lục D: Chọn một giấy phép PMNM như thế nào.........................................................................71 D.1 Các tiêu chí cấp phép chủ chốt...............................................................................................71 D.2 Qui trình chọn giấy phép đơn giản.........................................................................................72Các tham chiếu...................................................................................................................................75Bảng chú giải.....................................................................................................................................77Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 5/77
  • 6. 2011 - Các bài học học được về công nghệ mởChương 1. Giới thiệuMục đích của tài liệu này là để giúp cho cá nhân và các nhà thầu của chính phủ M ỹ tri ển khai pháttriển công nghệ mở (OTD) cho các phần mềm bên trong các dự án của chính phủ, đặc biệt trongquốc phòng.OTD là một tiếp cận đối với sự phát triển phần mềm/hệ thống trong đó những người phát triển trongcác tổ chức khác nhau về quân sự, liên bang, thương mại và có khả năng là công chúng có th ể c ộngtác phát triển và duy trì phần mềm hoặc một hệ thống theo một cách th ức phi t ập trung. OTD ph ụthuộc vào các tiêu chuẩn và các giao diện mở, các phần mềm nguồn mở (PMNM) và các thiết k ếmở, các công cụ trực tuyến cộng tác và phân tán, và sự lanh lẹ về công nghệ. [OTD2006].Vào tháng 04/2006, Thứ trưởng Bộ Quốc phòng về các Hệ thống Tiên tiến và các Khái niệm(AS&C) đã xuất bản Lộ trình Phát triển Công nghệ Mở [OTD2006]. Kế hoạch Lộ trình OTD đã t ậptrung vào các bước và các khuyến cáo để triển khai các thực tiễn này bên trong Bộ Quốc phòng.Tài liệu này được chia thành 4 chương. Chương đầu ngắn gọn giải thích ngữ c ảnh đối v ới OTD vàvì sao nó quan trọng đối với quân đội Mỹ. Chương 2 đ ưa ra nh ững b ước c ụ th ể cho vi ệc thi ết l ập,quản lý và phân phối các dự án OTD bên trong chính phủ. Chương 3 xác đ ịnh các th ủ t ục ch ươngtrình cho OTD, bao gồm các phân tích những lựa chọn thay thế, qui trình Yêu c ầu Thông tin/Yêucầu Đề xuất (RFI/RFP), đánh giá các đề xuất, chọn nguồn, ngôn ngữ làm hợp đồng, và các tiêu chíchấp nhận/phê chuẩn cho việc phân phối. Chương 4 làm việc với quản lý vòng đời: sự chuyển tiếp,các hoạt động và bảo trì, và khuyến khích một cộng đồng những người phát tri ển cho s ự phát tri ểnhiện đang diễn ra.1.1 Phần mềm là một tài nguyên có thể thay mới được của quân sự “Nước Mỹ không thể rút lui ra đằng sau một đường Maginot của các tường lửa hoặc nếu không nó sẽ gặp rủi ro bị xéo qua. Chiến tranh không gian mạng giống như là chiến tranh dùng mẹo, trong đó tốc độ và sự linh hoạt là quan trọng nhất”. ― William J. Lynn III. [Lynn2010]Phần mềm đã trở thành trung tâm đối với cách mà một chiến binh th ực hi ện các nhi ệm v ụ. Vì s ự tincậy vào phần mềm sẽ là một sức mạnh, Bộ Quốc phòng (DoD - Department of Defense) ph ải tuântheo một chiến lược tích cực để quản lý hồ sơ phần mềm của mình và thúc đẩy một văn hóa nội bộđối với các giao diện, module hóa và sử dụng lại mở [Scott2010]. Đ ặc biệt, DoD ph ải có ph ần m ềmmà dễ dàng có thể áp dụng được cho việc thay đổi các nhu c ầu nhi ệm v ụ và có th ể đ ược ti ến hóa vàđược phân phối nhanh chóng ở chi phí thấp để đáp ứng được các yêu cầu nhiệm vụ một cách đúnglúc. Sự tiến hóa về công nghệ đi sau một sự tiến hóa song song trong các phương pháp luận muasắm và thái độ của các tập đoàn để tạo điều kiện cho sự mở ra, sử dụng lại, và sửa đổi các ph ầnmềm xuyên khắp DoD và Chính phủ Mỹ.Phần mềm là kết cấu xúc tác cho việc lên kế hoạch, các vũ khí và các hệ thống h ậu c ần hi ện đ ạihoạt động. Nó có thể là tài nguyên quân sự có khả năng thay mới đ ược m ột cách vô t ận. Các kh ảnăng tiến hóa khi phần mềm mới được tạo ra một lần nữa ho ặc xây d ựng d ựa trên ph ần m ềm hi ệnđang tồn tại. Từ những cảm biến mặt đất tới các vệ tinh, phần mềm là ở khắp mọi nơi; nó là sự thểhiện cuối cùng của tri thức quân sự được truyền vào mã nguồn và được triển khai trên chiến địa.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 6/77
  • 7. 2011 - Các bài học học được về công nghệ mởChúng ta cần một cách thức phát triển bất kể ngày tháng, triển khai và cập nh ật các h ệ th ống ph ầnmềm cường độ lớn mà sẽ đáp ứng được nhịp độ và các yêu cầu nhiệm vụ bất kể thay đổi thế nào củacác tác chiến quân sự.Hãy tưởng tượng nếu chỉ nhà sản xuất của một rãnh xoắn (trong súng) được phép làm s ạch, s ửa l ỗi,sửa đổi hoặc nâng cấp rãnh xoắn đó. Quân đội thường nhận ra bản thân mình trong tình huống nàyvới người đóng thuế, nhà thầu phát triển phần mềm: một nhà thầu với một sự độc quyền về tri thứccủa một hệ thống phần mềm quân sự và kiểm soát mã nguồn phần mềm. Điều này chỉ hợp lý đối vớinhà thầu độc quyền, nhưng tạo ra sự thiếu khả năng và tính không hiệu quả đối với chính phủ, giảmcác cơ hội cho cơ sở công nghiệp, hạn chế nghiêm trọng sự cạnh tranh đối với những cập nh ật ph ầnmềm, làm rỗng các tài nguyên có thể được sử dụng để có hiệu quả tốt hơn và lãng phí ti ền mànhững người đóng thuế cung cấp.Để giải quyết được vấn đề này, một chế độ sở hữu trí tuệ phần mềm hiện đại mở r ộng mà c ơ sởcông nghiệp quốc phòng cần phải xác định để xúc tác cho sự truy cập một cách rộng rãi đ ối v ới n ềncông nghiệp để bảo vệ tri thức, bao gồm cả mã nguồn phần mềm, tài liệu, các thi ết kế phần cứng vàcác giao diện. Kết quả sẽ làm gia tăng sự cạnh tranh và một chi phí thu ần th ấp đ ối v ới s ự đ ổi m ớisáng tạo. Thời gian trôi đi, quân đội có thể tiến hóa các kiến trúc phần mềm chung và các nền tảngcơ bản rộng lớn của nền công nghiệp để làm gia tăng khả năng thích nghi, tính mau lẹ và, quantrọng nhất, khả năng đáp ứng được với những mối đe dọa mới, biến động một cách nhanh chóng.Những lợi ích chính của OTD là: • Tính mau lẹ/Tính mềm dẻo gia tăng: Vì chính phủ có sự truy cập và các quy ền không h ạn chế đối với mã nguồn được phát triển bằng tiền của người đóng thuế, nên mã ngu ồn có th ể được thực hiện một cách có thể nhận biết được và có thể truy cập được đối với nh ững ng ười quản lý, các nhân viên dân sự và các nhà thầu chương trình tương tự nh ư nhau, làm gia tăng tiềm năng đáp ứng được nhu cầu hoặc yêu cầu mới đối với cơ sở mã nguồn đang tồn tại mà nó cung cấp một phần lớn của giải pháp có thể được nhập vào hoặc được cải tiến để đáp ứng một nhiệm vụ mới. Cũng thế, các thành phần được chính phủ cấp tiền đang tồn tại trước đó từ các chương trình khác nhau có thể được lắp ráp mà không có các chi phí và nh ững s ự chậm trễ không cần thiết gỡ rối cho các quyền sở hữu trí tuệ để xác định cái gì là đ ược phép và không được phép. Thay vì phải bắt đầu từ không có gì để phát triển hoặc cải tiến một khả năng, chính phủ có thể sử dụng lại những gì chính phủ đã trả tiền và làm việc và thiết kế từ một cơ sở rộng lớn các lập trình viên và các nhà thầu mà họ quen với mã nguồn và thành phần và có thể nhanh chóng lắp ráp, trộn và sửa đổi các hệ th ống và các thành ph ần đang có sẵn với mã nguồn khác đang tồn tại. • Đưa ra nhanh hơn: Vì các lập trình viên chỉ cần tập trung vào nh ững thay đ ổi, và s ự tích h ợp của các khả năng phần mềm hiện đang có thay vì phải phát triển lại toàn bộ các hệ thống, họ có thể giảm được đáng kể thời gian đưa ra các khả năng mới. Thậm chí khi m ột module hoặc thành phần được phát triển từ không có gì để thay thế một thành ph ần đã l ỗi th ời, thì những lợi ích phát triển lại như vậy từ các giao diện và tiêu chuẩn mở đã được chứng minh trong các hệ thống mà mà module đó tương tác được với chúng. Việc xúc tác để sinh ra các mã nguồn có sở hữu từ tiền của những người đóng thuế đã trả, thì thời gian để phát triển và triển khai có thể giảm đáng kể. • Đổi mới sáng tạo gia tăng: Với sự truy cập tới mã nguồn đ ối v ới các kh ả năng hi ện đang t ồn tại, các lập trình viên và các nhà thầu có thể tập trung vào sự đổi mới sáng tạo và các yêu cầu mới mà chúng còn chưa đáp ứng được bằng các khả năng của mã nguồn đang tồn tại.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 7/77
  • 8. 2011 - Các bài học học được về công nghệ mở Tính lanh lẹ này là đặc biệt quan trọng vì một sự thâm hụt đ ược đ ưa ra v ề s ố l ượng các công dân Mỹ với các học vị về khoa học máy tính và kỹ thuật có thể sẽ là rõ ràng để làm việc trong các dự án quân sự trong các thập niên tiếp theo [Viện Hàn lâm Khoa h ọc Qu ốc gia 2008]. Khi một tỷ lệ lớn hơn các học vị kỹ thu ật phần mềm đ ược các qu ốc gia n ước ngoài nắm giữ, và các chương trình của Mỹ là hấp dẫn bởi sự đổi mới sáng tạo và công việc có sinh lợi trong khu vực tư nhân, thì quân đội sẽ đối mặt với sự thiếu hụt dài hạn các kỹ s ư phần mềm để làm việc trong các hệ thống đặc chủng của quân đội. Bộ Quốc phòng vì thế phải tập trung vào thách thức dài hạn đối với việc thu thập các mức đổi mới sáng tạo cao hơn ngoài kho tài năng và kỹ năng con người bị hạn chế hơn. Sẽ là quan trọng đ ể thúc đ ẩy sự đầu tư của con người bằng việc để các kỹ sư tập trung vào 10% mã nguồn cải thi ện một cách tích cực một hệ thống mà cũng không cần phải đòi hỏi phải tạo lại 90% khả năng đã có sẵn rồi. • Giảm thiểu rủi ro: việc tạo ra các khả năng mới từ không có gì là r ủi ro h ơn so v ới vi ệc s ử dụng lại các khả năng đang tồn tại mà chúng đã được chứng minh và được hiểu tốt rồi. Bằng việc sử dụng lại các khả năng ở dạng mã nguồn, các giao di ện và các h ệ th ống do chính ph ủ sở hữu, các lập trình viên có thể bỏ ra nhiều thời gian và tài nguyên hơn trong các phần r ủi ro nhất của triển khai. • Bảo hiểm và an ninh thông tin: Một trong những giá trị lớn nhất của phát triển nguồn mở là việc xúc tác cho sự truy cập của cộng đồng rộng lớn hơn tới nguồn phần mềm. Theo cách này các lỗi sẽ cạn và vì thế thấy dễ dàng hơn. Sự truy cập r ộng rãi h ơn t ới mã ngu ồn ph ần mềm cũng là chìa khóa cho việc hình thành và duy trì một dáng vẻ an ninh phần mềm từ việc có khả năng rà soát lại mã nguồn phần mềm cho tới việc xem những gì thực s ự hiện diện bên trong phần mềm đó. • Chi phí thấp hơn: Chi phí đầu tiên sẽ giảm được có lợi cho OTD là ti ền thu tô t ừ s ự đ ộc quyền mà chính phủ trả cho các nhà thầu để họ đã xây dựng một bức tường có tính loại trừ xung quanh các khả năng mà họ được trả tiền từ chính Chính phủ để phát triển. Họ có thể đã phát triển mã nguồn một cách nội bộ (nghiên cứu và phát triển nội bộ – IRAD – Internal Research And Development) mà nó là có giá trị, nhưng trong một hệ th ống OTD mà mã nguồn đã được module hóa sao cho chính phủ có thể thực hiện được một quyết định h ợp lý về việc liệu họ có muốn cấp phép lại cho mã nguồn đối với một d ự án m ới hay tr ả ti ền đ ể phát triển một sự thay thế. Toàn bộ giá trị đầu tư của chính phủ đã không bị làm rỗng bởi việc trộn lẫn IRAD vào một hệ thống do chính phủ đã đầu tư như một ph ương ti ện đ ảm b ảo cho sự khóa trói vào một nhà cung cấp cụ thể. Với các quyền và sự truy cập không hạn chế tới mã nguồn do chính phủ cấp tiền, chính phủ có thể vẽ ra trong một kho r ộng l ớn h ơn những đề xuất cạnh tranh đối với những cập nhật phần mềm và các khả năng mới mà chúng thúc đẩy các hệ thống hiện hành. Sự hạn chế thu tô từ sự độc quyền, kết hợp với sự cạnh tranh lớn hơn, sẽ làm giảm chi phí và cải thiện chất lượng của kết quả phân phối, vì bất kỳ nhà thầu nào làm việc trong một hệ thống đều biết họ có thể bị thay thế bằng một đối thủ cạnh tranh có sự truy cập đầy đủ tới mã nguồn và tài liệu.Như Bộ trưởng Quốc phòng Robert Gates đã nói “Giếng dầu phun [tiền] đã và đang tắt và sẽ ở trạngthái tắt trong một giai đoạn thời gian”. DoD cần một hệ sinh thái phát triển ph ần mềm có hi ệu qu ảhơn – đổi mới sáng tạo với chi phí thấp hơn. OTD vắt ép sự lãng phí tài chính ra kh ỏi s ự cân b ằngbằng việc giảm sự khóa trói và gia tăng sự cạnh tranh.Bằng việc triển khai OTD, DoD có thể giúp làm cho mã nguồn phần mềm thành một tài nguyên cóthể thay mới được của quân sự một cách vô hạn.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 8/77
  • 9. 2011 - Các bài học học được về công nghệ mở1.2 Phát triển Công nghệ Mở (OTD) là gì “Trong một thế giới thực với các tài nguyên và kỹ năng hạn chế, các cá nhân và nhóm hình thành, tan rã và cải biên tình thế cộng tác hoặc cạnh tranh của h ọ trong m ột cu ộc v ật l ộn liên tục để loại bỏ hoặc vượt qua được những trở ngại của môi trường xã h ội và v ật lý. Sự lanh lẹ về công nghệ nên là một thước đo”. ― Col John Boyd (USAF) [Boyd1976]Như được nêu ở trên, OTD là một tiếp cận đối với s ự phát triển ph ần m ềm/h ệ th ống trong đó nh ữnglập trình viên (bên ngoài chính phủ và quân đội) phát triển và duy trì một cách cộng tác ph ần m ềmhoặc hệ thống theo một cách thức phi tập trung. OTD phụ thuộc vào các tiêu chuẩn và giao diệnmở, phần mềm nguồn mở và các thiết kế mở, các công cụ trực tuyến cộng tác và phân tán, và sựlanh lẹ về công nghệ. [OTD2006]Những thực tiễn này được chứng minh và được sử dụng trong thế giới thương mại. Các tiêu chu ẩnvà các giao diện mở cho phép các hệ thống và các dịch vụ tiến hóa trong một thị trường biến động.Việc sử dụng, cải tiến, và phát triển phần mềm nguồn mở (PMNM) làm gi ảm t ới m ức t ối thi ểu thi ếtkế kỹ thuật phần mềm dư thừa và xúc tác cho sự phát triển lanh lẹ c ủa các h ệ th ốn g. Các công cụtrực tuyến cộng tác và phân tán bây giờ được sử dụng một cách r ộng rãi trong phát tri ển ph ần m ềm.Khu vực tư nhân cũng thường đấu tranh để tránh bị khóa trói vào một nhà cung c ấp ho ặc công ngh ệduy nhất và thay vào đó cố gắng giữ các lựa chọn công nghệ của mình là m ở (nghĩa là, b ằng vi ệcgắn vào các tiêu chuẩn mở). Các nghiên cứu trước đây đã ghi thành tài liệu rằng PMNM hiện đượcsử dụng trong nhiều ứng dụng sống còn của DoD và bây giờ là một ph ần không th ể tách r ời đ ượccủa hạ tầng quân sự [MITRE2003] [OTD2006].Các phương pháp luận của OTD dựa vào khả năng của một cộng đồng phần mềm có quan tâm truycập vào mã nguồn phần mềm hoặc các giao diện ứng dụng xuyên khắp doanh nghi ệp. S ự truy c ậptới mã nguồn, các tài liệu thiết kế và tới các nhà lập trình khác và những người sử dụng đầu cuốixúc tác cho sự phát triển phi tập trung các khả năng mà chúng thúc đẩy cho các tài s ản ph ần m ềmhiện đang tồn tại. Các phương pháp luận OTD đã và đang được sử dụng trong phát tri ển ngu ồn m ở,các kiến trúc của các tiêu chuẩn mở, và thế hệ gần đây nhất các công nghệ cộng tác d ựa trên web.Mô hình phát triển PMNM là thành công vì các cộng đồng lợi ích tham gia vào là c ả nh ững l ậptrình viên và những người sử dụng.OTD đưa vào những sáng kiến nguồn mở nhưng không bị hạn chế đối với sự phát triển và các ch ếđộ cấp phép của PMNM, mà chúng làm cho sự phân phối lại mã nguồn có hi ệu lực. Đi ều quantrọng, trong ngữ cảnh của báo cáo này và tạo ra những thảo lu ận về chính sách, đ ể phân bi ệt gi ữaPMNM và OTD, khi mà OTD có thể đưa vào mã nguồn mà sự phân phối của nó có th ể b ị h ạn ch ếđối với DoD, và quả thực chỉ có thể truy cập được trong các mạng bí mật. S ự thúc đ ẩy OTD bêntrong DoD không vi phạm tình trạng pháp lý của phần mềm được phát tri ển b ằng ti ền c ủa khu v ựctư nhân bởi các nhà cung cấp thương mại.Nói chung, điều quan trọng phải đơn giản hóa sử dụng, sửa đổi, và phân phối. Nếu mà lấy một độicác luật sư để xác định liệu có các quyền phù hợp để sửa đổi hay không cho một chương trình, thì sẽkhông làm được.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 9/77
  • 10. 2011 - Các bài học học được về công nghệ mở1.3 Các tiếp cận phát triển phần mềm dùng ngay được OTS (Off-the-shelf), bao gồm cả OTS của Chính phủ Mở (OGOTS) và PMNM.Một chiến lược OTD cho phép các tổ chức phát triển và duy trì ph ần m ềm theo m ột cách th ức c ộngtác. Để tối đa hóa sự cộng tác, phần mềm nên được phát triển để sử dụng các thành ph ần OTS vàbản thân nó trở thành OTS ở một mức độ thực tiễn tối đa.Phần mềm OTS đơn giản là phần mềm mà nó được làm sẵn rồi và s ẵn sàng đ ể s ử d ụng. S ự h ợp lýcho việc phát triển phần mềm OTS là để tạo ra phần mềm mà nó có th ể được sử dụng cho nhiềumục đích, thay vì sử dụng phần mềm được xây dựng tùy biến cho một mục đích và s ử dụng đ ơnnhất. Phần mềm OTS có tiềm năng tiết kiệm được thời gian, tiết kiệm ti ền, làm gia tăng ch ất l ượng,và làm gia tăng sự đổi mới sáng tạo thông qua việc gộp các tài nguyên. Thậm chí khi một h ệ th ốngcủa khách hàng là cần thiết, thì việc xây dựng nó từ nhiều thành phần OTS sẽ có nhiều ưu điểm.Có nhiều cách thức khác nhau mà phần mềm OTS có thể được duy trì. M ột s ố OTS có th ể đ ược gi ữvà được duy trì bên trong chính phủ Mỹ (nghĩa là, vì nó là bí mật hoặc được kiểm soát xu ất kh ẩu);như những phần mềm OTS được chính phủ chỉ định (GOTS). Các điều khoản OTS mà là các đi ềukhoản thương mại (như, để được bán, được cấp phép, hoặc được đưa ra công khai để s ử d ụng khôngtrong chính phủ) là các OTS thương mại. Lưu ý là theo luật và qui định, ph ần m ềm đ ược c ấp phépcho công chúng và được sử dụng cho ít nhất một mục đích không phải của chính phủ là phần mềmthương mại, thậm chí nếu nó được chính phủ duy trì. Hình 1 miêu tả các dạng tiếp cận duy trì OTSkhác nhau này. Hình 1. Các chiến lược duy trì OTSCó 2 dạng phần mềm OTS thương mại: PMNM và phần mềm s ở h ữu đ ộc quy ền. Trong c ả 2 tr ườnghợp chúng đều có thể được một người duy trì duy nhất hoặc một cộng đồng duy trì. Trong s ự duy trìcủa cộng đồng sẽ thường có một tổ chức duy nhất xác định liệu các đề xuất có nên được chấp nhậnhay không, nhưng mấu chốt ở đây là công việc này có xu hướng được phân trong số những người cóảnh hưởng.Ngày nay, ở những nơi có phần mềm GOTS, thì nó có xu hướng sẽ được một người duy trì duy nh ấtphát triển và duy trì. Điều này có xu thế làm giảm tính có thể áp dụng được c ủa GOTS. Nhi ềuchương trình của chính phủ có thể sử dụng một cách tiềm tàng một thành phần GOTS nếu nhữngthay đổi chắc chắn nào đó đã được thực hiện, nhưng không thể thực hiện đ ược nh ững thay đ ổi đ ốivới thành phần GOTS này một cách trực tiếp, và thậm chí nếu chúng đã được thực hiện, thì s ẽVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 10/77
  • 11. 2011 - Các bài học học được về công nghệ mởkhông có cấu trúc nào với nó cho những thay đổi có thể được trộn ngược trở lại vào s ản phẩmGOTS chính để tất cả cùng sử dụng. Ngược lại, hầu hết các dự án PMNM được cộng đồng duy trì,nơi mà các tổ chức khác nhau làm việc một cách tích cực cùng nhau để phát triển phần mềm hữu íchcho tất cả họ. Dự án PMNM một người duy nhất duy trì có tồn tại, nhưng chúng là ít phổ biến hơn.Một dự án GOTS mở (OGOTS) là một dự án GOTS sử dụng các ti ếp cận phát triển cộng tác c ủanhiều tổ chức để phát triển và duy trì phần mềm, theo cách tương tự đ ối v ới PMNM. M ột d ự án nh ưvậy bên trong DoD đôi lúc bị giới hạn như là “phần mềm nguồn cộng đồng DoD” hoặc “PMNMcủa Chính phủ” (GOSS). Một mục tiêu của tài liệu này là để làm gia tăng s ố lượng các d ự án GOTSmà chúng là các dự án OGOTS. Một dự án có thể trở thành OGOTS thay vì PMNM vì các nhà lãnhđạo của nó muốn sự đổi mới sáng tạo, tốc độ phát triển, và chi phí th ấp có th ể t ới t ừ s ự đ ồng pháttriển của nhiều bên tham gia: 1. Chính phủ thiếu các quyền về trí tuệ để làm cho nó mở hơn (như, chính phủ có th ể có các quyền theo mục đích của chính phủ GPR ( government-purpose rights) và không có các quyền không hạn chế), và/hoặc 2. Chính phủ mong muốn duy trì một ưu thế an ninh quốc gia bằng việc không làm cho ph ần mềm đó sẵn sàng đối với các kẻ địch tiềm tàng (đặc biệt những phần mềm như vậy s ẽ là bí mật và/hoặc xuất khẩu bị kiểm soát).Bổ sung thêm, các dự án GOTS nên xác định khi nào chúng nên tr ở thành COTS (nh ư, khi các d ựán PMNM do cộng đồng hỗ trợ). Đặc biệt, các dự án GOTS nên xem xét nghiêm túc vi ệc chuy ểnsang duy trì như PMNM sau khi một hệ thống đã được tri ển khai. Có m ột lo ạt nh ững lý do vì saochính phủ nên giữ các phần mềm chắc chắn nào đó trong nội bộ, như, vì s ự sở hữu duy nh ất đ ối v ớiphần mềm trao cho chính phủ Mỹ một ưu thế khác biệt đối với các kẻ đ ịch c ủa mình. Tuy nhiên, ưuthế về công nghệ thường là trôi nổi. Thường có một điều khoản được phát triển thương mại sẵn sàngcho công chúng mà nó bắt đầu để thực thi các chức năng tương tự. Khi nó chín mu ồi, các c ơ quankhác bắt đầu sử dụng giải pháp không phải GOTS này, làm cho giải pháp GOTS có ti ềm năng tr ởthành lỗi thời. Những trường hợp như vậy thường đặt ra những quyết định khó khăn, khi mà chínhphủ phải xác định liệu có trả chi phí không đối xứng rất nặng đ ể chuy ển hay không, hay n ếu s ẽ ti ếptục “như thường” với các hệ thống GOTS bây giờ đã lỗi thời của mình (v ới các chi phí hàng nămcao và những hạn chế có thể gây rủi ro cho cuộc sống và các nhiệm vụ). Điều này có nghĩa là có r ủiro đáng kể đối với chính phủ nếu chính phủ cố giữ riêng phần mềm GOTS đó bên trong chính ph ủquá lâu.OTD liên quan tới sự phát triển của cộng đồng trong số những người sử dụng của chính ph ủ, và vìthế bao gồm cả PMNM và OGOTS.1.4 Những điều kiện tiên quyết chủ chốt đối với OTD1.4.1 Các quyền trí tuệTheo định nghĩa, một dự án OTD được xây dựng trong sự cộng tác. Sự cộng tác như vậy ch ỉ có thểkhi mà một khung pháp lý cho phép nó (bao gồm các quyền trí tu ệ c ần thi ết) và khi các c ơ s ở c ủakhung này có thể hiểu được đối với những người thường.Khái niệm “các quyền trí tuệ” có nghĩa là một tập hợp các quyền đối với một tác phẩm trí tuệ đượcgiữ bởi hàng loạt các cá nhân thông qua các luật, qui định, giấy phép, hợp đồng, ... phù hợp. Cácluật phù hợp bao gồm bản quyền, bằng sáng chế, và luật về thương hiệu. Luật bản quyền là đ ặc biệtVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 11/77
  • 12. 2011 - Các bài học học được về công nghệ mởquan trọng; những người giữ bản quyền tác phẩm, hoặc có các quyền chủ chốt mà một người giữcác quyền có, có thể đặt ra các điều kiện khi nào thì tác phẩm đó có thể được sử dụng, được sửa đổi,hoặc được phân phối lại. Vì những mục đích của tài liệu này, tất cả các luật và qui định đụng chạmtới cách mà các tác phẩm có thể được chia sẻ và được sử dụng s ẽ ảnh h ưởng t ới các quy ền trí tu ệ;bao gồm cả các luật và các qui định đối với sự bí mật và kiểm soát xuất khẩu.Vấn đề chính trong bất kỳ dự án OTD nào là để thực hiện các quy ền trí tu ệ sao cho ph ần m ềm cóthể được sử dụng, được xem xét, được sửa đổi, và được phân phối lại trong cộng đồng.Khi được thực hiện đúng, việc đòi hỏi các quyền trí tuệ cần thiết cho một ti ếp c ận OTD s ẽ khôngxung đột với chính sách của DoD. Qui định Mua sắm Liên bang (FAR) c ủa DoD B ổ sung (DFARS)227.7203 có thể bị hiểu lầm như việc đấu thầu một tiếp cận OTD, nhưng khi được xem xét kỹ thì nóhoàn toàn không cấm OTD. DFARS 227.7203-1(c) (được rà soát lại vào ngày 20/01/2011) nói rằng“Những người chào hàng sẽ không bị yêu cầu, hoặc như một điều kiện có trách nhiệm đối với sự nàixin hoặc như một điều kiện để trao thưởng, sẽ bán hoặc nếu khác từ bỏ bất kỳ quy ền nào cho Chínhphủ trong phần mềm máy tính được phát triển chỉ bằng chi phí của tư nhân ngo ại tr ừ các ph ần m ềmđược xác định tại 227.7203-5(a)(3) tới (6)”. Tương tự, DFARS 227.7203-1(d) nói r ằng “Nh ữngngười chào hàng và các nhà thầu sẽ không bị cấm hoặc không được khuy ến khích đ ối v ới vi ệc cungcấp hoặc chào để cung cấp phần mềm máy tính được phát triển chỉ bằng chi phí của tư nhân chỉ vìcác quyền của Chính phủ để sử dụng, sửa đổi, đưa ra, tái sản xuất, thực thi, hiển thị, hoặc mở phầnmềm ra có thể bị hạn chế”. Tuy nhiên, lưu ý rằng những chính sách này chỉ áp dụng cho phần mềmđược phát triển chỉ bằng chi phí của tư nhân. Chính phủ có thể yêu cầu rằng chính phủ nhận cácquyền đối với phần mềm mà người đóng thuế đã trả để phát triển (một phần hoặc toàn phần), vàphần mềm như vậy là sự tập trung của tài liệu này.Việc có được các quyền trí tuệ rộng rãi (cũng như bản thân các sản phẩm trí tu ệ) h ạn ch ế đ ược m ộtrào cản chính đối với sự cạnh tranh, một rào c ản mà GAO và nh ững c ơ quan khác đã l ưu ý nhi ềunăm và đang được tích cực giải quyết: • Báo cáo của Văn phòng Kiểm toán Liên bang GAO (Government Accountability Office) GAO-06-839 tháng 07/2006 [GAO 2006] đã nói rằng “Sự thiếu hụt các quyền của dữ liệu kỹ thuật đã hạn chế tính mềm dẻo của các dịch vụ để tiến hành các thay đ ổi đ ối v ới các k ế hoạch bền vững có mục đích để đạt được sự tiết kiệm chi phí và đáp ứng được những yêu cầu pháp lý về các khả năng duy trì kho chứa... Trừ phi DoD đánh giá và đảm bảo các quyền của mình để sử dụng các dữ liệu kỹ thuật từ sớm trong quá trình mua s ắm các h ệ thống vũ khí khi DoD có tác dụng đòn bẩy lớn nhất để thương th ảo, thì DoD có th ể s ẽ đ ối mặt sau này với những thách thức trong việc làm cho bền vững các hệ th ống vũ khí su ốt vòng đời của chúng”. • Báo cáo của GAO GAO-10-833 tháng 07/2010 [GAO2010] th ấy rằng đối v ới “các d ịch v ụ hỗ trợ các hệ thống vũ khí của DoD, thì thiếu sự truy cập của chính ph ủ t ới các d ữ li ệu k ỹ thuật sở hữu độc quyền và sự tin cậy lâu nhiều thập kỷ vào các nhà thầu cụ thể vì hạn ch ế v ề sự tinh thông - hoặc thậm chí loại bỏ luôn khả năng - cạnh tranh”. Đây là m ột v ấn đ ề nghiêm trọng, vì sự cạnh tranh “là một công cụ sống còn để đạt được s ự hoàn v ốn đ ầu t ư t ốt nhất của chính phủ”. Gần 60% trong số 47 hợp đồng phi cạnh tranh của DoD được GAO xem xét, thì bộ này về cơ bản đã bị mắc kẹt với một nhà th ầu c ụ th ể vì nó đã thi ếu các d ữ liệu kỹ thuật đằng sau các hàng hóa và dịch vụ mà nó đã từng mua. • Ashton B. Carter vào năm 2010 [Carter 2010] đã lưu ý các vấn đ ề có liên quan t ới s ự c ạnh tranh. Điểm đầu tiên của ông về việc cung cấp những sự thúc đẩy là để “Tránh những v ụVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 12/77
  • 13. 2011 - Các bài học học được về công nghệ mở mua được định hướng và những vật thay thế khác vì sự cạnh tranh thực sự. Sử dụng các gói dữ liệu kỹ thuật và các kiến trúc hệ thống mở để hỗ trợ một môi trường cạnh tranh liên tục”. • Bản ghi của David M. Van Buren năm 2011 [Buren 2011] là sự triển khai của Không Lực đối với đường hướng của USD (AT&L) cho một chiến lược cạnh tranh dày 1 trang. Bản ghi của Không Lực này đòi hỏi rằng mọi chương trình của Không Lực mô t ả cách mà nó s ẽ “có được các dữ liệu kỹ thuật, tài liệu phần mềm máy tính, và các quyền s ở h ữu trí tu ệ có liên quan cần thiết cho việc vận hành, duy trì, bền vững lâu dài, nâng cấp, và cạnh tranh trong tương lai” và một tổng kết về phân tích các trường hợp nghiệp vụ nếu nó không có đ ược chúng.Một dự án OTD đòi hỏi các quyền trí tuệ cụ thể nào đó; việc đòi hỏi các quyền như vậy là luôn luônvới chính sách và đường lối của DoD.1.4.2 Tính đơn giảnSự cộng tác bị gượng gạo bởi tính phức tạp không cần thiết. Phấn đấu liên t ục đ ể đ ơn gi ản hóa d ựán. Đặc biệt, đảm bảo rằng các vấn đề về quyền trí tuệ là đơn giản và rõ ràng (nh ư, thông qua cácgiấy phép rõ ràng và phổ biến), mà tư liệu là dễ dàng có sẵn cho tất c ả nh ững ai có kh ả năng truycập nó, và rằng những thiết kế kỹ thuật là các module rõ ràng.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 13/77
  • 14. 2011 - Các bài học học được về công nghệ mởChương 2. Điều hành các dự án OTDChương này đưa ra khung cơ bản cho việc điều hành một dự án OTD. Tiểu ph ần đ ầu tiên mô t ảcách thiết lập một chương trình OTD một khi một đề xuất dự án đã được chấp thuận. Các ti ểu ph ầntiếp sau thảo luận việc thiết lập một hạ tầng kỹ thuật cho sự cộng tác, các vấn đề truyền thông, cáctiêu chí quản lý/kỹ thuật, và sự phân phối liên tục. Trong DoD chúng phải phù h ợp theo các quitrình mua sắm của DoD; cách mà điều này có thể xảy ra được thảo luận trong chương 3.2.1 Thiết lập một chương trình OTDMột khi một đề xuất dự án đã được chấp nhận, thì một chương trình OTD có thể được thiết lập có sửdụng các bước được phác thảo ở bên dưới. Nhiều thông tin hơn về cách làm điều này từ vi ễn c ảnhcủa một dự án PMNM có thể thấy trong chương 2 của [Fogel2009].2.1.1 Bước 1: Xác định các lựa chọn sử dụng lạiĐầu tiên, tìm kiếm các dự án PMNM đang tồn tại mà chúng có chức năng phù h ợp. M ột tìm ki ếmweb đơn giản các chuỗi “open source software” (“phần mềm nguồn mở”) cộng với một kh ả năngmong muốn sẽ thường biến thành thứ gì đó gần với những gì bạn cần. Cũng xem xét l ại các site cáckho PMNM như http://www.sourceforge.net, http://www.freshmeat.net, http://www.github.com,http://directory.fsf.org và http://code.google.com. Thậm chí nếu không có gì s ẵn sàng đ ể s ử d ụngmột cách trực tiếp, thì có thể có những phần nhỏ mà có thể là những ý tưởng được tích hợp hoặchữu dụng.Áp dụng kiểu cơ hội chủ nghĩa đối với PMNM là quan trọng vì s ự đ ổi m ới sáng t ạo v ề công ngh ệtrước hết đang xảy ra trên Internet không có gì là bí mật, không phải là trong môi trường quân đ ội.Hầu hết các phần nhỏ đối với bất kỳ dự án đưa ra nào cũng sẵn sàng ở đó, và có vô số các PMNMcó thể nhanh chóng đưa ra trước được các nhu cầu của các dự án chính phủ. Sự đánh giá, lựa chọn,và tham gia cẩn thận trong các dự án bên ngoài này là cách hiệu quả nhất để tiến hóa các khả năngqua vòng đời của một chương trình của chính phủ. Các phần mềm GOTS đang tồn tại có thể nhanhchóng trở thành lỗi thời một khi có một dự án COTS nhà nước (bao gồm c ả m ột d ự án PMNM) v ớimục tiêu y như vậy.Bạn cũng nên xem xét các lựa chọn phần mềm GOTS đang tồn tại. Không có ch ỗ duy nh ất nào đ ểtìm các phần mềm như vậy, nhưng sử dụng các máy tìm kiếm ph ổ bi ến có th ể là đáng giá, cũng nh ưviệc tìm kiếm trong Intellipedia và DTIC.Nếu bạn có phần mềm đã được phát triển trước đó rồi như một ph ần c ủa m ột h ợp đ ồng c ủa chínhphủ, thì hãy xác định liệu bạn có các quyền trí tuệ đủ để đưa ra hoặc chuy ển ph ần m ềm đó thànhnhư một dự án ODT được không. Đối với sự phát triển và duy trì như một d ự án OTD, thì ph ầnmềm đó (như Hình 1.1) cần phải được tung ra như một OGOTS hoặc ưu tiên hơn như một d ự ánPMNM công khai được cộng đồng duy trì. Phụ lục B làm sáng tỏ sự hợp pháp của việc đ ưa raGOTS như là PMNM, phụ thuộc vào các nhà chức trách được viện tới trong hợp đồng ban đầu.Nhiều chương trình của chính phủ có công nghệ hiện hành mà ban đầu được cấp vốn từ chính phủ.Nếu các quyền trí tuệ đối với các công nghệ đó là không phù hợp hoặc không th ể xác đ ịnh đ ược, thìchính phủ nên xem xét thương thảo với các nhà tích hợp/các nhà cung cấp phù hợp để đưa ra mãnguồn theo các quyền dữ liệu ít hạn chế hơn đối với một dự án OGOTS hoặc PMNM. Một cách dễdàng để làm điều này là cấp vốn một cách đơn giản cho quá trình chuyển đổi đối với (các) nhà thầu.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 14/77
  • 15. 2011 - Các bài học học được về công nghệ mở2.1.2 Bước 2: Xác định dự án để thiết lậpĐưa ra các lựa chọn sử dụng lại, xác định những dự án mới nào là cần thiết và những dự án đang tồntại nào cần phải được chuyển dịch sang OTD. Trong một số trường hợp, “dự án” mới có thể là mộtdự án để mở rộng một số dự án đang tồn tại và để sự mở r ộng đó đ ược tích h ợp vào trong d ự án banđầu. Ở những nơi có thể, hãy tách dự án đó thành vài dự án nhỏ h ơn v ới các giao di ện rõ ràng.Những dự án nhỏ hơn này có thể được phân chia theo một loạt các tiêu chí, bao gồm có thể việc sửdụng lại (để tối đa hóa số lượng những người tham gia trong ít nh ất m ột vài d ự án) và s ự c ần thi ếtphải hạn chế sự truy cập (các module bí mật hoặc được kiểm soát xu ất kh ẩu có th ể c ần đ ược táchbiệt khỏi các thành phần khác, nghĩa là, bằng việc tạo ra một “khung” không bí mật trong đó “cáctrình cài cắm” được kiểm soát có thể được đặt ra).Đặt tên cho từng dự án sao cho không dễ bị nhầm lẫn với các dự án khác. Nó nên là có thể nêu tênđược và dễ tìm trên một máy tìm kiếm web (lý tưởng thì, nó có th ể ch ỉ là k ết qu ả t ừ m ột s ự tìmkiếm; chắc chắn tránh các tên không thể tìm được như “the” hoặc “why”).Mỗi dự án (bao gồm bất kỳ dự án hiện đang tồn t ại nào chuy ển đ ổi sang OTD) c ần m ột tuyên b ố v ềdự định mà nó tham chiếu tới triết lý duy trì phần mềm OTD. Như được khuyến cáo trong[Fogel2009] “tuyên bố nhiệm vụ nên cụ thể, giới hạn, và trên tất cả, ng ắn g ọn”. Tuyên b ố nhi ệm v ụnên làm rõ mục tiêu để sử dụng các nguyên tắc phát triển mở (như tránh s ự khóa trói vào m ột nhàcung cấp duy nhất) và những gì mà các sản phẩm kết quả nên làm. Đây là m ột ví d ụ v ề m ột ph ầnmềm tốt, từ http://www.openoffice.org: Để tạo ra, như một cộng đồng, bộ phần mềm văn phòng quốc tế hàng đầu sẽ chạy trên tất cả các nền tảng và đưa ra sự truy cập tới tất cả chức năng và dữ liệu thông qua các giao diện lập trình ứng dụng API dựa trên các thành phần mở và định dạng tệp dựa trên XML.Trong một dự án của DoD, tuyên bố về triết lý duy trì ph ần m ềm có th ể tham chi ếu t ới DFARS227.7203-2 (“Mua sắm phần mềm máy tính và tài liệu phần mềm máy tính phi thương mại”), và đặcbiệt văn bản tại DFARS 227.7203-2(b)(1) (đậm và gạch chân được bổ sung vào): Những người quản lý dữ liệu hoặc các nhân viên của các yêu cầu khác có tránh nhiệm xác định các nhu cầu tối thiểu của Chính phủ. Bổ sung thêm vào với sự thực thi, tính tương thích, hoặc các xem xét kỹ thuật khác của phần mềm như mong đợi, cần có những xác định nên xem xét những yếu tố như nhiều site hoặc các yêu cầu sử dụng được chia sẻ, liệu triết lý duy trì phần mềm của Chính phủ có đòi hỏi quyền để sửa đổi hoặc các bên thứ 3 sửa đổi phần mềm hay không, và bất kỳ yêu cầu tài liệu phần mềm máy tính đặc biệt nào.Hãy xác định, đối với từng dự án, liệu nó có phải bị hạn chế ch ỉ có s ự truy c ập c ủa DoD ho ặc chínhphủ nói chung như một dự án OGOTS hay không. Mặc định, các dự án nên tr ở thành COTS OSS(COTS PMNM) thay vì OGOTS. Trong một số trường hợp (nh ư, vì tính bí m ật ho ặc ki ểm soát xu ấtkhẩu) một dự án phải bị hạn chế đối với sự truy cập mà DoD hoặc chính phủ Mỹ qui định. Các d ựán GOTS thể hiện một rủi ro cao hơn so với các dự án COTS, vì theo đ ịnh nghĩa s ẽ có ít h ơn nh ữngngười đóng góp tiềm năng (giảm sự cạnh tranh và gia tăng chi phí một cách tiềm tàng), và các nhàthầu (khác so với những người nắm giữ bản quyền của chúng) sẽ không được khích lệ đối với vi ệcsử dụng các dự án GOTS vì chúng không thể sử dụng lại những thành phần hoặc tri thức về chúngtheo các cách thức khác có thể sống sót được một cách thương mại. Trong nhiều trường h ợp có kh ảnăng chia dự án thành 2 dự án, một là PMNM (như một “khung công việc”) và một là OGOTS (nh ưmột “trình cài cắm” vào khung công việc). Phương pháp này đã được sử d ụng thành công trong lĩnhvực ảnh và bản đồ khi mà Văn phòng Trinh sát Quốc gia đã đỡ đầu cho sự phát triển của khungcông việc Hình ảnh và Bản đồ Nguồn Mở OSSIM (Open Source Imagery and Mapping). KhungVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 15/77
  • 16. 2011 - Các bài học học được về công nghệ mởcông việc này được các lập trình viên khu vực tư nhân phân tán và duy trì một cách r ộng rãi, trongkhi các trình cài cắm bí mật được phát triển trong các mạng an ninh của DoD và đ ược h ạn ch ế đ ốivới các môi trường đó.2.1.3 Bước 3: Chọn và áp dụng một giấy phép chungMỗi dự án phải có một giấy phép rõ ràng và đơn giản xúc tác cho s ự cộng tác h ợp pháp. M ột gi ấyphép đưa ra các quyền và trách nhiệm của các lập trình viên và những người sử dụng phần mềm.Nếu dự án là một dự án PMNM, phải chắc chắn chọn một giấy phép đã có từ trước và nổi ti ếng,một giấy phép đã được xác thực một cách rộng rãi như là PMNM. Nó nên là t ương thích v ới GPL,vì GPL là giấy phép PMNM phổ biến nhất. Nếu phần m ềm đã có tr ước đó r ồi, thì th ường là khônngoan để đưa vào giấy phép trước đó của nó như một trong các lựa chọn. Xem Ph ụ l ục D đ ể cóthêm thông tin về cách chọn một giấy phép PMNM.2.1.4 Bước 4: Thiết lập sự điều hànhCác dự án sử dụng OTD cần phải được điều hành. Quá trình điều hành đối với mỗi dự án c ần ph ảikhuyến khích sự phát triển cộng tác, nhưng nó cũng phải cho phép từ chối các đóng góp ở nh ữngnơi được đảm bảo. Quá trình điều hành OTD phải xúc tác cho nhiều tổ chức làm vi ệc v ới nhau đ ểcải thiện từng thành phần đang trải qua sự phát triển được chia sẻ (bao gồm các ph ần m ềm, cáckiểm thử, và tài liệu của nó), thay vì phát triển lại các thành phần độc lập riêng rẽ với chức năngtương tự. Trước khi thảo luận về các mô hình điều hành khác nhau, đi ều quan tr ọng đ ể l ưu ý là tínhcó thể rẽ nhánh là cần thiết, như được mô tả tiếp sau.2.1.4.1 Tính có thể rẽ nhánhMột rẽ nhánh là một dự án cạnh tranh được thiết lập có sử dụng một bản sao của một ph ần m ềmcủa dự án đang tồn tại.Là cần thiết sống còn rằng một dự án OTD có thể rẽ nhánh được. Đó là, nó phải có khả năng tạo rađược một dự án cạnh tranh có thể sống được có sử dụng một bản sao của mã nguồn phần mềm củadự án đang tồn tại. Việc tạo ra một rẽ nhánh là tương tự một lời gọi đối với một s ự “ bỏ phiếu bất tínnhiệm” trong quốc hội. Người tạo ra rẽ nhánh về cơ bản yêu cầu các lập trình viên và những ngườisử dụng dừng hỗ trợ dự án ban đầu, và thay vào đó hỗ trợ dự án mới được rẽ nhánh (việc hỗ trợ cả 2dự án thường là phi thực tế qua thời gian).Các rẽ nhánh cũng có thể xảy ra vì cộng đồng đang tồn tại không lên k ế ho ạch đ ưa vào m ột ph ầntập hợp các tính năng của cộng đồng được cho là quan trọng, các lý do có thể là: hỗ trợ cho một h ệđiều hành hoặc phần mềm trung gian khác hoặc đưa vào một ngôn ngữ lập trình mới. Bất kể là lý donào, mỗi nỗ lực nên được thực hiện để giữ cho các dự án rẽ nhánh b ằng cách nào đó đ ược đi ều ph ốimột cách tốt nhất có thể.Tính có thể rẽ nhánh được là một phần cần thiết của sự điều hành OTD. Ngay khi m ột d ự án r ẽnhánh, thì lãnh đạo dự án sẽ đấu tranh để có trách nhiệm đối với những người s ử d ụng và các l ậptrình viên. Điều này là vì nếu các quyết định của lãnh đạo là đ ặc bi ệt xu ất s ắc, thì m ột d ự án r ẽnhánh có thể được bắt đầu theo sự quản lý có trách nhiệm hơn. Tính có th ể r ẽ nhánh đ ược m ột cáchdễ dàng thực sự làm giảm rủi ro của một rẽ nhánh, vì lãnh đ ạo s ẽ b ị ép ph ải nghe theo nh ững ng ườisử dụng và các lập trình viên (vì nếu họ không nghe, thì một rẽ nhánh có th ể s ống đ ược s ẽ n ổi lên).Hơn nữa, tính có thể rẽ nhánh được một cách dễ dàng làm gia tăng s ự h ợp lý c ủa các đóng góp; tínhVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 16/77
  • 17. 2011 - Các bài học học được về công nghệ mởcó thể rẽ nhánh một cách dễ dàng đưa ra sự bảo vệ đáng kể đối với những người đóng góp có thể, vìnếu họ sau này không đồng ý với sự điều hành của dự án, thì họ có thể tạo ra một rẽ nhánh.Nói như vậy, tránh tạo ra các rẽ nhánh ở bất kỳ đâu có thể. Hầu hết những ý định rẽ nhánh đều th ấtbại, vì tình huống phải là đặc biệt tồi tệ đối với nhiều lập trình viên và ng ười sử d ụng đ ể dò tìm đ ốivới rẽ nhánh mới. Ai đó định tạo một rẽ nhánh và không thiết lập được rẽ nhánh đó như một d ự áncó thể sống được thì sẽ thường kết thúc việc duy trì dự án của riêng họ ở chi phí khổng lồ. Côngviệc thông thường trong cả 2 dự án thường để dừng một khoảng thời gian, khi những thảo luận t ậptrung vào việc liệu sự rẽ nhánh có được chứng minh hay không.Để có thêm thông tin về việc rẽ nhánh, xem [Forgel2009] các chương 4 và 8.2.1.4.2 Các mô hình điều hànhCác dự án cần một số quá trình điều hành. Hai tiếp cận chung là: • Người độc tài rộng lượng BD (Benevolent dictator). Trong trường h ợp này, có m ột ng ười chịu trách nhiệm về các quyết định cuối cùng. BD có thể ủy quyền các quyết đ ịnh cho những người khác (trong khi giữ lại một quyền phủ quyết), nhưng cuối cùng, một ng ười duy nhất có trách nhiệm. Điều này đặc biệt phổ biến trong các dự án nhỏ hơn nơi mà một người (thường là người khởi xướng) hiểu được dự án tốt nhất, nhưng thậm chí nó đ ược m ột s ố d ự án PMNM lớn sử dụng (như nhân Linux). • Nhóm ra quyết định. Trong trường hợp này, một nhóm ra quyết định cu ối cùng. Đi ều này có thể thông qua một đa số đơn giản, hoặc thông qua một số cơ chế khác. Một số dự án cho phép các thành viên của nhóm cũng đưa ra một phủ quyết. Thường thì nhóm này không phải là tập hợp của tất cả những người đóng góp, mà là một s ố tập h ợp con, và nhóm này ph ải đồng ý đối với việc đưa thêm vào một thành viên mới. Một quá trình chung đ ể ti ến hành là từ Quỹ Phần mềm Apache. Trong hệ thống này thì một “+1” có nghĩa là chấp nhận, một “-1” có nghĩa là phản đối, và mặc định một đề xuất có thể chỉ thông qua được nếu nó nhận được tổng số ít nhất +3 mà không có phủ quyết nào. Trong một s ố tr ường h ợp Apache cho phép “sự đồng thuận lười biếng” (còn gọi là “im lặng tức là đồng ý”, trong đó m ột đ ề xu ất đ ược chấp thuận trừ phi ai đó phủ quyết (phản đối) trong một khoảng thời gian. Trong bất kỳ quá trình nào như vậy sẽ có một sự rủi ro rằng các phủ quyết s ẽ bị l ạm d ụng quá m ức; tính t ới điều này, Apache yêu cầu tất cả các phủ quyết đưa ra một sự chứng minh n ếu không thì chúng là không hợp lệ [Apache2010]. Nhiều chuyên gia viện lý rằng việc biểu quyết nên là một phương sách cuối cùng (như [Collins2007] và [Fogel2009], và rằng bạn nên cố gắng có được một sự đồng thuận sơ bộ mà không có một phiếu chính thức nào ở bất kỳ đâu có thể.Một vấn đề chính là số lượng người thực sự hiểu được các chi ti ết k ỹ thu ật c ủa d ự án. N ếu m ộtngười hiểu rõ nó tốt hơn những người khác (điều thường đúng ở lúc b ắt đ ầu c ủa d ự án), thì mô hìnhBD nên được khuyến cáo. Nếu nhiều người hiểu dự án tốt như nhau, mà th ường là tr ường h ợp đ ốivới các dự án lớn, thì quá trình ra quyết định của nhóm nên được khuyến cáo.Bất chấp mô hình điều hành, (những) người ra quyết định phải tránh thực hiện một quyết định giữacác lựa chọn thay thế quá sớm. Nếu có một sự không đồng ý, thì có th ể là m ột ti ếp c ận th ỏa hi ệphoặc lựa chọn thay thế mà có thể là tốt hơn so với các lựa ch ọn rõ ngay t ức thì. Vì th ế, nh ững ng ườira quyết định nên cố gắng để các bên thấy được những thỏa hiệp và những lựa chọn thay thế đó. Tuynhiên, nếu một sự thỏa hiệp hợp lý không thể tìm kiếm được và một quy ết đ ịnh ph ải đ ược đ ưa ra,thì (những) người ra quyết định nên đưa ra quyết định sau khi nghe tất c ả các bên. Quy ết đ ịnh đónên được công bố một cách rõ ràng, cùng với sự hợp lý. (Những) người ra quyết định cũng phải cóVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 17/77
  • 18. 2011 - Các bài học học được về công nghệ mởthiện chí thay đổi một quyết định khi thông tin mới, các lựa chọn mới, hoặc một thay đổi theo hoàncảnh quan trọng được đưa ra.Dự án nên được quản lý và cấu trúc để luôn tiến hóa và có cơ hội. Việc g ắn vào các tiêu chu ẩn vàgiao diện mở sẽ đưa ra được tính mềm dẻo đối với chương trình để nhanh chóng thích nghi các gi ảipháp mới khi chúng xuất hiện.Như được lưu ý trong phần 2.1.4.1, một điều chủ chốt đối với bất kỳ tiếp cận điều hành nào là việcdự án phải có khả năng rẽ nhánh. Bất kỳ mô hình điều hành nào cuối cùng cũng có th ể th ất b ại n ếunhững người ra quyết định không có nhu cầu trả lời cho những người khác. Nếu d ự án là có th ể r ẽnhánh được, thì rồi lãnh đạo (bất chấp mô hình điều hành) cuối cùng cũng phải tôn trọng những nhucầu của người sử dụng và các lập trình viên.Nhiều thông tin hơn có thể thấy trong [Fogel2009] chương 4 và [Bacon2010] chương 8.2.1.5 Bước 5: Thiết lập sự cộng tácViệc thiết lập sự cộng tác không y hệt như việc tạo ra một chiến lược truy ền thông m ột chi ều. C ộngtác liên quan tới sự trao đổi các ý tưởng một cách dễ dàng giữa nhiều đối tượng (bao g ồm gi ới côngnghiệp, giới hàn lâm và các văn phòng và phòng thí nghiệm của các cơ quan chính phủ khác) để sảnxuất ra một kết quả tốt hơn mà bất kỳ một trong số các đối tượng trên có th ể đ ạt đ ược m ột cáchriêng rẽ. Phần 2.2 thảo luận xa hơn cách để thiết lập hạ tầng kỹ thuật cần thiết để xúc tác cho sựcộng tác; phần 2.3 thảo luận khía cạnh xã hội của sự giao tiếp.Khi mở ra một dự án nguồn đóng có từ trước, sẽ là nhạy cảm về thái đ ộ đ ối v ới s ự thay đ ổi. Hãychắc chắn rằng tất cả các lập trình viên hiện đang tồn tại hiểu được r ằng m ột s ự thay đ ổi l ớn đangtới. Hãy giải thích, hãy nói cho họ rằng sự bất tiện ban đầu là hoàn toàn bình thường, và cam đoanvới họ rằng mọi việc sẽ là tốt hơn. Hãy tính tới những nh ầm l ẫn trong nh ững th ảo lu ận riêng gi ữacác lập trình viên lâu năm, và khuyến khích sự chuyển đổi của họ sang các nhóm thảo luận cộngđồng như các danh sách thư [Fogel2009].Vì một số người sẽ vật lộn với tính mở của một dự án OTD, điều quan trọng ph ải nh ấn m ạnh t ớinhu cầu về tính mở. Hãy đưa ra chỉ dẫn như những chỉ dẫn quản trị hiện hành và b ắt bu ộc v ề tínhminh bạch, và trong bản ghi nhớ năm 2009 của DoD về PMNM bắt buộc rằng phần mềm phải đượcđối xử như các dữ liệu và được chia sẻ một cách phù hợp. Trích từ bản ghi nhớ năm 2009: f. Mã nguồn của phần mềm và các tài liệu thiết kế có liên quan là “các dữ liệu” như theo Chỉ thị của DoD số 8320.02 (reference (h)), và vì thế sẽ được chia sẻ khắp DoD m ột cách r ộng rãi nhất có thể để hỗ trợ cho các nhu cầu nhiệm vụ.Có những cuộc thảo luận phải được giữ đóng đối với công chúng, như lựa chọn nguồn các công tyvà các dữ liệu sở hữu độc quyền của các công ty. Nhưng mỗi dự định nên được thực hiện để mở raquá trình phát triển phần mềm càng nhiều càng tốt. Để đơn giản hóa sự điều hành, phương phápđược ưu tiên cũng nên đòi hỏi các nhà thầu và các nhà tích h ợp ph ần m ềm t ổ ch ức các d ự án c ủa h ọsao cho chúng sẽ tiếp tục là minh bạch và mở cho chính phủ cho sự kiểm tra được từ xa.2.1.6 Bước 6: Tạo ra đường lối kỹ thuật của dự ánĐối với từng dự án, hãy xác định các vấn đề kỹ thuật chủ chốt, như những thành phần chủ chốt nàosẽ được sử dụng lại, những thành phần nào mà hệ thống phải tương tác v ới chúng, cách mà nó s ẽđược triển khai (như ngôn ngữ triển khai để sử dụng là gì), trên những nền tảng nào nó phải làmVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 18/77
  • 19. 2011 - Các bài học học được về công nghệ mởviệc được, và các chỉ dẫn cơ bản cho các lập trình viên. M ỗi d ự án nên nh ấn m ạnh t ới tính có th ểmodule hóa được. Một hệ thống theo module là một hệ thống được xây d ựng t ừ các d ự án t ương tácnhỏ hơn mà chúng có thể được phát triển song song và được thay thế một các đ ộc l ập riêng r ẽ màkhông ảnh hưởng tới các thành phần khác.Tính có thể module hóa được là mấu chốt và làm đơn giản hóa việc s ử d ụng l ại sở h ữu trí tu ệ (IP)của công nghệ và phần mềm, làm giảm nhẹ và tách bạch các vấn đề bí mật và kiểm soát xu ất kh ẩu,làm đơn giản hóa sự quản lý, tăng tốc độ cho sự tri ển khai, làm gi ảm chi phí duy trì, và làm tăngtính lanh lẹ. Một tham chiếu quân sự về tính có thể module hóa có th ể th ấy ở đây:http://www.acq.osd.mil/osjtf/docsmemo.html. Các bằng sáng chế về thiết kế và các bằng sáng chếvề kiến trúc nổi tiếng có thể được sử dụng để chia các vấn đề thành các thành ph ần nh ỏ h ơn[Martin2000].Phần 2.4 thảo luận xa hơn về quản lý kỹ thuật và các tiêu chí kỹ thuật.2.1.7 Bước 7: Công bốKhi một dự án được thành lập và được trình bày (dù chưa tuyệt vời), hoặc một s ự kiện đáng k ể nh ưtung ra một cách chính thức xảy ra, hãy nói cho những người khác xem ai có thể sẽ muốn biết.Nếu bạn biết các danh sách thư nơi mà một tuyên bố về dự án của bạn có thể là chủ đề quan tâm, thìhãy đưa lên đó, nhưng hãy cẩn thận để làm một bài viết chính xác cho m ỗi di ễn đàn, và đ ể h ướngmọi người vào các diễn đàn riêng của dự án của bạn cho những thảo luận sau đó. Nếu có các dự áncó liên quan (như những dự án có thể sử dụng nó hoặc va chạm với nó), thì phải chắc chắn cung cấpcho họ thông tin, và mời họ đưa lên các đường liên kết web t ới website c ủa d ự án c ủa b ạn. Nhi ềungười phát triển các trang web với các danh sách hoặc những rà soát lại của các dạng phần mềmnhư vậy; hãy cung cấp thông tin cho họ sao cho họ có thể c ải thiện đ ược các trang web c ủa h ọ. Hãyđưa lên một cập nhật trên Intellipedia và DoD Techipedia (Điều này là đặc biệt quan trọng cho cácdự án OGOTS, vì có thể là khó để tìm thấy chúng nếu chúng không được bi ết công khai). N ếu đâylà một dự án PMNM công khai, thì hãy đưa ra những công bố như vậy lên http://freshmeat.net/.2.1.8 Tiếp tục rà soát lại các bước từ 1-7Các bước 1-6 nên là sự khởi đầu của một quá trình liên tục n ơi mà các d ự án luôn đ ược luân chuy ểnthông qua tìm kiếm các thành phần mới, phát triển cộng đồng, làm chín muồi các công nghệ và tìmkiếm để mở rộng phạm vi về kích thước, sự nâng cao và sự chín mu ồi c ủa c ộng đ ồng. Qua th ời giancộng đồng sẽ phát triển, vì thế việc đưa vào những người và ý tưởng mới và dẫn dắt tới một sự giatăng trong khả năng và sự cạnh tranh cho các hợp đồng của chính phủ.2.2 Hạ tầng kỹ thuật cho sự cộng tácVì sự cộng tác giữa những người tham gia phân tán một cách r ộng rãi là chìa khóa cho OTD, nêncác dự án phải thiết lập được một site của dự án với hạ tầng k ỹ thu ật c ần thi ết cho s ự c ộng tác. Sitecủa dự án phải xúc tác cho sự phát triển phần mềm, các bộ kiểm thử, và tài liệu (bao gồm cả ngườisử dụng, cài đặt, quản trị, và tài liệu thiết kế) được chia sẻ, dù các chi tiết về cách mà những thứ nàyxảy ra thường khác nhau giữa các dự án. Các chỉ dẫn hữu ích cho việc thiết lập hạ tầng kỹ thuật cóthể thấy trong [Fogel2009] chương 3; sau đây là một ít những điểm mấu chốt. Trong ngôn ngữ hợpđồng của DoD thì hạ tầng kỹ thuật này là tập hợp của “các kho d ữ li ệu” (xem DFARS 227.7108),nhưng sự cần thiết cho việc cộng tác có nghĩa là những kho này ph ải tri ển khai các yêu c ầu b ổ sungVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 19/77
  • 20. 2011 - Các bài học học được về công nghệ mởkhông phải luôn được các hợp đồng bắt buộc.Phải có khả năng cho tất cả những người đóng góp và những ng ười s ử d ụng ti ềm năng s ử d ụngđược các công cụ một cách dễ dàng. Ví dụ, nếu những hạn chế về an ninh làm quá khó cho m ọingười để tham gia, thì họ sẽ không tham gia. Các dự án nên ưu tiên s ử d ụng các công c ụ c ộng tácđược sử dụng một cách rộng rãi của PMNM mà chúng làm vi ệc tốt đ ược v ới b ất kỳ trình duy ệt webnào tuân thủ các chuẩn. Các công cụ không thông dụng tạo ra một rào cản không cần thiết để thamgia vào, vì chúng đòi hỏi những người sử dụng phải học cách sử dụng các công cụ mới thay vì vi ệcđóng góp một cách đơn giản. (Thậm chí nếu những người s ử dụng đã h ọc đ ược cách s ử d ụng m ộtcông cụ, thì những người sử dụng sẽ có thiện chí nhiều hơn nếu công cụ được sử dụng một cáchrộng rãi vì thời gian học của họ được giảm dần). Các công cụ PMNM nên đ ược ưu tiên m ột cáchmạnh mẽ; chúng có thể được thiết lập cấu hình cho những nhu cầu đặc biệt, có xu hướng sẽ làkhông đắt giá để triển khai, và có xu hướng sẽ đặc biệt tốt cho s ự c ộng tác d ạng OTD vì chúngthường được sử dụng cho mục đích đó. Tối đa hóa sự truy cập thông qua các trình duy ệt web tuânthủ các tiêu chuẩn sẽ là gia tăng khả năng cho những người khác để tương tác v ới s ản ph ẩm, nh ư,họ có thể tương tác từ chiến trường.Các nhà thầu phải mong đợi rằng hạ tầng kỹ thuật này có nghĩa rằng chính phủ và các nhà th ầukhác sẽ luôn có sự truy cập ngay lập tức tới sự tiến bộ. Sự minh bạch này là mặc định từ thiết kế.2.2.1 Các chức năng mấu chốtSite trung tâm của dự án phải hỗ trợ sự cộng tác đối với những c ải tiến đang di ễn ra và nên cungcấp các chức năng sau: • Cửa chính (website). Site trung tâm của dự án phải đưa ra được điểm khởi đầu duy nhất cho những ai có quan tâm về dự án, xúc tác mọi người học về dự án và tìm th ấy tất cả các thông tin có liên quan (đặc biệt, cách để có được nó và/hoặc trở thành một phần của cộng đồng phát triển nó). Thường là một website với một URL cố định đơn giản. • Theo dõi lỗi và tính năng. Site trung tâm của dự án phải đưa ra một cơ chế cho những người sủ dụng để đưa lên các báo cáo lỗi và các yêu cầu về tính năng, và đối với các lập trình viên để xác định cách (hoặc nếu có) để giải quyết chúng. Điều này thường đ ược tri ển khai thông qua các công cụ đặc thù như Bugzilla, Trac, hoặc Redmine, nhưng các công cụ khác (nh ư wikis) cũng có thể được sử dụng. Có thể cần phải có một qui trình đặc biệt cho việc báo cáo những chỗ bị tổn thương về an ninh để ngăn chặn sự để lộ ra chúng trước khi việc sửa chúng là sẵn sàng. • Quản lý Cấu hình Phần mềm (SCM). Site trung tâm của dự án phải đưa ra một cơ chế cho việc theo dõi những thay đổi, bao gồm ít nhất phần mềm và thường cả các b ộ kiểm th ử và một số tài liệu. Nó nên ít nhất là đưa ra một phương pháp cho vi ệc xem xét và theo dõi “nhánh phát triển chính” và mỗi phiên bản chính. SCM phải làm cho có khả năng đ ể th ấy được ai đã tiến hành với từng thay đổi, khi nào, và sự thay đổi đó là gì. Không sử dụng CVS trong các dự án mới; CVS từng là phổ biến trong quá khứ nhưng đã được thay th ế b ằng các công cụ tốt hơn. Có 2 dạng hệ thống SCM chính, SCM tập trung (nh ư Subversion hay SVN) và SCM phân tán (như git và mercurial). Như được th ảo luận bên d ưới, trong m ột môi trường quân sự thì các hệ thống SCM phân tán (như git) có những ưu điểm đáng kể và nên là SCM được ưu tiên cho các dự án OTD. • Tương tác cộng đồng (danh sách thư, wiki, và/hoặc IRC) . Site trung tâm của dự án phải đưaVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 20/77
  • 21. 2011 - Các bài học học được về công nghệ mở ra một cơ chế cho những người sử dụng và các lập trình viên để thảo luận các vấn đề. Sự tương tác cộng đồng thường được triển khai thông qua các danh sách thư (như Mailman), wikis, hoặc các hệ thống chat như Internet Relay Chat (IRC). Nhiều dự án s ử d ụng các danh sách thư cho các thảo luận để sử dụng sau này, và trao cho mọi ng ười th ời gian đ ể t ạo ra các câu trả lời cẩn trọng. Trong ngữ cảnh quân sự thì các danh sách thư và wikis có xu hướng s ẽ là dễ dàng sử dụng hơn, vì cả 2 chúng đều đã được triển khai một cách rộng rãi rồi trong các máy tính quân sự. Nếu sử dụng các hệ thống chat, thì hãy chắc chắn phải đạt được các thảo luận theo cách là những người tham gia sau này có thể tìm thấy chúng, nếu không các th ảo luận quan trọng sẽ bị mất. Hơn nữa, hãy chắc chắn rằng hệ thống chat hỗ trợ cho bất kỳ yêu cầu an ninh cần thiết nào (như xác thực và bảo mật). • Tải về các phiên bản. Site trung tâm của dự án phải đưa ra được một cơ chế cho việc tải về các phiên bản chính; nếu chúng là lớn, thì việc có các site soi gương (mirroring) có thể là cần thiết.Wikis (như MediaWiki, MoinMoin, PmWiki, và PhpWiki) là các chương trình mềm d ẻo và có th ểđược sử dụng để làm thỏa mãn một vài trong số các chức năng này.2.2.2 Truy cập, công khai, bí mật và kiểm soát xuất khẩuỞ những nơi có thể, hãy xác định các thành phần nào có thể được đưa ra cho công chúng như làPMNM ngay từ trước, và thiết lập dự án bên ngoài trong công chúng ngay từ đầu. Điều này s ẽ h ạnchế nhiều vấn đề, khi điều này làm cho dễ dàng đối với những người khác đ ể tìm ki ếm và đóng gópcho dự án, và làm gia tăng mạnh số lượng những người đóng góp tiềm năng. Đi ều này cũng xúc táccho việc sử dụng các dịch vụ hosting thương mại sẵn có (xem phần 2.2.3). Không có yêu cầu pháplý nào chờ cho tới khi dự án là “hoàn tất về tính năng” trước khi phiên bản này xảy ra, và nếu điềuđó cũng sẽ là công khai nốt, thì càng sớm đưa nó ra công khai bao nhiêu thì càng tốt bấy nhiêu.Một số thành phần là bí mật, và vì thế sự phát triển của chúng chỉ có thể diễn ra trong các h ệ th ốngđược ủy quyền cho việc xử lý bí mật. Tương tự, một số thành phần s ẽ là d ưới sự ki ểm soát xu ấtkhẩu theo ITAR hoặc EAR. Ở những nơi có thể, hãy chia các thành phần dựa trên tính nhạy cảmcủa chúng để hạn chế những gì là bí mật và kiểm soát xuất khẩu phải được bảo vệ. Trong nhữngtrường hợp này, việc thiết lập một dự án OGOTS cho phép sự cộng tác gi ữa nh ững ng ười có th ẩmquyền được truy cập tới dự án. Những dự án như vậy phải làm việc một cách đặc biệt khó đ ể đ ảmbảo rằng những người sử dụng và những người đóng góp tiềm năng biết về sự hiện diện của chúng.Trong nhiều trường hợp sự phát triển phần mềm sẽ có được mong đợi sẽ là sẵn sàng cho công chúngnhư là PMNM, nhưng phải thực hiện trước hết sự rà soát về bí mật và/ho ặc kiểm soát xuất khẩu.Điều này có thể là một rào cản đáng kể cho sự cộng tác, nhưng trong nhiều tr ường h ợp nó là b ướccần thiết. Hãy xem xét việc thiết lập một dự án OGOTS nội bộ để “dựng” nh ững thay đ ổi đ ược đ ềxuất này cho tới khi chúng có thể được tung ra như một dự án PMNM. Việc dàn d ựng là đ ặc bi ệtquan trọng nếu nó được xác định rằng một số thay đổi là cần thiết cho sử dụng của chính phủ vàkhông thể được tung ra cho công chúng. Những đề xuất như vậy, lý tưởng mà nói, nên được thiết lậpnhư “những nhánh“ riêng rẽ sao cho thậm chí nếu một số thay đổi được cho là s ẽ không th ể đ ượctung ra, thì những thay đổi khác vẫn còn có thể tung ra được một cách độc lập.Các dự án nên xem xét một cách nghiêm túc việc sử dụng một SCM phân tán (nh ư “git”) n ơi mà cóthể sẽ có các vấn đề về kiểm soát xuất khẩu hoặc các mức độ khác nhau về bí mật. Các h ệ th ốngSCM phân tán làm cho dễ dàng hơn nhiều để tạo ra các nhánh riêng rẽ bên ngoài và sau này cungcấp chúng cho những người khác cho việc trộn nếu sự phê chuẩn được trao.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 21/77
  • 22. 2011 - Các bài học học được về công nghệ mở2.2.3 HostingMỗi dự án phải xác định liệu nó sẽ dựa vào một số dịch vụ hosting cộng tác đang tồn tại để đ ưa rachức năng được thiết lập cấu hình sẵn từ trước, hay liệu nó sẽ thiết lập hệ thống riêng của mình, cóđược các công cụ cần thiết, và tự tổ chức (host) dự án. Bất kể quyết định nào về hosting, thì bạncũng phải có khả năng cạnh tranh và thay đổi xem ai làm việc hỗ trợ hosting. Không được b ị khóatrói vào chỉ một nhà cung cấp duy nhất. Nếu không có khả năng để dễ dàng xuất ra tất c ả mãnguồn, tài liệu và các tư liệu thảo luận từ một dịch vụ hosting và nhập các thông tin đó vào m ột môitrường hosting khác, thì dự án OTD của bạn bị dịch vụ hosting sở hữu độc quyền bắt làm con tinmột cách có hiệu quả (một sự mỉa mai đáng tiếc rằng nó có thể làm xói mòn tính h ợp pháp c ủa b ảnthân dự án). Một tiêu chí chủ chốt cho sự đánh giá dịch vụ hosting là phải xác định sẽ khó khăn nhưthế nào khi sao chép các dữ liệu (nghĩa là, các báo cáo lỗi, mã nguồn, ...) ở đâu đó khác nữa sao chonếu dịch vụ hosting là không phù hợp, thì dự án có thể dễ dàng chuyển đi.Hầu hết các dự án lớn hơn hoặc PMNM được sử dụng rộng rãi (nh ư nhân Linux) thi ết l ập h ạ t ầngcộng tác của riêng họ có sử dụng các công cụ PMNM hiện đang có thay vì sử dụng một d ịch v ụhosting (dù họ có thể sử dụng một dịch vụ hosting như SourceForge để phân phối các phiên bảncuối cùng). Ngó qua lần đầu, thì việc sử dụng một dịch vụ hosting cộng tác đang t ồn t ại có th ể xemgiống như là lựa chọn đơn giản nhất và dễ dàng nhất, nhưng các dịch v ụ hosting không ph ải luôn làcách tốt nhất để đi. Một dịch vụ hosting thường được thiết lập để cung c ấp các d ịch v ụ chung, màchúng có thể không phù hợp được tốt cho một dự án cụ thể. Các dự cán nh ỏ th ường đ ược ph ục v ụtốt bằng việc sử dụng dịch vụ hosting cộng tác đang tồn tại, khi mà chúng không thể minh giải đượccác tài nguyên để cấu hình một cách đặc biệt cho hạ tầng của chúng. Nhưng các dự án cỡ trung bìnhvà lớn thường hưởng lợi từ tính có thể thiết lập được cấu hình gia tăng c ủa h ạ t ầng c ộng tác c ủariêng chúng, đặc biệt nếu đó là PMNM.Lý tưởng mà nói, nếu một dự án sẽ là sẵn sàng công khai như PMNM, thì nó nên đ ược thi ết l ập nh ưmột dự án công khai trước khi thiết kế được tạo ra. Nhưng bất chấp việc khi nào thì d ự án s ẽ đ ượcđưa ra công khai, điều quan trọng phải đánh giá được sự thích hợp của các dịch v ụ hosting th ươngmại có sẵn. Những dịch vụ hosting như vậy bao gồm SourceForge (http://www.sourceforge.net),github (http://www.github.com), gitorious (http://gitorious.org), và Google Code(http://code.google.com/). GSA đã thực hiện các điều khoản dịch vụ và thỏa thuận với SourceForge;để có thêm thông tin, hãy xem: https://apps.gov/cloud/advantage/cloud/sa_details.do?BV_UseBVCookie=Yes&clid=160&catId=66. Wikipedia có một trang so sánh các dịch vụ như vậytại http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities.Nếu dự án sẽ là OGOTS, thì nó phải thiết lập được hạ tầng c ộng tác theo m ột cách th ức cho phépchính phủ và các nhà thầu phụ được phép của chính phủ (ở bất kỳ lớp nào) truy c ập đ ược đ ầy đ ủ t ớinó. Một dịch vụ hosting cộng tác chung là Forge.mil của DISA (http://www.forge.mil/). Forge.milcó thể là hữu dụng cho các dự án OGOTS, nhưng không có yêu cầu phải s ử d ụng Forge.mil. Ph ụthuộc vào các nhu cầu dự án của bạn, có thể có một lựa chọn tốt hoặc tồi. Một ưu điểm củaForge.mil là việc những nhu cầu nhỏ sẽ được thực hiện để bắt đầu sử dụng nó. Nhưng Forge.milcũng có một số khuyết điểm. Nó thường có thể mất thời gian đối với những người tham gia tiềmnăng để có được sự truy cập, đặc biệt nếu họ không làm việc trực ti ếp cho m ột khách hàng c ủaDoD, vì một thẻ CAC hoặc chứng thực ECA được yêu cầu cho sự truy cập (truy cập ph ải do chínhphủ đỡ đầu). Điều này có thể là một vấn đề đặc biệt cho những thành viên của cộng đồng tình báomà họ không được DoD ủy nhiệm. Forge.mil thiếu một số dịch v ụ; đ ặc bi ệt, s ự thi ếu h ỗ tr ợ m ạnhcủa nó đối với git hoặc bất kỳ hệ thống kiểm soát phiên bản phân tán nào khác làm cho nó khôngphù hợp đối với nhiều dự án của chính phủ liên bang. Cuối cùng, như với các dịch vụ hosting cộngVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 22/77
  • 23. 2011 - Các bài học học được về công nghệ mởtác thương mại khác, nó đưa ra các dịch vụ chung có thể không được chỉnh sửa để đáp ứng đượcnhững nhu cầu của một dự án đặc biệt.Nhiều dự án OGOTS có thể xác định rằng, chỉ giống như nhiều dự án PMNM công khai, chúng cóthể được phục vụ tốt hơn bằng việc thiết lập host của riêng chúng. Trong trường h ợp này, có th ểthấy rằng một dịch vụ như “SoftwareForge” của Forge.mil là một cách hữu dụng để phân phối cácphiên bản cuối cùng, thậm chí nếu không sử dụng nó cho sự cộng tác khi phát tri ển (t ương t ự đ ốivới cách mà nhiều dự án PMNM đưa ra các phiên bản thông qua SourceForge, thậm chí nếu chúngkhông sử dụng các dịch vụ cộng tác của mình).Chính phủ không cần phải host các site OTD có sử dụng các mạng hoặc trang thiết b ị c ủa chínhphủ. Chính phủ có thể tạo ra một RFP cho một nhà thầu chạy một site hosting mà site này có th ểđược truyền cho chính phủ hoặc nhà thầu khác. Các site cộng đồng cũng có thể được các nghiệpđoàn nghiên cứu và phát triển được chính phủ liên bang cấp tiền (FFRDC) đ ể duy trì. M ấu ch ốt làđối với chính phủ phải thiết lập sự mong đợi về tính minh bạch và sự cộng tác xung quanh côngnghệ mà những người đóng thuế cấp tiền.2.3 Giao tiếp truyền thôngGiao tiếp truyền thông hiệu quả là chìa khóa cho sự thành công với bất kỳ d ự án hay ch ương trìnhnào. Những người cầm đầu cần giao tiếp truyền thông tốt và các kỹ năng có đ ộng c ơ đ ể đ ảm b ảorằng những lập trình viên và những người sử dụng nhận được thông tin mà họ cần. Họ cũng cần khảnăng nhanh chóng đánh giá các cơ hội và phản hồi từ các lập trình viên và người s ử d ụng đ ầu cu ối.Cuối cùng, họ cần phải xúc tác cho tất cả tham gia, bao gồm cả các lập trình viên và nh ững ng ườisử dụng, để cộng tác.Điều này là đặc biệt hiển nhiên trong các dự án PMNM thành công n ơi mà nh ững ng ười s ử d ụng vàhàng loạt các mức độ những người lập trình thường xuyên giao tiếp thông qua các danh sách th ư,các phòng chat, và các hệ thống theo dõi lỗi. Hãy xác định các dự án PMNM thành công và xem xétviệc áp dụng các thực tiễn của chúng. Nhiều thông tin hơn có thể thấy trong [Fogel2009] chương 6và 8, và trong [Bacon2010] chương 3.2.3.1 Hãy là người tham giaNói chung, sự cộng tác nên được khuyến khích, và số lượng những người tham gia tích c ực nên làtối đa.Hãy tích hợp những người sử dụng và các lập trình viên ngay từ đầu, đừng phát triển trong s ự cô lậpvà chỉ có sự tham gia của những người sử dụng vào lúc cuối cùng. Các công nghệ mở thành công sẽcùng tiến hóa giữa những người sử dụng và các lập trình viên của chúng, với các bình luận và ý kiếnphản hồi được tính tới trong mỗi giai đoạn của sự phát triển. Một người quản lý kỹ thuật OTD nêntiến hành những nỗ lực đặc biệt để tuyển mộ những người sử dụng đầu cuối vào site trung tâm c ủadự án như những thành viên của cộng đồng dự án - đặc biệt những người sử dụng đ ầu cu ối có k ỹthuật mà họ có thể đưa ra được ý kiến phản hồi có tính xây dựng về cách mà dự án giúp hoặc xungđột với các tiến trình công việc đang tồn tại. Trong một số trường hợp, những người sử dụng đầucuối có hiểu biết kỹ thuật sẽ hoàn tất tiến hành những đóng góp kỹ thuật phạm vi nhỏ (hoặc lớn)cho dự án, từ việc theo dõi lỗi tới phát triển các module. Sự đầu tư về thời gian và suy nghĩ c ủanhững người sử dụng đầu cuối sẽ tạo ra một nhịp cầu cho cộng đồng những người sử dụng tạo điềukiện cho sự chuyển dịch, và làm cho dễ dàng hơn để vượt qua và chỉ định công việc tiếp tục màkhách hàng sẽ ôm lấy. Người quản lý về kỹ thuật nên thường xuyên đấu tranh để xây dựng và duyVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 23/77
  • 24. 2011 - Các bài học học được về công nghệ mởtrì một mối quan hệ làm việc gần gũi giữa các lập trình viên và những người sử dụng đầu cuối.Khuyến khích những người mới tới. Ở những nơi mà những bình lu ận của họ chứa chất đ ầy tìnhcảm, hãy cố gắng xác định vấn đề kỹ thuật hay thủ tục đằng sau ý kiến ph ản h ồi sao cho nó có th ểđược hành động (như biến nó thành một báo cáo lỗi thực sự). Hãy cố gắng trao cho những ngườikhác (đặc biệt là những người mới đến) lợi ích của sự ngờ vực.2.3.2 Tránh các thảo luật riêng tưTrừ phi bị cấm theo luật, hãy làm cho tất cả những thảo luận dẫn tới một quy ết đ ịnh có s ử d ụng cácdiễn đàn như các danh sách thư mà chúng (a) được ghi lại để xem xét sau này và (b) s ẵn sàng chotất cả những người tham gia tiềm năng (như các lập trình viên và những người s ử dụng). Nhiều d ựán có một luật lệ rằng tất cả các quyết định phải được thực hiện trong một danh sách thư, chứ khôngphải là mặt đối mặt, để đảm bảo rằng mỗi người mà muốn thì có thể tham gia vào trong quá trìnhnày, và để đảm bảo rằng các quyết định và nhân tố cơ bản được ghi lại để sử dụng sau này.Đối với các dự án PMNM thì những thảo luận này nên là công khai thực sự. Các dự án OGOTSthường đòi hỏi một số dạng của quá trình đăng nhập trước khi cho phép nh ững ng ười khác xemthông tin của dự án như các thảo luận. Tuy nhiên, một khi ai đó đã được cho phép xem các d ữ li ệucủa dự án, thì họ thường nên có khả năng xem tất cả các thảo luận của dự án. Tương tự, một khi aiđó đã trở thành một phần của dự án, thì họ nên có khả năng thấy được và tham gia đ ược vào trongtất cả các thảo luận của dự án.Nhiều người sáng lập bị giục phải dàn xếp các vấn đề khó thông qua giao ti ếp truy ền thông riêng.Vâng các thảo luận công khai hơn luôn hầu hết đáng ưa chuộng hơn về lâu dài. Nếu các quy ết đ ịnhquan trọng được thực hiện một cách riêng tư, thì sự hỗ trợ của cộng đồng cho dự án s ẽ yếu. Hơnnữa, các cơ hội để nhận được ý kiến phản hồi khác, và để gi ải thích cho nh ững ng ười khác vì saoquyết định đã được thực hiện, sẽ bị mất.Nói một cách nghiêm khắc, đây là tất cả các phần của người tham gia (xem ph ần 2.3.1), nh ưng vi ệccó sai sót trong các thảo luận riêng tư thường là lỗi lầm đặc biệt phổ biến.2.3.3 Sử dụng các cơ chế truyền thông hiệu quảHãy đảm bảo rằng website của dự án được cập nhật phù hợp sao cho nh ững ng ười s ử d ụng và cáclập trình viên tiềm năng có thể nhanh chóng học được những gì họ cần biết. Vì các qui đ ịnh đ ượcthiết lập và các câu hỏi thường được hỏi sẽ được tr ả lời, nên hãy đảm b ảo r ằng nh ững qui đ ịnh vànhững câu trả lời đó được viết ra và được đưa lên ở một chỗ dễ dàng truy cập đ ược sao cho nh ữngngười khác có thể nhanh chóng học được các thông tin đó.Hãy đảm bảo rằng mỗi đề xuất thay đổi đưa vào một giải thích (ngắn gọn) của những gì thay đổi đólàm. Bằng cách đó, mọi người có thể hiểu những gì dự kiến ph ải làm, và n ếu thay đ ổi đó đ ược ch ấpnhận, thì thông tin đó có thể sau đó được cung cấp cho những người sử dụng sao cho h ọ bi ết nh ữnggì được thay đổi và vì sao. Khi một đề xuất (như, một sự đóng góp) bị từ chối, hãy đảm bảo rằng cómột sự giải thích rõ ràng việc vì sao nó đã bị từ chối, sao cho người đóng góp có th ể thay đ ổi nótrong thứ gì đó có thể áp dụng được và/hoặc sao cho những người khác sẽ không phí th ời gian c ủahọ làm lại thứ y hệt.Tối đa hóa việc sử dụng các phương pháp truyền thông mà chúng được ghi lại và có s ẵn cho nh ữngngười khác sau đó (như các danh sách thư). Hãy yêu cầu mọi người tìm kiếm các v ấn đ ề đã đ ượcgiải quyết trước đó bằng việc đưa lên một chủ đề. Nếu họ đưa ra các chủ đề đã được thảo luận trướcVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 24/77
  • 25. 2011 - Các bài học học được về công nghệ mởđó rồi, thì hãy chỉ cho họ tới thảo luận trước đó đó. Bằng cách này, th ời gian c ủa m ọi ng ười s ẽkhông bị phí phạm vì những vấn đề đã cũ và đã được giải quyết trước đó rồi.2.3.4 Thực tế rà soát mã nguồn dễ thấySự rà soát và bình luận dễ thấy về mã nguồn. Sự rà soát điểm ngang hàng này liên quan tới ch ấtlượng cả một cách trực tiếp (thông qua các bình luận) và gián tiếp (bằng việc cảnh báo cho nh ữngngười khác rằng họ phải làm tốt công việc vì những người khác sẽ kiểm tra các đề xuất của h ọ).Như với bất kỳ thảo luận nào khác, rà soát lại mã nguồn nên tránh các thảo luận riêng tư.2.3.5 Sự khiếm nhã là không nênĐừng cho phép hành vi khiếm nhã và lăng mạ sỉ nhục. Ví dụ, khi ai đó đưa lên một bình lu ận k ỹthuật được trộn với một cuộc tấn công quảng cáo cá nhân, hãy giải quy ết tr ước h ết cu ộc t ấn côngquảng cáo cá nhân (làm rõ rằng nó là không được chấp nhận) và sau đó giải quyết vấn đề kỹ thuật.Trong những trường hợp cực đoan những người này có thể cần bị lo ại b ỏ kh ỏi d ự án, nh ưng tronghầu hết các trường hợp, những người nhắc nhở không thường xuyên sẽ dừng sự bất nhã đó.2.3.6 Tính tới những người độc hạiMột vấn đề lãnh đạo phải giải quyết là “những người độc hại”. Những người này không nh ất thi ếtphải là những người bất nhã, mà đơn giản là những người mà ngăn chặn thay vì xúc tác cho s ự ti ếnbộ. Ví dụ, chủ nghĩa cầu toàn có thể là một vấn đề, vì sự cầu toàn có thể là kẻ thù của cái tốt. Ch ấtlượng cao là rất quan trọng, nhưng nếu đấu tranh cho sự cầu toàn làm cho không có s ự ti ến b ộ, thìkhông chấp nhận được. Một số người kích động đối với dự án phải thay đổi theo các hướng cơ bảnkhông nằm trong nhiệm vụ; Hãy nhắc nhở những người này về nhiệm vụ của dự án, và gi ữ cho m ọingười tập trung vào nhiệm vụ đó. Một số người thù địch mong đợi để làm cho những người kháccáu giận một cách có chủ ý; hãy bỏ qua hoặc loại bỏ họ khỏi dự án sao cho dự án có th ể ti ếp t ụcđược. Nếu ai đó tiếp tục làm tiêu hao sự chú ý và tập trung, thì lãnh đ ạo nên xác đ ịnh xem li ệungười đó có nên bị loại bỏ dựa vào việc liệu có hay không việc người đó có thể cuối cùng có làm lợiđược cho dự án, và liệu người đó có đang làm tê liệt dự án ngay lúc này hay không. Lãnh đ ạo nênkhuyến khích tính lịch sự, sự tôn trọng, sự tin cậy, và tình người trong số những người tham gia đ ểtối đa hóa tính hiệu quả [Collins2007].2.3.7 Hãy nhận thức được về các vai tròSự phát triển cơ bản có chia sẻ thường liên quan tới những người có các vai trò sau: • Các lập trình viên. Những người này phát triển phần mềm và các tư liệu liên quan (như kiểm thử) như một loạt các thay đổi nhỏ được đề xuất (“các bản vá”), mỗi thứ đủ nhỏ để được những người khác rà soát lại. Họ cũng rà soát lại những thay đổi được đề xuất. • Các lập trình viên/các lãnh đạo được tin cậy. Những người này hành động như là những người rà soát lại cuối cùng của những thay đổi được đề xuất, để xác định những thay đổi nào đưa vào “nhánh phát triển chính” của phần mềm và khi các phiên bản chính thống được thực hiện. Những người này nên được tin cậy để trở thành “những người môi giới trung thực” và không chịu ơn một tổ chức cụ thể nào, và phải được tin cậy s ẽ là hi ểu bi ết đ ủ nhi ều v ề k ỹ thuật để hành động như những người rà soát lại mỗi thay đổi được đề xuất.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 25/77
  • 26. 2011 - Các bài học học được về công nghệ mở • Những người sử dụng. Những người này sử dụng khả năng kỹ thuật kết quả, và có sự lựa chọn để đưa lên các báo cáo lỗi hoặc các yêu cầu về tính năng. Một số có thể xác định rằng họ muốn thay đổi phần mềm, trở thành các lập trình viên. • Những nhà phân phối. Những người này giúp những người sử dụng tri ển khai thành ph ần này với các thành phần khác. Họ có thể gói lại bình luận, thường với các bình luận khác, và có thể đưa ra những dịch vụ bổ sung (như huấn luyện, cài đặt và hỗ trợ).2.4 Quản lý kỹ thuật/Các tiêu chí kỹ thuậtLãnh đạo kỹ thuật nên làm việc để đảm bảo rằng các kết quả của dự án có chất lượng cao.2.4.1 Các mục tiêuLãnh đạo kỹ thuật nên đấu tranh cho những điều sau trong các thành ph ần đang đ ược phát tri ểntrong một dự án OTD: 1. Tính mềm dẻo. Một thành phần có thể được sử dụng trong một loạt các cách thức có xu hướng sẽ có nhiều hơn những người sử dụng tiềm năng, một số trong số họ có thể giúp cho dự án (như, thông qua các báo cáo lỗi và thời gian phát triển). 2. Tính khả chuyển. Một thành phần có thể được sử dụng trên nhiều hơn các nền tảng có xu hướng sẽ có nhiều người sử dụng tiềm năng hơn. 3. Tính có khả năng module hóa. Một thành phần là một module (như, với các thành phần con được xác định một cách rõ ràng và có thể hỗ trợ cho một kiến trúc “cài c ắm”) là m ềm d ẻo hơn, cũng như dễ dàng hơn để rà soát làm đúng lại. 4. Sử dụng các tiêu chuẩn mở. Ở những nơi có thể, tránh phụ thuộc vào các giao diện mà bị một nhà cung cấp duy nhất kiểm soát. 5. Sử dụng lại và cộng tác với các dự án OTD hiện đang tồn tại . Một dự án nên tập trung vào việc xây dựng phần mềm mới, không triển khai lại các dự án OTD đã và đang tồn tại. Điều này được thảo luận xa hơn bên dưới. 6. Tránh những phụ thuộc không phải là OTD . Phụ thuộc chỉ vào các nền tảng, thư viện, và các công cụ phát triển OTD được sử dụng một cách rộng rãi. N ếu m ột thành ph ần ph ụ thu ộc vào một thành phần không phải là OTD, và thành phần đó sau này cần ph ải đ ược thay đ ổi, thì có thể là khó khăn để có được sự hỗ trợ đối với các thư viện và các công cụ phát triển không bình thường. Là tốt nếu một thành phần có thể được sử dụng trong một nền tảng không phải là OTD (cải thiện tính khả chuyển của nó), miễn là nó không phụ thuộc vào n ền tảng đó. Nếu một thành phần sở hữu độc quyền phải bị phụ thuộc, thì hãy cô l ập nó thông qua các trình cài cắm hoặc một giao diện được một tiêu chuẩn mở xác định. 7. Tính chính xác. Phấn đấu cho tính đơn giản trong mã nguồn, mã nguồn càng đơn giản thì càng dễ đúng. Yêu cầu rằng một bộ kiểm thử hồi qui tự động được đưa vào trong sự phát triển, sao cho khi những thay đổi được thực hiện thì nhiều lỗi sẽ được dò tìm ra ngay lập tức. Ở những nơi mà có các tiếp cận của lựa chọn thay thế, một phân tích đơn giản các lựa chọn thay thế nên được tiến hành, và được thảo luận trong dự án sao cho các v ấn đ ề chính ho ặc các lựa chọn thay thế sẽ không bị bỏ qua.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 26/77
  • 27. 2011 - Các bài học học được về công nghệ mở2.4.2 Sử dụng lại và cộng tác trong các thành phần OTDMột đặc tính phân biệt được của quản lý kỹ thuật OTD (ngoài s ự phát tri ển c ủa c ộng đ ồng) là s ự ápdụng cơ hội chủ nghĩa đối với các công nghệ mở được những người khác phát triển.Các lãnh đạo của các dự án OTD phải làm việc để khuyến khích sử d ụng l ại các thành ph ần OTDhiện đang tồn tại, bao gồm sự cộng tác trong phát triển của họ khi cần thi ết. Đôi khi khó khăn đ ể ápdụng các thành phần được phát triển từ “những người bên ngoài”. Tuy nhiên, những người lãnh đ ạonên tăng cường áp dụng các dự án OTD được nuôi dưỡng tốt nh ất, bao g ồm c ả s ự s ửa đ ổi có hi ệuquả các dự án đã tồn tại trước đó. Thời gian của dự án nên được tập trung vào vi ệc phát tri ển cácphần mềm mới thay vì việc phát triển các phần mềm mà đã tồn tại rồi.Khi xem xét sử dụng các thành phần OTD đang tồn tại, hãy đánh giá chúng trước. [Wheeler2010e]đưa ra một tiếp cận cho việc đánh giá các dự án OTD, bao gồm cả cách để có thông tin cho nh ữngđánh giá như vậy.2.4.3 Không rẽ nhành PMNM chỉ vì sử dụng của Chính phủMột sai lầm phổ biến mà các công ty và các dự án của chính phủ thực hiện khi b ắt đ ầu áp d ụng cáctiếp cận OTD là bắt đầu bằng việc tạo ra một rẽ nhánh b ằng vi ệc l ấy m ột ảnh ch ụp nhanh c ủa mãnguồn và sửa đổi nó cho những nhu cầu của riêng họ, tách biệt kh ỏi c ộng đ ồng xung quanh mãnguồn đó.Đây là một sai lầm vì các dự án OTD thành công thường là tiến hóa và cải ti ến liên t ục. Vi ệc t ạo ramột rẽ nhánh sẽ cô lập tất cả những người sử dụng của rẽ nhánh đó đối với dự án OTD chính, baogồm cả các cải tiến mà dự án chính làm ra. Việc làm tươi lại các thành phần OTD là m ột cách th ứcrất có hiệu quả của việc tiến hóa nền tảng cơ sở cho dự án. Điều quan trọng là phải giữ l ại được s ựđồng bộ hóa với những phiên bản chính thức mới nhất của các dự án đ ược ch ọn vì tính tin c ậy đ ượccủa hệ thống, sự phù hợp của công nghệ, và có được lợi ích tối đa của một tiếp cận OTD.Trong một số trường hợp, không có nhu cầu sửa đổi bản thân thành phần đó. Giao diện lập trìnhứng dụng (API) của thành phần đó hoặc hệ thống các trình cài cắm có th ể cung c ấp tính m ềm d ẻocần thiết mà hoàn toàn không thay đổi thành phần đó.Nếu một thành phần phải được thay đổi, thì những chỗ sửa và những c ải tiến chủ chốt đối v ới n ềntảng cơ bản nên được phát triển trong sự tư vấn với dự án ban đầu và sau đó được đệ trình trở ngượclại tới dự án gốc ban đầu. Các giao diện và chức năng độc nhất của chính ph ủ nên đ ược tách bi ệtthông qua các cơ chế của các trình cài cắm hoặc với các giao diện lập trình ứng dụng (APIs) ở m ứcđộ cao hơn. Việc nắm lấy tiếp cận này cho phép dự án của chính phủ nâng cấp một cách không đauđớn khi những phiên bản mới được làm ra từ dự án bên ngoài. Hầu hết các thành phần hữu dụngtiếp tục được cải tiến, nên khả năng thực hiện các cập nhật theo chu kỳ ph ải đ ược xây d ựng trongquá trình phát triển và duy trì.Trong một số trường hợp, một dự án phải thực hiện những sửa đổi đáng k ể cho m ột thành ph ầnOTD mà nó sẽ phụ thuộc vào. Trước hết hãy chắc chắn đây chính là vấn đề; đôi khi không ph ải th ế.Nhưng nếu đây đúng là vấn đề, thì hãy thảo lu ận với dự án có thành ph ần mà nh ững thay đ ổi c ầnphải được thực hiện, và tìm kiếm các cách thức để đề xuất những thay đ ổi đó t ừng tí m ột cho d ự ánthượng nguồn (upstream). Điều này sẽ làm gia tăng sự hợp lý khi các thay đổi sẽ được dự án củathành phần đó chấp nhận. Tốt nhất nếu có một hợp đồng khuyến khích những thay đổi đó đ ối v ớicác dự án bên ngoài được chấp nhận ngược trở lại vào trong các dự án đó, để khuyến khích nhà thầulàm việc với các dự án bên ngoài đó.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 27/77
  • 28. 2011 - Các bài học học được về công nghệ mởTrong tất cả các trường hợp, hãy tập trung sự phát triển vào những yêu c ầu mà chúng th ực s ự là đ ộcnhất vô nhị.Lưu ý rằng điều này không là một mâu thuẫn với phần 2.1.4.1, mà đã nhấn mạnh t ới tính có th ể r ẽnhánh được. Điều quan trọng là một dự án là có thể rẽ nhánh đ ược đ ể khuy ến khích các lãnh đ ạo d ựán quản lý dự án một cách phù hợp. Nhưng vì qui trình của việc rẽ nhánh gây trở ngại một cáchtrầm trọng với sử dụng lại, nên tất cả các bên nên cố gắng tránh th ực sự t ạo ra m ột r ẽ nhánh, và nênthay vào đó tìm kiếm một cách thức để làm việc cùng nhau.2.4.2 Các tiêu chuẩn mởHãy sử dụng các tiêu chuẩn mở. Vì các mục đích của tài liệu này, một “tiêu chu ẩn m ở” là m ột đ ặctả ít nhất đáp ứng được định nghĩa của Liên minh châu Âu như được áp d ụng trong Khung T ươnghợp châu Âu: • Tiêu chuẩn được áp dụng và sẽ được một tổ chức phi lợi nhuận duy trì, và s ự phát tri ển hi ện hành của nó diễn ra trên cơ sở của một thủ tục ra quyết định mở s ẵn sàng cho t ất c ả các bên có quan tâm (quyết định đồng thuận hoặc theo số đông...). • Tiêu chuẩn đã được xuất bản và tài liệu đặc tả của tiêu chuẩn là s ẵn sàng ho ặc m ột cách t ự do hoặc với một phí tượng trưng. Tất cả mọi người phải được phép sao chép, phân ph ối và sử dụng nó mà không mất phí hoặc với một phí tượng trưng. • Sở hữu trí tuệ - nghĩa là, các bằng sáng chế có thể là có - đ ối v ới (các ph ần) tiêu chu ẩn và được làm cho sẵn sàng không thể hủy bỏ được trên cơ sở không có chi phí bản quyền. • Không có bất kỳ ràng buộc nào trong việc sử dụng lại tiêu chuẩn đó.Đôi khi những mở rộng là cần thiết, nhưng chúng chỉ nên được sử dụng với sự xem xét khi nó có thểdễ dàng trở thành bị khóa trói một cách không cố ý vào một mở rộng sở hữu độc quyền. Bị khóa tróivào một mở rộng sở hữu độc quyền có thể là một vấn đề, đặc biệt nếu nó ch ỉ đ ược tri ển khai b ằngmột chương trình sở hữu độc quyền (khi mà điều này hạn chế sự cạnh tranh một cách có hi ệu qu ả,làm gia tăng chi phí về lâu dài).Hãy xem xét việc yêu cầu các kiểm thử (như một phần của hợp đ ồng) v ới m ột tri ển khai l ựa ch ọnthay thế của một tiêu chuẩn để làm gia tăng tính hợp lý của việc giữ được bên trong tiêu chuẩn.Ở những nơi thích hợp, hãy tạo hoặc làm việc để mở rộng các tiêu chuẩn mở.Đăng ký các Tiêu chuẩn Công nghệ thông tin của Bộ Quốc phòng DISR (DoD IT StandardsRegistry) là một kho trực tuyến các tiêu chuẩn công nghệ thông tin, và có th ể s ử d ụng đ ược m ột s ố.Nó là có sẵn trên https://disronline.disa.mil/ nhưng truy cập vào cần có một th ẻ CAC. L ưu ý làkhông phải tất cả các tiêu chuẩn được liệt kê trong DISR đều là các tiêu chuẩn mở.2.4.5 Quản lý các đóng gópNhững người lãnh đạo dự án nên rà soát lại những đóng góp hoặc đảm b ảo r ằng chúng đ ược rà soátlại. Quá trình đóng góp nên đảm bảo rằng những người đóng góp đáp ứng được những yêu c ầu k ỹthuật (như, nó biên dịch và đưa ra giá trị) cũng như bất kỳ yêu cầu pháp lý nào (nh ư, nh ững ng ườiđóng góp có một quyền để đề xuất yêu cầu pháp lý). Nếu dự án đòi h ỏi nh ững ch ỉ đ ịnh quy ền, thìhãy chắc chắn những chỉ định đó cũng là có.Những đóng góp lần đầu thường bị từ chối, vì những người đóng góp th ường không nh ận th ức đ ượcVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 28/77
  • 29. 2011 - Các bài học học được về công nghệ mởcác chi tiết về dự án. Ở những nơi thực tế, hãy giải thích chi tiết vì sao một sự đóng góp b ị t ừ ch ối(tập trung vào sự đóng góp và không vào người đóng góp), và giúp người đóng góp hi ểu đ ược cáchtiến hành những thay đổi cần thiết để sản xuất ra một sự đóng góp có thể được chấp nhận.2.5 Đưa ra liên tụcSự phát triển nên là một sự tiến hóa liên tục thông qua những thay đổi nhỏ được theo dõi m ột cáchtương ứng. Bằng cách đó, những người khác có thể rà soát lại một cách có hiệu quả những thay đ ổiđó. Những thay đổi đó nên không ngăn cản một hệ thống khỏi việc xây dựng và quản lý. Trong mộtsố trường hợp, một thay đổi sẽ không có được hiệu ứng người sử dụng nhìn th ấy đ ược, nh ư, nó cóthể là một sự thay đổi về kiến trúc để chuẩn bị cho chức năng trong tương lai. Những xây dựng hàngngày được tuân theo bằng các kiểm thử hồi qui tự động được khuy ến cáo m ột cách cao đ ộ; chúnglàm cho các vấn đề rõ ràng ngay lập tức.Theo nhiều cách phiên bản chính thức (và sự đưa ra) của một sản phẩm OTD không ph ải là m ột s ựkiện vì đối với sự phát triển, kiểm thử, và phản hồi ý kiến liên t ục trong t ất c ả nh ững ng ười thamgia. Hơn nữa, những người sử dụng thường cần phải biết rằng một phiên bản đặc bi ệt là “s ẵn sàngđể sử dụng”, và thường việc kiểm thử đặc biệt được thực hiện mà không th ể th ực hi ện đ ược trongtừng sự rà soát lại (như, kiểm thử các trường) trước một phiên bản. Nh ững phiên b ản chính th ốngnhư vậy là một lần tốt lành cho những nhà thầu lớp trên và chính phủ để đảm bảo rằng: 1. Họ thực sự nhận được mã nguồn cho tất cả phần mềm mà họ có quyền. 2. Mã nguồn và tài liệu có những ghi nhận các quyền chính xác. Nếu chính phủ nh ận đ ược các quyền không hạn chế, thì nó nên nói thế. 3. Phần mềm nên được xây dựng một cách tự động có sử dụng một lệnh ng ắn duy nh ất (nh ư, “make”). 4. Phần mềm nên tuân theo các tiêu chuẩn và các chỉ dẫn cài đặt cho nền tảng của nó. Đối với Unix và Linux, xem [Wheeler2009]. 5. Bộ kiểm thử hồi qui nên được đưa vào.Trong một phân phối chính thức, hãy công bố sự tồn tại hoặc phiên bản mới một cách rộng rãi saocho những người sử dụng tiềm năng có thể biết được về nó. Nếu sự tồn tại của nó có th ể đ ược bi ếtđối với công chúng, hãy đảm bảo rằng công bố đó có thể được thấy bằng các máy tìm kiếm ph ổbiến như Google. Hãy cập nhật (các) trang Intellipedia của dự án nếu đây là OGOTS. N ếu đây làmột dự án của DoD, hãy cung cấp một bản sao mã nguồn của nó và tư liệu có liên quan cho DTICđể giảm thiểu rủi ro mất dữ liệu.Xem [Fogel2009] chương 7 để có thêm thông tin.2.5.1 Quản lý các quyền trí tuệHãy đảm bảo rằng mỗi đóng góp đều có các quyền trí tuệ cần thiết (bao g ồm c ả “các quy ền c ủa d ữliệu”) mà chúng xúc tác cho các lập trình viên và những người s ử d ụng d ự án đ ể ti ếp t ục s ử d ụng,sửa đổi, và phân phối lại chúng một cách phù hợp. Đặc biệt, hãy kiểm tra nh ững ghi nh ận v ề b ảnquyền trong các đóng góp, và tìm kiếm việc chèn thêm vào các ph ụ thu ộc m ới trong các công c ụ vàthành phần sở hữu độc quyền. Những ghi nhận không đúng thường bị sao chép sang t ư li ệu khác, vìthế việc ghi nhận không đúng có thể “lan truyền” sang các dự án khác.Một dự án PMNM phải từ chối bất kỳ sự đóng góp nào không đáp ứng được (các) giấy phép đ ượcVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 29/77
  • 30. 2011 - Các bài học học được về công nghệ mởchọn của dự án PMNM đó. Tương tự, một dự án OGOTS nên từ chối những đóng góp v ới ch ỉ“những quyền hạn chế” như được xác định trong DFARS 252.227-7014(a)(14) vì nh ững đóng gópđó không cung cấp cho chính phủ và các nhà thầu với các quyền đầy đủ để s ử d ụng l ại ph ần m ềmtrong những hoàn cảnh tùy ý của chính phủ.Các dự án OGOTS thường là nên chấp nhận bất kỳ đóng góp nào với nh ững quy ền không h ạn ch ếcủa chính phủ. Một dự án OGOTS có thể chọn chấp nhận những đóng góp với các quyền theo mụcđích của chính phủ GPR (Government Purpose Rights), đặc biệt nếu có một th ời gian h ết h ạn rõràng mà sau đó đóng góp sẽ trở lại các quyền không giới hạn của chính phủ. Những đóng góp nh ưvậy chỉ có thể được tự do sử dụng đối với các mục đích của chính phủ, nhưng vì các d ự án OGOTSchỉ sẵn sàng đối với những người sử dụng trong chính phủ, nên điều này không phải là một s ự thayđổi thực tế. Việc chấp nhận những đóng góp GPR nên được chấp nhận một cách đ ặc bi ệt t ừ chínhphủ, vì việc chấp nhận những đóng góp như vậy sẽ hạn chế được nh ững gì mà chính ph ủ có th ể làmvới các kết quả của dự án. Hợp đồng đặc biệt được sử dụng để tạo ra s ự qu ản lý ph ần m ềm GPR,nhưng trong nhiều trường hợp phần mềm GPR là GPR cho 5 năm sau chữ ký của hợp đồng hoặcchữ ký sửa đổi hợp đồng theo DFARS 252.227-7014(b)(2)(ii); Sau thời gian đó thì đóng góp tr ởthành các quyền không hạn chế của chính phủ. Mỗi đóng góp nên được đánh dấu rõ ràng nh ư làGPR và đưa vào ngày tháng khi đóng góp đó sẽ thay đổi thành các quy ền không h ạn ch ế, sao chonó sẽ là dễ dàng cho chính phủ để xác định khi nào chính phủ sẽ có các quyền không hạn chế thayvì GPR. Các dự án OGOTS mà chấp nhận những đóng góp GPR ph ải đ ảm b ảo r ằng t ất c ả nh ữngngười nhận sẽ nhận thức được và đã đồng ý đối với những hạn ch ế phù h ợp v ới GPR tr ước khi h ọnhận được sự truy cập tới tư liệu GPR.Để có thêm thông tin về các quyền trí tuệ về PMNM, hãy xem [Fogel2009] chương 9 (“Các giấyphép, Bản quyền và Bằng sáng chế”).Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 30/77
  • 31. 2011 - Các bài học học được về công nghệ mởChương 3. Lập trình OTD: Các chiến thuật, công cụ và thủ tụcCơ hội tốt nhất cho một chương trình quân sự để trở thành (và giữ là) mở là khi các qui đ ịnh c ủa“con đường mở” được đặt ra một cách rõ ràng và súc tích sớm cho các nhà thầu và quan tr ọng nh ấtlà cho các cán bộ văn phòng chương trình. Chương này sẽ giải thích cách để thiết lập nh ững quiđịnh này trong một vụ mua sắm. Xem chỉ thị của DoD 5000.02 (Hoạt động của Hệ thống Mua sắmQuốc phòng) về những thông tin cơ bản trong qui trình mua sắm của DoD.3.1 Khởi tạo và/hoặc chuyển sang OTDĐiều sống còn để đưa nền công nghiệp (và các bên tham gia khác có quan tâm) vào sớm nhất cóthể, ví dụ, bằng việc tổ chức các Ngày Công nghiệp, đi cùng với một yêu cầu về qui trình thông tin(RFI) Nếu có thể, cố tạo ra một cổng web mở làm việc với những ý tưởng và giải pháp được đề xuấtcho việc phát triển khả năng mong muốn. Mục tiêu là tập hợp càng nhiều ý tưởng có thể càng tốt đ ểđưa ra quyết định có thông tin tốt nhất cho chính phủ. Những người qu ản lý ch ương trình cũng cóthể tham dự các hội nghị cộng đồng và tổ chức các phiên đưa ra những phiên thảo lu ận với mụcđích thu thập các ý tưởng. Tất cả tư liệu được tạo ra trong các phiên đó nên được xu ất b ản m ột cáchmở cho tất cả các nhà thầu tiềm năng để xem và sử dụng (miễn là t ất c ả các nhà th ầu đ ược thôngbáo, thì nhiều vấn đề pháp lý sẽ biến mất). Nếu được quản lý phù hợp, thì cộng đ ồng t ạo ra lúc banđầu của dự án có thể tăng trưởng và tiến hóa các khả năng công nghệ của hệ thống thông qua sựchuyển dịch và hơn thế. Site cộng tác cuối cùng cũng có thể lớn thành một site chia s ẻ các d ữ li ệukỹ thuật chính thống nơi mà các thiết kế, các đặc tả, các định dạng dữ liệu, các thủ tục kiểm th ử c ủadự án, … có thể được tổ chức.Các phần con sau trình bày chi tiết hơn về qui trình mua s ắm đ ặc bi ệt c ủa chính ph ủ, nh ư là Phântích các lựa chọn thay thế AoA (Analysis of Alternatives), Yêu cầu thông tin RFI (Requests forInformation) từ giới công nghiệp và Yêu cầu đề xuất RFP (Request for Proposal).Các điểm chính phải ghi nhớ: • Rà soát lại các quyền trí tuệ có liên quan tới dự án; đảm b ảo r ằng chúng xúc tác cho s ự phát triển và phiên bản cộng đồng. • Ưu tiên hơn cho các tiếp cận do cộng đồng phát triển (các tiếp cận OGOTS ho ặc PMNM) cho việc phát triển phần mềm mới. • Quyết định khi nào/cách nào để phát triển PMNM, và khi nào và cách nào để chuyển dịch. • Khi nói chuyện với các luật sư, hãy hỏi “làm thế nào tôi có thể đạt được mục tiêu X?”, không bao giờ hỏi “liệu tôi có thể làm X?”. Các luật sư có thể đơn giản tr ả lời “không” cho câu hỏi sau, mà không giúp bạn đạt được các mục đích lớn hơn bằng pháp lý. • Vươn tới các cộng đồng rộng lớn hơn và các diễn đàn trực tuyến, như, Intelink và nhóm MIL-OSS. • Hãy xác định các yêu cầu về an ninh và các qui trình theo yêu cầu, như, Chứng chỉ & Ủy nhiệm, FIPS, và các tiêu chí chung (Common Criteria). • Rà soát lại kiểm soát xuất khẩu (EAR, ITAR) và các nhu cầu cho các d ự án bí m ật. Hãy s ử dụng các công cụ PMNM đang tồn tại để giữ cho dự án được mở.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 31/77
  • 32. 2011 - Các bài học học được về công nghệ mở • Sử dụng/sửa đổi/tạo ra các tiêu chuẩn mở, theo trật tự đó. Hãy kiểm tra tính hợp lệ rằng các tiêu chuẩn được sử dụng là mở; một kiểm thử đơn giản về tính mở là xác định liệu tiêu chuẩn đó có được các phần mềm nguồn mở triển khai hay không.3.1.1 Phân tích các lựa chọn thay thế (AoA)Các phiên bản sớm của AoA có thể thường được phát triển theo một cách thức mở. Ngoài việc đầutư một cách đơn giản một đội nghiên cứu, các nhà quản lý chương trình nên nỗ lực xuất bản cácphát hiện mở trên web (hoặc nếu nhạy cảm thì trên Intelink) và để thu hút một cách tích c ực các ýkiến và các ý tưởng từ bên ngoài từ những người thường không có liên quan với quân s ự ho ặc chínhphủ liên bang, khi thường có sự tinh thông nhiều hơn từ bên ngoài hơn là bên trong.Các tham chiếu chính thức cho AoA có thể thấy ở: https://dap.dau.mil/policy/Pages/overview.aspxhoặc https://acquisition.navy.mil/content/view/full/3486. Một tham chiếu thực tế tốt cho AoA cũngcó thể thấy trong “Phân tích các lựa chọn thay thế (AoA) S ổ tay ch ỉ d ẫn th ực t ế cho các phân tíchcác lựa chọn thay thế” (“Analysis of Alternatives (AoA) Handbook A Practical Guide to Analyses ofAlternatives”) (Tháng 07/2008).AoA nên xác định các tiêu chuẩn hiện đang tồn tại có thể được sử dụng cũng như các lĩnh v ực n ơimà các tiêu chuẩn mới có thể cần được tạo ra. Bất kỳ các tiêu chuẩn mới nào cũng ph ải đ ược xu ấtbản như các tiêu chuẩn mở không được gây trở ngại bởi các quyền trí tu ệ. Sử dụng phù h ợp cácgiao diện lập trình ứng dụng (APIs) cũng nên được rà soát lại và các khuyến cáo được th ực hi ện.Các API phải được chính phủ hoặc một cơ quan tiêu chuẩn độc lập sở hữu và kiểm soát vì chúng lànhững điểm tiềm tàng cho sự khóa trói.PMNM đang tồn tại thường bị bỏ qua khi phát triển AoA. Điều này là ng ược v ới lu ật và chính sách,mà chúng đòi hỏi sự nghiên cứu thị trường các khoản thương mại (bao gồm c ả các PMNM s ẵn cómột cách công khai). Một văn phòng chương trình phải tìm ra các lựa chọn thay thế là PMNM để sửdụng, và nếu phù hợp, thí điểm với các công cụ đó. Các đ ịa đi ểm đ ể ki ểm tra đ ối v ới các công c ụPMNM bao gồm: http://www.github.com, http://www.freshmeat.com, http://www.sourceforge.net,và tìm kiếm một cách đơn giản trên web với cụm từ “open source software” (“ph ần m ềm ngu ồnmở”) cộng với khả năng mà bạn đang cố gắng phát triển.Các câu hỏi ví dụ của AoA:1. Các mục đích, mục tiêu và các yêu cầu của hệ 2. Có các khả năng COTS và GOTS phù hợpthống là gì? hiện đang tồn tại hay không, bao gồm cả PMNM và OGOTS?3. Có các chương trình quân sự khác xây dựng 4. Có các chương trình khác của chính phủ xâyhoặc phát triển các khả năng tương tự không? dựng hoặc phát triển các khả năng tương tự hayBạn có thể kết hợp với chúng (như, để chia sẻ không?công nghệ) được không?5. Có các chương trình của đối tác quốc tế 6. Có các cộng đồng khác hiện đang tồn tại mà(NATO, …) xây dựng hoặc phát triển các khả chương trình của bạn có thể tham gia cùngnăng giống như thế hay không? (IEEE, NIST, ASME, NDIA, …) hay không?7. Nếu chương trình của bạn cần phải xây dựng 8. Các tiêu chuẩn nào nên/có thể được sử dụng?một giải pháp tùy biến (như GOTS) thì bạn cóthể và nên đưa nó ra như PMNM được không?Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 32/77
  • 33. 2011 - Các bài học học được về công nghệ mở3.1.2 Yêu cầu thông tin (RFI)Sau một sự khởi đầu AoA được phát triển, bước tiếp sau là xu ất b ản m ột cách chính th ức m ột yêucầu thông tin (RFI), mà nó là một cơ hội tốt đầu tiên để cam kết một cách chính thức với giới côngnghiệp. Quá trình tạo một RFI được đưa ra trong loạt DoD 5000.RFI nên có một mô tả chi tiết về các khả năng nào chính phủ mong muốn. Một số vấn đề và các câuhỏi chung sẽ được hỏi trong RFI có thể có: 1. Các quyền trí tuệ a) Chính phủ mong muốn các quyền dữ liệu không hạn chế cho tất cả các mã nguồn phần mềm được phát triển bằng tiền của người đóng thuế, sao cho chính phủ có thể đưa ra các phần mềm đó như là các PMNM để triển khai một triết lý duy trì phần mềm theo sự phát triển cộng đồng PMNM (theo DFARS 227.7203-2(b)(1)). b) Chính phủ có thể chỉ dẫn cho nhà thầu đưa mã nguồn ra như là PMNM. Hãy mô t ả cách mà điều này có thể xảy ra và giấy phép PMNM nào có thể là tốt nhất. 2. Các định dạng dữ liệu, các tiêu chuẩn & các giao diện a) Chính phủ sẽ chỉ sử dụng các định dạng dữ liệu, các tiêu chuẩn & các giao diện mà chúng là mở và có khả năng truy cập được một cách mở. b) Những định dạng dữ liệu, những tiêu chuẩn & những giao diện nào s ẽ được đ ề xu ất để sử dụng? Đối với một tiêu chuẩn dữ liệu được đưa ra, liệu có một triển khai PMNM nào của tiêu chuẩn đó hay không? c) Ở những nơi mà các tiêu chuẩn mở không có sẵn, hãy thảo luận về các tiêu chu ẩn s ở hữu độc quyền mà chúng đang tồn tại, cách mà các tiêu chuẩn mở mới có thể được tạo ra, và nhóm nào có thể chi phối chúng (như IETF, W3C, OASIS, …). 3. Các công nghệ OTS a) Theo luật và chính sách của chính phủ, thì COST (bao gồm cả PMNM) là ch ấp nh ận được để sử dụng trong chương trình này. b) Xin hãy xác định các công nghệ có thể được sử dụng: c) Thích nghi: Các công nghệ nào là sẵn sàng để sử dụng mà không được sửa đổi? d) Sửa đổi: Các khả năng hiện có nào có thể được tinh chỉnh và/hoặc sửa đổi? e) Tạo: Các công nghệ nào có thể cần phải được tạo ra? 4. Các thực tiễn của OTD a) Chính phủ muốn cam kết với một khán thính phòng của các lập trình viên và người sử dụng rộng lớn hơn cho khả năng này; xin mô tả cách mà điều này có thể xảy ra. b) Nếu có các phần hoặc tất cả khả năng là kiểm soát xuất khẩu và/hoặc bí mật, hãy gi ải thích cách mà một nhà thầu/nhà tích hợp có thể tạo ra và chi ph ối mã ngu ồn và cam k ết một cách có hiệu quả với một cộng đồng. 5. Các tham chiếu a) Nếu có khả năng thì AoA cũng có thể được xuất bản để giúp cộng đ ồng hi ểu đ ược các giải pháp tiềm năng đã được khai thác rồi và quan trọng hơn là những giải pháp nào đã không được kiểm tra.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 33/77
  • 34. 2011 - Các bài học học được về công nghệ mở b) Một loạt các tham chiếu mở được nhắc trong chỉ dẫn này cũng có thể được đưa vào.RFI nên yêu cầu những ví dụ cụ thể về các tiêu chuẩn mở được xác định và được đ ề xu ất tr ước đóđể sử dụng. Đối với phần mềm được đề xuất mà không tồn tại và sẽ cần ph ải đ ược c ấp v ốn cho nhàthầu thì phải chi tiết cách mà nó sẽ được đưa ra và cách mà nhà th ầu s ẽ phát tri ển m ột c ộng đ ồngxung quanh khả năng của phần mềm đó.3.2 Yêu cầu đề xuất (RFP)Sau sự khởi đầu AoA và RFI sẽ hoàn thành, văn phòng chương trình nên có một ý tưởng tương đ ốivững chắc về những công nghệ nào là sẵn sàng, sự cạnh tranh nào đang tồn tại, và đường hướngcông nghệ nào chương trình có thể mong muốn đi. Một quyết định mấu ch ốt mà chính ph ủ có th ểthực hiện là quyết định liệu sẽ là mở thì có là yêu cầu và thước đo chính cho s ự th ực thi hay không.Nếu sự minh bạch của công nghệ trong mã nguồn phần mềm là một thước đo và tham s ố chính màchính phủ cần để thỏa mãn nhiệm vụ của mình thì nó nên tuyên bố như thế trong RFP.Các phần con sau đây chi tiết hóa các mục đích của RFP giúp đảm bảo tính mở trong một kh ả năngquân sự.3.2.1 Tuyên bố về các mục đích (SOO) & ý địnhMột tuyên bố rõ ràng về ý định và các mục đích của chương trình là cần thiết để thiết lập ng ữ c ảnhcủa những gì là mở sẽ có nghĩa cho một dự án. Như được thảo luận trước đó, là mở có một s ố khíacạnh khác biệt, từ các tiêu chuẩn mở tới PMNM tới phát triển mở. Lãnh đạo của từng chương trìnhsẽ cần phải tự quyết định ở đâu trong sự liên tục này họ có thể đứng và muốn kết thúc dài hạn hơn.SOO nên thực hiện các tuyên bố về OTD, như việc xác định OTD, l ưu ý r ằng đây là “tri ết lý duy trìphần mềm” có dụng ý (DFARS cho phép chỉ định triết lý duy trì phần mềm như là minh ch ứng chocác dạng hoạt động này), và yêu cầu những người chào hàng giải thích cách họ sẽ triển khai OTD.Ví dụ:Chính phủ định sử dụng một triết lý duy trì phần mềm theo OTD (xem DFARS 227.7203-2(b)(1)) đ ểgia tăng tính lanh lẹ, gia tăng sự cạnh tranh, làm giảm chi phí, và tăng t ốc đ ộ tri ển khai. OTD làmột tiếp cận cho sự phát triển phần mềm/hệ thống trong đó các lập trình viên (những người khôngnhất thiết phải nằm trong cùng một tổ chức) phát triển và duy trì một cách c ộng tác ph ần m ềmhoặc một hệ thống theo một cách thức phân tán. OTD phụ thuộc vào các tiêu chuẩn m ở và cácgiao diện mở, PMNM và thiết kế mở, các công cụ trực tuyến cộng tác và phân tán, và s ự lanh l ẹcủa công nghệ. Người chào hàng sẽ mô tả cách mà họ sẽ triển khai OTD, bao gồm c ả cách mà h ọdự định phát triển, tiến hóa, và/hoặc đóng góp cho một cộng đồng phát triển từ nhiều t ổ ch ức.Người chào hàng sẽ thảo luận các kế hoạch của họ cho việc sử dụng, triển khai, và phát triển cáctiêu chuẩn mở, các giao diện mở, PMNM và các thiết kế mở, và các công cụ trực tuyến cộng tác vàphân tán.Phần mềm/hệ thống nên tiếp tục tiến hóa như một khả năng mở chung được phát triển và đượcgiới quân sự, và ở những nơi phù hợp, giới công nghiệp cập nhật chung. Qua th ời gian thì kh ảnăng này sẽ trở thành rẻ hơn để sở hữu, vận hành và nâng cấp thông qua sự cạnh tranh gia tăng,sự kết bám chặt chẽ vào các tiêu chuẩn mở, sự thương mại hóa của các công nghệ, sử dụngPMNM gia tăng và việc thi hành các quyền không hạn chế theo các mục đích của chính ph ủ. Cũngsẽ là mềm dẻo để xúc tác khả năng để mở rộng phạm vi m ột cách nhanh chóng nh ằm đáp ứngđược với những mối đe dọa mới, đang tiến hóa trong tương lai.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 34/77
  • 35. 2011 - Các bài học học được về công nghệ mở3.2.2 Các quyền trí tuệHãy đảm bảo rằng chính phủ có được các quyền cần thiết để triển khai OTD.Văn bản ví dụ:Chính phủ sẽ sử dụng OTD như là triết lý duy trì phần m ềm c ủa mình (xem DFARS 227.7203-2 (b)(1)). Điều này có nghĩa rằng phần mềm không được phát triển độc nhất với chi phí của tư nhân s ẽđược duy trì thông qua sự cộng tác giữa nhiều tổ chức, hoặc độc nhất bên trong chính phủ hoặcvới khu vực thương mại, theo ý muốn của chính phủ. Vì th ế, chính ph ủ ph ải có các quy ền khônghạn chế đối với tất cả các phần mềm máy tính (bao gồm cả mã ngu ồn, các tài li ệu thi ết k ế chínhthức và không chính thức) và các dữ liệu kỹ thuật (bao gồm cả các sách chỉ dẫn cho người s ửdụng) được phát triển theo hợp đồng này trừ phi chính phủ đưa ra sự cho phép cụ th ể b ằng vănbản để làm khác đi. Phần mềm được phân phối phải đưa ra được các quyền không hạn chế hoặcđưa ra một giấy phép PMNM trừ phi chính phủ đưa ra sự cho phép cụ thể b ằng văn b ản đ ể làmkhác đi. Hơn nữa, chính phủ mong muốn rằng nhà thầu sẽ đưa ra bất kỳ mã ngu ồn ph ần m ềmđược phát triển nào theo một giấy phép PMNM trừ phi chính phủ phân loại phần m ềm ho ặc ch ỉđịnh khác đi vì lợi ích của an ninh quốc gia.3.2.3 Các định dạng dữ liệu, các tiêu chuẩn & các giao diệnPhụ lục A đưa ra các chỉ dẫn cho một số trong số nhiều chỉ thị và chính sách của chính phủ M ỹ cóliên quan tới các định dạng dữ liệu, các tiêu chuẩn, và các giao diện mở.Văn bản ví dụ:Theo các chỉ thị và chính sách của chính phủ Mỹ thì chương trình này s ẽ ưu tiên và s ử d ụng cácđịnh dạng dữ liệu, các tiêu chuẩn và các giao diện có thể được truy cập một cách mở. Nếu bất kỳthứ gì trong số này không sẵn sàng thì nhà thầu nên chi tiết hóa cách có thể áp dụng và/ho ặc s ửađổi các tiêu chuẩn hiện đang tồn tại hoặc cách sẽ tạo ra mới những thứ đó và đưa chúng ra theomột cách thức đảm bảo rằng chúng là tự do và không bị gây trở ngại. Đặc biệt: 1. Các định dạng dữ liệu, các tiêu chuẩn và các giao diện sau s ẽ đ ược s ử d ụng: <LI ỆT KÊ NHỮNG THỨ PHÙ HỢP CHO DỰ ÁN, VÀ MÔ TẢ CÁCH MÀ CHÚNG PH ẢI Đ ƯỢC SỬ DỤNG>. 2. Phần mềm/hệ thống kết quả phải là theo các module. Người chào hàng phải xác đ ịnh các module chủ chốt và cách mà các module đó sẽ tương tác. 3. Nhà thầu sẽ sử dụng và/hoặc mở rộng các tiêu chuẩn mở không bị gây trở ngại trong quá trình diễn tiến của chương trình này. Nếu chúng được mở rộng, thì chúng s ẽ được ghi thành tài liệu ở dạng (và với các quyền cần thiết) sao cho những mở rộng đó có thể được đệ trình cho một cơ quan tiêu chuẩn phù hợp. 4. Nếu các tiêu chuẩn mở cho các giao diện chủ chốt bên ngoài không tồn tại, thì nhà thầu sẽ tạo ra và xuất bản các tiêu chuẩn mở không bị gây trở ngại có thể truy c ập đ ược. Đâu là những tiêu chuẩn mà nhà thầu đề xuất để tạo ra, đâu là các phạm vi c ủa chúng và cách mà chúng sẽ được tạo ra? 5. Các định dạng dữ liệu, các tiêu chuẩn và các giao diện nào khác sẽ được đề xuất sử dụng? Trong từng trường hợp, có một triển khai PMNM nào xử lý hoặc triển khai nó hay không?Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 35/77
  • 36. 2011 - Các bài học học được về công nghệ mở3.2.4. Các công nghệ OTSVăn bản ví dụ:Theo luật và chính sách của chính phủ, sử dụng COTS thương mại, bao gồm cả PMNM, được ưutiên, và sử dụng lại là bắt buộc đối với việc phát triển (lại). Các nhà th ầu nên đánh giá các côngnghệ để sử dụng theo trật tự sau: 1. Áp dụng các công nghệ hiện đang tồn tại. Điều này bao gồm COTS (bao gồm cả PMNM) và GOTS (bao gồm OGOTS) 2. Sửa đổi: Những công nghệ đang tồn tại nào có thể được tinh chỉnh và/hoặc được sửa đổi? 3. Tạo ra: Những công nghệ nào có thể cần phải được tạo ra? 4. Người chào hàng sẽ liệt kê những sản phẩm GOTS nào sẽ được s ử dụng và xem xét kh ả năng cho việc chuyển đổi và đưa nó ra cho sự phát triển cộng tác, như là PMNM ho ặc OGOTS.3.2.5 Các thực tiễn của OTDVăn bản ví dụ:Người chào hàng nên sử dụng các thực tiễn của sự phát triển công nghệ mở: 1. Chính phủ mong muốn cam kết với một khán thính phòng rộng lớn hơn của các lập trình viên và những người sử dụng cho khả năng này. Hãy mô tả cách mà điều này có thể xảy ra được. 2. Nếu các phần hoặc tất cả khả năng là kiểm soát xuất khẩu và/hoặc bí mật, thì hãy giải thích cách mà một nhà thầu/nhà tích hợp có thể tạo ra và qu ản lý mã ngu ồn và cam k ết m ột cách có hiệu quả với một cộng đồng (như, khung công việc với các trình cài c ắm, h ệ th ống qu ản lý cấu hình phân tán, ...). 3. Các phiên bản mã nguồn phải tuân thủ các tiêu chuẩn của cộng đồng PMNM. Chúng ph ải là dễ dàng và theo một cách thức tự động được biên dịch/xây dựng, kiểm thử, và chạy có sử dụng các công cụ và thư viện sẵn có được sử dụng rộng rãi. Nó phải có khả năng đ ể cập nhật một cách riêng rẽ và nhanh chóng các thư viện và các phụ thuộc khác (thay vì việc chúng được nhúng và khó để cập nhật). 4. Văn phòng và/hoặc nhà thầu của chương trình nên triển khai, như các kho dữ liệu (DFARS 227.7108), các site cộng tác ở nơi mà tất cả các mã nguồn phần mềm, thông tin thiết k ế không chính thức (như, các thư điện tử, wikis, các nhật ký chat), các trình theo dõi l ỗi, các tài liệu thiết kế chính thức, và mã có thể chạy được sẽ có thể truy cập được đối với chính phủ và/hoặc bất kỳ ai mà chính phủ thấy phù hợp để trao quyền truy cập. Ng ười th ực hi ện nên chi tiết: a) Môi trường phát triển tích hợp IDE (Integrated Development Environment) nào được sử dụng. b) Các cộng đồng tham gia và/hoặc tạo ra. c) Các vấn đề tiềm tàng về kiểm soát xuất khẩu (ITAR/EAR) và bí mật với phiên bản mã nguồn và dữ liệu của phần mềm. d) Giải thích cách mà chính phủ và các nhân viên khác sẽ được cung cấp sự truy cậpVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 36/77
  • 37. 2011 - Các bài học học được về công nghệ mở mạng từ xa một cách liên tục tới diễn tiến của công việc hiện hành (chứ không phải là các kết quả cuối cùng). 5. Cách thức và nơi mà người thực hiện có kế hoạch chuyển các công nghệ và các ch ương trình phần mềm này sau một giai đoạn thực hiện? 6. Người chào hàng nên xác định vài trong số các ví dụ phù hợp nhất gần đây trong đó h ọ đã sử dụng các thực tiễn OTD để duy trì phần mềm, chỉ ra cách mà các kinh nghiệm và các thành công của mình thể hiện được rằng sẽ có khả năng triển khai OTD trong dự án này.3.2.6 Các phân phốiVăn bản ví dụ: 1. Các quyền trí tuệ a) Chính phủ phải nhận được các quyền không hạn chế đối với các dữ liệu cho tất cả mã nguồn phần mềm được phát triển bằng tiền của những người đóng thuế trừ phi người chào hàng đã nhận được sự cho phép bằng văn bản. b) Chính phủ phải nhận được các giấy phép PMNM hoặc các quyền không hạn chế cho tất cả các phân phối trừ phi người chào hàng đã nhận được sự cho phép bằng văn b ản. Ở những nơi mà phần mềm được cấp phép của PMNM thì: • Tất cả các giấy phép PMNM phải tương thích được theo pháp lý theo cách mà chúng được sử dụng. • Tất cả các giấy phép phải được OSI chứng thực như là các giấy phép PMNM và FSF chứng thực như là các giấy phép phần mềm tự do. 2. Các định dạng dữ liệu, các tiêu chuẩn & các giao diện a) Một trình bày về sự tuân thủ với các tiêu chuẩn mở chính được yêu cầu. Ở những nơi có thể, điều này sẽ được thể hiện bằng việc thay thế từng thành phần mà nó triển khai một tiêu chuẩn mở với một triển khai độc lập cũng triển khai tiêu chu ẩn m ở đó. Ví d ụ, nếu một ứng dụng web được xây dựng trên các tiêu chuẩn m ở như HTTP, HTML, và CSS, thì nó phải được thể hiện với các trình duyệt web thông dụng có thể thay thế được mà chúng triển khai các tiêu chuẩn này. b) Kiểm tra tính hợp lệ mà các định dạng dữ liệu, các tiêu chuẩn & các giao di ện này s ẽ không bị gây trở ngại (như, các bằng sáng chế chứa đựng phí bản quyền) và có thể truy cập được một cách mở. c) Nếu các tiêu chuẩn mới đã được tạo ra, hãy kiểm tra tính hợp lệ rằng chúng đang được một cơ quan độc lập duy trì. 3. Kiểm tra tính hợp lệ rằng các kho dữ liệu đang xúc tác cho sự phát tri ển c ủa c ộng đ ồng. Kiểm tra tính hợp lệ rằng bất kỳ thông tin mật hoặc kiểm soát xuất khẩu nào cũng được đánh dấu và bảo vệ một cách phù hợp.3.3 Lựa chọn nguồn: Đánh giá các đề xuấtLoạt DoD 5000 là rất rõ ràng về cách mà những nỗ lực đề xuất sẽ được quản lý và tính điểm; phầnnày chỉ đưa ra các khuyến cáo.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 37/77
  • 38. 2011 - Các bài học học được về công nghệ mở3.3.1 Đánh giá cách mà đề xuất tốt đáp ứng RFPĐánh giá nên xem xét và tính điểm đề xuất đã đáp ứng tốt thế nào cho RFP, bao g ồm c ả các lĩnhvực được liệt kê ở trên: 1. Nó có đáp ứng được tất cả các mục đích hay không? 2. Các quyền trí tuệ 3. Các định dạng dữ liệu, các tiêu chuẩn & các giao diện 4. Các công nghệ OTS 5. Các thực tiễn OTSKhi tiến hành lựa chọn nguồn thì mấu chốt để phát triển các tiêu chí mà chúng không mơ hồ và d ễdàng để tính điểm. Ví dụ: 1. Nhà thầu đã liệt kê những tiêu chuẩn nào mà họ có kế hoạch sử dụng, và chúng có phù hợp không? 2. Chiến lược cộng đồng kỹ thuật gắn kết và có thể làm việc được là gì? 3. Các quyền trí tuệ, các định dạng/giao diện, và các thành phần OTS cho các k ết qu ả công việc có được mô tả rõ ràng hay không?3.3.2 Các tiêu chí chấp nhận/phê chuẩn đối với các phân phốiThậm chí khi chính phủ và một nhà thầu đạt được một thỏa thuận đưa vào các quyền không h ạnchế, thì kiến trúc theo module, các tiêu chuẩn và giao diện mở, và một chiến lược cộng đồng, thìvẫn có khả năng đánh mất những lợi ích của OTD nếu các phân ph ối theo h ợp đ ồng b ỏ sót nh ữngđiểm nhỏ. Nếu một nhà thầu triển khai phần mềm như là các nhị phân trong một hệ thống quân sự,thì chính phủ không thể kiểm tra được tính hợp lệ rằng tất cả các mã nguồn mà chính phủ đã trả tiềnthực sự được biên dịch trong phân phối cuối cùng. Các khách hàng của chính phủ nên áp dụng mộttiếp cận “tin cậy nhưng phải kiểm tra” đối với việc biên dịch các phần m ềm do chính ph ủ c ấp v ốnbằng việc kiên định rằng tất cả mã nguồn sẽ được phân phối và biên dịch trong hệ thống điện toánnơi mà nó có nghĩa để chạy. Việc biên dịch phần mềm trong một hệ thống đích nên là một điều kiệnchấp nhận theo hợp đồng đối với phân phối đó. Cũng vậy, phân phối của một bản sao được lưu trữcủa tất cả các tài liệu thiết kế chính thức và không chính thức nên là một điều kiện của sự chấp nhậntheo hợp đồng của phân phối đó. Những yếu tố này bao gồm: 1. Các giản đồ và tài liệu kiến trúc và hệ thống. 2. Tất cả các thư viện phần mềm cần thiết. 3. Tài liệu về ngôn ngữ, môi trường phát triển, và các phiên bản của trình biên dịch được s ử dụng. 4. Các thảo luận trên các diễn đàn và danh sách thư và các nhật ký chat. 5. Các báo cáo theo dõi lỗi. 6. Các nhật ký kiểm soát phiên bản.Tất cả các yếu tố OTD trong đề xuất của dự án nên được đánh số như các nhi ệm v ụ riêng r ẽ tronghợp đồng, và tài liệu được tạo ra và có liên quan tới các y ếu t ố đó ph ải đ ược phân ph ối tr ước khi h ệVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 38/77
  • 39. 2011 - Các bài học học được về công nghệ mởthống được cho là được phê chuẩn và được chấp nhận đối với các mục đích hợp đồng và thanh toán.3.3.3 Các cạm bẫy phải tránhChú ý đối với những cạm bẫy sau: 1. Phần mềm lẫn lộn việc chính phủ cấp vốn với phần mềm tư nhân cấp v ốn (đ ặc bi ệt n ếu nó được cấp bằng sáng chế), vì thế mà chính phủ không nhận được các quyền không hạn chế. 2. Kết hợp các thành phần sở hữu độc quyền (đặc biệt không phải là OTS) mà chúng b ị m ắc vào các phí cấp phép, đặc biệt nếu hệ thống đó được thiết kế để bảo vệ các thành phần đó. 3. Phần mềm lẫn lộn với kiểm soát xuất khẩu và bí mật với các phần mềm khác. Các lập trình viên nên thay vào đó bằng việc tạo ra một kiến trúc “cài cắm” (ở những nơi có khả năng) mà nó cho phép sử dụng và chia sẻ phần mềm không bị hạn chế bằng các kiểm soát xu ất kh ẩu hoặc bí mật. 4. Thất bại trong việc đưa vào các yếu tố cần thiết để biên dịch mã nguồn trong hệ thống đích (vì lý do yêu cầu các phân phối phải được đưa ra nh ư mã ngu ồn và đ ược biên d ịch trên h ệ thống đích). 5. Thiếu việc lên kế hoạch quản lý cộng đồng và duy trì mã nguồn của d ự án nh ư m ột y ếu t ố cho việc vận hành và duy trì O&M (Operation & Maintenance). Sự duy trì và qu ản lý c ủa một cộng đồng xung quanh một thành phần phần mềm cụ thể có thể đưa ra những lợi ích to lớn (như những cải tiến trong an ninh và tính tương hợp khi các công nghệ tiến hóa bên trong và bên ngoài chính phủ) ở chi phí thấp nhất. Nhưng có ai đó, một lập trình viên cao cấp sẽ là ưu tiên hơn, cần chuyên tâm toàn bộ thời gian vào nhiệm vụ này, và đi ều đó ch ắc sẽ xảy ra nếu người quản lý cộng đồng được đền bù cho công việc này. Là h ợp pháp đ ối v ới một nhà cung cấp để phản đối đối với một nhiệm vụ kết thúc mở c ủa vi ệc qu ản lý m ột c ộng đồng nguồn mở nhiều lập trình viên hoặc một cộng đồng các lập trình viên c ủa GOTS nh ư một hoạt động tình nguyện, thậm chí dù điều đó có thể là một lợi ích dài hạn cho công việc kinh doanh của họ. Cũng vậy, là ngây thơ và lạc quan đối với chính phủ đ ể gi ả thi ết r ằng s ự quản lý thông minh và sự duy trì và cập nhật được liên tục đối với một d ự án OTD, đ ặc bi ệt một dự án GOTS (so với PMNM công khai), sẽ xảy ra một cách màu nhi ệm mà không có các tài nguyên chuyên dành cho nhiệm vụ đó. Những người quản lý chương trình nên xác định các tài nguyên để triển khai thậm chí một phần nhỏ tương đương toàn b ộ th ời gian đ ể duy trì các cộng đồng OTD sau khi các dự án được phân phối. Nếu tiền cho chương trình không thể có sẵn cho O&M (so với sự phát triển) như một vấn đề v ề chính sách, thì nh ững người quản lý chương trình nên chắc chắn rằng sự quản lý cộng đồng OTD được xây d ựng trên kế hoạch chuyển dịch và rằng chi phí (như thời gian cộng với chi phí duy trì hạ tầng cộng tác của cộng đồng) được xây dựng trong ngân sách O&M đối với khả năng được triển khai. Hãy sử dụng hạ tầng cộng tác PMNM, so với các dịch vụ được quản lý một cách s ở hữu độc quyền, có thể giảm các chi phí O&M đối với các dự án OTD trong các hoạt động và pha duy trì, đảm bảo rằng tiền của O&M sẽ được sử dụng để giữ lại th ời gian và s ự chú ý của một lập trình viên cao cấp hoặc người quản lý cộng đồng mà anh này gi ữ cho d ự án được nạp năng lượng.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 39/77
  • 40. 2011 - Các bài học học được về công nghệ mởChương 4. Phát triển & Phân phối liên tụcMột khi một khả năng quân sự được đưa lên và chạy, thì dự án còn chưa kết thúc. Trên th ực t ế, nóchỉ bắt đầu. Các hoạt động và pha duy trì của phần mềm được đặc trưng bởi những thay đổi liên tiếptrong kho mã nguồn, đối với bất kỳ số lượng lý do nào như: những thay đổi ph ần c ứng, s ửa các l ỗiphần mềm, các cập nhật và thay đổi, các thay đổi về hạ tầng công nghệ thông tin, đ ộ r ộng băngthông và các cập nhật theo các nhu cầu chiến đấu. Các nhà thầu và nhân viên của chính ph ủ cũng s ẽthay đổi.Cuối cùng, nếu các bước bên dưới được tuân theo, thì chương trình sẽ ở trong một tình tr ạng t ốt đ ểnhanh chóng nâng cấp khả năng của phần mềm để giữ được cập nhật v ới thay đ ổi công ngh ệ và cácmối đe dọa mới.4.1 Các chu kỳ phát triển nhanhVề mặt lịch sử, các dự án phần mềm của chính phủ theo các rà soát lại các yêu cầu dài lâu đ ượctuân theo với những suy nhược của các tác vụ, các lịch trình, kiểm thử và đánh giá, và phân ph ốichính thức đều theo kiểu thác nước đổ. Là không bình thường đối với các vòng đời để tạo ra nh ữngvòng đời phân phối tối thiểu theo một năm hoặc lâu hơn - với tính mềm dẻo nh ỏ bé cho vi ệc ápdụng chức năng hoặc công nghệ mới bên trong chu kỳ đó.Đối nghịch lại một cách sâu sắc, hầu hết các dự án PMNM là trong một tình trạng luôn luôn tiếnhóa với các chu kỳ kiểm thử và xây dựng rất ngắn. Những thực ti ễn đ ược nuôi n ấng t ốt nh ất s ẽnhanh chóng được áp dụng xuyên khắp các dự án nguồn mở được thiết lập. Trong nhiều trường hợp,điều này đã thiết lập nên các tiêu chuẩn de facto cho các dự án phát triển phần mềm.Điều điển hình đối với các dự án nguồn mở là đánh dấu các phiên bản của chúng b ằng các con s ốchẵn - như 1.8.2. Tần suất của những xây dựng và các phiên bản chính thức là khác nhau đ ối v ớitừng dự án - nhưng được lên kế hoạch một cách thông thường trên c ơ s ở theo quý, n ửa năm, ho ặcmột năm. Theo qui ước, những phiên bản phát triển - đôi khi được đặt tên là những phiên b ảnkhông ổn định, sẽ được tung ra ở giữa chừng cho cộng đồng kiểm thử và bình luận. Những phiênbản phát triển, như là những phiên bản không chính thức, thường có các con số phiên bản là lẻ -như 1.7.0. Đối với các chương trình của chính phủ, thường sẽ có ý nghĩa để đưa ra các phiên b ảnchính thức.4.2 Kiểm thử, chứng thực và làm cho tin tưởngPhần mềm OTD phải đáp ứng y hệt các tiêu chuẩn cho sự chứng thực và làm cho tin t ưởng C&A(Certification & Accreditation) như phần mềm đóng hoặc sở hữu độc quyền. Ưu điểm của OTD làcác thành phần có thể đã được chứng thực từ trước hoặc được kết hợp vào các h ệ th ống đ ược ch ứngthực và được làm cho tin tưởng rồi. Đặc biệt trong các kiến trúc hướng dịch vụ, thành ph ần ho ặcchứng thực dịch vụ phần mềm đã có trước đó rồi làm giảm thi ểu kích c ỡ c ủa kho mã ngu ồn m ới mànó sẽ được chứng thực và làm cho tin tưởng được.Hầu hết các dự án nguồn mở bây giờ hỗ trợ đơn vị kiểm thử và những phần xây dựng được tự đ ộnghóa vào ban đêm với việc kiểm thử được tích hợp. Các vấn đề vì thế được phát hiện và được s ửachữa nhanh chóng. Sự phát triển và triển khai các giải pháp phần mềm được gia tốc bằng dòng ti ếntrình kiểm thử, xây dựng, và đóng gói theo đơn vị được tích hợp. Nó sẽ trở nên ngày một quan trọngđể chứng thực cho các qui trình phát triển, kiểm thử, và phân phối so với nh ững phiên b ản ph ầnVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 40/77
  • 41. 2011 - Các bài học học được về công nghệ mởmềm cụ thể. Quản lý chương trình nên được khuyến khích để tham gia một cách tích c ực v ới cácnhóm nguồn mở bên ngoài bằng việc phát triển và thúc đẩy đơn vị kiểm thử.Thách thức đối với một người quản lý chương trình mà khả năng của phần m ềm c ủa anh ta là liêntục được tiến bộ bởi một cộng đồng là: cách nào và khi nào bạn xác định được một phiên bản cụ thểvề khả năng như là một phiên bản chính thức cho các mục đích C&A, và tần suất của các phiên bảnđó là thế nào. Là sống còn để duy trì nhận thức của cả nh ững nhu c ầu c ủa nh ững ng ười s ử d ụng đ ầucuối (như những người sử dụng khắc khoải muốn hoặc cần phiên bản mới nhất của phần mềm nhưthế nào) và những sự kiện đáng kể ở phía phát triển (như một chỗ bị tổn thương đã được xác định vàđược giải quyết).Cũng vậy, là quan trọng để xây dựng và duy trì một mối quan hệ với bất kỳ ai xác thực và làm chohệ thống tin tưởng được, sao cho họ biết trước được những thay đổi của phiên bản tiếp sau là l ớnhay nhỏ thế nào. Được khuyến cáo cao độ để tuyển mộ các chuyên gia chứng thực và làm cho tintưởng và “những cánh tay cũ” của C&A vào cộng đồng các lập trình viên để đưa ra ý ki ến ph ản h ồivề những thay đổi và sửa lỗi được đề xuất. Cơ quan chức trách C&A đối với một hệ thống OTD nêncó tầm nhìn đầy đủ trong hạ tầng cộng tác, hoặc như một người th ẩm tra b ị đ ộng ho ặc nh ư m ộtngười tham gia tích cực trong quá trình C&A, khi xác định các vấn đề và các tiêu chí C&A c ần thi ếtphải được giải quyết.4.3 Chuyển sang các hoạt động & duy trìĐiểm vào chung đối với các công nghệ PMNM là thông qua các phòng thí nghi ệm, các d ự án, vàcác vật mẫu đầu. Thường thì, các qui trình quản lý cấu hình và ch ứng th ực c ủa các d ự án này ít ch ặtchẽ hơn so với các hệ thống hoạt động có tính sống còn. Sự chuyển các khả năng và giải pháp nàysang các hoạt động luôn là một thách thức - cho cả các công nghệ mở và sở hữu độc quyền. Thôngthái ra thì để bắt đầu lên kế hoạch chuyển ngay từ đầu của bất kỳ dự án nào. Tài liệu d ồi dào v ềchức năng, các chỉ dẫn quản trị, và quản lý cấu hình, qui trình kiểm thử và kiểm tra tính đúng đắn,cũng như tài liệu quản lý điều hành dự án, sẽ giúp làm trơn tru con đường hướng tới những ho ạtđộng. Hầu hết các dự án thất bại vì thiếu hụt kế hoạch chuyển dịch chính thức. Gần đây, chính phủđã bắt đầu chính thức xác định những người quản lý chuyển đổi sớm trong qui trình.Chính phủ có những thủ tục tốt cho những yêu cầu, rà soát lại, và hỗ trợ nhà th ầu v ề các công ngh ệmà chính phủ mua sắm. Các nhà tích hợp, các chuyên gia theo chuyên ngành, và các nhà thầu hỗ trợcác công nghệ mở có thể đơn giản được nghĩ về các nhà cung cấp COTS. Các dự án thường s ẽ c ầncấp vốn và tiền cho các hoạt động và hỗ trợ duy trì và các d ịch v ụ chuyên nghi ệp cho duy trì m ộtkhả năng của phần mềm OTD và cộng đồng của nó.4.4 Khả năng tìm kiếmBạn tìm kiếm mọi thứ thế nào? Ngày nay nếu chương trình phần mềm và/ho ặc d ự án c ủa b ạn là“không thể tìm được” thì nó là không tồn tại.Tính có thể tìm được được xác định như là dễ dàng trong đó thứ gì đó trên World Wide Web có th ểtìm thấy, như, dễ dàng có thể tìm được và tìm ra được. [Morville2005].Điều này đi với các chương trình của chính phủ. Vì nhiều lý do, chính ph ủ và quân đ ội có m ột s ựthuê mướn để chi cho các tài nguyên và thời gian khan hiếm hoặc cho việc xây dựng lại ho ặc tái t ạolại các mẩu của tất cả các công nghệ hiện đang tồn tại.Các chương trình quân sự cũng có thể tập trung nhiều vào việc đáp ứng các yêu cầu của chúng làmVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 41/77
  • 42. 2011 - Các bài học học được về công nghệ mởcho những người khác nhận thức được về dự án không được xác định đặc biệt như một khách hàngbị bỏ rơi. Trong thực tế khi mỗi nỗ lực nên được thực hiện s ẽ là có sự tham gia vào và làm chonhững người khác nhận thức được về các khả năng đang được phát triển.Đây là một bước rất thực dụng vì nó có thể dẫn tới tiền của bổ sung thêm đang đ ược đ ưa vàochương trình và có thể làm gia tăng kích cỡ số lượng những người s ử dụng đ ược văn phòng ch ươngtrình quân sự phục vụ.Một ít các qui định đơn giản để làm cho một dự án quân sự “có thể tìm thấy được”: 1. Worl Wide Web: Tạo một website liệt kê khả năng đang được phát triển. Website này có th ể được một nhà thầu hoặc văn phòng chương trình tạo ra. 2. Sử dụng Trung tâm Thông tin Kỹ thuật Quốc phòng (http://www.dtic.mil/dtic/) để công b ố công việc. 3. Đưa ra các thông cáo báo chí chính thức. 4. Các phương tiện xã hội: nếu chương trình dự kiến sẽ sử dụng các công c ụ m ạng xã h ội lâu dài. 5. Intelink: tạo ra một trang trong dịch vụ Intellipedia của các cộng đồng trí thức. 6. Tham gia, phát biểu và hiện diện trong các hội nghị quân sự và phi quân sự.4.5 Các bài học học được.Điểm chủ chốt khác về vấn đề mở là đối với các bài học học được đ ược ghi chép t ốt thành các tàiliệu sao cho những người khác có thể làm theo sự thành công và quan trọng hơn để tránh đượcnhững cạm bẫy phổ biến. Thành thực mà nói, mở và trung thực về những gì được làm và đã khônglàm là một hòn đá tảng của các hoạt động quân sự, chúng ta cần đảm bảo r ằng chúng ta có m ức đ ộy hệt đối với sự tin cậy và sự trung thực trong phát triển và mua sắm phần mềm.Cũng là nói về những thành công, việc xuất bản các bài học học được trong các tạp chí thương mạicông nghiệp và các kỷ yếu của các hội thảo.4.6 Danh sách chọn các thành công của OTDSau đây là một danh sách chọn được gợi ý cho các dự án phát triển OTD: • Cộng đồng trước, công nghệ sau. Thường thì quân sự sẽ tập trung vào việc tạo ra các giải pháp công nghệ khi các bên đóng góp sẽ không tiến hành hoặc không tồn tại. Nhà công nghệ phải được kiểm soát và không được cho phép để xây dựng và/ho ặc triển khai ph ần m ềm cho tới khi một cộng đồng và cơ sở những người sử dụng được xác định. • Mặc định là mở, đóng chỉ là khi cần thiết. • Chương trình của bạn không phải là đặc biệt. Vâng, quân s ự có nh ững nhu c ầu và các kh ả năng chiến đấu đặc biệt, nhưng (đặc biệt là trong công nghệ thông tin) thì chúng tôi không thế. Hãy tìm kiếm các dự án công nghệ thông tin đang tồn tại và các nền công nghiệp và sử dụng các giải pháp của họ. • Hãy thiết lập các qui định đơn giản về cách chia sẻ và cách truy cập GOTS. Vi ệc t ạo ra m ột cơ cấu chia sẻ mã nguồn phần mềm làm việc được là vì ưu thế của chính phủ là quan trọng.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 42/77
  • 43. 2011 - Các bài học học được về công nghệ mở • Các quyền trí tuệ. Việc sử dụng các giấy phép PMNM đơn giản hóa to lớn s ự qu ản lý các quyền đối với chính phủ. • Hãy thương thảo và yêu cầu các quyền không hạn chế trong phần mềm và mã ngu ồn. Chính phủ có ý định các quyền là cơ bản còn cơ chế giấy phép què quặt nên được tránh. • Không tạo ra các giấy phép mới cho phần mềm, hãy sử dụng các giấy phép hiện đang tồn tại - chúng được hiểu trong nền công nghiệp thương mại và đã được các lu ật s ư c ủa các t ập đoàn phê chuẩn. • Hãy hạn chế mạnh mẽ sự pha trộn lẫn lộn các phần mềm chính phủ cấp tiền với các phần mềm tư nhân cấp tiền (đặc biệt nếu nó được trao các bằng sáng chế). Nếu sự pha trộn lẫn lộn được yêu cầu thì hãy phát triển theo một cách thức theo các module và hãy yêu cầu các quyền không hạn chế. • Các phần mềm có kiểm soát xuất khẩu và bí mật pha trộn l ẫn l ộn v ới các ph ần m ềm khác. Các lập trình viên nên thay vào đó hãy sáng chế ra một kiến trúc “cài cắm” ( ở nh ững n ơi có thể) cho phép sử dụng và chia sẻ phần mềm không bị hạn chế vì những kiểm soát xu ất kh ẩu hoặc bí mật. • Hãy hạn chế việc kết hợp các thành phần sở hữu độc quyền (đặc biệt không phải OTS) mà chúng mắc vào chi phí cấp phép, đặc biệt nếu hệ thống được thiết kế phụ thuộc vào các thành phần đó. • Lên kế hoạch và cấp vốn cho sự quản lý cộng đồng của dự án và duy trì mã nguồn như một yếu tố chuyển O&M. • Tiếp tục và khuyến khích những tranh luận và thảo luận mạnh mẽ về phần mềm trong những người sử dụng, và trong các lập trình viên. • Đừng quên viết tài liệu. Điều này bao gồm cả tài liệu cho người s ử d ụng, cài đ ặt, qu ản tr ị, và thiết kế. Nó cũng bao gồm các sách chỉ dẫn về cách để cài đặt và duy trì phần mềm theo cách đưa ra được an ninh. • Quản lý cấu hình: Thông tin được duy trì về những gì mà những công cụ/những đánh giá từ bên ngoài đã được chạy, về phiên bản nào của phần mềm, và các kết quả đã có là gì. • Hãy quản lý dự án như là một phường hội: những người s ử dụng đôi khi s ẽ tr ở thành các l ập trình viên, ít nhất là đối với những khiếm khuyết nhỏ.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 43/77
  • 44. 2011 - Các bài học học được về công nghệ mởPhụ lục A: Chính sách và chỉ dẫn của chính phủ Mỹ về tính mởPhụ lục này trình bày chỉ dẫn và các chính sách thích hợp của Chính phủ Mỹ có liên quan tới OTD.OTD là một tiếp cận cho sự phát triển phần mềm/hệ thống và duy trì phần m ềm hoặc một hệ th ốngtheo một cách thức phi tập trung. OTD là một cách thức để làm giảm thiểu chi phí gia tăng của cáchệ thống phần mềm và tăng tốc độ đưa ra các khả năng mới. OTD cũng làm gia tăng các c ơ h ội chosự cạnh tranh và đổi mới sáng tạo, xúc tác một cách nhanh chóng cho các h ệ th ống th ực đ ịa và cóthể nâng cấp được trong khi tối ưu hóa sử dụng lại các tài sản phần mềm. Kế hoạch về lộ trình OTD2006 [OTD 2006] nói rằng OTD kết hợp: 1. Các tiêu chuẩn và các giao diện mở (bao gồm cả các định dạng tài liệu mở). 2. PMNM và các thiết kế mở. 3. Văn hóa cộng tác/phân tán và các công cụ hỗ trợ trực tuyến. 4. Tính lanh lẹ của công nghệ (bao gồm các hệ thống mở/kiến trúc mở).Các qui trình mua sắm và phát triển phần mềm nên sử dụng, mở rộng, và tạo ra từng trong số nh ữngyếu tố chủ chốt này để đạt được sự phát triển các công nghệ mở: Mấu chốt của OTD Yếu tố Mở rộng sử dụng Tạo1. Các tiêu chuẩn mở và Ưu tiên sử dụng các tiêu Đưa lên những thay đổi Khởi tạo các đặc tả chocác giao diện mở (bao chuẩn/ giao diện/ định được đề xuất để mở ra tiêu chuẩn mới ở nhữnggồm các định dạng mở). dạng dữ liệu mở hơn sở cho những người duy trì nơi phù hợp. Ví dụ, giúp hữu độc quyền; kiểm thử các tiêu chuẩn ở những phát triển một đặc tả có để đảm bảo có các triển nơi mà các tiêu chuẩn thể được sử dụng như một khai là các lựa chọn thay không đáp ứng được các “tài liệu cơ bản”. thế có thể sử dụng được. yêu cầu.2. PMNM và các thiết kế Sử dụng PMNM đang có Sửa đổi PMNM (như, sửa Khởi tạo các dự ánmở sẵn. các lỗi hoặc bổ sung các PMNM mới. chức năng) mà không rẽ nhánh kho mã nguồn.3. Văn hóa cộng tác/ phân Tham gia sử dụng các Chỉnh sửa các dự án cộng Thiết lập các dự án và cácphối và các công cụ hỗ công cụ có sẵn về quản lý tác và các công cụ/ hạ công cụ/hạ tầng quản lýtrợ trực tuyến. dự án cộng tác của cộng tầng quản lý dự án hiện dự án cộng tác mới liên đồng. đang tồn tại (như, đối với các tổ chức, nhưng tránh sự phát triển phần mềm bí trùng lặp. Điều này có thể mật). là OGOTS hoặc PMNM.4. Tính lanh lẹ về công Ưu tiên sử dụng các sản Cải thiện tính có thể Tạo ra các sản phẩm,nghệ (các hệ thống phẩm và dịch vụ mà là module hóa được, hỗ trợ dịch vụ, hoặc hạ tầng mà:mở/kiến trúc mở). theo các module và lanh nền tảng, và tính có thể (1) hỗ trợ hoặc cải thiện lệ về công nghệ. Tránh thiết lập cấu hình được sự lanh lẹ về công nghệ các sản phẩm và dịch vụ của các sản phẩm và dịch và (2) có tính module hóa nguyên khối hoặc bị khóa vụ đang sử dụng. nhiều hơn. trói vào chỉ một nền tảng.Các tiêu chuẩn và giao diện mở (bao gồm các định dạng dữ liệu mở) là một cơ ch ế mấu ch ốt đ ểVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 44/77
  • 45. 2011 - Các bài học học được về công nghệ mởtránh bị khóa trói vào nhà cung cấp và xúc tác cho s ự c ộng tác. Chúng xúc tác cho s ự c ộng tác vìcác lập trình viên ở mọi phía của giao diện là tự do để tiến hành những thay đ ổi mi ễn là chúng tuânthủ với các tiêu chuẩn phù hợp.PMNM có thể được sử dụng y như nó đang có, được sửa đổi ho ặc đ ược t ạo ra. Dù v ậy, nh ững m ởrộng của các thành phần PMNM có sẵn một cách công khai nên là mặc định đối với phiên b ản côngkhai, để tránh mắc kẹt vào các chi phí lớn và đánh mất sự đổi mới sáng t ạo vì s ự duy trì theo ki ểuđường ống khói. Việc tạo ra một dự án riêng rẽ bằng việc bắt đầu từ một dự án đang tồn tại được gọilà “rẽ nhánh”. Bất kỳ ai bắt đầu một rẽ nhánh cũng sẽ trở thành có trách nhiệm đ ối v ới m ột gánhnặng O&M riêng rẽ, vì phiên bản rẽ nhánh không tương thích với phiên b ản công khai đ ược c ộngđồng phát triển hiện hành hỗ trợ.Văn hóa cộng tác/phân tán với các công cụ hỗ trợ trực tuyến xúc tác cho s ự cộng tác nhi ều t ổ ch ức.Khá là dễ dàng để thiết lập một dự án cộng tác mới: trong nhiều trường hợp chúng nên là nh ững d ựán PMNM để tối đa hóa sự cộng tác (điều này làm giảm chi phí O&M v ề lâu dài). Tuy nhiên, m ộtsố thành phần phải không được đưa ra cho công chúng (thường những thành ph ần này có th ể là bímật và/hoặc tuân theo các kiểm soát xuất khẩu), hoặc chính phủ có thể không có các quyền dữ liệucần thiết. Trong trường hợp sau cùng, chính phủ nên ít nhất đấu tranh để có các quyền theo mụcđích của chính phủ GPR (Government Purpose Rights) sao cho sự cộng tác và sử d ụng r ộng rãi đótrong chính phủ có thể xảy ra được.Sự lanh lệ về công nghệ là quan trọng, và điều này được xúc tác mạnh mẽ bởi tính có thể chia thànhmodule tới từ một tiếp cận của các hệ thống mở/ kiến trúc mở. Trong một tiếp c ận h ệ th ống m ở/ki ếntrúc mở, các hệ thống được bẻ xuống thành các thành phần theo module, và các tiêu chuẩn và giaodiện mở sẽ được sử dụng để kết nối các thành phần này. Những giao diện của nhiều thành ph ần s ẽcó thể không được xác định một cách duy nhất bằng các tiêu chuẩn mở, nhưng ở những nơi có cáctiêu chuẩn mở thì chúng nên được sử dụng, và ở những nơi không có tiêu chuẩn mở phù hợp, thìgiao diện nên được ghi thành tài liệu và phải có các quyền phù hợp để đảm b ảo r ằng nh ững thànhphần khác có thể thay thế thành phần đó mà không có hạn chế nào (như, với thanh toán chi phí b ảnquyền).Các phần sau đây đi sâu vào từng lĩnh vực và xác định một s ố trong các chính sách c ủa chính ph ủvề chúng.A.1 Các tiêu chuẩn và các giao diện mở (bao gồm các định dạng dữ liệu mở)Chính phủ liên bang và DoD đã nhận thức được giá trị của các tiêu chu ẩn d ữ li ệu m ở không s ở h ữuđộc quyền và đã thiết lập các chính sách và qui định một cách tương ứng. Ph ần này đ ưa ra m ột s ốchính sách hiện hành của chính phủ và DoD xung quanh các tiêu chuẩn công nghệ thông tin(CNTT), và các vấn đề có liên quan tới chúng.Tuy nhiên, một ít lưu ý chung là như sau: 1. Hãy nhớ rằng các tiêu chuẩn đưa vào cả các giao diện và các định dạng dữ liệu; đừng quên nhu cầu về các tiêu chuẩn định dạng dữ liệu. Là dễ dàng đối với chính ph ủ đ ể k ết thúc trong một hoàn cảnh nơi mà chính phủ có các dữ liệu, nhưng chính phủ bị khóa trói một cách có hiệu quả vào một nhà cung cấp cụ thể, vì các dữ liệu bị khóa trói trong một ứng dụng sở hữu độc quyền cụ thể mà ứng dụng đó là cần thiết để xem, để sử dụng hoặc đ ể cập nh ật các d ữ liệu đó.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 45/77
  • 46. 2011 - Các bài học học được về công nghệ mở 2. Hãy nhận thức được các vấn đề về bằng sáng chế trong các tiêu chuẩn. Bất kỳ tiêu chuẩn nào được sử dụng trong một dự án của chính phủ liên bang và DoD nên được đánh giá đ ể đảm bảo rằng các tiêu chuẩn mà nó sử dụng không bị gây trở ngại từ m ột vi ễn c ảnh c ủa các quyền trí tuệ (như, chúng là sẵn sàng cho bất kỳ ai sử dụng hoặc triển khai lại, mà không có những trở ngại như thanh toán tiền bản quyền của các bằng sáng chế). Hãy nhận thức được rằng một số cơ quan tiêu chuẩn nói rằng một tiêu chuẩn “mở” chỉ là một tiêu chu ẩn mà qui trình để đạt được sự đồng thuận là mở; điều này có thể dẫn tới các tiêu chuẩn mà chúng đòi hỏi việc cấp phép cho các thỏa thuận và thanh toán tiền đáng kể cho các công ty đ ể đáp ứng được cái gọi là tiêu chuẩn “mở” đó. Trong tài liệu này, một “tiêu chuẩn đồng thuận một cách tình nguyện” được phát triển bởi sự đồng thuận, và có hoặc không th ể đòi h ỏi m ột thanh toán tiền bản quyền. Một “tiêu chuẩn mở” là một tiêu chu ẩn đ ồng thu ận m ột cách tình nguyện mà nó không đặt ra những thanh toán tiền bản quyền hoặc những hạn chế khác khi sử dụng nó. 3. Tương tự, hãy nhận thức được về “các tiêu chuẩn de facto” mà chúng hoàn toàn không ph ải là những đặc tả, hoặc ở những nơi mà những đặc tả được xuất bản thì có ít mối quan hệ tới các giao diện hoặc các định dạng mà chúng thực sự được sử dụng.A.1.1 Chính phủ MỹA.1.1.1 Các tiêu chuẩn đồng thuận tự nguyệnCác cơ quan chính phủ liên bang Mỹ phải sử dụng “các tiêu chuẩn đồng thuận tự nguyện” trong cácmua sắm của họ. Như được mô tả trong Thông tư số A-119 của Văn phòng Ngân sách & Qu ản lý,“Sự tham gia của Liên bang trong phát triển và sử dụng các tiêu chuẩn đồng thuận tự nguyện vàtrong sự tuân thủ các hoạt động đánh giá (10/02/1998,http://www.whitehouse.gov/omb/circulars/a119/a119.html)”: “Tất cả các cơ quan liên bang phải sử dụng các tiêu chu ẩn đồng thuận tự nguy ện thay cho các tiêu chuẩn duy nhất của chính phủ trong mua sắm và các hoạt động điều chỉnh theo luật của họ, ngoại trừ ở những nơi có sự mâu thuẫn với luật hoặc nếu không sẽ là không thực tế. Trong những hoàn cảnh đó, cơ quan của bạn phải đệ trình một báo cáo mô tả (các) lý do cho việc sử dụng của mình đối với các tiêu chuẩn duy nhất của chính phủ thay vì các tiêu chuẩn đồng thuận tự nguyện đối với Văn phòng Quản lý và Ngân sách (OMB) thông qua Viện Quốc gia về tiêu chuẩn và công nghệ (NIST)”.Tài liệu này cũng giải thích vì sao chính phủ nên sử dụng các tiêu chuẩn đồng thuận tự nguyện:Nhiều tiêu chuẩn đồng thuận tự nguyện là phù hợp hoặc có thể áp dụng được cho các m ục đích c ủaChính phủ. Sử dụng các tiêu chuẩn như vậy, ở bất kỳ nơi nào phù hợp và th ực t ế, đ ược mong đ ợi s ẽđạt được các mục tiêu sau: 1. Hạn chế được chi phí cho Chính phủ về phát triển các tiêu chu ẩn của riêng mình và làm giảm chi phí hàng hóa được mua sắm và gánh nặng của việc tuân thủ với qui định của cơ quan. 2. Đưa ra những khuyến khích và cơ hội để thiết lập các tiêu chuẩn ph ục v ụ cho các nhu c ầu quốc gia. 3. Khuyến khích sự tăng trưởng dài hạn cho các doanh nghiệp Mỹ và thúc đẩy sự cạnh tranh có hiệu quả và kinh tế thông qua sự hài hòa của các tiêu chuẩn.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 46/77
  • 47. 2011 - Các bài học học được về công nghệ mở 4. Xa hơn chính sách của sự tin cậy vào khu vực tư nhân để cung cấp cho các nhu cầu đối v ới các hàng hóa và dịch vụ của Chính phủ.Chính sách của OMB cũng xác định khái niệm “các tiêu chuẩn đồng thuận tự nguyện”: 1. Vì những lý do của chính sách này, “các tiêu chu ẩn đồng thu ận t ự nguy ện” là các tiêu chu ẩn được phát triển hoặc được các cơ quan tiêu chuẩn đồng thuận tự nguy ện áp d ụng, c ả trong nước và quốc tế. Những tiêu chuẩn này bao gồm các điều khoản yêu cầu rằng những người chủ sở hữu trí tuệ phù hợp đã đồng ý làm cho sở hữu trí tu ệ đó s ẵn sàng trên m ột c ơ s ở không phân biệt đối xử, không có chi phí bản quyền hoặc chi phí bản quyền hợp lý đối với tất cả các bên có quan tâm. Đối với các mục tiêu của Thông tư này, “các tiêu chu ẩn k ỹ thu ật được các cơ quan tiêu chuẩn đồng thuận tự nguyện phát triển hoặc áp d ụng” là m ột đi ều khoản tương đương. a) “Các cơ quan tiêu chuẩn đồng thuận tự nguyện” là các tổ chức trong n ước và qu ốc t ế mà họ lên kế hoạch, phát triển, thiết lập, hoặc điều phối các tiêu chuẩn đồng thuận tự nguyện có sử dụng các thủ tục dựa trên sự đồng thuận. Vì những lý do của Thông tư này, “các cơ quan tiêu chuẩn đồng thuận, khu vực tư nhân, tự nguyện” như đ ược trích trong Luật, là một điều khoản tương đương. Luật và Thông tư đó khuyến khích sự tham gia của các đại diện liên bang trong các cơ quan đó để gia tăng sự hợp lý rằng các tiêu chuẩn mà họ phát triển sẽ đáp ứng được cả các nhu cầu của khu vực nhà nước và t ư nhân. Một cơ quan tiêu chuẩn đồng thuận tự nguyện được xác định với những đặc điểm sau: • Tính mở • Cân bằng lợi ích • Tuân thủ qui trình • Một qui trình kháng nghị b) Đồng thuận, mà nó được xác định như là sự thỏa thu ận chung, nhưng không cần thiết có sự nhất trí, và bao gồm một qui trình cho dự định để giải quyết những phản đối của các bên có quan tâm, miễn là các bình luận đã được xem xét một cách công b ằng, m ỗi ng ười phản đối được tư vấn về sự sắp xếp các phản đối của anh hoặc chị ta và những lý do vì sao, và các thành viên của cơ quan đồng thuận được trao một cơ hội thay đổi các biểu quyết của họ sau việc rà soát lại các bình luận. 2. Các dạng tiêu chuẩn khác, là khác biệt với các tiêu chuẩn đồng thuận tự nguyện, như sau: a) “Các tiêu chuẩn không đồng thuận”, “các tiêu chuẩn công nghiệp”, “các tiêu chuẩn công ty”, hoặc “các tiêu chuẩn de facto”, mà chúng được phát triển trong khu vực tư nhân nhưng không trong qui trình đồng thuận đầy đủ. b) “Các tiêu chuẩn duy nhất của chính phủ”, mà chúng được chính phủ phát triển cho sử dụng của riêng chính phủ. c) Các tiêu chuẩn bắt buộc theo luật, như những tiêu chuẩn nằm trong Pharmacopeia c ủa Mỹ và Công thức Quốc gia, như được tham chiếu trong 21 U.S.C. 351.Lưu ý rằng chính sách của OMB cho phép sử dụng các tiêu chuẩn ở nh ững n ơi mà có m ột “c ơ s ởphí bản quyền hợp lý”, nhưng những người triển khai nên cảnh giác với những tiêu chuẩn khôngmở này. Những thanh toán tiền bản quyền như vậy ngăn cấm việc s ử dụng của nhi ều s ản ph ẩmPMNM (và vì thế trở thành một rào cản cho sự cạnh tranh), và có thể thường làm cho việc sử dụngVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 47/77
  • 48. 2011 - Các bài học học được về công nghệ mởchúng là không kinh tế.A.1.1.2 Gắn thẻ (Biểu 70)Để cơ quan những người mua dễ dàng chọn các sản phẩm và dịch vụ hỗ trợ các tiêu chu ẩn m ở, cácnhà cung cấp cần một cách thức để gắn thẻ cho từng khoản mà đối với các tiêu chu ẩn m ở đó nhàcung cấp sẽ hỗ trợ. Việc gắn thẻ cho các sản phẩm và dịch vụ này trong thị trường phần mềm làgiống hệt ý tưởng dạng “tính tương thích cài cắm” mà những người mua từ lâu đã phụ thuộc vào khimua các thành phần phần cứng.Vào năm 2005, một sự thay đổi cho chỉ dẫn trong các hợp đồng của chính phủ đã chỉ định cách màcác nhà cung cấp nên gắn thẻ vào các sản phẩm của họ sao cho nh ững ng ười mua có th ể d ễ dàngkiểm tra được các tiêu chuẩn tương hợp nào sẽ được hỗ trợ. Sự thay đổi này là trong m ột “L ưu ý đ ểchào hàng” trong một nguồn chính của các catalog sản phẩm cho các phần mềm thương m ại dùngđược ngay (off-the-shelf), “Biểu 70”.Biểu 70, được Cơ quan Dịch vụ Chung (General Services Administration) quản lý, có chứa h ơn4.000 hợp đồng được thương thảo trong năm 2004, và được tính cho khoảng 11 t ỷ USD trong bánhàng công nghệ thông tin cho chính phủ. Hơn nữa, các hợp đồng của Biểu 70 có thể đ ược s ử d ụngtrong các thực thể chính phủ bang, bộ lạc, địa phương hoặc vùng, và trong bất kỳ cơ quan giáo dụcđịa phương hoặc viện huấn luyện nâng cao nào. Thực tế này có thể rất quan trọng trong việc các h ệthống Liên bang Mỹ thường tương hợp không chỉ xuyên các cơ quan mà còn với các cấp chínhquyền khác, như, trong ngữ cảnh của Hạ tầng Dữ liệu Không gian Quốc gia.Những người chào hàng được khuyến khích xác định bên trong các khoản phần mềm của h ọ b ất kỳgiao diện thành phần nào mà chúng hỗ trợ cho tính tương hợp của các tiêu chuẩn mở. M ột giao di ệncủa các khoản có thể được xác định là có tính tương hợp được trên cơ s ở của s ự tham gia vào m ộtchương trình do cơ quan chính phủ bảo trợ hoặc trong chương trình của một t ổ ch ức đ ộc l ập. Cácgiao diện có thể được xác định bằng tham chiếu tới một giao diện được đăng ký trong kho đăng kýcác thành phần tại http://www.core.gov.A.1.2 Bộ Quốc phòngBổ sung thêm vào chỉ dẫn của Chính phủ Liên bang Mỹ, DoD đã xác định xa hơn chính sách về tiêuchuẩn. Ở đây có 7 tài liệu cung cấp các thông tin bổ sung về các tiêu chuẩn trong DoD1: 1. Kế hoạch Quản lý Chương trình các Tiêu chuẩn Công nghệ Thông tin của DoD (ITSP), ngày 19/01/2007. 2. Bản ghi của OSD: Chủ đề: Kế hoạch Quản lý Đại lý Điều hành Chương trình các Tiêu chuẩn Công nghệ Thông tin DoD, ngày 19/01/2007. 3. Bản ghi của OSD: Chủ đề: Đại lý Điều hành (EA) c ủa DoD v ề các Tiêu chu ẩn Công ngh ệ Thông tin, 21/05/2007. 4. CJCSI 6212.01D, Tính tương hợp và Tính có thể hỗ trợ được của các H ệ thống An ninh Quốc gia và Công nghệ Thông tin, ngày 08/03/2006. 5. Chỉ thị của DoD 5101.7, ngày 21/05/2004, chủ đề: Đại lý Điều hành của DoD v ề các Tiêu chuẩn Công nghệ Thông tin. 6. Chỉ lệnh của DoD 4630.8, ngày 30/06/2004, chủ đề: Các thủ tục về Tính tương hợp và Tính1 Thông tin này từ DISA GE331, ITSC Collaboration TWG.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 48/77
  • 49. 2011 - Các bài học học được về công nghệ mở có thể hỗ trợ được các Hệ thống An ninh Quốc gia và Công nghệ thông tin. 7. Chỉ thị của DoD (DoDD) 4630.05 (trước đó là 4630.5), chủ đề: Tính tương h ợp và Tính có thể hỗ trợ được các Hệ thống An ninh Quốc gia và Công nghệ Thông tin, ngày 05/05/2004.Về 7 tài liệu này, có 2 tài liệu đưa ra chi tiết nhiều nhất về kho các tiêu chu ẩn c ủa DISA (Kho đăngký Tiêu chuẩn Công nghệ Thông tin của DoD, xem chi tiết bên dưới) và sử dụng các tiêu chu ẩn b ắtbuộc là #1 và #4.5 ghi chép khác, các chỉ thị của DoD, và các chỉ lệnh của DoD là chung hơn về bản ch ất t ự nhiên,nhưng chúng cũng tham chiếu tới DISR và xác định một loạt các trách nhiệm của các thành ph ầncủa DoD trong qui trình quản lý và triển khai các tiêu chuẩn.Chỉ thị DoD 5101.7 đưa DISA thành đại lý điều hành của các tiêu chu ẩn công ngh ệ thông tin; cáctrách nhiệm của DISA là để (cùng với những trách nhiệm khác): 6.1.10 Thúc đẩy áp dụng các tiêu chuẩn được lựa chọn không phải của chính phủ (quốc gia và quốc tế) như các tiêu chuẩn Liên bang, trong sự phối hợp với Viện Quốc gia về Tiêu chuẩn và Công nghệ (NIST). Quản lý qui trình cho việc phối hợp các vị thế của DoD trong các tiêu chuẩn công nghệ thông tin với NIST và các cơ quan liên bang khác. T ạo đi ều ki ện hài hòa và tăng cường các thỏa thuận về tiêu chuẩn công nghệ thông tin và Biên b ản ghi nhớ/Biên bản thỏa thuận nhân danh DoD vì lý do về tính tương hợp các hệ thống đa qu ốc gia và giữa quốc gia với quốc gia. Khuyến khích sử dụng các khoản không phát triển, dùng ngay được của chính phủ, và các sản phẩm thương mại dùng ngay được bất kỳ ở đâu có thể tuân theo với tham chiếu (e). 6.1.11 Phát triển, với các lãnh đạo các bộ phận của DoD, các tiêu chu ẩn công ngh ệ thông tin quân sự theo hiểu biết của DISA chỉ khi mà các tiêu chuẩn không phải c ủa chính ph ủ ho ặc các tiêu chuẩn của Liên bang không đáp ứng được các yêu cầu của DoD. Đ ại lý đi ều hành của DoD về các tiêu chuẩn công nghệ thông tin sẽ tiến hành kiểm thử tính hợp lệ trong tất cả các tiêu chuẩn của Tổ chức Phát triển các Tiêu chuẩn hoặc Tổ chức Thiết lập các Tiêu chuẩn. 6.1.12 Duy trì kho Đăng ký các Tiêu chuẩn công nghệ thông tin của DoD (DISR) cấu thành từ các tiêu chuẩn công nghệ thông tin được phê chuẩn và các hồ sơ tiêu chu ẩn đ ể giúp cho những người quản lý chương trình và dự án, các nhà chức trách mua s ắm, và các nhà ki ến trúc hệ thống và kỹ thuật trong sự phát triển và lĩnh vực của các hệ thống và các s ản ph ẩm có thể tương hợp được và hướng mạng. Thiết lập qui trình và các thủ tục cho việc qu ản lý cấu hình vòng đời của các tiêu chuẩn công nghệ thông tin có chứa trong DISR. Cung cấp trực tuyến không bí mật.Kho Đăng ký Tiêu chuẩn công nghệ thông tin của DoD (DISR) được DISA duy trì hi ện là duy nh ấtsẵn sàng cho DoD và các nhân viên chính phủ; những người có th ẩm quy ền đ ể truy c ập nó có th ểxem nó tại https://disronline.disa.mil. DISR là một kho trực tuy ến cho m ột t ập h ợp t ối thi ểu các tiêuchuẩn công nghệ thông tin thương mại ban đầu (trước đó được đặt trong Kiến trúc Kỹ thuật ChungJTA (Joint Technical Architecture). Các tiêu chuẩn này được sử dụng như “vi ệc xây d ựng các mã”cho tất cả các hệ thống đang được mua sắm trong DoD. Khi xây dựng các h ệ th ống, các yêu c ầu đ ềxuất và các bình luận hợp đồng của công việc phải được rà soát lại như một phần của các qui trìnhmua sắm được phê chuẩn để đảm bảo các tiêu chuẩn công nghệ thông tin đ ược thi ết l ập trong cácTài liệu về Các khả năng Ban đầu, Các tài liệu Phát triển Các khả năng và Các tài liệu Sản xuất Cáckhả năng được dịch thành các yêu cầu rõ ràng của hợp đồng. Bổ sung thêm, các yêu c ầu đ ề xu ất vàcác tuyên bố hợp đồng của công việc nên chứa đựng các yêu cầu bổ sung cho các nhà th ầu đ ể xácđịnh những trường hợp ở những nơi mà những ảnh hưởng của chi phí, lịch trình hoặc s ự th ực thi cóVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 49/77
  • 50. 2011 - Các bài học học được về công nghệ mởthể loại trừ việc sử dụng các tiêu chuẩn công nghệ thông tin được bắt buộc trong DISR. Để đảm bảotính tương hợp giữa các hệ thống DoDD 4630.05 yêu cầu các nhà thầu s ử d ụng ch ỉ các tiêu chu ẩnđược phê chuẩn từ DISR cho các hệ thống của họ.Có một nỗ lực liên dịch vụ được gọi là NESI (Các giải pháp doanh nghiệp hướng mạng cho tínhtương hợp)2 giữa Không quân (ESC), Hải quân (PEO C4I), và Cơ quan các H ệ th ống Thông tinQuân sự (DISA). NESI đang phát triển một cơ quan về tri thức kiến trúc và kỹ thuật mà nó ch ỉ d ẫnviệc thiết kế, triển khai, duy trì, tiến hóa, và sử dụng phần công nghệ thông tin của các giải pháphướng mạng cho ứng dụng quân sự. NESI cung cấp những khuyến cáo kỹ thuật đặc biệt mà một tổchức của DoD có thể sử dụng như các tham chiếu. NESI cũng ph ục v ụ nh ư m ột t ập h ợp các thamchiếu đối với những trường hợp tuân thủ các chỉ thị.A.2 PMNMSử dụng PMNM trong Chính phủ Liên bang và DoD đặc biệt đã được đánh mã bằng các tài liệu v ềchính sách sau đây: 1. Văn phòng Quản lý và Ngân sách (OMB) M-04-16 về “Mua s ắm ph ần m ềm” (http://www.whitehouse.gov/omb/memoranda/fy04/m04-16.html). Bản ghi này đơn giản nói rằng các chính sách hiện hành của liên bang về mua sắm phần mềm áp d ụng nh ư nhau cho cả các phần mềm nguồn đóng và nguồn mở. Lưu ý rằng không có ưu tiên cho phần mềm s ở hữu độc quyền hơn PMNM. 2. “Làm sáng tỏ chỉ dẫn về PMNM” của CIO DoD tháng 10/2009 (http://cio- nii.defense.gov/docs/OpenSourceInDoD.pdf). Bản ghi chính sách này đặc biệt lưu ý rằng “Có những khía cạnh tích cực của PMNM nên được xem xét khi tiến hành nghiên cứu th ị trường về phần mềm để sử dụng trong DoD”. Nó thậm chí nói những điều kiện theo đó “những khoản phần mềm, bao gồm cả những sửa lỗi và những cải tiến của mã nguồn, được phát triển cho Chính phủ nên được đưa ra công khai (như là theo một giấy phép nguồn mở)”. Bản ghi này thay thế biên bản ghi nhớ trước đó, “PMNM trong DoD”, ngày 28/05/2003.Các tài liệu sau cung cấp chỉ dẫn thông tin về PMNM cho chính ph ủ liên bang và DoD (m ột cáchtương ứng): 1. “Các câu hỏi thường gặp về bản quyền và các vấn đề phần mềm máy tính có ảnh hưởng tới Chính phủ Mỹ với nhấn mạnh đặc biệt về PMNM” của CENDI (http://www.cendi.gov/publications/09-1FAQ_OpenSourceSoftware_FINAL_110109.pdf) 2. “Các câu hỏi thường gặp về PMNM của DoD: Các câu hỏi thường gặp về PMNM và DoD” của CIO DoD (http://cionii.defense.gov/sites/oss/Open_Source_Software_%28OSS %29_FAQ.htm).Đối với chính sách hoặc các câu hỏi pháp lý chung về PMNM trong chính phủ Mỹ, hãy tư vấn cáctài liệu chính sách và chỉ dẫn.Tất cả các tài liệu chính sách và chỉ dẫn chỉ ra rằng trong khi một s ản ph ẩm PMNM c ụ th ể có th ểcó hoặc không phù hợp cho một mục đích đặc biệt nào đó, thì chỉ là PMNM s ẽ không là v ấn đ ề gìtrong tất cả các qui định mua sắm của DoD và chính phủ liên bang M ỹ. T ất c ả các chính sách vàchỉ dẫn làm rõ ràng rằng PMNM có thể chấp nhận được để sử dụng trong các mua sắm phần mềm.Hai vấn đề có liên quan tới PMNM là đặc biệt quan trọng trong mua s ắm c ủa chính ph ủ: PMNM là2 http://nesipublic.spawar.navy.mil/docsVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 50/77
  • 51. 2011 - Các bài học học được về công nghệ mởthương mại, và PMNM là không bị cấm bởi các kiểm soát bảo hiểm thông tin trong các phần mềmmiễn phí (freeware), phần mềm chia sẻ (shareware), và/hoặc phần mềm ít có đảm bảo (warranty-less software).A.2.1 Gần như tất cả PMNM là thương mại và thương mại dùng được ngay (COTS)Gần như tất cả PMNM có sẵn một cách công khai là một “khoản thương mại” và là “COTS”.Điều này là quan trọng vì nhiều luật và qui định có những yêu c ầu có th ể áp d ụng r ộng rãi v ề cáckhoản thương mại và các khoản COTS. Ví dụ, luật M ỹ (10 USC 2377) thi ết l ập m ột “ ưu tiên chomua sắm các khoản thương mại”, và FAR yêu cầu các cơ quan chính ph ủ “(a) ti ến hành nghiên c ứuthị trường để xác định [liệu] các khoản thương mại hoặc các khoản không phát tri ển có s ẵn haykhông... (b) Mua sắm [chúng] khi .... sẵn sàng ... [và] (c) Yêu cầu các nhà thầu trước tiên và các nhàthầu phụ ở mọi lớp phải kết hợp, để tối đa hóa phạm vi có thể thực hành được, [chúng] nh ư cácthành phần... ” Một cơ quan không xem xét các lựa chọn PMNM có thể sẽ vi phạm trực tiếp các luậtvà qui định này.Đặc biệt, PMNM ít nhất có một sử dụng phi chính phủ, và đã t ừng ho ặc đang có s ẵn đ ối v ới côngchúng, theo định nghĩa là phần mềm thương mại. Nếu PMNM đã có sẵn sàng cho công chúng vàđược sử dụng không có thay đổi, thì nó thường là COTS. Có nhiều điều kiện khác để là một kho ảnthương mại hoặc COTS, và PMNM có sẵn một cách công khai có xu h ướng đáp ứng đ ược chúng.Điều này là đúng theo luật Mỹ, các qui định mua sắm Mỹ (đặc biệt Qui đ ịnh Mua s ắm Liên bangFAR và Bổ sung Qui định Mua sắm Liên bang trong Quân sự DFARS, và theo chính sách.Luật Mỹ điều tiết sự mua sắm của liên bang (Tên bộ Luật Mỹ 41, Chương 7, Ph ần 403) xác đ ịnh“khoản thương mại” khi đưa vào “Bất kỳ khoản nào, khác với sở hữu thực, mà là c ủa m ột d ạngđược công chúng nói chung hoặc các thực thể phi chính phủ sử dụng một cách thông thường chonhững mục đích khác so với các mục đích của chính phủ (như, nó có một số sử dụng phi chính phủ),và (i) Đã được bán, được thuê, hoặc được cấp phép cho công chúng nói chung; ho ặc (ii) Đã đ ượcchào bán, thuê, hoặc cấp phép cho công chúng nói chung...”. Vì thế, miễn là ph ần m ềm có ít nh ấtmột sử dụng phi chính phủ, thì phần mềm được thuê (hoặc được chào để thuê) cho công chúng làmột khoản thương mại cho các mục đích mua sắm.Tương tự, Tên Luật Mỹ 41, Chương 7, Phần 431 xác định khoản “kho ản COTS có s ẵn”; ph ần m ềmlà COST nếu nó là (a) “một khoản thương mại”, (b) được bán theo số l ượng đáng k ể trong th ịtrường thương mại, và (c) được chào cho Chính phủ, không có sửa đổi, ở dạng y hệt trong đó nóđược bán trong thị trường thương mại. Vì thế, PMNM sẵn sàng cho công chúng và được s ử dụngkhông thay đổi thường là COST.Cuối cùng, Tên Luật Mỹ 17, phần 101 xác định “lợi ích tài chính“ khi đưa vào “công thức, ho ặcmong đợi của công thức, của bất kỳ thứ gì có giá trị, bao gồm công th ức c ủa các tác ph ẩm có b ảnquyền”. Hầu hết các dự án PMNM đặc biệt được thiết lập để khuyến khích những người khác đónggóp các cải tiến (mà chúng là các công việc có bản quyền), một dạng lợi ích tài chính và vì th ế làthương mại.Những định nghĩa này trong luật của Mỹ chi phối các qui định mua sắm của Mỹ, ấy là Qui đ ịnhMua sắm Liên bang FAR và Bổ sung Qui định Mua sắm Liên bang của Quốc phòng DFARS. Ví dụ,các quyền của DFARS 252.227-7014 trong Phần mềm Máy tính Phi th ương m ại và Tài li ệu Ph ầnmềm Máy tính Phi thương mại xác định một cách tương tự “Phần mềm máy tính thương mại” như là“phần mềm được phát triển hoặc được sử dụng thường xuyên cho các mục đích phi chính ph ủ mà:Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 51/77
  • 52. 2011 - Các bài học học được về công nghệ mở(i) đã được bán, được thuê, hoặc được cấp phép cho công chúng”; (ii) Đã đ ược chào bán, thuê, ho ặccấp phép cho công chúng; (iii) Không được chào, bán, thuê, hoặc cấp phép cho công chúng nh ưnglà có sẵn cho sự bán, thuê, hoặc giấy phép thương mại đúng lúc để làm thỏa mãn các yêu cầu phânphối của hợp đồng; hoặc (iv) làm thỏa mãn một tiêu chí được thể hiện trong đo ạn (a)(1) (i), (ii),hoặc (iii) của mệnh đề này và có thể đòi hỏi chỉ sửa đổi nhỏ để đáp ứng được các yêu c ầu c ủa h ợpđồng này.Mặc dù biên bản ghi nhớ của OMB M-04-16 không nói một cách chính xác r ằng PMNM th ường làphần mềm thương mại, thì bản ghi nhớ của OMB M-03-14 “Việc gi ảm giá thành và c ải thi ện ch ấtlượng trong các mua sắm phần mềm thương mại của Liên bang” nói chính xác r ằng sáng ki ếnSmartBuy (Mua thông minh) của nó cho phần mềm thương mại đưa vào “sự hỗ trợ PMNM”. Vì thế,là sai để giả thiết rằng PMNM không phải là thương mại.Bản ghi tháng 10/2009 của DoD CIO “Việc làm sáng tỏ Chỉ dẫn về PMNM” l ưu ý chính xác r ằngtrong “hầu hết tất cả các trường hợp, PMNM đáp ứng được định nghĩa về phần mềm máy tínhthương mại và sẽ được trao sự ưu tiên phù hợp theo luật tuân thủ với 10 USC 2377 (tham chiếu (b))(cũng xem FAR 2.101(b), 12.000, 12.101 (tham chiếu (c)); và DFARS 212.212, and 252.227-7014(a)(1) (tham chiếu (d)))”.Sự hiểu lầm đã trở thành quá phổ biến rằng vào ngày 05/06/2007, Bộ H ải quân đã đ ưa ra m ột ghichép có đầu đề “Chỉ dẫn PMNM”. Ghi chép này lưu ý rằng “nh ững quan ni ệm sai v ề vi ệc li ệu cóhay không PMNM đủ tư cách như là phần mềm COTS hoặc GOTS. Vì quan niệm sai này, PMNMđã không nhận được sự xem xét bình đẳng trong qui trình mua sắm phần mềm. [Bộ Hải quân] sẽđối xử với PMNM như là COTS vì nó đáp ứng được định nghĩa của một khoản thương mại”.Việc giải thích hợp lý bổ sung vì sao PMNM là thương mại được đưa ra trong “PMTDNM là ph ầnmềm thương mại”3.A.2.2 PMNM không bị cấm vì các kiểm soát thông tin trong Freeware, Shareware và các đảm bảoCần phải xua tan một sự hiểu sai về PMNM. Cả các kiểm soát bảo hiểm thông tin IA (InformationAssurance) của Liên bang và DoD về freeware, shareware, và các phần mềm ít có đảm bảo h ơn,nhưng những kiểm soát này không áp dụng cho PMNM. Một phần của vấn đ ề này là nhi ều ng ườitham chiếu, không đúng, tới PMNM như là ‘freeware’ or ‘shareware’. Hơn nữa, nhiều người khônghiểu chính sách của Liên bang và DoD về các đảm bảo phần mềm. Kết quả là, họ tin tưởng sai rằngnhững chính sách đó cấm sử dụng PMNM.Các kiểm soát được hiểu nhầm theo cách này là: 1. Xuất bản đặc biệt của NIST 800-53, “Các kiểm soát an ninh được khuyến cáo cho các hệ thống thông tin Liên bang và các tổ chức” bản rà soát lại số 3 (http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final_updated- errata_05-01-2010.pdf), kiểm soát SA-6 biệt hiệu “Những hạn chế sử dụng phần mềm”. Tài liệu này nói: “[Một tổ chức phải cấm] sử dụng thư viện hoặc mã nguồn máy có th ể ch ạy được từ các nguồn với sự đảm bảo bị hạn chế hoặc không có và không đi kèm cùng với mã nguồn”. Chỉ dẫn bổ sung cải tiến cho kiểm soát này nói rằng: “Các s ản ph ẩm ph ần m ềm không đi kèm mã nguồn từ các nguồn với sự đảm bảo bị hạn chế hoặc không có sẽ được3 Wheeler, David A. “Free-Libre / Open Source Software (FLOSS) is Commercial Software” http://www.dwheeler.com/essays/commercial-floss.htmlVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 52/77
  • 53. 2011 - Các bài học học được về công nghệ mở đánh giá về những ảnh hưởng an ninh tiềm tàng. Sự đánh giá sẽ giải quyết thực tế rằng những dạng sản phẩm phần mềm này khó hoặc không có khả năng để rà soát lại, sửa chữa, hoặc mở rộng, biết rằng tổ chức không có sự truy cập được tới mã nguồn gốc ban đầu và không có chủ sở hữu có thể sửa chữa nhân danh của tổ chức như vậy được”. 2. Chỉ lệnh của DoD 8500.2 “Triển khai bảo hiểm thông tin (IA)” (http://www.dtic.mil/whs/directives/corres/pdf/850002p.pdf) ngày 06/02/2003, kiểm soát DCPD-1 tên hiệu “Các kiểm soát Phần mềm Miền Công cộng”. Kiểm soát này nói: “Các sản phẩm phần mềm miền công cộng có thể chạy được ở dạng nhị phân hoặc mã máy và các sản phẩm phần mềm khác với sự đảm bảo bị hạn chế hoặc không có, nh ư nh ững th ứ đ ược biết tới một cách phổ biến như là freeware hoặc shareware sẽ không được s ử dụng trong các hệ thống thông tin của DoD trừ phi chúng là cần thiết đối với sự hoàn thành nhiệm vụ và không có các giải pháp công nghệ thông tin lựa chọn thay thế nào sẵn có. Những sản phẩm như vậy sẽ được đánh giá về những ảnh hưởng về bảo hiểm thông tin, và được phê chu ẩn cho sử dụng từ DAA. Sự đánh giá sẽ giải quyết thực tế rằng những sản phẩm phần mềm như vậy là khó hoặc không có khả năng để rà soát lại, sửa, hoặc mở r ộng, bi ết r ằng Chính ph ủ không có sự truy cập tới mã nguồn gốc ban đầu và không có chủ sở hữu có thể tiến hành những sửa chữa như vậy nhân danh Chính phủ”.Nhưng đọc kỹ thì nó chỉ ra rằng những kiểm soát này không áp d ụng đ ược cho PMNM. C ả cáckiểm soát của Liên bang và DoD đều hạn chế sử dụng các phần mềm đó ở những nơi mà chính ph ủkhông thể “rà soát lại, sửa hoặc mở rộng, biết rằng Chính phủ không có s ự truy c ập t ới mã ngu ồngốc ban đầu” và có sự đảm bảo bị hạn chế. Bằng định nghĩa, chính phủ có được sự truy cập tới mãnguồn của PMNM, nên toàn bộ kiểm soát này không áp dụng được cho PMNM. M ặc dù các kho ản“freeware” và “shareware” không được xác định rõ ràng theo DCPD-1, thì hãy lưu ý r ằng văn b ảnnói rằng thực tế là chính phủ không có sự truy cập tới mã nguồn gốc ban đầu, nên vì thế PMNMkhông phải là freeware và shareware.Điều quan trọng phải hiểu kiểm soát này theo ngữ cảnh. Cả các kiểm soát v ề c ơ b ản đòi h ỏi ho ặcmã nguồn (để rà soát lại, sửa chữa, hoặc mở rộng phần mềm) hoặc một s ự đ ảm b ảo; ý t ưởng làchính phủ muốn đảm bảo rằng chính phủ có thể hoặc tự hỗ trợ phần mềm mà chính phủ cần, hoặccó khả năng để phụ thuộc vào những người khác để làm thế.Bản ghi của DoD năm 2009 về PMNM lưu ý đặc biệt trong khoản (c) rằng DCPD-1 (“Các ki ểmsoát Phần mềm Miền Công cộng”) “không nên được giải thích như là việc cấm sử dụng PMNM, vìmã nguồn là sẵn sàng cho việc rà soát lại, sửa chữa và mở rộng của chính ph ủ và các nhà th ầu c ủamình”.A.3 Văn hóa cộng tác/phân tán và các công cụ hỗ trợ trực tuyếnVề lịch sử, sự phát triển phần mềm và các hệ thống một cách cộng tác/phân tán t ừng khá là hãn h ữutrong các cộng đồng của Liên bang và DoD. Tài liệu này nhằm thay đổi điều đó. Hơn nữa, đã từngcó một số sự việc về nó, và các công cụ và các tiếp cận mà xúc tác cho nó.Hơn nữa, chính phủ Mỹ đôi khi đã trở thành có liên quan trong việc thiết lập hoặc trở thành có liênquan trong sự phát triển phân tán. Điều này một phần rõ ràng trong các d ự án PMNM. Chính ph ủđôi lúc đã thiết lập hoặc tham gia vào các dự án PMNM mà chúng đã bắt đầu hoặc đã được truy ềnvào trong các dự án của cộng đồng. Những ví dụ bao gồm Linux mong đợi và Linux được c ải ti ếnan ninh (Expect and Security-Enhanced Linux). Xem phần trước về PMNM để có thêm thông tin.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 53/77
  • 54. 2011 - Các bài học học được về công nghệ mởCác quyền dữ liệu mà chính phủ Mỹ nhận được một cách mặc định thường xúc tác cho sự phát tri ểncộng tác, thậm chí dù cơ hội này thường bị phung phí. Trong nhiều tr ường h ợp, chính ph ủ nh ậnđược các quyền không hạn chế, mà chúng xúc tác cho chính phủ thiết lập sự phát triển cộng tác v ớibất kỳ ai mà chính phủ mong muốn. Trong các trường hợp khác, chính phủ Mỹ ít nhất cũng nh ậnđược Các quyền theo Mục đích của Chính phủ GPR; chúng là đủ các quyền để xúc tác cho s ự pháttriển cộng tác của chính phủ và các nhà thầu của mình (ở mọi mức đ ộ), khi mà vi ệc s ử d ụng là vìcác mục đích của chính phủ Mỹ.Trong năm 2006 Văn phòng OA Hải quân đã thiết lập một kho phần mềm g ọi là SHARE[18] n ơimà các nhà thầu đang làm việc trong một hợp đồng của Hải quân có thể truy cập kho đ ể đ ưa lên vàduyệt mã nguồn4. Gần đây hơn, DISA đã xây dựng forge.mil (http://www.forge.mil) để xúc tác cho“sự phát triển cộng tác và sử dụng nguồn mở và các PMNM của cộng đ ồng DoD” (cái sau là nh ữnggì tài liệu này tham chiếu tới như là các phần mềm OGOTS).A.4 Tính lanh lẹ của công nghệ (Các hệ thống mở và kiến trúc mở)Quá thường thấy tất cả các phần mềm và các hệ thống trong lịch sử đã và đang đ ược phát tri ển nh ưlà những đồ nguyên khối. Những phần mềm hoặc hệ thống như vậy là khó để thay đ ổi và áp d ụngkhi công nghệ và và các nhu cầu thay đổi.Khi phần mềm đã trở thành ngày một được kết nối mạng, thì thiết k ế và các ph ương pháp lu ận k ỹthuật đã tiến bộ hướng tới các kiến trúc dựa vào dịch vụ mà chúng giao tiếp thông qua các giao di ệnmở và được tiêu chuẩn hóa. Một khi là dạng kiến trúc mở, dựa vào d ịch v ụ đ ược tri ển khai, thì h ệthống về bản chất tự nhiên phân li thành một thiết kế theo module - mỗi d ịch v ụ là t ự do đ ể c ải ti ếnvà tiến hóa một cách độc lập miễn là nó giao tiếp thông qua các giao diện tiêu chuẩn.Mấu chốt là để chia hệ thống thành các thành phần theo module, nhỏ hơn mà chúng có thể được sửdụng một cách riêng rẽ và có các giao diện tiêu chuẩn. Điều này cho phép thay đổi và thích nghiđược khi công nghệ và các nhu cầu thay đổi. Chính phủ cũng phải có các quy ền c ần thi ết đ ể thíchnghi hoặc thay thế những thành phần này và những quan hệ liên kết với nhau như cần thiết.Trong ngữ cảnh này, bất kỳ dịch vụ phần mềm nào cũng có thể được triển khai bằng COTS hoặcGOTS - triển khai tốt nhất có thể được chọn, được sửa đổi hoặc được thay th ế n ếu m ột l ựa ch ọncông nghệ tốt hơn là có sẵn. Được triển khai một cách phù hợp, các tiêu chuẩn và gi ải pháp m ở t ạora một sân chơi bình đẳng cho phép các công nghệ đằng sau tiến hóa trong khi gi ảm t ối thi ểu tínhphức tạp của các giao diện. Hơn nữa, tính module hóa đủ khả năng đối với các tiêu chuẩn và cácgiao diện mở để làm giảm rủi ro về công nghệ bằng việc hạn chế những phụ thuộc phần mềm theokiểu nối tầng (cascading), và làm giảm rủi ro về tài chính bằng việc h ạn ch ế nhu c ầu xây d ựng l ạihoặc tích hợp lại toàn bộ hệ thống khi các khả năng hoặc các yêu cầu mới nảy sinh.Chỉ thị 5000.1 của DoD (ngày 12/05/2003) đoạn E1.27 nói rằng: “Một tiếp cận các hệ thống mở,theo module sẽ được sử dụng, ở những nơi khả thi được”. Một hệ thống mở là m ột h ệ th ống “mà nósử dụng thiết kế theo module, sử dụng các tiêu chuẩn được hỗ trợ rộng rãi và dựa vào sự đồng thuậncho các giao diện chủ chốt của nó, và đã tuân thủ với sự kiểm tra tính hợp lệ và những kiểm thử tínhhợp lệ thành công để đảm bảo tính mở của các giao diện chủ yếu của nó”5.4 Xem PEO-IWS Library, Software, Hardware Asset Reuse Enterprise (SHARE), https://viewnet.nswc.navy.mil5 http://www.acq.osd.mil/osjtf/whatisos.htmlVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 54/77
  • 55. 2011 - Các bài học học được về công nghệ mởPhụ lục B: Các yêu cầu pháp lý cho PMNM đưa ra cho công chúng của chính phủ hoặc các nhà thầuPhần này tóm tắt khi chính phủ liên bang Mỹ hoặc các nhà thầu của mình có thể đưa ra công khai,như là PMNM, phần mềm được phát triển bằng tiền của chính phủ. Ph ần này đ ược mong đ ợi dànhcho những người không phải là luật sư để giúp họ hiểu được những qui định cơ bản mà h ọ ph ảituân thủ.Trước khi đi tiếp, một ít các định nghĩa và cảnh báo là cần thiết. Trong phần này, khái niệm “chínhphủ” có nghĩa là chính phủ liên bang Mỹ. “Bạn” nghĩa là tổ chức hoặc nhà thầu của chính ph ủ màmuốn đưa phần mềm ra công khai như là PMNM. “Việc đưa ra công khai như PMNM” nghĩa là: (1)đưa mã nguồn của phần mềm ra công chúng nói chung (như là thông qua m ột website công c ộng)và (2) trao cho những người sử dụng của mình sự tự do sử dụng nó (với bất kỳ m ục đích nào),nghiên cứu nó, sửa đổi nó, và phân phối lại nó (dù được sửa đổi hay không) 6. Lưu ý rằng nhữngquyền tự do này có thể có được bằng việc đưa phần mềm ra theo một giấy phép của PMNM 7, hoặcbằng việc đưa nó ra mà không có bất kỳ sự bảo vệ bản quyền nào. Hơn nữa, lưu ý r ằng vi ệc h ợpđồng của chính phủ là rất khác nhau từ các thực tiễn thương mại; đừng giả thiết rằng các th ực ti ễnthương mại áp dụng được.Để xác định liệu bạn có đưa ra cho công chúng một số phần m ềm được phát tri ển b ằng ti ền c ủachính phủ như là PMNM hay không, bạn phải trả lời các câu hỏi sau: 1. Hợp đồng nào áp dụng, những điều khoản của nó là gì, và các quyết định đã được thực hiện là gì? 2. Bạn có các quyền cần thiết có liên quan tới bản quyền hay không? 3. Bạn có các quyền trí tuệ cần thiết khác8 hay không (như, các bằng sáng chế)? 4. Bạn có được phép để đưa ra cho công chúng hay không (nh ư, ki ểm soát xu ất kh ẩu và bí mật)? 5. Bạn có các tư liệu (như, mã nguồn) và liệu tất cả các tư liệu có được đánh dấu phù hợp hay không?Từng câu trong những câu hỏi này được giải thích bên dưới, theo sau là một thảo lu ận v ề ai có th ểtiến hành những thảo luận cụ thể đó.1. Hợp đồng nào áp dụng, những điều khoản của nó là gì, và các quy ết đ ịnh đã đ ược th ựchiện là gì?Trước hết, hãy tìm hợp đồng và tìm những điều khoản nào áp dụng được, đ ặc bi ệt các m ệnh đ ề v ềquyền dữ liệu nào áp dụng được. Hầu hết các hợp đồng sử dụng một trong nh ững t ập h ợp nh ỏ các6 This is, in summarized form, the Free Software Definition (http://www.gnu.org/philosophy/free-sw.html) from the Free Software Foundation. A similar definition is in the DoD’s “Clarifying Guidance Regarding Open Source Software (OSS)” (http://cio-nii.defense.gov/sites/oss/2009OSS.pdf). A more detailed definition of OSS is the Open Source Definition (http://www.opensource.org/osd.html) from the Open Source Initiative.7 To release under an OSS license you must have the copyright-related rights (listed in 17 USC §106) to reproduce the work, to prepare derivative works, to distribute copies, and to permit others to perform those actions.8 Some lawyers use the term “intellectual property rights,” but many believe this term is misleading. Intellectual works (like software) are fundamentally different from physical property, because someone can receive an intellectual work (or rights to it) without its first possessor losing the work or their rights. The authors recommend using the term “intellectual rights” instead.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 55/77
  • 56. 2011 - Các bài học học được về công nghệ mởmệnh đề về các quyền dữ liệu tiêu chuẩn, nhưng bạn cần phải tìm ra nh ững m ệnh đ ề nào áp d ụngđược, và liệu hợp đồng có trao những sự ngoại trừ không. Nếu văn bản của mệnh đề là khó (như, cũquá) thì các mệnh đề được thảo luận ở đây, hoặc thực hiện một sự loại trừ, rồi hợp đồng đó (nếu hợppháp) sẽ chi phối. Hơn nữa, hãy xác định các quyết định các quyền dữ liệu nào đã đ ược nhân viênlàm hợp đồng thực hiện.2. Bạn có các quyền cần thiết có liên quan tới bản quyền hay không?Bảng sau đây chỉ ra những quyền mặc định có liên quan tới bản quyền cho một số hoàn c ảnhchung. Hàng đầu tiên là một trường hợp đặc biệt, nơi mà một nhân viên liên bang phát tri ển ph ầnmềm như một phần của nhiệm vụ chính thức của anh hoặc chị ta. Các hàng sau thảo luận về tácđộng thường thấy của các mệnh đề phổ biến về các quyền dữ liệu từ Qui định Mua s ắm c ủa Liênbang FAR hoặc Bổ sung FAR của DoD (DFARS) (nhưng lưu ý tới ngày tháng):Tình huống Các điều kiện khác Trườ Liệu chính phủ có đưa ra được như là Liệu nhà (nếu có) ng PMNM? thầu có đưa hợp ra được như là PMNM?Nhân viên của Chính phủ liên bang Mỹ A Có hiệu quả, được. Phần mềm không Chưa có(bao gồm các nhân viên quân sự) phát phải tuân thủ bản vệ bản quyền theotriển phần mềm như một phần của nghĩa U.S. per 17, USC §105, nên có thể đọc,vụ chính thức của anh/chị ta. Điều này sử dụng, sửa đổi, và phân phối lại nó.nghĩa là “Công việc của chính phủ Mỹ”. Chính phủ có thể áp dụng bản quyền bên ngoài nước Mỹ, nhưng vẫn đưa phần mềm ra như là PMNM.Các mặc định Chính phủ đã không trao B Được. Chính phủ thường có các quyền Không. Nhàmệnh đề của cho nhà thầu quyền đòi không hạn chế (đặc biệt các quyền y hệt thầu có thểhợp đồng theo bản quyền (mặc định). như một người giữ bản quyền) theo (b) yêu cầu quyềnFAR 52.227- (1). Trong FAR mã nguồn là phần mềm, để đòi bản14 (tháng 12 và phần mềm là dữ liệu, nên mã nguồn quyền.năm 2007), là dữ liệu.phần mềm Chính phủ đã trao cho C Không. Chính phủ không có đủ các Được. Nhàtrước hết được nhà thầu quyền đòi bản quyền, theo (c)(1)(iii); nó không thể thầu có thể đòisản xuất theo quyền (như, thông qua phân phối các bản sao cho công chúng. bản quyền.thực hiện hợp quyền đặc biệt được viết Chính phủ nên cẩn trọng trao một yêuđồng. thành văn bản hoặc qua cầu để đòi bản quyền, vì chính phủ vĩnh mệnh đề lựa chọn IV). viễn mất nhiều quyền đối với dữ liệu đã trả tiền để phát triển.Các mặc định Được phát triển hoàn D Được. Chính phủ có các quyền không Được. Bảncủa mệnh đề toàn bằng tiền của chính hạn chế (đặc biệt các quyền y như là một quyền đượchợp đồng theo phủ. người giữ bản quyền). Theo (b)(2)(ii), nhà thầu/nhàDFARS giai đoạn 5 năm từ khi cấp vốn pha trộn cung cấp giữ. Được phát triển bằng E252.227- có thể thương thảo cho một khoảng thời tiền pha trộn (chính phủ7014 gian khác, và nó bắt đầu “dựa vào sự trả một phần cho sự phát(Tháng 6 năm thực hiện hợp đồng, hợp đồng phụ, hợp triển phần mềm) và sự1995) đồng văn bản (hoặc công cụ hợp đồng thực hiện/sửa đổi hợp tương tự), sửa đổi hợp đồng, hoặc thực đồng (phụ) hơn 5 năm thi lựa chọn mà sự phát triển phần mềm trước. máy tính là theo yêu cầu”.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 56/77
  • 57. 2011 - Các bài học học được về công nghệ mởTình huống Các điều kiện khác Trườ Liệu chính phủ có đưa ra được như là Liệu nhà (nếu có) ng PMNM? thầu có đưa hợp ra được như là PMNM? Được phát triển bằng F Không. Chính phủ không có đủ các tiền pha trộn (chính phủ quyền. Theo (b)(2)(ii), giai đoạn 5 năm chi một phần để phát từ khi cấp vốn chung có thể thỏa thuận triển) và sự thực hiện/sửa một giai đoạn thời gian khác; trong thời đổi hợp đồng (phụ) hơn gian này chính phủ chỉ có “các quyền 5 năm trước. theo mục đích của chính phủ”. Nếu phần mềm được phát triển hoàn toàn bằng tiền Được phát triển hoàn G tư nhân, thì mặc định chính phủ chỉ có toàn bằng tiền tư nhân. “các quyền hạn chế”; chính phủ nên thận trọng đối với những lệ thuộc vào các thành phần như vậy. Chính phủ có thể thương thảo để có các quyền nhiều hơn theo (b)(3) and (b)(4).Các mặc định Không Ít hơn 5 năm sau H Không. Chính phủ không có đủ các Được. Nhàcủa mệnh đề được khi kết thúc dự quyền, theo (b)(4)(i). thầu có bảnhợp đồng theo phát án quyền.DFARS triển Hơn 5 năm sau I Được. Chính phủ có các quyền không252.227- hoàn khi kết thúc dự hạn chế (đặc biệt các quyền y hệt như7018 toàn án và lựa chọn I một người giữ bản quyền) theo (b)(1)(Tháng 06 năm bằng sẽ không được (vi). Đáng tiếc, đôi khi khó xác định khi1995): tiền tư sử dụng. nào thì giai đoạn thời gian này sẽ hếtChương trình nhân hạn.nghiên cứu đổimới sàng tạo Hơn 5 năm sau J Đôi khi được. Theo lựa chọn I thì Chínhcho các doanh khi kết thúc dự phủ không thể thực hiện được các quyềnnghiệp nhỏ án và lựa chọn I của mình để đưa ra nếu, trong giới hạn(SBIR). sử dụng được. thời gian nhất định nào đó, phần mềm được xuất bản và nhân viên làm hợp đồng được nhắc. Giới hạn này sẽ tiếp tục miễn là nó sẵn sàng một cách hợp lý đối với nhà nước để mua sắm (sau đó chính phủ có thể đưa nó ra như PMNM). Xem lựa chọn I để có các chi tiết. Được phát triển hoàn K Không. Chính phủ không có đủ các toàn bằng chi phí của tư quyền, theo (b)(2). nhân.Các mặc định Chính phủ đã không trao L Được, hoặc thông qua các quyền không Không. Nhàcủa mệnh đề cho nhà thầu quyền để hạn chế hoặc bằng việc giữ bản quyền. thầu khônghợp đồng “Các đòi bản quyền (mặc Mặc định, chính phủ có các quyền thể đòi cáccông việc đặc định), và phần mềm lần không hạn chế trong tất cả các dữ liệu quyền bảnbiệt” theo FAR đầu đã được làm ra theo được phân phối theo hợp đồng, và trong quyền theo (c)52.227- sự thực thi của hợp đồng. tất cả các dữ liệu lần đầu được sản xuất (1)(i). Nhà17 (Tháng 12 theo sự thực thi của hợp đồng, theo (b) thầu có thểnăm 2007) (1)(i). Theo (c)(ii), nếu nhà thầu không yêu cầu quyền được trao quyền để đòi các quyền bản để đòi bảnVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 57/77
  • 58. 2011 - Các bài học học được về công nghệ mởTình huống Các điều kiện khác Trườ Liệu chính phủ có đưa ra được như là Liệu nhà (nếu có) ng PMNM? thầu có đưa hợp ra được như là PMNM? quyền, thì nhân viên làm hợp đồng có quyền; nếu thể chỉ tới nhà thầu để chỉ định bản được trao thì quyền cho chính phủ. xem bên dưới. Chính phủ đã trao cho M Không. Chính phủ chỉ có các quyền hạn Được. Nhà nhà thầu quyền đòi bản chế hơn được liệt kê ở cuối của (c)(1)(i), thầu có bản quyền, và phần mềm lần và những quyền này bị hạn chế đối với quyền. đầu tiên được làm ra những sử dụng “bởi hoặc nhân danh của theo sự thực hiện hợp Chính phủ”. đồng Phần mềm lần đầu N Còn tùy. Lưu ý là một nhà thầu không Còn tùy. không được làm ra theo thể đưa phần mềm có bản quyền vào sự thực hiện của hợp trong một phân phối mà không có quyền đồng. bằng văn bản của nhân viên làm hợp đồng, xem (c)(2) để biết thêm.Các mặc định Công việc lần đầu được O Được. Chính phủ nhận được bản quyền, Không. Chínhcủa mệnh đề làm ra, được tạo ra, hoặc theo (c)(2). phủ có bảnhợp đồng “Các được sinh ra và được yêu quyền.công việc đặc cầu sẽ phải phân phốibiệt” theo theo hợp đồng.DFARS Các công việc khác có P Thường là được. Theo (c)(3) và (d), Thường là252.227- bản quyền được kết hợp nhà thầu thường phải trao cho chính phủ được. Nhà7020 (Tháng vào một phân phối theo một danh sách dài các quyền dữ liệu khi thầu phải có06 năm 1995). yêu cầu (trừ phi có sự kết hợp với các công việc có bản quyền các quyền đưa phê chuẩn bằng văn bản khác, và những quyền này cho phép đưa ra PMNM rồi được trao vì sự ngoại lệ). ra PMNM. Nhà thầu chỉ có thể kết hợp để kết hợp nó, phần mềm không có các quyền đó vào trừ phi đưa ra một phân phối nếu nhân viên làm hợp được sự phê đồng của chính phủ trao sự phê chuẩn chuẩn bằng bằng văn bản, theo (d). văn bản.Có những qui định chung, nhưng bạn phải kiểm tra các tình huống cụ thể của bạn để xác định chínhxác bạn cần phải làm gì. Có những chi tiết trong các mệnh đề của FAR và DFARS không được nhấnmạnh ở đây, và hợp đồng có thể thay đổi từ những mặc định cho tới thứ gì đó rất khác biệt. Một sốhợp đồng sẽ sử dụng các phiên bản khác nhau của các mệnh đề của FAR và DFARS, nên hãy ki ểmtra để xem liệu có bất kỳ sự khác biệt nào không. Lưu ý là một số cơ quan khác (như NASA) có cácbổ sung đối với FAR, mà chúng sẽ không được đưa ra ở đây.Bảng ở trên chỉ áp dụng cho phần mềm mà chúng từng hoặc: (1) được một nhân viên chính ph ủphát triển như một phần nhiệm vụ chính thức của anh hoặc chị ta hoặc (2) một nhà th ầu phát tri ển(trực tiếp hoặc gián tiếp) như một phần của một hợp đồng của chính ph ủ. Ph ần m ềm nh ư v ậy có th ểbao gồm hoặc phụ thuộc vào các phần mềm khác, như các phần mềm thương mại, mà chúng khôngđáp ứng được các tiêu chí này. Khi một hệ thống có các phần mềm th ương m ại, thì gi ấy phépthương mại áp dụng cho các thành phần đó, và mọi người phải tuân thủ với các điều khoản của giấyphép của chúng. Phần mềm thương mại bao gồm bất kỳ phần mềm nào được sử dụng cho ít nhấtVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 58/77
  • 59. 2011 - Các bài học học được về công nghệ mởmột sự sử dụng phi chính phủ và từng được bán, được thuê, hoặc được cấp phép cho công chúng nóichung (theo 41 USC §403 và DFARS 252.227-7014(a)(1)), vì thế gần nh ư t ất c ả các PMNM có s ẵnmột cách công khai là các phần mềm thương mại. Phần mềm thương mại với những sửa đổi nhỏ vẫnđược xem là các phần mềm thương mại.Trong nhiều trường hợp nhà thầu nhận được bản quyền. Khi có nhiều nhà th ầu ho ặc nhà cung c ấp(như, một nhà tích hợp hàng đầu và các nhà thầu phụ), thì các dàn xếp pháp lý gi ữa các t ổ ch ức xácđịnh các nhà thầu/nhà cung cấp nào sẽ được phép một cách hợp pháp để đòi bản quyền. Các nhàthầu dẫn dắt không nhất thiết nhận các bản quyền từ các nhà thầu phụ và các nhà cung cấp c ủa h ọ.Lưu ý rằng chính phủ có thể nhận được và giữ các bản quyền được truy ền cho chính ph ủ, theo 17USC §105.Trong nhiều trường hợp chính phủ không phải là người nắm giữ bản quyền nhưng có các quy ềnkhông hạn chế (xem các hàng B, D, E và I). Nếu chính phủ có các quyền không hạn chế, thì về cơbản chính phủ có các quyền y như một người giữ bản quyền vì những mục đích đ ưa ph ần m ềm ranhư PMNM9. Vì thế, chính phủ có thể đưa phần mềm đó ra theo bất kỳ giấy phép PMNM nào màchính phủ chọn, bao gồm cả Giấy phép Công cộng Chung GNU (GPL - GNU General PublicLicense) và Lesser GPL (LGPL)10. Khi chính phủ có các quyền không hạn chế nhưng không phải làngười giữ bản quyền, thì có một ít các hành động chính phủ không th ể th ực hi ện, nh ư, quy ền truy ềnhoặc chỉ định các quyền, và đứng khởi kiện tại tòa về vi phạm bản quyền 11. Tuy nhiên, vì những lýdo ở đây thì chúng là các chi tiết kỹ thuật; điểm chính là chính phủ có thể đưa phần mềm ra nhưPMNM, theo bất kỳ giấy phép PMNM nào mà chính phủ chọn, một khi chính ph ủ nh ận đ ược cácquyền không hạn chế.Chính phủ nên cực kỳ cẩn thận về việc nhận ít hơn các quyền không hạn chế đối v ới ph ần m ềmhoặc các hệ thống mà chính phủ đã chi tiền để phát triển. Ví dụ, một s ố nhà th ầu s ẽ c ố tình nhúngcác thành phần mà họ có sự kiểm soát hoàn toàn đối với chúng, và sau đó thiết kế phần còn lại củahệ thống để phụ thuộc vào các thành phần đó. Khi chính phủ có ít hơn các quyền không hạn chế, thìchính phủ có rủi ro tạo ra một sự phụ thuộc vào một nhà thầu, biến sự cạnh tranh đ ối v ới h ệ th ống9 The Council on Governmental Relations (CAGR)’s “Technical Data and Computer Software: A Guide to Rights and Responsibilities Under Federal Contracts, Grants and Cooperative Agreements” states that “This unlimited license enables the government to act on its own behalf and to authorize others to do the same things that it can do, thus giving the government essentially the same rights as the copyright owner.”10 CENDI’s “Frequently Asked Questions about Copyright and Computer Software” at http://cendi.gov/publications/09-1FAQ_OpenSourceSoftware_FINAL_110109.pdf question 4.3 says: “an agency may distribute software created by a vendor to all users under an open source licensing scheme if it acquired sufficient rights from the vendor to do so in the software. For example, an “unlimited rights license” acquired under a DFARS procurement-type contract...” Similarly, the “DoD Open Source Software (OSS) FAQ” says that once the government has unlimited rights, it can “use those rights to release that software under a variety of conditions (including an open source software license), because it has the use and modify the software at will, and has the right to authorize others to do so.”11 The government can probably take other measures against someone who does not comply with the license, though. For example, the government may be able to sue for breach of license. Also, an infringer may lose any ability to enforce rights over the resulting work in U.S. court due to the doctrine of unclean hands.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 59/77
  • 60. 2011 - Các bài học học được về công nghệ mởđó trở nên vô nghĩa12 và trong một số trường hợp đặt khả năng quân sự vào rủi ro.13 14Một số người đã hiểu sai luật và chính sách của Mỹ như việc yêu cầu chính phủ chấp nhận một cáchdại dột những đề xuất mà chúng trao ít hơn các quyền không hạn chế đối với các hệ thống được pháttriển dù chính phủ cấp tiền. Đúng là 10 U.S.C. §2320(a)(2)(F) nói rằng “một nhà thầu hoặc nhà thầuphụ (hoặc một nhà thầu hoặc nhà thầu phụ tương lai) có thể không được yêu c ầu, nh ư m ột đi ều ki ệncó trách nhiệm đối với một sự nài xin hoặc như một điều kiện để được trao hợp đồng, để ... bán hoặcnếu không sẽ từ bỏ bất kỳ các quyền nào đối với Mỹ trong các dữ li ệu kỹ thuật [ngo ại tr ừ trongnhững trường hợp nhất định, và có thể không được yêu cầu để] kìm lại không chào để sử dụng, hoặckhông sử dụng, một khoản hoặc qui trình đối với nó thì nhà thầu được trao quy ền đ ể h ạn ch ế cácquyền trong dữ liệu”15. Tuy nhiên, đây không phải là tất cả câu chuyện. “Nếu Chính phủ đã yêu cầumột cách phù hợp các dữ liệu hoặc phần mềm một cách khẩn khoản, thì nó đ ược cho quy ền đ ối v ớimột số quyền nhất định nào đó phù hợp với chế độ và một lời chào không đưa ra ít nhất các quyềnmà có thể được nắm không thể chấp nhận được”. Hơn nữa, chính phủ có thể (và nên) đánh giá cácđề xuất “trên cơ sở các quyền dữ liệu và đưa ra những mức cao hơn đối với nh ững ng ười chào hàngcó thiện chí cung cấp nhiều hơn các quyền tối thiểu trần trụi”16.Theo nhiều mệnh đề của FAR (nhưng không phải của DFARS), n ếu chính ph ủ đ ồng ý cho phép cácnhà thầu đòi bản quyền, thì chính phủ sẽ đánh mất nhiều quyền của mình, vĩnh viễn, đ ối v ới ph ầnmềm mà chính phủ đã trả tiền để phát triển (xem các hàng B, C, L, và M). S ự mất các quy ền này cóthể hoàn toàn bất lợi cho chính phủ. Hơn nữa, nó tạo ra một quyết định khó khăn cho một nhân viênlàm hợp đồng để làm, vì nhân viên làm hợp đồng phải thấy tr ước đ ược t ất c ả nh ững s ử d ụng có kh ảnăng trong tương lai để đưa ra một quyết định tốt (thứ gì đó mà là khó khăn trong thực tiễn). M ệnhđề thông thường của DFARS (252.227-7014) tránh vấn đề này; trong mệnh đề này, thường thì chínhphủ sẽ kết thúc bằng các quyền không hạn chế đối với phần mềm mà chính phủ đã trả tiền để pháttriển (trong một số trường hợp sau một sự trì hoãn), và nhà thầu có bản quyền, xúc tác cho các bênđể tiến hành các hành động như là đưa phần mềm ra thành PMNM.Đây là một số lưu ý về các mệnh đề đặc biệt: • Theo FAR 52.227-14 (các hàng B và C), chính phủ có thể trao cho một nhà thầu quy ền đòi bản quyền, trong đó chỉ cho nhà thầu giành các quyền nhưng chính phủ vĩnh vi ễn m ất các quyền. Theo FAR 27.404-3(a)(2), chính phủ nên trao yêu cầu này chỉ “khi nào [điều đó] s ẽ12 Ashton B. Carter, “Memorandum to Acquisition Professionals Subject: Better Buying Power: Mandate for Restoring Affordability and Productivity in Defense Spending” https://dap.dau.mil/policy/Documents/Policy/Carter%20Memo %20on%20Defense%20Spending%2028%20Jun%202010.pdf - His first point on providing incentives is to “Avoid directed buys and other substitutes for real competition. Use technical data packages and open systems architectures to support a continuous competitive environment.”13 GAO GAO-06-839 “WEAPONS ACQUISITION: DOD Should Strengthen Policies for Assessing Technical Data Needs to Support Weapon Systems” (July 2006) http://www.gao.gov/new.items/d06839.pdf reported that “The lack of technical data rights has limited the services’ flexibility to make changes to sustainment plans that are aimed at achieving cost savings and meeting legislative requirements regarding depot maintenance capabilities... Unless DOD assesses and secures its rights for the use of technical data early in the weapon system acquisition process when it has the greatest leverage to negotiate, DOD may face later challenges in sustaining weapon systems over their life cycle.”14 See, for example, “Fire support’s dependence on contractors,” Sgt Timothy Caucutt, http://www.mcamarines.org/gazette/article/paying-pirates15 This U.S. law does not cover software, but the DoD also applies this to software per DFARS 227.7203-1(c) and (d).16 George O. Winborne, Jr., “Who’s Killing the Goose?” American Bar Association Section of Public Contract Law Program Intellectual Property in Government Contracts—What You Didn‘t Learn in Kindergarten, November 11-12, 2010, Seaport Hotel, Boston, Massachusetts. https://acc.dau.mil/adl/en- US/401584/file/54029/Winborne_ABAPCL_paper_Who27s_Killing_the_Goose_For%20_Release.pdfVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 60/77
  • 61. 2011 - Các bài học học được về công nghệ mở cải thiện được sự phổ biến hoặc sử dụng phù hợp”. Các quan chức chính phủ nên không trao điều này một cách tự động, khi làm như vậy sẽ làm giảm đột ngột các quyền của chính phủ đối với các phần mềm mà chính phủ đã trả tiền để phát triển. Chính phủ có thể chọn trao quyền này với điều kiện rằng phần mềm sẽ được đưa ra ngay lập tức cho công chúng theo một số giấy phép cụ thể nào đó của PMNM (với giấy phép được đồng ý trên phần điều ki ện cho việc đưa ra). Trong trường hợp như vậy, sự tung ra công khai như PMNM có thể được sử dụng như một phương pháp để cải thiện sự phổ biến và sử dụng. Những phân phối có thể bao gồm các dữ liệu không phải lần đầu được sản xuất theo sự th ực hi ện c ủa h ợp đ ồng, theo (c)(2), nhưng trong trường hợp này không rõ đối với tác giả này nếu chính ph ủ có th ể đ ưa phần mềm ra như PMNM. • Theo DFARS 252.227-7014 (các hàng D-G), nhà thầu thường có b ản quy ền. Chính ph ủ có các quyền y như vậy như là một người giữ bản quyền (thông qua các quyền không hạn chế) nếu (1) phần mềm đã được phát triển chỉ bằng tiền của chính phủ hoặc (2) việc cấp tiền đã là pha trộn và 5 năm đã đi qua sau khi hợp đồng thích hợp hoặc sửa đổi hợp đồng mà chúng đã gây ra cho sự phát triển của nó đã được ký. Chính phủ nên nhận thức được về những tình huống ở đó những ý định của nhà thầu đưa ra phần mềm mà nó ph ụ thu ộc m ột cách vô cùng vào một số thành phần mà họ đã phát triển hoàn toàn bằng tiền tư nhân. S ự ph ụ thu ộc nh ư vậy có thể sẽ cấm bất kỳ sự cạnh tranh để duy trì nào trong t ương lai, vì m ặc đ ịnh chính ph ủ chỉ có các quyền hạn chế đối với những thành phần như vậy. • Theo DFARS 252.227-7018 (các hàng H-J), chính phủ thường có các quyền không hạn chế đối với phần mềm được phát triển không hoàn toàn bằng tiền của tư nhân, nh ưng ch ỉ sau 5 năm sau khi dự án đã hoàn thành (lưu ý rằng đây là một th ời đi ểm kh ởi đ ầu khác so v ới DFARS 252.227-7014). Sự sửa đổi cho tốt hơn I có thể loại bỏ quy ền này mi ễn là s ản ph ẩm là “sẵn sàng một cách hợp lý cho công chúng để mua”. • FAR 52.227-17 (các hàng L-N) là, theo FAR 27.409(e), để được sử dụng đối với phần mềm cho việc “sử dụng nội bộ của chính phủ” hoặc ở những nơi “có một nhu cầu hạn chế sự phân phối” hoặc để “có được tiền bồi thường trách nhiệm”. Tuy nhiên, các mục đích thay đ ổi; phần mềm được phát triển ban đầu cho “sử dụng nội bộ của chính phủ” có th ể tr ở thành phần mềm mà nên được đưa ra một cách công khai như là PMNM. Tài li ệu này mô t ả m ột cách đơn giản những gì được phép, hơn là những mong đợi của các tác giả hợp đồng gốc ban đầu. • DFARS 252.227-7020 (các hàng O-P, mệnh đề công việc đặc biệt) được thảo luận trong DFARS 227.7106. Thảo luận đó không đặc biệt nhắc tới phần mềm, nhưng mệnh đ ề c ủa -7020 có thể được sử dụng cho phần mềm. DFARS 2277106(2) nói nó có thể được sử dụng cho “một công việc” và không chỉ bị hạn chế cho “các dữ liệu kỹ thuật”. Mệnh đề này nên được sử dụng nếu chính phủ phải sở hữu hoặc kiểm soát bản quy ền. Ví dụ có thể là phù hợp nếu chính phủ mong muốn đưa ra một cách công khai PMNM và có khả năng để (1) tăng cường một cách trực tiếp bản quyền tại tòa án, và/hoặc (2) đưa ra sự bồi thường.3. Bạn có các quyền trí tuệ cần thiết khác hay không (như, các bằng sáng chế)?Bạn cần chắc chắn rằng bạn có bất kỳ các quyền trí tuệ cần thiết khác. Quan trọng nhất, hãy xácđịnh nếu có bất kỳ các bằng sáng chế nào phù hợp, và nếu có, thì các quyền cho chúng là gì.Các vấn đề tiềm tàng khác là thương hiệu, các dấu của chính phủ, và các bí mật th ương m ại. Cácvấn đề thương hiệu, nếu phù hợp, thường có thể dễ dàng được giải quyết bằng việc loại bỏ một cáchđơn giản dấu thương hiệu đó. Nếu nhà thầu đã trao bản quyền hoặc các quyền hạn chế cho côngVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 61/77
  • 62. 2011 - Các bài học học được về công nghệ mởchúng và vì thế không bị cản trở đối với việc tung ra không khai bởi luật bí mật thương mại.4. Bạn có được phép để đưa ra cho công chúng hay không (nh ư, ki ểm soát xu ất kh ẩu và bímật)?Đặc biệt, đối với việc tung ra công khai thì tư liệu phải không bị hạn chế bởi: • Đặc tả. Các dữ liệu đặc tả có thể không được tung ra một cách h ợp pháp cho công chúng. Ở những nơi mà điều này là không rõ ràng, thì một sự rà soát lại đặc tả có thể được yêu cầu. • Các tuyên bố phân phối. Một nhân viên làm hợp đồng của chính phủ có thể đòi hỏi các mệnh đề chắc chắn nào đó được đưa vào trong dữ liệu (bao gồm phần mềm) để h ạn ch ế s ự tung ra của nó; các nhà thầu phải tuân theo những mệnh đề này hoặc sẽ làm cho chúng b ị hủy bỏ. • Các kiểm soát xuất khẩu. Các qui định hành chính về xuất khẩu EAR (Export Administration Regulations) được Bộ Thương mại đưa ra, và ITAR (International Traffic in Arms Regulations) sẽ được Bộ Ngoại giao đưa ra. Sự cấm xuất khẩu không có phép các công nghệ cụ thể nào đó vì những lý do an ninh quốc gia hoặc bảo vệ thương mại. Lưu ý rằng mật mã có thể viện dẫn như các vấn đề kiểm soát xuất khẩu.Các kiểm soát xuất khẩu có thể đặc biệt khó hiểu, và bị phạt vì không tuân thủ với chúng có th ể làngặt nghèo (bao gồm cả những chi phí lớn và ngồi tù). Vì thế, d ưới đây là m ột s ố đi ều c ơ b ản v ềkiểm soát xuất khẩu: • Nhiều thông tin hơn về những qui định kiểm soát xuất khẩu theo EAR được Văn phòng Công nghiệp và An ninh (BIS) của Bộ Thương mại đưa ra (http://www.bis.doc.gov/licensing/). Đặc biệt, hãy xem các trang của họ về “Những điều cơ bản về kiểm soát xuất khẩu” và “Chỉ dẫn cấp phép”. Bất kỳ khoản nào (bao g ồm c ả ph ần mềm) được gửi từ Mỹ cho một đích nước ngoài, bao gồm bất kỳ nước ngoài nào, là một s ự xuất khẩu - thậm chí nếu khoản đó ban đầu tới từ bên ngoài nước Mỹ. Những xuất khẩu/xuất khẩu lại nào đó của Mỹ đòi hỏi một giấy phép từ BIS. Mấu chốt là phải biết li ệu kho ản mà bạn đang định xuất khẩu có một con số bí mật kiểm soát xuất khẩu ECCN (Export Control Classification Number) đặc biệt nào không như được liệt kê trong danh sách kiểm soát thương mại CCL (Commerce Control List), có sẵn trên website của EAR. Hơn nữa, một giấy phép được yêu cầu cho gần như tất cả sự xuất khẩu và nhiều sự xuất khẩu lại b ị c ấm v ận t ới những địa điểm và quốc gia đích được xem như là việc hỗ trợ cho các hoạt động khủng bố. • Tương tự, nhiều thông tin hơn về những qui định kiểm soát xuất khẩu theo ITAR, mà chúng bổ sung cho Luật Kiểm soát Xuất khẩu Quân sự AECA (Arms Export Control Act), đ ược Ban lãnh đạo các kiểm soát thương mại quốc phòng DDTC (Directorate of Defense Trade Controls) của Bộ Ngoại giao Mỹ (http://www.pmddtc.state.gov). Đặc biệt, hãy xem trang “Làm quen” (Getting Started) của họ. Mỹ qui định những xuất khẩu và xu ất kh ẩu l ại các khoản quân sự và công nghệ, nên nếu những gì bạn muốn xuất khẩu đ ược đ ề c ập t ới trong Danh sách Cung cấp đạn dược của Mỹ USML (U.S. Munitions List), thì một giấy phép từ DDTC được yêu cầu. Bạn có thể đệ trình một yêu cầu quyền hạn CJ (Juridiction Request) cho hàng hóa để xác định liệu một khoản hoặc dịch vụ được đề cập tới t ừ USML và vì th ế phải tuân thủ các kiểm soát xuất khẩu có liên quan tới AECA và ITAR hay không.DoD không có quyền trao các giấy phép kiểm soát xuất khẩu. Một nhà thầu có thể sẽ chịu tráchnhiệm nếu anh hoặc chị ta dựa vào một sự cho phép chính thức của DoD đối với kiểm soát xu ấtkhẩu, vì trong hầu hết các trường hợp thì DoD không có quyền năng này. L ưu ý là th ậm chí khi m ộtVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 62/77
  • 63. 2011 - Các bài học học được về công nghệ mởgiấy phép kiểm soát xuất khẩu về phần mềm được trao, thì thường ng ẫu nhiên không đ ưa ra mãnguồn, làm cho “những phiên bản” như vậy là vô dụng cho OTD đối với các bên tham gia.Tuy nhiên, nếu DoD xác định rằng thứ gì đó DoD có tầm ảnh hưởng sẽ có thể tung ra được chocông chúng, thì nó không còn phải tuân thủ theo kiểm soát xu ất kh ẩu n ữa . Điều này là vì 15C.F.R. 734.3(b)(3) nói rằng: “Những khoản sau đây không phải tuân thủ theo EAR... Công ngh ệ vàphần mềm có sẵn một cách công khai ...” Tương tự, 22 CFR 125.4 (13) lưu ý r ằng các d ữ li ệu k ỹthuật là được miễn khỏi các kiểm soát xuất khẩu ITAR nếu nó là “được ch ấp nh ận cho tung ra côngkhai (như, sự phân phối không hạn chế) biết rõ đối với bộ hoặc cơ quan chính phủ Mỹ hoặc Vănphòng về Tự do Thông tin và Rà soát lại về An ninh”. Vì thế, nếu phần mềm có dự định sẽ đượctung ra công khai, thì có sự biết rõ rồi của bộ ho ặc c ơ quan chính ph ủ M ỹ (nh ư DoD) ch ấpthuận sự tung ra công khai của nó thường là cách t ốt nh ất đ ể tuân th ủ hoàn toàn v ới nh ữngqui định về kiểm soát xuất khẩu.5. Bạn có các tư liệu (như, mã nguồn) và li ệu tất cả các t ư li ệu có đ ược đánh d ấu phù h ợp haykhông?Chính phủ và các nhà thầu các lớp ở trên nên đảm bảo rằng h ọ nh ận đ ược tất cả tư liệu, bao gồmmã nguồn, mà họ được quyền đối với chúng. Cũng rất phổ bi ến là để có quy ền đ ối v ới mã ngu ồnhoặc các tư liệu liên quan, vẫn không có được nó và vì thế không có kh ả năng th ực hi ện đ ược cácquyền của bạn. Mã nguồn là cần thiết cho phiên bản PMNM tiềm năng, và nó cũng là c ần thi ết đ ểxúc tác cho sự cạnh tranh cần thiết cho các vụ thầu duy trì phần mềm trong t ương lai. C ả chính ph ủvà các nhà thầu nên chắc chắn rằng họ không đánh mất mã nguồn, mà thay vào đó đ ối x ử v ới mãnguồn như là những dữ liệu có giá trị (như, bằng việc tạo ra nhiều bản sao sao lưu tại nhiều ch ỗkhác nhau).Theo DFARS 252.227-7014, định nghĩa về “phần mềm máy tính” bao gồm không ch ỉ “các chươngtrình máy tính”, mà còn cả “mã nguồn, các liệt kê mã nguồn... và tư liệu liên quan mà chúng có th ểxúc tác cho phần mềm sẽ được sản xuất lại, tái tạo lại, hoặc biên d ịch l ại”. Vì th ế, m ột s ự phân ph ốicủa phần mềm được phát triển sẽ được cho là sẽ đưa vào mã nguồn một cách mặc định. Hơn nữa,(b)(1)(i) and (b)(2)(i) nói rằng chính phủ có các quyền đối với phần mềm (bất k ể là nó t ừng đ ượctung ra hay không) nếu nó sử dụng tiền của chính phủ.Mã nguồn chỉ nên được chấp nhận nếu sẵn sàng để sử dụng. Tư liệu chỉ nên đ ược xem xét có th ểchấp nhận được như mã nguồn nếu nó là dạng công việc được ưa thích cho việc tiến hành những sửađổi đối với nó. Mã nguồn nên không được chấp nhận nếu nó chỉ là một bản in ra hoặc các hình ảnhđiện tử của một bản in ra. Nó nên không được chấp nhận trừ phi nó là dễ dàng đ ể xây d ựng l ại m ộtcách tự động, như, một lệnh “make” hoặc lệnh đơn giản tương tự là đủ để tạo lại một bản có thểchạy được. Tài liệu được xây dựng nên được đưa vào với bất kỳ thông tin nào có th ể ph ổ bi ến đ ược,bao gồm cả các thông tin về những gì cần thiết để xây dựng lại nó.Có lẽ tốt nhất nếu mã nguồn cũng được đưa vào cả ghi chép lịch sử (như, chi chép đầy đ ủ v ề t ừngthay đổi, ai đã thực hiện nó, và khi nào), ở một dạng điện tử phù h ợp cho vi ệc truy ền t ới h ệ th ốngquản lý cấu hình khác. Lý tưởng mà nói, chính phủ nên có đ ủ s ự truy c ập t ới môi tr ường k ỹ thu ậtphần mềm SEE (software engineering environment) của nhà thầu, sao cho chính phủ có thể giámsát được những thay đổi mà chúng được thực hiện.Hãy đảm bảo rằng mã nguồn và các tư liệu khác được ghi nhãn một cách phù hợp. Các công ty cóthể đưa vào các ghi nhãn hạn chế về các tư liệu, và nếu những ghi nhãn này là không phù h ợp, thìsau đó những ghi nhãn đó cần phải được sửa. Các mệnh đề hợp đồng bao gồm các quá trình choviệc sửa các ghi nhãn không đúng; hãy bám theo chúng. Chính phủ và các nhà thầu các lớp ở trênVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 63/77
  • 64. 2011 - Các bài học học được về công nghệ mởcần không thừa nhận một cách nhanh chóng các tư liệu được ghi nhãn một cách không đúng cách vìthiếu thời gian. Ví dụ, các hợp đồng sử dụng DFARS 227.7203-13 bao gồm, trong khoản (d)(3)(i),một giới hạn thời gian thách thức là 3 năm sau lần thanh toán hoặc phân ph ối cu ối cùng c ủa ph ầnmềm, bất cứ thứ gì là muộn hơn. Hơn nữa, những ghi nhãn không phù h ợp có xu h ướng đ ược saochép vào các tư liệu khác; việc sửa các ghi nhãn sớm sẽ làm giảm đáng kể nỗ lực sửa chúng saunày.Ai có thẩm quyền?Đáng tiếc, luôn không rõ ràng ai trong chính phủ hoặc một loạt các nhà thầu có thể đưa ra các quy ếtđịnh này. Có lẽ tốt nhất nếu chính phủ và các nhà thầu có thể làm sáng tỏ các vai trò, các chínhsách, và các thủ tục. Trong khi chờ đợi, những thứ sau đây có thể là hữu dụng: 1. Như được nêu ở trên, khi có nhiều nhà thầu hoặc nhà cung cấp, thì nh ững dàn x ếp pháp lý giữa các tổ chức xác định nhà thầu/nhà cung cấp nào sẽ được phép hợp pháp đ ể đòi b ản quyền. Các nhà thầu dẫn dắt không nhất thiết nhận được các bản quyền từ các nhà thầu phụ và các nhà cung cấp của họ. theo luật Mỹ (17 USC §201), “B ản quy ền... trao quy ền ban đ ầu cho tác giả hoặc các tác giả của tác phẩm... Trong trường hợp tác phẩm đó là đ ể cho thuê, thì ông chủ hoặc người khác mà tác phẩm làm cho họ đã được chuẩn bị được cho là tác gi ả [và giữ bản quyền] trừ phi các bên đã có sự đồng ý rõ ràng bằng văn bản được họ ký”. 2. Bản ghi nhớ về PMNM của DoD năm 2009 làm rõ ai trong DoD có thể xác định khi nào nên đưa phần mềm ra như là PMNM, và theo những điều kiện nào. Bản ghi nh ớ nói r ằng “các điều khoản phần mềm, bao gồm các sửa lỗi và các cải tiến, được phát tri ển cho Chính ph ủ nên được đưa ra cho công chúng (như là theo một giấy phép nguồn mở) khi tất c ả các đi ều kiện sau được đáp ứng: a) Người quản lý dự án, người quản lý chương trình, hoặc nhân viên t ương đ ương khác xác định đây là có ích cho Chính phủ để làm thế, như thông qua mong đợi những cải tiến từ những người khác trong tương lai. b) Chính phủ có các quyền sản xuất lại và tung ra khoản đó, và ủy quy ền cho nh ững ng ười khác làm thế. Ví dụ, Chính phủ có các quyền tung ra công khai khi ph ần m ềm đ ược phát triển từ các nhân viên của Chính phủ, khi Chính phủ nhận được “các quyền không h ạn chế” trong phần mềm được phát triển theo một hợp đồng từ tiền của Chính phủ, hoặc khi PMNM có sẵn từ trước được sửa đổi bởi hoặc cho Chính phủ”. c) Phiên bản công khai của khoản không bị hạn chế theo các luật hoặc qui định khác, như các Qui định Hành chính về Xuất khẩu hoặc Giao thương Quốc tế trong Qui định Quân sự, và khoản định tính đối với Tuyên bố Phân phối A, theo Chỉ thị 5230.24 (tham chiếu (i)) của DoD.” 3. Một số tổ chức không có một qui trình rà soát mã nguồn phần mềm nhưng lại có một qui trình rà soát các tài liệu. Trong những trường hợp này, có thể là phù hợp để đệ trình mã nguồn theo qui trình rà soát tài liệu. Điều này là đặc biệt phù hợp cho rà soát bí mật.Những lưu ý cuối cùngNếu chính phủ và các nhà thầu phù hợp có ý định đưa phần mềm ra như là PMNM, thì t ốt nh ất n ếuđiều đó được nêu một cách rõ ràng từ trước. Ví dụ, PMNM có thể được xác định như là triết lý duytrì phần mềm có kế hoạch theo DFARS 227.7203-2(b)(1). Tuy nhiên, vì nhiều hợp đồng không thảoluận việc đưa phần mềm ra như PMNM, nên điều quan trọng để hiểu các qui đ ịnh m ặc đ ịnh cho cáctrường hợp thường gặp phải.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 64/77
  • 65. 2011 - Các bài học học được về công nghệ mởNếu phần mềm được đưa ra cho công chúng như là PMNM và nó trở thành “được sử dụng một cáchtùy biến bởi công chúng nói chung hoặc bởi các thực thể phi chính ph ủ cho nh ững m ục đích kháchơn là các mục đích của chính phủ”, thì phần mềm đó trở thành phần mềm thương mại. Điều này làtheo cả luật (41 USC §403) và qui định (như, DFARS 252.227-7014(a)(1)). Không là vấn đề gì nếuphần mềm đã được phát triển ban đầu với tiền của chính phủ, hay không. Vì th ế, vi ệc đ ưa ph ầnmềm ra như PMNM có thể là một tiếp cận thương mại hóa.Chính phủ Mỹ và các nhà thầu của mình đã đưa ra nhiều chương trình nh ư là PMNM. Chúng tôi hyvọng rằng tư liệu này cung cấp một cách thức để đưa phần mềm ra một cách có trách nhiệm như làPMNM theo một cách thức phù hợp với các luật, qui định và hợp đồng.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 65/77
  • 66. 2011 - Các bài học học được về công nghệ mởPhụ lục C: Những điều cơ bản về PMNMPhụ lục này mô tả những điều cơ bản của PMNM. Đặc biệt, nó đưa ra nh ững đ ịnh nghĩa chung c ủaPMNM, mô tả các trụ cột pháp lý của chúng, mô tả các dạng giấy phép PMNM chung và th ảo lu ậncách mà PMNM có thể được kết hợp và kết hợp lại một cách hợp pháp.C.1 Định nghĩa PMNMViệc định nghĩa các khái niệm là khó khăn; phần này trình bày định nghĩa c ủa DoD cũng nh ư 2trong số những định nghĩa phổ biến của giới công nghiệp (“Định nghĩa phần mềm tự do” và “Địnhnghĩa phần mềm nguồn mở”).Trong DoD, PMNM được định nghĩa như là “phần mềm mà đối với nó thì mã ngu ồn con ng ười cóthể đọc được là sẵn sàng để sử dụng, nghiên cứu, sử dụng lại, sửa đổi, cải ti ến, và phân ph ối l ại b ởinhững người sử dụng của phần mềm đó” [DoD2002].Quỹ Phần mềm Tự do FSF (Free Software Foundation) định nghĩa khái niệm “Phần mềm Tự do”trong “Định nghĩa Phần mềm Tự do” của nó. Trong khi FSF sử dụng một s ố các khái ni ệm khác, thìvì những lý do của tài liệu này thì định nghĩa đó là một định nghĩa hữu dụng c ủa PMNM. M ộtchương trình là phần mềm tự do nếu những người sử dụng có s ự tự do “đ ể ch ạy, sao chép, phânphối, nghiên cứu, thay đổi và cải tiến phần mềm. Chính xác hơn, nó có nghĩa là nh ững ng ười s ửdụng chương trình có 4 quyền tự do cơ bản: 1. Tự do chạy chương trình, vì bất kỳ mục đích nào (tự do 0) 2. Tự do nghiên cứu cách mà chương trình làm việc, và thay đổi nó để làm cho nó làm đ ược những gì mà bạn muốn (tự do 2). Sự truy cập tới mã nguồn là một điều kiện tiên quy ết cho điều này. 3. Tự do phân phối lại các bản sao để bạn có thể giúp được người hàng xóm của bạn (tự do 2). 4. Tự do phân phối các bản sao những phiên bản đã được sửa đổi của bạn cho những người khác (tự do 3. Bằng việc làm này bạn có thể trao cho toàn bộ cộng đồng một cơ h ội h ưởng lợi từ những thay đổi của bạn. Sự truy cập tới mã nguồn là một điều kiện tiên quyết đối với điều này)”.Tổ chức phi lợi nhuận Sáng kiến Nguồn Mở (OSI) 17 được thiết lập để rà soát lại các giấy phép tiềmnăng và phán xét liệu chúng có là một giấy phép của PMNM hay không. 10 điểm trong “Định nghĩaNguồn Mở” của tổ chức này là: 1. Tự do phân phối lại Giấy phép phải không hạn chế bất kỳ bên nào trong việc bán hoặc cho các ph ần m ềm này như một thành phần của các chương trình tổng hợp chứa phát tán phần mềm này từ những nguồn khác nhau. Giấy phép phải không đòi hỏi phí bản quyền ho ặc các th ứ phí khác vì việc bán này. 2. Mã nguồn Chương trình phải bao gồm mã nguồn, và phải cho phép phân phối cùng mã ngu ồn cũng như dạng được biên dịch rồi. Trong khi một vài dạng của một sản phẩm không được phân phối cùng với mã nguồn, thì sẽ phải có một phương tiện được công khai hoá t ốt v ề vi ệc có17 http://www.opensource.orgVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 66/77
  • 67. 2011 - Các bài học học được về công nghệ mở được mã nguồn với giá thành không lớn hơn cho việc tái sản xuất chấp nhận được, tải về thông qua Intrnet một cách miễn phí. Mã nguồn phải ở dạng được ưa chuộng theo đó một nhà lập trình phát triển có thể sửa đổi được chương trình này. Mã ngu ồn c ố tình gây khó là không được phép. Các dạng trung gian như đầu ra của một trình tiền x ử lý và trình chuy ển đổi là không được phép. 3. Các công việc chuyển hoá Giấy phép phải cho phép các công việc sửa đổi và chuyển hoá, và phải cho phép chúng được phân phối theo cùng các điều khoản như giấy phép của phần mềm ban đầu. 4. Tính toàn vẹn của mã nguồn của tác giả Giấy phép có thể hạn chế mã nguồn đối với việc được phân phối theo dạng đ ược s ửa đ ổi ch ỉ khi nếu giấy phép đó cho phép phân phối các “tệp vá lỗi” với các mã ngu ồn vì m ục đích c ủa việc sửa đổi chương trình đó tại thời điểm xây dựng. Giấy phép phải cho phép một cách d ứt khoát việc phân phối phần mềm được xây dựng từ mã nguồn được sửa đổi đó. Giấy phép có thể yêu cầu các công việc chuyển hoá mang một tên khác hoặc số phiên bản khác với phần mềm gốc. 5. Không phân biệt các cá nhân và nhóm Giấy phép phải không phân biệt đối với bất kỳ ai hoặc nhóm người nào. 6. Không phân biệt trong các lĩnh vực khác nhau Giấy phép phải không hạn chế bất kỳ ai sử dụng chương trình này trong một lĩnh vực đặc thù. Ví dụ, nó có thể không hạn chế chương trình được s ử dụng trong m ột doanh nghi ệp, hoặc được sử dụng để nghiên cứu chung. 7. Phổ biến giấy phép Các quyền gắn với chương trình phải chấp thuận cho tất cả những ai mà chương trình này được phân phối lại mà không có nhu cầu thực hiện một giấy phép bổ sung bởi các bên tham gia đó. 8. Giấy phép phải không được đặc trưng cho một sản phẩm Các quyền gắn với chương trình phải không phụ thuộc vào một phần chương trình của một phát tán phần mềm đặc thù nào. Nếu chương trình này được trích xuất từ phát tán đó và được sử dụng hoặc được phân phối theo những điều khoản của giấy phép của chương trình, thì tất cả các bên mà với họ chương trình được phát tán phải có cùng các quyền như những quyền mà được trao trong sự kết hợp với phát tán phần mềm ban đầu. 9. Giấy phép phải không hạn chế các phần mềm khác Giấy phép phải không hạn chế các phần mềm khác mà chúng được phân phối cùng v ới ph ần mềm được cấp phép. Ví dụ, giấy phép phải không khăng khăng rằng mọi chương trình khác được phân phối theo cùng hoàn cảnh phải là phần mềm nguồn mở. 10. Giấy phép phải trung lập với công nghệ Không điều khoản nào của giấy phép được báo trước về bất kỳ công nghệ hoặc dạng giao diện độ lập nào.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 67/77
  • 68. 2011 - Các bài học học được về công nghệ mởC.2 Luật về các quyền trí tuệTại Mỹ và hầu hết các quốc gia có một cơ quan pháp luật quản lý các công việc trí tu ệ bao g ồm c ảphần mềm. Cơ quan pháp luật này thường được gọi là luật “các quyền trí tuệ” hoặc luật “sở hữu trítuệ”. Vì khái niệm “sở hữu trí tuệ” thường làm lạc lối, nên tài li ệu này s ẽ s ử d ụng khái ni ệm “cácquyền trí tuệ” để thay thế. Cơ quan pháp luật này bao gồm luật về bản quyền, bằng sáng ch ế vàthương hiệu. Các phần sau thảo luận những điều cơ bản về các luật này tại Mỹ.C.2.1 Bản quyền & Giấy phépHiện hành, luật bản quyền có hiệu lực vào thời điểm một tác phẩm ban đầu được tạo ra và đ ặt vàomột “dạng cố định” (đó là, được viết hoặc được gõ ra). Vì những giấy phép của PMNM được quảnlý theo luật bản quyền, nên điều quan trọng phải hiểu luật bản quyền, nền tảng về bản quyền phảiđược yêu cầu.Một bản quyền đưa ra cho những người nắm giữ bản quyền các quy ền đ ộc chi ếm đ ể làm nh ững th ứnhất định nào đó với tác phẩm trí tuệ mà những người khác không thể làm mà không có quy ền c ủabạn. Danh sách đầy đủ các quyền có thể thấy được trong Luật Bản quyền Mỹ, Copyright Act, 17USC §106; đối với phần mềm thì chúng đưa vào quyền độc chiếm để: • làm các bản sao • chuẩn bị các tác phẩm dẫn xuất • phân phối các bản sao của các tác phẩm gốc ban đầu hoặc dẫn xuấtNgười nắm giữ bản quyền cũng có thể trao một giấy phép cho ai đó khác đ ể sao chép, s ửa đ ổi, ho ặcphân phối một mẩu phần mềm, có thể với những hạn chế hoặc những điều kiện cụ thể nào đó.C.2.2 Các bằng sáng chếCác bằng sáng chế sai khiến và bắt tuân thủ cách mà một sáng tạo ban đ ầu (trong th ực ti ễn, m ột ýtưởng) được kiểm soát. Các bằng sáng chế trao cho một người s ở h ữu quy ền lo ại tr ừ nh ững ng ườikhác khỏi làm những thứ nhất định nào đó với sở hữu trí tuệ được cấp b ằng sáng ch ế [Rosen2005,page 23]. Danh sách đầy đủ các quyền có thể thấy được trong Luật về Bằng sáng chế của M ỹ, U.S.Patent Act, 35 USC §154, mà bao gồm quyền của người nắm giữ b ằng sáng ch ế đ ể lo ại tr ừ nh ữngngười khác khỏi: • việc làm ra các sản phẩm biểu hiện sáng tạo được cấp bằng sáng chế của họ. • việc sử dụng các sản phẩm biểu hiện sáng tạo của họ. • việc bán hoặc chào bán các sản phẩm biểu hiện sáng tạo của họ. • việc nhập khẩu các sản phẩm biểu hiện sáng tạo được cấp bằng sáng chế của họ.Việc áp dụng các bằng sáng chế đối với phần mềm là còn tranh cãi cao đ ộ; nhi ều qu ốc gia tuy ệt đ ốicấm điều này. Phần mềm có lẽ không được cấp bằng sáng chế tại M ỹ trong nhiều năm, và trongnhững năm này một số lượng lớn những đổi mới sáng tạo đã được t ạo ra, nên có m ột b ằng ch ứngtuyệt vời rằng các bằng sáng chế là không cần thiết đối với đổi mới sáng tạo của phần mềm.Tuy nhiên, tại thời điểm tài liệu này được viết, các bằng sáng chế về phần mềm đ ược cho phép t ạiMỹ, và có một số lượng khổng lồ các bằng sáng chế về phần mềm.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 68/77
  • 69. 2011 - Các bài học học được về công nghệ mởVì phần mềm đôi khi có những bằng sáng chế có liên quan tới sử dụng nó, nên một s ố gi ấy phépPMNM đưa ra một giấy phép cho những người sử dụng phần mềm đó để sử dụng và mở rộng phầnmềm đó mà không có các điều kiện ngoại trừ những điều kiện được biểu hiện trong giấy phép đó.C.2.3 Thương hiệuThương hiệu đưa ra sự độc chiếm về sử dụng một cái tên (như, một nhãn hi ệu - brand). Nhi ều d ự ánPMNM đòi thương hiệu đối với tên của một dự án PMNM. Các thương hiệu không cần đăng ký,nhưng các hành động có liên quan tới thương hiệu không thể được thực hiện trừ phi thương hi ệuđược đăng ký.Việc đăng ký một thương hiệu có thể là một quá trình khá d ễ dàng ho ặc quá trình khá đ ắt đ ỏ ph ụthuộc vào việc một công ty có mong muốn bảo vệ là bao nhiêu. Các chi tiết về cách để đăng ký mộtthương hiệu có thể thấy được trên website của Văn phòng Bằng sáng ch ế và Th ương hi ệu M ỹ(USPTO) tại: http://www.uspto.gov.C.3 Các dạng và các tổ hợp giấy phép của PMNMPMNM thường được kết hợp và tái kết hợp với các PMNM khác đ ể t ạo ra nh ững t ổ h ợp m ới và h ữudụng. Việc kết hợp phần mềm đòi hỏi rằng các lập trình viên và những người sử dụng tuân theo t ấtcả các giấy phép cùng một lúc. Rất cẩn thận phải được ti ến hành khi ch ọn m ột gi ấy phép đ ể đ ảmbảo rằng chương trình phần mềm có thể được sử dụng và sử dụng lại bởi nhóm ng ười s ử d ụng r ộnglớn nhất có thể (nếu điều đó là mục tiêu của việc làm ra một chương trình PMNM).Chỉ một số giấy phép PMNM có thể kết hợp được với những dạng các giấy phép khác trong khi v ẫnđáp ứng được những yêu cầu của tất cả các giấy phép đó. Hình và văn b ản sau đây có ngu ồn g ốc t ừ[Wheeler2007], mà nó tổng kết cách mà một số giấy phép PMNM có thể được kết hợp: Hình C.1. Sự tương tác của các giấy phép PMNM [Wheeler2007]Trong hình C.1, các hộp bóng mờ là các tên của các giấy phép PMTDNM khác nhau (dấu “+” nghĩalà “hoặc bất kỳ phiên bản sau nào”). Một mũi tên từ hộp A sang h ộp B có nghĩa là b ạn có th ể k ếthợp các phần mềm với các giấy phép đó; kết quả kết hợp có hiệu qu ả đ ối với gi ấy phép B, có th ểvới các điều kiện từ A. Để xem liệu phần mềm có thể kết hợp được không, hãy b ắt đ ầu ở các gi ấyphép tương ứng của chúng, và thấy một hộp chung mà bạn có thể đạt được khi đi theo các mũi tên(như “tuân theo slide”). Ví dụ, phần mềm có phép Apache 2.0 và ph ần m ềm có phép GPLv2 + cóthể cùng đạt được “GPLv3 hoặc GPLv3+”, nên chúng có thể kết h ợp đ ược b ằng vi ệc s ử d ụngGPLv3 hoặc GPLv3+. Hình này đã từng được chỉnh sửa một cách c ẩn th ận nên vi ệc tuân theoVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 69/77
  • 70. 2011 - Các bài học học được về công nghệ mởđường đi sẽ xác định liệu 2 giấy phép có tương thích hay không. Thông tin h ơn n ữa b ạn ph ải xemxét văn bản của giấy phép, nhưng điều này đưa ra câu trả lời cơ bản nhanh chóng.Hình chỉ ra các giấy phép PMNM, được tổ chức thành 3 nhóm: 1. Ở bên trái là các giấy phép “cho phép”, mà chúng cho phép phần mềm trở thành sở hữu đ ộc quyền (nghĩa là, không phải PMTDNM). Trên đỉnh bên trái là “Miền Công cộng” (trong trường hợp này có nghĩa là “không có bảo vệ bản quyền”), mà nó nói m ột cách hoàn toàn không phải là một giấy phép nhưng trên thực tế nó làm việc giống như một giấy phép. B ạn có thể làm bất kỳ điều gì với phần mềm trong miền công cộng, nhưng nó là r ất hi ếm; ph ần mềm phải hoàn toàn được tung ra cho miền công cộng hoặc được tạo ra từ một nhân viên của Chính phủ Mỹ trong khả năng chính thức của họ. Bên cạnh là cái gọi là giấy phép “MIT” hoặc “X11”, mà nó là rất cho phép (bạn có thể làm bất kỳ thứ gì ngoại trừ việc kiện tác giả). Phần mềm theo giấy phép MIT dễ dàng được kết hợp với giấy phép BSD hiện đ ại 3 mệnh đề (BSD-mới) (3-clause Berkeley Software Distribution), so với giấy phép MIT thì nó bổ sung thêm một mệnh đề cấm sử dụng tên các tác giả để chứng thực hoặc thúc đẩy các sản phẩm không có sự cho phép (còn gây tranh cãi nếu mệnh đề này thực sự không làm bất kỳ thứ gì, vì bạn thường phải có quyền như vậy dù thế nào chăng nữa). Cuối cùng chúng ta có giấy phép Apache phiên bản 2.0. 2. Ở bên phải là các giấy phép “bảo vệ mạnh mẽ” (“copyleft mạnh”), mà chúng ngăn ng ừa phần mềm khỏi việc trở thành sở hữu độc quyền. Điều này bao gồm giấy phép PMTDNM phổ biến nhất, GNU General Public License (GPL). GPL có phiên b ản 2 (GPLv2) và 3 (GPLv3); một dấu “+” đứng đằng sau có nghĩa là “phiên b ản X ho ặc sau này”. ch ỉ GPLv2 không thể kết hợp được với giấy phép bảo vệ mạng Affero GPLv3, nhưng GPLv2+ (“phiên bản 2 hoặc sau này”) có thể thông qua GPLv3. Giấy phép PMNM phổ biến nhất, cho tới nay là GPL, hầu hết các PMNM được tung ra theo GPL [Wheeler2010g]. 3. Nằm ở giữa là các giấy phép “bảo vệ yếu” (“copyleft yếu”), một sự thỏa hiệp giữa các giấy phép cho phép và bảo vệ mạnh. Những giấy phép này ngăn ngừa thành phần của phần mềm (thường là một thư viện phần mềm) khỏi việc trở thành sở hữu độc quyền, nhưng vẫn cho phép nó trở thành một phần của một chương trình sở hữu độc quyền lớn h ơn. Hình này ch ỉ ra những luật lệ khi bạn đang làm ra một phần khác của phần mềm của một thành phần được bảo vệ yếu; có những khả năng khác nếu bạn chỉ đang sử dụng thành phần đó như một thư viện. Giấy phép GNU Lesser General Public License (LGPL) là giấy phép b ảo v ệ y ếu ph ổ biến nhất, và có phiên bản 2.1 (LGPLv2.1) và 3 (LGPLv3). Lưu ý rằng LGPLv2.1 trao cho bạn quyền để cấp phép lại mã nguồn theo bất kỳ phiên bản nào của GPL kể từ GPLv2. Một giấy phép khác như vậy là Mozilla Public License 1.1 (MPLv1.1), nh ưng MPL có nh ững hạn chế nghiêm trọng khi nó không tương thích với GPL phổ biến rộng rãi, b ạn th ậm chí không thể sử dụng một module có phép MPL trong một chương trình có phép GPL lớn hơn.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 70/77
  • 71. 2011 - Các bài học học được về công nghệ mởPhụ lục D: Chọn một giấy phép PMNM như thế nàoD.1 Các tiêu chí cấp phép chủ chốtKhi chọn một giấy phép PMNM, hãy giữ các tiêu chí sau trong đầu: 1. Hãy sử dụng một giấy phép PMNM có sẵn; không tạo ra một giấy phép PMNM mới . Những người sử dụng ghét làm việc với nhiều giấy phép PMNM khác nhau, vì các vấn đề mà chúng gây ra. Mỗi giấy phép mới phải được đánh giá bởi từng người s ử d ụng ti ềm năng ho ặc phòng pháp lý của họ, làm nảy sinh các chi phí một cách đáng kể. Những phân m ảnh c ủa một chương trình thường không thể được sử dụng trong chương trình khác vì tính không tương thích về giấy phép, và thậm chí nơi mà chúng có thể kết hợp được, thì sự phân tích pháp lý để xác định các giấy phép mới này cũng có thể là đáng kể. Việc tạo ra một giấy phép PMNM cũng rất rủi ro; nó đòi hỏi tri thức pháp lý về PMNM mà nh ững lu ật s ư theo h ợp đồng và việc hợp đồng với các chuyên gia thường không có, thậm chí các chuyên gia còn tạo ra những sai lầm khó có thể sửa sai sau này được. 2. Hãy chắc chắn nó thực sự là PMNM. Hãy chọn một giấy phép PMNM mà nó đã được chứng thực như là PMNM từ OSI và như là PMTD từ FSF. Nó cũng nên được các phát tán Debian và Fedora phê chuẩn (cả 2 đều thực hiện phân tích pháp lý về các giấy phép). Các giấy phép phi tiêu chuẩn thường không phải là PMNM, thậm chí khi chúng được mong đợi để trở thành. 3. Hãy sử dụng một giấy phép tương thích được với GPL . Hầu hết các PMNM được tung ra có sử dụng các giấy phép GPLv2 hoặc GPLv3. Điều này không có nghĩa là tất cả các PMNM phải được tung ra có sử dụng GPL, nhưng việc chọn một giấy phép không t ương thích được với GPL, như “Thỏa thuận Nguồn Mở của NASA” phiên b ản 1.3 ho ặc “Gi ấy phép Công cộng Mozilla” MPL (Mozilla Public License). Nếu bạn phải sử dụng một giấy phép không tương thích với GPL, thì cũng hãy tung ra cùng một lúc ph ần m ềm đó có s ử dụng một giấy phép tương thích với GPL tiêu chuẩn. 4. Không lẫn lộn với những chuyện hoang đường về GPL . GPL chỉ đòi hỏi rằng bạn cung cấp mã nguồn nếu bạn đã cung cấp mã nguồn chạy được cho họ; nó không đòi h ỏi đ ưa ra cho công chúng mọi thứ. Nếu nó vẫn nằm trong chính phủ Mỹ, thì nó không đ ược phân ph ối hoàn toàn (chỉ có mỗi một chính phủ liên bang Mỹ). Khi mã nguồn được cấp phép theo GPL được tải vào một mạng bí mật của chính phủ, thì nó không đòi hỏi tung ra bất kỳ d ữ li ệu hoặc phần mềm nào. Mã nguồn chỉ phải tung ra nếu những thay đổi được thực hiện, và thậm chí sau đó, mã nguồn chỉ cần phải được tung ra cho những ai mà họ đã nhận được một chương trình chạy được. Vì thế, không có vấn đề gì với việc lấy một chương trình được cấp phép GPL và tiến hành làm những sửa đổi bí mật; theo định nghĩa, chỉ những người nhận s ẽ có sự rõ ràng đối với thông tin bí mật. Một số nhà cung cấp có thể nói r ằng “n ếu chúng tôi sử dụng mã nguồn được cấp phép theo GPL, thì chúng tôi có thể phải tung ra ph ần m ềm quân sự chiến lược này lên Internet”, nhưng nói thế đơn giản là không đúng. 5. Hãy chọn một giấy phép đáp ứng được những sử dụng được mong đợi của bạn . Nếu phần mềm có thể sẽ được kết hợp với chương trình khác, thì hãy sử dụng một giấy phép tương thích được với giấy phép của chương trình khác đó. Nếu phần mềm sẽ được ki ểm soát xu ất khẩu, thì hãy đảm bảo rằng chế độ cấp phép có thể làm việc được bên trong nó. Nếu chương trình được cấp phép theo GPL được xuất khẩu sang một nước khác, thì người nh ận đó ph ảiVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 71/77
  • 72. 2011 - Các bài học học được về công nghệ mở có khả năng nhận được mã nguồn đối với phần mềm đó (nên đây là một lĩnh vực nơi mà GPL phải được thận trọng xem xét). 6. Hãy sử dụng một giấy phép PMNM phổ biến . Một giấy phép phi tiêu chuẩn hoặc không phổ biến sẽ tạo ra nhiều vấn đề về pháp lý. Các luật sư khắp thế giới s ẽ phải xem xét c ẩn th ận giấy phép phi tiêu chuẩn và xác định liệu nó có thể chấp nhận được không và li ệu nó có tương thích được với các giấy phép khác hay không (điều này có thể tiềm tàng việc làm tốn hàng triệu USD, và những người rà soát lại như vậy có th ể lúng túng s ử d ụng). Các gi ấy phép PMNM phổ biến (tất cả chúng đều tương thích với GPL) bao gồm cả giấy phép MIT/X, giấy phép BSD mới, giấy phép Apache 2.0, LGPL và GPL.D.2 Qui trình chọn giấy phép đơn giảnĐược đưa ra ở trên, sau đây là một qui trình đơn giản cho việc chọn một giấy phép phần mềm làPMNM. Đơn giản hãy trả lời các câu hỏi sau cho tới khi bạn tìm thấy sự phù hợp: 1. Phần mềm có được phát triển hoàn toàn bằng nhân viên của chính phủ như một phần nhiệm vụ chính thức của họ hay không? Nếu thế, thì phần mềm này (nếu được tung ra) hoàn toàn không thể có bất kỳ s ự bảo v ệ b ản quyền nào cả tại Mỹ, theo 17 USC 105 and 17 USC 101. Các công việc không có bảo v ệ bản quyền thường được tham chiếu tới như là đang ở trong “miền công cộng”; đáng ti ếc, cụm từ “miền công cộng” cũng có những ý nghĩa khác, nên cụm từ đó có thể gây lẫn lộn. Việc tung ra một cách đơn giản phần mềm cho thế giới mà không có b ảo v ệ b ản quy ền là tiếp cận đơn giản nhất cho việc đưa ra phần mềm như vậy. Tuy nhiên, phần mềm như vậy có thể có bảo vệ bản quyền bên ngoài nước Mỹ. Nếu bạn (chính phủ Mỹ) mong mu ốn tăng cường bản quyền bên ngoài nước Mỹ, thì bạn nên đăng ký bản quyền của phần mềm đó tại các nước ngoài, chuẩn bị tăng cường giấy phép bản quyền tại các tòa án c ủa các n ước ngoài, và chọn một lựa chọn thay thế cấp phép khi nó là ở ngoài nước Mỹ (như, từ những lựa chọn bên dưới). Chính phủ cũng có thể thuê một nhà thầu để sửa đổi phần mềm, và chỉ cho phép đưa ra tác phẩm được kết hợp (mà không có việc xác định nh ững ph ần nào là cái gì); vì những sửa đổi có bản quyền, thì bản quyền có thể áp dụng được cho tác ph ẩm t ổng th ể, và tác phẩm được sửa đổi này có thể không là một tác phẩm mà không có bảo vệ bản quyền. 2. Liệu đây có là một sửa đổi hoặc mở rộng của PMNM đang tồn tại hay không? Nếu là thế, thì bạn nên tung phần mềm đó ra hoặc (1) theo giấy phép hiện hành của dự án PMNM hiện đang tồn tại, hoặc (2) hoàn toàn không có bảo vệ bản quyền . Bằng cách đó, phần mềm mới có thể được kết hợp vào dự án hiện hành đang duy trì nó. Nếu dự án không sử dụng một giấy phép PMNM phổ biến, và sự s ửa đ ổi ho ặc m ở r ộng có bảo vệ bản quyền, thì hãy xem xét việc cũng đưa phần mềm mới ra theo một giấy phép PMNM phổ biến (như được mô tả bên dưới). Việc tung phần mềm đó ra theo c ả gi ấy phép không bình thường và một giấy phép phổ biến (một “giấy phép đôi”) có nghĩa là dự án có thể sử dụng sự sửa đổi hoặc mở rộng đó ngay lập tức (mà không có vi ệc thay đ ổi các gi ấy phép) và có thể dễ dàng hơn để chuyển sang một giấy phép PMNM phổ biến trong tương lai. 3. Bạn có muốn bất kỳ ai đó sẽ có khả năng sử dụng phần m ềm đó vì b ất kỳ m ục đích gì hay không, bao gồm việc tạo ra những phiên bản phân kỳ sở hữu độc quyền không t ương thích và các module sở hữu độc quyền bên trong các chương trình sở hữu độc quy ền r ộng l ớn hơn hay không?Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 72/77
  • 73. 2011 - Các bài học học được về công nghệ mở Nếu thế, hãy chọn một giấy phép cho phép (còn gọi là hàn lâm) ph ổ bi ến: đ ặc bi ệt, gi ấy phép MIT/X, giấy phép BSD mới, hoặc giấy phép Apache 2.0. Các giấy phép cho phép là đặc biệt hữu dụng khi sử dụng rộng rãi một công nghệ mới hoặc tiêu chuẩn mới là mục tiêu. Những giấy phép này đôi khi còn được gọi là các giấy phép “hàn lâm” vì giá tr ị c ủa chúng trong việc làm cho các khái niệm hàn lâm được triển khai một cách rộng rãi trong công nghiệp. Ví dụ, Internet đã trở thành lan truyền rộng rãi một phần lớn vì m ột trong nh ững triển khai cài đặt đầu tiên của các tiêu chuẩn Internet TCP/IP đã đ ược tung ra theo d ạng gi ấy phép này. Một rủi ro của các giấy phép này là việc phần mềm có thể sẽ đ ược s ửa đ ổi thành một hoặc nhiều hơn các phiên bản sở hữu độc quyền, mà nó có thể không còn có khả năng được chia sẻ và được đồng phát triển được nữa bởi những người mà đã phát triển ra phiên bản gốc ban đầu; các thế lực kinh tế có thể làm cho những dự án như vậy rẽ nhánh thành nhiều dự án theo thời gian. Giấy phép MIT/X cho tới nay là giấy phép đơn giản nhất như vậy, nên ở những nơi phù hợp, hãy sử dụng nó. Giấy phép BSD mới (3-clause) cũng không phức tạp và lan truyền rộng rãi, nên nó cũng là một sự lựa ch ọn t ốt (không s ử d ụng gi ấy phép “BSD cũ” với 4-mệnh đề (4-clause) mà nó đã bị Berkeley và những n ơi khác c ấm; phiên bản cũ của giấy phép này không tương thích với GPL). Giấy phép Apache 2.0 là tương thích với GPLv3, nhưng không tương thích với GPLv2, mà đó là một cú đánh chống lại nó. 4. Bạn có muốn khuyến khích sự duy trì dài hạn của một chương trình ph ổ bi ến b ằng vi ệc thiết lập một khung pháp lý giống như nhóm các doanh nghiệp, bảo vệ chương trình đó khỏi trở thành một chương trình sở hữu độc quyền hoặc module sở hữu độc quyền hay không? Nếu thế, hãy chọn một giấy phép bảo vệ mạnh và phổ biến (còn gọi là copyleft mạnh hoặc có đi có lại). Trong thực tế điều này có thể thường là một phiên bản của GPL, nhưng nếu bạn muốn đảm bảo cho sự đồng phát triển của các ứng dụng web thì Affero GPL (AGPL) có thể sẽ được lựa chọn thay vào đó. Các giấy phép bảo vệ mạnh đặc biệt là hữu dụng khi cố làm gia tăng sự hợp lý r ằng m ột chương trình được đưa ra sẽ được duy trì trong tương lai bởi một nhóm các bên có quan tâm. Nhân Linux là một ví dụ của một chương trình như vậy. Có 2 phiên bản GPL được s ử dụng phổ biến, phiên bản 2 và phiên bản 3. Hầu hết các phần mềm PMNM được đưa ra theo “GPL phiên bản 2 hoặc sau này”, mà nó làm tối đa hóa tính t ương h ợp; đây có l ẽ là con đường đơn giản nhất và nhìn xa nhất cho việc cấp phép bảo vệ mạnh. Nếu văn bản “bất kỳ phiên bản nào sau này” được cho là không thể chấp nhận được đối với một phiên bản đ ặc biệt, thì hãy công bố “GPL phiên bản 2 hoặc phiên bản 3”, và hãy chắc chắn chỉ định ai s ẽ có thẩm quyền để tung ra phần mềm theo những phiên bản sau đó của giấy phép, và hãy chắc chắn đưa vào tuyên bố đó trong giấy phép sao cho những người khác đóng góp s ẽ cùng một lúc được ràng buộc vào quyết định này. Trong một số trường hợp chỉ một phiên b ản c ủa GPL có thể được lựa chọn (như, phiên bản 2 hoặc phiên bản 3), nhưng điều này có thể cấm việc kết hợp các phần mềm. Hãy lưu ý rằng giấy phép Apache 2.0 và AGPL là t ương thích với GPLv3, nhưng không tương thích với GPLv2. 5. Bạn có muốn khuyến khích sự duy trì dài hạn của m ột thư viện ph ổ bi ến b ằng vi ệc thi ết l ập một khung pháp lý giống như một nhóm công nghiệp, bảo vệ chương trình khỏi việc trở thành một thư viện sở hữu độc quyền, nhưng cho phép các chương trình sở hữu độc quyền đưa vào được trong thư viện đó hay không? Nếu thế, hãy chọn một giấy phép bảo vệ yếu (còn gọi là copyleft y ếu). Đi ều này th ường được triển khai bằng việc sử dụng một phiên bản của LGPL. Một lựa chọn thay thế phổ biếnVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 73/77
  • 74. 2011 - Các bài học học được về công nghệ mở là cấp phép cho thư viện có sử dụng GPL với một liên kết ngoại lệ GPL (liên kết ngoại lệ CLASSPATH là một lựa chọn phổ biến đặc biệt như vậy). Các giấy phép bảo vệ yếu là những thỏa hiệp giữa các giấy phép cho phép và bảo vệ mạnh; chúng khuyến khích sự đồng phát triển của thư viện, trong khi lại cho phép các ch ương trình sở hữu độc quyền đưa vào chúng. LGPL yêu cầu rằng những người sử dụng có khả năng tái liên kết tới các thư viện được cập nhật; điều này là hữu dụng cho những người sử dụng nhưng trong một số ngôn ngữ lập trình thì điều này là không khả thi (trong đó trường h ợp GPL với một liên kết ngoại lệ GPL là lựa chọn tốt hơn).Một số tổ chức chọn một tiếp cận “cấp phép đôi” (dual-licensing) trong đó phần mềm được tung ratheo cả một giấy phép PMNM (thường là GPL) và một giấy phép không của PMNM. T ổ ch ức mànắm giữ các quyền đối với phần mềm sau đó yêu cầu “những thỏa thu ận c ủa nh ững ng ười đónggóp” từ tất cả những người đề xuất (submitters) bên ngoài; những thỏa thuận này trao cho t ổ ch ứccác quyền bổ sung ngoài giấy phép PMNM (xúc tác cho giấy phép không ph ải là PMNM thànhvĩnh viễn). Những thỏa thuận này thường là không độc chiếm, nhưng tuy nhiên, như một sự thu thậpthì những thỏa thuận này trao cho tổ chức các quyền bổ sung không đối xứng không được nắm giữbởi những người khác. Vì mối quan hệ này là không đối xứng, một vấn đề chủ chốt đối với từngngười là tổ chức này là ai: liệu nó là phi lợi nhuận (như, một nhóm công nghi ệp ho ặc m ột chínhphủ), hay là một công ty vì lợi nhuận? Các công ty đôi khi sử dụng thỏa thuận này sao cho họ có thểáp đặt lên những người khác đối với các quyền bổ sung; điều này có thể là có lợi ích, nhưng nó cũngcó thể xúc tác cho một dạng khóa trói phụ thuộc vào công ty làm gì với các quyền đó và các kháchhàng cần cái gì. Tiếp cận này cũng có thể làm suy yếu mạnh mẽ s ự c ộng tác; nhi ều ng ười không th ểhoặc sẽ không đóng góp những cải tiến theo những thỏa thuận không đối xứng này. Ngắn gọn,những tiếp cận này làm suy yếu sự cộng tác trong trao đ ổi vì m ột s ố l ợi ích đ ược th ừa nh ận khác;liệu có hay không điều này là có lợi ích, và cho ai, còn phụ thuộc vào từng hoàn cảnh.Tất cả văn bản ở trên giả thiết rằng phần mềm đang được cấp phép. Các tác phẩm do cộng đồngphát triển mà không phải là phần mềm thường được tung ra theo 2 giấy phép c ủa CriativeCommons, mà chúng nên được sử dụng cho các tác phẩm trí tuệ thông thường không ph ải là ph ầnmềm khi bạn muốn xúc tác cho sự duy trì của cộng đồng: 1. Giấy phép thẩm quyền (CC BY), mà là một giấy phép cho phép đ ối v ới các tác ph ẩm không phải là phần mềm. 2. Giấy phép thẩm quyền chia sẻ (CC BY-SA), mà nó là giấy phép bảo vệ m ạnh (có đi có l ại) đối với các tác phẩm không phải là phần mềm.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 74/77
  • 75. 2011 - Các bài học học được về công nghệ mởCác tham chiếu[Apache2010] Apache Software Foundation. 2010. “Consensus Gauging through Voting”. http://www.apache.org/foundation/voting.html[Bacon2009] Bacon, Jono. August 2009. The Art of Community: Building the New Age of Participation. ISBN: 978-0-596-15671-8. http://www.artofcommunityonline.org/downloads/jonobacon-theartofcommunity-1ed.pdf[Boyd1976] Boyd, Col. John, Destruction and Creation - John Boyd - Winning and Losing, Sept 3, 1976[Burnette2006] Burnette, Ed. June 14, 2006. “HOWTO: Pick an open source license”. ZDNet.com Blog. http://blogs.zdnet.com/Burnette/?p=130[Carter 2010] Carter, Ashton B. June 2010. “Memorandum to Acquisition Professionals Subject: Better Buying Power: Mandate for Restoring Affordability and Productivity in Defense Spending” https://dap.dau.mil/policy/Documents/Policy/Carter%20Memo%20on%20Defense%20Spending %2028%20Jun%202010.pdf[Collins2007] Collins-Sussman, Ben, and Brian W. Fitzpatrick. January 25, 2007. “How Open Source Projects Survive Poisonous People (And You Can Too)” also titled “How to Protect Your Open Source Project from Poisonous People”. Google Tech Talks. Video. http://video.google.com/videoplay?docid=-4216011961522818645[DeHaan2009] DeHaan, Mike. May 17, 2009. “Recognizing and Avoiding Common Open Source Community Pitfalls”. http://michaeldehaan.net/2009/05/17/oss-pitfalls/ Retrieved 2010-08-19.[DoDI5000] Department of Defense (DoD). December 8, 2008. Operation of the Defense Acquisition System. DoD Instruction 5000.02. http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf[DoD2009] Department of Defense (DoD). October 16, 2009. Clarifying Guidance Regarding Open Source Software (OSS). http://cio-nii.defense.gov/sites/oss/2009OSS.pdf[Fogel2009] Fogel, Karl. 2009. Producing Open Source Software: How to Run a Successful Free Software Project. http://producingoss.com/[GAO 2006] Government Accountability Office (GAO). July 2006. “WEAPONS ACQUISITION: DOD Should Strengthen Policies for Assessing Technical Data Needs to Support Weapon Systems”. Report GAO- 06-839. http://www.gao.gov/new.items/d06839.pdf[GAO 2010] Government Accountability Office (GAO). July 2010. FEDERAL CONTRACTING: Opportunities Exist to Increase Competition and Assess Reasons When Only One Offer Is Received Report GAO- 10-833. http://www.gao.gov/new.items/d10833.pdf[Java.net] Choose a License. Undated. http://java.net/choose-license[Lynn2010] Lynn, William J. III. September 2010. “Defending a New Domain: The Pentagon’s Cyberstrategy”. Foreign Affairs.[Martin2000] Martin, Robert C. 2000. Design Principles and Design Patterns. http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf[MITRE2003] MITRE Corporation. January 2, 2003. Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense. http://cionii.defense.gov/sites/oss/2003Survey/dodfoss_pdf.pdf[Morville2005] Ambient Findability: What We Find Changes Who We Become, Morville, Peter, OReilly Media, Sept. 2005[National Rising Above the Gathering Storm: Energizing and Employing America for a Brighter EconomicAcademies 2008] Future. Report of the Committee on Science, Engineering, and Public Policy. National Academies Press, 2008[OSI-Licenses] Open Source Initiative (OSI). Undated. Licenses by Name. http://www.opensource.org/licenses/alphabetical. Retrieved 2010-08-19.[OSI OSD] Open Source Initiative (OSI). Open Source Definition (OSD). http://www.opensource.org/docs/osd[OTD2006] J.C. Herz, Mark Lucas, and John Scott. April 2006. Open Technology Development Roadmap Plan. http://www.acq.osd.mil/jctd/articles/OTDRoadmapFinal.pdf.[Raymond1999] Raymond, Eric. October 1999. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O’Reilly Media. http://www.catb.org/~esr/writings/cathedral-bazaar/[RedHat2009] Red Hat Community Architecture Team. 2009. The Open Source Way.Văn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 75/77
  • 76. 2011 - Các bài học học được về công nghệ mở http://www.theopensourceway.org[Rosen2005] Rosen, Lawrence. 2005. Open Source Licensing. Prentice-Hall.[Scott2010] Scott, John. 2010. Pentagon is Loosing the Softwar(e). Denfense News June 21, 2010. http://www.defensenews.com/story.php?i=4677662[Van Buren2011] Van Buren, David M. January 14, 2011. SAF/AQ. “Present a Competitive Acquisition Strategy at Each Program Milestone” https://dap.dau.mil/policy/Documents/2011/Present%20a%20Competitive%20Acquisi tion%20Strategy%20at%20Each%20Program%20Milestone_AQ%20Memo.pdf[VonHippel2005] Von Hippel, Eric. 2005. Democratizing Innovation. Cambridge, Massachusetts: The MIT Press. ISBN 0-262-00274-4. http://web.mit.edu/evhippel/www/democ1.htm[Wegner 2002] Wegner, Etienne, Richard McDermott, and William M. Snyder. March 15, 2002. Cultivating Communities of Practice. Harvard Business Press. ISBN-10: 1578513308. ISBN-13: 978- 1578513307.[Wheeler2007] Wheeler, David A. September 27, 2007. The Free-Libre / Open Source Software (FLOSS) License Slide. http://www.dwheeler.com/essays/floss-license-slide.html[Wheeler2009] Wheeler, David A. 2009. Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation. http://www.dwheeler.com/essays/releasing-floss-software.html.[Wheeler2010e] Wheeler, David A. Revised as of January 8, 2010. How to Evaluate Open Source Software / Free Software (OSS/FS) Programs. http://www.dwheeler.com/oss_fs_eval.html[Wheeler2010g] Wheeler, David A. Released 2002-05-06, revised 2010-06-05. Make Your Open Source Software GPL-Compatible. Or Else. http://www.dwheeler.com/essays/gplcompatible.htmlVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 76/77
  • 77. 2011 - Các bài học học được về công nghệ mởBảng chú giảiAoA Analysis of Alternatives - Phân tích các lựa chọn thay thếDoD Department of Defense - Bộ Quốc phòngCOTS Commercial Off-the-shelf (OTS) - Thương mại, dùng được ngayGOTS Government Off-the-shelf (OTS) - Của chính phủ, dùng được ngayOGOTS Open Government Off-the-shelf (GOTS) - Mở, của chính phủ, dùng được ngayOSS Open Source Software - Phần mềm nguồn mở - PMNMOTD Open Technology Development - Phát triển Công nghệ MởOTS Off-the-shelf - Dùng được ngayRFI Request for Information - Yêu cầu thông tinRFP Request for Proposal - Yêu cầu đề xuấtPhần mềm nguồn mở – PMNMPhần mềm tự do – PMTDPhần mềm tự do nguồn mở – PMTDNMCông nghệ thông tin – CNTTVăn phòng Phối hợp Phát triển Môi trường Khoa học và Công nghệ, Bộ Khoa học và Công nghệ Trang 77/77

×