Клієнт хоче вихідний код, але він містить багато спільного коду, який я повторно використовую з іншими проектами

У мене є клієнт, який хотів би, щоб я доставляв вихідний код із розробленим бінарним додатком. Вони спочатку нічого не говорили про вихідний код, але нещодавно вони сказали, що це потрібно. Договір не завершений. Вони погодилися на роботу, не підписали, а потім повернулися з цією умовою.

Проблема полягає в тому, що у мене є база коду, яку я створив за ці роки і використовую як шаблон для більшості застосунків, які я пишу. Він набагато більший, ніж обсяг проекту.

Я також маю намір використовувати його для продукту, тому я дійсно не бажаю надавати його для порівняно невеликого проекту.

Я здогадуюсь, що це не перший раз, коли це трапилося в цій галузі. Який найкращий спосіб обійти це питання? Я здогадуюсь, такі речі, як спільні бібліотеки, можуть допомогти.

Перше, що потрібно пам’ятати, - це те, що вихідний код має значення, окреме від двійкових файлів. Цілком розумно або відмовитись від підписання договору, який вимагає доставки вихідного коду, або наполягати на додаткових платежах за доставку вихідного коду. Контракти - це двосторонні документи. Не дозволяйте іншій частині диктувати те, що потрібно лише тому, що вони "великі компанії" і "роблять це постійно". По-перше, визначте, що ви готові доставити і як ви хочете отримати компенсацію. Потім віднесіть їхній контракт до юриста і розробіть, що потрібно змінити. Тоді ви домовляєтесь.

Не робіть того, що робить багато молодих людей, коли вони починають укладати контракти. Не просто підписуйте, бо, здається, у них багато досвіду, а ви - ні. Це хороший спосіб позбутися.

Подивіться, чому вони хочуть джерела. Вони можуть захотіти цього, щоб згодом мати можливість використовувати інший розробник. Або вони можуть цього захотіти лише тому, що вони бояться, що вас може вдарити автобус, і раптом у них залишиться бінарний файл, який вони не зможуть покращити. Якщо це другий випадок, загляньте в службу детекції програмного коду . Ці служби містять вихідний код у випадку, якщо ви збанкрутуєте чи іншим чином не зможете підтримувати програмне забезпечення. Це може задовольнити як ваше бажання зберегти свій код власним для обслуговування інших клієнтів, так і їхнє бажання не залишати сумку з нездійсненним набором бінарних файлів, якщо трапиться щось погане.

"Ні" - це прекрасна відповідь, насправді це неймовірно корисна відповідь, яку я чомусь не можу зрозуміти, є дуже заниженою.

"Привіт, ми неодмінно вирішили, що хочемо також просто вихідний код, безкоштовно".
"Привіт, ні".

Насправді це не так складно.

Тоді, якщо вони бажають платити кричущу суму грошей понад те, що вони вже зобов'язані вам, ви могли б дати їм обрізану версію програми, яка включає в себе тільки джерела , вони на насправді потрібні, і піклуватися , вони отримують абсолютно не є -Ексклюзивні права.

Не ускладнюйте прості речі.

Ваше запитання: "який найкращий спосіб обійти цю проблему?" Але в чому ви бачите проблему? Інші правильно вказали, що це питання переговорів: усе має цінність, і ви повинні дати клієнтові ціну за надання того, про що вимагається.

Але ви також повинні уважно розглянути - і записати договір - наслідки надання коду. Це просто так, щоб клієнт міг це побачити? Чи може клієнт це змінити? І зокрема, чи могли б ви розглянути можливість надання клієнту ексклюзивних прав на створену вами базу коду за останні роки і використовується як шаблон для більшості програм, щоб ви більше ніколи не могли використовувати її самостійно в майбутньому?

Вам потрібно забезпечити, щоб у договорі прямо було вказано, хто має права на використання коду та якими способами.

Пам'ятайте, що будь-який вихідний код вимагає ліцензії. Якщо ви передаєте вихідний код, компанія може використовувати вихідний код, щоб зробити все, що дозволяє ліцензія, і все, що є поза порушенням авторських прав. Отже, якщо ви передасте вихідний код, у вас буде укладено контракт, в якому абсолютно ясно, що ви зберігаєте виключне авторське право на вихідний код, а також саме те, яке використання вихідного коду дозволено. І звичайно вихідний код + ліцензія не буде безкоштовною.

Велика компанія навряд чи порушить Ваші авторські права, тому що потрапляння в зловлення призведе до значної шкоди їхній репутації, крім фінансової шкоди. З іншого боку, оплата програмного забезпечення без гарантії того, що в майбутньому можуть бути усунені проблеми, може бути неприйнятною для клієнта.

Раніше я зазвичай надавав клієнту вихідний код (бібліотеки та всі) під ліцензією MIT. Якщо ваші бібліотеки добре організовані, ви надаєте лише необхідні файли / ресурси для цього конкретного клієнта, але нічого більше. Я думаю, що це справедливо і для мене, і для клієнта. Однак завжди випускався новий код, написаний для цього конкретного клієнта за контрактом, який раніше не був частиною бібліотеки. Тому я почав обговорювати це питання з клієнтом ще до початку проекту. Деякі клієнти хотіли володіти цим кодом, інші - ні (я завжди надавав негативні стимули, як підвищення цін для тих, хто це робить). Але, дійсно, для деяких клієнтів ця дискусія була дуже заплутаною, і іноді я закінчував розмову для 3 або 5 різних людей (включаючи їх адвоката), щоб отримати проект затверджений.

