Bước tới nội dung

Giấy phép phần mềm tự do

Bách khoa toàn thư mở Wikipedia
Giấy phép phần mềm trong bối cảnh bản quyền theo Mark Webbink.[1] Từ trái sang phải ít quyền cho người được cấp phép/user của một phần mềm và nhiều hơn nữa quyền giữ lại bởi chủ sở hữu. Ba danh mục giấy phép đầu tiên từ bên trái được coi là một phần của hệ sinh thái "phần mềm tự do", cũng bao gồm Giấy phép tương đương tên miền công cộng (như CC0).
Phổ phần mềm cấp phép tự do và một số ví dụ về các chương trình theo các giấy phép đó theo David A. Wheeler (2007)[2]

Giấy phép phần mềm tự do là thông báo cấp cho người nhận một phần của các quyền mở rộng phần mềm để sửa đổi và phân phối lại phần mềm đó. Những hành động này thường bị luật bản quyền cấm, nhưng chủ bản quyền (thường là tác giả) của một phần mềm có thể loại bỏ những hạn chế này bằng cách kèm theo phần mềm với giấy phép phần mềm cấp cho người nhận các quyền này. Phần mềm sử dụng giấy phép đó là phần mềm tự do (hoặc phần mềm tự do - mã nguồn mở) do chủ sở hữu bản quyền trao tặng. Giấy phép phần mềm miễn phí được áp dụng cho phần mềm trong mã nguồn và cũng dưới dạng mã đối tượng nhị phân, vì luật bản quyền công nhận cả hai biểu mẫu.[3]

Lịch sử

[sửa | sửa mã nguồn]

Trước thập niên 1980

[sửa | sửa mã nguồn]

Trong thời kỳ đầu của phần mềm, chia sẻ phần mèm và mã nguồn là phổ biến trong cộng đồng, cho các tổ chức giáo dục chẳng hạn. Trước khi Ủy ban Hoa Kỳ về sử dụng công nghệ mới có bản quyền (CONTU) quyết định năm 1974 rằng "chương trình máy tính, trong phạm vi mà chúng thể hiện sáng tạo ban đầu của tác giả, là đối tượng thích hợp của bản quyền",[4][5] phần mềm không được coi là có bản quyền. Do đó, phần mềm không có giấy phép kèm theo và được chia sẻ như là phần mềm tên miền công cộng. Quyết định của CONTU cùng với quết định của tòa án tại vụ viện giữa Apple v. Franklin năm 1983 cho mã đối tượng, đã làm rõ rằng luật Bản quyền đã cung cấp cho ứng dụng máy tính có bản quyền của tác phẩm văn học và bắt đầu cấp phép phần mềm.

Giấy phép phần mềm tự do trước cuối những năm 1980 là những thông báo chính thức thường được viết bởi chính các nhà phát triển. Những giấy phép ban đầu này thuộc loại "được phép".

Giữa thập niên 1980,dự án GNU đã tạo ra các giấy phép phần mềm tự do copyleft cho mỗi gói phần mềm của nó. Giấy phép sớm như vậy ("GNU Emacs Copying Permission Notice") đã được sử dụng cho GNU Emacs vào năm 1985,[6] với các sửa đổi tiếp theo vào năm 1986, 1987 và 1988 lấy tên là "GNU Emacs General Public License".[7] Tương tự vậy, Giấy phép Công cộng GCC (GCC General Public License) đã được áp dụng cho GNU Compiler Collection, ban đầu được phát hành vào năm 1987.[8][9] Giấy phép BSD ban đầu cũng là một trong những giấy phép phần mềm tự do đầu tiên, bắt đầu từ năm 1988. Năm 1989, phiên bản 1 của GNU General Public License (GPL) được phát hành. Phiên bản 2 của GPL, phát hành năm 1991, tiếp tục trở thành giấy phép phần mềm miễn phí được sử dụng rộng rãi nhất.[10][11][12]

Những năm 1980

[sửa | sửa mã nguồn]

Giữa thập niên 1980, GNU project đã tạo ra các giấy phép phần mềm miễn phí copyleft cho từng gói phần mềm của nó. Giấy phép sớm như vậy ("GNU Emacs Copying Permission Notice") được dùng cho GNU Emacs năm 1985,[13] với các sửa đổi tiếp theo vào năm 1986, 1987 và 1988 với tên gọi "GNU Emacs General Public License".[14] Tương tự như vậy, GCC General Public License được áp dụng cho GNU Compiler Collection, ban đầu được xuất bản vào năm 1987.[15][16] Giấy phép BSD gốc cũng là một trong những giấy phép phần mềm tự do đầu tiên, bắt đầu từ 1988. Năm 1989, phiên bản 1 của GNU General Public License (GPL) được phát hành. Phiên bản 2 của GPL được phát hành năm 1991, đã trở thành giấy phép phần mềm tự do được sử dụng rộng rãi nhất.[17][18][19]

Thập niên 1990 đến thập niên 2000

[sửa | sửa mã nguồn]

