Dự luật bắt buộc các cơ quan Mỹ chia sẻ mã nguồn với nhau đã được ban hành

• Tổng thống Joe Biden đã ký SHARE IT Act vào ngày 23/12, yêu cầu các cơ quan liên bang Mỹ phải chia sẻ mã nguồn tùy chỉnh với nhau nhằm giảm các hợp đồng phát triển trùng lặp
• Trọng tâm là công khai danh mục mã tùy chỉnh theo từng cơ quan và cho phép tái sử dụng, nhằm cắt giảm khoảng 12 tỷ USD mà chính phủ liên bang được ước tính chi mỗi năm cho việc mua phần mềm
• Phạm vi áp dụng của luật loại trừ mã mật, hệ thống an ninh quốc gia và mã có thể gây rủi ro về quyền riêng tư nếu được chia sẻ
• CIO của các cơ quan phải xây dựng chính sách triển khai trong vòng 180 ngày kể từ khi luật có hiệu lực, bao gồm tuân thủ thực hành tốt nhất, công khai metadata và quy trình báo cáo được chuẩn hóa
• Atlassian và GitLab Inc. ủng hộ dự luật; dự luật được Thượng viện và Hạ viện thông qua trong tháng 12 mà không có cuộc bỏ phiếu ghi danh

---

Nghĩa vụ chia sẻ mã theo SHARE IT Act

• Source Code Harmonization And Reuse in Information Technology Act, hay SHARE IT Act, yêu cầu các cơ quan liên bang chia sẻ mã nguồn do họ phát triển tùy chỉnh với các cơ quan khác
• Luật tập trung vào việc giảm phát triển trùng lặp, tức ký hợp đồng làm lại mã mà không biết mã đó đã được phát triển cho một cơ quan khác
• Các cơ quan phải lập danh mục công khai mã tùy chỉnh và cho phép các cơ quan khác sử dụng mã đó

Mục tiêu tiết kiệm ngân sách và các ngoại lệ áp dụng

• Những người bảo trợ dự luật ước tính chính phủ liên bang chi khoảng 12 tỷ USD mỗi năm cho việc mua phần mềm
• SHARE IT Act là đạo luật nhằm giảm chi phí này thông qua việc tái sử dụng mã tùy chỉnh
• Các loại mã sau được loại trừ khỏi phạm vi áp dụng của luật
  • Mã mật
  • Hệ thống an ninh quốc gia
  • Mã có thể phát sinh rủi ro về quyền riêng tư nếu được chia sẻ

Nghĩa vụ của CIO cơ quan trong việc xây dựng chính sách trong 180 ngày

• Giám đốc thông tin (CIO) của cơ quan phải lập chính sách triển khai SHARE IT Act trong vòng 180 ngày kể từ khi luật có hiệu lực
• Chính sách phải bao gồm các quy trình sau
  • Quy trình đảm bảo mã được phát triển tùy chỉnh phù hợp với thực hành tốt nhất
  • Quy trình công khai metadata của mã tùy chỉnh
  • Quy trình báo cáo được chuẩn hóa

Metadata cần công khai

• Metadata được luật đề cập bao gồm thông tin giúp xác nhận trạng thái phát triển và chia sẻ của mã tùy chỉnh
• Các mục bao gồm như sau
  • Mã tùy chỉnh có được phát triển theo hợp đồng hay không
  • Mã đã được chia sẻ trong kho lưu trữ hay chưa
  • Số hợp đồng
  • Siêu liên kết đến kho lưu trữ nơi mã được chia sẻ

Quá trình lập pháp và sự ủng hộ từ ngành

• Dự luật được Ted Cruz và Gary Peters bảo trợ tại Thượng viện, và Nicholas Langworthy cùng William Timmons bảo trợ tại Hạ viện
• Thượng viện và Hạ viện đã thông qua dự luật trong tháng 12 mà không có cuộc bỏ phiếu thuận/chống được ghi danh
• Theo thông báo của Langworthy về việc trình dự luật tại Hạ viện hồi tháng 9, Atlassian và GitLab Inc. đã ủng hộ dự luật
• Stan Shepard, Giám đốc pháp lý của Atlassian, cho rằng việc mở rộng hợp tác và chia sẻ mã tùy chỉnh sẽ thúc đẩy tính cởi mở, hiệu quả và đổi mới trên toàn bộ các tổ chức liên bang

