Khuyến nghị và kinh nghiệm về việc chọn giấy phép nào cho phần mềm?

Các nhà phát triển phần mềm có quyền lựa chọn một giấy phép phù hợp với mục tiêu của công việc.

Bất cứ ai cũng có thể đưa ra một số khuyến nghị / kinh nghiệm về việc chọn giấy phép nào cho phần mềm?

Những ưu / nhược điểm của việc "cho đi" tất cả các công việc được mã hóa dưới dạng mã nguồn mở là gì?

Làm thế nào để đối phó với những người chơi công nghiệp muốn hưởng lợi từ mã nghiên cứu?

Bất cứ ai cũng có thể đưa ra một số khuyến nghị / kinh nghiệm về việc chọn giấy phép nào cho phần mềm?

Mà cấp phép cho bạn chọn sẽ phụ thuộc vào cách miễn phí mà bạn muốn mã của bạn được, nhưng phương tiện miễn phí khác nhau đối với những người khác nhau.

• Đối với những người đề xuất giấy phép cho phép, phương tiện miễn phí cho phép mọi người bây giờ sử dụng phần mềm theo cách họ muốn ngay bây giờ , không phải lo lắng về việc phái sinh trong tương lai miễn phí như thế nào .
• Đối với những người đề xuất giấy phép copyleft , miễn phí có nghĩa là đảm bảo rằng phần mềm và mọi sản phẩm của nó được miễn phí , sẵn sàng hy sinh một số quyền tự do ngay lập tức để đảm bảo điều đó.

Giấy phép càng được cho phép, càng nhiều người sẽ có thể sử dụng nó, nhưng bạn càng có ít quyền kiểm soát đối với nó. Mặc dù càng hạn chế, bạn càng có nhiều khả năng khiến mọi người ngừng sử dụng phần mềm của bạn ngay từ đầu.

Có một số giấy phép nguồn mở và miễn phí ngoài kia, bao gồm GPL <= 2, GPL 3 , LGPL , BSD , Eclipse , v.v. Có những ưu điểm và nhược điểm đối với từng loại, vì vậy hãy đọc những hạn chế nào họ đặt trên mã và quyết định ai là người bạn muốn có thể sử dụng nó. Cảnh báo , bất cứ điều gì bạn chọn ai đó sẽ phàn nàn - đây là lãnh thổ chiến tranh thần thánh .

Nhìn chung, đây là một hành động cân bằng tinh tế và nó phụ thuộc rất nhiều vào đối tượng mục tiêu cho phần mềm của bạn.

• Một nguồn tuyệt vời để xác định giấy phép nào là giấy phép phù hợp với bạn là phân biệt giấy phép tương tác rất toàn diện , từ Đồng hồ OSS của Đại học Oxford .

Theo tôi, cả hai giấy phép cho phép và copyleft đều phù hợp với mã khoa học - điều quan trọng là mã này là nguồn mở ngay từ đầu. Tôi tin rằng Khoa học nên được mở, và mã cũng được sử dụng để hỗ trợ khoa học đó.

Những ưu / nhược điểm của việc "cho đi" tất cả các công việc được mã hóa dưới dạng mã nguồn mở là gì?

Ý tưởng cho đi phần mềm của bạn là nếu người khác thấy nó hữu ích thì họ sẽ sử dụng nó.

Nếu họ sử dụng nó, họ sẽ tìm thấy, báo cáo và thường sửa lỗi, tiết kiệm công sức của bạn để làm điều tương tự.

Nếu họ thích nó và phần mềm của bạn làm gần như những gì họ muốn, họ có thể cải thiện phần mềm của bạn và đóng góp những cải tiến đó lại.

Đó là rất nhiều ifs mặc dù.

Làm thế nào để đối phó với những người chơi công nghiệp muốn hưởng lợi từ mã nghiên cứu?

Thứ nhất, nếu bạn muốn cấm sử dụng mã thương mại, bạn có thể chọn giấy phép không có điều khoản sử dụng lại thương mại.

Thứ hai, nếu bạn nghĩ rằng ai đó có thể sử dụng phần mềm của bạn để cung cấp dịch vụ, mà không bao giờ thực sự phân phối mã cho bất kỳ ai khác, thì bạn có thể xem xét GPL của Affero có lỗ hổng copyleft cụ thể đó.

