Lý do KHÔNG mở mã phi lợi nhuận? [đóng cửa]

Tôi là một fan hâm mộ lớn của mã nguồn mở. Tôi nghĩ rằng tôi hiểu hầu hết các lợi thế của việc mở nguồn. Tôi là một nhà nghiên cứu sinh viên khoa học và tôi phải làm việc với một số lượng phần mềm và mã khá đáng ngạc nhiên không phải là nguồn mở (có thể là độc quyền hoặc không công khai). Tôi thực sự không thể thấy một lý do chính đáng cho điều này và tôi có thể thấy rằng mã và những người sử dụng nó chắc chắn sẽ được hưởng lợi từ việc công khai hơn (nếu không có gì khác, trong khoa học, điều quan trọng là kết quả của bạn có thể được sao chép nếu cần, và điều đó khó hơn nhiều nếu những người khác không có quyền truy cập vào mã của bạn).

Trước khi tôi ra ngoài và bắt đầu thịnh vượng, tôi muốn biết: có bất kỳ lý lẽ tốt nào để không phát hành mã phi lợi nhuận công khai và với giấy phép tuân thủ OSI không?

(Tôi nhận thấy có một vài câu hỏi tương tự xung quanh, nhưng hầu hết tập trung vào các tình huống mà mã chủ yếu được sử dụng để kiếm tiền và tôi không thể liên quan nhiều đến câu trả lời.)

Làm rõ: Bằng cách "phi lợi nhuận", tôi bao gồm các động cơ lợi nhuận hạ nguồn, chẳng hạn như nhận biết thương hiệu của công ty mẹ và kỳ vọng lợi nhuận của nhà đầu tư. Nói cách khác, câu hỏi chỉ liên quan đến phần mềm mà KHÔNG có động cơ lợi nhuận gắn liền với phần mềm từ trước đến nay.

Bạn cần tính đến việc tìm nguồn mở mã của bạn có thể cần thêm nỗ lực.

Ví dụ, trong bài viết trên blog này, kỹ sư của Sun / Oracle đã mô tả những nỗ lực họ phải bỏ ra khi tìm nguồn cung ứng mã nguồn mở : Nguồn mở hay Giặt bẩn?

Khi chúng ta sẵn sàng lao vào thế giới nguồn mở, một trong nhiều hoạt động đang diễn ra là chuẩn bị mã để được mở nguồn. Có một số điều rõ ràng cần phải được thực hiện. Chẳng hạn, mã nguồn của chúng tôi bao gồm một hỗn hợp mã mà chúng tôi đã viết và mã mà chúng tôi đã cấp phép từ những người khác. Chúng ta sẽ cần tách riêng phần sau và chỉ nguồn mở cho các đoạn mã thích hợp.

Một hoạt động chuẩn bị khác là "lọc" mã thông tin độc quyền, đề cập đến các khách hàng cụ thể, nhà phát triển, công nghệ, v.v ... Điều này ít rõ ràng hơn, nhưng hãy xem xét ví dụ sau:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

Mặc dù tất cả những điều trên có thể là sự thật, nhưng có lẽ chúng tôi có mối quan hệ nào đó với Intertrode Tech và việc có những nhận xét như thế này trong mã có thể gây tổn hại cho doanh nghiệp của chúng tôi và vì vậy cần xóa bỏ. Có thể cho rằng nó không nên ở đó ngay từ đầu, nhưng giờ là lúc để đưa nó ra ngoài.

Một phần khác của hoạt động "chà" là loại bỏ những lời tục tĩu và những từ "không mong muốn" khác ...

Lưu ý tất cả các thay đổi ở trên phải được thực hiện đối với mã đã được coi là hoàn toàn OK dưới dạng nguồn đóng - điều đó làm cho nó hoàn toàn nỗ lực hơn để nói.

Bảo vệ.

Ví dụ: giả sử bạn xây dựng một khung web và chính bạn sử dụng nó.

Là một dự án phi lợi nhuận, bạn đã không có thời gian dành cho việc kiểm tra từng bit mã để tìm lỗ hổng cho cuộc tấn công này hay cuộc tấn công khác:

• CSRF
• XSS
• Tiêm SQL
• Phiên cố định
• Sử dụng các thư viện bên thứ ba có lỗi hoặc thậm chí các ngôn ngữ

Bây giờ, khi đã mở nguồn dự án, bạn cho phép đôi mắt thân thiện đóng góp, nhưng bạn cũng cho phép đôi mắt độc hại hiểu biết sâu sắc về công việc của bạn và, nếu họ tìm thấy một máy chủ đang chạy mã của bạn, bạn đã loại bỏ khả năng che giấu sự không hoàn hảo trong tối nghĩa.

Tất nhiên, điều này có thể không áp dụng cho loại phần mềm bạn đang làm việc; và như mọi khi tối nghĩa không phải là lý do cho sự lười biếng trong bảo mật.

