February 2016 Download this article as a PDFAbstract

Разработчики программного обеспечения кибербезопасности часто включают и полагаться на открытые программные пакеты в своих коммерческих программных продуктов. Перед открытым исходным кодом впитывается в собственнический продукт, разработчики должны проверить пакет лицензии, чтобы увидеть, если проект permissively лицензию, тем самым позволяя для коммерческих friendly наследования и перераспределения. Однако существует опасность того, что лицензия открытого исходного пакета может быть неточным из-за заражения молча с ограничительно лицензированным открытым исходным кодом, который может запретить продажу или конфиденциальность коммерческой производной работы. Загрязнение коммерческих продуктов может привести к дорогостоящим восстановительных расходов, ущерб репутации компании и дорогостоящие судебные издержки. В этой статье мы сообщаем о нашего предварительного анализа более чем 200 открытых источников кибербезопасности проекты для выявления наиболее часто используемых языков и типов лицензий и искать доказательства permissively лицензированных открытым исходным кодом проекты, которые, вероятно, загрязненные ограничительные лицензионные материалы (например, содержащих коммерческие недружественных кода). Наш анализ выявленных ограничительные лицензии загрязнения случаев, происходящих в permissively лицензии open source проектов. Кроме того мы обнаружили большое количество кода, который не хватало авторского права присвоения. Мы ожидаем, что результаты этого исследования будут: i) предоставить менеджерам и разработчикам с пониманием того, как может произойти загрязнение, ii) обеспечивают открытым исходным кодом сообщества с пониманием о как они могут лучше защитить свою интеллектуальную собственность путем включения лицензии и информацию об авторских правах в их коде и ii) ознакомление предпринимателей с открытым исходным кодом кибербезопасности домена с точки зрения лицензирования и загрязнения и как они влияют на решения о архитектуры программного обеспечения кибербезопасности.

Введение

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

Для целей этой статьи мы делим лицензии на две категории: разрешительного и ограничительный характер. Разрешительный категория включает коммерческие дружественные лицензии, такие как BSD, Apache и MIT. Напротив ограничительная категория включает сравнительно коммерческие недружественных лицензии, такие как GPL, которые ограничивают продажу программного обеспечения, которое включает пакет открытым исходным кодом с такой лицензией.

Интеллектуальная собственность и вопросы соблюдения правовых норм могут возникнуть, когда компании не выполняют процесс оценки тщательной лицензии, когда они потребляют открытым исходным кодом. Задача подчеркивается отсутствие принудительного нажмите «Я согласен» условия лицензионного соглашения перед установкой или использованием кода (багор и Ploussios, 2012). Заражение может произойти когда ограничительно лицензированных код копируется в permissively лицензированный проект пакета или когда ограничительно лицензированный пакет копируется в permissively лицензированный проект. Разработчики, которые работают в сжатые сроки могут легко игнорировать лицензионные обязательства что они потребляют, если они не имеют политики и инструментов в целях предотвращения загрязнения (Khanafer, 2015). Эта простота потребления увеличивает риск заражения. Разработчики должны знать ли они потребляют код, который permissively лицензию (например, коммерческие дружественных) или ограничительно лицензированных (например, коммерческие недружественных). В простейшем случае они могут просто проверить путем проверки пакета лицензии (например, файл «readme» или файл «Лицензия»), но осложнения могут возникать, если permissively лицензированный проект автоматически скрывает код под несовместимой ограничительной лицензией. Однако чтобы уменьшить риск заражения, разработчикам не следует предполагать, что же степень осмотрительности была проделана другими разработчиками, которые внесли свой код в другой проект, который в настоящее время потребляется как часть отдельного пакета. Проекты должны заботиться, чтобы не наследуют проблемы других, которые могут распространяться через проекты в вирусной форме как код копируется. В 2007 году обследования Saugatuck Technology 21% респондентов ощущали проблемы безопасности/открыть/общин может сдерживать принятие открытым исходным кодом, в то время как 12% считали, что лицензирование вопросы и риски, являются предметом озабоченности (цитируется в Хасин, 2007). Несоблюдение с открытым исходным кодом, условия лицензирования может привести к дорогостоящим судебному разбирательству, ущерб репутации и расходов, потраченных на восстановление загрязненных кода компании. Например в 2009 году, свобода программного обеспечения охраны природы, Inc принесла судебный иск за нарушение авторских прав против 14 коммерческих электроники дистрибьюторов, включая "Вестингауз" цифровой электроники, Best Buy и Samsung (Klasfelld, 2011). Эти компании распространяется код из BusyBox (открытым исходным кодом инструмент) в своей продукции без соблюдения лицензии BusyBox. Лицензия заявила, что наследники BusyBox должны сделать свой собственный исходный код для общественности. Таким образом нарушения лицензирования и авторских прав, во многих случаях, связанных с загрязнением кода, являются существенных вопросов, затрагивающих поставщиков программного обеспечения, которое использует open source проектов.