Thứ ba, bạn có thể làm như trên và cung cấp tùy chọn giấy phép kép. Cung cấp giấy phép GPL hoặc AGPL để tải xuống công khai và giấy phép thương mại có tính phí mang lại cho bạn cả hai thế giới tốt nhất và có nghĩa là bạn thậm chí có thể tạo ra một số doanh thu từ bán phần mềm thương mại có thể giúp hỗ trợ các hoạt động khoa học của bạn.

Lưu ý, nếu bạn định làm điều này, hãy cung cấp nó ngay từ đầu - điều đó có khả năng gây ra ít ma sát hơn từ những người đóng góp nguồn mở của bạn hơn là bắt đầu cung cấp giấy phép thương mại sau này. Nếu cộng đồng của bạn trở nên phổ biến, bạn không muốn mọi người buộc tội bạn bán hết hàng nếu bạn không nói thẳng về khả năng khai thác thương mại sau này. Tốt nhất là bạn nên thiết lập Thỏa thuận cấp phép cộng tác viên (CLA) phù hợp trước khi bạn bắt đầu chấp nhận đóng góp của bên thứ ba vào cơ sở mã của mình.

Câu trả lời cho câu hỏi này cũng cung cấp một số thông tin tốt về tùy chọn này.

PETSc sử dụng giấy phép này , đây là một hình thức BSD ít hạn chế hơn . Sự khác biệt quan trọng từ GPL, là phần mềm có thể được sử dụng thương mại. Nhiều người phản đối nguyên tắc đối với phần mềm đã đóng, tuy nhiên theo kinh nghiệm của tôi, sẽ không có doanh nghiệp nào đến gần mã của bạn nếu nó có giấy phép GPL. Hơn nữa, người dùng công nghiệp của PETSc rất có giá trị. Họ có xu hướng chạy các vấn đề khá phức tạp, điều mà hầu hết các học giả sẽ gặp khó khăn hơn là được bảo hành cho một ấn phẩm. Họ cũng đã đóng góp rất nhiều mã trở lại cho PETSc, để nó sẽ vào chuỗi hỗ trợ thông thường. Tôi sẽ khuyên bạn nên chống lại bất kỳ giấy phép nào mà không có tiềm năng sử dụng thương mại và trên thực tế ủng hộ giấy phép hạn chế ít nhất có thể (bạn chắc chắn có thể ghi PETSc vào đĩa CD và thử và bán nó cho cả tin).

Tôi sử dụng GPL, chủ yếu là do tình cảm đối với phong trào nguồn mở ban đầu (và do đó hy vọng rằng nó sẽ giúp nó lan rộng). Hơn nữa, đây là cách tốt nhất để bảo vệ thu nhập có thể của bạn khỏi các nhà tư bản vô đạo đức - với tư cách là một tác giả, bạn luôn có thể phân phối mã trên một giấy phép khác song song và do đó duy trì phiên bản độc quyền cho việc sử dụng kinh doanh nhãn trắng.
Tuy nhiên, đây cũng có thể là một khuyết điểm - nguồn tài trợ của bạn có thể từ chối trách nhiệm rằng tất cả công việc của bạn sẽ trở thành phạm vi công cộng, vượt quá giấy phép này.

Dù sao, điều quan trọng nhất trong chủ đề đó là bất kỳ giấy phép nào tốt hơn không có, điều không may là khá thường xuyên trong thế giới phát triển khoa học - và tôi chỉ ghét tất cả những / / Bị đánh cắp từ chương trình của John Smith mà anh ấy chưa bao giờ công khai * / hoặc CI nghĩ rằng tôi đã thấy điều này trong bài đăng của Jane Smith trên một số nhóm vào năm 1995 ... hoặc có thể là năm 1993?

Đầu tiên, những ưu / nhược điểm của việc mở nguồn:

Pro: nhiều người sẽ sử dụng mã của bạn, cung cấp phản hồi, chỉnh sửa, cải tiến, v.v ... Bạn sẽ có mã tốt hơn và nhiều người tin tưởng nó hơn.

Con: nếu bạn từng muốn đặt cơ sở kinh doanh theo mã của mình, bạn có ít tùy chọn hơn (nhưng vẫn còn một vài, chẳng hạn như bán dịch vụ tư vấn)

Đối với việc chọn giấy phép, tôi sẽ tiến hành theo thứ tự sau:

