054.3 Bài 1

Giấy phép phần mềm mã nguồn mở và tự do phải được coi trọng ngang với các giấy phép và hợp đồng khác. Các tổ chức thực thi chúng (như Tổ chức Bảo vệ Quyền Tự do Phần mềm) sẽ hoạt động thay mặt cho các dự án copyleft nhỏ lẻ không có cơ chế thực thi riêng.

Các tổ chức này thường coi việc kiện cáo như giải pháp cuối cùng. Hầu hết các vi phạm thường đều là vô tình và có thể dễ dàng giải quyết thông qua việc phổ cập kiến thức. Tuy vậy, việc một tổ chức bị coi là thiếu hiểu biết và vô cảm đối với các cộng đồng mà phần mềm của tổ chức đó phụ thuộc vào vẫn sẽ gây ảnh hưởng đến danh tiếng của chính tổ chức đó.

Có rất nhiều vụ kiện thực sự đã xảy ra khi một người dùng phần mềm từ chối hợp tác một cách trắng trợn và khi phần mềm và bên bị đơn đủ quan trọng.

Ngay cả khi một tổ chức không phải đối mặt với một vụ kiện, thiệt hại mà hành vi vi phạm giấy phép gây ra cho mối quan hệ của tổ chức đó với cộng đồng cũng như là danh tiếng của tổ chức có thể là rất lớn. Một dự án có thể đi lệch khỏi quỹ đạo bởi một chuyện đơn giản như việc các câu hỏi của nhà phát triển không được trả lời trên các diễn đàn dành riêng cho phần mềm mà họ đang cố gắng sử dụng.

Nó có thể sẽ trở thành một thảm họa đối với một cá nhân nào đó khi họ tìm thấy phần mềm copyleft trong một sản phẩm độc quyền. Để tuân thủ giấy phép, các nhà phát triển sẽ phải loại bỏ toàn bộ mã copyleft hoặc là giải phóng sản phẩm của họ theo giấy phép copyleft. Việc cung cấp phần mềm tự do với mã nguồn có sẵn có thể gây ra những tác động nghiêm trọng đến các mô hình kinh doanh dựa trên phí cấp phép hoặc các phương thức khác nhằm nắm giữ độc quyền giá trị của sản phẩm.

Chúng ta đã thấy rằng việc vi phạm giấy phép có thể gây ra các thiệt hại rất lớn. Các loại hành vi khác làm mất lòng tin và danh tiếng cũng có thể gây ra nhiều rủi ro.

Có một số tổ chức phát hành phần mềm theo giấy phép phần mềm mã nguồn mở hoặc tự do, sau đó tại một thời điểm nào đó lại thông báo rằng các phiên bản trong tương lai sẽ được phát hành theo giấy phép độc quyền. Sự thay đổi này có thể sẽ khá hấp dẫn vì nhiều dự án nguồn mã mở không có đủ khách hàng và từ đó không có được đủ hỗ trợ về mặt tài chính.

Nhưng những thay đổi về giấy phép như vậy sẽ gây ra bất mãn cho cả phía khách hàng lẫn phía các nhà phát triển bên ngoài đóng góp vào dự án. Đôi khi, các nhà phát triển bên ngoài sẽ sử dụng phiên bản tự do và tiếp tục phát triển độc lập — phương hướng phát triển được gọi là phân nhánh (fork) dự án. Phiên bản tự do có thể sẽ trở nên cạnh tranh hơn so với phiên bản độc quyền của công ty và thu hút khách hàng rời xa công ty.

Việc tham gia diễn đàn dự án cũng có thể có rủi ro. Một công ty phải học cách để trở thành một công dân tốt. Các vấn đề phổ biến gồm có:

Các mô hình kinh doanh sẽ được thảo luận trong bài học khác; phần này sẽ chỉ tập trung lưu ý đến rủi ro tài chính khi tham gia vào các dự án mã nguồn mở.

Các công ty có thể bắt đầu hoặc tham gia các dự án mã nguồn mở với kỳ vọng thu được doanh thu thông qua một số cơ chế như hợp đồng hỗ trợ, hợp đồng SaaS, thu thập dữ liệu hoặc thậm chí là quyên góp và tài trợ. Thật không may, những người thực hiện các dự án mã nguồn mở thường thấy được rằng chúng ít sinh lợi hơn so với mong đợi. Tất nhiên bất kỳ doanh nghiệp nào cũng phải chấp nhận rủi ro khi bắt đầu một dự án mới, nhưng mã nguồn mở lại là lĩnh vực đặc biệt khó để tìm được một nguồn thu nhập đáng tin cậy.

Mã nguồn mở có vẻ bền vững nhất khi nó hỗ trợ một số hình thức thu nhập khác, chẳng hạn như việc bán thiết bị phần cứng, ô tô, máy in, v.v.

