Клиенту нужен исходный код, но он содержит много общего кода, который я повторно использую с другими проектами

У меня есть клиент, который хотел бы, чтобы я доставил исходный код с разработанным двоичным файлом приложения. Изначально они ничего не сказали об исходном коде, но недавно сказали, что он им нужен. Контракт не окончен. Они согласились на работу, не подписали, а затем вернулись с этим пунктом.

Проблема в том, что у меня есть кодовая база, которую я создал за многие годы и использовал в качестве шаблона для большинства приложений, которые я пишу. Это намного больше, чем масштаб проекта.

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

Я предполагаю, что это не первый раз, когда это происходит в этой отрасли. Каков наилучший способ обойти эту проблему? Я предполагаю, что такие вещи, как общие библиотеки, могут помочь.

Первое, что нужно иметь в виду, это то, что исходный код имеет значение отдельно от двоичных файлов. Вполне разумно либо отказаться от подписания контракта, требующего доставки исходного кода, либо настаивать на дополнительных платежах за доставку исходного кода. Контракты являются двусторонними документами. Не позволяйте другой части диктовать, что требуется только потому, что они являются «большими компаниями» и «делают это все время». Во-первых, решите, что вы хотите доставить и как вы хотите получить компенсацию. Затем возьмите свой контракт с адвокатом и определите, что нужно изменить. Затем вы ведете переговоры.

Не делайте то, что делают многие молодые люди, когда начинают заключать контракты. Не просто подписывайтесь, потому что кажется, что у них большой опыт, а у вас нет. Это хороший способ сорваться.

Посмотрите, почему они хотят источник. Они могут хотеть этого, чтобы потом иметь возможность использовать другого разработчика. Или они могут хотеть этого только потому, что боятся, что вы можете попасть под автобус, и вдруг у них останутся двоичные файлы, которые они не смогут улучшить. Если это второй случай, обратитесь в службу условного депонирования программного кода . Эти службы хранят исходный код на случай, если вы обанкротитесь или не сможете поддерживать программное обеспечение. Это может удовлетворить как ваше желание сохранить свой код закрытым для обслуживания других клиентов, так и их желание не оставлять пакет с неуправляемым набором двоичных файлов, если что-то плохое случится.

«Нет» - это очень хороший ответ, на самом деле это невероятно полезный ответ, который по какой-то причине, которого я не могу понять, очень недооценен.

«Привет, мы неожиданно решили, что нам нужен только исходный код, бесплатно».
"Привет, нет."

Это не так сложно, правда.

Тогда, если они желают платить вопиющую сумму денег сверх того, что они уже обязаны вам, вы могли бы дать им обрезанную версию приложения, которая включает в себя только источники , они на самом деле нужны, и заботиться , они получают абсолютно не являющиеся -Эксклюзивные права.

Не усложняйте простые вещи.

Ваш вопрос: «Каков наилучший способ обойти эту проблему?» Но в чем вы видите проблему? Другие правильно отметили, что это вопрос переговоров: все имеет ценность, и вы должны дать клиенту цену за то, что он попросил.

Но вы также должны внимательно рассмотреть - и записать в контракт - последствия предоставления кода. Это просто, чтобы клиент мог это увидеть? Может ли клиент изменить это? И, в частности, хотели бы вы предоставить своему клиенту эксклюзивные права на кодовую базу, которую вы создали за многие годы и которая используется в качестве шаблона для большинства приложений, чтобы вы никогда больше не могли использовать ее в будущем?

Вы должны убедиться, что в контракте четко указано, кто имеет права на использование кода и каким образом.

Помните, что любой исходный код требует лицензии. Если вы передадите исходный код, компания может использовать исходный код для выполнения всего, что позволяет лицензия, и всего, что не является нарушением авторских прав. Таким образом, если вы передадите исходный код, у вас будет контракт, в котором будет абсолютно ясно, что вы сохраняете исключительное авторское право на исходный код, и что в точности разрешено использование исходного кода. И, конечно, исходный код + лицензия не будут бесплатными.

Крупная компания вряд ли будет нарушать ваши авторские права, потому что попадание может нанести серьезный ущерб их репутации, помимо финансового ущерба. С другой стороны, оплата программного обеспечения без гарантии того, что какие-либо проблемы могут быть исправлены в будущем, может быть неприемлемой для клиента.

