Кастомизированная разработка практически невозможна без передачи разработчику конфиденциальной информации (КИ). Иначе какая же она кастомизированная.
Чем крупнее заказчик, тем сложнее согласовать условия соглашения о конфиденциальности. Типовой договор с вероятностью, близкой к 100%, будет избыточным.
В итоге вместе с минимальным объемом информации, необходимой для работы, можно получить кучу обязанностей – хранить и оберегать как свою собственную, в течение многих лет, даже после окончания срока действия соглашения. Вести учёт, организовывать хранение, компенсировать убытки. Предоставлять раскрывающей стороне возможность аудита. Платить многомиллионные штрафы за сам факт раскрытия. Бог знает, что еще. Это же типовая форма, она утверждена председателем правления, в неё нельзя вносить изменения.
Чтобы иметь возможность спокойно делать свою работу, нужно иметь максимально понятный объем обязательств. Эта простая истина может быть реализована с помощью нескольких условий.
Каждое из этих условий логично и защищает в том числе заказчика – чем меньше КИ он раскрывает, тем ниже риск утечки. Нет избыточности, да четкому кругу обязательств. Берегите себя и свою конфиденциальную информацию.
Чем крупнее заказчик, тем сложнее согласовать условия соглашения о конфиденциальности. Типовой договор с вероятностью, близкой к 100%, будет избыточным.
В итоге вместе с минимальным объемом информации, необходимой для работы, можно получить кучу обязанностей – хранить и оберегать как свою собственную, в течение многих лет, даже после окончания срока действия соглашения. Вести учёт, организовывать хранение, компенсировать убытки. Предоставлять раскрывающей стороне возможность аудита. Платить многомиллионные штрафы за сам факт раскрытия. Бог знает, что еще. Это же типовая форма, она утверждена председателем правления, в неё нельзя вносить изменения.
Чтобы иметь возможность спокойно делать свою работу, нужно иметь максимально понятный объем обязательств. Эта простая истина может быть реализована с помощью нескольких условий.
- Указание, что NDA применим к конкретному проекту. Соблазн распространить его на все существующие и будущие проекты велик, зачем подписывать лишнее. Но чем меньше объем, тем меньше ресурсов требуется на его хранение, меньшее количество людей могут получить доступ, ниже риски раскрытия.
- Конфиденциальная информация – только письменная, с пометкой типа «конфиденциально». Позволяющая однозначно понять, распространяется на конкретную информацию режим конфиденциальности или нет. В таком случае маркировать информацию – зона ответственности заказчика. Избегать формулировок типа «любая информация».
- Не всю КИ возможно вернуть и уничтожить. «Остаточная» оговорка («residual» clause) используется в стандартных NDA компаний типа Microsoft. Закрепляет право на данные, оставшиеся в результате наличия доступа к КИ, существующие вне материальных носителей (например, в памяти лица, имевшего доступ к КИ), включая идеи, принципы, методы. Ни одна из сторон не в праве ограничивать или запрещать использование «остаточной» информации такими лицами, а также взымать плату за ее использование. Настоящее условие не распространяется на объекты патентного и авторского права, принадлежащие на законном основании раскрывающей стороне.
- Персональные данные – не забываем добавить обязательство раскрывающей стороны получить согласие субъекта на передачу его персональных данных принимающей стороне, и предоставить это согласие по требованию принимающей стороны (например, в случае проверки). А еще уведомить субъекта, что его данные переданы 3 лицу (особенно актуально для европейских граждан).
- Право на досрочный возврат КИ. Если получаем что-то ненужное (например, лишнее или вообще не относящееся к проекту), не стесняемся возвращать КИ ее владельцу (материальный носитель), либо уведомлять об уничтожении (если возвращать нечего).
- Нет двойной и тройной ответственности за одно и то же нарушение. Случайная утечка данных не может использоваться как средство обогащения одной из сторон. Ограничиваемся прямыми документально подтвержденным ущербом (не убытками, что будет означать ущерб + упущенная выгода) в пределах 30-70% от стоимости проекта.
Каждое из этих условий логично и защищает в том числе заказчика – чем меньше КИ он раскрывает, тем ниже риск утечки. Нет избыточности, да четкому кругу обязательств. Берегите себя и свою конфиденциальную информацию.
powerman
Это всё слишком далеко от текущих реалий.
Большинство знакомых разработчиков подписывают любые NDA не заморачиваясь. Я обычно 4 из 5 NDA возвращаю на доработку, и пока что мои правки всегда принимались, но и там речь шла об убирании совсем уж полной дичи (сроки в 10 лет после завершения проекта, безумные суммы возмещения, отсутствие ограничений на информацию о конкретном проекте или хотя бы компании, отсутствие ограничений на общеизвестную информацию либо просто известную мне до начала работы над проектом, отсутствие принципиальной возможности выкладывать части проекта в опенсорс с разрешения заказчика, ограничение на разглашение названия компании/проекта, etc.)…
А Вы тут рассуждаете о письменных документах с явной пометкой "конфиденциально" — я лично таких за 30 лет работы не видел ни разу. Упоминания возможности "случайной утечки" так же ни разу ни в одном NDA мне пока не попадалось.
В общем, было бы неплохо, конечно, выпустить и популяризовать "рекомендованный NDA" (вроде типовых лицензий MIT/BSD/GPL), но пока это фантастика.
WhiteSideOfTheLaw Автор
Документы с пометкой «конфиденциально» не есть экзотика, а вот получить разрешение от крупного заказчика разместить в открытом доступе часть кода, написанного за его счёт, это фантастика. Госзаказчик — тот прямо рискует получить претензии от ФАС за подобные формулировки, поэтому у него другое понятие о том, что есть дичь.
А любой «рекомендованный» договор навязать невозможно, свобода воли сторон и всё такое. Только практика, которая у нас вырабатывается, вырабатывается, да никак не выработается.
powerman
Я не работал (и не хочу, если честно, слишком много лишних проблем) на госзаказчика. Из моих заказчиков ещё ни один принципиально не отказывался выкладывать код в опенсорс. Разумеется, речь не идёт о проекте целиком или частях с бизнес-логикой проекта, но всякие вспомогательные библиотеки/утилиты которые создаются в рамках работы над проектом никто из заказчиков не препятствовал выкладывать в опенсорс.
Более того, я в принципе не буду работать на проекте, где возможность выкладывать в опенсорс исключена, просто потому, что у меня нет желания переизобретать какие-то технические элементы на каждом следующем проекте с нуля, я предпочитаю сохранять возможность использования удачных технических решений/инструментов с предыдущих проектов в следующих.
Никто не говорит о навязывании. Просто у компании уже есть шаблонный договор, который она пытается пропихнуть всем сотрудникам — почему бы новым сотрудникам тоже не иметь свой вариант этого договора?
И когда есть такой "общеизвестный" вариант NDA, а компания продолжает настаивать на собственном — это хороший момент чтобы поинтересоваться, а что, собственно, данную компанию не устраивает в "общеизвестном" варианте NDA, какие именно дополнительные ограничения так критичны для этой компании… и это даст хорошую пищу для размышлений, стоит ли вообще идти к ним на работу.