Программное обеспечение с открытым исходным кодом

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

Бесплатное программное обеспечение (Freeware)

Впервые термин «freeware» появился в 1982 году, его зарегистрировал в качестве товарного знака американский программист Андрю Флеглеман (Andrew Flegleman) для разработанной им коммуникационной программы.

Бесплатно можно скачать:

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

Достоинство freeware одно - не надо платить деньги, недостатков немного больше:

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

Практически любая коммерческая программа под Windows имеет свои бесплатные аналоги:

  • Архиваторы (7-Zip)
  • ПО для работы с FTP (FileZilla)
  • Антивирусы (CureIt, Avast!, AVZ)
  • Текстовые редакторы (Notepad++)
  • Браузеры (Mozilla, Firefox, Opera, GoogleChrome)
  • Аудиоплееры (WinAmp)
  • Видеоплееры (VLC, Miro, Media Player Classic)
  • Транскодеры (MediaCoder)
  • Графические редакторы (GIMPshop)
  • Офисное ПО (Apache OpenOffice, LibreOffice)

Бесплатные приложения под Windows доступны в Интернете на сайтах разработчиков. После скачивания архива и установки ПО на компьютере автоматически формируются все необходимые для нормальной работы приложения каталоги и файлы в них. Бесплатные приложения для Android и iOS можно скачать при помощи маркетплейсов PlayStore и AppStore.

Скачивая бесплатные программы, вы рискуете столкнуться с эффектом «троянского коня»: разработчик включает в бесплатно распространяемый пакет другие программы, которые автоматически размещаются на компьютере при установке пакета. Не всегда это ПО безопасно!

Особое место в категории бесплатных программ занимают проекты open source. Часть из вышеперечисленного ПО (Mozilla Firefox, 7-Zip, FileZilla, Notepad++, Miro, VLC, Apache OpenOffice, LibreOffice, Media Player Classic, GIMPshop, Google Chrome) относится именно к этой категории.

Open Source ПО

Программное обеспечение может распространяться с закрытым исходным кодом (Microsoft Windows, MS Office – проприетарное ПО), и с открытым кодом (open source). Появившийся в 1984 году термин «free software» (свободное программное обеспечение) относится к ПО, которое можно бесплатно получить, модифицировать, используя доступные исходные тексты программ, и распространять дальше.

Программы распространяются по лицензии GNU GPL и должны удовлетворять следующим требованиям:

  1. Нет ограничений на использование ПО в определенных областях деятельности.
  2. Исходный код распространяется вместе с исполняемым модулем или его можно получить из доступного источника бесплатно/по умеренной цене. Код должен быть читаемым.
  3. Модифицированная версия распространяется на общих условиях. Допускается изменение названия или номера версии.
  4. Программа доступна всем желающим.

В 1998 году было введено понятие «open source software» – ПО с открытым кодом. Формально, все свободное программное обеспечение можно считать ПО с открытым кодом. Принято относить программы open source к бесплатным, хотя не запрещено их использовать в коммерческих целях. Обычно, оно распространяется по лицензии Apache 2.0. Но есть и другие варианты (подробнее о лицензиях в мире open source см. ).

Преимущества работы с проектами open source:

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

Недостатки:

  • для компиляции могут потребоваться дополнительные библиотеки, которые придется искать в Интернете
  • если возникнут вопросы при использовании этого ПО, ответ нужно будет искать на форумах в Интернете.

Концепция Open Source основана на повышении надежности и качества ПО за счет обнаружения и исправления ошибок многими пользователями. Находящийся в открытом доступе open source проект постоянно тестируется огромным количеством программистов.

Давно широко внедряет технологию «открытого кода» компания Google. Все ее проекты такого типа, их примерно 200 (изначально и Kubernetes был разработан здесь, а затем передан под управление Cloud Native Computing Foundation), доступны на портале компании GOOGLE OPEN SOURCE. На ресурсе лежат не только коды программ, но и документация по их использованию и поддержке. Насколько широко можно использовать открыто предоставляемый код - указано в лицензии, обычно непосредственно размещаемой в тексте программы.

Компания Apple, открыв исходные коды языка Swift, пытается увеличить количество доступных приложений для Apple. Текущая версия языка на настоящий момент имеет ограничения: чтобы загрузить свою разработку на AppStore, придется приобрести лицензированный Swift. Вся необходимая по языку информация размещена на сайте swift.org и в облачном хранилище GitHub. Выпущен релиз Swift под Linux.

