Юридические последствия использования открытого кода (Open Source)
Использование свободного или открытого кода при разработке нового программного обеспечения является распространенным, практически повсеместным явлением в современной IT индустрии. Такой код выгоден как разработчикам, так и заказчикам, поскольку значительно экономит время, силы и средства на разработку новых продуктов. При этом, использование свободного или открытого кода имеет свои юридические правила и последствия, которые могут существенно влиять на дальнейшую судьбу софта.Эта статья обязательна к прочтению всеми разработчиками и девелоперами, которые в своей работе используют открытый код, а также потенциальным заказчикам программного обеспечения.
Что такое открытый код (Open Source) с точки зрения права?
Следует сразу отметить, что в данной статье мы будем рассматривать под открытым кодом (Open Source) большую группу свободных (Free Software) и открытых кодов (Open-Source Software) без разделения на отдельные подкатегории, т.к. для целей этой статьи такое разделение несущественно.
Учебный стенд FUSE по кондиционерам и отопителям hvac school
Любой открытый код доступен для просмотра, изучения использования или изменения, и, как правило, размещается в открытых публичных репозиториях вместе с информацией о возможном применении и условиях использования. Именно условия использования таких кодов представляют наибольший интерес с точки зрения права, поскольку авторы открытого кода не отказываются от своих прав, а предоставляют его другим на условиях открытых лицензий.
Существует большое разнообразие видов лицензий на открытый код, и различия между ними являются очень существенными. Тем не менее, в подавляющем большинстве случаев есть одно крайне важное требование всех лицензиатов – упоминание об использовании этого открытого кода (например, в формате Third Party Software Attribution Notice) и включение в текст конечной лицензии определенных условий.
Далее мы более детально поговорим про эти обязательства, и как правильно организовать работу с открытым кодом, поскольку последствия от невыполнения условий лицензии на открытый софт могут быть не менее серьезны, чем от нарушения условия любой другой лицензии.
Сбор информации про весь открытый код, используемы при разработке ПО
Главным условием, которое позволит вам избежать последующих сложностей при использовании открытого кода, является скрупулёзный сбор информации про весь открытый код, используемый при работе над вашим софтом.Разумеется, реализовать это могут только сами разработчики, поскольку только они знают, какие именно открытые коды были использованы при работе над программным обеспечением. Если вы являетесь заказчиком софта, то в контрактах с разработчиками следует обязательно включать пункт о том, что разработчики должны передать вам информацию о всех открытых кодах, использованных ими в работе. Разумеется, такое обязательство должно сопровождаться описанием ответственности за его нарушение, иначе в нем теряется всякий смысл.
Ethical Hacking в стиле Mr. Robot — На информатике этому не научат | CTF #0
Как правило, такая информация передается в отдельном приложении к договору о разработке, и оформляется в виде таблицы с указанием названия открытого кода, ссылки на репозиторий, из которого такой код взят, и типа лицензии, на основании которой открытый код был размещен его автором.
Информация о названии лицензии, как и сам текст лицензии, в подавляющем большинстве случаем содержится в том же репозитории в виде текстового файла TXT или в формате Word. Само название файла может быть разным, но, как правило это классические названия Readme или License.
Идентифицировать весь открытый код, использованный в разработке вашего софта – важнейший этап, от которого зависит вся дальнейшая работа с производным кодом, т.е. тем самым софтом, который вы в итоге разработали или получили. Крупные IT компании даже проводят отдельную экспертизу кодов, чтобы убедиться в том, что был указан весь использованный открытый код и ничего не пропущено.
Анализ лицензий на открытый код, использованный при разработке ПО
Ранее мы уже упоминали о том, что существует большие разнообразие лицензий на открытый код, и отличия между ними могут быть довольно существенными. Среди наиболее популярных можно выделить такие типы лицензий как MIT, BSD, Apache 2.0, GNU GPL и т.д. – их очень много.
Не вдаваясь в детали каждой отдельно-взятой лицензии, стоит выделить два основных вида таких лицензий — copyleft-лицензии и permissive-лицензии.
Поскольку большинство программ разрабатываются с целью их дальнейшего использования для получения выгоды, то их заказчикам стоит избегать использования copyleft-лицензий, и вот почему. Сopyleft-лицензии (например, лицензии GPL) предусматривают, что любой производный код (в частности, конечній код вашей программы) должен быть открытым для общественности на условиях GPL-лицензии, и при передаче прав на его использование необходимо прикладывать GPL-лицензию, уведомление об авторском праве и файл с открытым исходным кодом.
Таким образом, используя открытый код на основе copyleft-лицензии вы автоматически теряете возможность получить производный код в свое полное распоряжение и контролировать его последующее коммерческое использование.
Permissive-лицензии позволяют распространять производный код на условиях других лицензий, так что при разработке ПО они пользуются большей популярностью. В тоже время, использование открытого кода по Permissive-лицензии не означает отсутствие дополнительных требований, таких как упоминание ей автора и т.д.
Таким образом, сбор информации и анализ типов лицензий, используемых при разработке вашего софта, стоит проводить всем, кто использует открытый софт в своей работе, и для этого следует привлечь профессиональных юристов, которые смогут дать рекомендации по дальнейшему составлению конечной лицензии и использованию вашего софта.
Источник: vc.ru
Open Source
Open Source — это программное обеспечение, которое поставляется для конечного пользователя с открытым исходным кодом. То есть приложение можно доработать под свои задачи без нарушения авторских прав разработчиков исходного ПО. Решение распространяется под лицензиями GNU/Linux, MIT и др.
Само понятие возникло как альтернатива проприетарному ПО, когда коммерческие компании закрывали доступ к исходному коду.
Особенности
Программное обеспечение, распространяемое как Open Source продукт, обладает рядом особенностей:
- Программные продукты поставляются абсолютно бесплатно до конечного потребителя.
- Разрабатываются разными людьми, которые сами его используют. Они внимательно отслеживают код программы, оперативно устраняя ошибки или уязвимости, которые могут привести к критическим последствиям.
- Большинство продуктов Open Source совместимы с разными семействами операционных систем, то есть они кроссплатформенные.
- Сообщество разработчиков свободного ПО открыто для обратной связи от пользователей. Каждый из них может внести предложение по улучшению или добавлению новой функции.
- Обновление Open Source решений происходит гораздо чаще, чем коммерческих продуктов. Конечный пользователь получает актуальные исправления мгновенно, как только они фиксируются.
- Активное развитие свободного ПО оживляет конкуренцию среди коммерческих организаций, что способствует повышению качества последних.
- В качестве коммерческой основы разработчики используют в своих решениях опцию донейшен. То есть пользователи могут по собственному желанию поддержать программистов финансовыми средствами путем перевода на электронный кошелек.
- Большинство Open Source решений создаются под операционные системы семейства Unix/Linux, что снижает риск заражения компьютера или сервера вирусом. Это связано с тем, что вредоносное ПО в основном пишется под Windows.
Примеры
Среди наиболее известных продуктов с открытым исходным кодом отмечают WordPress — система управления контентом на сайтах. Все возможности продукта поставляются для пользователя бесплатно. В качестве языка программирования использовался PHP, база данных — MySQL.
Бесплатная альтернатива Microsoft Office — OpenOffice. Возможности ПО идентичны, а интерфейс очень похож.
Язык программирования PHP основан на скриптах. Он используется для большинства веб-приложений и динамических сайтов.
GIMP представляет собой альтернативу коммерческому продукту Adobe Photoshop. Функции и возможности полностью идентичны коммерческому решению.
Mozilla Firefox разработан на движке Quantum, распространяется по умолчанию во многих дистрибутивах Linux как основной браузер в ОС.
Open Source решения поставляются как альтернатива коммерческому ПО, но бесплатно. Разработчики создают качественный продукт, что способствует конкуренции на рынке программного обеспечения. При желании пользователи могут самостоятельно доработать исходный код Open Source продуктов под свои задачи.
Источник: itglobal.com
Как поучаствовать в Open Source проекте? 8 ответов новичку
Как поучаствовать в разработке Open Source проектов, какова их роль и что они могут дать вам как разработчику?
Начнём с того, что гордое название «Open Source» носят проекты с открытым исходным кодом, которые чаще всего разрабатываются и поддерживаются силами сообщества. Это значит, что устройство и принцип работы таких проектов прозрачны, а в разработке может принять участие любой желающий.
Участие в Open Source проектах — это возможность усовершенствовать свои навыки, создавая при этом что-то новое или улучшая уже существующее. При этом не имеет значения, изучаете вы основы PHP или являетесь продвинутым C++ разработчиком — открытых проектов уйма, на любой вкус и цвет. Начинающие программисты могут не только пополнить багаж знаний, научиться работать с чужим кодом и получать фидбек от опытных программистов, но также пополнить портфолио первой серьёзной работой.
Разбираемся, как поучаствовать в Open Source проекте и не ударить в грязь лицом.
Чем может быть полезен Open Source?
Тут всё зависит от ваших целей и задач. Кто-то начинает работать с Open Source, чтобы глубже изучить определённый технологический стек, кто-то — потому что сам использует тот или иной инструмент в работе и считает, что может его улучшить. Кто-то, как мы в ABBYY в случае с нашей библиотекой NeoML, сначала создаёт инструмент для решения внутренних задач, а потом понимает, что от его выхода в Open Source выиграет и компания, и сообщество. Есть разные пути — решите, какой из них больше подходит именно вам.
Иван Ямщиков , AI-евангелист в ABBYY
Работа в Open Source может дать много, если подойти к ней с умом. Навык чтения чужого кода здорово выпрямляет руки, работа с кураторами подтянет английский. А чувство, что вы приложили руку к крупному проекту (которых в Open Source достаточно), может неплохо смотивировать вас в карьерном плане.
Антон Немкин , председатель совета фонда Цифровая долина Сочи
Как найти Open Source проект?
Для участия в Open Source проекте самое главное — определиться со сферой собственных интересов. Это крайне важно, так как вам предстоит выбрать проект, максимально подходящий под ваши интересы и компетенции. Делается это просто. Крупнейший сайт с проектами — это Github. Там вы делаете поисковый запрос по ключевым словам, соответствующим интересам, например «javascript gamification framework».
В ответ получаете список проектов, в каждом из которых вы можете поучаствовать.
Никита Буйда , основатель и ведущий разработчик Datebox.app
Очевидный ответ, который напрашивается, — зайти на GitHub. Уже на месте стоит определиться с тематикой, хотя бы с точностью до крупной области. Затем погуглить, что есть на сайте на этот счёт.
Новичку я бы посоветовал обратить внимание на GitHub Trending, где постят небольшие проекты.
Начать просто: найдите проект, который вам по зубам, и предложите свои доработки.
Вообще, нередко кураторы идут навстречу новичкам и охотно разъясняют, что упрощает процесс работы.
Антон Немкин , председатель совета фонда Цифровая долина Сочи
На что обращать внимание при выборе проекта?
Обратите внимание на ПО, которым пользуетесь сами: во-первых, вы уже знакомы с проектом как пользователь и хорошо понимаете, что стоит улучшить или изменить; во-вторых, вы будете вносить вклад в то, что важно для вас.
- Описание проекта — интересен ли он вам? Решает ли важную (интересную) проблему? Актуальна ли тема?
- Популярность проекта. На Github это можно оценить по количеству звёзд — местному аналогу лайка.
- Посмотрите на раздел с проблемами (issues): много ли там открытых и особенно закрытых проблем? Это поможет оценить простор для творчества.
- Изучите часть описания проекта, относящуюся к сторонним разработчикам (contributing). Там, как правило, описывается простой способ, как настроить среду разработки под этот конкретный проект и прислать свои изменения. Иногда просто пишут «pull requests are welcome», то есть «ждём не дождёмся ваших исправлений и предложений».
- Насколько давно были сделаны последние изменения в проекте, активно ли идёт разработка? Если да, то ваши изменения быстро рассмотрят и, возможно, примут. Если не активно — быть может, вы захотите взять продвижение проекта в свои руки?
- Есть ли активное комьюнити? Часто у проекта может быть чат, форум или группа в соцсети, где разработчики активно обсуждают проект. Кроме того, активность можно посмотреть в комментариях к проблемам и предлагаемым изменениям.
Никита Буйда , основатель и ведущий разработчик Datebox.app
Успех взаимодействия, конечно, зависит не только от разработчика. Важно, как выстроены процессы в команде, какая рабочая атмосфера, есть ли у нового специалиста возможность использовать именно тот стек технологий, который ему интересен. При обсуждении любых вопросов в команде, в чатах не должно быть токсичности — эффективна только конструктивная критика.
Источник: tproger.ru
На англоязычном сайте указано что программа опен соурс что это значит
JavaRush — это интерактивный онлайн-курс по изучению Java-программирования c нуля. Он содержит 1200 практических задач с проверкой решения в один клик, необходимый минимум теории по основам Java и мотивирующие фишки, которые помогут пройти курс до конца: игры, опросы, интересные проекты и статьи об эффективном обучении и карьере Java‑девелопера.
Подписывайтесь
Язык интерфейса
Скачивайте наши приложения
Этот веб-сайт использует данные cookie, чтобы настроить персонально под вас работу сервиса. Используя веб-сайт, вы даете согласие на применение данных cookie. Больше подробностей — в нашем Пользовательском соглашении.
Источник: javarush.com
Open Source: мифы, вопросы безопасности и особенности использования
Эксперт британской разведки: “Нет никаких объективных оснований полагать, что открытый код лучше проприетарного, равно как и наоборот”
Некоторые наблюдатели, подвергая критике ПО с открытым исходным кодом, в качестве потенциальной угрозы для безопасности называют значительную базу разработчиков Open Source. По мнению Иена Леви, технического директора одного из департаментов британской разведывательной службы GCHQ, ответственной за ведение радиоэлектронной разведки и обеспечение защиты информации органов правительства и армии, такая точка зрения лишена оснований. Эксперт полагает, что когда речь заходит о безопасности, то между ПО с открытым исходным кодом и проприетарным софтом можно поставить знак равенства.
На недавно состоявшейся в Лондоне конференции Open Source, Open Standards Леви попытался развеять существующие мифы об открытом ПО, заодно выделив подлинные проблемы в области легитимности и безопасного использования софта Open Source.
Мифы
Открытое ПО более (или менее) безопасно, нежели проприетарное
“Нет никаких объективных оснований полагать, что открытый код лучше проприетарного, равно как и наоборот”, — говорит Леви. С его точки зрения, безопасность программного кода является лишь частью более широкого круга вопросов безопасности. Эксперт ратует за то, что наиболее правильным подходом организаций к выбору открытого софта является определение базовых требований к безопасности ПО и лишь затем поиск программ, удовлетворяющих этим требованиям.
Открытость программного кода делает его безопасным “по умолчанию”
Предполагается, что поскольку Open Source открыт для всех, то сомнения в его небезопасности безосновательны. Леви это предположение считает неверным хотя бы потому, что мало кто настолько компетентен, чтобы судить о безопасности ядра Linux, содержащего 21 млн. строк кода. “Много глаз — это по большей части просто много ресниц, и ничего более”, — шутит он.
Открытый исходный код легко модифицировать для злонамеренных целей
“Это заблуждение. Поведенческий анализ создателей вредоносного софта свидетельствует о том, что они не используют исходный код напрямую, предпочитая работу с интерактивным дизассемблером IDA Pro. Это средство позволяет находить уязвимости посредством анализа работы программы, превращая её бинарный код в ассемблерный текст независимо от того, открытый ли у неё код или закрытый”, — говорит Леви.
Открытый софт хуже, потому что код для него может писать любой желающий
Это верно лишь отчасти: для некоторых общедоступных проектов код можно писать по желанию, в то время как разработкой кода для других проектов Open Source занимаются профессиональные программисты. Чтобы уменьшить риск установки низкокачественного или опасного ПО, в любом случае не будет лишним изучить историю проекта с открытым кодом, советует Леви.
Открытое ПО означает его беспрепятственное использование
“ПО с открытым исходным кодом вовсе не означает, что оно свободно от ограничений. Эти ограничения предусматриваются условиями лицензирования GPL либо более умеренными требованиями BSD-лицензий. Таким образом, лицензионные условия на Open Source не обязательно будут распространяться конкретно на вашу организацию, но они существуют”, — предупреждает эксперт. Как пример Леви привел инструмент для распределенных вычислений и хранения данных Hadoop, который упоминается в качестве проекта с открытым исходным кодом: “Это запатентованный алгоритм. Его можно использовать бесплатно, но сам алгоритм запатентован, поэтому его реализация в виде отдельного проекта невозможна”.
Весь софт должен проходить аудит с точки зрения его безопасности
Это не реализуемо чисто технически, так что гарантией безопасности софта может служить лишь соблюдение базовых правил безопасности, считает Леви.
Вероятные опасности при использовании Open Source
Скачивание открытого софта по Сети
Распространением ПО онлайн занимаются многие проекты с открытым кодом, из-за чего конечные пользователи рискуют вместо подлинного софта скачать его подмену, содержащую вредоносный код. “Нет никаких гарантий, что при скачивании софта алгоритм криптографического хеширования SHA-1 и цифровая подпись к нему отправляются одним и тем же сервером распространения. К тому же нападения на серверы, распространяющие софт, случались уже неоднократно, и хоть они и не коснулись исходного кода, но затронули бинарный, MD5, SHA-1 и PGP”, — говорит Леви.
Патчи
Ситуация с происхождением кода повторяется и в том случае, когда исправления безопасности для ПО пользователи получают с открытых источников. “Заходя в центр обновления Windows, вы вправе полагаться на многоуровневый механизм аутентификации, который исключает всякую возможность подмены. Эквивалентную защиту предложит и Red Hat. В то же время нет уверенности, что под видом HTTP-серверов для распространения Open Source не могут скрываться недобросовестные источники вредоносного софта”, — продолжает специалист разведслужбы.
Эксплуатация уязвимостей
“Как и в случае с проприетарным софтом, патчи для Open Source являются необходимым источником устранения уязвимостей. По своей сути они же являются краеугольным камнем для его безопасности. К примеру, если в продукте обнаружена уязвимость, но бинарный патч для её устранения выложен в открытом доступе, то злоумышленникам не составит большого труда декомпилировать его код и найти источник уязвимости для его последующей эксплуатации. Собственно, безопасный источник исправлений для открытого софта позволит на порядок уменьшить риски его заражения вредоносным кодом”, — делится своими размышлениями Иен Леви. Эксперт говорит, что во многих открытых проектах есть отдельные лица или целые группы, активно отслеживающие ошибки в коде, что может привлекать к этим устаревшим ошибкам внимание злоумышленников: “Выложенные на всеобщее обозрение потенциальные уязвимости “нулевого дня” изрядно упрощают хакерам задачи по созданию эксплойтов, так как патчей для них не существует даже в проекте”.
Аудит открытого кода
Как узнать, кто написал код для интересующего вас open-source-софта? Иными словами, как получить уверенность, что даже если код заимствован, он не нарушает ничьих прав? Особенно данные вопросы актуальны для организаций, поэтому перед импортированием модулей ПО целесообразно усилиями штатных юристов и инженеров провести аудит открытого софта на предмет его лицензионной чистоты, советует Леви.
“Эффект индивидуальности”
В чём привлекательность коммерческого софта для предприятий? Ответ очевиден: фирменный бренд, гарантированная поддержка на протяжении длительного времени, как правило, обеспечиваемая штатом квалифицированных инженеров, в то время как в случае с проектами Open Source, которые подчас ведутся несколькими разработчиками, не всегда можно рассчитывать на своевременную консультацию по требуемым вопросам, не говоря уже о том, что между руководителями некоторых открытых проектов нередко возникали размолвки и разногласия, приводившие к их закрытию либо к смене направления деятельности, отмечает Леви.
Отношения с разработчиками
Степень безопасности открытого софта иногда можно оценить по косвенным признакам, особенно если чётко представлять себе, является ли интересующий вас open-source-проект перспективным для разработчиков. “Оценка безопасности открытого проекта не всегда упирается в код. Любой, кто думает, что в каждой строчке кода его поджидает уязвимость, глубоко заблуждается.
Существуют не менее животрепещущие вопросы типа: имеют ли разработчики долгосрочные планы по поддержанию своего софта? Планируется ли регулярный выход патчей безопасности? Есть ли у них план управления инцидентами? Не собираются ли они радикальным образом изменить дизайн софта или политики безопасности? То есть взаимоотношения с разработчиками помогут вашей организации снизить бизнес-риски при использовании проекта”, — говорит Леви.
Идентификация разработчика
В то время как коммерческая компания может иметь несколько слоев для идентификации разработчика: по Сети, корпоративный идентификатор, техническое удостоверение для проверки исходного кода, — процесс идентификации некоторых разработчиков, занятых в open-source-проектах, может представлять собой некоторые сложности. Особое внимание стоит обратить на ситуации, когда для поддержания связи разработчик указывает бесплатную почту типа Gmail. “Многие ли захотят доверить безопасность своей компании почтовому аккаунту?” — вопрошает эксперт.
Источник: www.itweek.ru