Интересует возможность делать коммерческое ПО под linux. И для начала решил разобраться с лицензиями на ПО. И возник такой вопрос. (ссылки на гугл и вики не надо давать, искал, читал, не понял....) Если я делаю программный продукт состоящий как-бы из двух частей: Код на прикладном уровне( UNIX) который взаимодействует с модулем уровня ядра Linux. Модуль написан мной, но вплотную взаимодействует с кодом ядра, где активно использует структуры(получает информацию, модифицирует данные ..) и некоторые функции из исходников kernel .( как пример можно рассмотреть применении таких функций как printk , list_add, list_for_each , filp_open и тд. ). Могу ли я такой софт распространять на коммерческой основе? Не попадает ли модуль ядра под эту GPL ?
Great Если считать про первую часть которая работает на прикладном уровне, то это бесспорно да, могу. Но тут огромное НО¸ из-за второй части этого ПО, так как оно представляет из себя модуль ядра и фактически использует в своей работе функции и структуры ядра, которые находятся в исходном коде определённой версии ядра linux , которые находятся под лицензией GPL . Значит я могу поставить любую лицензию на этот модуль и никаких проблем с законодательством возникнуть не должно?
Если бы ты распространял сами исходники ядра в каком-либо виде под другой лицензией - этода, нельзя. Но у тебя же _собственный_ код. Не важно, что он использует GPLное ядро. Насколько я знаю.
Great Не так всё просто. Можно вспомнить историю с clisp'ом, который использует библиотеку readline. Из-за этого, Haible в один прекрасный момент получил письмо от Столлмана, который предложил распространять clisp под GPL. Они некоторое время спорили, и теперь clisp под GPL лицензией. Собственно из-за такого рода проблем и придумали LGPL, которая позволяет линковать LGPL библиотеку к программе, не открывая сорцов этой программы. Скажем, glibc под LGPL, что позволяет написать распространять пропиетарную программу под linux не таская за собой свою libc, а пользуясь системной. Ядро под GPLv2. Но тем не менее, модуль ядра распространять с закрытым кодом можно. Ведь существуют модули ядра с закрытыми сорцами. Наиболее известные -- это дрова для видеокарт. Почему это так -- я не знаю, в тонкости не вникал. Кстати, быть может это накладывает какие-то ограничения на возможности модуля. ps. Оффтоп, но всё же: пропиетарные дрова -- это, по-моему, одна из самых убогих вещей, которая может придти в голову программисту. Ладно прикладной софт, его бажность не критична для работы системы. Но ядерный код, который может просто по-приколу разбрасываться kernel-panic'ами -- это уже гораздо хуже. Мне, честно говоря, за глаза и за уши хватает дров на видеокарту, со всеми их багами и со всеми порождаемыми ими геморроями при пересборке/обновлении ядра. Я когда только-только влез в линукс, первым делом провёл апгрейд железа: сменил pci-модем на COM'овский Zyxel (до сих пор у меня на полке стоит, как памятник). Просто чтобы избавиться от необходимости иметь дело с закрытыми дровами. Была б возможность, я б точно также и видеокарту погрейдил. Да хоть бы и даунгрейдил, ещё бы и денег заплатил. Если бы мне дали видяшку с 32-64M памяти, более-менее пристойным ускорением, и открытым драйвером ядра. А ещё лучше, если драйвер был бы реализован в user-space. эхх. несбыточные мечты.
Это добавляет кучу лишних переходов ядро-юзермод и юзермод-ядро, а видеокарта критична для игр и проч. Так что это вряд ли.
r90 Кстати да, читал что многие функции для модуля будут не доступны. (но это всегда можно обойти) Спасибо за развернутый ответ.
Насчёт медленности работы юзерспейсного драйвера видеокарты: ты предполагаешь, или можно почитать какие-то исследования на эту тему? Но, даже если игры и будут медленнее бегать -- мне плевать на игры. Я играю раз в год. И то в игры десятилетней давности. Мне 3d-акселератор нужен, для того, чтобы обычные приложения отрисовывались без тормозов. Плюс есть пара программ, которые используют OpenGL для вывода. При существующих дровах, вывод графики в наихудшем варианте не отъедает и 10% времени процессора. Так что если это время увеличиться на десятую часть, и достигнет 11%, то я нисколько не пострадаю от этого. И по-моему стабильность системы того стоит. Пускай игроманы разглядывают бсоды, почему меня должны задевать их проблемы? Но я почему-то думаю, что "кучи" лишних переходов ядро<->юзерспейс не будет. Никто не мешает буферизировать данные отправляемые в видеокарту и засылать их в kernel-space пакетно. То же самое с данными идущими навстречу. Кроме того, можно же в ядро вставить небольшой модуль-адаптер, который упростит все эти действия. По-моему, тут проблемы абсолютно другого характера. Либо нвидиям страшно вытаскивать драйвер из ядра, поскольку его ревёрсить будет проще. Либо они не считают стабильность моей системы достаточной причиной, для того, чтобы переписывать ту груду кода, которую они называют драйвером. А у них ведь действительно груда кода. Драйвер ядра (файлик .ko) весит пять метров. Ядро, в которое статически вкомпонованы практически все остальные необходимые мне дрова, весит 30M. То есть драйвер видяхи -- это шестая часть ядра, не хреново так, да?
а мс, тогда по вашему зачем все в ядро запихали в нт? раньше ведь в юзере было. либо их продукция рассчитана для игроков. и как следствие скорость при выше всего.
spa 1. Мотивы поведения MS очень непредсказуемы. 2. Раньше -- это когда? В '95 венде? Не верю. Или в 1.0? Во сколько раз повышается производительность видеокарты за год? Процентов на 10%? На 20%? Или больше? В 2001 я покупал видеокарту с 8M оперативки на борту, сегодня гигабайт -- это нормально. 2^7 за 9 лет. В два раза повышается производительность? И на фоне этого единоразовое снижение скорости на 10% -- это ничто. Но то, что они затачиваются на игроманов -- это очевидно. И сегмент рынка не игроманов просто пустует. Есть у меня надежда на открытое железо... Может OpenHardware привнесёт разнообразие в железо?
2) Ознакомьтесь с архитектурой НТ, хотя бы поверхностно, если не верите. Вообще речь про линейку NT, 9х мы в рассчет не берем. Она уже мертва. В линейке NT до Windows 2000 (NT4, NT3) графика была в юзермоде. Начиная с Windows 2000 перенесли в ядро (печально известный win32k.sys своими багами). 1) Причина была очевидна - графика жестко тормозила из-за кучи переходов юзер-кернел и кернел-юзер, которые весьма трудозатратны. Правда, после переноса появилась другая проблема - написанный наспех код содержит весьма нехилое число ошибок. Сплоиты все видели для win32k.sys да?)
Great Люблю ответы, источающие конструктивность. Я могу допустить, что это очевидно. Но мне всё равно неочевидно, что единственный способ решения этой проблемы -- это иметь в ядре драйвер размером в 11Mb. (Я кстати наврал выше про 5M: не туда глянул, ещё удивлялся чего это так мало. Не 5, а 11)
