Исходный код и его 11 составляющих


Правовое положение исходного кода программы для ЭВМ

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

Ключевые слова: гражданское право, интеллектуальное право, исходный код, программа для ЭВМ, авторское право, исключительное право.

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

В связи с этим законодатель для защиты гарантированных законных прав и свобод граждан автору(разработчику) и пользователю (потребителю) предоставляет соответствующую правовую охрану. В действующем законодательстве программа ЭВМ в ст. 1261 ГК РФ определяется как представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата, включая подготовительные материалы, полученные в ходе разработке программы для ЭВМ, и порождаемые ею аудиовизуальные отображения. Авторам и правообладателям, в связи с закреплением объекта в законодательстве, предоставляются соответствующая правовая охрана, характерная для авторского и исключительного права согласно ст.1259 ГК РФ. В 1886 году была принята и подписана договаривающимися сторонами Бернская Конвенция по охране литературных и художественных произведений.

Основной задачей конвенции было предусмотреть для авторов инструменты, с помощью которых они могут контролировать, как, кем и на каких условиях используются их произведения. В 1979 году была принята обновленная Конвенция с отредактированными нормами, отвечающими современным условиям и Российская Федерация присоединилась к данной Конвенции 13 марта 1995 года, а затем постепенно ратифицировала ее в своем законодательстве. 21 июля 2008 года Российской Федерацией было принято решение о присоединении к договору Всемирной организации интеллектуальной собственности по авторскому праву от 20 декабря 1996 года, который уточнял положения ст. 20 Бернской Конвенции о порядке охраны произведений и прав авторов в цифровой среде. В ст. 4 данной Договора указано, что «компьютерные программы охраняются как литературные произведения в смысле статьи 2 Бернской конвенции. Такая охрана распространяется на программы независимо от способа или формы их выражения».

В ст. 2 четко определяется термин «художественные и литературные произведения», какие именно произведения в него включаются и указываются основные их черты. Понятие «литературные и художественные» рассматривается как одно целое и дополняющее друг друга. Программы для ЭВМ по сравнению с другими объектами охраняемыми авторскими правом имеют свою определенную специфику, и именно поэтому упоминание в статье 1259 происходит отдельно после основного перечня объектов [2, c. 51]. Автору, коллективу авторов или правообладателю предоставляется исключительное право на программу для ЭВМ в силу первичной разработки (создания программы) или в силу передачи таких прав по возмездной или безвозмездной сделке, в случае физических лиц согласно ст.1234 ГК РФ.

Моментом возникновения исключительного права и права авторства на программу для ЭВМ является событие, повлекшее ее создание. До момента создания итоговой программы, охрана не распространяется в связи с тем, что объект охраны еще не существует. Стоит отметить, что разработка программы проходит в несколько этапов, и каждый из них сопряжен с интеллектуальным творческим трудом [3-4; 5, c. 29].

А так же в процессе разработки может быть написано техническое задание с изложением представлений и функций программы, создан проект или презентация, описана алгоритмическая схема действий, инструкции и т.д. При этом до создания самой программы каждый документ получает самостоятельную правовую охрану как результат интеллектуально деятельности, и так как не являются непосредственно самой программой или ее составляющей или как-то с ней связанной, но после ее создания в силу статьи 1261 Гражданского Кодекса, они могут являться подготовительными материалами, конечно, если без них не будет возможным ее использование [1, c.18].

Одним из этапов процесса создания (разработки) программы для ЭВМ является написание исходного кода. Исходный код до его компиляции и пост- обработки (компоновки) нуждается в правовой оценке и соответственно правовой охране. К сожалению, законодатель не дает определения исходного кода на момент написания статьи, но оно имеется в действующих технических ГОСТах. Например, исходный код – это: – компьютерная программа в текстовом виде на каком-либо языке программирования (ГОСТ Р 54593-2011 «Свободное программное обеспечение. Общие положения»); – код, написанный на исходном языке программирования, таком как язык ассемблера и/или язык высокого уровня, в машинно-читаемой форме, пригодной для ввода в ассемблер или компилятор (ИСО 24765-2020 «Системная и программная инженерия. Словарь») (ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем.

Общие требования к разработке и документированию»); – оригинальная компьютерная программа, выраженная в пригодной для чтения человеком форме (язык программирования), которую необходимо перевести в машиночитаемую форму, прежде чем она может быть выполнена компьютером (ГОСТ 31887-2012 «Принципы надлежащей лабораторной практики (GLP). Применение принципов GLP к компьютеризированным системам»). Исходный код можно определить как структурированный набор команд языка программирования, написанный по определенному разработчиком алгоритму в пригодной для чтения человеком форме, предназначенный для компиляции компилятором, результатом которого является создание объектного кода, и записанный в файле. В данном определении используется термин компилятор, который обозначает программу, которая выполняет перевод исходного кода в объектный код (компиляция) согласно ГОСТ 19781-90 «Обеспечение систем обработки информации программное. Термины и определения». Затем объектный код с помощью программы-компоновщика уже переводится в исполняемый файл – программа для ЭВМ.

Отдельно нужно отметить, что основываясь на постановлении Суда по Интеллектуальным правам от 04.02.2015 по делу № А56-75812/2013, законодатель не разделяет понятия «программа для ЭВМ» и «исходный код». Здесь важно отметить, что имеется правовая неопределенность при переводе результата интеллектуальной деятельности из одной формы в другую – исходный код в программу для ЭВМ. Законодатель просто считает две разные по природе формы выражения результата интеллектуальной деятельности, которые могут существовать самостоятельно и независимо друг от друга, как одну. В связи с тем, что исходный код это форма выражения программы для ЭВМ, он охраняется как произведение литературы (ст. 1261 ГК РФ) и может охраняться как секрет производства (ноу-хау) [9, c.17]. Это можно обосновать следующим: – представляет собой форматированный наглядный текст в электронной форме, состоящий из команд языка программирования, имеет строгую структуру, код может быть воспринят, прочтен третьими лицами, а также распечатан в бумажной форме, а также в силу ратифицированной упомянутой выше Конвенцией; – представляет ценность как секрет, раскрытие которого позволит третьим лицам создать на его основе программу для ЭВМ с описанными в нем возможностями и функционалом, может иметь статус коммерческой тайны.

