Что каждый разработчик должен знать о правовых вопросах?

Сегодня У меня был плохой сюрприз, узнав о некоторых последствиях лицензии GPL, в основном, что я не мог использовать ее так свободно, как я думал.

Теперь я знаю.

Что еще я должен знать и более широко, что каждый разработчик знает о таких юридических вещах?

Вы можете разделить сотрудников, фрилансеров, участников проектов с открытым исходным кодом (и т.д.) или дать более широкий ответ.

Ответ 1

Двенадцать юридических аспектов разработки программного обеспечения

  • Программное обеспечение защищено авторским правом, если оно доступно для широкой публики. Больше не нужно размещать уведомление об авторском праве в приложении или в исходном коде. Владельцем авторских прав является автор или компания, оплачивающая автора (ов).

  • Авторские права на программное обеспечение могут быть назначены владельцем авторского права или могут быть сохранены владельцем, и программное обеспечение может быть лицензировано пользователем или пользователями владельцем.

  • Библиотеки, используемые в разработке, вероятно, имеют ограничения в их использовании и распространении. GPL не делает общедоступным библиотеку, а также тот факт, что библиотека поставляется с платформой разработки. Вы должны прочитать и понять лицензию, прежде чем распространять свое приложение. Некоторые библиотеки требуют роялти, хотя в последние годы это стало менее распространенным явлением.

  • Патентные иски программного обеспечения - это дерьмовые побеги. Разумеется, вы не должны сознательно нарушать патент на программное обеспечение. Тем не менее, есть небольшой, но реальный шанс, что какая-то компания будет судиться с вами за нарушение своего патента. Это может произойти, даже если вы разрабатываете свое программное обеспечение самостоятельно, вы никогда не слышали о патенте, и патент охватывает технику, которая интуитивно очевидна и почти полностью не связана с вашим программным обеспечением. Существует не так много, чтобы избежать этого, учитывая текущие политики USPTO, кроме страхования на покупку. Хорошей новостью является то, что патентные тролли обычно подают в суд на крупные компании с большим количеством денег.

  • Если вы используете сотрудника или внештатного сотрудника для разработки программного обеспечения, вы должны четко указать, кто владеет авторским правом на приложение, включая исходный код. Некоторые фрилансеры и компании по разработке контрактов считают исходный код своей собственностью, оставляя компанию зависимой от первоначального разработчика (разработчиков). Это является законным, если оно находится в соглашении о разработке.

  • Если у вас есть сотрудник, который разрабатывает программное обеспечение "круглосуточно", вы должны четко указать, кто владеет этим программным обеспечением, и какое программное обеспечение должен иметь сотрудник, чтобы писать и распространять за пределами компании.

  • Если вы являетесь сотрудником или разработчиком программного обеспечения для фрилансеров, вы должны четко указать, кто будет владеть авторским правом на ваше приложение, прежде чем вы начнете разработку. Кроме того, вы должны знать или разъяснять, кому принадлежит программное обеспечение, которое вы пишете в свое время. Некоторые компании имеют положения в трудовых соглашениях, претендующие на право собственности на любое программное обеспечение, написанное разработчиком в период работы, будь то дома или на работе. Многие компании имеют неконкурентные положения в трудовых соглашениях, которые ограничивают программное обеспечение, которое может производить сотрудник для распространения за пределами компании. Иногда эти ограничения довольно широки.

  • Товарный знак - это имя или символ, а не само программное обеспечение. Если вы распространяете программное обеспечение, вы должны (а) убедиться, что ваше имя приложения и "отметка" или дизайн имени не являются "схожим образом" с другими приложениями и (б) зарегистрируйте свой товарный знак. Дата первого использования важна для разрешения конфликтов, поэтому вы должны документировать, когда приложение впервые используется в торговле.

  • Когда вы называете приложение, проверяете зарегистрированные товарные знаки, но также проверяете Google. Приложение с первым использованием имени может использовать ваше имя и товарный знак после успешной подачи заявки, даже если они не зарегистрировали товарный знак и у вас есть.

  • Когда вы используете или подписываете контракт или соглашение, убедитесь, что обе стороны это понимают. В трудовом соглашении упоминание любых потенциально чувствительных областей впереди может предотвратить множество проблем позже. В соглашении о развитии, если обе стороны знают, кто владеет исходным кодом или кто отвечает за обновления, или кто несет ответственность за обслуживание и т.д., Входя в проект разработки, то вероятность того, завершено. В соглашении о дистрибуции убедитесь, что дистрибьютор понимает обязанности и срок действия соглашения.

  • У каждого нетривиального приложения есть ошибки (или "соображения дизайна":-)). В любом пользовательском соглашении или соглашении о дистрибьюции должно быть ясно, что вы несете ответственность за программное обеспечение без ошибок, и вы не можете исправить все ошибки. Проясните, что изменения, исправления и обновления выполняются по выбору (или лучшим образом) разработчика и дают понять, кто платит за исправления и обновления.

  • Даже после того, как вы консультируетесь с адвокатом о соглашениях о разработке и распространении программного обеспечения, вы должны ознакомиться с соглашениями других компаний-разработчиков программного обеспечения и узнать, что придумали их адвокаты.

  • Я не юрист, и это не юридическая консультация.

