Из какого материала сделан сайт? Или, что более важно, из какого материала он не сделан? Для меня это был настоящий юридический вопрос, когда коллега обратился ко мне по поводу спора с участием его клиента, веб-хостинга, ставшего разработчиком.
Клиент недавно расширил и обновил свои внутренние технические ресурсы. Тем не менее, он не стал переориентировать свое правовое мышление, чтобы отразить технический сдвиг, который он сделал от создания простых веб-сайтов к разработке мощных программно-ориентированных сайтов и программного обеспечения на основе Интернета. Этот недосмотр привел к неподходящим контрактам и в конечном итоге поставил под угрозу авторское право компании на ценную библиотеку исходного кода, которую она использовала в проектах для множества различных клиентов.
К счастью, если вы позволите своим техническим идеям руководствоваться при составлении контрактов, вы сможете избежать ошибок этой компании.
Чей это сайт? Что такое сайт?
Очень часто покупатель требует владения правами интеллектуальной собственности на веб-сайт, который он заказывает. Заказчик вполне может утверждать, что он был бы привязан к развивающемуся хосту, если бы он не владел сайтом. Это обманчиво убедительный аргумент, который, честно говоря, многим разработчикам-хостам сложно опровергнуть. Но в этом и заключается ловушка.
За что торгуется клиент, когда заказывает сайт? Что предлагает разработчик-хост? С изменениями в технологии веб-разработки ответы на эти вопросы могут быть не такими ясными в наши дни, как раньше.
До: веб-сайт = внешний вид = бренд клиента
В прошлом веб-сайты содержали только чистый язык гипертекстовой разметки (HTML). Веб-страница представляет собой статическое отображение визуальных элементов: логотипов, графики, макета, цветовых тем и, конечно же, текста. Только в HTML реализован дизайн и оформление, «внешний вид» веб-сайта.
Визуальные элементы веб-сайта, разработанные на заказ, составляют основу уникального брендинга клиента. Конечно, клиент приводит веские аргументы в пользу владения этими элементами веб-сайта. И совершенно очевидно, что интерес клиента к этим элементам его сайта может быть юридически защищен (хотя по иронии судьбы, большая часть этой защиты «внешний вид и восприятие» может исходить не только из закона об авторском праве, но и из закона об авторском праве).
Поэтому веб-разработчики часто заключают контракты, которые предоставляют клиенту право собственности на его «Веб-сайт». Но что именно это означает сегодня?
Сейчас: Website = Logic = Инструментарий разработчика
Чистые статические HTML-сайты становятся все более редкими. Сегодня у нас есть клиентская интерактивность. У нас также есть множество платформ для обработки баз данных на стороне сервера и других серверных логических манипуляций, или, другими словами, для полноценного программирования.
Будь то на стороне сервера или на стороне клиента, логика, приводящая в действие веб-сайт, визуально не маркирует веб-сайт.
Извините, логика продается отдельно… Возможно
Итак, насколько убедительным является аргумент клиента в пользу владения серверной логикой, которая обеспечивает его веб-сайт? На мой взгляд, клиент не имеет права владеть логикой, которая обеспечивает работу сайта — если клиент явно не заключил сделку и не заплатил премию, особенно за права собственности на код (хотя, конечно, клиент имеет право на лицензию, не исключительно, использование логики).
Что говорится в законе о программном обеспечении сайта? На мой взгляд, ответ часто неясен. Если контракта нет, разработчик, не являющийся сотрудником, обычно владеет авторскими правами на программное обеспечение, которое они пишут, и другой интеллектуальной собственностью, которую они создают.
Однако обратите внимание, что есть некоторые важные исключения из этого правила, и суды иногда определяют «работника» иначе, чем мы, обычные люди.
Сделайте контракт, скажите, что вы имеете в виду
На практике обычно существует договор между разработчиком и заказчиком. К сожалению, в этом договоре обычно упоминается «Веб-сайт Клиента» без определения этого термина. Затем контракт подразумевает передачу клиенту права собственности на этот неопределенный «Веб-сайт». Для меня это напрашивается вопрос о том, включено ли программное обеспечение для обеспечения сайта в «Сайт».
Передача прав собственности на программные веб-сайты должна вызывать некоторые опасения у разработчиков. Если вы не правильно оформите свой контракт, вы можете поставить под угрозу владение вашим ценным исходным кодом.
Хорошей новостью является то, что при надлежащем уходе вы сможете предоставить своему клиенту желаемое и заслуженное право собственности на функции брендинга на его веб-сайте и при этом сохранить права на ваше программное обеспечение. Это беспроигрышный сценарий.
Чтобы достичь этого, все, что вам нужно сделать, — это четко отличить программное обеспечение, обеспечивающее работу Сайта, от самого «Сайта». Как обычно бывает, это выполнимая задача, если она решена в контракте.
Никогда не поздно…
Что если вы уже подписали «Веб-сайт» в договоре, который не проводит должного различия, и ваш клиент предъявляет претензии в отношении программного обеспечения, которое вы написали для работы за сайтом? В этом случае, я полагаю, вы сталкиваетесь с более дорогими и сложными задачами доказательства (нетехническому судье или жюри), что различие между разрешающим программным обеспечением и остальной частью Веб-сайта:
- прорезает суть того, действительно ли вообще было соглашение (общеизвестная «встреча умов»), и
- заслуживает большого веса при принятии решения по конкретным фактам вашего дела (так как нет договорного определения).
Программирование 101 для судей и присяжных
Как вы убедите народного судью или присяжных, как это различие должно было подкрепить всю сделку? Я бы сказал, что визуальные элементы — это, в основном, одноразовые сделки. Когда разработчик разрабатывает логотип для клиента, он должен извлечь полную стоимость или цену от этого клиента — потому что он никогда не сможет использовать (то есть повторно использовать) этот логотип для другого клиента. Точно так же HTML-код не может быть действительно использован.
Не так для истинных логических элементов, будь то сценарий или язык программирования. Как правило, эффективные и опытные разработчики работают усерднее и умнее, разрабатывая модульный код, который они могут многократно использовать, и постоянно извлекать из него выгоду.
Следовательно, расставание с авторскими правами на код, по сути, будет «стоить» разработчику снова и снова. Технически здравый смысл, справедливость и динамика бизнеса заставляют разработчика отказаться от владения кодом только осознанно и за соответствующую цену.
Архитектура веб-сайта для серверной стойки — и зал суда
Как вы убедительно отличаете программное обеспечение от веб-сайта для судьи или присяжных? Ваше программное обеспечение должно быть как можно более разным и отделенным от остальной части Сайта. В идеале ваше программное обеспечение должно существовать в совершенно отдельных файлах (DLL, EXE-файлах и т. П.) И находиться на отдельном сервере от того, на котором размещается сайт. Прелесть этой архитектуры в том, что она одинаково желательна как с правовой, так и с технической точек зрения.
Вывод
На основании широко распространенных контрактов, связанных с Интернетом, различие между веб-сайтом и программным обеспечением для управления сайтом является неясным. Но при правильных обстоятельствах — если умело рисовать, в суде или в контракте — это различие может просто иметь значение между прибылями и убытками.
Что случилось с клиентом моего коллеги, обсуждалось в начале этой статьи? Было решено провести переговоры, чтобы избежать неопределенности исхода ожидаемого судебного разбирательства. Видите ли, у этого разработчика-хозяина было несколько ударов по нему.
Во-первых, в его контракте не было никакой разницы между веб-сайтом и программным обеспечением. Напротив, по своим безрассудным условиям разработчик-хозяин передал своему клиенту права интеллектуальной собственности на «всю разрабатываемую собственность».
Во-вторых, этот разработчик-хостер не пытался технически отделить веб-интерфейс пользователя от значительного количества логики, которая использовалась для веб-сайта. Вместо этого он внедрил всю логику в сценарии на стороне сервера, которые полностью находились в веб-страницах рендеринга. Конечно, вы и я знаем, что это все еще программное обеспечение, но попробуйте объяснить это нетехническому судье и жюри.
В любом случае, имеет смысл просто отделить пользовательский веб-интерфейс от логики — как юридически, желательно в виде четкого и тщательного контракта, так и технически в архитектуре реализации.
ПРИМЕЧАНИЕ. Предыдущая статья содержит только общую информацию. Не содержит юридических консультаций. Для получения юридической консультации вы должны проконсультироваться с адвокатом о вашей конкретной ситуации.