Что должен знать каждый разработчик о юридических вопросах? [закрытый]
сегодня у меня был неприятный сюрприз, узнав о некоторых последствиях лицензии GPL, в основном о том, что я не мог использовать ее так свободно, как я думал.
теперь я знаю.
что еще я должен знать, и более широко, что должен знать каждый разработчик о таких юридических вещах?
вы можете разделить сотрудников, фрилансеров, участников проектов с открытым исходным кодом (и т. д.) или дать более широкий ответ.
15 ответов:
двенадцать юридических соображений для разработки программного обеспечения
программное обеспечение защищено авторским правом, если оно доступно для широкой публики. Больше нет необходимости размещать уведомление об авторских правах на приложение или в исходном коде. Владельцем авторских прав является автор (ы) или компания, выплачивающая автор(ы).
авторское право на программное обеспечение может быть присвоено владельцем авторского права, или оно может быть сохранено владельцем и программным обеспечением может быть лицензирован для пользователя или пользователей владельцем.
библиотеки, используемые в разработке, вероятно, имеют ограничения в их использовании и распространении. GPL не делает библиотеку общественным достоянием, как и тот факт, что библиотека поставляется с платформой разработки. Вы должны прочитать и понять лицензию, прежде чем распространять свое приложение. Некоторые библиотеки требуют выплаты роялти, хотя это стало менее распространенным в последнее время годы.
патентные иски программного обеспечения-это дерьмовые побеги. Вы не должны, конечно, сознательно нарушают патент. Тем не менее, есть небольшой, но реальный шанс, что какая-то компания подаст в суд на вас за нарушение их патента. Это может произойти, даже если вы разрабатываете свое программное обеспечение самостоятельно, вы никогда не слышали о патенте, и патент охватывает технику, которая интуитивно очевидна и почти полностью не связана с вашим программным обеспечением. Там не много вы можете сделать, чтобы избежать этого, учитывая нынешнюю политику США, другие, чем покупать страховку. Хорошей новостью является то, что патентные тролли обычно подают в суд на крупные компании с большим количеством денег.
Если вы используете сотрудника или фрилансера для разработки программного обеспечения, вы должны четко указать в письменной форме, кому принадлежат авторские права на приложение, включая исходный код. Некоторые фрилансеры и контрактные компании-разработчики считают исходный код своей собственностью, оставляя компанию в зависимости от оригинала разработчик(ы). Это законно, если это в соглашении о развитии.
Если у вас есть сотрудник, который разрабатывает программное обеспечение" вне часов", вы должны дать понять, кто владеет этим программным обеспечением, и какое программное обеспечение сотрудник должен иметь возможность писать и распространять за пределами компании.
Если вы являетесь сотрудником или фрилансером, разрабатывающим программное обеспечение, вы должны четко указать, кто будет владеть авторскими правами на ваше приложение, прежде чем начать развитие. Кроме того, вы должны знать или уточнить, кому принадлежит программное обеспечение, которое вы пишете в свое время. Некоторые компании имеют положения в трудовых договорах, претендующие на право собственности на любое программное обеспечение, написанное разработчиком в период работы, будь то дома или на работе. Многие компании имеют неконкурентные положения в трудовых соглашениях, которые ограничивают программное обеспечение, которое сотрудник может производить для распространения за пределами компании. Иногда эти ограничения довольно широки.
A товарный знак-это имя или символ, а не само программное обеспечение. Если вы распространяете программное обеспечение, вы должны (а) убедиться, что ваше имя приложения и "Марка" или дизайн имени не "смутно похожи" с другими приложениями, и (Б) зарегистрировать свой товарный знак. Дата первого использования важна для разрешения конфликтов, поэтому вы должны документировать, когда приложение впервые используется в торговле.
когда вы называете приложение, проверьте наличие зарегистрированных товарных знаков, но также проверьте Google. Один заявка с первым использованием имени может быть в состоянии принять ваше имя и товарный знак после того, как ваша заявка будет успешной, даже если они не зарегистрировали товарный знак, и у вас есть.
когда вы используете или подписать контракт или соглашение, убедитесь, что обе стороны понимают это. В трудовом договоре упоминание любых потенциально чувствительных областей может предотвратить много проблем позже. В соглашении о разработке, если обе стороны знают, кому принадлежит исходный код, или кто отвечает за обновления, или кто отвечает за ремонт и т. д., зайдя в проект развития, то есть гораздо меньше вероятность судебного процесса после того, как заявка была завершена. В дистрибьюторском соглашении убедитесь, что дистрибьютор понимает ответственность и срок действия соглашения.
каждое нетривиальное приложение имеет ошибки (или "конструктивные соображения" :-)). Любое пользовательское соглашение или соглашение о распространении должно четко указывать, что вы являетесь не несет ответственности за ошибки программного обеспечения, и вы не можете ожидать, чтобы исправить все ошибки. Уточните, что изменения, исправления и обновления производятся по выбору (или с максимальными усилиями) разработчика, и уточните, кто платит за исправления и обновления.
даже после того, как вы проконсультируетесь с юристом о соглашениях о разработке и распространении программного обеспечения, вы должны прочитать соглашения от других компаний-разработчиков программного обеспечения и посмотреть, что придумали их юристы.
Я не юрист, и это не юридическая консультация.
Я не юрист, но со временем я собрал несколько эмпирических правил от юридических людей, которые вы можете использовать, чтобы сэкономить время:
- лицензия GPL-это "копия слева" или "вирусная". Это означает, что любой код, который вы пишете, который зависит от компонента GPL, также должен быть выпущен под GPL. Хорошее эмпирическое правило заключается в том, что если вам нужен компонент GPL для компиляции вашего программного обеспечения, ваше программное обеспечение должно быть выпущено под лицензией GPL.
- вы не обязаны предоставлять свой источник вы не распространяете свое программное обеспечение. Например, если вы запускаете программное обеспечение для внутренних целей или на веб-сервере, вам не нужно освобождать источник. Вот почему Google не нужно выпускать свое программное обеспечение, которое использует библиотеки GPL. Это была ключевая точка соперничества в GPL v3.
- LGPL (библиотека или меньшая GPL) требует от вас только GPL свой собственный исходный код, если вы включаете библиотеку LGPL-ed таким образом, что она становится незаменимой. Ваше собственное программное обеспечение не должно быть GPL если вы только "используете" библиотеку. В том числе заголовочные файлы и ссылки против
.dll/.soбиблиотеки является одним из способов вы можете "использовать" LGPL-ed код без каких-либо обязательств, за исключением надлежащего уведомления об авторских правах.- лицензия BSD (Лицензия Apache очень похожа) позволяет создавать коммерческие расширения, которые используют компонент с открытым исходным кодом. Именно поэтому Apple выбрала FreeBSD вместо Linux в качестве ядра для OSX.
- MPL очень коммерчески дружелюбный потому что Netscape думал, что они могли бы сделать некоторые деньги из Mozilla в то время, когда лицензия была написана.
это часто помогает связаться с сопровождающим проекта с открытым исходным кодом. Они находятся в лучшем положении, чтобы посоветовать вам о первоначальном намерении лицензии, а также свои собственные взгляды на открытый исходный код. Иногда сопровождающие готовы выпустить программное обеспечение под несколькими лицензиями, чтобы помочь вам. Часто это не так. Зависит от человека, который владеет авторское право.
проект KDE имеет удобная матрица
Я думаю юридическое руководство по разработке веб-и программного обеспечения Стивен Фишман адвокат - это то, что вы ищете.
комментарий
потрясающая книга! Ответы почти каждый юридический вопрос вы можете себе представить а некоторые вы бы никогда не подумали из. -- Джон Дворак, PC Magazine
охватывает все мыслимые детали важно, чтобы такой быстро растущий и нематериальная среда. -- Предприниматель
эта книга проходит мой личный тест для юридических гидов-с более высокими оценками чем любое другое юридическое руководство. -- Джефф Duntemann, редактор, PC Techniques Журнал
Описание Продукта
защитите свои права, и ваш тяжелый труд!
законы, охватывающие веб-сайт и программное обеспечение разработка сложна и запутанна, но если вы не распутаете их, это может стоить вам тысячи долларов в гонорары адвокатов и судебные иски.
к счастью, юридическое руководство по интернету & Разработка программного обеспечения декодирует это комплексная область права, основательно и на удобном для читателя английском языке. Оно также предусмотрены договоры, соглашения и юридические формы на CD-ROM, с пошаговая инструкция по заполнению они вне, поэтому вы можете защитить ваше программное обеспечение и веб-сайт без оплаты адвокатский выкуп.
используйте юридическое руководство по веб-и программному обеспечению Развития узнайте:
- какая правовая защита вам нужна
- сильные и слабые стороны каждого типа защиты
- как избежать нарушения
- какие положения вам нужны при составлении договора
- как получить разрешение на использование чужих материалов
вы найдете полный, шаг за шагом инструкции к проекту:
- занятость соглашения
- договоры подрядчика и консультанта
- соглашения о развитии
- лицензионное соглашение
5-е издание юридического руководства по Web & Разработка программного обеспечения полностью обновлено, чтобы обеспечить последнюю прецедентное право и изменения в уставе.
некоторые другие предложения :
- работа на себя: Закон и налоги для независимых подрядчиков, фрилансеров & Консультанты (тот же автор).
- Соглашения С Консультантами И Независимыми Подрядчиками (тот же автор).
- Руководство По Лицензированию Программного Обеспечения Джеффри И. Гордон.
- практическое руководство по лицензированию программного обеспечения для лицензиатов и лицензиаров по H. Ward Classen.
- The Tech Contracts Pocket Guide: соглашения о программном обеспечении и услугах для продавцов, менеджеров по контрактам, разработчиков бизнеса и Адвокаты Дэвид Tollen.
если фрилансер или подрядчик: убедитесь, что у вас есть хорошее страхование ответственности и знать, что скрывается под ней.
например, мой не покрывает ответственность за ошибки, сделанные в коде, который может раскрыть номера кредитных карт. Так что я больше не прикасаюсь к этой дряни!
для сотрудников: мы должны быть в состоянии дать первый раунд консультаций для ваших клиентов-как они/мы можем использовать компонент, который мы хотим, в своем приложении ?
для фрилансеров : мы должны быть в состоянии дать хороший совет для ваших клиентов, и выбрать компоненты, которые мы можем использовать для приложений, которые мы разрабатываем для них.
вы конечно, ваше слово не так хорошо, как Советы Адвоката может получить вас ; но вы уже можете помочь в первом раунде ; например, сказать "мы определенно не могу использовать это, потому что это будет означать..."
в конце концов, адвокат много знаю о случаях, но если вы можете помочь немного...
Для участников OSS: знание некоторых различий между свободными лицензиями может иметь значение, если вам важно, что люди могут делать с вашим кодом (распространять ? изменить ? использовать его в коммерческих целях ? использовать его в собственном приложении ? )
один ответ утверждал, что закон не похож на кодекс. Я не согласен.
в первые дни IBM платила программистам по инструкции. (Один мой знакомый сказал, что он работал с программистом, который таким образом разбогател. Очевидно, парень не знал, как использовать индексный регистр машины; он написал процедуру нулевой памяти, которая вручную сохраняла ноль в каждом адресе памяти.)
было также время (давным-давно), когда адвокатам платили словом. Это помогло популяризировать такие практики, как обращение к людям как "наиболее высоко почитаемые такие-то" и другие глаголы.
Я просто прочитал ответ на так что сказал VB.NET 2008 по-прежнему позволяет номера строк. Вы все еще можете запустить чистый DOS на современном компьютере. И есть много правды в шутке, что все программы COBOL происходят от общего предка путем постепенных изменений. Обратная совместимость и" исторические причины " широко распространены в нашей области.
Это сопоставимо с царством юридический. Есть законы, которые вносят небольшие (или большие) изменения в другие законы. У вас есть своего рода зависимость-ад. Есть некоторые нелепые исторические законы (в Хобарте, Тасмания, мужчине запрещено носить женское платье после захода солнца - потому что когда-то осужденные одевались как женщины и грабили людей), которые никто не мечтал бы применять, так же как есть некоторые исторические функции в программном обеспечении, которые больше никто не использует.
законы часто имеют непреднамеренные последствия (ошибки!), вам использовать в творческих целях (писаки!), содержат лазейки (уязвимости безопасности!), некоторые из которых являются преднамеренными (бэкдоры!), получить изменения (патчи!) или опрокинут (удаление!).
да, законы (в отличие от Кодекса) подлежат толкованию. Но я думаю, что это скорее похоже на обслуживание кода. Это помогает приспособить законы к новым социальным нормам.
чтобы ответить на вопрос напрямую: каждый разработчик должен знать, что закон скорее похож на смехотворно огромный программный проект, который находится в разработке уже сотни лет. (На самом деле у каждой страны есть свой проект, и они решают проблемы по-разному.) В теории, после прочтения лицензии, вы будете знать, что вы можете и не можете сделать с вашим кодом. Но если компетентный программист не может обнаружить все ошибки в своем коде, просто прочитав его, то какой шанс делает a Не-адвокат есть ли анализ угловых случаев и серых областей юридического документа?
Как с исходным кодом программного обеспечения, вы можете обычно суть юридического документа читая его, но если вам нужно знать что-то конкретное, профессиональное.
NOLO (я не работаю на них) публикует хороший набор юридических книг для непрофессионала.
http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
Я бы ответил на это так же, как я бы ответил: "что должен знать каждый адвокат о программировании?-То есть знайте, что вы не можете знать глубинное поле достаточно хорошо, чтобы делать больше, чем самые простые вещи. Найди эксперта.
вы должны знать основные права и обязанности лицензия, которую вы собираетесь использовать. Это не так сложно, и даже если их много, нужно внимательно читать только те, которые вы собираетесь использовать. Просто прочитайте их, в большинстве случаев они достаточно ясны.
все остальное вам может понадобиться, ну, это зависит. Патентование ? Товарные знаки ? Если вам нужны эти вещи, скорее всего, вы находитесь в компании и есть юридический отдел, чтобы сделать это за вас.
Я всегда предполагаю, что разработчики проекта хотят, чтобы любое программное обеспечение, использующее их работу, было выпущено под той же лицензией. Прочитайте их часто задаваемые вопросы и юридические страницы для получения дополнительной информации и не стесняйтесь обращаться к разработчикам/сопровождающим, если вы все еще не уверены.
Если вы хотите помочь понять детали лицензионного соглашения, поговорите с адвокатом.
- Не работайте в стране, где больше юристов, чем разработчиков.
- чрезвычайно большой процент всех (американских) патентов на программное обеспечение являются фиктивными, но вы не можете платить или ждать их аннулирования.
- Если вы хотите использовать/разрабатывать программное обеспечение с открытым кодом, использовать существующую лицензию и не изменять его. Не приближайтесь к границам того, что должна означать лицензия.
6.Если у вас есть сотрудник, который разрабатывает программное обеспечение "вне часов", вы должны дать понять, кто владеет > этим программным обеспечением, и какое программное обеспечение сотрудник должен уметь писать и распространять вне компании.
право на свободу слова, как указано в большинстве конституций (esp. если разработчики делают бесплатный s / w off-the-clock) может сделать такие условия терпят неудачу в судах