[GN⁺]

Các ý kiến trên Hacker News

• Nếu chưa từng có kinh nghiệm trong chính phủ, có thể bạn sẽ không hình dung được vì sao việc này lại khó đến vậy. Quân đội dị ứng với phần mềm nội bộ, và CNTT quân sự là một thế giới hoàn toàn khác, hằng ngày bị những kẻ xâm nhập được nhà nước hậu thuẫn thuộc hàng giỏi nhất thế giới tấn công
  Startup không gặp những chuyện như vậy, và ngay cả các tập đoàn lớn như Facebook cũng chỉ vừa chạm tới mức tương tự xét về độ quan trọng; trong khu vực tư nhân, nơi gần nhất có lẽ là các định chế tài chính lớn. Quân đội Mỹ cũng là một chủ lao động đơn lẻ lớn nhất hành tinh, tương đương 4,5 lần Walmart
  Vì thế quân đội giám sát mọi thứ ở nhiều tầng, và khóa chặt bằng danh sách phần mềm được phê duyệt theo từng tầng. Những người viết hoặc giám sát chính sách bảo mật nhiều khả năng không phải là các giám đốc phần mềm dày dạn, và khi nhìn vào NPM hay Maven, họ xem đó là các vector tấn công vô hạn do những người không hiểu bảo mật tạo ra — nói vậy cũng không sai
  Trong khu vực tư nhân và nhà thầu, quyền sở hữu mã cũng phức tạp. Nếu được tạo ra bằng tiền của chính phủ thì lẽ ra phải thuộc sở hữu chính phủ, nhưng các nhà thầu lại cho rằng họ cần giữ nó như tài sản riêng tách khỏi chính phủ để có thể tính phí lại. Nếu nhà thầu phụ không khớp với mục tiêu tài chính của nhà thầu chính thì còn phức tạp hơn. Cá nhân tôi nghĩ cứ bàn giao hết cho chính phủ là xong, nhưng thật kỳ lạ khi người ta dựng lên hết lớp rào cản này đến lớp khác. Hạ tầng phía chính phủ có mức chứng nhận bảo mật cao hơn nhiều, nên nhìn chung cũng ít bị hạn chế hơn

  • Việc mô tả CNTT quân sự gần như bất khả xâm phạm đã bỏ qua thực tế rằng hạ tầng cũ kỹ và các chính sách trì trệ làm giảm hiệu quả rất lớn
    Một số lĩnh vực của quân đội Mỹ có thể đang đối mặt với mức đe dọa và độ tinh vi bảo mật như đã mô tả, nhưng nhìn tổng thể thì có rất nhiều hệ thống legacy khó tích hợp các giải pháp hiện đại hay best practice. Những hệ thống, quy trình làm việc và bộ máy quan liêu lỗi thời như vậy dễ tạo ra sự kém hiệu quả và lỗ hổng hơn là bảo mật xuất sắc
    Bạn không nghe chuyện quân đội Mỹ bị xâm phạm không phải vì chuyện đó không xảy ra, mà vì nếu xảy ra thì sẽ được xếp mật. Tránh bẽ mặt công khai là công dụng số một của việc xếp loại mật, nên mới tạo ra niềm tin rằng họ có năng lực. Nếu là tôi, bất cứ lúc nào tôi cũng sẽ xếp bảo mật của Facebook cao hơn quân đội Mỹ, và tôi nghĩ khoảng cách cũng không nhỏ. Facebook còn là một đơn vị xử lý thanh toán nữa
  • Tôi khó đồng ý với câu “các tập đoàn lớn như Facebook chỉ gặp chuyện tương tự vì không đủ quan trọng”. Khi còn làm ở Microsoft và nói chuyện với đội bảo mật, tôi có ấn tượng rằng MSFT liên tục hứng chịu các cuộc tấn công cấp quốc gia, bao gồm cả những nỗ lực đưa tài sản của chính phủ vào làm việc tại Microsoft để lấy cắp bí mật
    Xét đến tầm quan trọng của AWS, chắc chắn Amazon cũng đang đối mặt với các mối đe dọa tương tự
  • Theo tôi, dự luật này gần như không liên quan mấy đến quân đội. Trong dự luật thực tế có nói rằng mã nguồn mật hoặc mã nguồn cho hệ thống an ninh quốc gia không thuộc phạm vi áp dụng
    (A) Điều khoản chung—Luật này không áp dụng cho mã nguồn mật hoặc mã nguồn được phát triển chủ yếu để sử dụng trong hệ thống an ninh quốc gia như được định nghĩa tại 40 U.S.C. 11103
    (B) An ninh quốc gia—Việc miễn trừ các yêu cầu tại điều 3 áp dụng cho mã nguồn mật hoặc mã nguồn sau: (i) mã được phát triển chủ yếu để sử dụng trong hệ thống an ninh quốc gia, hoặc (ii) mã do một cơ quan thành viên của cộng đồng tình báo, hoặc một bộ phận của cơ quan đó, như được định nghĩa tại mục 3(4) của Đạo luật An ninh Quốc gia năm 1947, phát triển
  • Sau một năm nói chuyện với đội bảo mật của bộ phận tôi, quanh bộ phận khách hàng, mạng lưới nhà thầu địa phương và nhiều nhà cung cấp, tôi bỏ làm hợp đồng khi thấy một quân chủng khác đã hoàn thành đúng thứ giống hệt dự án của tôi từ vài năm trước, và khi tôi nói “sao không nói chuyện với bên đó?” thì khách hàng chính phủ chỉ nhìn tôi ngơ ngác
    Khi đó tôi hiểu ngành kinh doanh hợp đồng chính phủ vận hành theo cấu trúc nào, và vì sao công việc lại kéo dài thêm nhiều năm so với mức cần thiết
  • Tôi đồng cảm với ý tưởng “cứ bàn giao hết cho chính phủ là được”. Thực tế tôi từng làm ở một nhà thầu nơi khách hàng sở hữu mọi sản phẩm bàn giao, nên nhìn các đồng nghiệp làm ở những nhà thầu không như vậy lúc nào cũng thấy lạ
    Đó là tiền thuế của chúng ta, vậy tại sao lại cổ vũ cho việc rút tiền khỏi túi mọi người để làm cho vài nhân vật lớn và đội ngũ bán hàng của công ty giàu lên đáng kể?
    Nếu lập trường là “sẽ không giao mọi thứ cho chính phủ”, thì theo tôi cách hợp lý là trao cho chính phủ quyền sử dụng sản phẩm bàn giao theo ý họ muốn, đồng thời cho phép tự do bán các thành phần không mật và các sản phẩm phái sinh của chúng cho khu vực tư nhân

