Python là mã nguồn mở hay được cấp phép?

Nếu bạn đang chia sẻ mã của mình, bạn cũng cần có giấy phép. Giấy phép là một thỏa thuận xác định một số tiêu chí chính về chương trình của bạn, chẳng hạn như, nhưng không giới hạn đối với

• ai có thể sử dụng mã của bạn
• họ có thể sử dụng mã của bạn đến mức nào
• những loại thuộc tính được yêu cầu
• làm thế nào họ có thể sử dụng mã của bạn
• ai chịu trách nhiệm nếu xảy ra sự cố
• ai có thể sửa đổi mã của bạn
• cấp giấy phép phụ
• ai có thể bán lại mã của bạn hoặc thứ gì đó được tạo bằng mã đó, v.v. vân vân

May mắn thay, nếu mã của bạn là nguồn mở, có một số tùy chọn giấy phép phần mềm nguồn mở thuận tiện và sẵn sàng sử dụng mà bạn có thể chọn. Chúng tôi coi những giấy phép này là đương nhiên nhưng chúng giúp các lập trình viên và nhà phát triển nguồn mở đỡ phải đau đầu và chi phí pháp lý

Khi bạn quyết định chia sẻ mã của mình dưới dạng mã nguồn mở, đây là một điều đáng kinh ngạc, giấy phép chủ yếu nhằm mục đích bảo vệ bạn, nhà phát triển, khỏi các tình huống xảy ra sự cố liên quan đến mã hoặc chương trình của bạn

Một trong những tiêu chí quan trọng và quan trọng nhất liên quan đến việc chọn giấy phép nguồn mở thích hợp cho phần mềm của bạn, hoặc cả khi bạn đang làm việc với phần mềm nguồn mở, là giấy phép được cho phép hoặc copyleft.

Giấy phép dễ dãi thoải mái hơn trong các điều khoản của chúng và về cơ bản chúng cho phép bất cứ điều gì người dùng muốn làm với mã nguồn của thư viện, gói, chương trình hoặc phần mềm

Mặt khác, Copyleft đi kèm với một số nghĩa vụ, do đó nó hạn chế hơn theo nghĩa này. Nó thường yêu cầu người dùng tiếp tục sử dụng cùng một giấy phép và tiếp tục chia sẻ mã nguồn của tác phẩm đã sửa đổi của họ [và cả mọi thứ liên quan đến tác phẩm đó]. Tuy nhiên, copyleft cũng có dạng copyleft yếu, có thể dễ dãi và linh hoạt hơn copyleft một chút, nhưng vẫn không hoàn toàn dễ dãi

Copyleft Vs. dễ dãi

Nói chung, các giấy phép nguồn mở thuộc hai loại. dễ dãi và copyleft

Permissive đưa ra ít yêu cầu hơn đối với người dùng của chương trình. Nó không thực thi công việc phái sinh hoặc sửa đổi, đổi thương hiệu, phân phối lại, v.v. để duy trì theo một giấy phép cụ thể. Không yêu cầu rằng trong trường hợp thích ứng thương mại, mã phải được chia sẻ dưới dạng mã nguồn mở

Vì những lý do này, giấy phép nguồn mở dễ dãi được biết là thân thiện với thương mại hơn và nói chung ít nghiêm ngặt hơn

Mặt khác, Copyleft hơi bướng bỉnh hoặc đòi hỏi theo nghĩa đó. Nó thường yêu cầu mã đó vẫn theo cùng một giấy phép nguồn mở hoặc tương tự. Nó cũng có thể áp dụng các hạn chế trong các trường hợp sử dụng thương mại. Mặc dù việc duy trì nguồn mở có thể là một điều tốt, nhưng các hạn chế cũng có thể gây tổn hại cho doanh nghiệp về lâu dài, đặc biệt nếu giấy phép bắt buộc phải duy trì theo cùng một giấy phép.  

Có thể có trường hợp VC hoặc các nhà đầu tư khác tránh làm việc với giấy phép copyleft đơn giản vì nó có thể hàm ý những hạn chế hơn nữa trong tương lai. Copyleft cũng có thể khiến bạn không thể sử dụng giấy phép tùy chỉnh

Tuy nhiên, chắc chắn vẫn có chỗ cho các ứng dụng copyleft trong thế giới mã nguồn mở và các tùy chọn giấy phép nổi tiếng từ cả hai bên vẫn tiếp tục tồn tại và cùng tồn tại.  