Исходному коду правовая охрана как секрету производства может быть представлена в связи с его уникальностью алгоритмических последовательностей описанных командами языка программирования. В его основе лежит заранее придуманный алгоритм, который описывает порядок обработки данных, действий с ними. Уникальность исходного кода определяет индивидуальную особенность программы, которая ее отличает от других существующих программ в своем классе. Заказчик или работодатель может по своему усмотрению отнести с помощью специальной процедуры исходный код к коммерческой тайне, основываясь на п. 2 ст. 6.1 ФЗ «О коммерческой тайне», если он представляет собой коммерческую ценность в случае востребованности программы ЭВМ на рынке. Внесение изменений в исходный код позволяет на его основе выпускать более совершенные версии программы для ЭВМ с

дополненными функциональными возможностями и тем самым поддерживать ее состояние на конкурентном уровне. В силу п. 1 ст. 1228 ГК РФ автор (программист), написавший исходный код, будет являться его автором и ему гарантируются право авторства и исключительное право. Далее у него возникает право распоряжаться судьбой кода – уничтожить, модифицировать либо передать право по договору другому лицу.

Но в случае если программист пишет исходный код по трудовому договору или договору на создание программы для ЭВМ, в котором определена судьба исходного кода, исключительное право будет принадлежать работодателю или заказчику согласно п.2 ст.1288 ГК РФ. Лицо, которое скомпилирует исходный код и скомпонует объектный код, будет являться автором программы для ЭВМ и ему будет гарантированы исключительные права на нее.

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

В виду того, что согласно п. 3 ст. 1280 ГК РФ пользователю предоставлено право декомпилировать программу для ЭВМ, то есть исполняемый файл программы с помощью специальных программных средств представить в виде исходного кода, правообладатель при предоставлении права пользования, как правило, прямо ограничивает в таком праве условием в лицензионном договоре. Это связано с тем, что получив исходный код и исследовав его, пользователь получит информацию о логической и технологической составляющей программы, основных идеях и принципах функционирования, что в дальнейшем позволит воспользоваться ею для создания собственной программы с похожим функционалом – заимствование чужой идеи.

Отдельно стоит отметить, что исходный код в силу своей специфики может существовать отдельно от созданной на его основе программы для ЭВМ, а так же вообще не иметь выражения в объективной форме или в виде исполняемого файла в виду отсутствия проводимых над ним процедур компиляции и компоновки. Исходный код в силу своей природы нельзя запустить на ЭВМ, задать начальные параметры и получить конкретный результат его действия, как от программы для ЭВМ. Но, как правило, процесс написания исходного кода для его проверки корректности предусматривает компилирование и компоновку промежуточной версии программы для ЭВМ («alfa-версия»).

1.Авторские и смежные права. Постатейный комментарий глав 70 и 71 ГК РФ / под ред. П.В. Крашенинникова. – М.: Статут, 2010. – 480 с.

2. Комментарий к части четвертой гражданского кодекса Российской Федерации / под ред. А.Л.Маковского. – М.: Статут, 2008. – 225 с.

3. Минбалеев, А.В. Авторское право в сфере массовых коммуникаций : учебное пособие / А. В. Минбалеев ; М-во образования и науки Российской Федерации, Южно-Уральский гос. ун-т, Каф. «Конституционное и административное право». Челябинск, 2010. – 119 с

4. Минбалеев, А.В. Отзыв на диссертацию Кулакова Н. А. на тему «Административно-правовое регулирование в сфере защиты прав патентообладателей» / А.В. Минбалеев // Вестник УрФО. Безопасность в информационной сфере. – 2013. – № 3 (9). – С. 43–50.

5. Минбалеев, А.В. Правовая охрана произведений науки, литературы и искусства по обновленному российскому законодательству / А.В. Минбалеев // Ученые труды Российской Академии адвокатуры. – 2008. – № 3. – С. 28–33.

6. Минбалеев, А.В. Правовая охрана объектов интеллектуальной собственности вуза / А.В. Минбалеев // Ежегодник российского образовательного законодательства. – 2009. – Т. 4. – № 2. – С. 132–145.

7. Минбалеев, А.В. Смежно-правовая охрана баз данных по части четвертой Гражданского кодекса Российской Федерации (комментарии по применению норм) / А.В. Минбалеев // Проблемы права. – 2009. – № 2. – С. 111–113.


8. Минбалеев, А.В. Смежно-правовая охрана баз данных / А.В. Минбалеев // Интеллектуальная собственность. Авторское право и смежные права. – 2011. – № 4. – С. 32–38.

9. Савельев, С.И. Лицензирование программного обеспечения в России / С.И. Савельев. – М.: Инфотропик Медиа, 2012. – 432 с.

Открытый или закрытый исходный код скрипта, в чем разница?

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

В качестве вступления приведу небольшой пример истории из жизни. Предприниматель Екатерина Сергеевна, приобрела программное обеспечения для создания на его безе интернет магазина, на момент покупки Екатерину Сергеевну устраивало практически все, что касалось функционала приобретаемого ПО. В течении нескольких дней был запущен сайт, затем на протяжении месяца сайт наполнялся полезными статьями, писался раздел справки и помощи, активно добавлялись товары. Параллельно с этим была развернута рекламная компания, по привлечению клиентов в интернет магазин. Спустя 6 месяцев, сайт начал приносить доход, и перед предпринимателем встал вопрос о его улучшении, внесении ряда правок, чтобы сделать работу сайта лучше и эффективнее. Екатерина Сергеевна, обратилась к разработчику ПО, собственно у кого оно и было куплено. Но, как оказалось разработчик в данный момент занят, и не может заняться её проектом. Тогда, Екатерина обратилась к стороннему программисту, найти которого не составило большого труда. Подготовила подробный список того, что хочет изменить в своем сайте, и договорилась с ним, о начале работ. Но каково было удивление Екатерины, услышать от программиста ответ: «Я не могу реализовать ваши пожелания, т.к. исходный код ПО закрыт, я не имею к нему доступа». Работа встала.

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

1) код закрыт(скомпилирован, зашифрован, обфусцирован) и его нельзя посмотреть, а следовательно нельзя внести правки, изменения, дополнения;

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

На фоне вышесказанного, возникает вопрос: кто может вносить изменения в работу такого программного обеспечения? Ответ — только разработчик, и то если пожелает, или вы сможете с ним договориться.

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

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

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