• Luật yêu cầu CIO của các cơ quan phải xây dựng chính sách trong vòng 180 ngày sau khi có hiệu lực; chính sách đó phải bảo đảm mã được phát triển tùy chỉnh phù hợp với các thông lệ tốt nhất, đồng thời quy định quy trình công bố metadata của mã tùy chỉnh và quy trình báo cáo chuẩn
  Trong luật mới, metadata bao gồm việc mã tùy chỉnh có được phát triển theo hợp đồng hay không, có được chia sẻ trong kho lưu trữ hay không, số hợp đồng, và liên kết tới kho lưu trữ nơi mã được chia sẻ
  Đáng tiếc là luật này dường như không yêu cầu các cơ quan biến mã thành mã nguồn mở công khai, mà chỉ yêu cầu chia sẻ giữa các cơ quan. Thứ phải chia sẻ công khai chỉ là “metadata”. Toàn văn dự luật có tại https://www.congress.gov/bill/118th-congress/house-bill/9566...

  • Đây là một bước khởi đầu tốt. Bước tiếp theo có lẽ là chia sẻ với chính quyền bang, địa phương và các trường đại học. Chia sẻ công khai sẽ phân tán nhiều trách nhiệm IT hiện nay chưa tồn tại
  • Chỉ nhìn tiêu đề được đăng lên thôi thì mức đó cũng đã khá rõ rồi
  • Cứ thấy cụm “thông lệ tốt nhất” là tôi bắt đầu nghi ngờ, vì rất có khả năng nó sẽ càng thúc đẩy kiểu sùng bái hàng hóa mang tính quan liêu
  • Phần lớn hợp đồng của DOE, tức các hợp đồng chính phủ ký với các trường đại học hoặc consortium vận hành phòng thí nghiệm, thường có nội dung kiểu như “mã nguồn này có thể được giữ kín hoặc công bố dưới dạng mã nguồn mở nếu không chứng minh được rằng nó có khả năng thương mại hóa hoặc có giá trị SBIR. Nhưng không được dùng GPL”
    Có ngoại lệ, nhưng cũng từng có lập luận rằng các nhà thầu khác phải duy trì khả năng sửa mã nguồn và tương tự là không công bố nó. Tôi đoán có lẽ là vì lĩnh vực quốc phòng
    Nếu muốn giữ kín vì tiền thì tiêu chuẩn khá cao, nhưng luôn có thể giữ kín vì bất kỳ lý do nào khác. DOE Code là chương trình theo dõi phần mềm mã nguồn mở và thường được quản lý thông qua các tổ chức GitHub. OSTI là bộ phận theo dõi toàn bộ sở hữu trí tuệ và nghiên cứu
  • Một số thứ như ZFSOnLinux đã được chia sẻ công khai rồi. Kho lưu trữ nay đã trở thành kho OpenZFS và giúp cuộc sống của rất nhiều người tốt hơn. Cuộc sống của tôi cũng dễ dàng hơn
    Mô hình phát triển mã nguồn mở cũng có lợi cho LLNL, và họ có được một codebase tốt hơn nhiều so với khi tự phát triển một mình
    Cũng có những thứ đã công khai như NASA IKOS: https://github.com/NASA-SW-VnV/ikos
    Dự án này đang nhận được ít sự chú ý từ bên thứ ba hơn nhiều so với mức nó đáng được nhận. Nếu nó có thể phát triển thành một trình phân tích tĩnh sound, đa dụng, xử lý được multithreading, thì sẽ giúp cải thiện rất nhiều dự án khác

