Tại sao tôi chuyển sang giấy phép EUPL sau 28 năm viết phần mềm

Sau gần ba thập kỷ phát hành phần mềm, tôi đã trải qua ba thời kỳ cấp phép khác nhau. Giờ đây, mọi sản phẩm mới của tôi đều được phát hành dưới European Union Public License 1.2 (EUPL) — và tôi muốn giải thích lý do vì sao.

Bài viết của Henri Bergius — nhà phát triển kỳ cựu người Phần Lan, người sáng lập Flowhub và là một trong những người tiên phong trong lĩnh vực lập trình dòng dữ liệu (flow-based programming) — không chỉ là câu chuyện cá nhân mà còn phản ánh một xu hướng đang dâng cao trong cộng đồng mã nguồn mở: sự quay lưng với các giấy phép permissive (dễ dãi) để tìm đến các giấy phép copyleft mạnh hơn nhằm bảo vệ công sức của người phát triển.

Cờ Liên minh châu Âu — biểu tượng của giấy phép EUPL

Hành trình từ LGPL đến MIT rồi EUPL

Ở giai đoạn đầu sự nghiệp, tôi phát triển Midgard — một web framework — và sử dụng giấy phép LGPLv2. Đó là thời kỳ đơn giản khi số lượng giấy phép mã nguồn mở còn ít, và bản quyền yếu (weak copyleft) là lựa chọn hợp lý cho một công cụ dành cho nhà phát triển web.

Bước sang giai đoạn làm việc nghiêm túc với JavaScript từ khoảng năm 2011, tôi chuyển sang giấy phép MIT. Đây là kiểu giấy phép “làm gì tùy bạn, chỉ cần đừng kiện tôi” — một lựa chọn phổ biến trong hệ sinh thái NPM nhờ tính dễ dàng tương tác giữa các thư viện.

Sau khi đóng cửa Flowhub, tôi gần như ngừng xuất bản phần mềm trong vài năm — một phần vì công việc, một phần vì niềm đam mê với con thuyền. Nhưng năm nay, tôi quyết định thay đổi “giấy phép mặc định” của mình sang EUPL-1.2.

EUPL — lựa chọn mới đầy tính chiến lược

EUPL là giấy phép phần mềm tự do được OSI công nhận, do Liên minh châu Âu tạo ra và phát hành. Điểm khác biệt lớn nhất so với các giấy phép tôi từng dùng trước đây nằm ở hai yếu tố:

• Đây là một giấy phép copyleft mạnh (strong copyleft), yêu cầu các dẫn xuất phải được cấp phép lại theo cùng điều khoản.
• EUPL bịt kín “lỗ hổng SaaS” — nghĩa là ngay cả khi phần mềm chỉ được cung cấp qua dịch vụ đám mây (không phân phối mã nguồn trực tiếp), nhà cung cấp vẫn phải tuân thủ nghĩa vụ chia sẻ ngược lại.

Quan trọng hơn, EUPL có bản dịch chính thức có giá trị pháp lý sang 23 ngôn ngữ — điều hiếm thấy ở các giấy phép khác — đặc biệt hữu ích trong bối cảnh phần mềm ngày nay được xây dựng và sử dụng trên toàn thế giới, không chỉ riêng tại Thung lũng Silicon.

Vì sao tôi rời bỏ phe “mã nguồn mở dễ dãi”

Quan điểm của tôi đã thay đổi sau nhiều năm quan sát ngành công nghiệp:

“Chúng tôi — những người thuộc phe ‘mã nguồn mở’ — đã sai suốt từ đầu. Chúng tôi thắng cuộc tranh luận, nhưng người dùng và lập trình viên chẳng thu được lợi ích gì nhiều. Tất cả những gì chúng tôi làm chỉ giúp các tập đoàn lớn xây dựng sản phẩm rẻ hơn và giúp tỷ phú trở thành triệu phú.”

Đây là một lời cảnh tỉnh mạnh mẽ được nhiều nhà phát triển ở Đông Nam Á cũng đồng cảm — khi nhiều startup trong khu vực chủ yếu dùng mã nguồn mở từ các nhà phát triển độc lập mà hiếm khi đóng góp ngược lại. Với EUPL, tôi muốn nói rõ thông điệp: nếu doanh nghiệp không muốn dùng phần mềm theo điều khoản của chúng tôi, họ có thể tự bỏ công sức hoặc chi phí token để tự xây dựng.

Các dự án mới được phát hành dưới EUPL

Hiện tại tôi đã phát hành một loạt dự án mới theo EUPL:

• reticulum-js — bản cài đặt JavaScript của giao thức mạng lưới Reticulum (mesh networking)
• dacar — hệ thống ủy quyền phi tập trung xây dựng trên Reticulum
• signalk-energy-predictor — hệ thống dự đoán năng lượng tái tạo cho thuyền buồm
• offshore-blogging-system — công cụ xuất bản blog và tải dữ liệu thời tiết qua vệ tinh InReach

Ngoài ra, phiên bản viết lại mới của Môi trường phát triển NoFlo cũng sẽ mang giấy phép EUPL. Riêng phần mềm NoFlo vẫn giữ giấy phép MIT vì đó là dự án đã tồn tại lâu dài với nhiều đóng góp từ bên thứ ba không thể thu hồi.

Bài học cho cộng đồng mã nguồn mở Việt Nam

Câu chuyện của Henri Bergius cho thấy việc chọn giấy phép không chỉ là chi tiết kỹ thuật mà là một quyết định mang tính triết lý và chiến lược. Với các lập trình viên Việt Nam đang xây dựng sản phẩm mã nguồn mở — từ library nhỏ đến nền tảng lớn — việc cân nhắc giữa MIT, Apache hay EUPL nên dựa trên câu hỏi: Bạn muốn mã nguồn của mình được sử dụng tự do đến đâu, và bạn muốn nhận lại điều gì?

Trong bối cảnh ngày càng nhiều nền tảng trí tuệ nhân tạo và dịch vụ đám mây thương mại hóa mã nguồn mở mà không chia sẻ lợi ích trở lại, xu hướng chuyển sang các giấy phép copyleft mạnh như EUPL có thể sẽ còn lan rộng trong thời gian tới.