В области кибербезопасности мы исследовали степени, на какие проекты с разрешительным открытым исходным кодом пакета лицензий (например, лицензии и README файлы, которые ссылаются на Apache, BSD или MIT) загрязненные ограничительным лицензированный файл (GPL версии 1.0, 2.0, 3.0 ext). Мы рассмотрели более 200 проектов open source кибербезопасности в качестве начального, произвольного исследования. Путем изучения кода загрязнения в open source проектах кибербезопасности и предоставляя соответствующие идеи о том, как можно избежать заражения, мы в конечном итоге стремимся помочь разработчикам сделать чистой и прибыльной продукции.

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

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

Обзор литературы

Ограничительные лицензии обычно считаются «вирусный» потому, что они требуют потребителя лицензионного кода для распространения производных исходный код под этой же лицензией. «Собственный код, распространяемый с или вместе с лицензией GPL [с открытыми исходными кодами] как часть большего программы или приложения могут во многих случаях считаться «крытая работа» вместе с [программное обеспечение open source]. Это означает, что вся крытая работа – собственный код и OSS – могут распространяться только в соответствии с условиями лицензии GPL» (багор и Ploussios, 2012). Разрешительные лицензии позволяют потребителям из открытого проекта распространять или продавать скомпилированный двоичный файл без необходимости подвергать любой код для общественности. Вообще говоря ограничительные лицензии позволяют потребителям открытым исходным кодом проекта распространять скомпилированный двоичный файл при условии, что исходный код двоичного файла должны быть доступны для общественности и что двоичный и исходный код не может быть продан. Не соблюдение условий лицензии в open source программное обеспечение может результаты в претензии нарушении авторских прав или нарушение договора, который в свою очередь может привести к запрету дальнейших продаж, подтопления и уничтожение комбинированного программного обеспечения и оплату юридических услуг (багор и Ploussios, 2012).

Большинство лицензий являются взаимные лицензии означает, что они заставляют все производные произведения, лицензируемой по той же лицензии, связанные с исходной копией компонента (Link, 2011). General Public License (GPL) является наиболее распространенным и заметным примером. Разрешительные лицензии как MIT и Apache имеют меньше ограничений и обычно не требуют от пользователя распространять свои собственные производные работы. Из-за изменения условий в каждом типе лицензии лицензии, могут быть несовместимы друг с другом, если они находятся в том же пакете, открытым исходным кодом. Другими словами Если разработчик рассматривает использование нескольких видов лицензированных open source проектов, существует риск, что лицензии не будут совместимы и что программное обеспечение, поэтому не могут быть объединены (Лохман соавт, 2013). Например пакет, который имеет лицензию Apache 2.0 не совместим с GPL 1.0. Таким образом GPL 1.0 код не в базе кода пакета лицензии Apache. В этой статье термины «лицензионный конфликт» или «загрязнение» относятся к проект с неограничительной лицензией содержит ограничительно лицензированный код.

Влияние на архитектуру лицензирования Open source

Мы определяем производные работы как результат расширения или открытым исходным кодом программное обеспечение для редактирования. В зависимости от разработчика намерения, либо распространять производные работы или публиковать свои работы, сохраняя авторские права собственности, открыть источник законности и необходимо решать вопросы лицензирования. Один из подходов, используется ядро Linux является «периферией план» (Лохман соавт, 2013). Ядро Linux ядра владеет авторскими правами для базовой системы, в то время как приложения, построенные вокруг этой системы (то есть, на периферии) могут быть заменены с различными приложениями, чтобы разрешить любое количество версий или дистрибутивов Linux для различных целей и систем. Такой подход позволяет лицензии совместимые настройки и тем самым обеспечивает удобство, масштабируемость и модульность.

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