Từ giữa thập niên 1990 và cho đến giữa thập niên 2000, phong trào nguồn mở đã điều chỉnh và tập trung ý tưởng phần mềm tự do theo hướng nhận thức công khai và kinh doanh rộng hơn.[20] Trong thời kỳ bong bóng Dot-com, bước đi của Netscape Communications phát hành trình duyệt web của họ theo giấy phép tự do năm 1998,[21][22] đã truyền cảm hứng cho nhiều công ty khác thích ứng với hệ sinh thái FOSS.[23] Trong các công ty theo xu hướng này và các dự án mới (Mozilla, Apache Foundation, và Sun...) đã viết các giấy phép FOSS riêng của họ, hoặc điều chỉnh các giấy phép hiện có. Sự gia tăng Giấy phép này sau đó được công nhận là vấn đề đối với hệ sinh thái tự do và nguồn mở do sự phức tạp về tính tương thích của giấy phép.[24] Trong khi việc tạo ra các giấy phép mới bị chậm lại sau đó, sự gia tăng giấy phép và tác động của nó được coi là một thách thức nghiêm trọng đang diễn ra đối với hệ sinh thái tự do và nguồn mở.

Từ giấy phép phần mềm tự do, GNU GPL v2 đã được thử nghiệm tại tòa án, lần đầu tiên ở Đức vào năm 2004 và sau đó tại Mỹ. Trong trường hợp ở Đức, thẩm phán đã không thảo luận rõ ràng về tính hợp lệ của các điều khoản của GPL nhưng đã chấp nhận rằng GPL phải được tôn trọng: "Nếu GPL không được các bên thỏa thuận, bị cáo bất kể thiếu các quyền cần thiết để sao chép, phân phối và làm cho phần mềm 'netfilter / iptables' có sẵn công khai."Bởi vì bị đơn không tuân thủ GPL, nên họ phải ngừng sử dụng phần mềm này..[25] Thrường hợp ở (Mỹ MySQL với Progress) đã được giải quyết trước khi phán quyết được đưa ra, nhưng tại phiên điều trần ban đầu, Thẩm phán Saris "không thấy lý do gì" rằng GPL sẽ không được thi hành..[26]

Khoảng năm 2004 luật sư Lawrence Rosen tranh luận trong bài luận Tại sao Phạm vi công cộng không phải là một giấy phép phần mềm có thể không thực sự từ bỏ và không thể hiểu là cấp phép theo giấy phép FOSS,[27] một vị trí phải đối mặt với sự phản đối của Daniel J. Bernstein những người khác.[28] Vào năm 2012, tranh chấp cuối cùng đã được giải quyết khi Rosen chấp nhận các CC0 là một giấy phép nguồn mở, trong khi thừa nhận rằng trái với bản quyền yêu cầu trước đó của mình có thể phải từ bỏ, được hỗ trợ bởi các quyết định củaTòa phúc thẩm Hoa Kỳ cho Vòng thứ chín.[29]

Năm 2007, sau nhiều năm thảo luận dự thảo,GPLv3 bản cập nhật lớn của GPLv2 đã được phát hành. Bản phát hành đã gây tranh cãi do phạm vi mở rộng đáng kể của giấy phép[30], khiến nó không tương thích với GPLv2.[31] Một số dự án FOSS lớn (Linux kernel,[32][33] MySQL,[34] BusyBox,[35][36] Blender,[37] VLC media player[38]) đã quyết định không chấp nhận GPLv3. Mặt khác, trong năm 2009, hai năm sau khi phát hành GPLv3, Quản lý văn phòng chương trình nguồn mở của Google Chris DiBona đã báo cáo rằng số lượng các dự án mã nguồn mở được cấp phép phần mềm đã chuyển sang GPLv3 từ GPLv2 là 50%, chỉ bao gồm các dự án được lưu trữ tại Google Code.[39]

Những năm 2010

[sửa | sửa mã nguồn]

Năm 2011, bốn năm sau khi phát hành GPLv3, 6.5% giấy phép nguồn mở của các dự án là GPLv3 trong khi 42,5% vẫn là GPLv2 theo dữ liệu Black Duck Software.[33][40] Sau năm 2011, nhà phân tích Matthew Aslett của 451 Group đã lập luận trong một bài đăng trên blog rằng các giấy phép copyleft đã bị từ chối và giấy phép được phép tăng lên, dựa trên số liệu thống kê từ Black Duck Software.[41][42]

Năm 2015 theo số liệu thống kê của Black Duck Software[43] và GitHub,[44] giấy phép MIT trở thành giấy phép nguồn mở phổ biến nhất và GPLv2 bị đẩy xuống vị trí thứ hai trong khi giấy phép Apache theo sau sau đây đã ở vị trí thứ ba. Tháng 6 năm 2016, một phân tích về các gói của Dự án Fedora được tiết lộ là hầu hết các giấy phép sử dụng của GPL, MIT, BSD và LGPL.[45]

Định nghĩa

[sửa | sửa mã nguồn]

Giấy phép "nguồn mở" được OSI phê chuẩn

[sửa | sửa mã nguồn]

Tổ chức Open Source Initiative (OSI) định nghĩa và duy trì một danh sách các giấy phép nguồn mở được chấp thuận. OSI đồng ý với FSF trên tất cả các giấy phép Phần mềm Tự do được sử dụng rộng rãi, nhưng khác với danh sách của FSF, vì nó phê duyệt dựa trên Định nghĩa nguồn mở hơn là Định nghĩa phần mềm tự do. Nó xem xét Free Software Permissive là một tham chiếu cho giấy phép phần mềm tự do.[cần dẫn nguồn][cần giải thích] Vì vậy yêu cầu phê duyệt giấy phép của nó là khác nhau.

Giấy phép "phần mềm tự do" được FSF phê duyệt

[sửa | sửa mã nguồn]

Free Software Foundation, nhóm duy trì Định nghĩa phần mềm tự do, duy trì một danh sách không đầy đủ về Giấy phép Phần mềm Tự do.[46]