Тож тепер усі мої бібліотеки є частиною користувацької структури, яку я завжди використовую для розробки, і я пояснюю клієнту, що я буду використовувати цей фреймворк, але що фреймворк - це інший продукт з іншою ліцензією. (Іноді я використовую "програмні компоненти" при поясненні, оскільки "фреймворк" може бути невідомий для них). Я завжди надаю код використаних файлів під ліцензією MIT і (оскільки весь код добре організований) код низького рівня (навіть новий) залишається в рамках (щоб він повторно використовувався мною та ними), але код, що стосується до їхнього застосування лише вони повинні триматись під власними умовами (цей код, швидше за все, мій буде марним для повторного використання в іншому проекті). Звичайно все, що правильно записано в договорі. Я думаю, це теж справедливо.

Ключовим є: "ці компоненти - це інший товар", і все написано в договорі перед початком.

Так що так, ви можете уявити, що користуватися бібліотеками, що ділиться спільно, правильно. Однак я запитую вас, чому ви не надасте їм вихідний код під ліцензією, яка дозволить їм знизити ризик? Я думаю, це було б справедливо.

Спосіб вирішити це - домовитися.

Якщо вони хочуть вихідний код, тоді вони повинні бути готові заплатити за нього, і саме ви вирішите, скільки це повинно бути.

З іншого боку ... якщо вони не готові платити те, що ви хочете, вони можуть вирішити "взяти свою справу в інше місце".

Ласкаво просимо у світ бізнесу :-)

І коли ви будете спілкуватися з майбутніми клієнтами в майбутньому, не забудьте згадати цю проблему на початку ... щоб не витрачати час на всіх.

Варто також зазначити, що те, що ви робите, - це анафема як для розробників з відкритим кодом, так і для (освічених) клієнтів, які шукають рішення з відкритим кодом.

Це може бути для вас занадто пізно, оскільки ви, можливо, вже домовились зробити це договірно, і ви могли погодитися на взаємно несумісні умови з різними клієнтами.

Є два способи, якими Ви можете надати своїм клієнтам вихідний код. Право власності на авторське право та ліцензію.

Деякі клієнти захочуть право власності на вихідний код. Це означає, що в кінці процесу вони будуть платити вам гроші, і ви в обмін дасте їм авторські права на створений для них код. Однією з причин цього є те, якщо вони бачать значний потенціал інтелектуальної власності у вихідному коді і, можливо, хочуть оцінити це на балансі своєї компанії. У цьому випадку ви не матимете права на продовження використання цього вихідного коду для інших проектів, якщо ви також не отримаєте ліцензію від свого замовника, який дає вам це право.

Якщо ваш клієнт купує у вас продукт "з полиці", він очікує отримання ліцензії на використання програмного забезпечення, а не володіння вихідним кодом. Вони повинні очікувати, що ви продаєте те саме (або подібне) програмне забезпечення для багатьох інших організацій, і що вони, сподіваючись, виграють від меншої вартості придбання за рахунок ширшої бази клієнтів.

Однак ситуація в цьому питанні - це суперечка двох.

Ось що я хотів би зробити. Я надаю вашому клієнту ліцензію на використання (і зміну) вашого спільного коду. Якщо я запитав замовника, я зазначу, що це спільний код, який ви вже використовували в декількох проектах і маєте поточні ставки для майбутніх робіт, які базуються на тому, що ви продовжуєте використовувати цю роботу. зауважте, що це призвело до скорочення часу на цей проект для вашого замовника, і що він заплатив нижчу ціну. Як і інші спільні бібліотеки коду, що використовуються проектом, вони мають ліцензію на використання цього коду та дозволити іншим командам розробників розробляти цей та інші проекти на базі цієї бібліотеки. Однак, якщо вони бажають володіти всім кодом, ви готові створити заміну, але це буде додатковою платою.

Залежно від того, що ви вже взяли на себе зобов’язання, вам, можливо, доведеться написати функцію заміни безкоштовно або подати вихідний код.

Пам'ятайте, існують різні типи бібліотек. Стандартна бібліотека шаблонів в C ++ - хороший приклад бібліотеки, яка включена на рівні вихідного коду і складена у виконуваний проект, який може бути досить схожим на те, як ви використовували ваш загальний код.

Якщо ви використовуєте сторонне програмне забезпечення, яке ви постачаєте, можливо, у вас немає вихідного коду для цієї третьої сторони. Ви все одно будете доставляти програмне забезпечення компанії з бінарними файлами третьої сторони. Код, який ви розробили як основу, яка ділиться у всіх ваших проектах, точно так само, як і третя сторона, навіть якщо вона належить вам. У цьому випадку компанія має точно такий же ризик із бінарними файлами вашої системи, ніж з третьою стороною. Чому в такому випадку ви дасте компанії вихідний код вашої системи. Ви можете надати їй хорошу документацію API з ліцензійною угодою і це. Якщо ваш код містить наступну велику річ, яка зробить революцію в галузі, це вже інша історія, але це, як правило, не так.