Ответ 2

В случае сомнений обратитесь к адвокату.

Ответ 3

Я не юрист, но со временем я собрал несколько эмпирических правил от юридических лиц, которые вы можете использовать, чтобы сэкономить время:

  • Лицензия GPL - "copy-left" или "viral". Это означает, что любой код, который вы пишете, который зависит от компонента GPL, также должен быть выпущен под GPL. Хорошее эмпирическое правило: если вам нужен компонент GPL для компиляции вашего программного обеспечения, ваше программное обеспечение должно быть выпущено под лицензией GPL.
  • Вы не обязаны предоставлять свой источник, если вы не распространяете свое программное обеспечение. Например, если вы запускаете программное обеспечение для внутренних целей или на веб-сервере, вам не нужно освобождать источник. Вот почему Google не нужно выпускать свое программное обеспечение, использующее библиотеки GPL. Это была ключевая спорная точка в GPL v3.
  • LGPL (Library или Lesser GPL) требует только GPL собственного исходного кода, если вы включаете библиотеку LGPL-ed таким образом, чтобы она стала незаменимой. Ваше собственное программное обеспечение не обязательно должно быть GPL, если вы используете только библиотеку. Включение заголовочных файлов и привязка к библиотеке .dll/.so является одним из способов использования кода LGPL-ed без каких-либо обязательств, за исключением надлежащего уведомления об авторских правах.
  • Лицензия BSD (лицензия Apache очень похожа) позволяет создавать коммерческие расширения, использующие компонент с открытым исходным кодом. Именно поэтому Apple выбрала FreeBSD поверх Linux как ядро ​​для OSX.
  • MPL очень коммерчески дружелюбен, потому что Netscape подумал, что они могут сделать некоторые деньги из Mozilla на момент написания лицензии.

Часто помогает связаться с разработчиком проекта с открытым исходным кодом. Они находятся в лучшем положении, чтобы посоветовать вам о первоначальном намерении лицензии, а также о своих собственных взглядах на открытый исходный код. Иногда разработчики готовы выпустить программное обеспечение под несколькими лицензиями, чтобы помочь вам. Часто это не так. Зависит от лица, которому принадлежит авторское право.

В проекте KDE есть удобная матрица

Ответ 4

Я думаю, Юридическое руководство по веб-разработке и разработке программного обеспечения Стивеном Фишманом. То, что вы ищете.

alt text

Обзор

Удивительная книга! Ответы почти каждый юридический вопрос, который вы можете себе представить и некоторые вы бы никогда не думали из. - Джон Дворак, журнал PC

