Bear nay chuyển sang giấy phép công khai mã nguồn

 (herman.bearblog.dev)
5 điểm bởi GN⁺ 2025-09-02 | 3 bình luận | Chia sẻ qua WhatsApp
  • Dự án Bear đã chuyển từ giấy phép MIT sang Elastic License
  • Giấy phép MIT trước đây cho phép sử dụng mã tự do và fork, nhưng giấy phép mới hạn chế việc cung cấp dưới dạng dịch vụ lưu trữ/hosted service
  • Nhiều dự án mã nguồn mở khác cũng đang có xu hướng áp dụng thay đổi giấy phép tương tự để ngăn cạnh tranh miễn phí
  • Trong thời đại trí tuệ nhân tạo, việc sao chép mã và biến nó thành dịch vụ đã trở nên rất dễ dàng
  • Tính công khai của mã nguồn vẫn quan trọng, nhưng cộng đồng người dùng và ý chí vận hành lâu dài mới là cốt lõi của Bear

Bối cảnh Bear chuyển đổi giấy phép công khai mã nguồn

  • Dự án Bear ban đầu công khai mã nguồn theo giấy phép MIT, với mục tiêu hỗ trợ học tập và khả năng kiểm tra/audit, đồng thời mang lại cho người dùng niềm tin về quyền riêng tư và bảo mật
  • Tuy nhiên theo thời gian, đã xuất hiện các dịch vụ cạnh tranh dựa trên mã của dự án Bear
    • Tác giả đã phát triển phần mềm của mình với nhiều tâm huyết, nhưng lại rơi vào cảm giác mất mát và áp lực kinh tế khi mã nguồn bị sao chép dễ dàng rồi quay lại trở thành đối thủ cạnh tranh
    • Dù vẫn tin vào giá trị của mã nguồn mở, đây là một tình huống gây khó khăn trên thực tế

Quyết định thay đổi giấy phép

  • Sau một sự việc gần đây, Bear đã quyết định đổi giấy phép từ MIT sang Elastic License (một cách tiếp cận kiểu copyleft được Elastic Search áp dụng)
    • Elastic License tương tự MIT, nhưng cấm cung cấp phần mềm dưới dạng dịch vụ lưu trữ hoặc dịch vụ quản lý
    • Có thể xem các điều khoản giấy phép cụ thể tại GitHub link
Quảng cáo

Xu hướng trong hệ sinh thái mã nguồn mở

  • Kết quả tìm hiểu cho thấy nhiều dự án mã nguồn mở trong vài năm gần đây đang có xu hướng siết giấy phép để ngăn “cạnh tranh ăn theo miễn phí”
    • Ví dụ: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry và nhiều dự án khác đã đưa ra quyết định tương tự

Thời đại AI và cạnh tranh gia tăng

  • Sự xuất hiện của các công cụ lập trình AI khiến những việc như “hãy fork repo này, đổi tên rồi triển khai lên EC2” trở nên khả thi, dẫn tới sao chép nhanh và thương mại hóa dưới dạng dịch vụ
  • Sự thay đổi môi trường này tạo thêm gánh nặng và rủi ro lớn hơn cho tác giả gốc

Giá trị đặc biệt của Bear

  • Giá trị thực sự của nền tảng Bear không chỉ nằm ở bản thân mã nguồn, mà còn đến từ cộng đồng sử dụng nó và trách nhiệm dài hạn của người vận hành
  • Trong tương lai, dù có thêm một số giới hạn ở cấp độ mã nguồn, nhóm phát triển vẫn bày tỏ cam kết sẽ duy trì và quản lý nền tảng một cách nghiêm túc

Bài viết liên quan

3 bình luận

 
coremaker 2025-09-02

Có vẻ như GPLv3 và AGPL không được sử dụng đúng theo ý định ban đầu của những người tạo ra các giấy phép này.
Tôi đã thấy quá nhiều trường hợp vì hầu hết đều cho phép cấp phép kép, nên cuối cùng chúng lại được dùng như một công cụ để ép buộc sử dụng thương mại.

Theo nghĩa đó, tôi nghĩ Apache hay MIT là một trong số ít giấy phép mã nguồn mở còn hoạt động đúng theo ý đồ ban đầu.
(Tuy nhiên, tôi không cho rằng tồn tại một giấy phép mã nguồn mở hoàn toàn vô khuyết.)
 