Copyleft mạnh so với Copyleft yếu

Copyleft yếu là phiên bản nhẹ hơn của giấy phép copyleft thông thường. Nó thường có các điều kiện ít hạn chế hơn và cho phép một số mã vẫn là độc quyền hoặc không được tiết lộ tùy thuộc vào mối quan hệ với mã nguồn đã sửa đổi

Đây là một lời giải thích hay và chi tiết về copyleft [hoặc copyleft mạnh] so với copyleft yếu từ. TrắngNguồnPhần Mềm. com

Các giấy phép copyleft yếu yêu cầu bạn tiết lộ nguồn của mình trên mã nguồn, nhưng không tiết lộ trên các tệp nhị phân và do đó bạn có thể biên dịch các nguồn được bảo hiểm với những người khác và phân phối các tệp nhị phân kết quả [được hợp nhất] theo giấy phép bạn chọn. Với giấy phép copyleft 'mạnh', họ GPL, bạn có nghĩa vụ sử dụng lại cùng một giấy phép trong trường hợp phân phối lại các bản sao hoặc dẫn xuất trên cả nguồn và tệp nhị phân

Giấy phép mã nguồn mở phổ biến nhất

Hãy xem xét kỹ hơn hầu hết các giấy phép nguồn mở phổ biến

Một số giấy phép mã nguồn mở copyleft phổ biến nhất là

• GNU GPL [copyleft mạnh]
• Giấy phép Công cộng Eclipse 2. 0 [copyleft yếu]
• LGPL [copyleft yếu]
• Giấy phép phân phối và phát triển chung,  CDDL, [copyleft yếu]

Và, một số giấy phép nguồn mở dễ dãi phổ biến nhất là

• Apache-2. 0
• Giấy phép MIT
• Berkeley Software  Phân phối, BSD

Vì thường xảy ra trong thực tiễn pháp lý, có một số sắc thái giữa bản in đẹp của các giấy phép này.  Hãy cùng xem xét các đặc điểm chính của từng giấy phép này.

GPL và AGPL

GPL là một giấy phép hơi phức tạp vì nếu bạn chia sẻ thứ gì đó theo giấy phép GPL, điều này có nghĩa là gói của bạn có thể được sử dụng tự do nhưng nếu ai đó muốn sửa đổi hoặc đóng gói lại và phân phối lại gói của bạn, họ cũng sẽ phải sử dụng cùng một giấy phép GPL

Vì vậy, bạn có thể cân nhắc rằng khán giả của mình sẽ buộc phải sử dụng cùng một giấy phép trong trường hợp đó. Ngoài ra, nếu bạn đang làm việc trên một gói được xuất bản theo giấy phép GPL và dự định phân phối một phiên bản khác hoặc cải tiến của gói đó, bạn không muốn vi phạm thỏa thuận cấp phép, vì vậy, bạn phải sử dụng cùng một giấy phép

Theo nghĩa này, nó có thể hơi hạn chế như một giấy phép nhưng nó cũng hỗ trợ và thúc đẩy việc tiếp tục phân phối nguồn mở, điều này thực sự tốt

Về cơ bản, nếu bạn chia sẻ công việc của mình theo GPL thì có khả năng nó sẽ ở trong cùng một giấy phép nguồn mở

Một điểm quan trọng khác với GPL là nó có 3 biến thể cho đến nay. GPL1, GPL2 và GPL3. Nhưng mỗi biến thể này cũng có các phiên bản "chỉ" và "hoặc mới hơn". Vì vậy, nếu trước đây bạn quyết định điều chỉnh giấy phép chỉ GPL2, thì bạn thậm chí không thể chuyển sang giấy phép GPL3 khi nó ra mắt trong khi nếu bạn chọn giấy phép GPL3 trở lên, điều đó có nghĩa là bạn cũng có thể sử dụng bất kỳ giấy phép nào có sau GPL3 nếu nó

AGPL [Affero GPL] gần như là GPL cho các ứng dụng mạng như trang web hoặc dịch vụ trực tuyến. Nó không phải là copyleft yếu như LGPL và nó là copyleft như GPL. Sự khác biệt duy nhất là người dùng được xác định lại là khách truy cập trang web hoặc người dùng ứng dụng trực tuyến trong trường hợp GPL, người dùng là người dùng chương trình