Ранее я обычно предоставлял клиенту исходный код (библиотеки и все) под лицензией MIT. Если ваши библиотеки хорошо организованы, вы предоставляете только необходимые файлы / ресурсы для этого конкретного клиента, но не более того. Я думаю, что это справедливо как для меня, так и для клиента. Однако всегда была проблема нового кода, написанного для этого конкретного клиента по контракту, который раньше не был частью библиотеки. Поэтому я начал обсуждать эту проблему с клиентом перед началом проекта. Некоторые клиенты хотели владеть этим кодом, некоторые - нет (я всегда давал негативные стимулы, например, более высокие цены для тех, кто это делает). Но на самом деле для некоторых клиентов эта дискуссия была очень запутанной, и иногда я в конечном итоге разговаривал с 3 или 5 разными людьми (включая их адвоката) только для того, чтобы одобрить проект.

Так что теперь все мои библиотеки являются частью пользовательской среды, которую я всегда использую для разработки, и я объясняю клиенту, что буду использовать эту среду, но эта среда - это другой продукт с другой лицензией. (Иногда я использую «программные компоненты» при объяснении, потому что «фреймворк» может быть им неизвестен). Я всегда предоставляю код используемых файлов по лицензии MIT и (поскольку весь код хорошо организован) низкоуровневый код (даже новый) остается в структуре (для повторного использования мной и ими), но код, относящийся к только для их приложения, чтобы они оставались на своих собственных условиях (этот код, скорее всего, было бы бесполезным для меня для повторного использования в другом проекте). Конечно все это правильно написано в договоре. Я думаю, что это тоже справедливо.

Ключ: «эти компоненты - другой продукт», и все написано в контракте перед началом.

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

Способ справиться с этим - вести переговоры.

Если им нужен исходный код, он должен быть готов заплатить за него, и вам решать, сколько это должно быть.

С другой стороны ... если они не готовы заплатить то, что вы хотите, они могут решить «заняться своими делами в другом месте».

Добро пожаловать в мир бизнеса :-)

И когда вы будете разговаривать с потенциальными клиентами в будущем, обязательно упомяните эту проблему на ранней стадии ... чтобы не тратить время каждого.

Также стоит отметить, что вы делаете анафему для разработчиков с открытым исходным кодом и (для образованных) клиентов, которые ищут решения с открытым исходным кодом.

Это может быть слишком поздно для вас, поскольку вы, возможно, уже договорились сделать это по контракту, и вы могли бы договориться о взаимно несовместимых условиях с различными клиентами.

Вы можете предоставить своим клиентам исходный код двумя способами. Право собственности на авторское и лицензированное.

Некоторые клиенты захотят владеть исходным кодом. Это означает, что в конце процесса они заплатят вам деньги, а вы в обмен передадите им авторские права на код, который вы для них создаете. Одна из причин этого заключается в том, что они видят значительный потенциал интеллектуальной собственности в исходном коде и могут захотеть оценить это в балансе своей компании. В этом случае у вас не будет права на дальнейшее использование этого исходного кода для других проектов, если только вы не получите лицензию от своего клиента, дающую вам это право.

Если ваш клиент покупает «готовый» продукт у вас, он будет ожидать получения лицензии на использование программного обеспечения, а не владения исходным кодом. Они должны ожидать, что вы продаете то же самое (или подобное) программное обеспечение многим другим организациям, и что они надеются получить выгоду от более низкой стоимости покупки из-за более широкой клиентской базы.

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

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

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

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

Если вы используете стороннее программное обеспечение, которое вы поставляете, есть вероятность, что у вас нет исходного кода для этого третьего лица. Вы все равно будете доставлять программное обеспечение в компанию с двоичными файлами третьей стороны. Код, который вы разработали в качестве фреймворка для всех ваших проектов, похож на сторонний, даже если он принадлежит вам. В этом случае компания имеет тот же риск с двоичными файлами вашей платформы, что и с третьей стороной. Почему в этом случае вы дадите компании исходный код вашей платформы? Вы можете предоставить ей хорошую API-документацию с лицензионным соглашением и этим. Если ваш код содержит следующую важную вещь, которая произведет революцию в отрасли, это уже другая история, но, как правило, это не так.