Условно-бесплатное программное обеспечение

Некоторые программы, распространяемые бесплатно, имеют ограничения:

  • по сроку работы
  • по количеству запусков
  • по функциональности

Для ограничения срока работы и числа запусков используется trial-защита – специальные счетчики. В качестве ограниченного по функционалу ПО предоставляют демо-версию или версию с ограниченным сервисом. Иногда разработчик вставляет в код программы рекламу, затрудняющую работу с пакетом. Чтобы избавиться от рекламного баннера, придется заплатить.

Примеры программ с лицензией shareware:

  • Архиватор WinRAR (30 дней)
  • Антивирус Nod32 (30 дней)

AcrobatReader – пример программы, ограниченной по функционалу. Эта программа, нижний сегмент пакета AdobeAcrobat, разрешает только просмотр PDF-файлов. Для полноценной работы с файлами таких типов необходимо купить более полную версию Acrobat’a.

Крупные разработчики бесплатно предоставляют свои продукты для личного пользования в целях изучения. Если их ПО планируется использовать в коммерческих целях, необходимо покупать лицензию.

Например, компания Oracle бесплатно позволяет скачивать дистрибутив СУБД и утилиты для работы с ней. При этом накладываются ограничения на объем массива обрабатываемых данных. Но для изучения принципов работы с базой данных и отработки навыка написания процедур этот вариант работы с ПО подходит.

Собственно, скачивая «исходники» открытого ПО - open source - вы должны быть готовы понести определенные затраты, чтобы его использовать. Не надо приобретать лицензию, но потребуется оплатить работу программистов, которые будут создавать на его основе программные продукты под определенную задачу.

Выводы

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

Устанавливая бесплатное программное обеспечение, обращайте внимание на дату его создания/обновления и обязательно проверяйте ПО на наличие вирусов. Такими программами пользуются как IT-специалисты, так и пользователи ПК разного уровня.

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

Несомненным достоинством open source проектов является их независимость от вендора, крупные компании предпочитают на их основе создавать корпоративное ПО. Особенно это становится актуальным для госкорпораций в связи с возможными сложностями в приобретении проприетарных продуктов из-за экономических санкций. Сдерживающим фактором при внедрении open source является некоторая неопределенность, связанная с информационной безопасностью: возможны проблемы при прохождении сертификации в ФСТЭК.


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

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

Существует несколько критериев соответствия для программ с открытым исходным кодом:

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

Рассмотрим один из самых ярких примеров программного обеспечения, которое сопровождает открытый исходный код, получивший всемирное распространение. В начале 90-х годов прошлого века финский студент Линус Торвальдс разработал абсолютно новую операционную систему, основанную на Unix, которая известна сегодня как Linux . Система была выпущена под лицензионным соглашением GNU General Public License , где содержалось определение открытого исходного кода с юридической точки зрения. Довольно большое количество программистов стало использовать и совершенствовать эту операционную систему. Собрав доработки от программистов по всему миру в единое целое, в 1994 году Линус Торвальдс выпускает Linux версии 1.0. До этого нумерация версий велась начиная в нуля.

Со временем появилась некая всеобщая обеспокоенность потребителей, касающаяся отсутствия гарантии, а также технической поддержки подобного программного обеспечения. Поэтому компания Red Hat Software создает официальный программный пакет Official Red Hat Linux, который им удается продавать. Наиболее значительной особенностью такой продаваемой операционной системы стало наличие гарантии и технической поддержки , что немаловажно.

Некоторые другие компании также занимались разработкой новых версий Linux, предназначенных для продажи, причем эти пакеты были дополнительно укомплектованы различным программным обеспечением , среди которого: интернет-браузер Mozilla, созданный на ядре Netscape, веб-сервер Apache, язык для подготовки веб-сценариев Perl, формат графических файлов PNG и многие другие. Кроме того, существуют версии перечисленных программных пакетов, разработанные для операционной системы Windows и Android. Это говорит о том, что программы с открытым кодом доступны не только для компьютеров, но и мобильных устройств.

Подводя итог, стоит сказать, что программы, с которыми в комплекте идет их открытый исходный код, имеют ряд минусов. Прежде всего это многообразие версий , в результате которого доработка одной программы может вызвать создание нового независимого программного пакета. Второе, что нужно подчеркнуть, - это использование пользователями устаревших программ , в которых могут быть не устранены некоторые ошибки, нет возможности работать с новыми форматами файлов и так далее. Примером такого случая можно назвать программы Microsoft Word и Open Office. Если в первом пакете будет записана какая-нибудь сложная формула, то второй просто-напросто не сможет ее прочитать.

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

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

