LINUX.ORG.RU
ФорумTalks

Разработчики Grsecurity упоролись окончательно

 , ,


2

4

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

Разработчики Grsecurity подали судебный иск против Брюса Перенса

Компания Open Source Security (развивает Grsecurity) при юридической поддержке Chhabra Law Firm подала судебный иск против Брюса Перенса (Bruce Perens), одного из авторов определения Open Source, соучредителя организации OSI (Open Source Initiative), создателя пакета BusyBox и одного из первых лидеров проекта Debian. Иск о защите репутации компании подан в связи с размещением в блоге Перенса публикации с оценкой возможного нарушения лицензии GPLv2 при распространении патчей Grsecurity.

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

Один из управляющих партнёров юридической компании O'Melveny & Myers LLP прокомментировал изданию The Register своё мнение об инициированном иске: «Брюс Перенс является всемирно известным экспертом, публикующим свою оценку соблюдения открытых лицензий в интересах общественности. Иск является замаскированной попыткой заставить Перенса замолчать и не выражать своё мнение, лишь на основании несогласия с этим мнением. Печально, что кто-то в сообществе открытого ПО склоняется к подобной тактике».

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

После получения иска Брюс Перенс по-прежнему настаивает на своей правоте, считая, что нарушением GPL является сам факт создания дополнительных условий в договоре. В случае патчей Grsecurity, рассматривается не самодостаточный GPL-продукт, имущественные права на который находятся в одних руках, а производная от ядра Linux работа, которая также затрагивает и права разработчиков ядра. Патчи Grsecurity не могут существовать по отдельности без ядра и неразрывно с ним связаны, что соответствует критериям производного продукта. Подписание договора на предоставление доступа к патчам Grsecurity приводит к нарушению GPLv2, так как компания Open Source Security не имеет права распространять производный продукт от ядра Linux с дополнительными условиями, без получения согласия от разработчиков ядра.

>>> Подробности

Да с ними все давно было понятно.

StReLoK ☆☆ ()

Вот что свежий эффективный юрист может сделать — даже я, срать желающий на всякое security mumbo jumbo, теперь знаю о конторе Open Source Security. И вся это реклама абсолютно бесплатна. Просто через неделю они с помпой уволят юриста, извинятся перед Перенсом, но останутся знаменитыми.

MimisGotAPlan ()

Видно, совсем плохо у них идут дела.

viewizard ★★ ()

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

imul ★★★★★ ()
Ответ на: комментарий от imul

Там нереально вынести код, масса модификаций кода самого ядра — это почти вся суть патча.

viewizard ★★ ()
Ответ на: комментарий от imul

Потому что там нет (или почти нет) нового кода как такового. Что, кстати, ещё один аргумент в пользу того, что патч — это производная работа (вот этот вот товарищ, no-such-file, вот здесь внезапно считает иначе).

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от imul

Что им мешает написать gpl-прослойку, а весь свой код вынести в отдельный «проект»

Так ведь их код и есть отдельный проект, и он уже вынесен в виде патчей.

no-such-file ★★★★★ ()
Ответ на: комментарий от viewizard

Там нереально вынести код, масса модификаций кода самого ядра — это почти вся суть патча.

Ты посмотри сначала содержимое патча, а потом бросайся мне объяснять его суть.

imul ★★★★★ ()
Ответ на: комментарий от no-such-file

Так ведь их код и есть отдельный проект, и он уже вынесен в виде патчей.

В патче их код не только в виде отдельного проекта, но и в виде модификаций проекта стороннего — ядра.

imul ★★★★★ ()
Ответ на: комментарий от intelfx

Потому что там нет (или почти нет) нового кода как такового.

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

imul ★★★★★ ()
Ответ на: комментарий от imul

но и в виде модификаций проекта стороннего — ядра

Тем не менее это их авторские модификации.

no-such-file ★★★★★ ()
Ответ на: комментарий от imul

Ты посмотри сначала содержимое патча,

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

а потом бросайся мне объяснять его суть.

Да без проблем, помолчу.

viewizard ★★ ()
Ответ на: комментарий от no-such-file

Тем не менее это их авторские модификации.

Тем не менее, эти их авторские модификации — производная работа. И право на создание такой работы им даёт только договор (лицензия) на ядро, условия которого они обязаны соблюдать.

baka-kun ★★★★★ ()
Ответ на: комментарий от no-such-file

Тем не менее это их авторские модификации.

То есть часть их кода относится к категории «производная работа».

imul ★★★★★ ()
Ответ на: комментарий от viewizard

Я в курсе содержимого патча, использую его...

Молодец, а я его уже лет 8 как перестал использовать. Только вот последнюю общественно доступную версию в заначку сохранил.

В патче хорошо видно где добавляется функционал, а где добавляется/модифицируется код ядра, чтобы этот новый функционал работал.

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

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

Я где-то предложил обойтись без модификаций?

imul ★★★★★ ()
Ответ на: комментарий от imul

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

