Релиз ОС Genode 20.08

Оно развивается очень даже прилично, в оборонке в том числе. Но цены конские на саму среду разработчики 850 тыс.р, сама ось примерно 12 тыс стоит.

AGPL? В смысле, любой веб-сайт, который хочет вызвать ядерную функцию - должен раскрывать исходники веб-интерфейса?

Ненужно

где-то есть и инструкция, как по этому фреймворку построить свою ОС?

https://genode.org/documentation/genode-foundations/index - таки есть.

А так ли велика разница, между веб-сайтом и драйвером видеокарты в данном контексте?

любой веб-сайт, который хочет вызвать ядерную функцию - должен раскрывать исходники веб-интерфейса

Из всех идиотских высказываний про ГПЛ что я слышал это, пожалуй, самое тупое.

Но не такое говно, как XML. JSON - вот он показал себя хорошо во многих применениях.

xml2json -x xml-file -s schema-files -o json-file

Вообще без разницы - одно в другое тривиально конвертируется.

И упаси небо вляпаться в Го/Расты какие-нть.

А что тебя в них не устраивает? Помимо того, что ты их не осилил разумеется.

gcc-говна

И кому это говно надо??

Что за болезненная фиксация не фекальной тематике. У тебя запор что-ли? Поэтому ты такой злой?

Есть конечно. Как минимум описание того, как устроен Sculpt. Также есть серия статей от Norman Feske, по построению маленькой Unix-like ОС https://genodians.org/nfeske/2019-12-13-goa-unix-bash

зачем люди используют линукс? Чтобы запускать на нем свои веб-сервисы с закрытым исхоным кодом и продавать результаты их работы. Для этого у линукса есть бридж из LGPL библиотек и прослойка коммандлайновых утилит с пайпами

AGPL в отличие от GPL переопределяет понятие пользователя. Пользователю нужно раскрывать все исходники. В случае сдрайвером это окажется человек, сдиящий за компьютером, в котором работает драйвер. В случае с сайтом, пользователь - это человек, пользующийся сайтом. Это «сквозная» лицензия

Операционная система, на которой нельзя запустить сервис, который можно продать - нужна только очень небольшому количеству людей. Какому-нибудь 0.001% энтузиастов.

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

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

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

А что, неужели для этого нет опенсорсных решений? Не, ну понятно, я согласен, что слова «майки из Китая» надо будет вписать в какой-то шаблон :) но всё остальное-то?

Для этого у линукса есть бридж из LGPL библиотек

Даже библиотек не надо: system call interface линукса не GPL:

   NOTE! This [примечание: GPL] copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".

По сути превращая ядро для всех библиотек и программ в LGPL.

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

В таких случаях действительно логичнее писать, что продукт доступен по коммерческой лицензии, а также по [A]GPL, но не наоборот.

P.S. И вот если пишут, что использование GPL кода через нормальное API - это нормальное использование GPL кода, а не производная работа. То почему, если какая-то здоровенная GUI программа использует маленькую GPL-библиотеку для сохранения каких-то данных в какой-то редкоиспользуемый формат, используя открытый API этой библиотеки, вдруг становится производной работой от неё. Ведь у библиотеки точно так же как и у ядра кроме публичного API есть ещё и внутреннее API.

Угу, а запуск GPL программы в проприетарном шелле или наоборот делает всё GPL! 146% именно так оно и работает!

Я, в целом согласен, однако акценты расставлю иначе. Эти люди понимают, что они живут в крайне маргинальной области и их аудитория — немногочисленные любители и энтузиасты. Какую лицензию не поставь, но вы, лично вы всё равно будете держать свой сайт на линуксе (или фре). Потому что они лучше, быстрее и дешевле. А вот тотальный AGPL — хорошая фишка. Кроме того в их случае вопрос что является частью ядра, а что просто его использует не так тривиален, поэтому возможно они просто решили подстраховаться.

всё правильно, потому что такое использование не является GPL

И вот если пишут, что использование GPL кода через нормальное API - это нормальное использование GPL кода, а не производная работа.