Что лучше открытое или закрытое ПО?
Однозначного ответа на этот вопрос нет, в ряде случаев закрытое ПО не чем не хуже открытого. Оно выполняет поставленные задачи, обеспечивая пользователя хорошим функционалом, таких примеров много iOS, Windows, MS Office и т.д. Но если речь идет о бизнесе, который зависит от ПО, и который со временем будет расти требуя внедрения новых идей, выбор однозначно падает на программное обеспечение с открытым исходным кодом!

Образование | Термины и понятия открытого кода

Ната­лья Бара­но­ва

Всего материалов: 584

Термины и понятия открытого кода

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

Мастер Йода рекомендует:  Как создать CDN с Kubernetes

FOSS (Free and Open Source Software) – эту аббре­ви­а­ту­ру исполь­зу­ют, когда гово­рят про сво­бод­ное и откры­тое про­грамм­ное обес­пе­че­ние с откры­тым исход­ным кодом.

Откры­тое про­грамм­ное обес­пе­че­ние (open-source software) – это про­грамм­ное обес­пе­че­ние с откры­тым исход­ным кодом, кото­рый досту­пен для про­смот­ра, изу­че­ния и изме­не­ния. Поль­зо­ва­тель может сам дора­бо­тать откры­тую про­грам­му с помо­щью кода. Откры­тое ПО поль­зо­ва­тель может исполь­зо­вать и изме­нять под свои тре­бо­ва­ния.

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

Извест­ные откры­тые про­грам­мы: веб-сер­вер Apache, опе­ра­ци­он­ная систе­ма Linux и бра­у­зер Netscape Navigator.

Исход­ный код – текст ком­пью­тер­ной про­грам­мы на каком-либо язы­ке про­грам­ми­ро­ва­ния или язы­ке раз­мет­ки, кото­рый может быть про­чтен чело­ве­ком. Наи­бо­лее попу­ляр­ные язы­ки про­грам­ми­ро­ва­ния: C, C ++, Fortran, Java, Perl, PHP , Python. Откры­тый исход­ный код рас­про­стра­ня­ет­ся под откры­той лицен­зи­ей.

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

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


Donationware (от англий­ско­го donation «пожерт­во­ва­ние» и software «про­грамм­ное обес­пе­че­ние», сокра­щен­но donateware) – один из вари­ан­тов моне­ти­за­ции про­ек­тов с откры­тым кодом. Дело в том, что откры­тое ПО не все­гда рас­про­стра­ня­ет­ся бес­плат­но. Раз­ра­бот­чи­ки внед­ря­ют раз­лич­ные схе­мы под­держ­ки про­ек­та.

Напри­мер, попу­ляр­ная модель donateware пред­по­ла­га­ет, что поль­зо­ва­те­ли могут сде­лать пожерт­во­ва­ние и тем самым под­дер­жать раз­ра­бот­чи­ков. При этом поль­зо­ва­те­лю предо­став­ля­ет­ся пол­но­стью функ­ци­о­ни­ру­ю­щее про­грамм­ное обес­пе­че­ние.

Впер­вые такой спо­соб был опро­бо­ван в 1987 году для игры Ballerburg. Про­грам­мист рас­про­стра­нял игру бес­плат­но, но про­сил о пожерт­во­ва­нии, пред­ла­гая вза­мен исход­ный код игры.

LAMP – груп­па откры­тых про­грамм с откры­тым исход­ным кодом для созда­ния и запус­ка веб-сер­ве­ров. Аббре­ви­а­ту­ра обра­зо­ва­на от пер­вых букв вхо­дя­щих в груп­пу ком­по­нен­тов: опе­ра­ци­он­ная систе­ма Linux, веб-сер­вис Apache, сво­бод­ная систе­ма управ­ле­ния базой дан­ных MySQL, язык про­грам­ми­ро­ва­ния PHP. В широ­ком смыс­ле под тер­ми­ном пони­ма­ют неза­ви­си­мый и гиб­кий под­ход к созда­нию сер­вер­но­го при­ло­же­ния.

Github – круп­ней­шая плат­фор­ма для раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния и его хостин­га на облач­ном сер­ве­ре. Сооб­ще­ство объ­еди­ни­ло более 24 мил­ли­о­нов чело­век. На сай­те раз­ра­бот­чи­ки пуб­ли­ку­ют свои про­ек­ты с откры­тым исход­ным кодом, про­смат­ри­ва­ют код друг дру­га, остав­ля­ют ком­мен­та­рии и помо­га­ют в раз­ра­бот­ке. Исход­ный код про­ек­та хра­нит­ся в репо­зи­то­рии, так назы­ва­ют хра­ни­ли­ще исход­но­го кода ваше­го про­грамм­но­го про­ек­та.

Напри­мер, такие ком­па­нии как Microsoft, Google, Facebook исполь­зу­ют дан­ный ресурс для раз­ме­ще­ния исход­ных кодов сво­их раз­ра­бо­ток. Теп­ли­ца соци­аль­ных тех­но­ло­гий так­же все­гда пуб­ли­ку­ет исход­ный код про­ек­тов на Github.

Ключевые организации

Про­ект GNU – опе­ра­ци­он­ная систе­ма типа Unix, состо­ит из мно­же­ства сво­бод­ных про­грамм: при­ло­же­ний, биб­лио­тек, средств раз­ра­бот­ки, игр. Назва­ние про­ек­та про­изо­шло от фра­зы GNU’s Not Unix.

Про­ект осно­вал про­грам­мист Ричард Столл­ман в 1984 году, имен­но с его запус­ка нача­лось дви­же­ние в под­держ­ку сво­бод­но­го про­грамм­но­го обес­пе­че­ния. У про­ек­та есть соб­ствен­ная лицен­зия GNU General Public License (GNU GPL) для ПО.

Фонд сво­бод­но­го про­грамм­но­го обес­пе­че­ния (Free Software Foundation, FSF) – неком­мер­че­ская орга­ни­за­ция, кото­рую осно­вал Ричард Столл­ман в 1985 году. Сей­час сотруд­ни­ки и доб­ро­воль­цы фон­да рабо­та­ют над юри­ди­че­ски­ми и орга­ни­за­ци­он­ны­ми вопро­са­ми в обла­сти сво­бод­но­го ПО.

При под­держ­ке ЮНЕСКО фонд раз­ра­бо­тал ката­лог сво­бод­но­го ПО Free Software Directory. Так­же фонд учре­дил две пре­мии: за про­дви­же­ние сво­бод­но­го про­грамм­но­го обес­пе­че­ния и сво­бод­но­го ПО за соци­аль­но зна­чи­мые про­ек­ты.

