Проект grsecurity (https://grsecurity.net), в рамках которого развивается серия надстроек для усиления безопасности ядра Linux, объявил (https://grsecurity.net/announce.php) о решении закрыть неограниченный доступ к стабильным версиям патчей, предоставив возможность их загрузки только спонсорам проекта. В качестве причины подобного решения называются массовые нарушения лицензии GPL и торговой марки проекта представителями индустрии встраиваемых устройств, которые используют разработки grsecurity в своих продуктах без какой-либо отдачи основному проекту и без открытия производных работ.
Доступ к экспериментальным веткам grsecurity останется открытым, что позволит избежать негативного влияния на сообщества Gentoo Hardened и Arch Linux, так как они используют выпуски на базе свежих ядер Linux. Стабильные ветки, основанные на ядрах 3.2 и 3.14, в течение двух недель станут доступны только компаниям, участвующим в финансировании grsecurity. Паразитирующие производители встраиваемой техники будут отрезаны от доступа к данным веткам grsecurity.
Поворотным моментом в принятии решения по переходу к платному распространению актуальных стабильных патчей стала попытка (http://lists.coreinfrastructure.org/pipermail/cii-discuss/20...) получить финансирование от фонда Core Infrastructure Initiative (CII), в рамках которого ведущие корпорации объединили (http://www.opennet.me/opennews/art.shtml?num=39635) свои усилия в направлении обеспечения поддержки открытых проектов, задействованных в ключевых областях компьютерной индустрии. Представители CII дали понять, что финансирование можно получить на работу по интеграции компонентов grsecurity в основное ядро Linux (ориентация на основное ядро связало бы руки разработчикам grsecurity и заставило бы отказаться от некоторых идей из-за слишком жестких требований по включению кода в mainline и обеспечению совместимости). Выделение средств на продолжение работы над grsecurity в прежнем виде оценено как нецелесообразное, так как средства выделяются не на поддержание разработки, а на создание новых возможностей или решение проблем в важных для инфраструктуры проектах.
Разработчики grsecurity попытались напомнить, что grsecurity не просто ещё один набор патчей к ядру Linux, а, по сути, является проектом для создания новых технологий (https://grsecurity.net/features.php) и практических средств защиты в области информационной безопасности и предотвращения атак. Наработки grsecurity активно применяются многими производителями дистрибутивов и прошивок, а по степени важности для обеспечения безопасности разработка grsecurity значительно важнее уже профинансированных CII инструментов fuzzing-тестирования и статического анализа.URL: https://grsecurity.net/announce.php
Новость: http://www.opennet.me/opennews/art.shtml?num=42856
> что grsecurity не просто ещё один набор патчей к ядру LinuxТолько это правда просто набор патчей. Но вообще молодцы - коммерсню и юзателей псевдостабильных веток надо гнобить.
Псевдо - то есть они у них не стабильные ни хрена?
> юзателей псевдостабильных веток надо гнобить.В результате они показали, что целью является вендорлок на себя всех кто вляпался. А не улучшение линуха. Логично что денег им в результате не дали. Сами пусть зарабатывают при таком подходе, вполне честно.
То есть им, по идее, не денежное спонсорство нужно, а приличная юридическая поддрежка чтобы вытрясти деньги из нарушивших лицению.Ну и байки насчёт "слишком жестких требований по включению кода в mainline и обеспечению совместимости" умиляют. Это ж надо - всё разрушить до основанья не дают. Но да, они ж лучше всех знают, что "по степени важности для обеспечения безопасности разработка grsecurity значительно важнее уже профинансированных CII инструментов fuzzing-тестирования и статического анализа". А вот то, что деньги даются на конкретные результаты, а не на вечную разработку - это плюс CII, конечно.
А по факту - плевать. Кому надо быстро - заплатят, кто не боится быть полигоном - есть экспериментальная ветка, для остальных желающих исходники так или иначе будут, хоть и попозже - на то и GPL, а в общем - не похоже, чтобы от этой штуки была великая польза.
> а в общем - не похоже, чтобы от этой штуки была великая польза.Ну, есть по крайней мере один дистрибутив, в котором grsecurity является важной базовой составляющей.
Болдженос?
> Болдженос?
Нет его. В том смысле, что это что-то редкое/экзотическое и его судьба вообще ни на что не влияет. Описание, впрочем, тоже не впечатлило. Огрызок вместо libc, свои пакеты...
> В том смысле, что это что-то редкое/экзотическое и его судьба вообще ни на что не влияет. Описание, впрочем, тоже не впечатлило. Огрызок вместо libc, свои пакеты...для вас есть убунта: популярное, glibc, дебиановский формат пакетов.
> для вас есть убунта: популярное, glibc, дебиановский формат пакетов.... и впечатляющее описание на сайте. вас же описание не впечатлило?
Ага, не впечатлило. Если люди не способны внятно сказать, что и дачем они делают - скорее всего они занимаются ерундой. Исключения бывают, но искать их - слишком много мороки, которая себя не оправдывает.
Для меня есть debian для работы и gentoo дома. Я не против разных дистрибутивов - но всерьёз считать проблемой то, что влияет на какую-то экзотику - это смешно. Ну уползут на экспериментальную ветку - один хрен не продакшн же делать на этом.
У вас что есть продакшн? Аптайм 5-10 лет?
Шикарная штука, для меня открытие года на роль десктопа и даже сервера. Нет богомерзкого systemD и grsecurity в штатном ядре.
> Шикарная штука, для меня открытие года на роль десктопа и даже сервераТоже так думал, пока не обнаружил, что Xorg -configure не работает из-за использования не glibc :(
Но консольные впечатления очень положительные.
>> Шикарная штука, для меня открытие года на роль десктопа и даже сервера
> Тоже так думал, пока не обнаружил, что Xorg -configure не работает из-за
> использования не glibc :(Я понимаю, что это может быть лишь один из примеров, но:
а) у меня и в Debian "X -configure" при определённых условиях заканчивалось ошибкой сегментирования;
б) Xorg уже несколько лет как конфигурируется сам при помощи udev, который в Alpine есть и даже не слишком древний (они там вроде на eudev собираются переходить).
> б) Xorg уже несколько лет как конфигурируется сам при помощи udevЭто как? Или имеется ввиду, что Xorg может сам подгружать необходимые драйвера/модули без специальной настройки?
>> б) Xorg уже несколько лет как конфигурируется сам при помощи udev
> Это как? Или имеется ввиду, что Xorg может сам подгружать необходимые драйвера/модули
> без специальной настройки?Да, имеется в виду именно это.
В Gentoo Hardened оно является не важной, не базовой или не составляющей?
> В Gentoo Hardened оно является не важной, не базовой или не составляющей?Gentoo просто далеко за пределами моих интересов.
>> Болдженос?
> http://alpinelinux.org/Их хороший десяток наберётся.
Первый - Adamantics сегодня Hardened Debian.
Основной - Hardened Gentoo, от него много производных, в том числе и Альпина.
>>> Болдженос?
>> http://alpinelinux.org/
> Первый - Adamantics сегодня Hardened Debian.Ни то, ни другое не гуглится. Вернее, второе гуглится, но какое-то давно умершее.
> Основной - Hardened Gentoo, от него много производных, в том числе и
> Альпина.А, и правда.
> previous versions of Alpine were based on Gentoo
важной базовой составляющей в не имеющем никакого значения дистрибутиве
Им нужны не деньги, а открытый код продуктов использующих их код. Что есть и основа GPL.
А деньги уже второе. GPL продукты получают деньги за поддержку, а не сам код.
Сами нарушают жипиэль под предлогом того, что другие нарушают. А на самом деле просто _хотят_больше_денег_. Все прочие аргументы надуманные.
Болше денег не выйдет, т к если дадут патчи хоть одной компании - они будут у всех.
В основную ветку не возьмут, т к нарушают совместимость? А если это так, то кому оно надо?
Сами не нарушают - GPL не обяывает давать софт всем подряд. Но они бы определились - либо у них готовый продукт, подходящий для мейнстрима - тогда могли бы и в ядро. Либо у них исследования - тогда какие, на фиг, клиенты, использующие стабильные ветки?
GPL какой-то резиновый стал. Мы публикуем... публикуем... точно опубликуем через 2 года, но опубликуем же! Также могут и компании говорить, которые взяли сорцы поюзать. Опубликуем через 10 лет. Какие претензии?
> GPL какой-то резиновый стал. Мы публикуем... публикуем... точно опубликуем через 2 года,
> но опубликуем же! Также могут и компании говорить, которые взяли сорцы
> поюзать. Опубликуем через 10 лет. Какие претензии?ровно до тех пор, пока они держат свои продукты у себя. как только кому‐то продали — обязаны по первому требованию предоставить исходники.
> поюзать. Опубликуем через 10 лет. Какие претензии?Публикуйте. А если у меня есть ваш продукт - сорец вы должны предоставить или сразу, или по моему требованию. Иначе возникает нарушение лицензии. И тогда права на использование кода отваливаются уже у такой компании. И компании выпадает шанс отдуться по всей строгости законов об авторском праве. А кто сказал что копираса-зажимаса нельзя откопирасить теми же законами? ;).
> Сами нарушают жипиэль под предлогом того, что другие нарушают. А на самом
> деле просто _хотят_больше_денег_. Все прочие аргументы надуманные.
> Болше денег не выйдет, т к если дадут патчи хоть одной компании
> - они будут у всех.
> В основную ветку не возьмут, т к нарушают совместимость? А если это
> так, то кому оно надо?Как автор может нарушить лицензию которую он сам установил для продукта?
Постойте! Он же памятник^W Автор (того памятника)!!!
Сменить лицензию, для новых версий, и действовать в соответствии с новой лицензией.
Ну или вообще забросить все к такой то матери.
Так что, если это кому то нужно, может стоит оплатить работу (или форкай и пили сам, если лицензия позволяет ;)
> Как автор может нарушить лицензию которую он сам установил для продукта?Проект grsecurity не является автором ядра, соответственно должен соблюдать все требования налагаемые лицензией (GPLv2) исходного проекта (ядра).
>> Как автор может нарушить лицензию которую он сам установил для продукта?
> Проект grsecurity не является автором ядра, соответственно должен соблюдать все требования
> налагаемые лицензией (GPLv2) исходного проекта (ядра).
>> Как автор может нарушить лицензию которую он сам установил для продукта?Я в общем смысле.
Думаю людям которые употребляют слово "паразиты" по отношению к тем кто использует открытый код, следует не морочить себе и людям голову и использовать проприетарную лицензию.
> "паразиты" по отношению к тем кто использует открытый код,Паразитами называют тех, кто не выполняет требование лицензии на этот код.
Хочешь создавать свой проприетарный продукт - используй код с соответствующей лицензией (MIT, Apache, BSD...), иначе, если используешь код под GPL, будь добр открыть код своих изменений.
А людей которые употребляют бранное слово "паразит" по отношению к людям не наносящим абсолютно никакого ущерба, в приличном обществе называют исключительно "вонючими свиньями".
> А людей которые употребляют бранное слово "паразит" по отношению к людям не
> наносящим абсолютно никакого ущербаОзнакомьтесь с понятием brand dilution как самым малым судебно наказуемым, что в данном случае, если верить написанному, уже применимо.
>А людей которые употребляют бранное слово "паразит" по отношению к людям не наносящим
>никакого ущерба, в приличном обществе называют исключительно "вонючими свиньями".Вы себя только что вонючей свиньёй назвали. Что тут сказать? Вам виднее.
В отношении тех, кто нарушает GPL и прикрывается чужой торговой маркой.
Ядрышок под GPL. Никак нельзя.
wget -O - https://grsecurity.net/announce.php | grep parasite
нет результатов.Вспомнился анекдот на тему оригиналов и трансляций.
- Говно этот ваш Шопен.
- Тебе не понравилось? Где ты слушал?
- Да сосед Петрович напевал вчера.
Вы не находите, что слова "паразитируют" и "паразит" несут совсем разный оттенок?
Чем вам использование слова "паразитируют" в контексте "пользуются чужим трудом, ничего не давая взамен" не понравилось?
Потому что нет ничего плохого в том чтобы пользоваться "чужим трудом" не давая ничего взамен. Это не наносит абсолютно никакого ущерба.
> Потому что нет ничего плохого в том чтобы пользоваться "чужим трудом" не
> давая ничего взамен. Это не наносит абсолютно никакого ущерба.До тех пор, пока соблюдаются условия распространения этого труда. Нарушил условия, не соблюдаешь GPL и держись закрытыми свои изменения - паразит в чистом виде.
держишь закрытыми изменения или не присылаешь их назад в проект?Это очень 2 разные вещи. Второе никто не обязан под GPL делать.
> не присылаешь их назад в проект?А это как в данном случае? В чем отличие от открытия изменений? В чем должно заключаться "присылание назад"? Запечатываешь в конверт и заказным письмом, голубиной почтой, с уведомлением и праздничной ленточкой отправляешь адресату? По получении мчишься к ним и умоляешь принять и включить в исходный проект, всячески лебезя и извиняясь адаптируешь патчи и моешь полы пока разработчики исходного проекта пьют пиво? Такого только EULA может требовать, только не предоставляя и не разрешая взамен вообще ничего (еще и стуча по башке за то что посмел вообще что-то изменить).
смотри за ручками.
Есть проект - ты взял его код под GPL, модифицировал и используешь.
Продаешь клиентам. Клиентам которые запросят - даешь код.Где тут нарушение GPL и паразитирование? Все сделано прямо по лицензии - буковка в буковку.
Можешь даже у себя выложить патчи - но не заморачиваться засылать их в upstream.
где тут нарушение? все строго в буковку написанному в GPL.
или кто-то скрывает изменения? (кстати надо еще доказать что они есть, так как если их нет - достаточно ссылки на страницу проекта).
так что у нас с ручками?
Барыгой пахнут ваши ручки ))) А им респекта не видать.
> Это очень 2 разные вещи. Второе никто не обязан под GPL делать.Ну да, только если твой код не совместим с GPL по лицензии - ты и линковаться с GPLным ядром не сможешь. Пиши свое ядро - будешь иметь полные права на его код. Правда, удачи с этого факта что-то поиметь...
> Потому что нет ничего плохого в том чтобы пользоваться "чужим трудом" не
> давая ничего взамен. Это не наносит абсолютно никакого ущерба.равно как и называние паразитов паразитами. представляешь — это тоже не наносит никакого ущерба.
Извините, но вы увлекаетесь каким-то флудом который я переварить не в состоянии.Аноним выше сказал: "люди которые употребляют слово \"паразиты\"" Потом ему ответили и Аноним ещё раз настоял именно на этом слове -- "паразиты".
Я отвечаю: командой grsecurity НЕ было употреблено это слово. И никакие другие переводы этого слова тоже.
Значит, компании тырят код и используют его в своих продуктах - это не по гпл.
GRSEC модифицирует код ядра и закрывает свои наработки - это не нарушает GPL, так чтоли?
А пиарщики из grsec хотябы читали GPLv2, под которой лицензируется ядро? Хотя бы пробовали читать, я уж не говорю о том, чтобы привлечь юристов, для растолковывания смысла gpl, раз уж господа из grsec такие тугодумы...
гпл это не нарушает. от слова совсем. Другой вопрос, что любой спонсор имеет право выложить исходники в открытый доступ ничего при этом не нарушив.
Согласен, пока вы не получили продукт нечего и выступать. Они вам ничего не должны. Главная идея лицензии в защите потребителя.
> А пиарщики из grsec хотябы читали GPLv2, под которой лицензируется ядро?Сами-то прочтите, там не так много. Хотя бы пункты 2 и 3.
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."Под "all third parties" подразумевается вообще все люди и фирмы, или только те на кого пальцем показали?
фу блин. С такой же аргументацией можно закрыть любой проект или драйвер. Потому как да, платят одни, а пользуются и другие тоже.
Точно - давайте стабильные ядра только спонсорам раздавать, обычным пользователям и нестабильных версий хватит - пусть тестингом занимаются, а то паразитируют на стабильных ядрах ;)Почему они не обратятся за помощью к SFC?
"Busybox, поставляемый под лицензией GPLv2, является флагманским продуктом в деле борьбы с нарушением GPL в прошивках и неоднократно с успехом использовался проектом Software Freedom Conservancy (SFC) в судебных процессах против компаний, не предоставивших доступа к исходному коду GPL-программ."
> Точно - давайте стабильные ядра только спонсорам раздавать, обычным пользователям и нестабильных
> версий хватит - пусть тестингом занимаются, а то паразитируют на стабильных
> ядрах ;)А сейчас разве не так? Хотите стабильное идите в RedHat. не нравится? пользуйтесь чем есть.
> А сейчас разве не так?На kernel.org доступны stable и longterm версии для всех желающих.
>> А сейчас разве не так?
> На kernel.org доступны stable и longterm версии для всех желающих.серьезно? и вы верите что там стабильные версии? Какой наивный вюнош..
А слова Линукса прям были фигней ?
> серьезно?Вполне.
> и вы верите что там стабильные версии? Какой наивный вюнош..
У вас есть альтернативное трактование терминов stable и longterm? Или вы сомневаетесь в компетентности разработчиков, давшим ядрам такой статус?
Из моей личной практики (16 лет на десктопе) - вероятность нарваться на баг в ядре на порядок меньше, чем в остальном user space. ИМХО это вообще самый стабильный открытый проект из крупных.
> А слова Линукса прям были фигней ?
Какие?
>> серьезно?
> Вполне.
>> и вы верите что там стабильные версии? Какой наивный вюнош..
> У вас есть альтернативное трактование терминов stable и longterm?Это лишь термины описывающие тип процесса и длительность процесса поддержки. К самому качеству кода отношения не имеют. В stable не допускаются улучшения функциональности, только багфиксы. Все или не все история умалчивает. Иначе бы не было ситуаций когда сразу после выпуска релиза в stable ветке приходилось выпускать следующий stable с фиксом предыдущего.
> Или вы сомневаетесь
> в компетентности разработчиков, давшим ядрам такой статус?сомневаюсь в компетентности. Вряди они проводили тестирование и сертификацию на оборудовании.
Скорее всего означает что когда им захочется они возможно исправят ошибки. Если время будет
При этом не за что не отвечая.> Из моей личной практики (16 лет на десктопе) - вероятность нарваться на
> баг в ядре на порядок меньше, чем в остальном user space.
> ИМХО это вообще самый стабильный открытый проект из крупных.
>> А слова Линукса прям были фигней ?
> Какие?О том что если кому-то нужны стабильные ядра - это к дистрибутописателям, а он в 2.6 сосредоточится на чистом искусстве.
> Это лишь термины описывающие тип процесса и длительность процесса поддержки. К самому
> качеству кода отношения не имеют. В stable не допускаются улучшения функциональности,
> только багфиксы.Имеет - так как единственный реальный способ получить стабильность - более длительное тестирование и исправление ошибок. Нужна большая стабильность - бери ядра проверенные временем и миллионами пользователей.
> Все или не все история умалчивает.Пруфы или это очередная теория заговора?
> Иначе бы не
> было ситуаций когда сразу после выпуска релиза в stable ветке приходилось
> выпускать следующий stable с фиксом предыдущего.Эта проблема уже многократно обсуждалась разработчиками ядра. Суть проблемы - недостаточное тестирование. Разработчики проверяют новый функционал на доступном им оборудовании и в доступным им ситуациям. Пользователи не хотят участвовать в тестировании и ждут стабильных версий. Естественно первые версии стабильных веток могут вызывать существенные регрессии.
Дабы улучшить ситуацию, разработчики отказались от деления на стабильные (2.0/2.2/2.4/etc) и экспериментальные (2.1/2.3/2.5) версии. Теперь добавляют функционал небольшими порциями обкатывают у себя, затем у пользователей. LO тоже использует подобную практику и не рекомендует первые версии в новой ветке для промышленного использования.
> сомневаюсь в компетентности.
А в redhat кто работает? А да там же Поттеринг :)
> Вряди они проводили тестирование и сертификацию на оборудовании.
А у redhat есть все оборудование в мире и миллион бета тестеров? Их бета тест - fedora (дивиз - проверено на людях :)
Если redhat и проводит внутреннее тестирование десятка серверов и дает на них сертификаты, мне как, пользователю десктопа, это безразлично.
> Скорее всего означает что когда им захочется они возможно исправят ошибки. Если
> время будет
> При этом не за что не отвечая.RHEL не было критических багов? Как redhat за них отвечала?
> О том что если кому-то нужны стабильные ядра - это к дистрибутописателям,
> а он в 2.6 сосредоточится на чистом искусстве.Цитата есть? Насколько я помню - это было об постоянно меняющемся API и косяках с закрытыми драйверами.
>>> А сейчас разве не так?
>> На kernel.org доступны stable и longterm версии для всех желающих.
> серьезно? и вы верите что там стабильные версии? Какой наивный вюнош..но ведь ты же веришь красношапке. и при этом считаешь, что другим верить кому‐либо иному нельзя. ну и бардак у тебя в черепе…
>>>> А сейчас разве не так?
>>> На kernel.org доступны stable и longterm версии для всех желающих.
>> серьезно? и вы верите что там стабильные версии? Какой наивный вюнош..
> но ведь ты же веришь красношапке. и при этом считаешь, что другим
> верить кому‐либо иному нельзя. ну и бардак у тебя в черепе…Краношляпка делает сертификации на оборудовании, вот FIPS было.. а где у longterm, и так называемого stable - такое? что-то там комитят.. не за что не отвечают.. сертификатов нету..
слишком толсто.
Мне это напомнило про драйвер для модемов коннексант лет 12 назад...
Странное решение, лучшеб попросили спонсоров или FSF судиться с нарушителями.
Хотя я это и не одобряю, но могу понять их решение. Это несколько нечестно, когда корпорации делают миллионные прибыли, не платят ни копейки разработчикам, и не выкладывают свои изменения.Им бы стоило, если возможно, перелицензировать часть кода под бесплатной только для некоммерческого использования лицензией, и тогда всё бало бы хорошо.
Несомненно, мы все за всё бесплатное и открытое, но разработчикам иногда хочется есть и иногда нужно платить за квартиру. И вот тут и возникает некоторая несостыковка: с одной стороны разработчики хотят работать на полную ставку (это эффективнее, чем "пилить" проект в свободное время), а с другой никто платить за это не хочет -- мы фанаты GPL, FSF и т.п.
Было бы вполне разумно взымать плату с тех корпораций, для которых данная технология является ключевой, и чьи многомиллионные прибыли были бы без неё невозможны.
> Несомненно, мы все за всё бесплатное и открытое, но разработчикам иногда хочется есть и иногда нужно платить за квартиру.И снова уже заезженное равенство: открытое != свободное != бесплатное
В данном случае речь идет о свободном.
Ага, тоже резануло.
Им бы стоило найти юристов - хоть с той же SFC договориться - и выжать из сильно хитрых товарищей деньги. И хтрецов бы поубавилось, и на развитие что-то получили бы.
Проект GPL становиться доступным только тем кто платит, потому что те кто не платит и не делится своим кодом нарушают GPL. Бред конечно, просто очевидно им хочется чтобы им платили и ничего плохого в этом нет. Разве что чтобы заработать на GPL нужна какая то бизнес модель, чтобы и деньги были и не оказаться сволочью в глазах сообщества
GPL не обязывает делиться кодом с автором кода. Контора А скачала исходники и продала их конторе Б. Исходники заказчиком получены, GPL соблюдена. Если контора Б использует их исключительно внутри себя, то и выкладывать на шару она никому не обязана.
> Представители CII дали понять, что финансирование можно получить на работу
> по интеграции компонентов grsecurity в основное ядро LinuxЧто, вообще говоря, резонно. Да, трудно, да, полностью может не получиться никогда даже для какого-либо текущего объёма изменений -- ну так дорогу осилит идущий, кусочки ow/grsec уже так или иначе вошли (те же restricted symlinks), а в остальном брали бы пример с тех же OpenVZ-шников, у которых задача включения в майнлайн никак не менее сложная.
Сложная дорога. Как я понимаю, им совершенно не хватает имеющихся security-хуков. Они понадобавляли проверки в кучу мест, не охватываемых ими. И для того, чтобы это всё включить в ядро, придётся, как минимум, увеличить таблицу хуков в несколько раз. А также, возможно, добавить отсутствующие механизмы.Проблема со включением может быть весьма простая: зачем включать в основное ядро то, что никому, кроме GRSEC, не нужно?
> Проблема со включением может быть весьма простая: зачем включать в основное ядро то, что никому, кроме GRSEC, не нужно?Если кроме grsecurity это никому не нужно, может быть тогда пусть на свой личный проект деньги сами тогда и находят? А то получается, что их прокатили с финансированием за сомнительную ценность их целей, а они обиделись и решили никому свои формочки и грабельки не давать? Ну ок. На них свет клином не сошёлся. Есть другие проекты.
Какую сомнитиельную ценность? Сказано же, что используют компании, у которые огромный оборот бабла. Где они тут http://grsecurity.net/contribute.php? И нахрена использовать, если нет ценности?
Сказано же, что нарушают торговую марку. ЕМНИП далеко не первый случай.
в чем нарушают? называют свой продукт grsecurity ? или просто упоминанием что проект растет оттуда?
Так за второе в ноги должны кланяться - ибо реклама их поделкам.
>Так за второе в ноги должны кланяться - ибо реклама их поделкам.Написано же, что эта "реклама" равносильна тому-же, что и нагадить кучу и воткнуть туда флажок "grsecurity".
>> Представители CII дали понять, что финансирование можно получить на работу
>> по интеграции компонентов grsecurity в основное ядро Linux
> Что, вообще говоря, резонно. Да, трудно, да, полностью может не получиться
> никогда даже для какого-либо текущего объёма изменений -- ну так дорогу
> осилит идущий, кусочки ow/grsec уже так или иначе вошли (те же
> restricted symlinks), а в остальном брали бы пример с тех же
> OpenVZ-шников, у которых задача включения в майнлайн никак не менее сложная.Нет. openvz и grsec - у них разные модели разработки. В openvz вложили (вкладывают) инвестиции. а grsec - это в первую очередь энтузиасты а-ля Тео, только в linux. А тащить на себе целое ядро с патчами дело не слабое.
У GPL есть недостаток, что исходники модификаций нужно открывать по желанию. Типа, мы сделаем свой супер-защищённый дистрибутив. Для того, чтобы иметь право требовать исходники, нужно заплатить много бабок, чтобы его купить. А с теми, кто купил, мы как-нибудь договоримся, чтобы в сеть не выкладывали. Да, и если клиентами являются крупные корпорации, то им эти исходники может и не сдались, до тех пор, пока есть платная техподдержка, и всё работает. И, уж, тем более, им нет никакого резона выкладывать их в сеть.В результате есть возможность паразитировать на софте под GPL, чем и недовольны авторы.
И поэтому надо паразитировать по этой схеме самим?>[оверквотинг удален]
> У GPL есть недостаток, что исходники модификаций нужно открывать по желанию. Типа,
> мы сделаем свой супер-защищённый дистрибутив. Для того, чтобы иметь право требовать
> исходники, нужно заплатить много бабок, чтобы его купить. А с теми,
> кто купил, мы как-нибудь договоримся, чтобы в сеть не выкладывали. Да,
> и если клиентами являются крупные корпорации, то им эти исходники может
> и не сдались, до тех пор, пока есть платная техподдержка, и
> всё работает. И, уж, тем более, им нет никакого резона выкладывать
> их в сеть.
> В результате есть возможность паразитировать на софте под GPL, чем и недовольны
> авторы.
люди взяли код соглано лицензии - что не нравится то ?
плохо что название крупных компаний нет в статье
Предприниматели суть и есть паразиты но попробуй им это сказать в лицо, вони будет столько сколько бывает от участкового которому обьяснили как переводится слово A.С.A.B. ))..
Ребята сами себя загнали выбрав лицензию GPL
Из wiki и тамGPL предоставляет получателям компьютерных программ следующие права, или «свободы»:
свободу запуска программы с любой целью;
свободу изучения того, как программа работает, и её модификации (предварительным условием для этого является доступ к исходному коду);
свободу распространения копий как исходного, так и исполняемого кода;
свободу улучшения программы, и выпуска улучшений в публичный доступ (предварительным условием для этого является доступ к исходному коду).
....
GNU GPL требует распространения с бинарными файлами (в том числе неизменными) исходного кода или письменного обязательства его предоставить (своего или чужого; способы зависят от версии лицензии).Обращаем внимание на то что, если покупатель купил у меня продукт под лицензией GPL, то он может потребовать его исходники и имеет право их распространять...
{{Проверить нейтральность}}