это не универсальное правило там написано, а исключение, которое юридически создает новую лицензию

в файлах с заголовками не используется лицензия «GPL», прямо в файле исходника написано «GPL-2.0 WITH Linux-syscall-note». Там в исходниках лежит файл COPYING, в котором про это написано подробней

точно так же, например, Java лицензирована не как GPL, а как «GPLv2 with the Classpath Exception»

А вот и разгадка: https://genode-labs.com/products/index

Это платформа для ARM виртуализации для датацентров. Все-таки их маркетологи не идиоты,

AGPL - это что-то вроде «бесплатного триала» - попробовать можно, а использовать нельзя. Если у тебя датацентр, иди покупай коммерческую лицензию

Не всем же, как bsd-шникам, хотеть на дядю даром работать. Кому-то нужно и эгоисты идти для баланса.

это не универсальное правило там написано, а исключение, которое юридически создает новую лицензию

Да, интересен именно прецедент понятия «нормальное использование» GPL кода без получения производного продукта. Ведь это же действительно 2 разницы: когда я что-то добавляю или изменяю в GPL коде библиотечного типа, используя его внутреннее API, и результат - модифицированный GPL код, производная работа. И если я ничего в нём не трогаю и вызываю этот отдельный код, используя только разрешённый API, в программе из совершенно другой области, а получается, что эта программа, вдруг, становится производной от того обособленного кода. Когда программа под GPL - всё понятно. Но обособленная GPL-библиотека - это странно.

точно так же, например, Java лицензирована не как GPL, а как «GPLv2 with the Classpath Exception»

И gcc тоже с исключением для runtime кода.

«нормальное использование» GPL кода без получения производного продукта

ты обязан предоставлять код пользователю

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

в схеме юзер->(http)->сайт->(линковка)->gpl-библиотека, GPL начинается с библиотеки, потом через линковку распространяется на сайт, и дальше цепочка обрывается. Потом что дальше http, а это не линковка. С тем же успехом там может быть что угодно другое - вызов через shell, сокеты и вебсокеты, общение через асинхронный «почтовый ящик», что угодно

в случае юзер->(http)->сайт->(линковка)->agpl-библиотека, пользователем является юзер, и поэтому тебе нужно раскрыть все исходники цепочки до него - то есть, нужно включить туда исходники сайта

используя только разрешённый API

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

Смотри дело Oracle vs Google. Он еще не закончился, следующее заседание 7 октября или будет перенесено на 2021, но пока Google проигрывает, к сожалению. То есть, будет считаться, что API - это код.

используя только разрешённый API

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

а) Ты приложил её в дистрибутив своей программы. Значит бинарно у тебя в твоем продукте лежит чужой код, и это совершенно очевидно создает произвольную работу. Еще бы, ты стащил себе чужой код!

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

Есть некий обходной маневр (я не могу сейчас тебе привести кейсов в суде про это, к сожалению), когда люди компилируют софт, слинкованный на GPL библиотеку, а когда распространяют дистрибутив - эту библиотеку из дистриба просто удаляют. При этом не делают зависимость в пакетном менеджере и не прикладывают никаких скриптов для скачивания. И пользователю пишут - ну знаешь, получай эту библиотеку как хочешь. Если рядом где-то при этом есть хорошая статья как её получить, и эта статья не является частью дистрибутива - это может сработать. Вроде, люди так распространяют ffmpeg, например. Но хотелось бы иметь разобранный кейс в суде, чтобы использовать эту практику без опаски.

Но обособленная GPL-библиотека - это странно.

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

Тут кстати, юристам привалило работы по поводу докеров. Потому что докерные образы же, формально, бинарные - значит с определенной долей фантазии это можно назвать линковкой!

2000-е давно прошли, сейчас модно жэсон, томээль, яамээл и т. д. А они всё на xml сидят.

2000-е давно прошли, сейчас модно жэсон, томээль, яамээл и т. д. А они всё на xml сидят.