Free Software Foundation ưu ái giấy phép phần mềm tự do copyleft (share-alike) thay vì cấp phép Phần mềm Tự do miễn phí cho hầu hết các mục đích. Thư của nó phân biệt giữa các giấy phép phần mềm tự do tương thích hoặc không tương thích với Copyleft GNU General Public License. của FSF.

Điều kiện trong giấy phép phần mềm tự do

[sửa | sửa mã nguồn]

Có tồn tại một cuộc tranh luận đang diễn ra trong cộng đồng phần mềm tự do về ranh giới giữa những hạn chế nào có thể được áp dụng và vẫn được gọi là "tự do".[cần dẫn nguồn]

Chỉ "phần mềm phạm vi công cộng" và phần mềm theo Giấy phép tương tự phạm vi công cộng là hạn chế tự do.[cần dẫn nguồn] Ví dụ về các giấy phép tương tự phạm vi công cộng, giấy phép WTFPL và CC0. Cấp phép có thể mang các nghĩa vụ nhỏ như ghi công tác giả nhưng cho phép thực tế tất cả các trường hợp sử dụng mã. Một số giấy phép, cụ thể là giấy phép copyleft, bao gồm các hạn chế cố ý mạnh hơn (đặc biệt là trên phân phối/nhà phân phối) để buộc các dự án có nguồn gốc đảm bảo các quyền cụ thể không thể lấy đi.

Copyleft

[sửa | sửa mã nguồn]
Bài chi tiết: copyleft

Giấy phép chia sẻ phần mềm tự do được viết bởi Richard Stallman giữa những năm 1980 đã đi tiên phong trong một khái niệm được gọi là "copyleft". Việc tuân thủ các quy định copyleft cho biết rằng khi các phiên bản sửa đổi của phần mềm tự do được phân phối, chúng phải được phân phối theo cùng các điều khoản như phần mềm gốc. Do đó chúng được gọi là "chia sẻ và chia sẻ tương tự" hoặc "quid pro quo". Điều này dẫn đến phần mềm mới là nguồn mở. Vì copyleft đảm bảo rằng các thế hệ sau của phần mềm cho phép tự do sửa đổi mã, đây là "phần mềm tự do". Các giấy phép không copyleft không đảm bảo rằng các thế hệ sau của phần mềm sẽ vẫn miễn phí.

Các nhà phát triển sử dụng mã GPL trong sản phẩm của họ phải cung cấp mã nguồn cho bất kỳ ai khi họ chia sẻ hoặc bán mã đối tượng.Trong trường hợp này, mã nguồn cũng phải chứa bất kỳ thay đổi nào mà nhà phát triển có thể đã thực hiện. Nếu mã GPL được sử dụng nhưng không được chia sẻ hoặc bán, mã này không bắt buộc phải có sẵn và mọi thay đổi có thể vẫn là riêng tư. Điều này cho phép các nhà phát triển và tổ chức sử dụng và sửa đổi mã GPL cho các mục đích cá nhân (nghĩa là, khi mã hoặc dự án không được bán hoặc chia sẻ) mà không cần phải thực hiện thay đổi của họ cho công chúng.

Những người ủng hộ GPL cho rằng bằng cách ủy thác rằng các tác phẩm phái sinh vẫn còn theo GPL, nó thúc đẩy sự phát triển của phần mềm tự do và đòi hỏi sự tham gia bình đẳng của tất cả người dùng. Những người phản đối GPL [47] cho rằng "không có giấy phép nào có thể đảm bảo tính sẵn có của phần mềm trong tương lai" và những nhược điểm của GPL lớn hơn lợi thế của nó.[48] Một số người cũng cho rằng hạn chế phân phối làm cho giấy phép ít mtựhdo ơn. Trong khi những người ủng hộ cho rằng không bảo toàn tự do trong quá trình phân phối sẽ làm cho nó ít tự do hơn. Ví dụ, một giấy phép không copyleft không cho phép tác giả tự do xem các phiên bản sửa đổi của tác phẩm của mình nếu nó được xuất bản công khai, trong khi đó một giấy phép copyleft không cấp quyền tự do đó.

Trả đũa bằng sáng chế

[sửa | sửa mã nguồn]

Trong những năm 1990, các giấy phép phần mềm tự do bắt đầu bao gồm các điều khoản, chẳng hạn như trả đũa bằng sáng chế, để bảo vệ chống lại các trường hợp kiện tụng bằng sáng chế phần mềm - một vấn đề chưa từng tồn tại trước đây. Mối đe dọa mới này là một trong những lý do để viết phiên bản 3 của GNU GPL vào năm 2006.[49] Trong những năm gần đây, thuật ngữ tivoization mô tả quá trình hạn chế phần cứng được sử dụng để ngăn người dùng chạy các phiên bản phần mềm sửa đổi trên phần cứng đó thiết bị TiVo là một ví dụ.Nó được FSF xem như một cách để biến phần mềm tự do thành không có hiệu quả, và là lý do tại sao họ đã chọn cấm nó trong GPLv3.[50] Hầu hết các giấy phép phần mềm tự do mới được viết kể từ cuối những năm 1990 đều bao gồm một số điều khoản trả đũa bằng sáng chế. Các biện pháp này quy định rằng các quyền của mình theo giấy phép (chẳng hạn như phân phối lại), có thể bị chấm dứt nếu một người cố gắng thực thi các bằng sáng chế liên quan đến phần mềm được cấp phép, trong một số trường hợp nhất định. Ví dụ, Apple Public Source License có thể chấm dứt quyền của người dùng nếu người dùng nói trên bắt tay vào các thủ tục kiện tụng chống lại họ do kiện tụng bằng sáng chế. Trả đũa bằng sáng chế xuất hiện để đáp ứng với sự gia tăng và lạm dụng các bằng sáng chế phần mềm.