1. Có sử dụng lao động / cơ quan cấp của bạn áp đặt bất cứ điều gì? Sau đó, bạn không có lựa chọn. Kiểm tra điều này cho tất cả những người đóng góp cho mã.
2. Bạn có sử dụng lại mã có một số giấy phép cụ thể giới hạn sự lựa chọn của bạn không? Sau đó, sự lựa chọn của bạn cũng bị hạn chế. Trong thực tế, việc tích hợp các đoạn mã được cấp phép GPL là nguồn thường xuyên nhất của những hạn chế đó.
3. Quyết định những gì bạn đánh giá cao hơn: triết lý tất cả các mã nên được mở sau GPL và các giấy phép tương tự, hoặc triết lý khuyến khích sử dụng rộng rãi nhất có thể đằng sau giấy phép BSD.
4. Trong mỗi hai gia đình giấy phép Nguồn mở lớn, hãy chọn theo những gì phổ biến nhất / được chấp nhận trong cộng đồng của bạn.

Hầu hết các nghiên cứu của tôi được tài trợ bởi các quỹ công cộng, và vì vậy tôi cảm thấy có nghĩa vụ sử dụng giấy phép hạn chế ít nhất có thể. Nếu những người khác ở đất nước tôi đang giúp trả tiền cho nghiên cứu này, tôi có thực sự có quyền nói với họ rằng họ không thể tích hợp mã của tôi vào một nguồn đóng và / hoặc phân phối phần mềm thương mại không? Tôi hy vọng rằng hầu hết những người sử dụng mã của tôi sẽ là các nhà khoa học hàn lâm, nhưng tôi không có vấn đề triết học nào với các doanh nghiệp cải thiện phần mềm của tôi bằng cách tích hợp nó với phần mềm (có thể thương mại) khác, đặt GUI trên đó, v.v., để cung cấp sản phẩm Điều đó giúp họ kiếm được lợi nhuận.

Điều đó đang được nói, tôi cố gắng sử dụng giấy phép yêu cầu ghi công thích hợp. Ví dụ, nếu một công ty không gấp mã của tôi thành một sản phẩm thương mại lớn hơn, tôi muốn họ làm cho nó rõ ràng rằng mã của tôi có thể đạt được tự do khỏi tôi. Nhưng khác với điều đó, tôi muốn đặt càng ít yêu cầu đối với người dùng mã của mình càng tốt.

Đối với việc phát triển phần mềm không được tài trợ bởi tiền thuế của người nộp thuế, tôi hiểu rằng các giấy phép khác có thể phù hợp hơn.

Không ai đánh vần điều này rất rõ ràng, vì vậy tôi nghĩ rằng nó đáng để nói:

Một số giấy phép nguồn mở (đáng chú ý: GPL) là "virus" theo nghĩa là bất cứ khi nào mã được sử dụng trong một dự án mới, dự án mới phải được cấp phép theo cùng một cách. Ngoài ra, mã không thể được liên kết đến (theo một số cách nhất định) mã được cấp phép khác nhau.

Một hậu quả thực tế là:

• Nếu bạn triển khai một phương thức số mới trong C, giấy phép sẽ không cho phép gọi nó từ phần mềm phổ biến như MATLAB hoặc Mathicala

• Nếu bạn triển khai thuật toán xử lý ảnh mới, giấy phép sẽ không cho phép tạo plugin Photoshop từ nó

• và v.v.

Điều này sẽ không chỉ ngăn chặn việc sử dụng lại thương mại mà còn sử dụng lại một cách thuận tiện bởi các học giả khác (nếu họ sử dụng phần mềm đóng) và nếu ai đó xây dựng trên mã của bạn, điều đó sẽ ngăn họ từ bỏ công việc của họ -cái gì-bạn-sẽ-với-nó ".

Đây là điều bạn phải xem xét trước khi hoàn thành việc cấp giấy phép.

Tôi đặt nó theo cách này bởi vì tôi đã gặp những người (không quen thuộc với giấy phép nguồn mở), những người không nhận thức được điều này hoặc chưa xem xét nó từ góc độ này.

^{(Đây chỉ là ý kiến ​​cá nhân, nhưng tôi tin rằng việc áp dụng các hạn chế như vậy đối với công việc xuất phát từ học viện (được tài trợ công khai) là không phù hợp. Vì vậy, tôi hoặc giữ mã, hoặc tôi cho đi.)}