Видимо они ещё не потеряли рассудок и сохраняют совместимость, а не гонятся за модой.

Но как же не быть стильным модным молодёжным?

в случае юзер->(http)->сайт->(линковка)->agpl-библиотека, пользователем является юзер, и поэтому тебе нужно раскрыть все исходники цепочки до него - то есть, нужно включить туда исходники сайта

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

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

Это фишка AGPL такая. Специальная такая лицензия.

требования такой лицензии в принципе не выполнимы на современных ЭВМ, где кроме софтовой части выполняемой на ЦПУ множество контроллеров с встроенным микрокодом.

AGPL в отличие от GPL переопределяет понятие пользователя.

Враньё. Это ты зачем-то пытаешься переопределить AGPL.

Пользователю нужно раскрывать все исходники.

Снова брехня.

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

Офигеть ты догадливый конечно :-D

По сути превращая ядро для всех библиотек и программ в LGPL

Даже близко не так. Это примечание вообще никак не меняет термины на которых лицензируется ядро. Собственно всё замечание там добавлено исключительно дабы в явном виде прояснить ситуацию тем кто слабо разбирается в лицензиях. Помогает, судя по твоим комментариям, не всегда.

В таких случаях действительно логичнее писать, что продукт доступен по коммерческой лицензии, а также по [A]GPL, но не наоборот.

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

если какая-то здоровенная GUI программа использует маленькую GPL-библиотеку для сохранения каких-то данных в какой-то редкоиспользуемый формат, используя открытый API этой библиотеки, вдруг становится производной работой от неё

Потому что это и есть производная работа. Не нравится - используй другую библиотеку.

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

Это отдельная от GPL лицензия

https://www.gnu.org/licenses/why-affero-gpl.ru.html

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

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

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

Даже близко не так. Это примечание вообще никак не меняет термины на которых лицензируется ядро. Собственно всё замечание там добавлено исключительно дабы в явном виде прояснить ситуацию тем кто слабо разбирается в лицензиях.

Ну почему же. Вот написал я программку, которая использует только открытый ядерный API, т.е. системные вызовы. Прописал её запуск в параметрах ядра. И теперь распространяю бинарное GPL-ядро с моей бинарной закрытой программкой. Но при этом должен предоставить только исходники ядра, а не моей программки. Как будто я использую LGPL библиотеку, а не GPL. Подчеркиваю, хоть формально линковка, системные вызовы, RPC-вызовы, конечно же, отличаются. На практике у них одна цель: обеспечить вызов кода.

Genode именно и в первую очередь это свободный продукт.

Может быть, но как это проверить про «первую очередь». Я руководствуюсь таким правилом: если разработчик общественная организация, нон-профит компания, то да. Если разработчик частная коммерческая компания, то нет, не в первую. Genode уже давно разрабатывается Genode Labs GmbH, частной коммерческой фирмой. Отсюда мой вывод.

Потому что это и есть производная работа. Не нравится - используй другую библиотеку.

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

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

Потом что дальше http, а это не линковка. С тем же успехом там может быть что угодно другое - вызов через shell, сокеты и вебсокеты, общение через асинхронный «почтовый ящик», что угодно

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

Вероятно потому, что линковка заставляет рядом с твоим проприетарным кодом класть ещё и бинарно скомпилированную свободную библиотеку. Иначе код тупо не заработает. Столлмана, когда он всё это изобретал, в первую очередь интересовало, чтобы на каждый бинарник был исходник. На каждый бинарник, котрый ты имеешь физически в руках на каком-то носителе. Первая версия GPL опубликована 25 февраля 1989 - тогда не было еще никаких RPC, и только безумец мог придумать такую неэффективность как HTTP интерфейсы к любому умному выключателю. «Облако» не являлось «носителем», «облачный сервис» не был «моделью вычислений» и не мог использоваться как «service as a software substitute». Это всё слишком новые концепции. Потом уже начали случаться штуки вроде тивоизации, от которой у Столлмана подгорел пердак, и тому подобное. В случае с RPC у тебя нет бинарника, значит и прав на исходник у тебя тоже никаких нет, всё логично (по крайней мере, с точки зрения человека из 1980-ого года).