Như chúng ta đã thấy, các thành viên của một dự án đôi khi sẽ không thể thống nhất về lộ trình, tư cách lãnh đạo hoặc các khía cạnh khác của dự án và tạo ra một dự án thay thế trên cùng một cơ sở mã. Việc phân nhánh (forking) cũng có thể được thực hiện bởi một tổ chức để tạo ra một phiên bản chuyên biệt của phần mềm. Ví dụ: Android đã sử dụng một phiên bản Linux chuyên biệt do Google duy trì (Google cũng đóng góp rất nhiều cho phiên bản cốt lõi của Linux nhưng không phải lúc nào chúng cũng được chấp nhận).

Các tổ chức có thể tạo ra một nhánh vì nhiều lý do khác nhau. Họ có thể gửi các thay đổi của mình cho dự án cốt lõi và bị từ chối vì các nhà phát triển khác không thích chúng. Trong một dự án có giấy phép linh hoạt hoặc một dự án chỉ được sử dụng trong tổ chức, họ có thể sẽ muốn giữ bí mật về các thay đổi của mình.

Rủi ro của việc phânnhánh là các nhà phát triển của dự án nhánh sẽ phải chịu trách nhiệm bảo trì toàn bộ sản phẩm. Nếu các bản sửa lỗi quan trọng hoặc các tính năng mới được thêm vào dự án cốt lõi, các nhà phát triển của dự án nhánh sẽ phải sao chép các thay đổi hoặc từ bỏ các lợi ích từ chúng. Dần dần khi thời gian trôi qua và các dự án ngày càng tách biệt nhau, việc theo kịp các thay đổi trong dự án cốt lõi sẽ trở nên ngày càng khó khăn hơn.

Như đã giải thích trong các bài học khác, một số giấy phép phần mềm mã nguồn mở và tự do sẽ có các điều khoản không tương thích. Các thành phần như vậy không thể được sử dụng cùng nhau trong một sản phẩm.

Vấn đề này thường phát sinh trong quá trình sáp nhập hoặc mua lại. Có thể là mỗi công ty đã sử dụng phần mềm với một giấy phép cụ thể và nếu họ muốn kết hợp mã trong các dự án của mình, họ phải đảm bảo rằng các giấy phép tương thích với nhau.

Nhiều giấy phép phần mềm mã nguồn mở (và các điều khoản dịch vụ cho nhiều phần mềm và dịch vụ độc quyền) từ chối triệt để mọi trách nhiệm pháp lý đối với việc sử dụng phần mềm. Nói cách khác, giấy phép hoặc các điều khoản dịch vụ không cung cấp bất kỳ hình thức bảo hành hoặc đảm bảo nào.

Các nhà cung cấp phần mềm hiếm khi phải chịu trách nhiệm về các vấn đề liên quan đến phần mềm của họ, nhưng khách hàng đôi khi vẫn sẽ kiện họ hoặc thử các hình thức trừng phạt khác. Tòa án sẽ không cần phải công nhận các điều khoản “không bảo hành”.

Ngày càng có nhiều luật lệ và quy định áp đặt trách nhiệm lên các nhà sáng tạo phần mềm. Có thể thấy được những hạn chế pháp lý này — hoặc ít nhất là các đề xuất về hạn chế — hiện đang đặc biệt nhắm tới trí tuệ nhân tạo; tuy vậy, đôi khi những hạn chế này cũng được áp dụng trong một phạm vi rộng hơn.

Có rất nhiều quốc gia hạn chế xuất khẩu hàng hóa và phần mềm. Đối với phần mềm, các quy định như vậy thường áp dụng cho các sản phẩm bảo mật và cụ thể là việc sử dụng mật mã. Hoa Kỳ từng kiểm soát rất chặt chẽ bất kỳ phần mềm nào có chứa mật mã, nhưng các biện pháp kiểm soát đã được nới lỏng đối với các dự án mã nguồn mở.

Các công ty nên lưu ý đến các quy định xuất khẩu tại nơi họ đang phát triển phần mềm trong trường hợp các quy định này ảnh hưởng đến việc bán và phân phối sản phẩm của họ.

Vì môi trường máy tính sử dụng số lượng thành phần rất lớn (đôi khi là hàng chục nghìn) và thay đổi thường xuyên, SBOM phải có cấu trúc cực kỳ tốt để thông tin có thể được trích xuất tự động và nhanh chóng. Ở phần này, chúng ta sẽ tìm hiểu hai định dạng phổ biến nhất trong thế giới mã nguồn mở:

Cả SPDX và CycloneDX đều tạo ra các cấu trúc phân cấp ở nhiều định dạng khác nhau bao gồm JSON và XML. Có nhiều công cụ cho từng tiêu chuẩn, vừa để tạo định dạng, vừa để quét các tệp đã tạo để tìm kiếm thông tin. Các trang kho lưu trữ kiểm soát phiên bản phổ biến sẽ cho phép các nhà phát triển tạo SBOM ở một trong các định dạng này chỉ với một cú nhấp chuột.