Open Source Initiative – неком­мер­че­ская орга­ни­за­ция, кото­рая зани­ма­ет­ся защи­той и про­дви­же­ни­ем про­грамм­но­го обес­пе­че­ния с откры­тым исход­ным кодом. Ее созда­ли хаке­ры, про­грам­ми­сты-хаке­ры Эрик Рей­монд и Брюс Перенс в 1998 году. Дея­тель­ность орга­ни­за­ции под­дер­жи­ва­ют и спон­си­ру­ют круп­ные ком­па­нии: Facebook, GitHub, Google, Heptio, Hewlett Packard Enterprise, IBM и Percona.

Исходный код (11 фото + 1 видео + 1 гиф)

2 января британский программист Джон Грэм-Камминг решил оценить фантастический фильм «Элизиум» (Elysium). Во время просмотра он из любопытства вбил в поисковик строки компьютерного кода, показанного в картине. К своему удивлению, Джон обнаружил их в третьем издании инструкции для разработчиков программного обеспечения компании Intel.

Выложив свое наблюдение в твиттер, Грэм-Камминг получил больше 500 ретвитов.

Программист понял, что идею можно развить в форме блога. Незамысловато озаглавив страничку на Tumblr «Исходный код из сериалов и кино», он написал свой первый пост уже 3 января. С тех пор блог регулярно пополнялся новыми находками Джона.

Терминатор в одноименном фильме Джеймса Кэмерона на самом деле смотрит на код для процессора 6502, используемого в компьютерах Apple II. Он был позаимствован из журнала Nibble.

Спустя две недели блог набрал более 12 тысяч подписчиков, а Грэм-Камминг начал получать сотни предложений для публикаций каждый день.

В сериале «Революция» Джей-Джей Абрамса и Эрика Крипке показан код открытой программы для работы с биометрическими данными. Создатели озаботились максимальной достоверностью.

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

В скоропостижно закрытом сериале «Ангелы Чарли», вышедшем в эфир в 2011 году, сейф взламывают с помощью кода, решающего судоку. Пасхалка для самых внимательных.

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

Код, показанный в «Социальной сети» Дэвида Финчера, был написан специально для фильма.

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


В сериале «Элементарно» действительно используется упомянутый в нем язык программирования Malbolge, однако в реальности зашифрованное послание, полученное Холмсом, гласит «Hello, World!»

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

В клипе группы Ramona Falls на песню Fingerhold используется исходный код игры Doom.

Создатель спецэффектов в сериалах «Последователи» и «Карточный домик» Боб Ландерманн в разговоре с Wired предположил, что для фильмов вроде «Железного человека» чаще всего нанимают специалистов в области языков программирования. Если картина рассказывает о компьютерном гении, вероятность того, что зрители поставят ее на паузу и попробуют прочитать написанное на экранах, значительно выше.

«Думаю, большинство людей удивятся, когда узнают, что «экраны» для большинства телесериалов создаются меньше, чем за 8-часовой рабочий день.Боб Ландерманн»

В сериале «Стрела» показан код, который рассчитывает положение лун Юпитера.

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

В культовом хакерском фильме «Пароль «Рыба-меч»» используется реальный код для взлома симметричного алгоритма шифрования DES, разработанного IBM в семидесятые.

Однажды Ландерманна попросили сделать экран отправки почты для сериала «Белый воротничок». Компьютер должен был стоять далеко от камеры, поэтому в качестве примера дизайнер использовал скриншот собственной почты с большим количеством личной информации, включая покупки на Amazon и счета на оплату учебы. По иронии судьбы компьютер было решено показать крупным планом. После выхода сезона на DVD Ландерманну на e-mail еще долго приходили шутливые письма.

Код из фильма «Штурм Белого дома» во время просмотра трейлера к своему удивлению узнал сам его автор.

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

Открытый исходный код

25.07.2012 11:06

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

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

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

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

Рассмотрим один из самых ярких примеров программного обеспечения, которое сопровождает открытый исходный код, получивший всемирное распространение. В начале 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-драйвера существуют далеко не для всех моделей устройств компьютера, что вызовет неправильную работу системы.

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

Что такое Исходный код?

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


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

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

Программисты часто переносят исходный код (в виде модулей, в имеющемся виде или с адаптацией) из одного проекта в другой, что носит название повторного использования кода (Software reusability).

Надежность и безопасность: открытый код против закрытого

Выпуск программного обеспечения с открытым кодом стал одним из важнейших ИТ-направлений. Но по мере роста популярности открытых систем все острее встают вопросы их надежности и безопасности.

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

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

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

Надежность и безопасность открытых и частных систем

Сегодня горячо обсуждаются надежность и безопасность открытых систем. Частные поставщики финансируют исследования и публикуют отчеты, свидетельствующие о том, что системы с закрытым кодом безопаснее их открытых аналогов. Но на каждый отчет, восхваляющий превосходство частных систем в этом отношении, открытое сообщество отвечает «опровергающим» отчетом. Возможно, основная причина горячих дебатов состоит в том, что широкое распространение открытой модели угрожает доходам поставщиков частного программного обеспечения. В недавних квартальных отчетах для Комиссии по ценным бумагам и биржам США компания Microsoft, один из крупнейших производителей ПО, заявила, что популяризация и распространение открытых систем представляют собой существенную угрозу ее бизнес-модели [1].

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

Доступность исходного кода

В июне 2002 года институт Alexis de Tocqueville Institution, частично финансировавшийся Microsoft, опубликовал работу [2]. Среди самых спорных ее результатов был вывод о том, что в госучреждениях использование программного обеспечения с открытым кодом по лицензии GPL (General Public License) может стать проблемой для национальной безопасности. Основанием для этого вывода стало такое предположение: общедоступность исходного кода провоцирует хакеров к исследованию его уязвимостей, разработке «троянских коней» и других типов вредоносных программ. Доступность исходного кода была представлена как существенная угроза для безопасности госорганизаций, применяющих открытое ПО.

Мастер Йода рекомендует:  Курс «Углубленное программирование на CС++»

