Должна ли лицензия на патч ядра быть GPL?

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

>Я имею ввиду не лицензию на всё ядро, пусть и патченное, а именно лицензию на сам патч.

На ЛОРе мелькали новости про ядерные реализации ZFS. Можно посмотреть, как те авторы решили этот вопрос.

Так в том и вопрос попадает ли патч под понятие производной работы, следовательно и под GPL?

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

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

> На ЛОРе мелькали новости про ядерные реализации ZFS. Можно посмотреть, как те авторы решили этот вопрос.

Может они просто не использовали код от SUN и всё реализовали с нуля по спецификациям?

>Может они просто не использовали код от SUN и всё реализовали с нуля по спецификациям?

Да. Я запутался, подумав о другой проблеме. Насколько мне известно, там есть какие-то патентные ограничения на эту ZFS. Вот я и задумался, как те авторы их обошли. Если бы это удалось повторить, проще было бы написать свой код под GPL с нуля.

Do I have to release the patch for a GPL software under GPL?

Вызывает большие сомнения фраза:

It is completely irrelevant what the form of the patch is, your patch does not work without the GPLed work, and cannot be used without it so it is a deriviate work.

Мой дистрибутив не работает без ядра Linux. Должны ли все программы быть перелицензированы?

Что качаемо ZFS, достаточно распространять его отдельно от ядра модулем.

> Мой дистрибутив не работает без ядра Linux.

уверен? даже под каким-нибудь гипотетическим line? (line is not an emulator) ;)

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

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

уверен? даже под каким-нибудь гипотетическим line? (line is not an emulator) ;)

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

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

Интересно, на каком основании он это утверждал.

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

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

> Интересно, на каком основании он это утверждал.

говорил, что это очевидно :)

If you use standard UNIX system calls (with accepted Linux extensions), your program obviously doesn't «derive» from the kernel itself.

The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL.

There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an «exception» — it's just a statement of a border of what is clearly considered a «derived work». User programs are clearly not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.

> Но необходимость таких нетривиальных рассуждений для корректного толкования, имхо, дискредитирует GPL.

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html — здесь толпа людей, в.т. Торвальдс, не могут толком понять, нарушают ли гпл проприетарные модули :)

Вот и я говорю: бардак. И ни разу это не очевидно. Точнее так, мне лично очевидно, что проприетарная программа, использующая либу на GPL, не нарушает GPL. Потому что у меня такие понятия о deriviate work.

LGPL не нарушает, GPL нарушает

Спасибо, кэп. Вот только при моём толковании derived work, это не так. Почему их толкование правильнее - хз.

Не, я целиком и полностью согласен, лицензирование сейчас совсем *банутая область.