• Tôi từng thúc đẩy một mô hình mã nguồn mở hoàn toàn với suy nghĩ rằng “nếu dùng ngân sách công, công chúng phải được xem kết quả tạo ra từ khoản tiền đó”: https://web.archive.org/web/20200920095030/http://oss4gov.or...
  Tôi cho rằng mặc định của phần mềm chính phủ nên là mã nguồn mở, trừ khi có ngoại lệ được phê duyệt ở cấp bộ trưởng. Nhưng hồi đó tôi còn trẻ và ngây thơ

  • Tôi không thấy chuyện đó gây tranh cãi đến vậy. Chính phủ Anh cũng nhìn nhận tương tự: https://www.gov.uk/service-manual/technology/making-source-c...
  • Tôi đã làm nhiều năm trong một nhà thầu quân sự, và có rất nhiều người tin rằng nếu người nộp thuế chi tiền và phần mềm không phải là bí mật thì nó nên là mã nguồn mở
    Ghidra là một ví dụ tốt, và việc phần mềm này trở nên miễn phí là một lợi ích lớn cho cộng đồng bảo mật
  • FSFE ở bên kia Đại Tây Dương cũng có cùng suy nghĩ: https://publiccode.eu/en/
  • Không phải là ngây thơ, mà là đi trước thời đại. Tiến bộ là công việc nhọc nhằn và là một cuộc marathon

