- Liquibase đã chuyển từ giấy phép mã nguồn mở hiện có sang Functional Source License (FSL)
- Dù FSL không phải là giấy phép mã nguồn mở chính thức theo tiêu chuẩn của Open Source Initiative (OSI), vẫn có vấn đề được nêu ra rằng dự án này tiếp tục được giới thiệu là dự án mã nguồn mở trong README và các nơi khác
- Trong cộng đồng, có cả ý kiến cho rằng FSL vi phạm các tiêu chuẩn mã nguồn mở chính thức lẫn ý kiến ngược lại rằng FSL đáp ứng các yêu cầu của mã nguồn mở
- Trong dự án, công việc chỉnh sửa các phần đề cập đến mã nguồn mở trong README đang được tiến hành
- Có chỉ ra rằng FSL xung đột với một số điều khoản trong OSI Open Source Definition (Định nghĩa Mã nguồn mở) do có các điều khoản như hạn chế việc sử dụng mang tính cạnh tranh
Tổng quan vấn đề
- Giấy phép của dự án Liquibase gần đây đã được đổi sang Functional Source License (FSL)
- Tuy nhiên, trong các tài liệu chính thức như README.md, Liquibase vẫn được giới thiệu là một dự án mã nguồn mở, gây ra sự nhầm lẫn và tranh cãi trong cộng đồng
Nội dung báo cáo và tranh cãi
- Người tạo issue chỉ ra rằng việc Liquibase vẫn ghi rõ mình là mã nguồn mở dù đã chuyển sang FSL là một vấn đề
- Chính Liquibase cũng từng đề cập rằng FSL không phải là giấy phép mã nguồn mở
- Có yêu cầu chỉnh sửa README và các tài liệu khác để không còn dùng thuật ngữ mã nguồn mở trong tài liệu dự án
Ý kiến từ cộng đồng và những người liên quan
- Một số người tham gia cho rằng FSL đáp ứng các tiêu chí của giấy phép mã nguồn mở được OSI phê duyệt, và nếu FSL trở thành giấy phép được OSI chấp thuận sau quy trình đánh giá chính thức thì sẽ không có vấn đề gì
- Ngược lại, những người khác nhấn mạnh rằng do có các điều khoản như “mục đích được phép” trong FSL, nó vi phạm nhiều điều khoản trong Định nghĩa Mã nguồn mở của OSI (điều 1, 3, 5, 6)
- Cũng có ý kiến nhấn mạnh sự khác biệt giữa “Fair Source” và “mã nguồn mở thực sự”, cho rằng FSL nên được phân loại là Fair Source
Quá trình xử lý issue và chỉnh sửa tài liệu
- Một cộng tác viên của dự án đã phản hồi vấn đề này bằng cách chỉnh sửa README.md và dần loại bỏ các đề cập đến mã nguồn mở
- Tuy vậy, trong kho lưu trữ vẫn còn rải rác một số cách diễn đạt như ‘open source’, ‘oss’, nên dự kiến sẽ tiếp tục rà soát và dọn dẹp thêm
Định nghĩa mã nguồn mở và vấn đề với FSL (Functional Source License)
- Richard Fontana cùng các nhân vật tiêu biểu trong giới mã nguồn mở khẳng định rõ rằng FSL vi phạm Định nghĩa Mã nguồn mở của OSI do có các điều khoản như cấm sử dụng mang tính cạnh tranh
- Định nghĩa mã nguồn mở có các điều khoản như “không phân biệt đối xử theo lĩnh vực, cá nhân hay tổ chức”, và việc cấm các mục đích sử dụng cạnh tranh là đi ngược lại điều đó
- FSL dự kiến sẽ được chuyển sang MIT hoặc Apache License sau 2 năm để trở thành mã nguồn mở hoàn toàn, nhưng trước thời điểm đó vẫn còn các điều kiện hạn chế
Kết luận và tình hình hiện tại
- Issue này đã thúc đẩy yêu cầu về tính minh bạch từ cộng đồng và cuộc thảo luận về bản chất của mã nguồn mở trong quá trình chỉnh sửa cách ghi nhãn mã nguồn mở của Liquibase
- Công việc chỉnh sửa các tài liệu chính thức như README đã bắt đầu, và tiêu chí phân biệt giữa Fair Source và mã nguồn mở đang được đem ra thảo luận như một trường hợp thực tế
- Bất kể có được OSI phê duyệt hay không, các điều kiện thực tế của giấy phép đều mang ý nghĩa đáng kể trong cộng đồng mã nguồn mở quốc tế
1 bình luận
Ý kiến trên Hacker News
Đang bắt đầu tìm phương án thay thế để phòng trường hợp không thể tiếp tục dùng phiên bản 4.x
Tôi hiểu việc chuyển từ giấy phép OSS sang trả phí khi ai đó muốn kiếm tiền từ phần mềm hữu ích
Nhưng tôi cho rằng việc đổi giấy phép từ open source là một kiểu chiến thuật mồi nhử rồi chuyển hướng
Những quyết định như vậy phá hủy niềm tin ngay lập tức, đồng thời làm mất đi cả nhóm người dùng tuy khó kiếm tiền ngay nhưng có tiềm năng dài hạn
Tôi đã nghĩ họ hẳn đã rút ra bài học quan trọng từ các trường hợp Elastic và TerraForm
Flyway cũng có thể đi theo con đường tương tự bất cứ lúc nào nên tôi cảm thấy mức độ tin cậy đã giảm đi
Nếu không có bản fork nào xuất hiện, chúng tôi cũng đang cân nhắc tự làm hẳn một thư viện migration phù hợp với nhu cầu sử dụng thực tế của mình
Liquibase chỉ đơn giản là tiện nên mới dùng, chứ tuyệt đối không phải không thể thay thế
Tôi nghĩ EventstoreDB (giờ là KurrentDB) và NATS cũng đang bị nghi ngờ về độ tin cậy của dịch vụ
EventstoreDB đã đổi giấy phép rồi, còn NATS thì chỉ rút kế hoạch lại vì phản ứng dữ dội từ người dùng
Giờ tôi có cảm giác những động thái như vậy đã trở thành một kiểu chiến lược kinh doanh
Ưu điểm lớn nhất của open source là luôn có thể fork các phiên bản cũ để tiếp tục dùng
Tôi cho rằng về bản chất việc chuyển đổi này cũng chẳng khác gì tăng giá sản phẩm
Dù chỉ dành cho Postgres, vẫn có dự án pgroll giúp đưa tự động hóa lên một tầm cao hơn
Ngoài Flyway (giấy phép Apache) còn có những lựa chọn vẫn là open source như Atlas (Apache), Sqitch (MIT)
Tôi tò mò không biết việc Elastic đổi giấy phép, nhìn từ phía họ, có thực sự là thất bại không
Giá cổ phiếu từng giảm một thời gian, nhưng công ty thực tế vẫn đang vận hành tốt
Tất cả các lập trình viên trong mảng tìm kiếm và RAG mà tôi biết vẫn chỉ dùng Elasticsearch do Elastic NV cung cấp (không dùng fork open source hay giải pháp thay thế)
Đặc biệt nếu chỉ nhìn vào nhóm khách hàng quan trọng nhất của Elastic là khách hàng trả phí, có vẻ điều này không phá hủy niềm tin mà còn phản tác dụng theo hướng ngược lại
Doanh thu thực tế cũng đã tăng gấp đôi so với năm 2020
Vẫn có ý kiến cho rằng nó còn là open source, nhưng chính Liquibase đã nói rõ FSL không phải là giấy phép open source
Xem thông báo trên blog chính thức của Liquibase
Thật đáng tiếc khi gần đây có nhiều dự án chỉ công khai mã nguồn nhưng lại xây dựng thương hiệu như thể là open source
Nếu Liquibase chọn Apache thay vì copyleft mạnh (ví dụ GNU AGPL), thì lẽ ra họ phải dự liệu chuyện bên khác tạo ra các bản phái sinh mã nguồn đóng
Suy cho cùng đây là lựa chọn do chính Liquibase đưa ra, nên tôi nghĩ trách nhiệm cũng thuộc về Liquibase
Có vẻ đây là cấu trúc tự động chuyển sang Apache sau một khoảng thời gian nhất định
Tôi cũng không chắc điều này tốt hơn hay không
Thực ra các công ty vẫn có thể đạt được mục tiêu của mình chỉ với giấy phép như AGPL
Redis cũng đã chuyển đổi và phản ứng cộng đồng khá tích cực
Tôi không nghĩ người dùng sẽ bất mãn nếu Liquibase chọn mô hình cấp phép kép AGPL
Có lẽ nên gọi đây là "open source trễ 2 năm" hoặc "open source sau 2 năm"
Thực tế tôi thấy nó là kiểu "open source khi đã hết hữu dụng"
Theo kiểu này, bản chất là chỉ tạo ra hình ảnh tôn trọng tự do thật sự trong khi thực tế thì không phải vậy
Trường hợp phiên bản cũ trở nên vô dụng nhanh đến vậy thật ra cũng hiếm
Tôi không xem đây là sự thiếu tôn trọng đối với tự do của mình
Mục tiêu là áp một số hạn chế lên doanh nghiệp (không phải con người)
Trong lĩnh vực enterprise, tôi nghĩ cốt lõi của open source không phải là "tự do" mà là niềm tin và tính minh bạch
Chỉ cần công khai mã nguồn thôi cũng đã có thể tận dụng được các lợi ích của FOSS mà không gặp vấn đề pháp lý hay kiếm tiền
Trên mạng có xu hướng quá tin tưởng một cách mù quáng vào mô hình open source
Tôi thấy chính sách pha trộn 2 năm cũng đủ hợp lý, và nếu không muốn giấy phép mới thì cứ dùng bản cũ
Open source bị trì hoãn, mang sắc thái hai nghĩa giống từ 'late' trong tiếng Anh
#source-washing
Nếu bạn chưa quen với giấy phép mới, hãy xem liên kết giải thích chi tiết về FSL
Bổ sung bối cảnh về FSL: đây là giấy phép do Sentry tạo ra; có thể xem blog của Sentry để hiểu vì sao giấy phép này cần thiết và họ muốn giải quyết vấn đề gì
Cá nhân tôi thấy giấy phép mã nguồn đóng duy nhất còn có thể chấp nhận là BuSL "Business Source License"
Sau thời hạn 4 năm thì bắt buộc trở thành open source, còn trước đó thì mã nguồn vẫn được công khai
Điều này cũng giúp tránh việc giấy phép bị phân mảnh không cần thiết
Có thể tham khảo thêm wiki về Business Source License
Tôi nghi ngờ rằng khoảng thời gian 2 năm có phải là quá ngắn không
Từ góc nhìn của doanh nghiệp lớn, phần mềm 5 năm tuổi vẫn dùng tốt, và với tôi Redis bản 2012 hay Postgres bản 2020 cũng hoàn toàn ổn
Tôi từng tổng hợp lịch sử của các trường hợp kiểu này cùng danh sách công ty
Tôi đã ghi lại trong bài blog liên quan, nếu ai biết thêm thì hãy chia sẻ
Các tính năng pro liên tục phá vỡ cú pháp của bản community nên tôi không hề cảm thấy có tính minh bạch nào
Tất nhiên công sức làm việc cần được đền đáp xứng đáng, nhưng kiểu "chúng tôi từng là open source rồi lặng lẽ không còn như vậy nữa" đang trở nên quá phổ biến
Những chuyển đổi như thế này dường như lúc nào cũng được tiến hành âm thầm với hy vọng không ai nhận ra
Tôi muốn biết cụ thể thiệt hại thực tế hay vấn đề chính là gì
Thậm chí tôi còn thích cách phân biệt giữa lĩnh vực cạnh tranh và không cạnh tranh
Tôi thấy không khí trong phần bình luận hơi kỳ lạ
Đa số chỉ nhìn thấy chữ "base" rồi đề xuất các dịch vụ chẳng liên quan, hoặc cho rằng chỉ cần công khai mã nguồn là đã là open source
Tôi không biết Liquibase đã đổi giấy phép
Thực tế gần như mọi framework web đều có phương án thay thế, và cũng có nhiều lựa chọn độc lập với framework như Alembic và Flyway
Ở thời điểm này điều đó có vẻ hơi lạ
Vấn đề lần này có thể gây rắc rối cả cho các dự án OSS như Keycloak
Theo chính sách của CNCF, giấy phép không phải open source không được phép sử dụng, nên Keycloak không thể dùng Liquibase
Vì Debian, Fedora cũng có điều kiện về giấy phép OSS, tôi tự hỏi liệu các dự án phụ thuộc Liquibase có thể được đưa vào các bản phân phối như vậy không
Liên kết chi tiết issue của Keycloak
Nhưng vẫn có thể được đưa vào các kho riêng hoặc các repo tùy chỉnh như rpm fusion non-free