Марк Робертс (Mark Roberts)
Директор по управлению продукцией (Director, Product Management)
компании QNX Software Systems
e-mail: [email protected]

Аннотация

Основное внимание в данной статье концентрируется на преимуществах, стратегических моментах, возникающих препятствиях и возможностях, связанных с использованием в коммерческой продукции программ с открытым исходным кодом. Используя в качестве примера интегрированную среду разработки (Integrated Development Environment - IDE) на базе платформы Eclipse, мы обсудим, какие отличия существуют между защитными (protective) и незащитными (nonprotective) лицензиями на исходный код программного обеспечения (ПО). При интеграции или компоновке открытого исходного кода с "фирменным" закрытым кодом зачастую требуется проявлять надлежащее внимание и осторожность. Следует иметь в виду и различные правовые проблемы, например, потенциальную возможность нарушения патентных прав. Мы также попытаемся объяснить, почему основные принципы использования ПО с открытым исходным кодом в среде информационных технологий (ИТ) не применимы в отношении коммерческой продукции для встраиваемых устройств.

Среда разработки QNX Momentics как пример использования ПО с открытым исходным кодом

Возвращаясь в 2001 г., когда многие фирмы-разработчики боролись за выживание в условиях всеобщего обвала рынка акций ИТ-компаний, особенно связанных с электронным бизнесом в Интернет, компания QNX Software Systems приняла стратегическое решение начать разработку новой интегрированной среды разработки (IDE) для рынка встраиваемых систем. У компании уже был солидный опыт по разработке серии инструментальных средств, используемых в разработке встраиваемых устройств, но руководство компании осознавало, что создание среды IDE позволит удержаться на гребне волны в условиях жесткой конкуренции. Решение о создании среды IDE стимулировалось также сменой акцентов в требованиях клиентов. В период спада деловой активности стесненные в средствах клиенты стали больше интересоваться решениями, которые могли бы максимизировать продуктивность работы и сделать их более мобильными (гибкими) при ведении работ, позволили бы повысить общую экономическую эффективность.

Для компании QNX разработка среды IDE была "ставкой на будущее", так как в то время стоимость и усилия на разработку проекта были вне зоны досягаемости для большинства вендоров инструментальных средств встроенных систем. К счастью, QNX работала в тесном контакте с IBM по различным сегментам рынка встроенных устройств. Благодаря тесному сотрудничеству, компания IBM поделилась с QNX своими планами по выпуску интегрированной среды разработки с использованием открытого исходного кода - эта среда впоследствии стала основой для платформы Eclipse.

Компания IBM предложила использовать опыт QNX для адаптации технологии IDE к нуждам разработчиков, занимающихся созданием встраиваемых приложений на базе языка C/C++. Специалисты компании QNX практически сразу указали на неопровержимые привлекательные стороны использования для среды IDE открытых исходных кодов. Например, для такой среды стало бы возможно:

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

И наконец, рассматривалась отдельная возможность того, что платформа IDE смогла бы завоевать популярность и стать стандартом "де факто", а это позволило бы компании QNX с помощью такой платформы захватить для использования рынок больших экосистем разработчиков и инструментов третьих сторон.

Основание открытого проекта Eclipse.org

В ноябре 2001 г. компании Borland, IBM, Merant, QNX Software Systems, Red Hat и SUSE основали Консорциум Eclipse. В начале 2004 г. Совет Управляющих (Board of Stewards) реорганизовал Консорциум Eclipse в некоммерческую корпорацию с именем Eclipse Foundation.

С самого начала Eclipse была проектом, действительно основанным на использовании открытого исходного кода. В рамках проекта предлагались как безвозмездно распространяемые технологии в виде открытых исходных текстов, так и возможность доступа к сообществу, состоящему из наиболее образованных и продвинутых разработчиков в своей области. Таким образом, данная технология оказалась универсальной платформой для интеграции всех видов инструментов разработки. В ее основе лежит открытая расширяемая архитектура, при этом она совершенно четко лицензируется как свободно распространяемый продукт, не требующий лицензионных отчислений. Вклад членов сообщества в проект Eclipse основан на стандартной модели разработки с открытым исходным кодом (Open Source Software - OSS), но большинство членов предлагают также и коммерческие разработки, основанные на платформе Eclipse.

