Có vấn đề gì với bạn không, một phần mềm là nguồn có sẵn của Google nhưng không phải là mã nguồn mở


11

Bạn có thể biết danh sách các giấy phép nguồn mở được OSI chính thức phê duyệt. Đáng chú ý nhất tôi đoán sẽ là GPL, MIT, [chèn giấy phép yêu thích của bạn vào đây].

Gần đây tôi đã chạy vào một dự án mặc dù là nguồn mở (người tạo đã cung cấp tất cả mã nguồn có sẵn), không phải là nguồn mở chính thức theo một trong những giấy phép chính thức đó.

  • Nó đã phát hành nguồn, nhưng không hứa hẹn sẽ phát hành nguồn trong tương lai.

  • Nó cho phép đề xuất sửa đổi, nhưng không hứa hẹn sẽ chấp nhận các bản vá và không cho phép phân phối bên ngoài các phiên bản được vá bên ngoài.

  • Nó cho phép sử dụng phần mềm trong các dự án thương mại hoặc trả phí, nhưng không cho phép bán phần mềm này.

Tôi cho rằng nó có thể được gọi là "nguồn có sẵn" chứ không phải nguồn mở như chúng ta muốn nghĩ về nó.

Tôi có thể thấy lý do tại sao đội ngũ quản lý của một công ty sẽ không muốn kinh doanh với phần mềm này. Họ không thể chia rẽ nó, họ không thể bán nó, họ không thể tạo phiên bản phần mềm của riêng họ và phân phối hoặc bán nó.

Nhưng nó có quan trọng với bạn như là một phần của nhóm kỹ thuật phần mềm chỉ sử dụng phần mềm này không? Tôi vẫn có thể hoàn thành công việc của mình với nó, tôi có thể sử dụng nó trong một dự án mà tôi đã trả tiền (nhưng tôi không thể bán phần mềm mà tôi không kinh doanh bằng cách nào) và tôi có thể thay đổi mã để làm cho nó hoạt động khác với nhu cầu của tôi (nhưng tôi không thể công khai những sửa đổi đó) và nếu tôi muốn những sửa đổi đó chính thức được cung cấp cho người khác, thì sự chấp thuận tùy thuộc vào dự án và họ chọn để kết hợp chúng trong một bản phát hành chính thức hay không.

Vì vậy, chúng tôi biết rằng một công ty muốn kinh doanh dựa trên phần mềm "nguồn sẵn có" này không thể làm điều đó, nhưng với tư cách là một người trong nhóm kỹ thuật phần mềm, những sự khác biệt đó có quan trọng với bạn hay chúng có vẻ ít liên quan hơn?

Tò mò những gì người khác nghĩ về điều này.


1
Tôi nghĩ một phần quan điểm của OSS là bạn không dựa vào người khác để chấp nhận và phân phối một bản vá, bạn có nguồn để bạn có thể tự mình làm tất cả mọi việc (bao gồm cả việc đặt toàn bộ thành một chi nhánh / sản phẩm cạnh tranh nếu bạn muốn)?
Jon Hopkins


Có vẻ như các điều khoản cấp phép khá rõ ràng đối với phần mềm này. Nghe có vẻ người ta nên viết mã của riêng họ thay vì sử dụng mã được cấp phép theo cách không cho phép họ thực sự sử dụng mã theo cách họ cần sử dụng.
Ramhound

Câu trả lời:


5

Đối với các dự án sẽ phải phát triển từ đầu chức năng được cung cấp bởi phần mềm này, đó là một sự thuận tiện nhất định không làm như vậy.

Nhưng liệu một gói nguồn mở tương đương sẽ tốt hơn hay không phụ thuộc vào các yếu tố khác:

  • nó sẽ được sử dụng để cung cấp một số dịch vụ hay gói nó như một phần của sản phẩm khác?
  • họ có các nguồn lực để tăng cường và duy trì sản phẩm một cách độc lập không?
  • Có lợi thế cạnh tranh nào để sử dụng phần mềm này so với phiên bản nguồn mở (trong mã hoặc quản lý dự án) không?