Bạn có thể xem bài viết thú vị này trên Wikipedia về việc mua lại MySQL và các giấy phép nguồn mở liên quan đã bị ảnh hưởng như thế nào. Bạn có thể xem động lực giấy phép thú vị và sự kiện dẫn đến hệ thống quản lý cơ sở dữ liệu MariaDB sau nỗ lực của Monty Widenius để rẽ nhánh MySQL và phát hành nó theo giấy phép duy nhất GPL với tên MariaDB

LGPL

LGPL hoặc GPL nhỏ hơn là phiên bản copyleft yếu của GPL. Mặc dù chúng giống nhau về nhiều mặt nhưng LGPL cho phép nhiều thứ quan trọng mà GPL không có

Với LGPL

Bạn có thể tự động liên kết đến một thư viện trong phần mềm của mình và bạn sẽ không phải xuất bản phần mềm của mình theo cùng một giấy phép vì điều đó miễn là bạn không sửa đổi thư viện bằng LGPL

Điều này cho phép các ứng dụng độc quyền cũng như các ứng dụng nguồn mở theo các giấy phép khác nhau

Nếu bạn liên kết tĩnh đến thư viện LGPL mặc dù tình hình thay đổi và bạn được yêu cầu xuất bản tác phẩm phái sinh theo LGPL

Có một cuộc thảo luận rất thú vị ở đây về cách GPL hoặc LGPL áp dụng cho các ngôn ngữ được giải thích như Python. Các quy tắc liên kết tĩnh-động GPL/LGPL áp dụng cho các ngôn ngữ được thông dịch như thế nào?

Ngoài ra, nếu bạn muốn tìm hiểu thêm về liên kết tĩnh Vs. liên kết động

Giấy phép Công cộng Eclipse 2. 0

Eclipse là một giấy phép copyleft yếu và nó giống với CDDL hơn là GPL. EPL cho phép kết hợp mã được cấp phép EPL và không phải EPL trong cùng một phần mềm với điều kiện chúng là các mô-đun riêng biệt. EPL cũng cho phép cấp phép phụ

Một tính năng khác của Eclipse Public License 2. 0 là nó yêu cầu các nhà phân phối thương mại bồi thường cho những người đóng góp cho bất kỳ tình huống thiệt hại hoặc kiện cáo nào có thể xảy ra

Eclipse Foundation có một trang Câu hỏi thường gặp rất hay mà bạn có thể tìm thấy tại đây nếu quan tâm

CĐDL

Giấy phép Phát triển và Phân phối Chung là một giấy phép copyleft yếu với mức giới hạn giữa GPL và các giấy phép dễ dãi như Apache 2. 0

Thay vì mọi thứ liên quan hoặc làm việc với mã được xuất bản theo cùng một giấy phép như trong trường hợp GPL, nó chỉ yêu cầu mã nguồn theo CDDL để duy trì theo CDDL

Điều này mang lại sự linh hoạt hơn về việc trộn mã với các giấy phép khác nhau và cũng cung cấp ít hạn chế hơn về quyền cấp phép lại

Mặc dù có vẻ tinh tế nhưng sự khác biệt này có ý nghĩa to lớn. Một ví dụ điển hình là nếu một sản phẩm nguồn đóng như Adobe Photoshop hoặc Microsoft Windows sử dụng mã được cấp phép GPL ở đâu đó trong hệ sinh thái khổng lồ của họ, thì họ phải xuất bản mọi thứ dưới dạng mã nguồn mở theo giấy phép GPL. Có lẽ là một kịch bản ác mộng đối với các công ty hoặc sản phẩm phần mềm độc quyền như vậy

Tuy nhiên, nếu một sản phẩm nguồn đóng sử dụng CDDL, họ sẽ chỉ phải xuất bản mã được cấp phép CDDL và phần mềm đã biên dịch có thể được đóng gói theo một giấy phép khác

Về cơ bản, đó là cách một giấy phép copyleft yếu như CDDL tồn tại ở vị trí thuận lợi giữa giấy phép copyleft và giấy phép dễ dãi

Không giống như các giấy phép copyleft mạnh như GPL, việc trộn các tệp mã nguồn được cấp phép CDDL với các tệp mã nguồn theo các giấy phép khác được cho phép mà không cần cấp phép lại. Theo Sun, sản phẩm phần mềm được biên dịch [“nhị phân”] có thể được cấp phép và bán theo một giấy phép khác, miễn là mã nguồn vẫn có sẵn theo CDDL, điều này sẽ cho phép nhiều trường hợp kinh doanh thương mại hơn, theo Sun. [5][6][7]