Tuy nhiên, giống như tôi đã tìm thấy trong một vài cấp độ mà tôi đã vượt qua trong trò chơi cờ bắt cờ , biết mã là một trong những cách dễ nhất để tìm lỗ hổng (và đôi khi nó có thể là cách duy nhất).

Một lý do chính đáng để không mở nguồn là một số nguồn của bạn có thể có bản quyền. Tần suất bạn không tìm kiếm trên web để tìm giải pháp nhanh chóng cho một vấn đề và chỉ cần lấy đoạn mã bạn tìm thấy?

Chà, những thứ đó có thể có bản quyền và tôi không biết liệu tác giả có muốn tìm mã của mình được cấp lại theo một giấy phép khác hay không.

Bạn cần cẩn thận với cách bạn chọn giấy phép để tránh các vấn đề trách nhiệm pháp lý tiềm ẩn.

Một luật sư có thể là một người tốt hơn để nói về vấn đề này, nhưng ý tưởng chung là điều gì xảy ra nếu ai đó sử dụng (hoặc lạm dụng) ứng dụng và nó gây ra một số tác hại? Bạn có trách nhiệm không Rõ ràng điều này sẽ phụ thuộc vào loại phần mềm bạn đang viết, nhưng bạn luôn cần cẩn thận với những gì giấy phép của bạn nói về trách nhiệm pháp lý của bạn. Đây có thể là một điều khó khăn để có được đúng, vì vậy có thể dễ dàng hơn khi không phát hành mã nguồn.

Cảnh báo: Tôi không phải là luật sư .

Chà, nếu đó là một tổ chức phi lợi nhuận và tài sản trí tuệ của nó bị ràng buộc chặt chẽ với mã của phần mềm, thì một số người có thể muốn bảo vệ nó khỏi bị tái sử dụng thương mại hoặc thậm chí bị khai thác một cách lạm dụng để tạo ra các bản sao của phần mềm.

Một số lý do khác - thực sự có nguồn gốc sâu xa trong lý do thứ nhất, thực tế - là trong trường hợp của bạn, rất nhiều nghiên cứu cao cấp xảy ra với nguồn vốn tư nhân, và thường các nhà đầu tư muốn xem ROI. Và cho đến nay, không có tất cả các tác nhân của ngành công nghiệp phần mềm (hoặc người mới tham gia) đã bị thuyết phục hoàn toàn về khả năng tồn tại của mô hình nguồn mở (rất có thể là do thiếu kiến ​​thức và hiểu biết về cấp phép, hoặc bởi sợ đơn giản rằng việc cấp phép sẽ không ngăn chặn được độc hại sử dụng và bản sao).

Ngoài ra, các công ty này không muốn bị kiện bởi những người cố gắng kiếm lợi nhuận trên lưng và việc cấp phép được coi là một biện pháp bảo vệ trong vấn đề này, với lý do chính đáng hay không.

Nó có thể không xuất hiện như vậy, nhưng có thể các tổ chức phi lợi nhuận đang sinh lãi cho người sáng lập hoặc nhà đầu tư của họ. Những lợi ích không phải là trực tiếp. Vì vậy, họ rất quan tâm đến việc NFP sẽ phát triển mạnh mẽ và không bị các đối thủ cạnh tranh đánh bại (mặc dù bạn cũng thường không nghĩ đến "đối thủ cạnh tranh" trong thị trường phi lợi nhuận) và họ muốn bảo vệ họ IP, ngay cả khi phải trả giá bằng việc không nhận được nhiều bóng mắt miễn phí hơn để xem lại mã của họ để tìm ra vấn đề và cải thiện sớm.

Cũng lưu ý rằng luật bản quyền khác nhau giữa các quốc gia. Ví dụ, nhiều quốc gia châu Âu coi luật bản quyền của Hoa Kỳ và hệ thống bằng sáng chế của Hoa Kỳ khá là ngu ngốc, vì vậy, có một nền tảng văn hóa và sức nặng khó có thể rũ bỏ.

Jut 2 xu của tôi về chủ đề này.

(Tôi đã làm việc với các trường đại học rất nhiều, và gần đây về tin sinh học và chăm sóc sức khỏe ... Đó là một câu hỏi thường xuyên đối với tôi và các đồng nghiệp của tôi :))

Có ít nhất hai loại nguồn mở khác nhau.

Nếu thái độ của bạn là "đây là một cái gì đó hữu ích, tôi đã hoàn thành nó" (và điều đó hóa ra là chính xác) thì có rất ít nhược điểm.

Mặt khác, nếu thái độ của bạn là "Tôi thực sự phấn khích và tôi muốn một số người dùng thực sự giúp thúc đẩy sự phát triển trong tương lai" thì hãy suy nghĩ thật kỹ. Bạn sẽ phải dành thời gian hỗ trợ người dùng, nhiều người trong số họ không biết gì. Bạn sẽ phải xem xét các yêu cầu xung đột về các tính năng và cải tiến. Bạn sẽ thấy ngày càng khó thực hiện các thay đổi, để duy trì khả năng tương thích ngược.