Конфликты могут запрещать интеграцию компонентов с открытым исходным кодом и требуют дополнительных усилий, чтобы понять ограничения используемых лицензий (Link, 2011). Рассмотрим разницу между меньшей общей общественной лицензии (LGPL) и GPL. Для кода под LGPL пользователю разрешается динамически связать его с другими компонентами без нарушения или применение LGPL (Лохман соавт, 2013). Напротив этот же сценарий с GPL требует отдельного исполняемого файла, если программный код не выпускается. Таким образом это требование GPL может повлиять на архитектуру всей системы, особенно, когда есть сочетание компонентов проприетарные и открытым исходным кодом. Например, вместо связывания компонентов с GPL компонента с помощью управления приводом связи, управляемые данными отношения должны быть использованы вместо (Хаммуда соавт, 2010). Другой подход заключается в том, чтобы использовать «шаблон изоляции», которая отделяет компоненты от друг друга, чтобы избежать конфликтов лицензий (Хаммуда соавт, 2010). В зависимости от характера системы (например, размещение, распределенных, выпущенный как open source) архитектура системы должна надлежащим образом учитывать лицензионные обязательства.

Загрязнение, ведущие к судебному разбирательству

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

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

  1. Выпуск: сторонних разработчиков создает исходный источник, который выпущен под GPL.
  2. Загрязнение: коммерческая организация «потребляет» код GPL и (сознательно или неосознанно) добавляет код их коммерческий продукт.
  3. Нарушение: коммерческое лицо выпускает их GPL-загрязненных продукт не придерживаясь условий GPL (то есть, они не могут сделать свой собственный исходный код для общественности).
  4. Обвинительное заключение: компания принимает правовые меры против нарушителя GPL не выполнение требований, связанных с условиями GPL.
  5. Разрешение: исход судебных разбирательств.

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

  • Репутационный ущерб
  • Предоставление клиентам ответственности
  • Угрозы нарушения патентных прав для кода, связанные с патентами
  • Собственный код с открытым исходным кодом
  • Уставных убытков
  • Расходы на восстановление повторного написания кода

Метод исследования

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

  1. Распределение ОС Linux Kali (наступление безопасности, 2015)
  2. Министерство национальной безопасности в список открытого программного обеспечения кибербезопасности (DHS, 2012)
  3. Дистрибутив ОС Linux лук безопасности (Burks, 2015)

Был создан общий набор данных из 334 open source проектов кибербезопасности и три уровня анализа был проведен:

  1. Атрибуция: Во всех проектах 334, мы определили степень: i) авторские права в каждом файле, ii) Лицензионная информация в каждом файле, iii) нет авторских прав или лицензии attribution в каждом файле. Цель этого анализа был в том, чтобы определить количество файлов во всех проектах нет авторских прав или лицензии attribution и также какие виды лицензии attribution были применены к файлу, если таковые имеются.
  2. Конфликты лицензий: Из 334 инструменты кибербезопасности открытым исходным кодом, которые мы загрузили инструменты, для которых мы могли бы подтвердить лицензию пакета из проекта веб-сайта или из исходного кода пакета лицензии (например, файл «Копирование» или «Лицензия») были отобраны для анализа конфликтов лицензий. Результирующее подмножество 255 проектов были изучены для доказательства заражения файла GPL в permissively лицензированный пакет. Для поиска шаблонов в появлении лицензии конфликтов, мы оценивали конфликты лицензий в отношении количества строк кода в пакете и типы и количество языков кодирования, используемых в каждом из этих проектов.
  3. Код сторонних: По всей выборке из 243 проектов, где мы могли бы подтвердить лицензии мы оценили объем кода сторонних как доля объема общего кода в каждом проекте. Для поиска шаблонов в появлении лицензии конфликтов, мы оценивали конфликты лицензий против строк кода в пакете.

Провести три уровня анализа, описанных выше, мы отсканированы и анализировали загруженных программных пакетов с помощью Protecode в 4 предприятия системы сканирования кода двигателя. Анализ включает определение количества строк кода на упаковку; вероятно, томов сторонних на упаковку; тип лицензии на упаковку; Языки программирования, используемые на упаковку; Если авторское право или лицензия существует в файле кода; и если существует конфликт лицензий в пакете. Protecode имеется база данных, содержащая миллионы файлов от многих проектов open source, размещенных на нескольких кузниц. При сканировании загруженного кода, Protecode создает подписи и хэши, которые он сравнивает с подписями файлов, хранящихся в базе данных Protecode в. Таким образом Protecode в инструменты можно определить, если все совпадающие файлы, тем самым указав файл или часть файла существует в проект с открытым исходным кодом. Protecode также хранит информацию, касающуюся авторского права и лицензии open source проектов, найденных в базе данных, которая поможет идентифицировать любые конфликты лицензий между открытым исходным кодом компонентов, указанных в отсканированный код.