Такой вывод далеко не бесспорен. Подразумевается, что частные системы с закрытым исходным кодом автоматически более безопасны (для них характерна так называемая «безопасность благодаря непостижимости»). Если это так, число выявленных уязвимостей в закрытых системах должно быть значительно меньшим, чем в открытых аналогах. Однако по опубликованным данным множество открытых систем имеют существенно более низкие рейтинги уязвимостей, чем их частные аналоги. Например, по сведениям координационного центра по безопасности CERT Coordination Center (www.cert.org), в Web-сервере с открытым кодом Apache HTTP Server (httpd.apache.org) обнаружено существенно меньше уязвимостей, чем в Microsoft Internet Information Server, и лишь немногим больше, чем в Netscape Enterprise Server.

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

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

Есть, конечно, и примеры небезопасности открытых систем. Программные дефекты в открытой почтовой программе sendmail были любимой мишенью для нападок в течение многих лет. В ноябре 1988 года студент Корнельского университета Роберт Моррис создал первый Internet-червь [4]. Отчасти из-за уязвимостей в программах sendmail и fingerd он быстро распространился по Internet и привел к массовым отказам компьютеров. Согласно одному из отчетов, червь Морриса затронул 6 тыс. из 60 тыс. (10%) систем Internet, причем Моррис обнаружил эти уязвимости при анализе исходного кода программ sendmail и finger. Однако та же доступность исходного кода позволила Internet-сообществу быстро среагировать на угрозу и смягчить ее последствия. В [5] отмечается: «Доступность исходного кода очень важна. Все стороны, которые быстро откликнулись и достигли успеха в понимании природы вируса, имели исходный код Unix».

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

В данном случае различие между широко распространенными открытыми системами и их частными аналогами проявляется в ценности применения исходного кода при ответе на угрозы. Наличие исходного кода оказалось критически важным для системных администраторов при борьбе с червем Морриса в 1988 году. Технические специалисты рассмотрели исходный код атакованных систем, нашли уязвимости и разработали меры защиты против конкретной угрозы и будущих нападений. Преимущество обладания исходным кодом было подчеркнуто в отчете корпорации MITRE [6], опубликованном в июле 2001 года. В нем утверждалось, что в открытом сообществе «популярные продукты с открытым кодом подвергаются обширной экспертизе, позволяющей программному обеспечению достичь высокого уровня эффективности» и что программные заплаты и исправления выпускаются «потенциально на порядок быстрее, чем в случае частного программного обеспечения».

Уровни дефектности

Любой пакет программ, открытый или закрытый, имеет множество недостатков, и их процент непосредственно влияет на безопасность системы. По данным Software Engineering Institute, опытный программист «пропускает» приблизительно один дефект на 100 строк кода [7]. Если в течение жизненного цикла программного обеспечения 99% этих дефектов будут обнаружены и исправлены, то в пакете программ, состоящем из 1 млн. строк исходного кода (довольно скромный объем по современным стандартам), останется примерно 1 тыс. дефектов.

Например, дистрибутив Red Hat Linux 7.1 состоит приблизительно из 30 млн. строк кода, а Microsoft Windows XP содержит около 40 млн. строк. Даже с учетом обширных испытаний и работы по устранению недостатков в этих системах все еще остается масса программных дефектов. Используя упомянутую статистику, число невыявленных дефектов в Windows XP и Red Hat Linux можно оценить, соответственно, как 40 тыс. и 30 тыс. Кроме того, частные и открытые системы постоянно развиваются. В ходе жизненного цикла в систему добавляются новые функции, а дефекты обнаруживаются и устраняются. А поскольку большинство программных пакетов находятся в состоянии постоянного развития, трудно оценить число дефектов конкретной системы.

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

Итак, каждый выпуск открытой или частной программы содержит множество дефектов. Имеющиеся данные, однако, показывают, что когда недостаток программного обеспечения обнаружен, открытое сообщество реагирует быстрее, чем частные поставщики. Согласно [8], открытые организации обычно реагируют на проблемы быстро и откровенно, тогда как частные поставщики «инстинктивно тянут, скрывают и отрицают». Открытые организации вносят небольшие поправки, которые становятся общедоступными через списки рассылок и Web-сайты. Пользователи могут загрузить обновление, применить заплату и восстановить систему. Сама заплата, в свою очередь, является сегментом исходного кода, который доступен для публичной ревизии. Напротив, частные поставщики стремятся выжидать и выпускать большие сводные пакеты обновлений. Они обычно содержат только двоичный код, который закрыт для публичного исследования и потенциально может внести в систему новые проблемы. При этом пользователям приходится слепо доверять честности и компетентности производителя.


Независимые исследования

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

В 1990 году профессор Бартон Миллер из Университета штата Висконсин разработал инструмент тестирования fuzz, который подавал случайные потоки данных на вход программ из нескольких частных версий Unix [3]. Миллер обнаружил, что 24-33% программ отказали под воздействием этих данных, и каждый из отказов мог быть непосредственно отнесен к программному дефекту. Правильно написанная программа не должна выходить из строя при получении неожиданных или случайных данных.

В 1995 году Миллер включил в испытания также утилиты Linux и другие свободно доступные программы из проекта GNU. Он протестировал свыше 80 утилит из девяти версий Unix. Семь из них принадлежали частным поставщикам, а две были разработаны открытым сообществом. Основные результаты исследования, опубликованные в [9], свидетельствуют о следующем. С момента первого исследования частные системы улучшились, и коэффициент их отказов снизился с 24-33 до 18-23%. В открытых системах утилиты Linux заняли второе место с коэффициентом отказов примерно 9%. Самым низким был коэффициент отказов утилит GNU, который составил 6%. Итак, популярные открытые реализации утилит Unix существенно более устойчивы к неожиданным данным, чем их частные аналоги, что указывает на более высокие качество и надежность утилит с открытым кодом. Нельзя сказать, что все открытые системы надежнее частных, но они могут быть качественнее коммерческих разработок.

В другом исследовании, предпринятом в 1999 году независимой консультационной и аналитической организацией Bloor Research из Великобритании, сравнивались Windows NT и GNU/Linux [10]. Испытание проводилось в течение года, и каждая из платформ оценивалась по девяти критериям. GNU/Linux была оценена выше, чем Windows NT, по семи критериям.

Так, по критерию готовности ОС GNU/Linux получила значительно более высокую оценку, чем Windows NT. За год GNU/Linux не продемонстрировала ни одного отказа, который можно отнести на счет программного обеспечения. Однако аппаратный отказ из-за сбоя жесткого диска послужил причиной отключения системы, которое продолжалось четыре часа. Итоговый коэффициент готовности GNU/Linux составил 99,95%. За тот же период система Windows NT «выдала» 68 отказов: один был отказом жесткого диска, 26 были связаны с ошибками управления памятью, восемь относились к ошибкам файловой системы, а остальные имели неизвестное происхождение. Потери времени из-за этих отказов составили 65 часов, что дало коэффициент готовности Windows NT, равный 99,26%. Результаты исследования убедительно показывают, что открытые системы могут по меньшей мере на равных конкурировать с частными аналогами, обеспечивая устойчивые и надежные серверные платформы.

