Модули ядра Non-GPL с помощью [закрытых] GPL
Может быть, вам нужно изменить источник данных коллекции
guard let textFields = alert.textFields else { return }
settingsVC.arr.append(textFields.first!.text!) // arr is collection dataSource
settingsVC.collectionView.reloadData()
5 ответов
Для модулей имеется флаг GPL_ONLY , который не следует использовать в модулях не-GPL. Так что если модуль, о котором вы говорите, не GPL_ONLY , вы можете использовать его.
Но даже те, которые являются GPL_ONLY , могут использоваться, если вы обращаетесь к ним через драйверы user-space , что возможно в 2.6.23 . Именно так и произошло с USB-подсистемой. http://www.linux-magazine.com/online/news/linux_2_6_25_without_closed_source_usb_drivers
Не совсем относится к юридической проблеме, но дает вам некоторое представление: http://www.cyberciti.biz/tips/linus-rejects-the-idea-of-non-gpl-kernel-modules.html
IANAL, поэтому вам действительно следует обратиться за квалифицированным юридическим заключением. Однако это подход, безусловно, идет вразрез с духом лицензии и не выиграет у вас друзей на земле ядра.
Однако вы могли бы рассмотреть другой раскол. Один подход заключается в том, чтобы иметь полностью GPL-модуль и поместите все ваши "секретные IP-адреса компании" в пользователя космический водитель. Это подход, который я использовал, когда компания, в которой я работал не хотел показывать детали нашей ПЛИС миру. Все решения и зарегистрировать настройки, где решено в пользовательском пространстве и сторона ядра драйвера только что загрузила значения в IRQ. С осторожностью дизайн вы можете решать любые проблемы в реальном времени, которые могут возникнуть и иметь хорошее чистое разделение между вашим закрытым драйвером и ядром. я считаю, что это проще с новыми ядрами с поддержкой пользовательского пространства драйверы, хотя я не думаю, что они поддерживают DMA должным образом (мне пришлось закодировать модуль ядра DMA пользовательского пространства для поддержки DMA непосредственно между чипсет и пространство пользователя).
Однако (опять же) я бы порекомендовал вам подумать, что это за ваш пытаясь защитить. Закрытые драйверы могут быть в порядке для встроенных приложений где у вас есть жесткий контроль над версией ядра и аппаратного обеспечения. Но если этот драйвер рассматривается для чего-то более общего (т.е. продавая оборудование люди подключатся к своим системам) потом закрыли исходные драйверы окажутся только источником постоянной боли и головные боли от обслуживания.
1-й: Вам нужно поговорить об этом с адвокатом; вероятно, юридический отдел вашей компании.
2-й: Важный вопрос - какой кусок кода получен из какого другого кода.
К сожалению, на этот вопрос существует практически любое количество ответов.
Некоторые считают, что все модули ядра являются производными от ядра, поэтому должны быть включены под GPL независимо от включения заголовка.
В качестве альтернативы ваш закрытый модуль является производным от модуля GPL, а модуль GPL - от ядра, поэтому закрытый модуль также должен быть GPL.
Некоторые ключевые разработчики ядра (но не сам Линус) придерживаются мнения, что любой модуль не из GPL является нарушением лицензии ядра.
Когда некоторые разработчики оторвали драйвер Belkin от маршрутизатора Linksys, перепроектировали его и опубликовали результат, Belkin не смог их остановить из-за противодействия доставке этой интерпретации лицензии в суд, как защита.
Бесчисленные другие драйверы использовали «shim» с открытым исходным кодом для соединения объектного файла с закрытым исходным кодом с ядром с открытым исходным кодом. Это считается большинством разработчиков ядра нарушением, по крайней мере, в духе GPL.
По моему мнению, это зависит от того, распространяете ли вы программное обеспечение. Если вы используете это исключительно на программном обеспечении как услуга, это должно быть разрешено. Если вы распространяете встроенное устройство или коробочный продукт, это нет-нет.
Извлеките все необходимые вам функции из ядра или откройте исходные тексты компонентов ядра. Это то, что делают все остальные (честно), и обычно это не так сложно, потому что у любого, кто обладает значительным количеством «интеллектуальной собственности» в пространстве ядра, либо плохая бизнес-модель, либо некомпетентная команда инженеров.
* выше мое мнение *