Apache-2. 0

Apache 2. 0 được cho phép và nó cũng rất giống với các giấy phép nguồn mở dễ dãi khác như MIT. Tuy nhiên, nó có một thủ thuật đặc biệt. Apache 2. 0 đi kèm với bảo vệ bằng sáng chế cho người dùng và chủ sở hữu phần mềm

Nếu có bất kỳ bằng sáng chế nào liên quan, Apache 2. 0 cấp quyền tự do sử dụng phần mềm và miễn tất cả các giấy phép hoặc phí bằng sáng chế. Khoản trợ cấp này có hiệu lực cho đến khi người dùng quyết định kiện người đóng góp/chủ sở hữu, trong trường hợp đó giấy phép sẽ bị thu hồi ngay lập tức

Mặt khác, Apache 2. 0 trao quyền làm bất cứ điều gì người dùng muốn làm một cách hợp pháp. Nó cũng bảo vệ chủ sở hữu khỏi trách nhiệm và các vấn đề pháp lý bằng cách từ chối bảo hành liên quan đến mã hoặc chương trình

Một cạnh khác của Apache 2. 0 có hơn những giấy phép khác là ngôn ngữ pháp lý phù hợp và tính rõ ràng khiến nó trở thành giấy phép được luật sư yêu thích

Bạn có thể kiểm tra Giấy phép Apache tại đây

MIT

MIT là giấy phép mã nguồn mở phổ biến nhất. Khoảng 50% tất cả các dự án mã nguồn mở theo giấy phép MIT trên Github, đây có lẽ là một ví dụ điển hình tốt cho tất cả các dự án mã nguồn mở trên thế giới

Giấy phép MIT được biết là rất ngắn và đơn giản về cơ bản gợi ý

• phần mềm miễn phí và mã nguồn được chia sẻ công khai
• người dùng có thể làm bất cứ điều gì họ muốn với nó
• [những] người đóng góp/[những] chủ sở hữu không chịu trách nhiệm và không đảm bảo bất cứ điều gì

Mặc dù các luật sư có thể cau mày trước sự đơn giản như vậy, nhưng hầu hết dân công nghệ đều yêu thích nó chính xác vì lý do đó

BSD

BSD có nhiều loại. Một số cái chính là

BSD 0 mệnh đề. Ban đầu được đặt tên là Free Public License 1. 0. 0, mệnh đề 0 BSD không bắt nguồn từ họ giấy phép BSD

BSD 2 mệnh đề. Rất giống với giấy phép MIT, ngoại trừ việc không đề cập rõ ràng đến việc cấp; .

Mặc dù, các quyền này có thể được cấp theo quyền sử dụng. Có thể có những hạn chế đối với một số mục vì chúng không được đề cập rõ ràng, chẳng hạn như cấp phép phụ

BSD 3 mệnh đề . Cấm sử dụng tên cộng tác viên hoặc tên tổ chức để quảng bá sản phẩm bắt nguồn từ mã nguồn gốc.

BSD 4 mệnh đề. Yêu cầu đề cập đến tên của tổ chức trong tất cả các quảng cáo liên quan đến công việc phái sinh. Đây là văn bản bắt buộc phải được đưa vào.

Sản phẩm này bao gồm phần mềm được phát triển bởi [tổ chức]

Ngoài ra còn có các loại Giấy phép BSD thú vị khác như

BSD + Bằng sáng chế 2 điều khoản, đây là tính tương hỗ bằng sáng chế hơi quen thuộc do Apache 2 cung cấp. 0 giấy phép

3 điều khoản BSD + không có hạt nhân, trong đó nêu rõ rằng mã không được cấp phép hoặc không dành cho bất kỳ mục đích sử dụng nào trong bất kỳ cơ sở hạt nhân nào

Bên dưới, bạn có thể truy cập từng giấy phép nguồn mở phổ biến nhất

• MIT
• Apache-2. 0
• BSD-3. 0
• AGPL-3. 0
• LGPL-3. 0
• GPL-3. 0
• CC-BY-4. 0
• CC-BY-NC-4. 0
• CC-BY-NC-SA-4. 0
• CC-BY-SA-4. 0
• CC0-1. 0
• LÀ C
• MPL-2. 0
• không có giấy phép