ну и вообще, у того же Столлмана нет никакой неприязни к in-house разработке. Что такое in-house? Ты обязан раскрывать исходники не всем подряд, а только тем, кто реально воспользовался результатом работы программы. Поэтому если в конторе разрабатывается какой-то «внутриконторский софт», которым могут пользоваться только сотрудники, и наружу его нигде скачать нельзя - это дает право получить исходники только сотрудникам, а не произвольному человеку в интернете. Столлман никогда не имел ничего против этой схемы.

по мне так, сейчас самое главное зло - это облака, и GPL не решает эту проблему никак. В big data важнее данные, чем код. Даже если у условного Васи будет весь код Facebook, он ни по какой лицензии не получит пользовательскую базу, данные профилей, твиты этих людей, и так далее. Имхо, проблему нужно вывёртывать наизнанку: разрешить проприетарным облакам использовать любые свои проприетарные коды, а вот данные каким-то образом обязать отдавать наружу в универсальном формате, не зависящем от конкретной реализации софта. Тогда много компаний смогут соревноваться за то, кто лучше обработает одни и те же данные.

До Столлмана это тоже дошло, но у него пока какая-то истерика на тему «не используйте фейсбук», «не используйте ютуб», хотя совершенно очевидно, что не использовать такие сервисы обычному человеку не получится. Сейчас над этой проблемой думает правительство США, последнее анимонопольное разбирательство - порка, когда всех глав больших корпораций притащили на один большой созвон - звоночек. Сейчас вот это дело Epic Games vs Apple. Что-то куда-то движется, но не очень активно

требования такой лицензии в принципе не выполнимы на современных ЭВМ, где кроме софтовой части выполняемой на ЦПУ множество контроллеров с встроенным микрокодом.

Когда у тебя есть «интерпретатор» и «скрипт» - это просто два продукта, лежащие рядом. Они самопроизвольно не смешиваются как на уроках химии, образуя производную работу :) Вот если кто-то их положил вместе в один дистрибутив (ака программно-аппаратный комплекс) - тут уже вопросы

Например, можно запускать проприетарный код в свободном шелле или наборот - свободный код в проприетарном шелле, и это никак их не склеит в одно целое

У тебя в примере интерпретатор - это процессор

По этому поводу есть забавные сто лет тянущиеся разборки с Apple по поводу легальности установки macOS на компьютеры с железом не от Apple в Европе. (в США такое законодательство, что ты можешь согласиться на любое анальное рабство). Которые сейчас Apple пресечет с помощью перехода на кастомный ARM

Например, можно запускать проприетарный код в свободном шелле или наборот - свободный код в проприетарном шелле, и это никак их не склеит в одно целое

ты сам себе противоречишь, вот твоя интерпретация AGPL под воздействием опиатов

в случае юзер->(http)->сайт->(линковка)->agpl-библиотека, пользователем является юзер, и поэтому тебе нужно раскрыть все исходники цепочки до него - то есть, нужно включить туда исходники сайта

сайт это и есть скрипт, а системные библиотеки с AGPL это часть интерпретатора

черт, надо с этим разобраться. Я могу придумать правдоподобное объяснение за обе стороны баррикады

это что-то вроде «бесплатного триала» - попробовать можно, а использовать нельзя

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

в случае юзер->(http)->сайт->(линковка)->agpl-библиотека, пользователем является юзер, и поэтому тебе нужно раскрыть все исходники цепочки до него

И близко не так разумеется - ты сам этот бред выдумал или прочитал где-то?

Смотри дело Oracle vs Google

Это вообще к GPL никак не относится. Там разборки про то подпадает-ли независимая реализация API под копирайт или нет.

Вроде, люди так распространяют ffmpeg

Это где ты подобное видел?

это специально сделано, чтобы люди подсаживались на свободное ПО

Это специально сделано чтобы проприетарщики не могли паразитировать на чужом коде. Вполне естественное желание.