Проект создания инструментального хранилища

В декабре 2001 г. компания QNX начала создание своей ОСРВ QNX® Neutrino®, базирующейся на среде IDE платформы Eclipse. В представлении компании среда IDE должна была обладать большими функциональными возможностями, ориентироваться на работу с языками C/C++, иметь глубоко интегрированные инструменты для отладки, профилирования, анализа и создания встраиваемых приложений. С самого начала, по замыслу команды QNX, это должна была быть многоцелевая и многоязычная среда IDE, поддерживающая множество инструментальных платформ. Сюда было включено:

  • несколько инструментальных платформ: Windows, Solaris, ОСРВ QNX Neutrino (разработка “сама для себя” - "self-hosted");
  • несколько целевых архитектур: ARM, MIPS, PowerPC, SH-4, x86;
  • языки программирования C, C++, Java.

С тех пор среда IDE продолжала разрастаться, включив в себя поддержку платформы Linux и поддержку дополнительных процессорных архитектур, включая процессоры XScale.

Реализация проекта была запущена в стиле "экстремального программирования". В компании была отобрана команда из 12 лучших инженеров. Им было предоставлено специальное помещение, их изолировали от всех отвлекающих внимание факторов, проект был отдан в их полное распоряжение.

Группе были даны необходимые полномочия в сфере принятия решений, для них было составлено жесткое, на грани риска расписание работ, с выпуском бета-версии продукта через 16 недель, а коммерческой версии -к 4 июля 2002 г. Группа уложилась во все поставленные контрольные сроки и выпустила новый продукт - получивший имя QNX Momentics® IDE - точно в соответствии с расписанием, что явилось свидетельством заложенного в программное обеспечение с открытым исходным кодом потенциала по сокращению времени выхода продукции на рынок.

От идеи до поставки продукта - менее 7 месяцев

Опираясь на платформу Eclipse, команда QNX завершила создание очень мощной и многосторонней среды IDE для разработки встраиваемого ПО за шесть месяцев. В среде IDE поддерживалась кросс-платформенная разработка для нескольких инструментальных платформ и нескольких языков программирования, а также поддерживались наиболее популярные процессорные платы для встраиваемых целевых устройств. С помощью платформы Eclipse компания QNX смогла:

  • использовать для кросс-разработки компиляторы GNU и инструменты для работы через командную строку;
  • осуществить поддержку подключаемых модулей сторонних разработчиков, например, IBM WebSphere для встраиваемых приложений Java и Rational ClearCase для модельно-управляемых разработок;
  • создать дополнительные инструменты для построения систем, управления целевыми устройствами, анализа памяти, профилирования систем и приложений и т.д.

На рис. 1 дан пример того, как при использовании платформы Eclipse происходит сокращение затрат на создание среды IDE, что дает возможность компаниям обратить основное внимание на верхние уровни разработки, где собственно и создаются реальные новшества. Например, с помощью платформы Eclipse компания QNX смогла легко создать несколько инновационных средств визуализации, которые позволяют проникнуть глубоко внутрь встраиваемой системы и отобразить ее поведение.

Обратный вклад в работу сообщества

Сильная сторона успешного проекта с открытым исходным кодом заключена в совместной работе сообщества разработчиков и в постоянном улучшении кодовой базы. Если компания принимает на вооружение и с пользой применяет открытый исходный код, то она просто обязана вносить свой вклад в работу сообщества. С этой целью компания QNX в июне 2002 г. взяла на себя руководство проектом Eclipse CDT.

Целью проекта Eclipse CDT (C/C++ Development Tools - инструменты разработки для языков C/C++) является создание общего набора взаимодействующих друг с другом инструментальных средств языков C/C++ для платформы Eclipse. Eclipse CDT был позиционирован как проект с открытым исходным кодом, с правами на управление со стороны корпорации Eclipse. Для запуска проекта CDT компания QNX передала для использования свои ресурсы для разработки и исходные коды проекта QNX Momentics IDE. Компании Rational и Red Hat как члены сообщества также оказали существенную поддержку проекта.

Рис. 1. При использовании платформы Eclipse вендоры инструментальных средств могут сконцентрировать внимание на верхнем уровне стека работ, где собственно и создаются реальные новшества.