Результаты

По 255 проектам, где можно определить лицензии 24% имели разрешительной лицензии. Четыре комплекта из 61 permissively лицензированных проектов были подтверждены из загрязненных с кодом GPL. GPL загрязнение было подтверждено, проверяя, если permissively лицензированный пакет содержит файл с GPL присвоения (например, лицензии GPL в файл или ссылку на GPL лицензии в файле). Случаи заражения GPL включают permissively лицензированные пакеты, которые включены один или несколько GPL лицензированные файлы или включая все GPL лицензированные пакеты (*.js, *.py, * .tar).

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

На рисунке 1 сравниваются permissively лицензированные пакеты, которые являются GPL, загрязненные с теми, которые не загрязнены, используя кластер участок всего строк уникального кода по сравнению с линиями кода сторонних. На рисунке показано, что загрязненные проекты имеют более чем 10 000 строк кода сторонних и более 1000 строк уникального кода, несмотря на очевидно, в этом наборе данных, который содержит только четыре случая заражения не прослеживается.

Рисунок 1

Рисунок 1. Кластер печати проектов с permisive линиями уникального кода и вероятно код сторонних пакетов лицензий

Пакет лицензий

Из 255 проектов, для которых была доступна информация о лицензировании 61 (24 процента) были обнаружены либеральными лицензиями (например, MIT, BSD или Apache). BSD-лицензированные проекты являются наиболее распространенными, приходится почти треть permissively лицензированных проектов и подчеркнув гибкость, унаследованных в настоящей лицензии. Лицензии MIT и Apache были также распространены, каждый составляет около 15% из оставшихся permissively лицензированных проектов. Из permissively лицензированных пакетов, загрязненных с кодом GPL лицензии два были лицензированы под BSD, один был под MIT, и одно содержит смесь либеральными лицензиями.

Другие 194 (76%) 255 проектов, для которых была доступна информация о лицензировании включена ограничительно лицензии (например, GPL) проектов. Было установлено, что один пакет иметь EUPL 1.1 лицензию, которая содержит файлы, которые сослались на время под лицензией GPL. Этот пакет был сгруппированы в категории ограничительной лицензией. Также включены, где пакеты были лицензированы под LGPL (v3, v2 или v2.1), который можно считать умеренно ограничительный характер.

На рисунке 2 показано количество языков программирования, используемых в каждом проекте в отношении количества строк кода для permissively и ограничительно лицензированных пакетов. На рисунке 2 показано, что пакеты с более чем 1000 строк кода, скорее всего с помощью одного, двух или более языках, в то время как пакеты с более чем 100 000 строк кода, скорее всего с помощью двух или более языков программирования. GPL загрязнения окна показывают расположение permissively лицензированных пакетов с GPL загрязнения. Из выборки 344 проектов (в том числе проекты, которые имеют лицензии, которые не могут быть подтверждены) три наиболее часто используемых языков программирования были C, Python и PERL. Это распределение четырех случаев код GPL найден в permissively лицензионных пакетах показывает, что загрязнение может происходить независимо от количества используемых языков.

Рисунок 2

Рисунок 2. Языки программирования по сравнению с всего строк кода ограничительно лицензированы и permissively лицензированные пакеты, включая доказательства загрязнения GPL в permissively лицензионных пакетах

Авторские права и лицензии информация в файлах кода

Часто, когда открытый исходный код приведен в проекты, что наследуется не является весь пакет другого проекта, но только фрагмент кода или файла из этого проекта. Если требования интеллектуальной собственности (авторское право) или лицензии не внедряются в файл, существует риск, что файл может быть ошибочно быть использованы в permissively лицензированный проект, и затем эта ошибка может распространяться в другие проекты, ведущие к вирусного заражения. В нашем наборе данных 334 пакетов в которых мы нашли 151,187 файлы (не включая двоичные файлы), 39% файлов не имеют авторских прав информации или не относится к лицензии. Для файлов, которые имеют авторских прав или лицензии информации 2% только сделал ссылку на лицензию, 43% сделал ссылку на лицензии содержит информацию об авторских правах и 16% только информация об авторских правах (таблица 1). Из 45%, что имел в виду лицензии, 63% из файлов ссылки на GPL, и 13% автономные (не смешанные) Apache, BSD или MIT лицензии.