Để biết một tổ chức đang sử dụng phần mềm nào, chúng ta cần phải đánh giá phần mềm của tổ chức đó. Đánh giá này sẽ bao gồm cả thông tin về nguồn gốc của phần mềm, các lỗ hổng mà phần mềm có, các giấy phép mà phần mềm sử dụng cũng như nhiều yếu tố khác giúp các cá nhân hoặc tổ chức quyết định xem có nên sử dụng phần mềm hay không. Nhiệm vụ này được gọi là Phân tích Thành phần Phần mềm (Software Composition Analysis - SCA); hiện này có rất nhiều công cụ có sẵn phục vụ việc quét một cách chi tiết các SBOM và chính bản thân phần mềm.

Một số công cụ sẽ trích xuất thông tin giấy phép để giúp tổ chức quyết định xem phần mềm có an toàn để đưa vào sản phẩm hay không, và liệu các thành phần có giấy phép tương thích với nhau hay không. Một số công cụ thậm chí còn so sánh các đoạn mã với các thư viện của nhiều dự án mã nguồn mở phổ biến để tìm hiểu xem mã có được lấy từ các dự án mã nguồn mở mà không ghi công tác giả một cách phù hợp hay không.

Việc chạy các công cụ này đặc biệt quan trọng trong quá trình sáp nhập hoặc mua lại. Công ty mua lại có thể sẽ thấy được rằng phần mềm mà họ muốn mua lại có giá trị không được như mong đợi vì nó có chứa các thành phần mã nguồn mở áp đặt nhiều yêu cầu can thiệp vào mục đích sử dụng dự kiến ​​của nó trong công ty/ tổ chức mới.

Các tổ chức có thể được hưởng lợi rất nhiều từ việc sử dụng và đóng góp vào phần mềm mã nguồn mở, nhưng họ cũng cần phải làm việc này theo một số cách nhất định để bảo vệ lợi ích của chính họ cũng như mang lại lợi ích cho các dự án mã nguồn mở. Các chính sách nên được xác định cho:

OSPO có thể phối hợp xây dựng các chính sách này với các quy trình đào tạo để đảm bảo việc tuân thủ.

Các dự án mã nguồn mở cần đảm bảo rằng các đóng góp đều hợp pháp. Ví dụ: mã không được lấy từ một số sản phẩm độc quyền hoặc một dự án mã nguồn mở có giấy phép không tương thích. Nhiều dự án mã nguồn mở sẽ yêu cầu các nhà phát triển cung cấp một tài liệu được gọi là Thỏa thuận Cấp phép của Nhà phát triển Đóng góp (Contributor License Agreement - CLA) để đảm bảo tính hợp pháp của những đóng góp từ họ.

Các nhà phát triển tại một tổ chức đóng góp vào các dự án này có thể yêu cầu luật sư của tổ chức xem xét và phê duyệt CLA. Do đó, các luật sư nên hiểu được tính thích đáng của các điều khoản CLA và sẵn sàng cho việc kiểm tra chúng.

CLA nhận về nhiều lời chỉ trích cả về cả tính phức tạp của chúng lẫn những lỗ hổng mà chúng để lại khiến các dự án sử dụng mã được đóng góp theo cách mà các nhà phát triển đóng góp không mong muốn.

Nhiều dự án sẽ yêu cầu nhà phát triển ký một tài liệu ngắn được gọi là Chứng chỉ Nguồn gốc của Nhà phát triển (Developer Certificate of Origin - DCO) thay vì CLA để chứng thực rằng nhà phát triển có quyền đóng góp mã. DCO (sẽ được thảo luận tới trong bài học khác) thường không được thông qua luật sư.

Một số dự án sẽ chỉ yêu cầu các nhà phát triển đóng góp ký chuyển bản quyền mã của họ cho dự án trong Thỏa thuận Chuyển nhượng Bản quyền (Copyright Assignment Agreement - CAA). Tuy nhiên, nhiều nhà phát triển đóng góp lại không thích cách làm này vì họ không thể sử dụng mã trong một số dự án độc quyền của riêng họ cũng như vì nó trao quá nhiều quyền cho dự án.

Các dự án mã nguồn mở thường kết hợp các yếu tố xã hội, kỹ thuật, pháp lý và tổ chức khác biệt so với bình thường. Hiện tại, kiến ​​thức về các yếu tố này ở trong các tổ chức vẫn chưa được lan toả đến tất cả các nhà quản lý, nhà phát triển, luật sư và những người khác để họ đều có thể hiểu một cách sâu sắc về chúng. Vì vậy, việc tạo ra Văn phòng Chương trình Mã nguồn Mở (OSPO) như một tụ điểm trung tâm cho các hoạt động vận động, hoạch định chính sách, thực thi chính sách và đào tạo sẽ rất có ích cho các tổ chức.

Là một loại phòng ban đa năng, OSPO có thể thực hiện nhiều vai trò như:

Có rất nhiều tài liệu và nguồn trực tuyến về việc tạo OSPO. Một tổ chức nhỏ có thể giao nhiệm vụ này cho một bên thứ ba có chuyên môn trong lĩnh vực.