Khách hàng muốn mã nguồn, nhưng nó chứa rất nhiều mã được chia sẻ mà tôi sử dụng lại với các dự án khác

Tôi có một khách hàng muốn tôi cung cấp mã nguồn với tệp nhị phân ứng dụng được phát triển. Ban đầu họ không nói gì về mã nguồn, nhưng gần đây họ nói họ cần nó. Hợp đồng không được hoàn thành. Họ đồng ý với công việc, không ký, và sau đó trở lại với điều khoản này.

Vấn đề là: Tôi có một cơ sở mã tôi đã tạo ra trong nhiều năm và được sử dụng làm mẫu cho hầu hết các ứng dụng tôi viết. Nó lớn hơn nhiều so với phạm vi của dự án.

Tôi cũng có ý định sử dụng nó cho một sản phẩm, vì vậy tôi thực sự không muốn cung cấp nó cho một dự án tương đối nhỏ.

Tôi đoán đây không phải là lần đầu tiên điều này xảy ra trong ngành này. Cách tốt nhất để phá vỡ vấn đề này là gì? Tôi đoán những thứ như thư viện chia sẻ có thể giúp đỡ.

Điều đầu tiên cần ghi nhớ là mã nguồn có giá trị tách biệt với các nhị phân. Hoàn toàn hợp lý khi từ chối ký hợp đồng yêu cầu phân phối mã nguồn hoặc yêu cầu thanh toán thêm cho việc phân phối mã nguồn. Hợp đồng là tài liệu hai chiều. Đừng để phần khác ra lệnh những gì được yêu cầu chỉ vì họ là "công ty lớn" và "làm điều này mọi lúc". Đầu tiên, quyết định những gì bạn sẵn sàng cung cấp và cách bạn muốn được bồi thường. Sau đó đưa hợp đồng của họ cho một luật sư và tìm ra những gì cần thay đổi. Sau đó, bạn thương lượng.

Đừng làm những gì nhiều người trẻ làm khi họ bắt đầu ký hợp đồng. Đừng chỉ ký vì có vẻ như họ có nhiều kinh nghiệm và bạn thì không. Đó là một cách tốt để bị gạt ra.

Nhìn vào lý do tại sao họ muốn nguồn. Họ có thể muốn nó để họ có tùy chọn sử dụng nhà phát triển khác sau này. Hoặc họ có thể muốn điều đó chỉ vì họ sợ bạn có thể bị xe buýt đâm và đột nhiên họ sẽ bị bỏ lại với những nhị phân mà họ không thể cải thiện. Nếu đây là trường hợp thứ hai, hãy xem xét Dịch vụ ký quỹ mã phần mềm . Các dịch vụ này giữ mã nguồn trong trường hợp bạn phá sản hoặc không thể bảo trì phần mềm. Điều này có thể đáp ứng cả mong muốn của bạn là giữ mã độc quyền của mình để phục vụ các khách hàng khác và mong muốn của họ không bị giữ túi với một bộ nhị phân không thể nhầm lẫn nếu có điều gì xấu xảy ra.

"Không" là một câu trả lời hoàn toàn tốt, thực sự đó là một câu trả lời cực kỳ hữu ích mà vì một số lý do tôi không thể hiểu được đánh giá rất thấp.

"Xin chào, chúng tôi đã quyết định một cách tuyệt vời, chúng tôi chỉ muốn mã nguồn miễn phí."
"Xin chào, không."

Điều đó thực sự không khó.

Sau đó, nếu họ có nhu cầu nộp tiền trắng trợn tiền hơn những gì họ đã nợ bạn, bạn có thể cung cấp cho họ một phiên bản tỉa của ứng dụng của bạn, mà chỉ bao gồm các nguồn mà họ thực sự cần, và chăm sóc họ nhận được hoàn toàn phi quyền -exclusive.

Đừng phức tạp hóa những điều đơn giản.

Câu hỏi của bạn là "cách tốt nhất để phá vỡ vấn đề này là gì?" Nhưng bạn thấy vấn đề là gì? Những người khác đã chỉ ra một cách chính xác rằng đó là vấn đề thương lượng: mọi thứ đều có giá trị, và bạn phải trả cho khách hàng một mức giá để cung cấp những gì được yêu cầu.

Nhưng bạn cũng phải xem xét cẩn thận về cách sử dụng và viết vào hợp đồng. Ý nghĩa của việc cung cấp mã. Có phải chỉ để khách hàng có thể nhìn thấy nó? Khách hàng có thể sửa đổi nó? Và đặc biệt, bạn có xem xét trao quyền độc quyền cho khách hàng của mình cho cơ sở mã mà bạn đã tạo trong nhiều năm qua và được sử dụng làm mẫu cho hầu hết các ứng dụng để bạn không bao giờ có thể tự sử dụng lại trong tương lai không?