А это не взаимоисключающие параграфы?

MrClon ★★★★★ ()
Ответ на: комментарий от imul

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

собственно GPL и мешает, это ее основное предназначение как бы
GPL разрешает проприетарщине обращаться к GPL софту по сетевым протоколам, весело если патчи ядра будут общаться с ядром по RPC

sanyock ★★ ()
Последнее исправление: sanyock (всего исправлений: 1)
Ответ на: комментарий от sanyock

Мне кажется, это ядро grsecurity, которое последнее бесплатное из заначки, хорошо только для каких-нить выделенных серверов (можно виртуальных) под сетевые штуковины типа firewall, webserver, почта и т.п.

потому как часть софта вообще не компилится с grsecurity, например ZFS

sanyock ★★ ()
Последнее исправление: sanyock (всего исправлений: 1)
Ответ на: комментарий от MrClon

А это не взаимоисключающие параграфы?

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

baka-kun ★★★★★ ()
Ответ на: комментарий от sanyock

GPL разрешает проприетарщине обращаться к GPL софту по сетевым протоколам

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

То есть единственный выход — а) независимый от ядра код, б) интерфейс между ним и ядром под GPLv2, в) сборка непосредственно у пользователя и г) нераспространение в исполняемом виде.

baka-kun ★★★★★ ()
Ответ на: комментарий от imul

с любой совместимой с [GNU GPL] лицензией, позволяющей накладывать дополнительные ограничения? Или таких лицензий нет?

Таких лицензий вагон и маленькая тележка (собственно это все неявно совместимые с GNU GPL лицензии), только какой от этого толк-то? Они же с точностью наоборот — хотят навязать условия несовместимые с GNU GPLv2, а не ослабить ее авторское лево.

Zmicier ★★★★★ ()
Ответ на: комментарий от Zmicier

накладывать дополнительные ограничения

Таких лицензий вагон и маленькая тележка

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

baka-kun ★★★★★ ()
Ответ на: комментарий от baka-kun

с любой совместимой [с GNU GPL] лицензией, позволяющей накладывать дополнительные ограничения? Или таких лицензий нет?

Таких лицензий вагон и маленькая тележка (собственно это все неявно совместимые с GNU GPL лицензии), только какой от этого толк-то?

Совместимых с GPL таких не бывает. GPL явно запрещает накладывать дополнительные ограничения...

Кто-то из нас, кажется, пишет быстрее, чем читает. :-)

Совместимых с GNU GPL лицензий, позволяющих накручивать ограничения (то есть не являющихся лицензиями авторского лева), десятки на практике, и бессчетное множество в теории. Известнейшие примеры: лицензия Expat’а, 2-BSDL, 3-BSDL, вторая лицензия Апача (только с третьей).

только давать дополнительные права.

*Никакая* лицензия не дозволяет давать сублизензиарам права сверх вами полученных. Подумайте сами — это же абсолютно бессмысленно, почему было просто не дать их сразу?

Zmicier ★★★★★ ()
Ответ на: комментарий от no-such-file

Тем не менее это их авторские модификации.

Сама по себе модификация ради сферической модификации в вакууме вообще мало кому интересна.

«Это их авторские модификации» главный вопрос модификации чего? И да они сами позиционируют себя как некий продукт повышающий безопасность ядра Linux. Их работа неприменима к: XNU, GNU Hurd... ядру NT в конце концов.

Следующий вопрос кто у кого заимствует и кто и кого использует. Ядро linux может существовать без их заплаток? Да и вполне успешно. И их заплатки без ядра linux ничто. Кучка diff кода реализующего некие их алгоритмы и не более.

init_6 ★★★★★ ()
Ответ на: комментарий от init_6

Сама по себе модификация ради сферической модификации в вакууме вообще мало кому интересна.

Тут бы сейчас набежал post-factum со своим zvercd..

xtraeft ★★☆☆ ()
Ответ на: комментарий от no-such-file

«авторские модификации» - imho ты вводишь какие-то новые левые термины, не справившись с общепринятыми.

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

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

Vit ★★★★★ ()
Ответ на: комментарий от baka-kun

Модификации не являются производной работой. Производная работа - это код с применёнными модификациями. Модификации они могут поставлять по каким угодно лицензиям, хоть по кровавой EULA.

Quasar ★★★★★ ()
Ответ на: комментарий от init_6

Следующий вопрос кто у кого заимствует и кто и кого использует. Ядро linux может существовать без их заплаток? Да и вполне успешно. И их заплатки без ядра linux ничто. Кучка diff кода реализующего некие их алгоритмы и не более.

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

Quasar ★★★★★ ()
Ответ на: комментарий от Vit

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

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

Quasar ★★★★★ ()
Ответ на: комментарий от imul

в отдельный «проект» с любой совместимой лицензией, позволяющей накладывать дополнительные ограничения?

Насчет лицензии перестарался. Теоретически, разбить на 2 патча можно. А практически - в данном конкретном случае видимо не получится закрыть так много как хотелось бы жадным детям.