Компания QNX по-прежнему ведет сопровождение проекта CDT, объем которого вырос с изначально скромных 80 000 строк кода до сегодняшних более чем 700 000 строк. В начале 2006 г. по журналу регистрации хода работ по проекту Eclipse CDT вклад компании QNX оценивался в 52%. Далее шла компания IBM со вкладом 36%. Проект CDT является вторым по популярности проектом корпорации Eclipse после собственно самой платформы Eclipse.

Можно ли себе позволить "подарить" код?

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

Более того, вы могли бы получить некоторый контроль над направлением развития "стандартной" платформы - заработанный, конечно, благодаря вашим заслугам перед сообществом! Если вы сопровождаете некоторый проект, ведите себя как хороший гражданин сообщества, уважайте чужое мнение, цените вклад и советы других членов. Не надо думать, что кто-то попытается "обчистить ваши карманы" в результате использования кода и перехватить у вас руководство над направлением развития платформы.

К примеру, стратегия компании QNX Software Systems состоит в том, чтобы использовать преимущества от участия в работе корпорации Eclipse, разрабатывая в то же время новые функциональные возможности, подключаемые через стандартизованные точки расширения, которые уже имеются в составе платформ Eclipse и CDT. С этой целью компания QNX намерена оставаться активным членом сообщества Eclipse, извлекая выгоду из существующей кодовой базы и наработок третьих сторон (подключаемых модулей), помогая в удовлетворении реальных потребностей клиентов, создавая свои фирменные расширения. Описанная стратегия иллюстрируется на рис. 2.

Рис. 2. Своими наработками можно делать вклад в работу сообщества.

Резюме по преимуществам

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

Выгода разработчиков заключается в уменьшении времени до поставки их продукции на рынок и в возможности воспользоваться результатами исследований других людей (при низких затратах на это). Среди этих результатов может присутствовать и высококачественный код, относящийся к категории "чистой интеллектуальной собственности" ("clean IP"), предоставленный уважаемыми фирмами, такими как IBM и QNX. Еще одним преимуществом для разработчика является то, что он получает простую и ясную схему лицензирования, включая коммерческие права и некоторую патентную защиту. Более того, разработчик получает возможность работы на платформах нескольких ОС, поддерживаемых в Eclipse, а также получает в свое распоряжение хорошо определенные в проекте Eclipse точки расширения.

Выгода клиентов, покупающих среду IDE на базе Eclipse, состоит в использовании инструментальной платформы, предназначенной для разработки встраиваемых приложений, с мощной поддержкой средств кросс-компиляции, простой отладкой и наличием расширений для управления целевыми системами. Команда разработчиков клиента сможет по достоинству оценить многие функции, облегчающие работу, малое время, требующееся на дополнительное обучение, хорошую производительность продукта и надежную платформу, позволяющую работать с большими проектами. Клиент может также с пользой применить платформу Eclipse в своих собственных приложениях (например, RCP, eRCP и т.д.).

Будущее корпорации Eclipse

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

Рис. 3. Корпорация Eclipse является энергичным и быстро растущим сообществом разработчиков подключаемых модулей.

Сравнение лицензий на открытый исходный код

Не все лицензии на ПО с открытым исходным кодом являются равноправными. Компания QNX сделала хорошо продуманный шаг, остановившись на лицензии Eclipse Public License. Этот выбор был продиктован частично потребностями ее клиентов, использующих встраиваемое оборудование, а частично желанием установить контроль над технологиями, дифференцирующими продукцию (и извлечь из этого выгоду).

Некоммерческая корпорация Open Source Initiative () предложила полезное, состоящее из 10 пунктов определение открытого исходного кода. В настоящее время на веб-сайте представлено более 50 одобренных OSI лицензий, включая Eclipse Public License. В этих лицензиях могут содержаться значительные отличия, которые нужно четко осознавать. Эти отличия могут существенно воздействовать на интеллектуальную собственность (ИС) разработчиков и на способность ее защиты. В наибольшей степени это относится к случаю использования открытого исходного кода (или производных разработок на базе открытого исходного кода) во встраиваемых устройствах.

Защитная и незащитная лицензия

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

Примерами незащитных лицензий являются оригинальные лицензии MIT и BSD. Незащитные лицензии сохраняют в силе авторские права владельца, но предоставляют широкие права пользователю, включая право на модификацию и неограниченное свободное распространение (или личное использование) ПО.

Что понимается под "вирусной лицензией"

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

Вопросы получения компенсаций