Охватывает все мыслимые детали важно для такого быстро растущего и неосязаемой среде. - Предприниматель

Эта книга проходит мой собственный личный тест для юридических гидов - с более высокими отметками чем любое другое юридическое руководство. - Джефф Duntemann, редактор, техника ПК Журнал

Описание продукта

Защитите свои права и тяжелую работу!

Законы, охватывающие веб-сайт и программное обеспечение развитие сложное и запутанное, но если вы не распутываете их, это может стоить вам тысячи долларов в адвокатских сборов и судебных процессов.

К счастью, Legal Guide to Web & Разработка программного обеспечения расшифровывает это сложная область права, тщательно и в удобном для читателя английском языке. Это также предоставляет контракты, соглашения и юридические формы на CD-ROM, с пошаговые инструкции для заполнения их, поэтому вы можете защитить свои программного обеспечения и веб-сайта без выкупа адвоката.

Использовать юридическое руководство для Интернета и программного обеспечения Развитие для изучения:

  • какая юридическая защита вам нужна
  • Сильные стороны и ограничения каждого типа защиты
  • как избежать нарушения.
  • какие положения вам нужны при составлении соглашения
  • как получить разрешение на использование материалов других людей.

Вы найдете полный, шаг за шагом инструкции для черновика:

  • трудовые соглашения
  • договоры подрядчика и консультанта
  • соглашения о развитии
  • лицензионные соглашения

Пятое издание Юридического руководства по веб-интерфейсу и разработка программного обеспечения полностью обновлено, чтобы обеспечить прецедентное право и законодательные изменения.

Некоторые другие предложения:

Ответ 5

Если фрилансер или подрядчик: убедитесь, что у вас есть хорошее страхование ответственности и знаете, что покрывало его.

Например, моя компания не несет ответственности за ошибки, допущенные в коде, которые могут выставлять номера кредитных карт. Поэтому я больше не прикасаюсь к этому материалу!

Ответ 6

Для сотрудников: мы должны быть в состоянии дать первый раунд консультаций вашим клиентам - например, можем ли мы/использовать компонент, который мы хотим, в своем приложении?

Для фрилансеров: мы должны быть в состоянии дать крепкие советы вашим клиентам; и выберите, какие компоненты мы можем использовать для приложений, которые мы разрабатываем для них.

Конечно, ваше слово не так хорошо, как советы, которые может получить адвокат; но вы уже можете помочь в первом раунде; например, сказать: "мы определенно не можем использовать это, потому что это будет означать..."
В конце концов, адвокат будет много знать о случаях в углу, но если вы можете немного помочь...


Для участников OSS: знание некоторых различий между бесплатными лицензиями может иметь значение, если вам небезразлично, что люди могут делать с вашим кодом (перераспределять? Изменять? Использовать его в коммерческом приложении? Использовать его в проприетарном приложении?)

Ответ 7

Один ответ утверждал, что закон не похож на код. Я не согласен.

В первые дни IBM платила программистам по инструкции. (Кто-то, кого я знал, сказал, что он работал с программистом, который получил богатый этот способ. Очевидно, парень не знал, как использовать индекс машинного индекса, он написал программу с нулевым размером памяти, которая вручную хранила нуль в каждом адресе памяти.)

Было также время (давно), когда адвокаты были оплачены этим словом. Это помогло популяризировать такие практики, как обращение к людям как "наиболее высоко оцененные такие-то" и другие многословия.

Я только что прочитал ответ на SO, который сказал, что VB.NET 2008 все еще позволяет номера строк. Вы все еще можете запускать чистую DOS на современном ПК. И в анекдоте есть много правды о том, что все программы COBOL будут отклонены от общего предка путем инкрементных изменений. Обратная совместимость и "исторические причины" распространены в нашей области.

