07 thg 11, 2025·8 phút
Richard Stallman và Phần mềm Tự do: Những ý tưởng đã thay đổi mã nguồn
Khám phá triết lý phần mềm tự do của Richard Stallman, Dự án GNU và GPL — và cách chúng thay đổi cấp phép, quyền nhà phát triển và mã nguồn mở.
Khám phá triết lý phần mềm tự do của Richard Stallman, Dự án GNU và GPL — và cách chúng thay đổi cấp phép, quyền nhà phát triển và mã nguồn mở.
Phần mềm không chỉ là một sản phẩm kỹ thuật—nó còn là một tập hợp quyền hạn. Ai có thể chạy nó, sao chép nó, chia sẻ với bạn bè, sửa một lỗi, hoặc xây dựng thứ gì đó mới dựa trên nó? Những câu hỏi này được trả lời ít bằng mã hơn và nhiều bằng cấp phép. Khi phần mềm trở nên trung tâm cho công việc, giao tiếp và nghiên cứu, các quy tắc về “bạn được phép làm gì” bắt đầu định hình đổi mới chẳng kém gì các tính năng.
Richard Stallman (thường gọi là “RMS”) quan trọng vì ông làm cho những quy tắc ấy không thể bị bỏ qua. Vào đầu thập niên 1980, ông chứng kiến một thay đổi: nhiều chương trình được phân phối mà không kèm mã nguồn, và người dùng ngày càng được nói rằng họ chỉ có thể dùng phần mềm theo điều khoản của người khác. Stallman không coi đó là một phiền toái nhỏ, mà là mất mát quyền tự do của người dùng và nhà phát triển—và ông đáp lại bằng cách đề xuất một tập nguyên tắc và công cụ pháp lý rõ ràng để bảo vệ những quyền đó.
Bài viết này tập trung vào các ý tưởng của Stallman và những hệ quả thực tế: định nghĩa Phần mềm Tự do, Dự án GNU, copyleft và GNU General Public License (GPL)—và cách những điều này đã định hình hệ sinh thái mã nguồn mở hiện đại và các chuẩn mực cấp phép phần mềm.
Nó không phải là một tiểu sử, và cũng không phải một bài đào sâu kỹ thuật về biên dịch kernel hay quản lý kho mã. Bạn không cần nền tảng lập trình để theo dõi.
Stallman vừa có ảnh hưởng vừa gây tranh cãi. Mục tiêu ở đây là giữ sự chính xác và dễ đọc: ông đã tranh luận điều gì, cơ chế pháp lý nào xuất hiện, doanh nghiệp và nhà phát triển đã thích nghi ra sao, và những tranh luận còn tiếp diễn ở đâu ngày nay—để bạn có thể thấy tại sao công việc của ông vẫn ảnh hưởng tới các lựa chọn phần mềm hàng ngày.
"Phần mềm tự do" dễ bị hiểu sai vì từ tự do nghe như nhãn giá. Richard Stallman dùng tự do để chỉ quyền—khả năng của người dùng kiểm soát phần mềm họ phụ thuộc.
Nếu một chương trình có giá $0 nhưng bạn không được phép xem mã nguồn, thay đổi nó, hay chia sẻ nó, thì nó có thể là “miễn phí như bia” nhưng vẫn không tự do theo nghĩa Stallman quan tâm.
Phần mềm tự do được định nghĩa bởi bốn quyền cơ bản:
Những quyền này liên quan đến năng lực hành động: bạn không chỉ là người tiêu dùng công cụ—bạn có thể trở thành người tham gia, xác minh, điều chỉnh và cải tiến chúng.
Freedom 1 và 3 không thể thực hiện được nếu không có truy cập tới mã nguồn—chỉ dẫn đọc được bởi con người. Không có mã nguồn, phần mềm giống như một thiết bị bị niêm phong: bạn có thể dùng nó, nhưng bạn không biết nó đang làm gì, không sửa khi hỏng, và không điều chỉnh cho nhu cầu mới.
Truy cập mã nguồn cũng quan trọng cho độ tin cậy. Nó cho phép kiểm tra độc lập (về riêng tư, bảo mật và tính công bằng) và làm cho việc duy trì phần mềm khả thi ngay cả khi người phát triển ban đầu ngừng hỗ trợ.
Hãy nghĩ đến một bữa ăn nhà hàng.
Đó là ý chính: phần mềm tự do nói về các quyền người dùng cần để giữ quyền kiểm soát máy tính của mình.
Trước khi “cấp phép phần mềm” trở thành điều phần lớn người ta tranh luận, nhiều văn hóa lập trình—đặc biệt ở đại học và phòng thí nghiệm nghiên cứu—chạy dựa trên một giả định: nếu bạn có thể cải tiến một công cụ, bạn sẽ chia sẻ cải tiến đó. Mã nguồn đi kèm phần mềm, người ta học bằng cách đọc công việc của nhau, và các sửa lỗi lan truyền qua hợp tác không chính thức.
Văn hóa đó bắt đầu thay đổi khi phần mềm trở thành sản phẩm. Các công ty (và thậm chí một số tổ chức) bắt đầu coi mã nguồn như lợi thế cạnh tranh. Phân phối kèm theo điều khoản “không chia sẻ”, mã không còn được phát hành cùng chương trình, và thỏa thuận không tiết lộ trở nên phổ biến. Với những nhà phát triển quen giải quyết vấn đề tập thể, sự thay đổi này không chỉ gây khó chịu—nó giống như thay đổi luật khiến việc giải quyết vấn đề theo cộng đồng trở nên rủi ro về mặt pháp lý.
Một trong những câu chuyện nguồn gốc được nhắc tới nhiều liên quan đến một chiếc máy in ở MIT’s AI Lab. Stallman mô tả rằng một máy in mới đến kèm phần mềm chỉ phân phối ở dạng nhị phân, không có mã nguồn. Vấn đề thực tế rất đời thường: phòng thí nghiệm muốn sửa chương trình để xử lý các tình huống như thông báo kẹt giấy hoặc định tuyến lệnh in thông minh hơn. Theo chuẩn mực “hacker” trước đây, ai đó sẽ vá mã và chia sẻ bản sửa. Ở đây, họ không thể—vì họ không được phép xem hoặc thay đổi mã nguồn.
Cần giữ điều này ở tỷ lệ hợp lý: không phải một chiếc máy in đã tạo nên phong trào toàn cầu. Đó là một ví dụ rõ ràng, dễ hiểu của một xu hướng rộng hơn—các công cụ mà người ta phụ thuộc đang trở nên không thể sửa bởi chính người dùng của chúng.
Với Stallman, vấn đề cốt lõi không chỉ là truy cập kỹ thuật; đó là mất quyền hợp tác. Nếu bạn không thể nghiên cứu cách một chương trình hoạt động, bạn không thể thực sự kiểm soát nó. Nếu bạn không thể chia sẻ cải tiến, các cộng đồng phân mảnh và mọi người sẽ tự phát minh lại sửa lỗi một cách riêng rẽ.
Động lực đó đã định hình các đổi mới về cấp phép sau này. Thay vì dựa vào thiện chí hay chuẩn mực không chính thức, Stallman muốn những quy tắc bảo tồn khả năng sử dụng, nghiên cứu, sửa đổi và chia sẻ phần mềm—để hợp tác không thể bị rút lại ngay khi một chương trình trở nên có giá trị thương mại.
Bước đi lớn của Stallman không chỉ là viết một tuyên ngôn—mà là khởi xướng một nỗ lực kỹ thuật thực tế. Năm 1983 ông tuyên bố Dự án GNU, với mục tiêu tham vọng: xây dựng một hệ điều hành hoàn chỉnh mà bất kỳ ai cũng có thể dùng, nghiên cứu, sửa đổi và chia sẻ, đồng thời tương thích với Unix để người dùng có thể chạy các chương trình và quy trình làm việc quen thuộc.
Một hệ điều hành không phải là một chương trình duy nhất—nó là cả một ngăn xếp. GNU đặt ra mục tiêu tạo tất cả các phần cần thiết hàng ngày để làm cho một máy tính hữu ích, bao gồm:
Nói đơn giản: GNU xây lớp ống nước, hệ dây điện và các công tắc—không chỉ một thiết bị đơn lẻ.
Đầu những năm 1990, GNU đã sản xuất phần lớn “userland” này, nhưng một mảnh quan trọng còn chậm trễ: kernel (phần quản lý phần cứng và tài nguyên). Khi Linux xuất hiện năm 1991, nó lấp vào khoảng trống đó.
Đó là lý do nhiều hệ thống phổ biến ngày nay kết hợp thành phần GNU với nhân Linux—thường gọi là “GNU/Linux”.
GNU biến ý tưởng phần mềm tự do thành hiện thực bằng cách tạo nền tảng hoạt động để người khác xây dựng. Triết lý giải thích tại sao tự do quan trọng; GNU cung cấp các công cụ làm cho tự do trở nên thực tế, có thể nhân rộng và mở rộng.
Copyleft là một chiến lược cấp phép nhằm giữ phần mềm tự do (theo nghĩa quyền) không chỉ ở lần phát hành đầu tiên, mà cả ở các phiên bản tương lai. Nếu bạn nhận được mã copyleft, bạn được phép sử dụng, nghiên cứu, sửa đổi và chia sẻ—nhưng khi bạn phân phối phiên bản đã chỉnh sửa, bạn phải truyền cùng các quyền đó cho người khác.
Copyleft nghe có vẻ như “chống bản quyền”, nhưng thực tế nó dựa vào luật bản quyền. Tác giả sử dụng quyền bản quyền của mình để đặt ra điều khoản cho phép: “Bạn có thể sao chép và sửa đổi, nhưng nếu bạn phân phối lại, bạn phải giữ nó dưới cùng giấy phép này.” Nếu không có bản quyền, sẽ không có cơ chế pháp lý để thực thi những điều kiện đó.
Hãy coi nó là một quy tắc theo sau mã:
Mục tiêu là ngăn chặn mô hình Stallman lo ngại: ai đó lấy công sức cộng đồng, cải tiến và sau đó khóa những cải tiến lại.
Giấy phép permissive (như MIT hoặc BSD) thường cho phép bạn làm gần như mọi thứ với mã, kể cả phân phối phiên bản đã chỉnh sửa dưới giấy phép đóng. Giấy phép copyleft (như GNU GPL) vẫn cho phép sử dụng và sửa đổi rộng rãi, nhưng yêu cầu các bản phân phối phái sinh giữ cùng điều khoản copyleft—vậy nên quyền tự do được bảo tồn về phía sau.
GNU General Public License (GPL) thay đổi cấp phép phần mềm bằng cách biến “chia sẻ” thành một quy tắc có thể thi hành, chứ không chỉ là một cử chỉ tốt. Trước GPL, bạn có thể nhận mã nguồn, cải tiến nó và sau đó phát hành phiên bản đóng cửa mà người dùng không thể nghiên cứu hay sửa đổi. GPL đảo ngược động lực đó: nó bảo vệ quyền người dùng bằng cách gắn điều kiện vào việc phân phối.
Ở mức thực tế, GPL trao quyền để chạy chương trình cho bất kỳ mục đích nào, đọc và sửa mã nguồn, và chia sẻ bản gốc hoặc phiên bản đã sửa.
Nếu bạn phân phối phần mềm theo GPL (đặc biệt trong một sản phẩm), bạn phải truyền lại những quyền đó. Điều này thường có nghĩa:
Nghĩa vụ của GPL chủ yếu kích hoạt khi bạn phân phối phần mềm cho người khác—gửi nhị phân, bán thiết bị kèm phần mềm, hoặc đưa bản sao cho khách hàng. Nếu bạn chỉnh sửa mã GPL để dùng nội bộ và không phân phối, thường bạn không phải công bố mã nguồn.
Bạn không cần lý thuyết pháp lý phức tạp để hiểu chung: nếu chương trình của bạn kết hợp mã GPL theo cách tạo ra một tác phẩm kết hợp (ví dụ, bằng cách liên kết vào ứng dụng của bạn), kết quả thường được coi là tác phẩm phái sinh và phải được phân phối theo GPL. Chỉ chạy chương trình GPL, hoặc giao tiếp với nó như một tiến trình riêng qua giao diện chuẩn, thường khác biệt.
GPLv2 là phiên bản cổ điển dùng rộng rãi. GPLv3 bổ sung các bảo vệ quanh các thỏa thuận bằng sáng chế và “tivoization” (thiết bị chặn phần mềm đã sửa đổi). LGPL được thiết kế cho thư viện: nó cho phép liên kết từ chương trình độc quyền trong một số điều kiện, đồng thời giữ thư viện tự do.
Giấy phép tự do (đặc biệt là GNU GPL) không chỉ “cho phép” chia sẻ—chúng bảo vệ quyền được nghiên cứu, sửa đổi và phân phối phần mềm theo cách khó bị thu hồi sau này. Với tư cách nhà phát triển, điều đó có nghĩa các cải tiến của bạn có thể tiếp tục có sẵn cho người khác dưới cùng điều khoản, thay vì bị hấp thụ vào sản phẩm đóng mà cộng đồng không hưởng lợi.
Dưới GPL, bạn có thể:
Đó là lý do GPL thường được mô tả là “tương hỗ có thể thi hành.” Nếu ai đó phân phối chương trình được phủ bởi GPL (hoặc tác phẩm phái sinh), họ không thể thêm các hạn chế ngăn người dùng phía sau làm cùng loại sửa đổi và chia sẻ.
Những quyền này đi kèm nghĩa vụ khi bạn phân phối phần mềm:
Những trách nhiệm này không phải “bẫy”—chúng là cơ chế giữ cho hợp tác không trở thành khai thác một chiều.
Các nhóm nên coi tuân thủ giấy phép như là thói quen phát hành. Hãy theo dõi:
Một SBOM đơn giản và checklist lặp lại cho phát hành có thể ngăn hầu hết vấn đề trước khi luật sư phải can thiệp.
Ở mức mã nguồn, “phần mềm tự do” và “mã nguồn mở” thường mô tả nhiều dự án giống nhau. Sự khác biệt chủ yếu là tại sao việc chia sẻ lại quan trọng.
Phong trào Phần mềm Tự do (liên quan đến Richard Stallman và Free Software Foundation) xem tự do phần mềm như một vấn đề đạo đức: người dùng nên có quyền chạy, nghiên cứu, sửa đổi và chia sẻ phần mềm. Ý điểm không chỉ là kỹ thuật tốt hơn—mà là bảo vệ quyền tự chủ của người dùng.
Cách tiếp cận Mã nguồn Mở nhấn mạnh kết quả thực tiễn: hợp tác tốt hơn, vòng lặp nhanh hơn, ít lỗi hơn và bảo mật cải thiện qua minh bạch. Nó chấp nhận giới thiệu tính mở như một mô hình phát triển vượt trội, mà không buộc các đội phải mang lập trường đạo đức.
Năm 1998, Open Source Initiative (OSI) phổ biến thuật ngữ “open source” để làm cho ý tưởng thân thiện hơn với doanh nghiệp. “Free software” thường bị hiểu nhầm là “miễn phí về giá”, và một số công ty e ngại thông điệp mang tính quyền và đạo đức. “Open source” cho tổ chức một cách nói “chúng ta có thể làm việc theo cách này” mà không mang vẻ ý thức hệ.
Nhiều dự án tự gọi là open source dùng GNU GPL hoặc các giấy phép copyleft khác, trong khi nhiều dự án khác chọn giấy phép permissive như MIT hoặc Apache. Văn bản pháp lý có thể giống nhau; câu chuyện kể với cộng tác viên, người dùng và khách hàng thay đổi. Một thông điệp là “điều này bảo vệ quyền của bạn”, thông điệp khác là “điều này giảm ma sát và cải thiện chất lượng.”
Phần mềm tự do không có nghĩa “không ai được trả tiền.” Nó có nghĩa người dùng có quyền chạy, nghiên cứu, sửa đổi và chia sẻ mã. Nhiều công ty xây doanh thu khỏe mạnh quanh quyền đó—thường bằng cách bán những thứ tổ chức thực sự cần: độ tin cậy, trách nhiệm, và thời gian.
Một vài mô hình phổ biến:
Một biến thể hiện đại của mô hình “dịch vụ quản lý” là sự xuất hiện của các nền tảng tạo và chạy ứng dụng nhanh. Ví dụ, Koder.ai là nền tảng vibe-coding giúp nhóm xây web, backend và ứng dụng di động qua chat—trong khi vẫn hỗ trợ xuất mã nguồn. Sự kết hợp đó (lặp nhanh + sở hữu mã) phù hợp tự nhiên với giá trị đằng sau tự do phần mềm: khả năng kiểm tra, thay đổi và di chuyển phần mềm khi bạn cần.
Lựa chọn giấy phép có thể định hình ai nắm giữ giá trị:
“Thương mại” mô tả cách bán; “phần mềm tự do” mô tả quyền người dùng. Một công ty có thể bán phần mềm tự do, tính phí hỗ trợ, và vẫn tôn trọng tự do phần mềm.
Trước khi áp dụng hoặc đặt cược vào một dự án FOSS, hãy hỏi:
GPL và “FOSS” được bàn luận nhiều, nhưng một vài quan niệm sai lầm thường làm rối những đội chỉ muốn phát hành sản phẩm mà không vô tình vi phạm giấy phép.
Không phải. Public domain nghĩa là không còn chủ sở hữu bản quyền—bất kỳ ai cũng có thể tái sử dụng mà không ràng buộc.
GNU GPL ngược lại với “không điều kiện”. Tác giả giữ bản quyền và cấp quyền rộng để dùng, sửa và chia sẻ—nhưng phải tuân theo điều khoản GPL (nổi tiếng nhất là chia sẻ mã nguồn khi bạn phân phối nhị phân được bảo phủ).
Hiển thị mã nguồn có thể giúp an ninh, nhưng không đảm bảo. Một dự án mã nguồn mở vẫn có thể:
Bảo mật đến từ việc duy trì tích cực, kiểm toán, quy trình tiết lộ có trách nhiệm và thực hành vận hành tốt—không phải chỉ vì nhãn giấy phép.
Người ta thường gọi GPL là “viral” để ám chỉ nó lan rộng vô kiểm soát. Đó là ẩn dụ nặng nề.
Nó thường nói tới copyleft: nếu bạn phân phối tác phẩm phái sinh của mã GPL, bạn phải cung cấp mã tương ứng theo GPL. Yêu cầu đó là cố ý: nó bảo tồn quyền cho người dùng phía sau. Đó không phải “lây nhiễm”; đó là một điều khoản mà bạn có thể chọn chấp nhận—hoặc tránh bằng cách dùng mã khác.
Quy tắc thông thường: nghĩa vụ kích hoạt chủ yếu khi bạn phân phối.
Khi quan trọng, hãy xem xét chính xác cách mã được kết hợp và phân phối—đừng chỉ dựa vào giả định.
Richard Stallman là một nhân vật gây tranh cãi. Có thể thừa nhận điều đó—và vẫn nói rõ về ảnh hưởng lâu dài của các ý tưởng và giấy phép gắn với ông.
Một khởi điểm hữu ích là tách hai cuộc trò chuyện: (1) tranh luận về Stallman với tư cách cá nhân và thành viên cộng đồng, và (2) tác động có thể đo lường của nguyên tắc phần mềm tự do, Dự án GNU, và GNU GPL lên cấp phép phần mềm và quyền nhà phát triển. Phần thứ hai có thể bàn bằng nguồn chính (văn bản giấy phép, lịch sử dự án, mô hình áp dụng) ngay cả khi người ta có quan điểm mạnh về phần đầu.
Một phê bình thường gặp không phải về cấp phép mà là về quản trị: dự án quyết định thế nào, ai có thẩm quyền, và chuyện gì xảy ra khi người sáng lập, người duy trì và người dùng muốn điều khác nhau. Cộng đồng phần mềm tự do đã vật lộn với các câu hỏi như:
Những câu hỏi này quan trọng vì giấy phép đặt điều khoản pháp lý, nhưng không tự tạo ra quy trình ra quyết định lành mạnh.
Một cuộc tranh luận khác tập trung vào tính bao dung và chuẩn mực cộng đồng: dự án đặt kỳ vọng về hành vi tôn trọng thế nào, xử lý xung đột ra sao, và chào đón người mới như thế nào. Một số cộng đồng nhấn mạnh quy tắc ứng xử chính thức; số khác thích ít quy tắc hơn và điều phối không chính thức. Không cách nào tự nhiên là “đúng”, nhưng cân nhắc đánh đổi là thực tế và đáng thảo luận mà không có công kích cá nhân.
Nếu bạn đánh giá di sản của Stallman, tốt nhất là giữ các khẳng định có thể kiểm chứng: GPL yêu cầu gì, copyleft thay đổi thực hành tuân thủ ra sao, và những ý tưởng này ảnh hưởng thế nào tới giấy phép và tổ chức sau này. Bạn có thể phê bình, ủng hộ hoặc phân vân—chỉ cần hướng tới sự chính xác, tôn trọng và rõ ràng về điều bị phê bình.
Món quà thực tế lớn nhất của Stallman cho các đội hàng ngày là một câu hỏi rõ ràng: bạn muốn đảm bảo những quyền nào cho người dùng phía sau? Trả lời câu đó biến “chọn giấy phép” từ cảm tính thành một quyết định.
Nếu chưa chắc, quyết định dựa trên mục tiêu của bạn: áp dụng (permissive) vs tương hỗ (copyleft) vs tương hỗ thân thiện với thư viện (copyleft yếu).
LICENSE ở gốc repo (sao chép toàn văn giấy phép).Nếu bạn dùng phát triển hỗ trợ AI (bao gồm nền tảng chat như Koder.ai), checklist này càng quan trọng hơn: bạn vẫn phân phối phụ thuộc thực, sản phẩm thực và nghĩa vụ giấy phép thực. Tốc độ không loại trừ trách nhiệm—nó chỉ làm cho quy trình tuân thủ có thể lặp lại trở nên quý giá.
Làm cho nó nhàm chán và lặp lại:
Để so sánh sâu hơn, xem Choosing an open-source license và GPL vs MIT vs Apache.
"Free software" có nghĩa là tự do, chứ không phải giá cả.
Một chương trình có thể miễn phí về giá tiền nhưng vẫn không tự do nếu bạn không thể kiểm tra, sửa đổi hoặc chia sẻ nó. Phần mềm tự do tập trung vào quyền được chạy, nghiên cứu, thay đổi và phân phối phần mềm mà bạn phụ thuộc vào.
Định nghĩa dựa trên bốn quyền cơ bản:
Nếu thiếu bất kỳ quyền nào trong số này, người dùng mất kiểm soát và sự hợp tác trở nên khó khăn hơn.
Bởi vì bạn không thực sự nghiên cứu hay sửa đổi phần mềm khi không có mã nguồn.
Truy cập mã nguồn cho phép:
Copyleft dùng luật bản quyền để yêu cầu “chia sẻ theo cùng điều kiện” khi bạn phân phối lại.
Bạn có thể sử dụng, sửa đổi, thậm chí bán phần mềm, nhưng nếu bạn phân phối phiên bản đã chỉnh sửa, bạn phải cung cấp cho người nhận các quyền tương tự (thường bằng cách phát hành mã nguồn tương ứng dưới cùng một giấy phép).
GPL trao cho người dùng quyền rộng (chạy, nghiên cứu, sửa đổi, chia sẻ) và yêu cầu đối ứng khi phân phối.
Nếu bạn phân phối nhị phân có GPL, thường bạn phải:
Thường thì không.
Với phần mềm GPL, nghĩa vụ thường bắt nguồn khi bạn phân phối. Nếu bạn chỉnh sửa mã GPL để dùng nội bộ và không đưa bản sao ra bên ngoài tổ chức, thường bạn không phải công bố thay đổi.
(Có các trường hợp cạnh; xem đây là quy tắc chung chứ không phải tư vấn pháp lý.)
Tùy thuộc cách mã được kết hợp.
Nói chung:
Khi vấn đề quan trọng, hãy vạch rõ kiểu tích hợp trước khi phát hành.
Chúng nhắm tới các mối quan tâm khác nhau:
Chọn dựa trên việc bạn muốn tính đối ứng mạnh mẽ (GPL) hay thân thiện với thư viện (LGPL).
Thông thường không theo GPL.
Nếu bạn chạy phần mềm GPL trên máy chủ của mình và người dùng chỉ tương tác qua mạng, bạn thường không phân phối bản sao, nên nghĩa vụ chia sẻ mã theo GPL thường không kích hoạt.
Nếu bạn muốn quyền sử dụng qua mạng cũng buộc phải chia sẻ mã, hãy xem xét AGPL và cân nhắc kỹ mô hình triển khai của bạn.
Có—nhiều công ty kiếm tiền với phần mềm tự do/mã nguồn mở bằng dịch vụ và cung cấp.
Mô hình phổ biến:
Lựa chọn giấy phép ảnh hưởng chiến lược: permissive có thể tối đa hóa việc áp dụng; copyleft có thể ngăn nhánh đóng nguồn và hỗ trợ các mô hình dựa trên dịch vụ.