GN⁺ 2025-09-02
Ý kiến trên Hacker News

  • Theo cách tôi hiểu thì phe 'Open Source' có quan điểm rằng nếu Amazon không thể cung cấp nó dưới dạng dịch vụ trên AWS thì đó không phải là nguồn mở thực sự, và họ sẽ tỏ ra rất khó chịu nếu ai đó nói ngược lại.
    Tôi mong mọi người thừa nhận nhiều hơn hiện tượng 'cạnh tranh ăn theo miễn phí' mà tác giả bài viết đang nói tới. Việc Herman đang làm là điều có ích cho tất cả mọi người, nên tôi ước gì có một thuật ngữ mới ấm áp hơn source-available và phản ánh đúng tinh thần của một dự án cộng đồng hơn.
    Tôi bổ sung vì có một bình luận bên dưới đã tóm tắt khá đúng suy nghĩ của tôi:
    Cấu trúc độc chiếm tự nhiên của thị trường không giúp ích cho sứ mệnh của phần mềm tự do nguồn mở (FOSS). Nếu không ngăn các tập đoàn lớn kiếm tiền theo cách này thì đó lại là vấn đề làm tổn hại nghiêm trọng tới chính sứ mệnh của nguồn mở. Và trong quá trình đó, người dùng bị kéo vào cái bẫy kết hợp giữa phần mềm độc quyền của tập đoàn lớn và FOSS

    • Thái độ vốn có của phe nguồn mở trước đây là các giấy phép như GPL → GPLv3 → AGPL, tức là ủng hộ những cách chặn rõ ràng kiểu vấn đề này
      Việc các giấy phép trao gần như toàn bộ quyền như MIT/BSD/Apache trở nên phổ biến dường như là một xu hướng có chủ đích nhằm làm suy yếu lý tưởng phần mềm tự do theo lợi ích doanh nghiệp

    • Đa số mọi người cũng không quá khó chịu với phần mềm không phải nguồn mở
      Vấn đề là những dự án như Terraform đã nổi tiếng và phát triển nhờ là nguồn mở, nhưng rồi lại rơi vào tình huống người duy trì đổi sang giấy phép đóng, khiến nền tảng ban đầu của thành công biến mất
      Tệ hơn gấp đôi là khi những người đóng góp đã ký CLA (thỏa thuận cấp phép của người đóng góp), để rồi cả phần mã của họ cũng bị đổi sang giấy phép đóng một cách tùy ý

    • Nếu không quan tâm đến nguồn mở thì đừng dùng, vậy thôi; từ trước đến nay nguồn mở vốn có ý nghĩa rõ ràng và nhất quán
      Mỗi bên cứ tự do làm phần mềm theo cách mình muốn, rồi chọn dùng theo giá trị mình tin tưởng, đâu nhất thiết phải thành vấn đề

    • Ai cũng có thể dùng giấy phép mình muốn, nhưng cũng cần nghĩ xem vì sao đa số nhà phát triển nguồn mở lại chọn các giấy phép dễ dãi như MIT
      Thực tế là trên thị trường có rất nhiều phần mềm nguồn mở tốt nên quyền lựa chọn rất rộng; nếu giấy phép có ràng buộc thì người ta thường đơn giản chọn phương án khác
      Vì vậy, nếu cấp phép theo kiểu GPL thì dự án sẽ khó được dùng rộng rãi. Tất nhiên Linux hay WordPress là những ngoại lệ thành công lớn, nhưng đó không hẳn là hiện tượng phổ biến
      Ngay cả với giấy phép dễ dãi như MIT, việc kiếm tiền đã khó; nếu còn mất cả người dùng thì lại càng khó hơn
      Tranh cãi chuyện này là tốt hay xấu thì vẫn còn đó, nhưng trên thực tế mọi người dường như đang hành xử rất hợp lý. Về bản chất, phần mềm không khan hiếm đến mức như vậy

    • Chẳng phải AGPL được tạo ra đúng cho những trường hợp thế này sao?
      AGPL là giấy phép nguồn mở được OSI công nhận, có đặt hạn chế khi phần mềm được cung cấp dưới dạng dịch vụ mạng

  • Tôi tự hỏi người duy trì đã xem qua Fair Source chưa: fair.io
    Tôi nghĩ Fair Source tốt hơn source-available, và cũng là con đường để cuối cùng trở thành nguồn mở hoàn chỉnh theo DOSP(opensource.org/dosp), nên có lợi cho cả người dùng miễn phí lẫn trả phí, đặc biệt là mô hình rất lý tưởng cho một nền tảng blog như Bear
    FCL(fcl.dev) Fair Source License cũng có tinh thần khá giống Bear Blog License và rất hợp với Bear manifesto(herman.bearblog.dev/manifesto/)
    Ngay cả khi Bear PTY LTD biến mất thì vẫn có thể tạo ra một cấu trúc để bản thân Bear tiếp tục tồn tại (có thể quy định bằng DOSP)
    Tôi cũng là người có tham gia soạn thảo Fair Source

    • Sản phẩm của chúng tôi(morphik.ai) được cấp phép theo BSL (Business Source License), và về mặt chính thức chúng tôi chỉ giới thiệu đơn giản là kho mã được công khai (github.com/morphik-org/morphik-core)
      Dù vậy, thuật ngữ 'fair source' nghe cũng khá ổn
      Tôi muốn hỏi liệu có thể hiểu rằng phần mềm theo thời gian sẽ trở thành nguồn mở như Apache hay MIT thì được tính là fair source, hay còn tiêu chí nào phức tạp hơn nữa không

  • Tôi cho rằng có người đã hơi ngây thơ. Nếu chọn giấy phép MIT thì bất kỳ ai cũng tự do dùng mã của tôi theo bất kỳ cách nào. Rồi khi sau này muốn kiếm tiền thì lại đổi sang một giấy phép kỳ quặc để xử lý
    Cuối cùng thì lựa chọn vẫn là MIT/BSD, GPL, LGPL, AGPL; còn các giấy phép khác chỉ tạo ra vấn đề tương thích vô ích mà thôi

    • Tôi cũng đồng ý với quan điểm này. Khi thực sự muốn công khai mã nguồn 'không điều kiện' thì cứ chọn MIT
      Trường hợp này thì có vẻ rõ ràng là ban đầu không thật sự nghĩ vậy, mà phần nào mơ hồ muốn vừa tỏ ra 'tử tế' vừa tỏ ra 'doanh nhân'

    • Tôi thấy MPL (Mozilla Public License) cũng là một giấy phép khá hữu ích nhưng bị đánh giá thấp
      Nó chắc chắn ít lây nhiễm hơn họ GPL, nhưng lại có nhiều ràng buộc hơn MIT/BSD (khi phân phối thì các thay đổi phải công khai mã nguồn)

    • MIT và BSD không có đảm bảo về quyền sáng chế, nên đó là lý do hợp lý để chọn Apache License

    • Guy (người tạo ra nó) có vẻ đơn giản là tự làm dự án của mình và coi trọng việc công khai mã nguồn
      Tôi không nghĩ có mục tiêu chiến lược nào đặc biệt khác

    • Những người dùng tin rằng một dự án nguồn mở sẽ mãi mãi là nguồn mở cũng ngây thơ không kém
      Tác giả có quyền đổi giấy phép; ngạc nhiên vì điều đó, hay tin rằng kinh doanh bằng nguồn mở sẽ dễ dàng, rốt cuộc cũng đều là những thái độ ngây thơ

  • Nếu muốn chặn triệt để việc sử dụng cho mục đích cạnh tranh thì đây là cách người ta thường làm. Việc không còn dùng thuật ngữ nguồn mở nữa cũng là lựa chọn đúng
    Nhưng trong phần lớn trường hợp, tôi nghĩ AGPL là phương án tốt hơn. Với AGPL, các tập đoàn lớn sẽ không thể dùng mã vì quy định nội bộ của họ, từ đó tạo hiệu ứng ngăn nhà cung cấp lớn tham gia

    • Khuyến nghị dùng AGPL như một giấy phép source-available được OSI phê duyệt trên thực tế là điều đáng xấu hổ
      Đó là sự phản bội ý nghĩa nguyên bản của nguồn mở

  • "Mở theo MIT rồi thấy có người dùng mã của tôi để kinh doanh kiếm tiền. Việc không lường trước kết quả này mới là điều kỳ lạ"
    Tại sao chuyện này cứ lặp đi lặp lại? Tôi thật sự thắc mắc vì sao nhiều nhà phát triển lại không thấy trước một kết quả hiển nhiên như vậy

    • MIT từng là mặc định có rào cản thấp, chỉ cần chọn trong menu thả xuống khi tạo dự án mới trên GitHub là xong
      Khi dự án còn mới và chưa biết sẽ phát triển ra sao, rất khó hình dung rằng sau này nó sẽ lớn đến mức phải lo chuyện giấy phép

    • Giấy phép MIT vốn cho phép dự án được tái cấp phép lại bất cứ lúc nào
      Người duy trì Bear ban đầu chọn một giấy phép dễ dãi, rồi khi tình hình thay đổi thì chuyển sang một giấy phép nghiêm hơn
      Với tôi đó là một quyết định hoàn toàn hợp lý

    • Tôi nghĩ là vì phe BSD đã thắng trong cuộc chiến văn hóa nguồn mở cách đây 15~20 năm
      Nếu phe giấy phép GNU thắng cuộc chiến đó thì hệ sinh thái ngày nay sẽ khác đi như thế nào, tôi cũng rất tò mò

  • Tôi đã tài trợ cho Bear vì nó là nguồn mở, nhưng nếu không còn vậy nữa thì tôi không còn lý do gì để tiếp tục hỗ trợ nên đã hủy đăng ký
    Nếu nó quay lại AGPL thì đó thật sự là điều đáng mong đợi

    • Tôi nghĩ cả Bear lẫn tôi đều đã đưa ra lựa chọn công bằng
      Bear có quyền tự do dùng giấy phép mà họ muốn, còn tôi có thể quyết định có dùng nó hay không
      Mục đích của giấy phép nguồn mở về cơ bản là chia sẻ chứ không phải lợi ích tài chính
      Việc chỉ tài trợ cho các dự án nguồn mở cũng hoàn toàn dễ hiểu
      Khi tới lúc cần tạo doanh thu, giấy phép nguồn mở có thể không còn phù hợp nữa
      Một số nhà phát triển hiểu lầm rằng nguồn mở sẽ bảo vệ được thu nhập của họ, còn một số người dùng lại lầm tưởng dự án sẽ mãi là nguồn mở
      Các mô hình như source-available hay shipped-with-source cũng là một dạng giấy phép độc quyền (proprietary), không nhất thiết phải là nguồn mở

  • “Người dùng không được lưu trữ hoặc cung cấp dưới dạng dịch vụ được quản lý các chức năng chính của phần mềm”
    Tôi không phải luật sư, nhưng tôi thắc mắc liệu hạn chế này có cấm luôn việc tự cài đặt để vận hành Bear cho mục đích nội bộ trong công ty hoặc dùng cá nhân hay không
    Thực ra nếu cả điều đó cũng không được thì tôi không hiểu vì sao trước đây lại dùng giấy phép MIT
    Nguyên văn Bear Blog License

    • Cá nhân hay doanh nghiệp vẫn có thể tự lưu trữ Bear cho mục đích nội bộ hoặc dùng riêng
      Nhưng không được cung cấp nó dưới dạng dịch vụ cho người khác hay cho doanh nghiệp khác
      Tham khảo: Elastic License FAQ

  • Tôi hiểu cảm giác hụt hẫng, nhưng giấy phép mới hơi mơ hồ
    Khi nói “không được cung cấp chức năng qua dịch vụ lưu trữ/dịch vụ quản lý”, thì các nhà cung cấp VPS thông thường (cài bằng package manager) có bị hạn chế không?
    Nếu có script cài đặt kiểu 1-click thì tính sao, hay chỉ cần trong quá trình cung cấp dịch vụ không nhắc đến là được; cách diễn đạt này mơ hồ đến mức giống một kiểu 'diễn kịch'
    Kiểu như bên thứ ba cung cấp script cài đặt thì được, còn trong bước cung cấp dịch vụ chỉ cần không nhắc đến là mọi thứ đều ổn

    • 'Người dùng' ở đây là người dùng cuối
      Tức là không được cung cấp phần mềm này cho người khác dưới dạng dịch vụ (miễn phí hay trả phí), còn tự dùng cho mình thì được
      Điểm cốt lõi là phải hiểu rằng việc cung cấp tài khoản tự nó đã bị cấm
      Việc cung cấp hosting trọn gói cũng bị cấm, nhưng vấn đề ở đây không phải bên cho thuê hosting mà là bên bán tài khoản người dùng được tạo trên instance hosting đó
      Cách viết này nhằm chặn các tập đoàn như Amazon cung cấp instance cơ sở dữ liệu ra bên ngoài rồi chỉ việc cấp tài khoản trên đó
      Ngược lại, chỉ đơn giản cài đặt bằng package manager trên VM thì vẫn ổn
      Dù vậy, kiểu giấy phép này cực kỳ dễ gây nhầm lẫn và thiếu rõ ràng
      Nếu đã định để nó là nguồn mở và muốn nhiều người dùng, nhưng lại không muốn người khác lưu trữ nó, thì thật ra chẳng cần chia sẻ mã làm gì; cứ để All rights reserved là xong

  • Tôi hiểu động cơ và ý định công khai mã nguồn, nhưng nếu lo ngại cạnh tranh thì có vẻ đáng lẽ nên cân nhắc AGPL thay vì MIT ngay từ đầu

    • Chẳng phải AGPL rốt cuộc vẫn cho phép người khác lấy nguyên mã đó đi bán lại thương mại miễn là không sửa đổi sao?
      AGPL chỉ ép công khai mã nguồn cho các phần đã sửa đổi thôi
      Ở đây dường như vấn đề là có những trường hợp gần như bê nguyên Bearblog, hoặc chỉ đổi tên đôi chút, rồi đem cung cấp thương mại

    • Có lẽ ban đầu người ta không nghĩ cạnh tranh sẽ là vấn đề, rồi dần dần khi nó thành vấn đề mới đổi giấy phép

  • Cá nhân tôi thấy cách này (công khai mã + hạn chế hosting, v.v.) là mô hình giấy phép tốt nhất
    Tôi có thể xem và chỉnh mã theo nhu cầu của mình, trong khi dự án và người bảo trì vẫn giữ được nền tảng riêng mà không phải chịu áp lực cạnh tranh quá mức
    Nếu ngay từ đầu đã làm như vậy thì sẽ tránh được cảnh sau này đột ngột thay đổi, gây tranh cãi, hay để một bản fork vượt mặt bản gốc
    Dù tôi không nghĩ Bear là kiểu dự án tạo ra mức độ chấn động lớn đến thế
    Thỉnh thoảng tôi cũng dùng mataroa.blog khá tốt, và tôi mong người duy trì Bear cũng cảm thấy xứng đáng với dự án của mình
 