Это сопоставимо с сферой права. Существуют законы, которые делают небольшие (или большие) изменения в других законах. У тебя какая-то зависимость - ад. Есть некоторые нелепые исторические законы (в Хобарте, Тасмания, это незаконно для мужчины, чтобы носить женское платье после захода солнца, потому что когда-то какое-то время осужденные одевались как женщины и люди с кружками), о которых никто не мог мечтать, есть некоторые исторические особенности в программном обеспечении, которое больше никто не использует.

Законы часто имеют непреднамеренные последствия (ошибки!), используются в творческих целях (хаки!), содержат лазейки (уязвимости безопасности!), некоторые из которых являются преднамеренными (backdoor!), становятся модифицированными (патчи!) или опрокидываются ( деинсталляция!).

Да, законы (в отличие от кода) подлежат интерпретации. Но я думаю, что это похоже на обслуживание кода. Это помогает приспособить законы к новым социальным нормам.

Чтобы ответить на вопрос напрямую: каждый разработчик должен знать, что закон скорее похож на смехотворно огромный программный проект, который разрабатывался уже сотни лет. (На самом деле каждая страна имеет свой собственный проект, и они решают проблемы по-разному.) Теоретически, после прочтения лицензии вы будете знать, что вы можете и не можете сделать с вашим кодом. Но если компетентный программист не может определить все ошибки в своем коде, просто прочитав его, то какой шанс у не-адвоката есть анализ угловых дел и серых областей юридического документа?

Как и исходный код программного обеспечения, вы обычно можете получить суть юридического документа, прочитав его, но если вам нужно знать что-то конкретное, спросить профессионала.

Ответ 9

Я бы ответил на это так же, как я бы ответил: "Что должен знать каждый юрист о программировании?" То есть знайте, что вы не можете знать глубину поля достаточно хорошо, чтобы делать больше, чем простейшие вещи. Получить эксперта.

Ответ 10

Вы должны знать основные права и обязанности лицензии, которую собираетесь использовать. Это не так сложно, и даже если их много, вам нужно внимательно прочитать только те, которые вы собираетесь использовать или прикоснуться. Просто прочитайте их, в большинстве случаев они понятны.

Что-нибудь еще, что вам может понадобиться, ну, это зависит. Патентование? Торговые марки? Если вам нужны эти вещи, есть вероятность, что вы находитесь в компании и имеете юридический отдел, чтобы сделать это за вас.

Ответ 11

Я всегда предполагал, что разработчики проекта хотят, чтобы любое программное обеспечение, использующее свою работу, было выпущено под той же лицензией. Прочтите их часто задаваемые вопросы и юридические страницы для получения дополнительной информации и не стесняйтесь обращаться к разработчикам/сопровождающим, если вы все еще не уверены.

Если вам нужна помощь в понимании деталей лицензионного соглашения, обратитесь к адвокату.

Ответ 12

  • Не работайте в стране с большим количеством юристов, чем разработчики.
  • Крайне большой процент всех патентов на программное обеспечение (США) является фиктивным, но вы не можете платить или ждать, пока они будут признаны недействительными.
  • Если вы хотите использовать/разрабатывать программное обеспечение с открытым исходным кодом, используйте существующую лицензию и не изменяйте ее. Не приближайтесь к границам того, что подразумевается под лицензией.

Ответ 13

Имя хорошего адвоката IP.

Ответ 14

6.Если у вас есть сотрудник, который разрабатывает программное обеспечение "круглосуточно", вы должны четко указать, кто владеет > этим программным обеспечением, и какое программное обеспечение должно выполнять сотрудник, чтобы писать и распространять вне компании.

право на свободу слова, как указано в большинстве конституций (например, если разработчики делают бесплатные s/w круглосуточно), могут сделать такие условия неудачными в суде

Ответ 15

Закон не похож на код. Это не отлитый набор шагов и правил, которые могут быть однозначно поняты.