Таблица 1. Авторские права и лицензии информация в 334 кибербезопасности проекты с открытым исходным кодом

Полный набор данных 334 проектов:

151,187 файлов в общей сложности, не включая двоичные файлы

IP или требования лицензии

 

Ссылка на лицензию или авторское право

 

 

91,651 файлы

61%

Нет IP или требования лицензии

 

Ссылки на авторские права или лицензии

 

59,536 файлы

39%

Ссылка на лицензию только

 

3267 файлов

2%

Ссылка на лицензии и авторские права

 

64,361 файлы

43%

Ссылка на авторское право только

 

24,023 файлы

16%

Объем сторонних код

Protecode Enterprise Server 4 используется для определения количества стороннего кода, который скорее всего существует в каждом проекте в нашем подвыборки 243 проектов. Когда программное обеспечение Protecode сканирует файл, он сравнивает его против своей базы данных известных сторонних код. Если программное обеспечение Protecode предлагается лучший матч третьей стороны для файла, ради этой статье мы рассматриваем весь файл как стороннего кода.

На рисунке 3 представлены распределение строк кода между проектами, подчеркнув стороннего кода, а также permissively лицензированные пакеты, которые загрязнены с GPL материалом. На рисунке 4 показано распределение проектов по проценту кода в рамках проекта, скорее всего, от третьей стороны. Около 145 проектов содержат код сторонних 0% до 10%, в то время как около 20 проектов содержат 90% или более сторонних. Во всех проектах средний объем кода сторонних составляет 27%.

Рисунок 3

Рисунок 3. Область памяти стороннего кода в 243 отобранных проектов, приказаны всего строк кода в каждом проекте

Рисунок 4

Рисунок 4. Гистограмма числа проектов по сравнению с часть пакета, вероятно, код сторонних

Будущая работа

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

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

Заключение

Мы обнаружили, что кибербезопасность сообщества open source не является добавление авторских прав информации или лицензии ссылки на файлы, чтобы претендовать на права интеллектуальной собственности: 39% файлов не имеют авторских прав или лицензии attribution. Мы предлагаем, что руководителям следует проводить политику добавления авторских прав и лицензий на их исходный код, чтобы обеспечить, что права интеллектуальной собственности утверждали и также убедиться, что исходный код GPL не может быть случайно потребляется и загрязнить коммерческий продукт. Мы также обнаружили, что нет никакой гарантии, что пакеты с либеральными лицензиями не загрязнены с ограничительным лицензированным материалом: четыре из 61 permissively лицензированные проекты были загрязнены с ограничительной лицензией. Кроме того 76% проектов open source кибербезопасности имеют ограничительный пакет лицензий и 24% имели разрешительного пакет лицензий. Эти результаты показывают, что варианты для повторного использования открытого исходного кода в пространстве кибербезопасности малы по продаже несвободных программ. Однако большинство ограничительных лицензий могут быть монетизированы посредством дополнительных услуг продуктов с открытым исходным кодом. Хотя большая часть существующей литературы обсуждается вопрос лицензирования открытым исходным кодом, лицензирование конфликтов и лицензирование совместимости, эти исследования зачастую свет на данных. В этом исследовании мы изучили набор данных из более 300 проектов open source кибербезопасности и предоставляет ступенькой для дальнейшего расследования в области кибербезопасности открытым исходным кодом. Хотя наши результаты показали лишь четыре случая заражения через 344 open source проектов кибербезопасности, потенциальные последствия такого загрязнения для дальнейшего изучения этих индивидуальных ордера в как компании могут снизить этот риск.

 


 

Ссылки

Бёркс, д к 2015 году. Проект безопасности лук: Инструменты. Лук решения безопасности. Доступны с 1 ноября
2015:https://github.com/Security-Onion-Solutions/security-onion/wiki/Tools

DHS. 2012. Open Source кибербезопасности каталог: Родина открытой безопасности технологии (HOST) проекта. Министерство национальной безопасности (DHS)-Наука и технологии управления. Доступ к 1 ноября,
2015:https://www.dhs.gov/sites/default/files/publications/csd-host-open-soruc...

Багор, б. м. & Ploussios, г. д. 2012. Открытое программное обеспечение. IEEE компьютерное общество, 45(6):
9-11.http://dx.doi.org/10.1109/MC.2012.213

