Свободное программное обеспечение
Открытое программное обеспечение — способ разработки ПО, при котором исходный код создаваемых программ открыт и общедоступен для просмотра и изменения. Это позволяет всем желающим использовать уже созданный код для своих нужд и, возможно, помочь в разработке открытой программы.
Бесплатность ПО есть право пользователя, но не обязанность производителя — «открытая» лицензия не требует, чтобы ПО всегда предоставлялось бесплатно. Многие из наиболее успешных проектов «открытого» ПО, тем не менее, бесплатны.
Термин «Открытое программное обеспечение» «англ. open source» был создан вместе с определением в 1998 году Эриком Реймондом и Брюсом Перенсом, которые утверждали, что термин «Свободное программное обеспечение» (англ. free software ) неоднозначен и отпугивает коммерческих предпринимателей.
Подавляющее большинство открытых программ является одновременно «свободными» и наоборот, ибо определения открытого и свободного ПО близки, а большинство лицензий соответствуют обоим.
Свободное программное обеспечение: что это? Чем отличается от Open Source? Лицензии и заблуждения
Отличие между движениями открытого ПО и свободного ПО заключается в основном в приоритетах. Сторонники открытого ПО делают упор на эффективность открытых исходников как метода разработки. Сторонники свободного ПО исходят из идеологических соображений, и считают, что именно права на распространение, модификацию и изучение программ являются главным достоинством свободного ПО.
В настоящее время открытое программное обеспечение не получило широкого распространения в России, что часто связывают с широким распространением нелегального собственнического программного обеспечения.
Определение состоит из десяти требований к лицензиям на ОПО:
1. Свободное распространение. Это значит, что лицензия не должна налагать ограничений на продажу и распространение ПО.
2. Доступные исходные тексты. Даже если ПО не поставляется с исходными текстами, эти тексты должны быть легко доступны.
3. Возможность модификации. Простая возможность читать исходные тексты не позволяет экспериментировать с ними и выпускать модификации. Лицензия, претендующая на звание «открытой», должна разрешать не только чтение кода, но и модификацию, использование частей кода в других проектах и т. д.
4. Даже в случае неприкосновенности авторского исходного текста, производные программы и их исходные тексты должны свободно распространяться. Свободные лицензии могут оставлять за автором какие-то права — например, производная программа обязана нести другое имя или версию; либо она должна состоять из авторских исходных текстов и патчей к ним. Тем не менее, автор должен разрешать распространять откомпилированные двоичные файлы и исходные тексты производной программы в том или ином виде.
5. Отсутствие дискриминации против людей и групп людей. Некоторые страны, например, США, имеют некоторые ограничения на экспорт ПО. Свободная лицензия может напоминать, что такие правила есть, но не может ставить свои.
Он вам не Open Source / Тайная империя свободного ПО
6. Отсутствие дискриминации по цели применения. Свободная лицензия должна разрешать все виды деятельности, включая генетические и ядерные исследования, коммерческое применение и т. д. Про коммерческое применение говорится особо: «Мы хотим, чтобы коммерческие пользователи подключались к сообществу, а не считали себя отрезанными от него».
7. Отсутствие дополнительных соглашений. Права, связанные с ОПО, должны быть применимы ко всем пользователям программы без заключения дополнительных соглашений, например, соглашения о неразглашении.
8. Лицензия не должна быть привязана к конкретному продукту. Права на программный код не должны зависеть от того, является ли программа частью какого-то продукта. Человек, распространяющий программу в отрыве от сборника или перенёсший часть кода в другой продукт, имеет такие же права, какие давал сборник. Это требование закрывает некоторые лицензионные лазейки.
9. Лицензия не должна ограничивать другие программные продукты. За исключением банальной несовместимости, пользователь имеет право выбирать, чем пользоваться. Например, нельзя требовать, чтобы остальные программы, поставляемые вместе с данной, также были открытыми.
10. Лицензия должна быть технологически нейтральной. То есть, лицензия не должна требовать что-либо от интерфейса или технологий, применяемых в производной программе.
Курсы обучения — Свободное ПО/Open Source
| Расписание |
Источник: www.interface.ru
Превращаем Windows в Open Source систему №1
Натёр глаза проклятый мастдай? Угрёбищная винда вызывает раздражение вплоть до приступов тошноты? Переходи на GNU/Linux, *BSD. А если для видеокарты драйвера нет даже проприентарного? Или любимая игрушка под мастдаем?
Или (не дай бог, конечно) ты этого самого мастдая админ? В этом цикле статей
я расскажу шаг за шагом, как превратить свою винду в более-менее удобную Free #128578; В глазах, правда, немного рябит от кнопок в настройках, но это ничего.
Оба клиента, конечно, поддерживают докачку и несколько соединений/закачек одновременно.
3.Текстовый редактор
Буду краток — мой любимый текстовый редактор для винды - Crimson Editor, хоть он и не Open Source. Если хочешь более мощный, попробуй emacs. Да не кричи ты, что он неудобный, почитай сперва мануал
4.Медиаплэйер
Немедленно выбрось свой Winblowz Media Payer на помойку! Скачай и распакуй Mplayer - тотальный плэйер для любых источников данных. А для просмотра фильмов лучше скачай и запиши на мини-диск отдельный GNU/Linux LiveCD дистрибутив Geexbox. Всего 6 MB! Не надо больше мучатся с поиском экзотических кодеков и устанавливать всякий хлам, засирая registry - всё включено!
Просто вставляешь диск в дисковод, ждёшь, пока запустится (несколько секунд) и вставляешь свой диск. Или открываешь файл с HDD или TV-out. Использует Mplayer. Для выхода в меню - Ecs, помощь по управлению - h.
5.Офисный пакет
Ещё я пробовал AbiWord, но у него поддержка мастдайного формата хромает, а в остальном нормальный редактор.
6.Графический редактор
Если ты всё ещё пользуешься CorelDraw, Photoshop или FotoCanvas для графических работ, то это только потому, что ты не пробовал (или не распробовал:) The GNU Image Manipulation Program (The GIMP). Универсальный редактор. Фантастически удобный, тотально совместимый и бесконечно расширяемый. Ну и, конечно, настраиваемый, от тем и расположения окон до управления памятью. И многопользовательский.
И. В общем долго перечислять все его достоинства, это просто отдельная операционная среда для манипулирования любыми изображениями любыми вообразимыми способами. Название очень точно отражает идеологию этой программы. Всё, что ты видел в вышеперечисленных проприентарных продуктах, в The GIMP можно найти в стандартном комплекте установки, или найти и скачать plug-in.
Или написать plug-in;), но вряд ли это тебе когда-нибудь понадобится, если ты не гуру графики. The GIMP имеет объектно-ориентированную структуру: ты создаёшь объект (кисть, градиент, слой, выделение, текстуру, path, . ) с определёнными параметрами, связываешь его с другими объектами и получаешь конкретную подпрограмму для рисования/редактирования.
Затем применяешь её с помощью мыши и/или другого ввода. Интерфейс очень удобный и продуманный. Хотя готовых функций невероятно много (за неделю всё не испробуешь;), но в них не заблудишься. Настраивается интерфейс очень тонко, но при этом интуитивно. Короче, тотальная и удобная среда разработки изображений.
Перед установкой, собственно, The GIMP требуется установить The GIMP Toolkit (GTK+ for Win32).
7.Приложение для 3D
В случае, если ты, о мой читатель, увлекаешься 3d графикой, настоятельно рекомендую скачать себе Blender (10MB), убрать сглаживание (antialiasing/oversampling) в настройках твоей видеокарты и наслаждаться этой великолепной средой 3D разработки. И выбросить свой 3ds max/maya/lightwave к чертям собачьим. Именно так я и поступил с 3ds max, хотя до этого пользовался им около 3-х лет.
Blender — это FOSS-замена большинству популярных 3D пакетов. Даже если ты не собираешься менять среду разаботки, рекомендую попробовать интерфейс Blender, предварительно почитав маленькую (всего 1 лист) обучалку по нему. После этого, как говорит обучалка, ты захочешь, чтобы все твои приложения имели такой же интерфейс!
Всё, пожалуй, хватит. В следующий раз будем ставить собственную графическую оболочку взамен explorer’а и перекраивать безобразную структуру каталогов винды.
Источник: xakep.ru
Российскому ИТ-рынку грядет полный опенсорс
Российские власти, судя по всему, решили сделать серьезную ставку на программное обеспечение с открытым кодом. Преодолеть зависимость от зарубежных разработчиков проприетарного ПО — дело благое, однако опыт показывает, что с Open Source не все так просто. О возможных проблемах рассказывает Дмитрий Комиссаров, член правления АРПП «Отечественный софт».
Как избавиться «от Microsoft»
Правительство России всерьез задумалось о реформировании российского ИТ-рынка и поручило ИТ-компаниям разработать стратегию поддержки свободного ПО. Сейчас над проектом работает более 500 профильных специалистов, которые пытаются выработать оптимальное для всей отрасли решение. Пока озвученный вариант кажется слишком рискованным — стремление к преимущественному использованию свободного ПО в госсекторе может привести к серьезным проблемам и в отрасли, и у самого государства. С учетом того, что первый драфт стратегии будет представлен уже 1 октября, у ИТ-сообщества не так много времени, чтобы внести коррективы в планы властей.
Идея перейти на опенсорс витала в высоких кабинетах уже довольно давно — еще летом 2021 г. в СМИ появились публикации о стремлении правительства приравнять открытый код к российскому. Причина проста — в свете нарастающих геополитических рисков нашей стране нужна технологическая независимость, и, казалось бы, что самый простой и легкий путь для ее достижения — взять за основу существующие свободные продукты и на их базе сделать собственные.
СПО можно расценивать как аналог библиотеки кода, и что важно, бесплатной, которой можно воспользоваться при написании мелких компонентов многострочного кода. Но есть один нюанс: если мы говорим о глобальной задаче по достижению цифровой независимости целой страны, то необходимо развивать российскую отрасль разработки в целом, а не концентрироваться только на open source. И вот, почему.
Чему нас учит иностранный опыт
В разное время в странах-локомотивах мировой экономики, таких как Франция и Германия, пытались внедрить СПО на государственном уровне. Но и там, и там, это действие не привело к каким-то позитивным сдвигам в развитии ИТ-отрасли.
Так, власти Мюнхена в начале 2000-х решили избавиться от Microsoft Windows и объявили о переходе на операционную систему с открытым исходным кодом LiMux . Это оказалось непросто, и на проект потребовалось больше 10 лет — только к 2013 г. миграция рабочих мест муниципалитета на СПО была завершена на 80%. Осознав все сложности с внедрением, а также необходимость дальнейшей поддержки и доработки инфраструктуры с открытым кодом, которую сообщество не торопилось делать самостоятельно, немецкие власти в 2017 г. решили вернуться к использованию американского проприетарного ПО.
Немецкий опыт показал, что руководство города оказалось не в силах влиять на комьюнити разработчиков, на которое они изначально делали ставку. Любые изменения в ПО требовали новых финансовых ресурсов для дополнительного программирования, и из-за экономической нецелесообразности таких действий проект был остановлен. Переход на СПО обошелся бюджету Мюнхена в € 30 млн, а на возврат к Microsoft Windows ушло еще порядка €50 млн.
Отношения Франции и СПО сложились немного лучше — еще в 2012 г. Жан-Марк Эро, премьер-министр Франции, издал распоряжение о переводе всех госорганов на СПО. Это распоряжение, с одной стороны, повлияло на появление новых французских ИТ-компаний, но с другой — сформировало их зависимость от государственных контрактов. Распоряжение не привело к бурному росту ИТ-рынка как планировалось изначально. Даже самые сильные игроки, такие как LINAGORA, которая разрабатывает софт для создания цифрового офисного рабочего места и считается одним из лидеров в области свободного ПО, с 2010 г. и до сих пор демонстрируют крайне скромные финансовые результаты — ее годовая выручка на протяжении десяти лет не превышала и €13 млн.
Может ли СПО быть экономически успешным
В 2012 г. в проект ROSA (российская ОС на базе ядра Linux), где я был основателем и генеральным директором, приезжа ли представители фонда Intel Capital. Американская компания искала опенсорс-команды, в которые можно инвестировать. В то время в России существовало несколько крупных СПО компаний, например, ROSA и PingWin Software, годовой оборот каждой из которых находился в пределах $5 млн. Во время презентации нашей компании я сделал акцент на выручке, на том, как много мы смогли добиться всего за пару лет существования. На это представители Intel Capital заметили, что опенсорс компании быстро достигают выручки в $5-10 млн, но вырасти сверх этого получается только в очень редких случаях.
И действительно, компании СПО, которые перешли рубеж в $100 млн в год, единицы: Canonical ( создатель Linux-дистрибутива Ubuntu) и EnterpriseDB (разработчик СУБД на базе PostgreSQL). Да и то, первая компания смогла выйти на самоокупаемость только спустя 1 6 лет существования. Единственным примером СПО-компании, которая преодолела $1 млрд является компания Red Hat, которая в 2019 г. показала выручку $3,3 млрд (и была куплена IBM).
Open source как средство против санкций
Мне можно возразить и сказать, что какой бы маленькой не была опенсорс-компания , она сможет поддерживать технологическую независимость страны в условиях санационного давления. Однако создание ПО на основе свободного кода не избавит от геополитических рисков. В любой момент владелец проекта — объединение разработчиков-энтузиастов, общественная организация, коммерческая компания — может изменить условия лицензии так, что они будут учитывать политическую обстановку. Отличным примером такой ситуации послужит кейс Huawei, едва не потерявшей свой международный мобильный бизнес из-за санкций американского регулятора и действий Google. Последняя запретила использовать приложения Google Mobile Services на смартфонах китайской компании, чем сильно осложнила продажи смартфонов и планшетов Huawei по всему миру.
Ключи от безопасности: Что важно учитывать, публикуя исходный код софта в национальном репозитории открытого ПО
Безопасность
Для того, чтобы по-настоящему избежать санкционных рисков и при этом использовать СПО как ключевую часть инфраструктуры государства или в крупных компаниях, нужны контрибьюторы. Это люди, которые уже сейчас активно участвуют в open source проекте: самостоятельно пишут код , погружены в его особенности и в случае изменений условий лицензий смогут поддерживать его. Но стать контрибьютором в проектах СПО непросто.
Для успешного возникновения и жизнеспособности любого опенсорс проекта необходимо соблюдение двух базовых условий. Первое — наличие пассионариев в рядах разработчиков, которые бы с энтузиазмом тратили свое личное время на создание и доработку открытого кода. Второе требование — дипломатия, гибкость и терпение у тех, кто управляет комьюнити. Большинство open source проектов спонсируются коммерческими компаниями (Intel, Huawei, Microsoft, Oracle, SAP и др.), которые конкурируют между собой. Для соблюдения баланса сил и сохранения устойчивости проекта, необходимо учитывать и мнение самого сообщества, интересы которого могут идти вразрез с интересами ИТ-гигантов.
Какое будущее ждет российский ИТ-рынок
Бесконтрольное приравнивание свободного ПО к российскому, а вместе с тем и выпуск директив госкомпаниям на его закупку, очевидно, усложнит работу существующих игроков российского рынка. Вновь образованные компании — так называемые номинальные владельцы кода иностранного СПО и создатели программ-клонов на его базе — получат возможность участвовать в госзакупках на тех же основаниях, что и настоящие отечественные разработчики. Но только затраты на создание продуктов будут разные, ведь скопировать чужой код можно бесплатно, а вот чтобы создать свой потребуются тысячи человеко-часов разработки.
Если сегодня в России мы сфокусируемся только на развитии open source проектов, то через несколько лет ландшафт отечественного ИТ-рынка будет сформирован лишь небольшими компаниями, которые обретут зависимость от регулярных инвестиций и поддержки. Кроме того, мы рискуем потерять и свой экспортный потенциал, так как слабые локальные команды не смогут участвовать на международном рынке — как я уже говорил, примеров глобальных опенсорс- компаний очень мало.
Вместо заключения: каким должен стать российский путь
По моему мнению, до принятия резких и ограничивающих конкуренцию мер, необходимо все же сначала провести работу по анализу рынка и понять в каких сегментах ИТ-рынка сегодня нет российских аналогов западным решениям. Так мы сформируем 20-30 крупных СПО-проектов, которые могут быть приравнены к отечественным, поддержка и участие в развитии которых будет выгодна с точки зрения реализации государственных инициатив.
Артем Пермяков, Directum: HR-специалист становится агентом цифровизации
Цифровизация
Затем необходимо сформировать гранты на поддержку тех, кто уже является контрибьютором и готов поддерживать интересы нашей страны в глобальном проекте. К примеру, выделить по пять миллионов рублей в год каждому контрибьютору ядра Linux на поддержку интересов нашей страны в глобальном проекте. При этом важно, чтобы он работал на российскую компанию и платил налоги в России.
Бюджету подобная инициатива обойдется примерно в ₽1 млрд в год (20 проектов, по 10 контрибьюторов в каждом). Это позволило бы получить существенное количество контрибьюторов в совершенно разных проектах, таких как OpenStack, Kubernetes и многих других. Расходы на опенсорс в ₽1 млрд намного меньше выделенного финансирования в рамках федерального проекта «Цифровые технологии» в 2022 г., там заложено ₽28,389 млрд. Такая сумма вполне подъемна для российского бюджета.
Источник: www.cnews.ru
Безопасно ли использовать Open Source в российском ПО на примере Галактика ECM.CORP и Liferay
С 2016 года в России начал формироваться Единый реестр российских программ, но активное обсуждение необходимости импортозамещения в IT-сфере началось фактически только с марта этого года, когда стало понятно, что нам с западным миром еще долгое время будет «не по пути». И вроде бы для многих зарубежных решений уже существуют и активно используются российские аналоги, однако вопрос безопасности использования отдельных продуктов из списка Минкомсвязи остается отрытым.
Менять нельзя использовать
Собственно, если у кого-то из российских высших чиновников и государственных топ-менеджеров и были сомнения в правильности замены импортного софта на отечественный, то Указ Президента РФ от 30 марта 2022 года № 166 о запрете закупки иностранного софта для критической информационной инфраструктуры (КИИ) в одночасье снял все вопросы. Более того, в ближайшие полгода Правительство РФ должно разработать дополнительную нормативку по импортозамещению на значимых объектах всех субъектов КИИ, а не только структур с государственным участием.
При этом коммерческие компании находятся в серьезных раздумьях – а так ли уж нужно ли делать следующие шаги по переходу на отечественный софт? Ведь, например, те же Atlassian, Zendensk или Notion, конечно, ушли с российского рынка и даже слегка «хлопнули дверью», но ведь пока нет ограничений на оплату соответствующих сервисов через белорусские банковские карты и никто пока не мешает использовать VPN для доступа к заветным «закромам»…
И главные проблемы кроются не только в очевидной сверхзатратности процесса перехода на новый софт, но и в вопросе безопасности использования незнакомого программного обеспечения. А пренебрежение «правилами техники безопасности» может бизнесу обойтись ох как дорого. Яркий пример – недавний трехдневный сбой в работе Rutube, который вызвал небывалое оживление в публичном пространстве и споры о том, что же на самом деле произошло – внутренняя диверсия или действия внешних «экспертов», нашедших таки недостатки в IT-структуре.
Насколько российский софт по-настоящему российский?
В реестр отечественного ПО сегодня включены более 13 тысяч программных продуктов, которые «официально признаны происходящими из Российской Федерации». Периодически список пополняется новыми решениями, но при этом параллельно происходит чистка реестра и исключение программного обеспечения, которое себя по какой-то причине скомпрометировало. Основные причины исключения связаны с постепенным, но планомерным выявлением использования зарубежного Open Source при разработке продуктов. Из последних примеров — продукт LibreOffice, который по сути являлся софтом, написанном на иностранном Open Sourсe, но забрендированном под отечественного производителя – компанию AlterOffice).
Любопытно, что использование импортного Open Source в продуктах не является формальным ограничением для включения в Реестр. По экспертной оценке, при разработке не менее 85% «реестровых» решений в той или иной степени используются зарубежные Open Source сервисы, которые по сей день активно совершенствуются представителями всего мирового IT-сообщества.
Таким образом, присутствие в данный конкретный момент программного обеспечения в Реестре вовсе не означает, что при его создании не использовались «запрещенные технологии» и, соответственно, не является гарантией «устойчивости» софта – а именно этот критерий сегодня является главным показателем «благонадежности» продукта в условиях санкционного давления со стороны мирового IT-сообщества.
Плохой хороший Open Source
При других текущих вводных повсеместное использование открытых кодов было бы абсолютно нормальным и правильным подходом – почему не использовать себе во благо имеющийся опыт тысяч разработчиков?
Однако общее настроение сегодня в международной IT-среде однозначно антироссийское. Например, крупнейший и самый популярный мировой репозиторий GitHub уже закрыл доступ десяткам российских разработчиков — включая профили попавших под западные санкции Сбербанка и Альфа-Банка — и продолжает пополнять перечень «неблагонадежных» аккаунтов. Ну и, конечно, «недружественность», в том числе, проявляется в среде разработчиков продуктов на Open Source, которые постепенно прекращают поддержку своих решений на территории нашей страны или даже блокируют возможность их использования российскими. В частности, о прекращении сотрудничества со своими партнерами из России и Белоруссии сообщила Red Hat (разработчик Linux-дистрибутива RHEL). Также в качестве примера можно привести уход Cisco, который владеет Open Source-продуктом Сlamav.
В общем, прекращение поддержки русскоязычного сообщества или запрет использования Open Source продукта на территории России – это достаточный повод, чтобы всерьез задуматься о замене на аналогичный продукт и продолжить работу без оглядки на санкции и возможные «косяки» в открытом коде. Но такая замена, как выясняется, возможна далеко не всегда.
Рассмотрим два примера архитектуры продуктов с использованием Open Source-решений (на примере ECM-систем).
1. Использование Open Source для формирования части «надстройки» над ядром – микросервисов, приложений для работы с внешним контуром и т.п. Пример – на рис. 1 (схема взята с сайта www.tadviser.ru и описывает архитектуру совместного продукта компаний Galantis и » Корпорация Галактика «).
В этом примере ядро системы – собственная разработка компании, и разработчикам ничего не мешает при этом иметь часть сопутствующих сервисов на открытом коде.
2. Использование Open Source в качестве основы продукта.
Пример – на рис. 2 (схема взята с сайта компании L2U и описывает архитектуру продукта InKnowledge ).
В ядре продукта, используется решение от Liferay (разработка американской компании Liferay LTD). Продукт известный и популярный, и, кстати, включен в Реестр отечественного ПО несмотря на импортную основу.
Liferay Portal CE – Open Source не для всех.
Несмотря на то, что Liferay Portal CE – это Open Source продукт, его правообладатель в праве накладывать ограничения на использование своего продукта. Например, в части экспорта, Liferay LTD . придерживается политики США и вводимых ими санкций.
На момент написания данной статьи правительством Соединенных Штатов Америки уже ограничена возможность вести деятельность как на отдельных территориях нашей страны, так и с конкретными организациями, которых в России уже более 14 000. И как быстро к этим компаниям добавятся новые, предсказать невозможно.
Если, оценив все риски, вы все же склоняетесь к продуктам на основе технологий Liferay, то стоит отметить, что вы можете использовать их абсолютно бесплатно. Liferay Portal CE это готовый к эксплуатации продукт, который абсолютно ничего не стоит и даже может быть доработан вами самостоятельно под ваши цели и задачи.
А вот что произойдет и какие у пользователей возникнут риски, если Liferay вслед за своими западными коллегами отключит Россию от «трубы поддержки» — попробуем разобраться далее.
Можно ли в России использовать продукт в основе которого лежит софт, подобный Liferay?
Формально Нет!
У каждого продукта есть правообладатель и лицензия, по которой он распространяется и условия которой нельзя нарушать.
Но…
Не думаем, что в текущей ситуации компания Liferay LTD, будет обращаться в российские суды, и нарушение останется лишь на совести разработчиков.
Теоретически Да…
Многие эксперты считают, что, имея доступ к открытому коду продукта (а уж как его скачать – решение всегда найдется), в нем можно «разобраться» и своевременно выявлять недостатки, устраняя их своими силами. И дорабатывать ядро «под себя», создавая по-настоящему уникальный российский продукт.
…Но Небезопасно!
Чем сложнее сервис, тем больше времени уходит на изучение деталей и нюансов кода. Те же специалисты оценивают период «полного погружения» от полугода и до бесконечности. А Liferay это далеко не маленькое решение, а полноценный продукт. И пока разработчики будут разбираться в хитросплетениях кода, только отцам-основателям Liferay будет известно, как будет работать продукт.
Практически Да…
Можно предположить, что с учетом высокого уровня квалификации IT-специалистов в большинстве крупных российских компаний найдутся лазейки даже для скачивания обновлений и доработок Open Source.
Но результат не прогнозируем!
Cовершенно непонятно (и таких примеров нам, во всяком случае, неизвестно), как обновлять ядро Open Source при том, что в этом же ядре уже активно «покопались» собственные специалисты. То бишь компания встанет перед выбором между потенциальным улучшением качества и повышением безопасности продукта и риском появления в продукте внутренних противоречий – возможно, критических и неразрешимых. А также не будем забывать и про толпы хакеров, жаждущих ворваться в «личное» пространство российского бизнеса – причем в сегодняшних условиях порой по идеологическим соображениям, а не корысти ради.
Думайте сами, решайте сами…
Итак, резюмируем. Имеется масса примеров реализации систем на проприетарном коде, который при этом прекрасно поддерживается и вендором, и свободными разработчиками. Казалось бы, все всё предусмотрели, но… Свежий пример с демаршем Atlassian с российского рынка — и в топку летят десятки готовых программных продуктов, а про сотни наработок уже молчим.
При этом, повторимся — нельзя говорить, что Open Source – это плохо! Если на открытом коде написана только часть продукта, поскольку это действительно удобно и позволяет быстро получить нужное решение (или использовать уже готовую технологию). Некогда открытый поисковый движок Elasticsearch поменял свою лицензионную политику и перестал быть открытым. Разработчики, которые использовали этот код, столкнулись с определенной проблемой, но оперативно поменяли его на Opensearch и ему подобные, и все произошло незаметно для пользователей.
А вот если Open Source лежит в основе продукта (как в приведенном примере с Liferay), то «незаметно», быстро и качественно заменить его нельзя.
Конечно, совсем от рисков себя уберечь невозможно, но можно эти риски минимизировать. И с точки зрения информационной безопасности при выборе продукта, необходимо в первую очередь внимательно смотреть за тем, чтобы в ядре не было заложено Open Source-решение.
Источник: www.comnews.ru
Системы с открытым кодом в современных IT
В последние десятилетия системы с открытым исходным кодом (Open Source системы) получили огромное распространение всем мире. Они широко применяются как для для развертывания IT инфраструктуры предприятия, для решения критичных бизнес-задач, так и для отдельных, сугубо ИТ-ориентированных задач. Да и сама всемирная паутина процентов на 70 (а по некоторым источникам и больше) базируется на системах с открытым исходным кодом и полностью — на открытых протоколах.
Хоть понятия «программное обеспечение с открытым исходным кодом» (Open Source software) и «cвободное программное обеспечение» (free software) часто отождествляются, на самом деле это не одно и то-же. Свободное программное обеспечение может распространяться и без исходных кодов, а системы с открытым исходным кодом могут быть проприетарными.
Термин свободное (или бесплатное, кто как переводит) программное обеспечение более старый, и произдеден от имени Фонда свободного программного обеспечения (Free Software Foundation — FSF), организации, основанной в 1985, чтобы защищать и продвигать бесплатное программное обеспечение. Термин программное обеспечение с открытым исходным кодом был введен в 1998 группой единимышленников — основателей Open Source Initiative (OSI – http://opensource.org) — также поддерживавших развитие и распространение бесплатного программного обеспечения, но кто не соглашался с FSF о том, как распространять его, и кто чувствовал, что свобода программного обеспечения была прежде всего практическим вопросом, а не идеологическим. Впрочем это длинный и не всегда понятный терминологическо-лицензионный спор и о нём можно прочитать в первоисточнике.
В итоге в некоторых источниках можно встретить и «бесплатное программное обеспечение с открытым исходным кодом«. По русски очень длинно и обычно все говорят просто — Open Source.
Лицензий на Open Source достаточно много, некоторые настолько схожи, что понять разницу можно только юристу. Но общее у них одно — пользователь обладает правами на неограниченную установку, запуск, а также свободное использование, изучение, распространение (в том числе — коммерческое) и изменение, эти права защищены юридически при помощи свободных лицензий.
Лицензии приведены на сайте OSI на английском языке и не переводятся принципиально, чтобы при переводе не потерять нюансов. Основной и наиболее часто употребляемой лицензией является GPL — лицензируются почти 95% открытых программных продуктов. На данный момент существует уже 3 версии GPL.
Более того, Европейский Союз, традиционно симпатизирующий открытому программному обеспечению, решился на создание собственной версии открытой лицензии, которая будет похожа на классическую лицензию GPL.
На сегодня европейская лицензия EUPL (European Union Public License) находится на этапе рассмотрения в правительствах европейских стран, входящих в ЕС, и по задумке Брюсселя выпускаться под этой лицензией должны открытые программные продукты, созданные в Европе и в большей степени ориентированные на использование в госсекторе. Несмотря на обсуждение новой лицензии, от использования продуктов на базе GPL, Евросоюз отказываться не намерен. Open Source Initiative, курирующая лицензирование открытого софта, уже приняла к рассмотрению текст EUPL, однако своего окончательного решения по статусу лицензии пока не вынесла.
Но основное это то, что Open Source прочно воли в нашу жизнь, стали составляющей всех информационных систем, если не как отдельные системы, то как компоненты закрытых решений. Практически все компании-противники открытого ПО, в том или ином виде его активно используют.
В большинстве случаев открытое ПО эксплуатируется наряду с традиционными коммерческими решениями. И это вполне обосновано – необходимо разумное сочетание свободного и проприетарного программного обеспечения, в зависимости от потребностей бизнеса и уменьшения финансовых издержек.
Чаще других Open Source решений эксплуатируются в высоконагруженном, промышленном режиме операционные системы – как правило, различные серверные (а в настоящее время и Desktop. ) клоны Linux, freeDSD. Порталы предприятий, корпоративная почта, IP телефония и многие другие подсистемы функционируют на серверных решениях Open Source.
Но в последние годы наблюдается рост интереса предприятий к инфраструктурным решениям и бизнес-приложениям с открытыми исходными текстами, которые выросли уже до такого уровня, что стали уже не уступать, а зачастую и превосходить традиционные коммерческие решения.
Вопреки бытующему мнению программы с открытым исходным кодом намного безопаснее и надёжнее проприетарных — процесс нахождения и устранения ошибок и уязвимостей в открытом коде более совершенен, оперативен и требует меньших временных затрат, так как существует огромное сообщество разработчиков, разбросанных по всему миру, тестирующих и улучшающих систему. Ну и в такие системы практически невозможно незаметно включить закладку.
Технология разработки Open Source систем давно уже отошла от технологии «базара», стала более фундаментальной и всё чаще к ней стали подключаться компьютерные гиганты. Многие разработки перешли под их непосредственное финансирование. Хорошо это или плохо — время покажет.
В России отношение бизнеса к Open Source решениям к сожалению намного прохладнее. Причин несколько. Основные, на мой взгляд, это массовые неграмотные попытки внедрения таких решений, порой дилетантские и не профессиональные, и яростное сопротивление разработчиков проприетарного программного обеспечения.
По вопросам внедрения – обращайтесь.
Источник: www.oslogic.ru