• Chúng tôi tạo phần mềm mã nguồn mở và cố gắng để các cơ quan chính phủ chấp nhận hoặc sử dụng, nhưng mức độ các cơ quan này dị ứng với mã nguồn mở thật đáng kinh ngạc
  Có nơi thà tự làm theo các cách legacy như upload CSV hoặc parser hỏng, rồi tạo ra cả những bug và khiếm khuyết có thể dự đoán được, còn hơn dùng mã của người khác
  Ngay cả khi trả lời RFP, phía mã nguồn mở cũng bị soi xét khắt khe hơn hệ thống đóng. Nếu công khai thì bạn phải chứng minh rằng điều đó là tốt, còn nếu đóng thì vendor chỉ cần nói “vâng, hoàn hảo” và cơ quan có thể cho qua. Có cảm giác các cơ quan và nhân viên không muốn chịu bất kỳ trách nhiệm nào. Dù vậy, tôi chưa từng thấy ai mất việc trong chính phủ vì kém năng lực

  • Ở bức tranh lớn là chủ nghĩa bảo hộ việc làm, còn ở cấp cá nhân là một cấu trúc khuyến khích người ta trở thành chuyên gia chủ đề về codebase của riêng mình để dùng nó cho việc thăng tiến. Thông thường các cơ quan không xem nhau là cùng một đội. Khi vận động Quốc hội để giành nguồn lực cho cơ quan của mình, họ có thể cạnh tranh rất gay gắt
    Tôi đang làm trong chính phủ và đã trực tiếp trải nghiệm điều đó. Văn hóa rất độc hại và hỏng hóc. Tôi mong chờ xem đội của Elon và Trump sẽ đề xuất những thay đổi gì
  • Với mã nguồn mở thì không thể quy trách nhiệm cho ai. Còn với phần mềm đóng, khi có chuyện trục trặc thì có đối tượng để chỉ tay đổ lỗi

• Bộ Quốc phòng Mỹ có FAQ về phần mềm nguồn mở: http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx và https://github.com/risacher/DoD-OSS-FAQ
  Phiên bản này được đăng trên GitHub như một thử nghiệm công cụ cộng tác để công chúng tham gia vào tài liệu chính sách của chính phủ, và nói rằng nhân sự quân sự/dân sự, nhà thầu và người dân có thể gửi đề xuất thay đổi hoặc bổ sung bằng pull request
  Video năm 2010: https://www.youtube.com/watch?v=WWt0YiXcEkE
  Dan Risacher từ văn phòng DoD CIO và chuyên gia bảo mật nguồn mở David A. Wheeler giải thích lịch sử và tác động của một bản ghi nhớ gần đây của DoD, trong đó làm rõ lập trường rằng Bộ Quốc phòng xem nguồn mở là một dạng phần mềm thương mại khả thi
  Tài liệu năm 2024: https://openssf.org/press-release/2024/10/29/openssf-expands...
  OpenSSF của Linux Foundation cho biết họ nhận thấy nhu cầu đào tạo về bảo mật; theo David A. Wheeler, Giám đốc bảo mật chuỗi cung ứng nguồn mở của OpenSSF, hơn 25.000 người đã đăng ký các tài liệu đào tạo này kể từ khi khóa học bắt đầu

• Ý định thì tốt, nhưng thực tế có lẽ sẽ chẳng có gì nhiều xảy ra ngoài việc các đối thủ tiềm năng của nhà thầu 1 thu hẹp khoảng cách hoặc công kích dựa trên chất lượng code của hợp đồng hiện tại. Đọc code còn khó hơn viết code

  • Nếu các đối thủ tiềm năng thu hẹp được khoảng cách, thì với chính phủ đó là tăng cạnh tranh và giảm chi phí
    Nếu họ công kích dựa trên chất lượng code của hợp đồng hiện tại, thì đó là code review, và kiểu gì cũng dẫn đến cải thiện chất lượng code. Không rõ vấn đề ở đây là gì

• Đây là điều tuyệt vời. Tôi nhớ từng chật vật vì không thể đọc code ngay cả trong cùng một tổ chức. Thay đổi như vậy có vẻ sẽ giúp những người xây dựng mô hình tư duy từ trên xuống làm việc dễ dàng hơn