В последнее время вопросы возмещения потерь за нарушение прав ИС (IP Indemnification) стали для разработчиков главной темой обсуждения. В ответ на это некоторые вендоры открытого исходного кода объявили о том, что они будут защищать клиентов от судебных исков, связанных с нарушениями патентных или авторских прав. И в самых новых лицензиях на открытый исходный код разъясняются меры наказания для пользователей, которые пытаются отстаивать свои патентные права в отношении других пользователей кодовой базы.

Главные проблемы, возникающие при коммерциализации ПО с открытым исходным кодом

Сравнение встраиваемых и ИТ-приложений

Успеху сферы открытого исходного кода способствовало принятие ИТ-организациями ОС Linux. Выгода от использования Linux была связана с работой на относительно однородном и стабильном оборудовании (обычно семейства x86) и с использованием гибкой, богатой ресурсами компьютерной платформы.

Со встраиваемым ПО дела обстоят совсем по-другому. Это ПО запускается на огромном числе устройств с фиксированным набором функций, при этом используется широкий диапазон оборудования с разнообразной архитектурой. Разработчики встраиваемых устройств часто основывают свои конкурентные преимущества на конкретном наборе функций, габаритных параметрах, производительности, стоимости, времени работы от батарей, надежности, способности взаимодействия с другими устройствами и расширяемости. Эти отличительные функции обычно реализуются на низкоуровневом ПО, что в случае Linux требует компоновки непосредственно к ядру ОС. Настройка низкоуровневого ПО под потребности клиента является нормой, а не исключением, поэтому разработчики часто добиваются нужных им функциональных возможностей за счет изменения ядра ОС. Используется также метод прямой компоновки путем внедрения в кодовые фрагменты с целью уменьшения издержек на создание библиотек. Такая практика, рассматриваемая в совокупности, делает весьма трудным защиту фирменного кода на условиях лицензий типа GPL (общедоступных).

Обычно эти проблемы лицензирования не касаются ИТ-приложений, поскольку фирменное, связанное с конкретным предприятием ПО не распространяется дальше предприятия, используясь исключительно для внутренних нужд. Если же взять встраиваемые устройства, то через них всегда распространяется производное ПО, по отношению к которому срабатывает статья “force open” (принудительно открытый код) лицензий на открытый исходный код, что может подвергать риску главные аспекты ценных предложений с открытым исходным кодом.

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

Проблемы лицензирования

Неопределенность правового статуса

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

Некоторые обходные пути, которые позволяют вендорам коммерческой продукции внедрить в Linux "фирменные" драйверы (например, Loadable Kernel Modules - загружаемые модули ядра), основываются скорее на аргументах типа "он сказал, она сказала", чем на прямых ссылках на текст лицензионного соглашения. Фактически такие драйверы, которые используют модули LKM, таят в себе опасный обход требований лицензии GPL. Впадая в крайность, можно интерпретировать дело так, что кодовая база Linux может быть представлена как бесполезная для большинства практических применений, если в неё не включены некоторые из этих самых "фирменных" драйверов. Такая ситуация способна достаточно эффективно обесценить идею лицензии GPL.

Отсутствие компенсаций при нарушении прав ИС

В большинстве случаев использования открытого исходного кода существует реальная возможность того, что вы непреднамеренно нарушите чьи-либо патентные права. Лишь в малой части лицензий на открытый исходный код делается явная ссылка на патенты, а по подразумеваемым лицензиям нельзя выносить какое-либо решение. Вы должны отдельно лицензировать любые патенты, касающиеся, например, кодеков из категории открытого исходного кода, в которых реализованы алгоритмы MP3 или другие запатентованные решения. А тем временем, "плохие мальчики" (и Microsoft в том числе) озабочены созданием портфолио из патентов, которыми, по представлению многих экспертов, можно будет "выстрелить" по сторонникам открытого исходного кода.

В некоторых лицензиях есть явные ссылки на патенты. Например, в лицензии Eclipse Public License есть явное упоминание о патентных правах, и в ней содержится пункт о мерах наказания в случае, если кто-то попытается отстаивать патентные права по-другому. Корпорация Eclipse прилагает также много усилий для проверки кода и выяснения источника его происхождения с точки зрения лицензионных, патентных или авторских прав.

Дополнительные усилия для сохранения ИС

Для использования открытого исходного кода компания должна затратить значительные усилия в следующих направлениях:

  • управление распространением продукции;
  • управление лицензиями;
  • разрешение правовых конфликтов в части обязательств клиентов;
  • уделение надлежащего внимания правовым вопросам: соблюдение чистоты прав ИС, проверка прав ИС на открытый код, установление источника происхождения кода, отслеживание изменений в версиях лицензий, например, GPL v3 и т.д.