Trả lời không cho bất kỳ yếu tố nào trong số này cho thấy OSS là lựa chọn tốt hơn.

Hầu hết thời gian, bản thân mã không phải là yếu tố quyết định. Người ta cần xem xét bức tranh lớn hơn.

Các dự án OSS của SIDEebar không thể hứa hẹn một cách hợp pháp rằng họ sẽ giữ các phiên bản trong tương lai mở hoặc sẽ có các phiên bản trong tương lai. Đó là một lý do tại sao có một giấy phép mở là rất thuận lợi. Ngoài ra, các dự án OSS không bắt buộc phải chấp nhận các bản vá từ những người đóng góp (đặc biệt là không chuyển quyền sở hữu hoặc quyền).


2

Câu hỏi cho điều này và bất kỳ thư viện bên ngoài khác là bảo trì .

Tuổi thọ của ứng dụng của bạn là gì và tuổi thọ rõ ràng của thư viện này là gì? Bạn nên hy vọng là ngắn nhất.

Ai sẽ sửa lỗi cho thư viện này? Vì có vẻ từ đây, công ty của bạn nên phân bổ rõ ràng các nguồn lực trong tương lai để duy trì phần mềm này, vì bạn không thể dựa vào bất kỳ lỗi sửa lỗi nào khác cho bạn. Bạn không thể chia sẻ gánh nặng bảo trì với bất kỳ ai khác vì bạn không thể chia sẻ nguồn. Bạn muốn tìm ra một lỗi điều kiện chủng tộc khó nắm bắt trong mã mà bạn không biết?

Chỉ riêng suy nghĩ này có thể khiến thư viện quá đắt để sử dụng.

Điều này có thể không liên quan nếu thư viện rất chắc chắn và mạnh mẽ và dễ làm việc ở mức nguồn, nhưng kinh nghiệm của tôi là áp lực ngang hàng của các dự án nguồn mở thực sự chỉ đơn giản là làm cho mã tốt hơn bởi vì bạn có xu hướng làm tốt nhất sau đó.

Cá nhân tôi sẽ suy nghĩ rất cẩn thận về việc tôi sẽ áp dụng mã này hay bất kỳ mã bên ngoài nào khác, vì toàn bộ lý do sử dụng mã người khác là bạn không phải tự mình giải quyết . Cũng nghĩ về những người duy trì trong tương lai - bạn nên thực hiện các cuộc tập trận thay đổi mã trong thư viện để xem liệu nó có thể được thực hiện hay không. Có thể có một số bất ngờ RẤT khó chịu ở đây.

Bạn có tự do để thảo luận về thư viện trong câu hỏi?


2

Thành thật mà nói, tôi không hiểu tại sao đội ngũ quản lý của một công ty sẽ gặp vấn đề với việc sử dụng thư viện "nguồn sẵn có" như vậy. Liên quan đến việc tích hợp vào sản phẩm của họ, họ chỉ có thể coi đó là một thư viện nguồn đóng.

Đối với tôi, là một lập trình viên, không có vấn đề gì nếu thư viện là "nguồn mở" hoặc "nguồn có sẵn". Tôi không muốn sửa đổi cục bộ cho một thư viện bên ngoài, vì điều đó có nghĩa là một gánh nặng bảo trì bổ sung. Không chỉ khi các lỗi được tìm thấy trong các sửa đổi cục bộ của tôi, mà còn về việc tích hợp các sửa đổi lặp đi lặp lại khi một bản phát hành mới của thư viện xuất hiện.

Các tình huống duy nhất trong đó, IMHO, "nguồn mở" đánh bại giấy phép "nguồn có sẵn" được nêu trong câu hỏi là khi nào

  • giấy phép sản phẩm của chúng tôi cũng yêu cầu tiết lộ các nguồn của các thư viện chứa
  • chúng tôi đang trong quá trình sản xuất một phiên bản nâng cao / mở rộng của thư viện

