Вы слышали это раньше: никогда не работайте без контракта. Проблема в том, что контракты могут принимать различные формы и формы.
На самом деле это хорошая вещь, так как это означает, что закон позволяет вам быть гибким в распределении различных обязательств между вами и клиентом, но он также может заставить вас чувствовать себя перегруженными вариантами и законами.
Попробуем пролить свет на контракты разработчиков.
Важные вещи
Сначала немного базовой юридической информации. Обещаю, я постараюсь сделать это коротким и простым. Веб-разработчики обычно заключают один из двух типов контрактов. Одним из них является «работа по найму», а другим — вариант «соглашения об обслуживании», который может быть более или менее длительным и сложным в зависимости от масштаба проекта. В обоих случаях вы рассматриваетесь как независимый подрядчик в соответствии с трудовым и налоговым законодательством (хотя законы меняются в разных штатах, каждая цивилизованная страна должна иметь какую-либо форму отношений с независимым подрядчиком).
Основное различие между этими двумя типами документов заключается в управлении интеллектуальной собственностью (IP — обычно IP означает только авторское право, но концепция включает также патенты и товарные знаки). Авторское право принадлежит создателю, в момент, когда произведение «рождается» (технически, момент, когда ваша творческая работа встроена в «фиксированный формат», то есть вы записываете ее в текстовом редакторе).
Если вы работаете по принципу «работа по найму», авторские права на вашу работу автоматически присваиваются клиенту. Вместо этого, если вы используете «сервисное соглашение», вы можете решить, будут ли, когда и как будут назначены авторские права на созданные работы. В обоих случаях вы обмениваете интеллектуальную работу — так называемые «результаты» — деньгами или эквивалентом (акции, будущие доходы и т. Д.).
Список
Контракты немного похожи на код. Есть некоторые формальные части, которые всегда повторяются, чтобы убедиться, что все покрыто, и есть важные разделы, которые являются уникальными для каждой сделки. Вот почему шаблоны полезны: они заботятся о формальных частях для вас, так что вы можете сосредоточиться на соответствующих частях.
Вы и только вы можете объяснить, что вы будете строить и как это сделать. Помните, поскольку вы никогда не должны развертывать код, который вы не понимаете, не подписывайте контракт, который вы не понимаете полностью. Я постараюсь объяснить некоторые из основных вещей, но не стесняйтесь обращаться к адвокату за помощью.
Время для захватывающих вещей: давайте рассмотрим самые популярные примеры из реальной жизни.
- Соглашение об обслуживании AIGA для интерактивных проектов . Это золотой договорный стандарт, установленный AIGA, профессиональной ассоциацией дизайнеров. Несмотря на то, что он был разработан для проектных работ, он является идеальным контрактом для больших проектов, в которых много дизайна и кода. Этот документ очень длинный (есть короткая версия ), но также очень защищает интересы дизайнера / разработчика. Если вы посмотрите на раздел, посвященный ИС, вы увидите четыре основных варианта:
- Полное задание : после полной оплаты цены (не забудьте эту часть) вы «назначаете» авторские права клиенту, в том числе полностью. Это означает, что он теперь владеет тем, что вы создали, и он может делать с ним все, что захочет. Ему обычно даже не нужно кредитовать вас за работу, но этот контракт позволяет вам сохранить право показа работы в вашем личном портфолио.
- Ограниченная лицензия : вы сохраняете право собственности на произведение, клиент платит вам лицензионный сбор за его использование. Условия лицензии могут быть настолько гибкими, насколько вы хотите. Например, вы можете разрешить клиенту использовать код только для этого конкретного проекта. Конечно, чем шире лицензия, тем выше цена.
- Эксклюзивная лицензия : вы гарантируете клиенту, что вы не будете использовать тот же код или дизайн для других, сторонних проектов. Хотя эксклюзивность обычно является вполне приемлемым запросом, вам может не потребоваться лицензировать исключительно те фрагменты кода, которые вы перерабатываете для каждого проекта (так называемые «инструменты проектирования»). Но подождите, это должно быть подразделено дальше:
- Исключительно с разрешенными модификациями : клиенты могут не только использовать вашу работу, но и редактировать / адаптировать ее по своему усмотрению.
- Исключительно с изменениями не допускается : клиент не может изменить или добавить в то, что вы сделали. Довольно редкое, но абсолютно законное положение. Если вы такой большой шанс договориться об этом по хорошей цене, поболеть за вас.
- Контрактный убийца Энди Кларка — это совершенно другой подход по сравнению с AIGA. Это короткий контракт на простом английском языке, который довольно четко устанавливает условия и не тратит много времени на различные юридические оговорки. Любимый дизайнерами, он становится популярным среди разработчиков и UX-людей.
- Контракт дизайнера Эрика Адлера — хороший компромисс между юридической партией AIGA и британским юмором Кларка. Сосредоточив внимание на дизайне, он принимает во внимание кодирование и имеет несколько полезных советов, которые помогут вам пройти через него, чтобы убедиться, что он работает для вас.
- Договор на разработку от Daniel Bearsdley больше ориентирован на конечных разработчиков и учитывает части кода, которые вы, возможно, захотите выпустить под лицензией с открытым исходным кодом. Это действительно короткий, но для более сложных проектов вы можете проверить следующие примеры.
- Росс Кимбаровский, разработчик и бывший адвокат, опубликовал « Контракт для разработчиков, которые ненавидят контракты» с удобным руководством по контрактам, которое, безусловно, рекомендуется читать. В нем рассказывается о вещах, с которыми адвокат не может помочь, например, об установлении основных этапов, обговоре без особых хлопот и написании достойного отчета о работе.
- Говоря о SOWs, хотя они не являются строго юридическими документами, ведомости работ имеют обязательную юридическую силу и часто определяют операционную сторону контракта. На самом деле нет единой мысли о том, как написать хороший SOW, поскольку это сильно зависит от вашего типа и стиля работы, но вот пример для цифровой рекламы .
- Помните, что соглашения с независимым подрядчиком также можно назвать работой по найму .
- В то время как вы будете в основном использовать соглашения с независимыми подрядчиками, подобные тем, которые были показаны ранее, вы не можете обойтись без классической лицензии на программное обеспечение . Для больших пользовательских программных проектов, лицензионное соглашение может быть именно то, что вам нужно. Этот пример исходит от юриста, который очень долго объясняет, что означают различные части, и бизнес-решения, стоящие за ними.
- Разработчик приложения? Не волнуйтесь, этот контракт на услуги по разработке мобильных приложений является отличной отправной точкой.
- Последнее, но не менее важное: консалтинг. Все сделали это или будут консультироваться по крайней мере один раз, поэтому добавьте в контракт Контракт Технологии .
Вывод
Надеюсь, этот подготовленный и объясненный список примеров контрактов для разработчиков был полезен. Если вы ищете другой шаблон, который вам может понадобиться, посмотрите, сможете ли вы найти его в этом большом списке . Также не стесняйтесь делиться комментариями и предложениями в комментариях!
Отказ от ответственности: эта статья хочет быть полезной и информативной, но имейте в виду, что это не юридическая консультация, и все упомянутые юридические документы должны использоваться только в качестве отправной точки. Автор, издатель, Docracy и первоначальные авторы указанных документов отказываются от любой ответственности, связанной с использованием этих материалов без лицензированного адвоката.