Thận trọng khi cấp phép tự do

Do có rất nhiều loại giấy phép khác nhau, bạn có thể muốn tạo ra giấy phép thú vị của riêng mình dưới dạng giấy phép dưa chuột và có thể đặt tên cho nó là Snow Frost ATL 5. 0. Chà, giữ ngựa của bạn vì đây có thể không phải là một điều rất khôn ngoan vì một số lý do

Mặc dù dường như có khá nhiều giấy phép nguồn mở nhưng tất cả đều được phê duyệt bởi Sáng kiến ​​nguồn mở OSI

1. Khi bạn cố gắng vận hành bằng giấy phép tự chế của riêng mình, điều này có thể có nghĩa là bạn bị loại khỏi việc sử dụng tài liệu nguồn mở khác chỉ được phép sử dụng bởi các dự án nguồn mở theo giấy phép được OSI phê duyệt
2. Tuy nhiên, một vấn đề lớn hơn là vùng biển chưa được khám phá . Về bất kỳ giấy phép nguồn mở phổ biến nào, bạn có thể lên diễn đàn trực tuyến hoặc hỏi luật sư sở hữu trí tuệ và bạn sẽ dễ dàng nhận được thông tin xác thực và kết quả có thể xảy ra về một trường hợp. Vì, tiền lệ là một nguyên tắc chính trong các vấn đề pháp lý, nên việc có các phán quyết hoặc tập đoàn được thiết lập trước đó sẽ tạo ra sự thuận tiện lớn về khả năng hiển thị tình huống của bạn. Giấy phép tự chế, tùy chỉnh có nghĩa là ước tính toàn bộ từ đầu, đây sẽ là một kịch bản rất tốn kém trong trường hợp bạn phải đi theo con đường đó.
3. Rất có khả năng bạn sẽ làm hỏng điều gì đó. Giấy phép nguồn mở được tạo ra bởi một lượng lớn quyền lực hợp pháp mà các tổ chức lớn sử dụng. Nó thường là một công việc nhóm và tốn rất nhiều thời gian và công sức mặc dù chúng có vẻ đơn giản. Về luật pháp, một từ hoặc thiếu nó có thể lật ngược thế cờ và có lẽ bạn không muốn trải qua tình huống căng thẳng như vậy

Vì những lý do này, chúng tôi thường không khuyên bạn nên điều chỉnh giấy phép nghiệp dư tự chế. Tuy nhiên, bạn không bao giờ biết được, dự án hoặc công ty khởi nghiệp của bạn thực sự có thể yêu cầu một cái gì đó tùy chỉnh hơn, trong trường hợp đó, làm việc với một số người có kinh nghiệm và chuyên gia luật có thể sẽ hợp lý nhất mặc dù ngay cả khi đó, trừ khi bạn thực sự phải làm, đó có lẽ là điều nên tránh

May mắn thay, có rất nhiều lựa chọn phục vụ cho các nhu cầu và triết lý khác nhau

Software Package Data Exchange® [SPDX®] cũng có một danh sách rất hay và phong phú về các giấy phép nguồn mở tại đây. Và bạn cũng có thể tìm thấy các giấy phép nguồn mở theo các danh mục khác nhau trong danh sách này

từ chối trách nhiệm. Xin hiểu rằng, kiến ​​thức và nhận xét chia sẻ trong bài viết này không phải là tư vấn pháp lý. Mặc dù chúng tôi hết sức cẩn thận về tính toàn vẹn và chính xác của thông tin được thu thập ở đây Holypython. com hoặc tác giả hoặc chủ sở hữu của nó không đảm bảo tính chính xác của thông tin này. Nếu bạn lo lắng về việc chọn giấy phép, chúng tôi khuyên bạn nên đọc giấy phép riêng lẻ và rút ra kết luận của riêng bạn trước khi đưa ra quyết định của mình. Hoặc, bạn cũng có thể xem xét tìm kiếm tư vấn pháp lý chuyên nghiệp. thánh trăn. com hoặc các tác giả hoặc chủ sở hữu của nó sẽ không chịu bất kỳ trách nhiệm nào đối với các quyết định đưa ra hoặc kết luận rút ra dựa trên bài báo này

Python có giấy phép không?

Python có phải là giấy phép GPL không?

Python vẫn miễn phí chứ?

Python có thuộc phạm vi công cộng không?