1

Đây là lý do tại sao Tổ chức phần mềm miễn phí sử dụng thuật ngữ 'miễn phí' hoặc 'không miễn phí' để mô tả phần mềm. Họ không đề cập đến giá cả, nhưng những hạn chế được đặt vào việc sử dụng hoặc phân phối phần mềm.

Có vẻ như bạn đã gặp phải một trong những trường hợp góc hiếm gặp khi bạn có quyền truy cập đầy đủ vào mã nguồn của một thứ gì đó, nhưng phần mềm không phải là "Nguồn mở" theo định nghĩa OSI .

Hoặc là thuật ngữ có khả năng trở thành một từ sai. Tôi đã trả 50 đô la cho bản sao đầu tiên của emacs (trên băng QIC), nhưng emacs là phần mềm miễn phí . Tôi có mã nguồn cho một số ứng dụng độc quyền mà công ty tôi sử dụng nội bộ, nhưng chúng không phải là nguồn mở.

Điều làm tăng cờ đỏ lớn nhất (ít nhất là với tôi) là không đảm bảo quyền truy cập vào mã nguồn của các phiên bản trong tương lai. Nếu bạn phụ thuộc nhiều vào việc có thể sửa đổi công cụ này, tôi sẽ cẩn thận. Ngay cả khi bạn có thỏa thuận bằng lời với nhà cung cấp rằng bạn sẽ luôn có mã, trừ khi nó ở dạng hợp đồng .. thỏa thuận đó không bao giờ xảy ra.

Là CTO, tôi cố gắng hết sức để đảm bảo rằng chúng tôi không phụ thuộc vào phần mềm không miễn phí. Tôi đã từng gặp phải tình trạng khóa nhà cung cấp nhiều lần trong quá khứ, một sai lầm mà tôi muốn tránh. Mặc dù chúng tôi sử dụng một số công cụ độc quyền, doanh nghiệp của chúng tôi sẽ không gặp khó khăn quá mức nếu đột nhiên chúng tôi không thể sử dụng nó nữa.

Tôi nghe có vẻ như bạn đang xây dựng mọi thứ xung quanh việc có phần mềm này và truy cập vào mã, vì vậy tôi khuyên bạn nên lấy một cái gì đó bằng văn bản nói rằng bạn sẽ luôn có quyền truy cập. Điều gì xảy ra nếu nhà cung cấp được mua?


-1

Điều này không quan trọng một chút. Các vấn đề chính với cách tiếp cận "nguồn có sẵn" mà bạn đã mô tả:

  • Bạn không kiểm soát vận mệnh công nghệ của mình nếu bạn không có quyền tự do sửa đổi nguồn. Thường thì hack nguồn trực tiếp có thể thích hợp hơn cho một cách giải quyết lộn xộn.
  • Bạn không có gì đảm bảo rằng phần mềm sẽ tiếp tục được duy trì và bạn không có tùy chọn dự phòng để tự mình làm điều đó với nguồn mở thực sự.
  • Vì nó có vẻ giống như một giấy phép tùy chỉnh, bạn có thể có rủi ro pháp lý lớn hơn so với việc sử dụng một cái gì đó nổi tiếng và được chứng minh như giấy phép GPL hoặc BSD.
  • Nếu nó không phải là nguồn mở thực sự, bạn sẽ không có cùng một cộng đồng hữu ích xung quanh nó, đó là một lợi thế lớn cho nhiều dự án nguồn mở

Đề nghị của tôi: cố gắng thuyết phục người tạo phát hành phần mềm theo giấy phép nguồn mở. Đó phải là một chiến thắng / thắng cho tất cả mọi người - bạn bởi vì bạn có được phần mềm bạn muốn theo giấy phép nguồn mở, người tạo vì làm cho dự án nguồn mở có khả năng làm cho phần mềm thành công hơn về lâu dài.


Cái quái gì là "nguồn mở thực sự" mà giấy phép mô tả với tôi nghe có vẻ thật với tôi.
Ramhound
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.