Итак, ваша работа заключается в разработке и разработке мобильных приложений. Но есть разница между простым созданием приложений и профессиональным разработчиком. Если вы серьезно относитесь к карьере в мобильных приложениях, вам нужно будет усилить свою игру и принять лучшие профессиональные практики, начиная с надлежащих бизнес-контрактов. Письменный договор защищает вас и людей, с которыми вы работаете. Тщательно составленный контракт может обеспечить вам оплату за работу и избавить вас от болезненных и дорогостоящих юридических проблем.
Мы рассмотрим пять основных документов, с которыми рано или поздно столкнется любой разработчик приложения в своей профессии, и поможем вам разобраться с юристами с помощью некоторых советов и примеров, которые вы можете использовать в качестве отправной точки.
Соглашение о передаче технологий
Согласно Закону об авторском праве разработчик владеет кодом в тот момент, когда он «зафиксирован в материальной форме». Другими словами, вы владеете авторским правом, как только нажимаете «Сохранить», даже если вы еще ничего не выпустили. Это также относится, конечно, к дизайну и креативному контенту, который входит в приложение. В подавляющем большинстве случаев вы также будете использовать работу других для создания своего приложения. Вам лучше убедиться, что вы им владеете, иначе вы можете столкнуться с претензиями третьих сторон на доходы. Для этого и существует Соглашение о передаче технологий. Это простой контракт, в котором кто-то назначит вам (или вашей компании, если вы зарегистрированы) интеллектуальную собственность произведения. Вот очень простой пример, чтобы дать вам идею.
Как и в случае с каждым контрактом, он должен быть действительным. Рассмотрение — это просто ценность, которой обмениваются, чтобы иметь права ИС (интеллектуальной собственности). Обычно это деньги (подойдет любая ценность, но могут оспариваться такие символические суммы, как 1 доллар), но они также могут быть акциями компании, как в этом примере . Это также может быть обещание, например, определенный процент будущих продаж или доходов. Важными вещами являются заверения и гарантии лица, которое присваивает авторские права. Например, в этом разделе будет указано, что:
- [разработчик] является единственным владельцем всех прав и прав на интеллектуальную собственность.
- [Разработчик] не назначил такие права никому другому.
- [Разработчик] не осведомлен о каком-либо нарушении, нарушении или незаконном присвоении прав третьих лиц ИС.
- [разработчик] не действовал в рамках сферы занятости какой-либо третьей стороной при разработке или создании ИС (потому что, в этом случае, ИС принадлежит стороннему работодателю).
Обратите внимание, что часто есть соглашение о неразглашении, включенное в этот тип соглашения. Это довольно стандартно и не должно быть предметом переговоров!
Работа по найму
Работа с другими; для этого есть контракт. Если вы используете подрядчиков для создания какой-либо части своего приложения, вам нужен документ под разными именами: соглашение с независимым подрядчиком, соглашение о работе по найму или даже контракт на оказание услуг по разработке мобильных приложений . Все они по сути одинаковы, если у них есть пункт «работа по найму», например:
Работа по найму. Разработчик прямо признает и соглашается с тем, что любые проприетарные материалы, подготовленные Разработчиком в соответствии с настоящим Соглашением, будут считаться «работами по найму» и исключительной собственностью Компании, если не указано иное. Эти элементы должны включать в себя, но не ограничиваться ими, любые результаты, полученные в результате использования Услуг Разработчика или предусмотренные настоящим Соглашением, все ощутимые результаты и доходы от Услуг, незавершенные работы, записи, диаграммы, примечания, чертежи, спецификации, схемы, документы, проекты, усовершенствования, изобретения, открытия, разработки, товарные знаки, коммерческие секреты, списки клиентов, базы данных, программное обеспечение, программы, промежуточное программное обеспечение, приложения и решения, задуманные, созданные или обнаруженные Разработчиком, исключительно или в сотрудничестве с другими в течение срока действия настоящего Соглашения, каким-либо образом относящегося к Услугам Разработчика.
Самое замечательное в договоре о найме на работу заключается в том, что он заботится о назначении IP для вас. Таким образом, если вы подписываете его своевременно со своим подрядчиком, то есть до того, как какая-либо работа будет выполнена, вам не нужно отдельное соглашение о переуступке: весь код и дизайн, который подрядчик сделает для вас, автоматически присваивается вашей компании.
Если вы являетесь внештатным разработчиком, вы можете ожидать, что ваши клиенты всегда захотят подписать соглашение о работе по найму, так как они хотят быть полноправными владельцами исходного кода приложения как можно скорее. Обратной стороной этого является то, что они могут делать с вашим творением все, что захотят. Если вы хотите ограничить использование вашего кода (или дизайна), вам следует избегать соглашений о работе по найму (подробнее об этом ниже).
Если у вас нет рычагов, чтобы избежать работы по найму, постарайтесь сохранить так называемые «права портфеля», чтобы вы могли хотя бы продемонстрировать свою работу будущим клиентам или работодателям.
Лицензионное соглашение
Очень часто называемый «соглашением об обслуживании» или некоторым его изменением, этот договор радикально отличается от того, который указан выше в положениях об ИС; авторское право не присваивается автоматически, а вместо этого лицензируется клиенту или комиссионеру за плату (фиксированную или периодическую). Лицензирование позволяет внештатным разработчикам настраивать свои предложения в большом объеме, например:
- они могут ограничивать объем лицензии конкретным проектом или продуктом, географическим районом или периодом времени;
- они могут заставить клиента платить премию за исключительное использование кода;
- они могут определять различную обработку IP для так называемых «инструментов» (то есть тех фрагментов кода или шрифтов, которые вы включаете в несколько проектов. То, что они находятся в каком-либо проекте клиента, не означает, что клиент владеет инструментами. Вместо этого, вы только даете клиенту разрешение на продолжение использования инструментов.)
Большую часть времени ваш лучший выбор — это хороший компромисс между лицензированием и работой по найму. Соглашение о всеобъемлющем обслуживании, как правило, является лучшим из обоих миров, см., Например:
Эти документы прямо исключают, что конечный продукт (в данном случае приложение) будет работать по найму, чтобы можно было выполнить задание при оплате полной цены. Это самый лучший инструмент, который вы должны избегать, так что убедитесь, что он включен в ваш контракт!
«Чистые» лицензионные соглашения пригодятся, когда вам необходимо получить надлежащее разрешение на использование в приложении сторонних носителей, таких как изображения и звуки. Прекрасным примером является это Лицензионное соглашение о музыке, относящееся к использованию мобильных приложений.
политика конфиденциальности
На данный момент вы не нарушаете закон, если у вас нет политики конфиденциальности при условии, что вы не собираете «конфиденциальные» данные, такие как информация о детях, финансовые данные или данные, связанные со здоровьем. Тем не менее, в Европейском Союзе действуют более строгие политики конфиденциальности, и вы можете попасть в эту регулирующую сеть. Кроме того, как в Apple App Store, так и в Android Market существуют условия, которые требуют обновленной и «юридически адекватной» политики конфиденциальности для всех приложений, которые собирают имена пользователей и пароли.
Таким образом, существует очень высокая вероятность того, что вашему приложению требуется политика конфиденциальности. Вот пара примеров с открытым исходным кодом, которые могут быть хорошей отправной точкой:
- Политика конфиденциальности для мобильных устройств
- Политика конфиденциальности для мобильных устройств (для приложений, использующих геолокацию)
- Политика конфиденциальности для мобильных устройств (для приложений, использующих рекламу)
Есть также несколько бесплатных генераторов политики конфиденциальности, с единственным мобильным центром на момент написания из Privacy Choice . В любом случае, дело не в том, чтобы в вашем приложении был фрагмент текста под названием «политика конфиденциальности», а в том, чтобы убедиться, что текст правдив и обновлен. Например, если вы добавляете в приложение службу отслеживания, такую как Google Analytics (даже если вы просто собираете анонимные данные для внутренних целей), вам необходимо обновить политику конфиденциальности. Прочтение новых руководств FTC для разработчиков приложений определенно поможет вам понять, что следует включить в политику конфиденциальности. Хотя слепое копирование и вставка политики вашего крупнейшего конкурента не очень хорошая идея, сравнение вашей политики с политикой других — лучший способ убедиться, что вы ничего не забыли.
NDA
Не в последнюю очередь, печально известный NDA! Столько, сколько все ненавидят соглашения о неразглашении, они все еще довольно распространены в техническом бизнесе. Так что не удивляйтесь, если кто-то, с кем вы имеете дело, попросит вас подписать его. Это один из тех контрактов, который редко срабатывает, но если работа или отношения уходят на юг, это может стать настоящим спасением, и именно поэтому люди все еще используют его.
Если вам прислали NDA для подписи, очень внимательно проверьте следующие три вещи:
- Если NDA является взаимным или односторонним: то есть, если только одна сторона раскрывает информацию. Если вы не являетесь подрядчиком или сотрудником, старайтесь подписывать только взаимные соглашения о неразглашении.
- Если NDA содержит неконкурентных: это, как правило, неприятное положение, настолько неприятное, что в Калифорнии его нельзя применять. Убедитесь, что этот пункт не является слишком широким, как по продолжительности, так и по объему.
- Если NDA содержит другие положения вне рынка. Как вы это проверяете? Что ж, сравните это со стандартными NDA в отрасли, такими как этот , этот или этот .
Вывод
Поскольку разработка приложений по-прежнему является относительно новым бизнесом, многие юридические вопросы были рассмотрены разработчиками, работодателями и даже магазинами приложений довольно свободно. Но не стоит забывать, что вышеупомянутые проблемы будут становиться все более важными по мере вашего продвижения по карьерной лестнице, а также по мере того, как мобильные приложения станут еще более масштабной отраслью.
Отказ от ответственности: эта статья хочет быть полезной и информативной, но имейте в виду, что это не юридическая консультация, и все упомянутые юридические документы должны использоваться только в качестве отправной точки. Автор BuildMobile, Docracy и авторы указанных правовых документов отказываются от любой ответственности, связанной с использованием этих материалов без лицензированного адвоката.