Vit ★★★★★ ()
Ответ на: комментарий от Zmicier

Кто-то из нас, кажется, пишет быстрее, чем читает. :-)

Я вижу, что один и тот же текст мы читаем по-разному. :)

1) Совместимых с GPL лицензий c наложенными дополнительно условиями (относительно GPL) не существует, поскольку после добавления таких условий они перестают быть совместимыми с GPL.

vs.

2) Есть совместимые с GPL лицензии, которые позволяют на производную работу установить любые дополнительные условия. Точка. (Собственно, поэтому они и являются совместимыми с GPL, что позволяют ей накрутить свои ограничения.)

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

*Никакая* лицензия не дозволяет давать сублизензиарам права сверх вами полученных.

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

baka-kun ★★★★★ ()
Ответ на: комментарий от Quasar

Если ты про скрипт, который накладывает патч, то да, он не является производной работой (подпадающей под gpl при растространении). А сам код - вполне. Т.к. он фактически содержит куски исходника в неявном виде. Но на практике патч реально содержит куски исходника - удаляемые строки и границы.

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

Vit ★★★★★ ()
Ответ на: комментарий от Quasar
1,3c1,3
< Модификации не являются производной работой.
< Производная работа - это код с применёнными модификациями.
< Они не несут в себе куски кода Linux.
---
> Модификации могут являються производной работой. И очень часто являются.
> Производная работа, код с модификациями, обязан быть под GPLv2.
> Эта модификация не несет в себе куски твоего сообщения. Not.
baka-kun ★★★★★ ()

о защите репутации

По-моему они так делают только хуже.

a1batross ★★★★★ ()
Ответ на: комментарий от Quasar

Модификации они могут поставлять по каким угодно лицензиям, хоть по кровавой EULA

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

bormant ★★★★★ ()
Ответ на: комментарий от MrClon

А это не взаимоисключающие параграфы?

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

imul ★★★★★ ()
Ответ на: комментарий от sanyock

собственно GPL и мешает, это ее основное предназначение как бы

gpl gpl-ю рознь, но вот gpl3 и делали чтобы прикрыть лазейки в gpl2 для тивоизаторов. Вдруг и для авторов grsec какая-нибудь лазейка в gpl2 найдётся.

весело если патчи ядра будут общаться с ядром по RPC

патч никак не может обзащаться, а «закрытый» lsm вполне может.

imul ★★★★★ ()
Последнее исправление: imul (всего исправлений: 1)
Ответ на: комментарий от Zmicier

Таких лицензий вагон и маленькая тележка (собственно это все неявно совместимые с GNU GPL лицензии), только какой от этого толк-то? Они же с точностью наоборот — хотят навязать условия несовместимые с GNU GPLv2, а не ослабить ее авторское лево.

Не, не, не. С точностью до наоборот не надо, вычёркивай. Нужна совместимая ослабляющая. Есть такая?

imul ★★★★★ ()
Ответ на: комментарий от Quasar

Разве патч - это не изменения кода?

Коля, ну вот тебя ещё тут не хватало с твоим тупняком.

imul ★★★★★ ()
Ответ на: комментарий от Vit

Насчет лицензии перестарался.

То есть в этом направлении лазеек в gpl2 нет?

Теоретически, разбить на 2 патча можно. А практически - в данном конкретном случае видимо не получится закрыть так много как хотелось бы жадным детям.

Так много-то и не надо закрывать. PATCH-CREATE/b/grsecurity вполне будет достаточно. У них в основном там вся логика. А дальше уже, ты прав, зависит от их жадности.

imul ★★★★★ ()
Ответ на: комментарий от baka-kun

То есть единственный выход — а) независимый от ядра код, б) интерфейс между ним и ядром под GPLv2, в) сборка непосредственно у пользователя и г) нераспространение в исполняемом виде.

Вернулись опять к моему первому сообщению.
а) и б) они могут сделать раздербанив патч, в) уже есть, г) нераспространение (не только в исполняемом, но и в исходном кроме gpl2 части) для них желаемая цель.
Что им мешает так сделать и не нарушать gpl2?

imul ★★★★★ ()
Ответ на: комментарий от imul

А чому никто не обсуждает _нужность_ grsecurity? Мне интересно, но я со стороны.

xtraeft ★★☆☆ ()
Ответ на: комментарий от xtraeft

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

imul ★★★★★ ()
Ответ на: комментарий от imul

Ну я вот выше приводил пример кода, который на момент своего выхода бил selinux и grsecurity. С моей точки зрения - это полный треш, т.к. по факту безопасности больше не получается, а одни хлопоты и иллюзия защиты. И на какой хер это поделие нужно?

xtraeft ★★☆☆ ()
Ответ на: комментарий от baka-kun

авторские модификации — производная работа

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

право на создание такой работы им даёт только договор (лицензия) на ядро

Да и что? Они и воспользовались этим правом - провели собственную работу.

no-such-file ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.