Bạn cần đảm bảo hợp đồng nêu rõ ai có quyền sử dụng mã, và bằng những cách nào.

Hãy nhớ rằng bất kỳ mã nguồn nào cũng cần có giấy phép. Nếu bạn bàn giao mã nguồn, công ty có thể sử dụng mã nguồn để làm bất cứ điều gì mà giấy phép cho phép và bất cứ điều gì ngoài đó là vi phạm bản quyền. Vì vậy, nếu bạn bàn giao mã nguồn, bạn sẽ có một hợp đồng hoàn toàn rõ ràng rằng bạn giữ bản quyền độc quyền của mã nguồn và chính xác những gì sử dụng mã nguồn được cho phép. Và tất nhiên mã nguồn + giấy phép sẽ không miễn phí.

Một công ty lớn sẽ khó có thể vi phạm bản quyền của bạn, bởi vì bị bắt sẽ gây thiệt hại lớn cho danh tiếng của họ, ngoài thiệt hại tài chính. Mặt khác, việc thanh toán cho phần mềm không đảm bảo rằng mọi sự cố có thể được khắc phục trong tương lai, có thể không được chấp nhận đối với khách hàng.

Trước đó tôi thường cung cấp mã nguồn (thư viện và tất cả) theo giấy phép MIT cho khách hàng. Nếu thư viện của bạn được tổ chức tốt, bạn chỉ cung cấp các tệp / tài nguyên cần thiết cho khách hàng cụ thể đó chứ không có gì khác. Tôi nghĩ đó là công bằng cho cả tôi và khách hàng. Tuy nhiên, luôn có vấn đề về mã mới được viết cho khách hàng cụ thể đó theo hợp đồng không phải là một phần của thư viện trước đây. Vì vậy, tôi bắt đầu thảo luận vấn đề với khách hàng trước khi bắt đầu dự án. Một số khách hàng muốn sở hữu mã đó, một số thì không (tôi luôn đưa ra các ưu đãi tiêu cực, như giá cao hơn cho những người làm). Nhưng, thực sự đối với một số khách hàng rằng cuộc thảo luận rất khó hiểu và đôi khi tôi đã kết thúc cuộc nói chuyện với 3 hoặc 5 người khác nhau (bao gồm cả luật sư của họ) chỉ để dự án được phê duyệt.

Vì vậy, bây giờ tất cả các thư viện của tôi là một phần của khung tùy chỉnh mà tôi luôn sử dụng để phát triển và tôi giải thích cho khách hàng rằng tôi sẽ sử dụng khung này nhưng khung đó là một sản phẩm khác với giấy phép khác. (Đôi khi tôi sử dụng "các thành phần phần mềm" khi giải thích vì "khung" có thể không phù hợp với chúng). Tôi luôn cung cấp mã của các tệp được sử dụng theo giấy phép MIT và (vì tất cả mã được tổ chức tốt) mã cấp thấp (thậm chí mới) vẫn còn trong khung (được tôi và chúng sử dụng lại) nhưng mã liên quan ứng dụng của họ chỉ dành cho họ để tuân theo các điều khoản của riêng họ (mã đó có lẽ sẽ vô dụng đối với tôi để sử dụng lại trong một dự án khác). Tất nhiên tất cả những gì được viết đúng trong hợp đồng. Tôi nghĩ rằng điều này là công bằng quá.

Chìa khóa là: "các thành phần này là một sản phẩm khác nhau" và tất cả được viết trong một hợp đồng trước khi bắt đầu.

Vì vậy, có, bạn nghĩ về việc sử dụng các thư viện chia sẻ có thể đúng. Tuy nhiên, tôi hỏi bạn, tại sao bạn không cung cấp cho họ mã nguồn bạn đã sử dụng, theo giấy phép cho phép họ giảm rủi ro? Tôi nghĩ rằng đó sẽ là công bằng.

Cách để đối phó với điều này là đàm phán.

Nếu họ muốn mã nguồn, thì họ nên sẵn sàng trả tiền cho nó, và bạn phải quyết định số tiền đó là bao nhiêu.

Mặt khác ... nếu họ không sẵn sàng trả những gì bạn muốn, họ có thể quyết định "đưa doanh nghiệp của họ đi nơi khác".

Chào mừng đến với thế giới kinh doanh :-)