Хаммуда, и., Микконен, т., Оксанена, в. & Jaaksi, а. 2010. Открытым исходным кодом шаблоны законности: Архитектурные решения мотивированных юридических проблем. Материалы XIV международной академической MindTrek конференции: 207-214. Нью-Йорк:
ACM.http://dx.doi.org/10.1145/1930488.1930533

Хасин, K. 2007. С открытым исходным кодом на суде. Open Source бизнес ресурс, Октябрь 2007 года:
15-19.http://timreview.ca/article/66

Klasfelld, а. 2011. "Вестингауз" санкции в случае над открытым исходным кодом. Кортхаус служба новостей: 12 августа 2011. Доступны с 1 февраля,
2016:http://www.courthousenews.com/2011/08/12/38954.php

Khanafer, х. к 2015 году. Q&A. Нужно ли открытым исходным кодом политики фирмы разработки программного обеспечения? Обзор управления инновационной технологии, 5(5):
45 – 46.http://timreview.ca/article/897

Ссылка, C. 2010. Шаблоны для коммерческого использования Open Source: Лицензирование и правовые аспекты. Материалы 15 Европейской конференции по шаблону языки программ (EuroPLoP ' 10): Номер статьи 7. Нью-Йорк:
ACM.http://dx.doi.org/10.1145/2328909.2328918

Лохман, а., Микконен, т., Хаммуда, и, Казман, р. & Hong Мэй, C. 2013. Ядро периферия законность архитектурный стиль для развития системы Open Source. Труды 46-й Международной конференции Гавайи по системе наук (HICSS):
3148-3157.http://dx.doi.org/10.1109/HICSS.2013.34

Наступление безопасности. к 2015 году. Индекс Kali Linux депо исходного кода. Наступление безопасности. Доступ
2015:http://http.kali.org/kali/pool/main
июля

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
1 голосов были поданы, с средняя оценка 5 звезд

Комментарии

Я все еще хотите, чтобы читать остальные бумаги, но я обеспокоен тем, что на раннем этапе вы сделали принципиально неверное утверждение, что рябь через остальную часть бумаги. Вы государство, «вообще говоря, ограничительные лицензии позволяют потребителям открытым исходным кодом проекта для перераспределения скомпилированного двоичного файла при условии, что исходный код двоичного файла должны быть доступны для общественности и что двоичный и исходный код не может быть продан.» GPL требует изменения, внесенные в код GPL для публикации. Он никогда не предотвращает продажу. Утвержденных OSI лицензия не ограничивает продажу.

Я жил в этом пространстве долгое время. Я построил компанию, чей продукт представляет собой комбинацию из 250-300 + открытых лицензированных проектов, охватываемых ~ 25 открытых лицензий, включая GPL (и некоторые из которых до сих пор не утверждены OSI по сей день), наши собственные проприетарное программное обеспечение и программное обеспечение, лицензии от корпорации Майкрософт на высоте их FOSS паранойя почти 20 лет назад. Наш продукт должен быть ядра интегрирован с Windows NT. Я сделал это с полным надзором фонда свободного программного обеспечения (параноидальным о Microsoft) и группой юристов компании Microsoft (параноидальным о FSF). Как команда разработки программного обеспечения мы были осторожны и вдумчивый и перешли без линий. Даже не gcc включают файл проблемы, которая была реальностью в то время.

Другие озабоченности, у меня есть приписывая «зараза» «загрязнитель» «вирусный» проблема быть открытым исходным кодом. Есть так много много источников программного обеспечения поспешил программист, явно не знают основных профессиональных авторского права, можно использовать. Учебники, научные публикации, несвободные библиотеки продуктов, которые содержат исходный код из-за программной среды и разработчиков сетей (например, Oracle, Microsoft, IBM) с бедными или нет условий лицензирования на фрагменты исходного кода или примеры являются бесконечно более опасными источниками зараза чем проект с объявленным открытым исходным кодом утвержденных лицензии. И вы можете поспорить, что IBM или Oracle будет судиться с тобою.

И наконец страх GPL стала мифология. Я недавно начал искать в лицензии на крупнейших проектов самых оживленных в мире ФОСС, основываясь на заявлении, которое сделал технический директор ВПО. GPL, вероятно, лучше лицензию на экосистемы роста чем разрешительного семьи. Написал его вверх здесь: https://opensource.com/business/16/2/bright-lines

Тем не менее мышления. Продолжит рассмотрение.

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

Обычный текст

  • Теги HTML не разрешены.
  • Адреса электронной почты и адреса страниц включите в ссылки автоматически.
  • Строки и параграфы переносятся автоматически.