Сегодня несколько компаний предлагают услуги проверки программного обеспечения, что позволяет производителям отдавать проверку кода на аутсорсинг. Фирма Reasoning почти 20 лет помогает организациям улучшать качество систем путем автоматизированной проверки программного обеспечения и считается лидером в этой области. В 2003 году Reasoning провела исследование реализации протокола TCP/IP в ядре Linux версии 2.4.19 и в пяти частных операционных системах [11]. Цель состояла в применении автоматизированных методов проверки кода для сравнения качества и уровней дефектности разных реализаций протокола. Выяснилось, что коэффициент дефектности для кода Linux составлял 0,1 дефекта на 1 тыс. строк кода, а для частных реализаций — 0,55. Reasoning пришла к выводу, что открытая реализация TCP/IP имеет значительно меньшую плотность дефектов, чем реализации в пяти частных операционных системах. Исследование также показало, что по общему качеству открытая система находится в первой трети списка рассмотренных проектов.

В июле 2003 года Reasoning проанализировала популярный открытый Web-сервер Apache [12], разработанный и поддерживаемый некоммерческой корпорацией Apache Software Foundation (www.apache.org). По данным Netcraft [13], сейчас Apache является доминирующим HTTP-сервером в Internet. В июне 2004 года он занимал 67% рынка, составлявшего 51,6 млн. серверов, а на долю продуктов Microsoft приходился 21%. Если столь много организаций полагаются на открытые технологии при организации своих Internet-представительств, то очевидно, что ИТ-администраторам был бы полезен независимый от поставщика показатель качества ПО, помогающий при выборе между открытыми и частными системами. Reasoning пришла к выводу, что коэффициент дефектности Apache версии 2.1 составляет 0,53 на 1 тыс. строк кода. В Reasoning сравнили плотность дефектов Apache с 200 другими открытыми и частными программами общим объемом 33 млн. строк кода. В первой трети списка этих проектов коэффициент дефектности был менее 0,36, во второй трети — от 0,36 до 0,71, а в последней трети — более 0,71. Коэффициент дефектности системы Apache попадает примерно в середину списка и несколько превосходит средний коэффициент дефектности частного программного обеспечения (по оценкам Reasoning, он составляет 0,51).

Reasoning продолжила исследования качества открытых систем на примере исходного кода ведущей открытой СУБД MySQL версии 4.0.16 [14]. В декабре 2003 года в Reasoning проверили 236 тыс. строк исходного кода MySQL и обнаружили в системе 21 программный дефект. Качество кода MySQL оказалось в шесть раз выше, чем в среднем у сопоставимого частного кода (коэффициенты дефектности, соответственно, 0,09 и 0,51). Разработчики MySQL быстро устранили обнаруженные проблемы и выпустили версию 4.0.17.

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

Процессы разработки

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

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

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

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

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

Наглядной иллюстрацией служит разработка Web-сервера Apache. Система Apache возникла в 1995 году из набора заплат (patch) для исходного кода популярного в то время Web-сервера Национального центра суперкомпьютерных приложений США. Этим заплатам система и обязана своим названием (игра слов: Apache server — a patchy server, то есть «заплаточный сервер» — Прим. перев.). Заплаты были предоставлены пользователями сервера (в то время почти лишенного поддержки), которые нуждались в дополнительных функциях. Потребители имели доступ к исходному коду сервера и могли изменять систему в соответствии со своими нуждами. Изменения поступали в группу добровольцев, поддерживающих систему.

В конечном счете эта группа отказалась от первоначального набора заплат и полностью перепроектировала систему. В декабре 1995 года был официально выпущен сервер Apache версии 1.0, который, как уже отмечалось, быстро стал доминирующим Web-сервером в Internet. По мере роста популярности системы Apache росло и число организаций, полагающихся на нее при решении своих основных задач. Как следствие, множилось число участников проекта. Группа добровольцев, рассматривавших усовершенствования и поддерживавших исходный код Apache, продолжала расти, в 1995 году превратившись в Apache Group, в 1999-м была преобразована в Apache Software Foundation.

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

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

Закрытое или открытое?

Что безопаснее — закрытое или открытое программное обеспечение? К сожалению, однозначного ответа пока нет. Открытые и частные системы не имеют явных преимуществ друг перед другом с точки зрения безопасности и надежности, а доводы в пользу любого из подходов не имеют окончательного характера. Эмпирические исследования показали, что открытые системы потенциально могут превзойти частные, но если безопасность не заложена при проектировании, то система защищенной не будет. Есть, конечно, частные системы, более защищенные, чем их открытые аналоги (например, S/COMP или GEMSOS в сравнении с GNU/Linux). Есть и открытые системы, которые кажутся более безопасными, чем их частные эквиваленты (например, Apache в сравнении с IIS).

Одним из препятствий при количественной оценке безопасности частных и открытых систем является то, что достоверно заслуживающие доверия системы очень трудоемки и дороги в разработке и сертификации. Пока существуют лишь семь операционных систем, достигших четвертого уровня CC EAL (Common Criteria Certification Evaluation Assurance Level), который означает «систематически разработанная, проверенная и проанализированная» [17]. Среди открытых операционных систем самый высокий рейтинг CC EAL, который составляет 3+ (т.е. «систематически протестированная и проверенная»), имеет дистрибутив SuSE Enterprise Server V8. Отсюда вовсе не следует, что открытые операционные системы с меньшими рейтингами менее надежны, чем частные. Это может означать, что не удалось добиться финансирования официальной сертификации. Поскольку сертификат Common Criteria дорог, только крупные организации позволяют себе субсидировать его получение, особенно на высших уровнях сертификации.

Мастер Йода рекомендует:  6 плагинов WordPress, которые позволят сайту оставаться в тренде