Và khi bạn nói chuyện với khách hàng tiềm năng trong tương lai, hãy nhớ đề cập đến vấn đề này sớm ... để tránh lãng phí thời gian của mọi người.

Điều đáng chú ý là những gì bạn đang làm là sự vô cảm đối với các nhà phát triển nguồn mở và cho các khách hàng (có học thức) đang tìm kiếm các giải pháp nguồn mở.

Điều này có thể là quá muộn đối với bạn, ở chỗ bạn có thể đã đồng ý hợp đồng để làm điều này và bạn có thể đã đồng ý với các điều khoản không tương thích lẫn nhau với các khách hàng khác nhau.

Có hai cách để bạn có thể cung cấp cho khách hàng mã nguồn của mình. Quyền sở hữu bản quyền và được cấp phép.

Một số khách hàng sẽ muốn sở hữu mã nguồn. Điều này có nghĩa là, vào cuối quá trình họ sẽ trả tiền cho bạn và đổi lại bạn sẽ trao cho họ bản quyền bản quyền của mã bạn tạo cho họ. Một lý do cho điều này là nếu họ thấy tiềm năng đáng kể đối với tài sản trí tuệ trong mã nguồn và có thể muốn định giá này trên bảng cân đối công ty của họ. Trong trường hợp này, bạn sẽ không có quyền tiếp tục sử dụng mã nguồn đó cho các dự án khác, trừ khi bạn cũng có được giấy phép từ khách hàng của bạn cung cấp cho bạn quyền này.

Nếu khách hàng của bạn đang mua một sản phẩm 'ngoài kệ' từ chính họ, họ sẽ mong nhận được giấy phép sử dụng phần mềm, chứ không phải quyền sở hữu mã nguồn. Họ nên hy vọng rằng bạn đang bán phần mềm tương tự (hoặc tương tự) cho nhiều tổ chức khác và họ hy vọng sẽ được hưởng lợi từ chi phí mua hàng thấp hơn do cơ sở khách hàng rộng hơn.

Tuy nhiên, tình huống trong câu hỏi này là một sự nhầm lẫn của cả hai.

Đây là những gì tôi muốn có thể làm. Tôi sẽ cấp cho khách hàng của bạn giấy phép sử dụng (và sửa đổi) mã được chia sẻ của bạn. Nếu khách hàng thắc mắc, tôi sẽ chỉ ra rằng đây là mã được chia sẻ mà bạn đã sử dụng trong nhiều dự án và có giá thầu hiện tại cho công việc trong tương lai dựa trên việc bạn tiếp tục sử dụng công việc này. chỉ ra rằng điều này đã dẫn đến ít thời gian hơn cho dự án này cho khách hàng của bạn và kết quả là họ đã trả giá thấp hơn. Giống như các thư viện chia sẻ mã khác được sử dụng bởi dự án, họ có giấy phép sử dụng mã này và cho phép các nhóm phát triển khác phát triển mã này và các dự án khác dựa trên thư viện này. Tuy nhiên, nếu họ muốn sở hữu tất cả các mã, bạn sẵn sàng tạo một sự thay thế, nhưng đây sẽ là một khoản phí bổ sung.

Tùy thuộc vào những gì bạn đã cam kết, bạn có thể phải viết một chức năng thay thế miễn phí hoặc cho đi mã nguồn của bạn.

Hãy nhớ rằng, có nhiều loại thư viện khác nhau. Thư viện mẫu tiêu chuẩn trong C ++ là một ví dụ điển hình về thư viện được bao gồm ở cấp mã nguồn và được biên dịch thành một tệp thực thi dự án có thể khá giống với cách bạn đã sử dụng mã chung của mình.

Nếu bạn sử dụng bên thứ ba với phần mềm mà bạn cung cấp, rất có thể bạn không có mã nguồn cho bên thứ ba này. Bạn vẫn sẽ cung cấp phần mềm cho công ty với các nhị phân của bên thứ ba. Mã mà bạn đã phát triển như một khung được chia sẻ trong tất cả các dự án của bạn giống hệt như bên thứ ba ngay cả khi thuộc sở hữu của bạn. Trong trường hợp này, công ty có cùng rủi ro với các nhị phân trong khuôn khổ của bạn so với bên thứ ba. Tại sao trong trường hợp này bạn sẽ cung cấp cho công ty mã nguồn của khung của bạn. Bạn có thể cung cấp cho cô ấy một tài liệu API tốt với một thỏa thuận cấp phép và nó. Nếu mã của bạn chứa thứ lớn tiếp theo sẽ cách mạng hóa ngành công nghiệp, thì đó là một câu chuyện khác nhưng nói chung không phải vậy.