Что каждый разработчик должен знать о правовых вопросах? [закрытый]
14 ответов
Двенадцать юридических аспектов разработки программного обеспечения
Программное обеспечение защищено авторским правом, если оно стало общедоступным. Больше нет необходимости помещать уведомление об авторских правах в приложение или в исходный код. Владелец авторских прав - автор (ы) или компания, выплачивающая автору (ам).
Авторское право на программное обеспечение может быть передано владельцем авторских прав, или оно может сохраняться за владельцем, и программное обеспечение может быть лицензированы для пользователя или пользователей владельцем.
Библиотеки, используемые в разработке, вероятно, имеют ограничения на их использование и распространение. GPL не делает библиотеку достоянием общественности, как и тот факт, что библиотека поставляется с платформой для разработки. Вы должны прочитать и понять лицензию, прежде чем распространять свое приложение. Некоторые библиотеки требуют выплаты роялти, хотя в последние годы это стало менее распространенным явлением.
Иски по патентным программам - это чушь. Вы, конечно, не должны сознательно нарушать патент на программное обеспечение. Однако есть небольшой, но реальный шанс, что какая-то компания подаст на вас в суд за нарушение их патента. Это может произойти, даже если вы разрабатываете свое программное обеспечение самостоятельно, вы никогда не слышали о патенте, а патент охватывает метод, который интуитивно очевиден и почти полностью не связан с вашим программным обеспечением. Учитывая текущую политику ВПТЗ США, мало что можно сделать, чтобы избежать этого, кроме покупки страховки. Хорошая новость заключается в том, что патентные тролли обычно предъявляют иски крупным компаниям с большими деньгами.
Если вы используете сотрудника или фрилансера для разработки программного обеспечения, вы должны четко указать в письменной форме, кому принадлежат авторские права на приложение, включая исходный код. код. Некоторые фрилансеры и контрактные компании-разработчики считают исходный код своей собственностью, оставляя компанию в зависимости от первоначального разработчика (ов). Это законно, если это указано в соглашении о разработке.
Если у вас есть сотрудник, который разрабатывает программное обеспечение «вне графика», вы должны четко указать, кому принадлежит это программное обеспечение, и какое программное обеспечение этот сотрудник должен уметь писать и распространять за пределами компании.
Если вы являетесь сотрудником или внештатным сотрудником, разрабатывающим программное обеспечение, вы должны четко указать, кому будут принадлежать авторские права на ваше приложение, прежде чем вы начнете разработку. Кроме того, вы должны знать или уточнить, кому принадлежит программа, которую вы пишете в свободное время. Некоторые компании содержат пункты в трудовых договорах, заявляющие о праве собственности на любое программное обеспечение, написанное разработчиком в период работы, будь то дома или на работе. Многие компании содержат в трудовых договорах положения о недопущении конкуренции, которые ограничивают программное обеспечение, которое сотрудник может производить для распространения за пределами компании. Иногда эти ограничения довольно широки.
Торговая марка - это имя или символ, а не само программное обеспечение. Если вы распространяете программное обеспечение, вы должны (а) убедиться, что название вашего приложения и «знак» или дизайн имени не «до степени смешения» похожи на другие приложения, и (б) зарегистрировать свой товарный знак. Дата первого использования важна при разрешении конфликтов, поэтому вы должны задокументировать, когда приложение впервые используется в торговле.
Когда вы даете название приложению, проверяйте наличие зарегистрированных товарных знаков, но также проверяйте Google. Приложение с первым использованием имени может получить ваше имя и товарный знак после того, как ваше приложение будет успешным, даже если они не зарегистрировали товарный знак, а вы зарегистрировали его.
Когда вы используете или подписываете договор или соглашение, убедитесь, что это понимают обе стороны. В трудовом договоре упоминание любых потенциально чувствительных областей заранее может предотвратить множество проблем в будущем. В соглашении о разработке, если обе стороны знают, кому принадлежит исходный код, или кто несет ответственность за обновления, или кто отвечает за обслуживание и т. Д. В рамках проекта разработки, то вероятность судебного разбирательства после приложения гораздо меньше. завершено. В соглашении о распространении убедитесь, что дистрибьютор понимает обязанности и условия соглашения.
В каждом нетривиальном приложении есть ошибки (или «соображения дизайна» :-)). В любом пользовательском соглашении или соглашении о распространении должно быть четко указано, что вы не несете ответственности за безошибочное программное обеспечение и не можете ожидать, что вы исправите все ошибки. Дайте понять, что изменения, исправления и обновления производятся по усмотрению (или при максимальных усилиях) разработчика, и проясните, кто платит за исправления и обновления.
Даже после консультации с юристом по поводу соглашений о разработке и распространении программного обеспечения. , вам следует ознакомиться с соглашениями других компаний-разработчиков программного обеспечения и посмотреть, что придумали их юристы.
Я не юрист, и это не юридическая консультация.
Имя хорошего юриста по интеллектуальной собственности.
Я бы ответил на этот вопрос так же, как отвечал бы: «Что должен знать каждый юрист о программировании?» Иными словами, знайте, что вы не можете знать глубинное поле настолько хорошо, чтобы делать больше, чем самые простые вещи. Найдите эксперта.
Для сотрудников: мы должны иметь возможность дать первый совет вашим клиентам - например, могут ли они / мы использовать компонент, который мы хотим, в своем приложении?
Для фрилансеров: мы должны уметь давать вашим клиентам дельные советы; и выбрать, какие компоненты мы можем использовать для приложений, которые мы для них разрабатываем.
Конечно, ваше слово не так хорошо, как советы, которые может вам дать юрист; но вы уже можете помочь в первом раунде; например, сказать «мы определенно не можем использовать это, потому что это означало бы ...»
В конце концов, юрист будет много знать о критических делах, но если вы можете немного помочь ...
Для участников OSS: знание некоторых различий между бесплатными лицензиями может иметь значение, если вам важно, что люди могут делать с ваш код (распространять? изменять? использовать в коммерческих приложениях? использовать в проприетарных приложениях?)
NOLO (я не работаю на них) издает хороший набор юридических инструкций для неспециалистов.
http://www.nolo.com/ products / a-legal-guide-to-web - & - software-development-SFT.html
Закон не похож на код. Это не очень четкий набор шагов и правил, которые можно было бы однозначно понять.
- Не работайте в стране, где больше юристов, чем разработчиков.
- Чрезвычайно большой процент всех патентов на программы (в США) являются фиктивными, но вы не можете платить или ждать они должны быть признаны недействительными.
- Если вы хотите использовать / разрабатывать программное обеспечение с открытым исходным кодом, используйте существующую лицензию и не изменяйте ее. Не приближайтесь к границам того, что должна означать лицензия.
Я всегда предполагал, что разработчики проекта хотят, чтобы любое программное обеспечение, использующее их работу, выпускалось под той же самой лицензией. Прочтите их часто задаваемые вопросы и юридические страницы для получения дополнительной информации и не стесняйтесь обращаться к разработчикам / сопровождающим, если вы все еще не уверены.
Если вам нужна помощь в понимании деталей лицензионного соглашения, поговорите с юристом.
Если вы фрилансер или подрядчик: убедитесь, что у вас есть хорошее страхование ответственности и вы знаете, что покрывается им.
Например, моя не покрывает ответственности за ошибки в коде, которые могут раскрыть номера кредитных карт. Так что я больше этого не трогаю!
В одном из ответов утверждалось, что закон не похож на код. Я не согласен.
Раньше IBM платила программистам инструкциями. (Кто-то из моих знакомых сказал, что он работал с программистом, который таким образом разбогател. Очевидно, этот парень не знал, как использовать индексный регистр машины; он написал процедуру нулевой памяти, которая вручную сохраняла ноль в каждом адресе памяти.)
Было также время (давно), когда адвокатам платили словом. Это помогло популяризировать такие практики, как обращение к людям как «наиболее уважаемые такие-то» и другие многословия.
Я только что прочитал ответ на SO, в котором говорилось, что VB.NET 2008 по-прежнему допускает номера строк ]. Вы все еще можете запускать чистый DOS на современном ПК. И есть большая доля правды в шутке о том, что все программы COBOL произошли от общего предка в результате постепенных изменений. Обратная совместимость и «исторические причины» широко распространены в нашей области
. Это сравнимо с областью права. Есть законы, которые вносят небольшие (или большие) изменения в другие законы. У вас что-то вроде адской зависимости. Есть некоторые нелепые исторические законы (в Хобарте, Тасмания, мужчинам запрещено носить женское платье после захода солнца, потому что когда-то осужденные наряжались женщинами и бранились за людей), о соблюдении которых никто и не мечтал, точно так же, как в программном обеспечении есть некоторые исторические особенности, которые больше никто не использует.
Законы часто имеют непреднамеренные последствия (ошибки!), используются творчески (взломы!), содержат лазейки (уязвимости в системе безопасности!), некоторые из них являются преднамеренными (бэкдоры!), модифицируются (исправления!) или отменяются (удаление!).
Да, законы (в отличие от кода) могут быть интерпретированы. Но я думаю, что это больше похоже на сопровождение кода. Это помогает приспосабливать законы к новым социальным нормам.
Если ответить прямо на вопрос: каждый разработчик должен знать, что закон скорее похож на смехотворно огромный программный проект, который разрабатывался сотни лет. (На самом деле, в каждой стране есть свой проект, и они решают проблемы по-разному.) Теоретически, прочитав лицензию, вы будете знать, что вы можете, а что не можете делать со своим кодом. Но если грамотный программист не может обнаружить все ошибки в своем коде, просто прочитав его,
Я не юрист, но со временем я собрал несколько практических правил от юридических лиц, которые вы можете использовать для экономии времени:
- Лицензия GPL - это «авторское право» или «вирусное». Это означает, что любой код, который вы пишете, который зависит от компонента GPL, также должен быть выпущен под GPL. Хорошее эмпирическое правило состоит в том, что если вам нужен компонент GPL для компиляции вашего программного обеспечения, ваше программное обеспечение должно выпускаться под лицензией GPL.
- Вы не обязаны делать свой исходный код доступным, если вы не распространяете свое программное обеспечение. Например, если вы запускаете программное обеспечение для внутренних целей или на веб-сервере, вам не нужно выпускать исходный код. Вот почему Google не нужно выпускать свое программное обеспечение, использующее библиотеки GPL. Это был ключевой момент в GPL v3.
- LGPL (библиотека или меньшая GPL) требует, чтобы вы использовали GPL свой собственный исходный код только в том случае, если вы включили библиотеку под LGPL таким образом, чтобы она стала незаменимой. Ваше собственное программное обеспечение не обязательно должно быть GPL, если вы только «используете» библиотеку. Включение файлов заголовков и связывание с
.dll/.soбиблиотеки - это один из способов "использования" кода LGPL без каких-либо обязательств, за исключением надлежащих авторских прав. уведомление. - Лицензия BSD (лицензия Apache очень похожа) позволяет создавать коммерческие расширения, использующие компонент с открытым исходным кодом. Вот почему Apple выбрала FreeBSD вместо Linux в качестве ядра для OSX.
- MPL очень дружественен к коммерции, потому что Netscape думала, что они могли бы заработать немного денег на Mozilla во время написания лицензии.
Часто помогает связаться с сопровождающим проекта Open Source. Они лучше всех могут посоветовать вам первоначальное намерение лицензии, а также свои собственные взгляды на открытый исходный код. Иногда сопровождающие готовы выпустить программное обеспечение под несколькими лицензиями, чтобы помочь вам. Часто это не так. Зависит от человека, владеющего авторскими правами.
В проекте KDE есть удобная матрица
Думаю, Юридическое руководство по веб-разработке и разработке программного обеспечения Стивена Фишмана Адвокат - это то, что вы ищете.
Обзор
Замечательная книга! Почти ответы любой юридический вопрос, который вы можете себе представить и некоторые вы никогда бы не подумали оф. - Джон Дворжак, PC Magazine
Охватывает все мыслимые детали. важно для столь быстро растущего и нематериальный носитель. - Предприниматель
Эта книга прошла мой личный тест. для юридических гидов - с более высокими оценками чем любое другое юридическое руководство. - Джефф Дантеманн, редактор, PC Techniques Журнал
Описание продукта
Защитите свои права и свой тяжелый труд!
Законы, касающиеся веб-сайтов и программного обеспечения разработки сложны и запутаны, но если не распутать их, это может стоить вам тысячи долларов гонорары адвокатам и судебные иски.
К счастью, Legal Guide to Web & Разработка программного обеспечения расшифровывает это сложная область права, основательно и на понятном для читателя английском языке. Это также предоставляет контракты, соглашения и юридические формы на CD-ROM, с пошаговая инструкция по заполнению их, так что вы можете защитить свои программное обеспечение и веб-сайт без оплаты выкуп адвоката.
Use Legal Guide to Web & Software Развитие, чтобы узнать:
- какая правовая защита вам нужна
- сильные стороны и ограничения каждого типа защиты
- как избежать нарушения
- какие положения вам понадобятся при составлении проекта соглашения
- как получить разрешение на использование чужих материалов
Вы найдете полное, пошаговое инструкции по составлению:
- трудовых договоров
- договоров с подрядчиками и консультантами
- договоров разработки
- лицензионных договоров
5-е издание Legal Guide to Web & Разработка программного обеспечения полностью обновлено, чтобы обеспечить последнее прецедентное право и изменения в законодательстве.
Некоторые другие предложения:
- Работа на себя: Закон и налоги для независимых подрядчиков, фрилансеров и консультантов (тот же автор).
- Консультант и независимые подрядные соглашения (тот же автор
- Руководство по лицензированию программного обеспечения Джеффри И. Гордон.
- Практическое руководство по лицензированию программного обеспечения для лицензиатов и лицензиаров Х. Уорда Классена.
- Карманное руководство по техническим контрактам: программное обеспечение и услуги Соглашения для продавцов, менеджеров по контрактам, разработчиков бизнеса и юристов Дэвида Толлена.
Вы должны знать основные права и обязанности лицензии, которую вы собираетесь использовать. Это не так сложно, и даже если их много, нужно внимательно читать только те, которые вы собираетесь использовать или трогать. Просто прочтите их, в большинстве случаев они довольно ясны.
Все, что вам может понадобиться, зависит от обстоятельств. Патентование? Товарные знаки? Если вам это нужно, скорее всего, вы работаете в компании и у вас есть юридический отдел, который сделает это за вас.