Принятие требований клиента

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

Проблемы, связанные с ИС

Затрагивают ли условия вашей лицензии на использование открытого исходного кода ту интеллектуальную собственность, которая является отличительной чертой вашего продукта? Если да, то ваша ИС находится под угрозой.

Если во встраиваемых системах используется смесь ПО вашей собственной разработки и программ с открытым исходным кодом, то вы должны представлять суть, происхождение и взаимосвязь всех компонентов встраиваемого ПО. Без такого глубокого проникновения в суть предмета вы можете непреднамеренно нарушить права чьей-нибудь ИС или даже потерять права на ПО собственной разработки.

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

Как показывает пример использования среды QNX Momentics IDE, для ПО с открытым исходным кодом существует много мгновенно получаемых преимуществ, включая сокращение времени до выпуска продукции на рынок, меньшие затраты на разработку и большую свободу по наделению вашего продукта дополнительными функциями и инновациями. Если вы предлагаете ваше ПО в виде услуги, которая решает некоторую проблему клиента, то клиенту безразлично, использовали вы или нет программы с открытым исходным кодом, он просто платит за полученную необходимую ему функцию.

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

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

И, наконец, присоединяйтесь к сообществу пользователей и разработчиков ПО с открытым исходным кодом для извлечения для себя максимальной пользы и выгоды!

Программное обеспечение с открытым кодом имеет своих почитателей, а в последнее время если речь заходит о разработке каких-то «национальных» продуктов, так в основном open-source и подразумевают. Парадоксально, но интерес к этому виду программного обеспечения породил массу искажений и заблуждений, которые на практике мешают его распространению.

Наша компания участвует в открытых проектах с 2005 года – и благодаря разработке собственных open source решений (проекты OpenVZ , CRIU), участвуя в других открытых проектах (QEMU , OpenStack , libvirt , libcontainer , и т.д.). За 10 лет мы собрали несколько наиболее распространённых мифов об открытом программном обеспечении. Я расскажу про каждое из заблуждений и объясню, почему оно ошибочно. Наверняка, вы вспомните еще столько же, но, на мой взгляд, эти пять самые «адовые».


Проект с открытым исходным кодом это открытый проект.

Любой программный проект состоит из множества артефактов: исходный код проекта, информация о неисправленных дефектах, исходный код тестов, документация. Исходный код проекта - это только его часть, свободный доступ к которой не даёт права называть весь проект открытым. Помимо исходного кода, свободный доступ должен быть открыт и к другим артефактам разработки, и чем больше артефактов открыто, тем больше проект открыт для контрибьюторов (людей, которые захотят сделать вклад в проект). Помимо этого, необходимы прозрачные процессы между всеми участниками сообщества, открытые коммуникации в проекте и т.д. Все эти меры будут только способствовать развитию проекта и плодотворному сотрудничеству участников сообщества.

Качество открытого ПО хуже, потому что код для него может писать любой желающий

Главный принцип открытого ПО – открытая совместная разработка – сам по себе является залогом того, что некачественный код, костыли и заплатки попросту невозможно будет скрыть от других участников. Человек, участвуя в такого рода проектах, готов к тому, что его работа будет подвергнута и анализу, и критике, а, значит, халтурить не будет. На кону его репутация, а её терять никто не хочет.

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

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

Отдельно стоит упомянуть, что компании, которые разрабатывают продукты на базе открытых проектов, в ходе тестирования заинтересованы в улучшении кода открытых проектов, которые они используют. Поэтому все обнаруженные проблемы необходимо исправлять и добиваться, чтобы это исправление было добавлено в основную ветку проекта, чтобы иметь как можно меньше отличий в своём коде и коде открытого проекта. Наши продукты используют код других открытых проектов, поэтому проблемы, найденные в коде этих проектов, мы исправляем и отправляем в upstream. Так было с уязвимостями в ядре RHEL: Red Hat отметил Владимира Давыдова за обнаружение серьезных уязвимостей CVE-2014-0203 и CVE-2014-4483 в одном из обновлений ядра RHEL6 (вторая проблема, кстати, была найдена с помощью одного из наших автоматических тестов, использующих Linux Test Project). Василий Аверин получил благодарность за обнаружение ошибки CVE-2014-5045 , Дмитрий Монахов – за CVE-2012-4508 . Факт хорошего тестирования Linux-ядра был даже отмечен Эндрю Мортоном (кто это?): “Мне интересно. За последние несколько месяцев люди из @openvz.org нашли (и исправили) кучу непонятных, но серьезных и довольно древних багов. Как вы обнаружили эти баги?”