Bất kể bạn chọn loại giấy phép nào, hãy nhớ kiểm tra cẩn thận tất cả các thỏa thuận tài trợ của bạn để đảm bảo rằng không có điều khoản nào trong đó quy định hoặc hạn chế cách bạn có thể cấp phép cho phần mềm của mình.

Tôi biết trong trường hợp của mình, nhiều dự án của tôi được xây dựng từ nhiều lớp tài trợ, một chút ở đây và một chút ở đó, và theo dõi làm thế nào tôi được phép cấp phép cho công cụ của mình bởi những người luôn bật đèn và Các máy móc chạy khá phức tạp.

Đối với các mã lớn, tôi sử dụng một trong các giấy phép được mô tả trong các câu trả lời khác và thường là LGPL. Tuy nhiên, mặc dù thường không được khuyến nghị cho phần mềm , nhưng đối với các tập lệnh nhỏ mà tôi có thể gửi cho đồng nghiệp trong ngành, tôi thường chọn giấy phép Creative Commons . Điều này là do họ có xu hướng rõ ràng hơn đối với cá nhân mà tôi gửi mã đến, điều này ngăn chặn mọi vấn đề tiềm ẩn về sự hiểu lầm. Điều này đã làm việc tốt cho tôi trong quá khứ.

Không giống như hầu hết những người trả lời ở đây (những người đang làm việc trong các tổ chức học thuật và / hoặc công cộng), tôi đang làm việc trong lĩnh vực thương mại.

Đối với các sản phẩm của tôi, mã được đóng lại và tiếp tục có những lợi thế kinh doanh lớn để làm điều này. Nhưng tất nhiên có nhiều cách khác để làm điều đó (ví dụ như được trình bày bởi MySQL trong số những cách khác). Tôi thường thấy cách tiếp cận giấy phép thương mại LGPL + cho các thư viện. Tôi vẫn chưa sử dụng một thư viện như vậy trong một hệ thống thương mại, nhưng tôi sẽ không loại trừ nó (cho đến nay tôi chỉ sử dụng các thư viện như vậy, ví dụ ALGLIB, ở cấp độ R & D). Điều này trái ngược với một sản phẩm GPL - mà tôi có thể sử dụng nội bộ nhưng sẽ không bao giờ sử dụng trong một sản phẩm, chủ yếu là do bản chất của virus.

Khi tôi phát hành mã nguồn (mẫu hướng dẫn, chương trình miễn phí, v.v.), tôi thường sử dụng giấy phép Berkeley. Điều này dường như nhiều hơn theo tinh thần của mã "miễn phí", với sự quy kết nhưng không có chuỗi GPL và chính trị. Có lẽ đây là lý do tại sao nó (hoặc các giấy phép tương tự như giấy phép MIT) rất phổ biến với các trường đại học và các tổ chức công cộng. Mã nguồn được cho đi theo nghĩa thực sự của 'miễn phí' (đây là một số mã, làm những gì bạn muốn với nó) nhưng tác giả vẫn nhận được tín dụng / ghi công.

Đây là một câu hỏi cũ, nhưng tôi nghĩ Giấy phép Công cộng Mozilla đáng được đề cập như một nền tảng trung gian giữa giấy phép cho phép (BSD, MIT) và giấy phép copyleft mạnh (GPL). Mã MPL có thể được sử dụng và phân phối lại, nhưng mã MPL và mọi sửa đổi đối với nó phải được cung cấp. Ví dụ, một công ty có thể lấy một số mã MPL, tự cải tiến nó và phân phối nó trong gói phần mềm nguồn đóng độc quyền, miễn là họ cung cấp phiên bản sửa đổi của mã MPL gốc. Họ không bắt buộc phải phát hành tất cả mã nguồn của riêng họ, như với GPL.

Với giấy phép BSD, có một nỗi sợ rằng một công ty có thể lấy mã của bạn và cải thiện nó mà không trả lại những đóng góp này cho bạn hoặc cộng đồng, theo lý do rằng những cải tiến mà họ tạo ra mang lại lợi thế cạnh tranh. (Câu trả lời của Matt Knepley cho thấy rằng không phải mọi hành động đều theo cách này). Mặt khác, nhiều người có thể tránh hoàn toàn mã GPL. MPL tránh được cả hai cạm bẫy tiềm năng này, ít nhất là về nguyên tắc.