Hạn chế phần cứng

[sửa | sửa mã nguồn]

GNU GPL v3 bao gồmbao gồm các ngôn ngữ cụ thể cấm các hạn chế bổ sung được thực thi bởi các hạn chế phần cứng và quản lý quyền kỹ thuật số (DRM), một thực hành FSF gọi tivoization sau Tivo sử dụng phần mềm GPL trên các thiết bị không cho phép người dùng sửa đổi phần mềm đó.

Ghi nhận tác giả, tuyên bố từ chối trách nhiệm và thông báo

[sửa | sửa mã nguồn]

Phần lớn giấy phép phần mềm tự do yêu cầu phần mềm sửa đổi không yêu cầu được sửa đổi. Một số giấy phép cũng yêu cầu giữ bản quyền được tạo. Một ví dụ như vậy là GNU GPL v2, yêu cầu các chương trình tương tác in thông tin bảo hành hoặc giấy phép, có thể không xóa các thông báo này khỏi các phiên bản được sửa đổi nhằm phân phối.

Vấn đề thực tế với giấy phép

[sửa | sửa mã nguồn]

Tương thích giấy phép

[sửa | sửa mã nguồn]
License compatibility between common FOSS software licenses according to David A. Wheeler (2007): the vector arrows denote a one directional compatibility, therefore better compatibility on the left side ("permissive licenses") than on the right side ("copyleft licenses")[51]

Giấy phép của các gói phần mềm chứa các yêu cầu mâu thuẫn nhau, khiến cho không thể kết hợp mã nguồn từ các gói đó để tạo các gói phần mềm mới.[52] Khả năng tương thích giấy phép giữa giấy phép copyleft và giấy phép khác thường chỉ là khả năng tương thích một chiều.[53] Đặc tính "tương thích một chiều" này bị chỉ trích bởi Apache Foundation, tổ chức cấp Giấy phép Apache mà không có đặc điểm này.[54] Giấy phép không copyleft, chẳng hạn như giấy phép cấp phép cho FOSS, có tương tác giấy phép ít phức tạp hơn và thường thể hiện khả năng tương thích giấy phép tốt hơn.[55][56] Ví dụ: nếu một giấy phép nói "phiên bản sửa đổi phải đề cập đến nhà phát triển trong bất kỳ tài liệu quảng cáo nào" và giấy phép khác nói "phiên bản sửa đổi không thể chứa các yêu cầu phân bổ bổ sung", thì, nếu ai đó kết hợp gói phần mềm sử dụng một giấy phép với gói phần mềm trong đó sử dụng cái khác, sẽ không thể phân phối kết hợp vì những yêu cầu mâu thuẫn này không thể được đáp ứng đồng thời. Vì vậy, hai gói này sẽ không tương thích giấy phép. Khi nói đến giấy phép phần mềm copyleft, chúng vốn không tương thích với các giấy phép copyleft khác, ngay cả bản thân GPLv2 cũng không tương thích với GPLv3.[31][57]

Mục đích sử dụng

[sửa | sửa mã nguồn]

Các hạn chế khi sử dụng phần mềm ("hạn chế sử dụng") thường không được chấp nhận theo các bản phân phối dựa trên FSF, OSI, Debian, hay BSD. Các ví dụ bao gồm việc cấm sử dụng phần mềm cho các ứng dụng phi cá nhân, cho mục đích quân sự, để so sánh hoặc đo benchmark, cho các phương tiện nghi vấn đạo đức[58] hoặc trong các tổ chức thương mại.[59]

Thị phần

[sửa | sửa mã nguồn]

Trong khi về mặt lịch sử, giấy phép FOSS được sử dụng rộng rãi nhất là GPLv2, vào năm 2015, theo Black Duck Software[60] giấy phép MIT cho phép đã thay thế GPLv2 ở vị trí thứ hai trong khi giấy phép Apache cho phép ở vị trí thứ ba. Một nghiên cứu từ năm 2012, sử dụng dữ liệu công khai có sẵn, chỉ trích Black Duck Software vì không xuất bản phương pháp luận của họ được sử dụng trong việc thu thập số liệu thống kê.[61] Daniel German, giáo sư Khoa Khoa học Máy tính tại Đại học Victoria ở Canada, đã trình bày một bài nói chuyện vào năm 2013 về những thách thức về phương pháp luận trong việc xác định giấy phép phần mềm tự do được sử dụng rộng rãi nhất, và chỉ ra cách ông không thể nhân rộng kết quả từ Black Duck Software.[62]

Một nghiên cứu trên GitHub năm 2015 về dữ liệu thống kê của họ cho thấy rằng giấy phép MIT là giấy phép FOSS nổi bật nhất trên nền tảng đó.[63]

Tháng 6/2016 một phân tích về các gói của Fedora Project cho thấy là giấy phép được sử dụng nhiều nhất trong họ GPL, theo sau là MIT, BSD, họ LGP, Artistic (cho các gói Perl), LPPL (cho các gói texlive), và ASL. GNU GPLv2+ là giấy phép phổ biến nhất[64]