• Nói chung, mọi thứ được chi trả bằng tiền thuế của dân đều nên được công khai. Public Monies Public Goods phải là nguyên tắc nền tảng tuyệt đối

  • Quy tắc đó đã có rồi, nhưng chỉ DoD là cơ quan nghiêm túc thực hiện. Ví dụ có BRL-CAD và FalconView
    Dù vậy, điều đó không ngăn được các nhà thầu vô đạo đức gắn bản quyền lên code và thu phí giấy phép. Phần lớn code của DoE là như vậy, ngoại lệ như NWCHEM. Tôi luôn thắc mắc vì sao chuyện này chưa dẫn tới kiện tụng, có lẽ vì chẳng ai thật sự quan tâm nhiều
  • Thật thú vị là một số chính quyền địa phương đặt bản quyền cho luật của mình để chính quyền địa phương khác không thể sao chép miễn phí
    Một mặt, cũng có thể hiểu khi họ xem việc khu vực khác hưởng lợi miễn phí từ hệ thống quy định do người nộp thuế của địa phương đó chi trả là không công bằng, nhất là nếu luật đó chủ yếu áp dụng cho chính quyền địa phương ở khu vực ấy. Mặt khác, việc luật bị hạn chế bằng bản quyền nghe vẫn kỳ lạ
  • Không đồng ý. Vì Trung Quốc. Chính phủ Mỹ phải giữ code của mình ở chế độ không công khai, kể cả đống code rác từ các nhà thầu đắt đỏ một cách tệ hại
  • Với phần mềm thì tôi không đồng ý
  • Ý là công khai tất cả, từ tài liệu mật đến bản ghi nhớ văn phòng và hồ sơ nhân sự sao? Chuyện đó sẽ không xảy ra
    Cũng nên nghĩ xem khi bạn thuê ai đó làm việc ở nhà, ngoài sản phẩm cuối cùng thì chính xác bạn sở hữu những gì

• Đây là một hướng đi rất tốt. Khi làm việc với các đội ngũ chính phủ, tôi từng thấy cách này được nêu như một thông lệ được khuyến khích: https://www.forgov.qld.gov.au/information-and-communication-...
  Tuy nhiên, trong nhiều trường hợp, để khuyến nghị đó thật sự được tuân thủ vẫn cần bước luật hóa thành yêu cầu. Điều này đặc biệt đúng trong dịch vụ công, nơi không hiếm người chưa từng tham gia cộng đồng nguồn mở
  Như những người khác đã nhấn mạnh, ngân sách công phải dẫn đến lợi ích công, và nguồn mở là một cách tốt để mở rộng lợi ích đó

• Có câu “Luật mới không áp dụng cho code mật, hệ thống an ninh quốc gia, hoặc code mà việc chia sẻ có thể gây rủi ro về quyền riêng tư”
  Code gây rủi ro quyền riêng tư khi chia sẻ rốt cuộc là loại code nào? Nghe như code và dữ liệu bị trộn lẫn khá tệ

  • Không có rủi ro thực sự, nhưng nó tạo ra một cái cớ tốt để không công khai. Các công ty và cơ quan chính phủ từng từ chối yêu cầu công khai thông tin đối với tài liệu kỹ thuật với lý do bảo vệ quyền riêng tư. Kiểu như “áp dụng cho hệ thống xử lý dữ liệu cá nhân”, hoặc “nếu biết cơ chế hoạt động bên trong hệ thống thì khả năng hệ thống bị xâm phạm sẽ tăng lên”
    Các nhà thầu chính phủ sẵn sàng thừa nhận giữa các dòng rằng code của họ tệ hại và phần lớn dựa vào bảo mật bằng che giấu. Ủy ban thông tin cũng đã vài lần đứng về phía họ
  • Code được tùy biến đủ nhiều sẽ có các chức năng tiết lộ nhiều thông tin về nghiệp vụ mục tiêu
    Chẳng hạn, cứ nghĩ xem bạn có thể thấy gì trong các công thức Excel
  • Không có khác biệt giữa hai thứ đó