Другая проблема состоит в том, что любая программная система требует частого внесения исправлений для устранения дефектов, а это само по себе небезопасно. Использование подсчета заплат в качестве меры защиты может ввести в заблуждение. Система, требующая заплат в механизмах обеспечения безопасности каждые полгода, не является вдвое более безопасной, чем система, которая требует внесения исправлений каждые три месяца. Они обе небезопасны. Программные системы постоянно изменяются, и при всяком устранении старых дефектов в систему могут быть введены новые. Пока нет простого способа определения абсолютного числа дефектов системы. Однако открытые системы имеют явное преимущество в ответах на угрозы. К примеру, организации, которые наиболее успешно справлялись с червем Морриса в 1988 году, имели доступ к исходному коду Unix. Наличие исходного кода позволило техническому персоналу понять угрозу и поделиться этой информацией с другими организациями.


Именно совместное использование информации — ключевая сила открытого движения. Разработчики открытого кода могут анализировать предыдущие системы и «стоять на плечах гигантов». Как и в научно-исследовательском сообществе, свободный обмен информацией способствует продвижению новшеств и расширению поля деятельности. Открытое движение может использовать обобществленную информацию для привлечения талантов из неисчерпаемого источника. Рост числа пользователей открытого проекта означает и рост количества его потенциальных разработчиков. Как только сформирована критическая масса пользователей, импульс объединенных усилий приводит к появлению высококачественных систем, которые по надежности и безопасности превосходят частные аналоги — при значительно меньшей стоимости.

Литература
  1. Securities and Exchange Commission Form 10-Q Quarterly Report For the Quarterly Period Ended 2004, March 31. Microsoft, 2004.
  2. Opening the Open Source Debate: A White Paper, Alexis de Tocqueville Institution. June 2002; www.adti.net/opensource.pdf.
  3. B. Miller, L. Fredriksen, B. So, An Empirical Study of the Reliability of UNIX Utilities. Communications of the ACM, 1990, No. 12.
  4. K. Hafner, J. Markoff, Cyberpunk: Outlaws and Hackers on the Computer Frontier. Simon & Schuster, New York, July 1992.
  5. M. Eichin, J. Rochlis, With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988. Proceedings of the 1989 IEEE Symposium on Security and Privacy, Oakland, CA. New York, 1989, May 1-3.
  6. C. Kenwood, A Business Case Study of Open Source Software. MITRE Corporation. July 2001; www.mitre.org/work/tech_papers/tech_papers_01/ kenwood_software/kenwood_software.pdf.
  7. W. Humphrey, The Quality Attitude. Software Engineering Institute, 2004; www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/watts-new-2004-3.htm.
  8. J. Papoza, eWeek Labs: Open Source Quicker at Fixing Flaws, Ziff-Davis Media, September 30.
  9. B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan, J. Ste >Алан Буланже (boulange@us.ibm.com) — сотрудник лаборатории анализа глобальной безопасности исследовательского центра IBM Thomas Watson Research Center.

A. Boulanger, Open-source versus proprietary software: Is one more reliable and secure than the other? IBM Systems Journal, Vol. 44, No. 2, 2005. Copyright 2005, International Business Machines Corporation. All rights reserved. Reprinted with permission.

Антивирусная прав ДА! TM

Кругозор без горизонтов

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

  • добавить в избранное

Исходный код открыт для всех

21 ноября 2020 года случилось странное. GitHub-
пользователь @FallingSnow сообщил, что в одной из
зависимостей event-stream спрятан вредоносный код,
который фактически представляет собой бэкдор
неизвестной функциональности.

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

Рассмотрим доводы сторонников такого подхода.


Любой желающий может проанализировать код программы и понять, что она делает на самом деле.

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

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

Открытое сообщество разработчиков следит за вкладом каждого участника и анализирует изменения, которые он внес.

Безусловно. Но по мере того, как сообщество разрастается, контролировать вклад каждого участника становится все сложнее.

Итак, началось расследование. Благодаря истории коммитов на GitHub сразу стало понятно, что вредоносный коммит сделал другой пользователь @right9ctrl, которому были предоставлены права мейнтейнера для event-stream. На его счету ряд нормальных коммитов, а автор проекта Доминик Карр (@dominictarr) передал ему права мейнтейнера.

Инструменты контроля версий — такие, например, как используются на Github — позволяют не допустить несанкционированного изменения программы.

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

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

И атака на event-stream является этому отличным примером. Что такое event-stream? Это всего лишь модуль, используемый для обработки потоков в Node.JS, то есть вспомогательный инструмент для реализации более крупных проектов. Любопытно отметить, что вредоносный код был внедрен даже не в саму библиотеку event-stream: в нее была добавлена зависимость на сторонний пакет, содержащий бэкдор.

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

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

Dr.Web рекомендует

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

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

Исходники

  • Компоненты Delphi (68)
  • Лабораторные работы, учеба (321)
  • Операционные системы, драйверы (40)
  • Офисные приложения (34)
  • Простенькие программки, библиотечки, мышка (401)
  • Серьезные программы (118)
  • Сеть, протоколы, модемы (75)
  • Форматы файлов (233)

  • Web, PERL, PHP, JavaScript (129)
  • Другое (160)

крестики нолики со вкусом))
сами увидите обязательно прочитете тхт файл

ilyosiddin_kalandar@mail.ru
по любому вопросу

Пример оконной программы на ассемблере, работающей под win32win64 операционными система, с использованием winAPI. Компилятор FASM.

Программа принимает текстовые данные из полей Editbox0, Editbox1, при нажатии кнопки, с помощью вызова WinAPI функции MessageBox выводиться окно с названием которое было получено из EditBox1, и текстом из Editbox0
\\\\\\\\\

Example of a window program in an assembler working under win32 win64 operating systems using winAPI. FASM compiler.

The program accepts text data from the Editbox0, Editbox1 fields, when you click a button, by calling the MessageBox WinAPI function, a window is displayed with the name that was obtained from EditBox1, and the text from Editbox0

Исходник:
(Source:)
https://catcut.net/mAPB
Канал ютуб:
https://www.youtube.com/ТипаПрограммист
Сайт проекта:
https://neosoft.pp.ua

Пример консольной программы, работающей под win32win64 операционными система, с использованием winAPI. Компилятор FASM.
help — Выводит на экран текст с списком команд.

An example of a console program running under win32 win64 operating system using winAPI. FASM compiler.

Test commands were created to display the health:
help — Displays text with a list of commands.
clear — Clears the screen.
title — Changes the name of the console window.
quit — Exit the program.