Xem thêm

[sửa | sửa mã nguồn]

Ghi chú

[sửa | sửa mã nguồn]
  1. ^ Larry Troan (2005). “Open Source from a Proprietary Perspective” (PDF). RedHat Summit 2006 Nashville. redhat.com. tr. 10. Bản gốc (pdf) lưu trữ ngày 6 tháng 3 năm 2016. Truy cập ngày 29 tháng 12 năm 2015.
  2. ^ Wheeler, David A. (2015). “The fight for freedom”. Bản gốc lưu trữ ngày 4 tháng 7 năm 2017. Truy cập ngày 21 tháng 11 năm 2018.
  3. ^ Hancock, Terry (29 tháng 8 năm 2008). “What if copyright didn't apply to binary executables?”. Free Software Magazine. Bản gốc lưu trữ ngày 25 tháng 1 năm 2016. Truy cập ngày 25 tháng 1 năm 2016.
  4. ^ Apple Computer, Inc. v. Franklin Computer Corporation Puts the Byte Back into Copyright Protection for Computer Programs in Golden Gate University Law Review Volume 14, Issue 2, Article 3 by Jan L. Nussbaum (January 1984)
  5. ^ Lemley, Menell, Merges and Samuelson. Software and Internet Law, p. 34.
  6. ^ “GNU Emacs Copying Permission Notice (1985)”. Truy cập ngày 8 tháng 11 năm 2015.
  7. ^ “Free Software - GPL Enforcement”. Tech Insider. Truy cập ngày 8 tháng 11 năm 2015.
  8. ^ “GCC Releases”. Truy cập ngày 19 tháng 3 năm 2015.
  9. ^ “GPLv3 - Transcript of Richard Stallman from the second international GPLv3 conference, Porto Alegre, Brazil; 2006-04-21”. Truy cập ngày 19 tháng 3 năm 2015.
  10. ^ Mark (8 tháng 5 năm 2008). “The Curse of Open Source License Proliferation”. socializedsoftware.com. Bản gốc lưu trữ ngày 8 tháng 12 năm 2015. Truy cập ngày 30 tháng 11 năm 2015. GNU General Public License (GPL) 2.0 58.69% GNU Lesser General Public License (LGPL) 2.1 11.39% Artistic License (Perl) 7.46% BSD License 6.50% Apache License 2.0 2.92% MIT License 2.58% GNU General Public Liense (GPL) 3.0 1.64% Mozilla Public License (MPL) 1.1 1.37% Common Public License 0.83% zlib/lippng License 0.64%
  11. ^ David A. Wheeler. “Estimating Linux's Size”.
  12. ^ “SourceForge.net: Software Map”. Dwheeler.com. Bản gốc lưu trữ ngày 13 tháng 2 năm 2017. Truy cập ngày 17 tháng 11 năm 2008. License -> OSI: […] GNU General Public License (GPL) (32641 projects), GNU Library or Lesser General Public License (LGPL) (4889 projects of 45727, 82.1%)
  13. ^ “GNU Emacs Copying Permission Notice (1985)”. Truy cập ngày 8 tháng 11 năm 2015.
  14. ^ “Free Software - GPL Enforcement”. Tech Insider. Truy cập ngày 8 tháng 11 năm 2015.
  15. ^ “GCC Releases”. Truy cập ngày 19 tháng 3 năm 2015.
  16. ^ “GPLv3 - Transcript of Richard Stallman from the second international GPLv3 conference, Porto Alegre, Brazil; 2006-04-21”. Truy cập ngày 19 tháng 3 năm 2015.
  17. ^ Mark (ngày 8 tháng 5 năm 2008). “The Curse of Open Source License Proliferation”. socializedsoftware.com. Bản gốc lưu trữ ngày 8 tháng 12 năm 2015. Truy cập ngày 30 tháng 11 năm 2015. GNU General Public License (GPL) 2.0 58.69% GNU Lesser General Public License (LGPL) 2.1 11.39% Artistic License (Perl) 7.46% BSD License 6.50% Apache License 2.0 2.92% MIT License 2.58% GNU General Public Liense (GPL) 3.0 1.64% Mozilla Public License (MPL) 1.1 1.37% Common Public License 0.83% zlib/lippng License 0.64%
  18. ^ David A. Wheeler. “Estimating Linux's Size”.
  19. ^ “SourceForge.net: Software Map”. Dwheeler.com. Bản gốc lưu trữ ngày 13 tháng 2 năm 2017. Truy cập ngày 17 tháng 11 năm 2008. License -> OSI: […] GNU General Public License (GPL) (32641 projects), GNU Library or Lesser General Public License (LGPL) (4889 projects of 45727, 82.1%)
  20. ^ Kelty, Christpher M. (2008). “The Cultural Significance of free Software - Two Bits” (PDF). Duke University press - durham and london. tr. 99. Prior to 1998, Free Software referred either to the Free Software Foundation (and the watchful, micromanaging eye of Stallman) or to one of thousands of different commercial, avocational, or university-research projects, processes, licenses, and ideologies that had a variety of names: sourceware, freeware, shareware, open software, public domain software, and so on. The term Open Source, by contrast, sought to encompass them all in one movement.
  21. ^ “Netscape Announces Plans to Make Next-Generation Communicator Source Code Available Free on the Net”. Netscape Communications Corporation. ngày 22 tháng 1 năm 1998. Bản gốc lưu trữ ngày 1 tháng 4 năm 2007. Truy cập ngày 8 tháng 8 năm 2013. Bold move to harness creative power of thousands of internet developers; company makes Netscape Navigator and Communicator 4.0 immediately free for all users, seeding market for enterprise and netcenter businesses
  22. ^ “MOUNTAIN VIEW, Calif., April 1 /PRNewswire/ -- Netscape Communications and open source developers are celebrating the first anniversary, ngày 31 tháng 3 năm 1999, of the release of Netscape's browser source code to mozilla.org”. Netscape Communications. ngày 31 tháng 3 năm 1999. Truy cập ngày 10 tháng 1 năm 2013. ... the organization that manages open source developers working on the next generation of Netscape's browser and communication software. This event marked a historical milestone for the Internet as Netscape became the first major commercial software company to open its source code, a trend that has since been followed by several other corporations. Since the code was first published on the Internet, thousands of individuals and organizations have downloaded it and made hundreds of contributions to the software. Mozilla.org is now celebrating this one-year anniversary with a party Thursday night in San Francisco.
  23. ^ Kelty, Christpher M. (2008). “The Cultural Significance of free Software - Two Bits” (PDF). Duke University press - durham and london. tr. 100. The term Open Source, by contrast, sought to encompass them all in one movement. The event that precipitated this attempted semantic coup d’état was the release of the source code for Netscape’s Communicator Web browser. It’s tough to overestimate the importance of Netscape to the fortunes of Free Software. […] But Netscape is far more famous among geeks for giving away something else, in 1998: the source code to Netscape Communicator (née Navigator).
  24. ^ “Report of License Proliferation Committee and draft FAQ”. Open Source Initiative. ngày 12 tháng 12 năm 2007.
  25. ^ “Groklaw - The German GPL Order - Translated”. Truy cập ngày 19 tháng 3 năm 2015.
  26. ^ See Progress Software Corporation v. MySQL AB, 195 F. Supp. 2d 328 (D. Mass. 2002), on defendant's motion for preliminary injunction.
  27. ^ Lawrence Rosen (ngày 25 tháng 5 năm 2004). “Why the public domain isn't a license”. rosenlaw.com. Truy cập ngày 22 tháng 2 năm 2016.
  28. ^ Bernstein, Daniel J. (2004). “Placing documents into the public domain”. Most rights can be voluntarily abandoned ("waived") by the owner of the rights. Legislators can go to extra effort to create rights that can't be abandoned, but usually they don't do this. In particular, you can voluntarily abandon your United States copyrights: "It is well settled that rights gained under the Copyright Act may be abandoned. But abandonment of a right must be manifested by some overt act indicating an intention to abandon that right. See Hampton v. Paramount Pictures Corp., 279 F.2d 100, 104 (9th Cir. 1960)."
  29. ^ Lawrence Rosen (ngày 8 tháng 3 năm 2012). “(License-review) (License-discuss) CC0 incompliant with OSD on patents, (was: MXM compared to CC0)”. opensource.org. Bản gốc lưu trữ ngày 12 tháng 3 năm 2016. Truy cập ngày 25 tháng 11 năm 2018. The case you referenced in your email, Hampton v. Paramount Pictures, 279 F.2d 100 (9th Cir. Cal. 1960), stands for the proposition that, at least in the Ninth Circuit, a person can indeed abandon his copyrights (counter to what I wrote in my article) -- but it takes the equivalent of a manifest license to do so.:-)... For the record, I have already voted +1 to approve the CC0 public domain dedication and fallback license as OSD compliant. I admit that I have argued for years against the "public domain" as an open source license, but in retrospect, considering the minimal risk to developers and users relying on such software and the evident popularity of that "license", I changed my mind. One can't stand in the way of a fire hose of free public domain software, even if it doesn't come with a better FOSS license that I trust more.
  30. ^ Mark (ngày 8 tháng 5 năm 2008). “The Curse of Open Source License Proliferation”. socializedsoftware.com. Bản gốc lưu trữ ngày 8 tháng 12 năm 2015. Truy cập ngày 30 tháng 11 năm 2015. Currently the decision to move from GPL v2 to GPL v3 is being hotly debated by many open source projects. According to Palamida, a provider of IP compliance software, there have been roughly 2489 open source projects that have moved from GPLv2 to later versions.
  31. ^ a b “Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2?”. gnu.org. Truy cập ngày 3 tháng 6 năm 2014. No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2. However, if code is released under GPL 'version 2 or later,' that is compatible with GPLv3 because GPLv3 is one of the options it permits.
  32. ^ Kerner, Sean Michael (ngày 8 tháng 1 năm 2008). “Torvalds Still Keen On GPLv2”. internetnews.com. Truy cập ngày 12 tháng 2 năm 2015. In some ways, Linux was the project that really made the split clear between what the FSF is pushing which is very different from what open source and Linux has always been about, which is more of a technical superiority instead of a -- this religious belief in freedom," Torvalds told Zemlin. So, the GPL Version 3 reflects the FSF's goals and the GPL Version 2 pretty closely matches what I think a license should do and so right now, Version 2 is where the kernel is.
  33. ^ a b Byfield, Bruce (ngày 22 tháng 11 năm 2011). “7 Reasons Why Free Software Is Losing Influence: Page 2”. Datamation.com. Truy cập ngày 23 tháng 8 năm 2013. At the time, the decision seemed sensible in the face of a deadlock. But now, GPLv2 is used for 42.5% of free software, and GPLv3 for less than 6.5%, according to Black Duck Software.
  34. ^ “MySQL changes license to avoid GPLv3”. Computer business review online. ngày 4 tháng 1 năm 2007. Bản gốc lưu trữ ngày 6 tháng 2 năm 2007. Truy cập ngày 21 tháng 11 năm 2016.
  35. ^ corbet (ngày 1 tháng 10 năm 2006). “Busy busy busybox”. lwn.net. Truy cập ngày 21 tháng 11 năm 2015. Since BusyBox can be found in so many embedded systems, it finds itself at the core of the GPLv3 anti-DRM debate. […] The real outcomes, however, are this: BusyBox will be GPLv2 only starting with the next release. It is generally accepted that stripping out the "or any later version" is legally defensible, and that the merging of other GPLv2-only code will force that issue in any case.
  36. ^ Landley, Rob (ngày 9 tháng 9 năm 2006). “Re: Move GPLv2 vs v3 fun...”. lwn.net. Truy cập ngày 21 tháng 11 năm 2015. Don't invent a straw man argument please. I consider licensing BusyBox under GPLv3 to be useless, unnecessary, overcomplicated, and confusing, and in addition to that it has actual downsides. 1) Useless: We're never dropping GPLv2.
  37. ^ Prokoudine, Alexandre (ngày 26 tháng 1 năm 2012). “What's up with DWG adoption in free software?”. libregraphicsworld.org. Bản gốc lưu trữ ngày 9 tháng 11 năm 2016. Truy cập ngày 5 tháng 12 năm 2015. Blender is also still 'GPLv2 or later'. For the time being we stick to that, moving to GPL 3 has no evident benefits I know of.
  38. ^ Denis-Courmont, Rémi. “VLC media player to remain under GNU GPL version 2”. videolan.org. Truy cập ngày 21 tháng 11 năm 2015. In 2001, VLC was released under the OSI-approved GNU General Public version 2, with the commonly-offered option to use 'any later version' thereof (though there was not any such later version at the time). Following the release by the Free Software Foundation (FSF) of the new version 3 of its GNU General Public License (GPL) on the 29th of June 2007, contributors to the VLC media player, and other software projects hosted at videolan.org, debated the possibility of updating the licensing terms for future version of the VLC media player and other hosted projects, to version 3 of the GPL.... There is strong concern that these new additional requirements might not match the industrial and economic reality of our time, especially in the market of consumer electronics. It is our belief that changing our licensing terms to GPL version 3 would currently not be in the best interest of our community as a whole. Consequently, we plan to keep distributing future versions of VLC media player under the terms of the GPL version 2.
  39. ^ Asay, Matt (ngày 23 tháng 7 năm 2009). “GPLv3 hits 50 percent adoption | The Open Road - CNET News”. News.cnet.com. Bản gốc lưu trữ ngày 29 tháng 10 năm 2013. Truy cập ngày 2 tháng 9 năm 2013.
  40. ^ Proffitt, Brian (ngày 16 tháng 12 năm 2011). “GPL, copyleft use declining faster than ever”. ITworld. Bản gốc lưu trữ ngày 4 tháng 9 năm 2017. Truy cập ngày 25 tháng 11 năm 2018.
  41. ^ Proffitt, Brian (ngày 16 tháng 12 năm 2011). “GPL, copyleft use declining faster than ever - Data suggests a sharper rate of decline, which raises the question: why?”. IT world. Bản gốc lưu trữ ngày 3 tháng 12 năm 2013. Truy cập ngày 23 tháng 8 năm 2013.
  42. ^ Aslett, Matthew (ngày 15 tháng 12 năm 2011). “On the continuing decline of the GPL”. Bản gốc lưu trữ ngày 9 tháng 12 năm 2016. Truy cập ngày 25 tháng 11 năm 2018.
  43. ^ “Top 20 licenses”. Black Duck Software. ngày 19 tháng 11 năm 2015. Bản gốc lưu trữ ngày 19 tháng 7 năm 2016. Truy cập ngày 19 tháng 11 năm 2015. 1. MIT license 24%, 2. GNU General Public License (GPL) 2.0 23%, 3. Apache License 16%, 4. GNU General Public License (GPL) 3.0 9%, 5. BSD License 2.0 (3-clause, New or Revised) License 6%, 6. GNU Lesser General Public License (LGPL) 2.1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3.0 2%, 9. Microsoft Public License 2%, 10. Eclipse Public License (EPL) 2%
  44. ^ Balter, Ben (ngày 9 tháng 3 năm 2015). “Open source license usage on GitHub.com”. github.com. Truy cập ngày 21 tháng 11 năm 2015. 1 MIT 44.69%, 2 Other 15.68%, 3 GPLv2 12.96%, 4 Apache 11.19%, 5 GPLv3 8.88%, 6 BSD 3-clause 4.53%, 7 Unlicense 1.87%, 8 BSD 2-clause 1.70%, 9 LGPLv3 1.30%, 10 AGPLv3 1.05%
  45. ^ Anwesha Das (ngày 22 tháng 6 năm 2016). “Software Licenses in Fedora Ecosystem”. anweshadas.in. Truy cập ngày 27 tháng 6 năm 2016. From the above chart it is clear that the GPL family is the highest used (I had miscalculated it as MIT before).The other major licenses are MIT, BSD, the LGPL family, Artistic (for Perl packages), LPPL (foe texlive packages), ASL.
  46. ^ “Various Licenses and Comments about Them - GNU Project - Free Software Foundation”. Truy cập ngày 19 tháng 3 năm 2015.
  47. ^ “Why you should use a BSD style license for your Open Source Project”. Truy cập ngày 19 tháng 3 năm 2015.
  48. ^ “Why you should use a BSD style license for your Open Source Project”. Truy cập ngày 19 tháng 3 năm 2015.
  49. ^ “GPLv3 - Transcript of Richard Stallman from the fifth international GPLv3 conference, Tokyo, Japan; 2006-11-21”. Truy cập ngày 19 tháng 3 năm 2015.
  50. ^ “Richard Stallman discusses changes in GPLv3”. a new method of trying to deprive the users of freedom. In broad terms we refer to this as tivoisation.
  51. ^ Wheeler, David A. (ngày 27 tháng 9 năm 2007). “The Free-Libre / Open Source Software (FLOSS) License Slide”.
  52. ^ “How GPLv3 tackles license proliferation”. Bản gốc lưu trữ ngày 2 tháng 5 năm 2013.
  53. ^ LAURENT, Philippe (ngày 24 tháng 9 năm 2008). “The GPLv3 and compatibility issues” (PDF). European Open source Lawyers Event 2008. University of Namur – Belgium. tr. 7. Bản gốc (pdf) lưu trữ ngày 4 tháng 3 năm 2016. Truy cập ngày 30 tháng 5 năm 2015. Copyleft is the main source of compatibility problems.
  54. ^ Apache foundation (ngày 30 tháng 5 năm 2015). “GPL compatibility”. Truy cập ngày 30 tháng 5 năm 2015. Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.
  55. ^ Hanwell, Marcus D. (28 tháng 1 năm 2014). “Should I use a permissive license? Copyleft? Or something in the middle?”. opensource.com. Truy cập ngày 30 tháng 5 năm 2015. Permissive licensing simplifies things One reason the business world, and more and more developers […], favor permissive licenses is in the simplicity of reuse. The license usually only pertains to the source code that is licensed and makes no attempt to infer any conditions upon any other component, and because of this there is no need to define what constitutes a derived work. I have also never seen a license compatibility chart for permissive licenses; it seems that they are all compatible.
  56. ^ “Licence Compatibility and Interoperability”. Open-Source Software - Develop, share, and reuse open source software for public administrations. joinup.ec.europa.eu. Bản gốc lưu trữ ngày 17 tháng 6 năm 2015. Truy cập ngày 30 tháng 5 năm 2015. The licences for distributing free or open source software (FOSS) are divided in two families: permissive and copyleft. Permissive licences (BSD, MIT, X11, Apache, Zope) are generally compatible and interoperable with most other licences, tolerating to merge, combine or improve the covered code and to re-distribute it under many licences (including non-free or 'proprietary').
  57. ^ Landley, Rob. “CELF 2013 Toybox talk”. landley.net. Truy cập ngày 21 tháng 8 năm 2013. GPLv3 broke "the" GPL into incompatible forks that can't share code.
  58. ^ “The HESSLA's Problems - GNU Project - Free Software Foundation”. Truy cập ngày 19 tháng 3 năm 2015.
  59. ^ “GPLv3 - Transcript of Richard Stallman from the third international GPLv3 conference, Barcelona; 2006-06-22”. Truy cập ngày 19 tháng 3 năm 2015.
  60. ^ “Top 20 licenses”. Black Duck Software. ngày 19 tháng 11 năm 2015. Bản gốc lưu trữ ngày 19 tháng 7 năm 2016. Truy cập ngày 19 tháng 11 năm 2015. 1. MIT license 24%, 2. GNU General Public License (GPL) 2.0 23%, 3. Apache License 16%, 4. GNU General Public License (GPL) 3.0 9%, 5. BSD License 2.0 (3-clause, New or Revised) License 6%, 6. GNU Lesser General Public License (LGPL) 2.1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3.0 2%, 9. Microsoft Public License 2%, 10. Eclipse Public License (EPL) 2%
  61. ^ Sam Varghese (ngày 7 tháng 2 năm 2012). “GPL use in Debian on the rise: study”. Itwire.com. Truy cập ngày 2 tháng 9 năm 2013.
  62. ^ “Surveying open source licenses”. Lwn.net. Truy cập ngày 2 tháng 9 năm 2013.
  63. ^ Balter, Ben (9 tháng 3 năm 2015). “Open source license usage on GitHub.com”. github.com. Truy cập ngày 21 tháng 11 năm 2015. 1 MIT 44.69%, 2 Other 15.68%, 3 GPLv2 12.96%, 4 Apache 11.19%, 5 GPLv3 8.88%, 6 BSD 3-clause 4.53%, 7 Unlicense 1.87%, 8 BSD 2-clause 1.70%, 9 LGPLv3 1.30%, 10 AGPLv3 1.05%
  64. ^ Anwesha Das (ngày 22 tháng 6 năm 2016). “Software Licenses in Fedora Ecosystem”. anweshadas.in. Truy cập ngày 27 tháng 6 năm 2016. From the above chart it is clear that the GPL family is the highest used (I had miscalculated it as MIT before).The other major licenses are MIT, BSD, the LGPL family, Artistic (for Perl packages), LPPL (foe texlive packages), ASL.

Chú thích

[sửa | sửa mã nguồn]

Liên kết ngoài

[sửa | sửa mã nguồn]
Lấy từ “https://vi.wikipedia.org/w/index.php?title=Giấy_phép_phần_mềm_tự_do&oldid=71736310”