Там разборки про то подпадает-ли независимая реализация API под копирайт или нет.

Кстати Wine попадает или нет?

Я руководствуюсь таким правилом

Да на здоровье! Но с чего ты решил что этим правилом должен руководствоваться кто-то ещё?

если никакого отношения к коду той библиотеки нет

Ну если и вправду никакого отношения нет, то и распространяй без библиотеки ничего не открывая - вообще никаких проблем нет. Разве что не очень понятно что проприетарщик забыл на данном сайте.

к лицензионному замечанию к ядру написано, что если вы используете его публичный API - то это, конечно же, не означает, что ваша к ядру не относящаяся программка стала, вдруг, производной от него работой

И в gcc на всякий случай похожее прописали, и в OpenJDK Classpath, и наверняка много где ещё. Разработчики по возможности стараются явно определить потенциально спорные ситуации.

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

Чё? Во-первых с какого хрена, а во-вторых как ты этот бред вывел из предыдущего предложения?

Ведь если я напишу GPL-программку, предоставляющую RPC-интерфейс к маленькой GPL-библиотеке, то та здоровенная программка всё равно будет приравнена к слинкованной, хотя она через HTTP общается.

Это называется, пардон, GPL-condom - как раз в последней версии ядра (5.9) смерджили дополнительную защиту от подобных говнюков.

Основная идея genode, что это, все таки, фреймворк для OS. Любой компонент может быть заменен. Можно взять написать/готовое ядро на rust и использовать c genode.

сделали бы уже какой нибудь протокол-прослойку для драйверов и ввели бы его как сдандарт для опенсорс сообщества - тогда бы у всех свободных ос была единая база драйверов и работоспособность оборудования не зависела от версии ядра.

А если headless для embedded?

Его почти сделали, Linux называется. В genode через dde_linux как раз и тянут драйвера. Но, пока еще этот подход требует много ручной работы.

по мне так, сейчас самое главное зло - это облака, и GPL не решает эту проблему никак

В том числе под это и придумали AGPL. В его оригинальном варианте разумеется, а не в твоей странной интерпретации.

а вот данные каким-то образом обязать отдавать наружу

Это вообще область GDPR, оно к свободе софта вообще никак не относится. Непонятно, зачем ты это сюда приплёл?

хотя совершенно очевидно, что не использовать такие сервисы обычному человеку не получится

В твоём маня-мирке - вполне возможно. На практике фейсбуком не пользуюсь не только я, но и здоровенная часть пользователей интернета, не говоря уже о населении планеты в целом. По оценкам интернетом пользуется около 4.8 лярдов, а активных пользователей фейсбука около 2.7 - то есть твоё «не получится» промахнулось всего-то на пару миллиардов человек. Ты не просто в лужу пёрнул - ты её испарил своим выхлопом :)

Что-то куда-то движется, но не очень активно

Это довольно точное описание твоей мыслительной активности.

Его почти сделали, Linux называется.

В Linux нет стабильных интерфейсов ядра и драйверов.

Его почти сделали, Linux называется. В genode через dde_linux как раз и тянут драйвера. Но, пока еще этот подход требует много ручной работы.

ну разве что «почти». Еслиб сделаи - то не требовалось бы много ручного труда и в том же самом генод работало бы всё что и в линуксе.

Кстати Wine попадает или нет?

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

С чьей точки зрения?

С точки зрения суда. Хотя в США суд Шрёденгера: пока не начнётся судебный процесс результат не определён.

В Linux нет стабильных интерфейсов ядра

Есть разумеется - там очень тщательно следят за тем чтобы не поломать интерфейсы userspace.

Есть разумеется - там очень тщательно следят за тем чтобы не поломать интерфейсы userspace.

Имеются ввиду интерфейсы ядра для модулей ядра.

С точки зрения суда.

Какого именно? В мире разные системы права, которые по-разному трактуют данный вопрос.

Какого именно?

США.

Имеются ввиду интерфейсы ядра для модулей ядра.

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