————————————————————————————————————
Использованы WinAPI функции:
(Used WinAPI functions:)
— AllocConsole
— FreeConsole
— CreateFile
— WriteFile
— ReadFile
— SetConsoleTitle
— FillConsoleOutputCharacter
— SetConsoleCursorPosition
— ExitProcess

Исходник:
(Source:)
https://catcut.net/tAPB
Ютуб канал:
https://www.youtube.com/ТипаПрограммист
Сайт проекта:
https://neosoft.pp.ua

Пример простой Raycast графики с возможностью перемещения по карте, и вращения камеры, на ассемблере компилятор FASM, работает в реальном режиме. Используется 13h видео режим BIOS 320х200, 256 цветовой режим.

Используются прерывания BIOS
— INT 10h
— INT 16h

Возможности графической оболочки:
— Заливка экрана
— Рисование спрайтов
— Рисования прямоугольников ( простых линий )
Особенности графической оболочки
— Небольшой вес, простота
— Использование видео буфера для создания фрейма

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

Плюсы этого исходника:
— Почти полностю рабочий raycast
— Возможность вращения камеры
-Возможность перемещения в пространстве.
Минусы:
— Низкая производительность нужна оптимизация

Исходник игры (source):
https://catcut.net/CAPB
Канал ютуб:
https://www.youtube.com/ТипаПрограммист
Сайт проекта:
https://neosoft.pp.ua

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

Созданы дескрипторы для:
— сегмента кода ( Покрывает все 4 Гб )
— сегмента данных ( Покрывает все 4 Гб )
— сегмент видео буфера для текстового режима.

Для работоспособности в режиме трансляции страниц было создано две PTE, страница кода, и страница видео буфера.

Исходник можно скачать здесь:
https://catcut.net/CfzB
Так-же есть канал проекта, где иногда появляються видео, исходники новых программ:
https://youtube.com/ТипаПрограммист

И да у канала есть свой сервер с иходниками, где в основном исходники на ассемблере ( почти все мусор ), а так-же есть на С++, операционная система на Си, и программа на Паскале:
https://catcut.net/7Nqw
При желании добавить свой исходник на сервер, пишите мне на почту:
vitaliynovak555@gmail.com
( Да да анонимность не мой конек. )

Сайт проекта:
https://neosoft.pp.ua

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

Как посмотреть и редактировать исходный код open source программы

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

Несмотря на то, что открытый исходный код абсолютно точно можно назвать хорошим выбором, вам также надо будет инвестировать в «правильное» сообщество. Мы расскажем про сервис, который представляет собой один из лучших подобных ресурсов не только из-за огромной численности пользователей, но также и благодаря свойствам, которые предлагает система. Если вы найдете любую программу с открытым исходным кодом на GitHub, вам будет представлено несколько опций, включая просмотр, редактирование и создание форка (использование кодовой базы в качестве старта для другого – прим. Wikipedia).

Создаем аккаунт

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

Просматриваем программу

Как только вы создадите аккаунт, вы сразу же можете приступать к рассмотрению приложений с открытым исходным кодом. Здесь вы можете видеть страницы приложений, включая папки и файлы, присущие приложению, сетевую графу, список запросов, проблемные места, wiki-страницу и другие графы. Очевидно, если вам небходимо будет увидеть код из файлов, кликните по ним, и перед вами предстанет полноценный исходный код. В зависимости от представленного кода, вам могут понадобиться фоновые знания различных языков программирования, на одно из которых может быть написана программа, будь то Java, C++, Python или какой-нибудь еще. Если вам до сих пор что-то не понятно, взгляните на представленный ниже скриншот:

Форкинг проекта

Редактирование кода требует несколько дополнительных этапов. Если вы хотите скопировать код без официального форкинга на GitHub, то скачайте файлы, а затем отредактировать их локально. Тем не менее, если вы хотите взять доступный код, и на его основе создать собственный проект, вам следует сделать форкинг. Форкинг можно сделать посредством зарегистрированного аккаунта – нажмите «Fork» на странице, как показано на скриншоте. Следующие инструкции предназначены для пользователей Linux, которым нужно установить пакет Git для дальнейшей дистрибуции.

Если вы хотите получить файлы из репозитория на свой компьютер, вам нужно запустить команду git clone, заменив username на ваш логин в GitHub, а project_name на название приложения, с которого вы реализуете форкинг. Запустите эту команду в папке, которая должна содержать все проекты, так как каждая команда git clone создает новую папку внутри той, с которой вы работаете. Это еще один способ скачать файлы, так как для этого не требуется авторизация. Теперь вы можете изменить файлы по собственному усмотрению, используя любой текстовый редактор или IDE. Что касается пользователей Linux, я порекомендовал бы Eclipse или Geany, так как они представляют собой отличные редакторы для программирования – Eclipse больше укомплектован функциями, а Geany более удобный. Пользователи Windows также могут воспользоваться родным GitHub-клиентом.

Загружаем изменения

Как только вы закончите вносить правки, вы можете загрузить обновленные файлы обратно на Github посредством команды git push origin master, находясь внутри папки приложения. Это позволит перенести изменения в «источник» (на основе которого вы делаете личный), и в главную ветвь (стандартное расположение исходного кода).

Следим за потоком

Если вы хотели бы и дальше следить за развитием проекта, с которого вы использовали основу, то вам нужно добавить кое-что, что принято называть дополнительным удаленным. Это просто еще один ключ, который вы можете использовать, находясь внутри папки приложения. Чтобы создать новый удаленный проект, запустите команду git remote add upstream, где username нужно заменить на логин из исходног, а project_name нужно заменить на название его проекта.

Если вы заметили, что главный проект обновляется, и вы хотели бы принять эти правки, то нужно запустить команду git pull upstream после того, как будет создан дополнительный удаленный, и GitHub скачает и внесет изменения из основного в файлы вашего. Если все будет работать после запуска, вы можете сразу же запустить команду git push origin master, чтобы извлечь обновления для вашего собственного проекта.

Предлагаем редактирование

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

В завершение

GitHub – это невероятный инструмент с большим объемом открытого кода проектов, которыми уже пользуются многие разработчики. В то время, как этот сервис использует Git-утилиту, которую каждый может настроить на собственных серверах, сервис также включает в себя отличное сообщество разработчиков – неотъемлемую и важную часть открытого кода. Данное введение в курс дела должно помочь вам познакомиться с основами. Если вам хочется узнать больше о самом процессе разработки кода, вы можете взглянуть статью, в которой описываются лучшие сайты, помогающие изучить C++.

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

Добавить комментарий