Как объяснить клиенту, что вы не можете дать им часть источника

У нас есть несколько компонентов AS/Flex, которые мы построили с течением времени и улучшили. Они были превращены в компоненты, чтобы их можно было повторно использовать в разных проектах и сэкономить время. Таким образом, вы можете думать о них как о собственной структуре.

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

Итак, мой вопрос

Когда клиент приходит к вам, как вы объясните им, что вы не можете предоставить им полный исходный код для этих компонентов. Клиент не понимает разницы, он просто ожидает, что вы предоставите им весь код для сайта, который он вам заплатил. Он не понимает, что этот код заставил вас писать намного больше, чем то, что он заплатил за свой сайт. Но так как он не понимает, он отключится и подумает, что вы его разорвали или что-то в этом роде.
Как вы справляетесь с этой ситуацией? Что вы скажете клиентам заранее? Вы рекламируете его на своем сайте с самого начала? Как вы справляетесь со своими возражениями, чтобы они все еще нанимали вас?
Как побочный вопрос, как часто вы даете AS и Flex исходный код своим клиентам? В случае, если код не содержит каких-либо внутренних компонентов, которые вы повторно используете в нескольких проектах, и в случае, если у него есть внутренние компоненты.

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

Ответ 1

Я объясню моему клиенту, как работает мир. Я бы использовал примеры, аналогии и метафоры.

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

Предположим, вы хотите купить дом. Вы оплачиваете инженера и архитектора за их работу, и вы получаете документы, которые они производят. Эти документы содержат информацию, которая опирается на другие части информации, которые вы не получаете. Например, инженер может использовать огромные стальные стержни в своих планах. Технические характеристики инженера определяют качества, которые должны иметь каждый стальной стержень, но они не указывают, как создаются стальные стержни. Покупка планов домов не покупает вам планы по созданию блоков домов. С softwre это почти то же самое: вы не получаете исходный код для платформы .NET при покупке приложения .NET с включенным исходным кодом. То, что вы получаете, это документация .NET, определяющая, как работать с каркасом (и не указывать, как работает фреймворк).

Количество примеров на самом деле бесконечно, потому что, как указано выше, так работает мир.

Постройте свои собственные аналогии в соответствии со своим сценарием. Объясните своему клиенту, где заканчивается инфраструктура, и его собственное решение начинается.

quoo прав насчет необходимости указывать их в контракте. Контракт является юридическим основанием сделки. Но я хотел бы подчеркнуть тот факт, что , указывающий на контракт, должен быть последним средством. Если вы можете дать своему клиенту разумное объяснение, которое позволяет клиенту понять, почему все так, как вам кажется, вам не нужно будет размахивать контрактом (который определяет только то, что происходит, без мотивации, объяснения и т.д.),

Ответ 2

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

Ответ 3

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

Ответ 4

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

Какие компоненты предоставляются третьими лицами и относятся к их условиям лицензирования.
Какой код будет создан как часть контракта.
Лицензируйте или продайте различные права на интеллектуальную собственность.
Условия лицензирования.

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

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

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

Ответ 5

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