ndrgrd 2025-09-02

Thực ra, với các dự án mã nguồn mở, gần như nguồn lực duy nhất là sự quan tâm và đóng góp từ người dùng.
Nếu dự án chưa thật sự đứng vững mà bị bất kỳ ai, đặc biệt là các tập đoàn lớn, fork rồi chiếm hết sự chú ý, thì rốt cuộc chỉ là làm lợi cho người khác.

Ngay từ đầu, những giấy phép kiểu này là vì tự do của người dùng, chứ không phải vì nhà phát triển.

Bạn có biết winget, trình quản lý gói CLI của Windows, cũng là trường hợp Microsoft fork nguyên một dự án của người khác rồi chỉ đổi tên để phát hành không.
Cũng có bài viết do tác giả của dự án gốc appget viết.
The Day AppGet Died.

Nếu bạn không muốn công sức của mình chỉ mang lợi cho người khác, đặc biệt là các tập đoàn lớn hay những người rất giỏi tạo hiệu ứng lan truyền, và coi trọng giá trị thời gian của bản thân, thì bạn nên cân nhắc lại việc chọn giấy phép mã nguồn mở.
Dù đều là đóng góp tự nguyện, nhưng được tôn trọng cho công sức bỏ ra và bị phớt lờ hoàn toàn là hai chuyện rất khác nhau.

Hãy xem các lựa chọn thay thế như những gì được nêu trong phần bình luận trên Hacker News.