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

Question

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

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

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

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

• Как вы справляетесь с этой ситуацией? Что вы говорите клиентам заранее? Вы рекламируете это на своем сайте с самого начала? Как вы справляетесь с их возражениями, чтобы они все еще нанимали вас?

• В качестве дополнительного вопроса, как часто вы предоставляете исходный код AS и Flex своим клиентам? В случае, когда в коде нет внутренних компонентов, которые вы повторно используете в нескольких проектах, и в случае, когда в нем есть внутренние компоненты.

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

Хорошо подготовленный заранее подготовленный контракт избавит от многих недоразумений и ненужных переговоров. Вам, вероятно, понадобится всего один шаблон, который вы можете использовать для всех своих клиентов. Поэтому мой совет на самом деле «поговори с адвокатом» .

Answer 5

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