Итог

На самом деле все перечисленные мифы возникают по большей части у пользователей, которые либо только начинают работать с OpenSource ПО, либо не пробовали этого делать вообще. Лучший способ избавиться от предубеждений – начать вплотную работать с такими решениями.
Мы недавно новой версии нашего продукта Virtuozzo 7. Если вы также заинтересованы в создании лучшей технологии контейнерной виртуализации, то

Программное обеспечение с открытым кодом имеет своих почитателей, а в последнее время если речь заходит о разработке каких-то «национальных» продуктов, так в основном open-source и подразумевают. Парадоксально, но интерес к этому виду программного обеспечения породил массу искажений и заблуждений, которые на практике мешают его распространению.

Наша компания участвует в открытых проектах с 2005 года – и благодаря разработке собственных open source решений (проекты OpenVZ , CRIU), участвуя в других открытых проектах (QEMU , OpenStack , libvirt , libcontainer , и т.д.). За 10 лет мы собрали несколько наиболее распространённых мифов об открытом программном обеспечении. Я расскажу про каждое из заблуждений и объясню, почему оно ошибочно. Наверняка, вы вспомните еще столько же, но, на мой взгляд, эти пять самые «адовые».


Проект с открытым исходным кодом это открытый проект.

Любой программный проект состоит из множества артефактов: исходный код проекта, информация о неисправленных дефектах, исходный код тестов, документация. Исходный код проекта - это только его часть, свободный доступ к которой не даёт права называть весь проект открытым. Помимо исходного кода, свободный доступ должен быть открыт и к другим артефактам разработки, и чем больше артефактов открыто, тем больше проект открыт для контрибьюторов (людей, которые захотят сделать вклад в проект). Помимо этого, необходимы прозрачные процессы между всеми участниками сообщества, открытые коммуникации в проекте и т.д. Все эти меры будут только способствовать развитию проекта и плодотворному сотрудничеству участников сообщества.

Качество открытого ПО хуже, потому что код для него может писать любой желающий

Главный принцип открытого ПО – открытая совместная разработка – сам по себе является залогом того, что некачественный код, костыли и заплатки попросту невозможно будет скрыть от других участников. Человек, участвуя в такого рода проектах, готов к тому, что его работа будет подвергнута и анализу, и критике, а, значит, халтурить не будет. На кону его репутация, а её терять никто не хочет.

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

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

Отдельно стоит упомянуть, что компании, которые разрабатывают продукты на базе открытых проектов, в ходе тестирования заинтересованы в улучшении кода открытых проектов, которые они используют. Поэтому все обнаруженные проблемы необходимо исправлять и добиваться, чтобы это исправление было добавлено в основную ветку проекта, чтобы иметь как можно меньше отличий в своём коде и коде открытого проекта. Наши продукты используют код других открытых проектов, поэтому проблемы, найденные в коде этих проектов, мы исправляем и отправляем в upstream. Так было с уязвимостями в ядре RHEL: Red Hat отметил Владимира Давыдова за обнаружение серьезных уязвимостей CVE-2014-0203 и CVE-2014-4483 в одном из обновлений ядра RHEL6 (вторая проблема, кстати, была найдена с помощью одного из наших автоматических тестов, использующих Linux Test Project). Василий Аверин получил благодарность за обнаружение ошибки CVE-2014-5045 , Дмитрий Монахов – за CVE-2012-4508 . Факт хорошего тестирования Linux-ядра был даже отмечен Эндрю Мортоном (кто это?): “Мне интересно. За последние несколько месяцев люди из @openvz.org нашли (и исправили) кучу непонятных, но серьезных и довольно древних багов. Как вы обнаружили эти баги?”

Итог

На самом деле все перечисленные мифы возникают по большей части у пользователей, которые либо только начинают работать с OpenSource ПО, либо не пробовали этого делать вообще. Лучший способ избавиться от предубеждений – начать вплотную работать с такими решениями.
Мы недавно анонсировали открытый процесс разработки новой версии нашего продукта Virtuozzo 7. Если вы также заинтересованы в создании лучшей технологии контейнерной виртуализации, то