Что делает лицензию Open Source (как GNU-GPL) средний? [закрытый]
4 ответа
Важно понимать, что «GPL» может относиться к двум лицензиям.
- Стандартная общественная лицензия GNU
- Стандартная общественная лицензия ограниченного применения GNU (также известная как Стандартная общественная лицензия для библиотеки
) Любая из них очень четко указывает, что она рассматривает код из библиотеки, смешанной с программой, как комбинированная работа . Это означает, что если ваша программа загружает библиотеку через динамический загрузчик (то есть общий общий объект) или связывает его статически, полученный исполняемый файл представляет собой совместную работу самой программы и библиотек, которые его поддерживают.
Теперь различия между двумя лицензиями становятся очень важными.
GPL гласит, что если ваша программа использует библиотеку (или любой другой код, подпадающий под действие GPL), она должна быть выпущена на тех же условиях, что и GPL. Это (опять же) потому, что GPL рассматривает получившуюся программу как совместную работу вашего кода плюс работу других.
К счастью (или нет? В зависимости от ваших взглядов), библиотека GNU C не подпадает под действие GPL. На него распространяется LGPL. В LGPL говорится, что простая загрузка и использование системной библиотеки C представляет собой комбинированную работу, но сделано исключение, которое позволяет закрытым приложениям делать это без соблюдения требований GPL к распространению. Таким образом, в этом случае Oracle может свободно использовать системную библиотеку C (необходимую для запуска их кода), не будучи обязанным выпускать свой исходный код.
Если Oracle выпустит программное обеспечение, которое необходимо загрузить или связать с библиотекой под GPL, скажем .. readline () , то да, они будут обязаны поделиться кодом.Oracle (как и многие другие, которые пишут программное обеспечение для UNIX-подобных операционных систем) осторожно выбирает библиотеки, выпущенные под более разрешительной лицензией (также известной как BSD с двумя или тремя пунктами), или реализует свои собственные.
Что касается ядра, простое использование его интерфейса системных вызовов не является совместной работой. Хотя большинство из нас просто позволяет системной библиотеке C абстрагироваться от этих сложностей, вы полностью свободны реализовывать свои собственные системные вызовы на любых условиях. Это иллюстрирует, почему LGPL для системной библиотеки C был очень стратегическим выбором. Если бы все было наоборот, GNU / Linux отпугнул бы больше разработчиков, чем привлек. Также обратите внимание, что многие заголовки Linux, которые определяют магические числа, необходимые для взаимодействия с интерфейсом системных вызовов ядра, вообще не имеют упомянутой лицензии. См., Например, linux / sysctl.h или эту заметку самого Линуса в файле COPYING , распространяемом с ядром:
ПРИМЕЧАНИЕ! Это авторское право не , а не охватывают пользовательские программы, использующие ядро услуги обычными системными вызовами - это просто считается нормальным использованием ядро, и не подпадает ли не под заголовок «производная работа». Также обратите внимание, что приведенная ниже GPL защищена авторским правом Фондом свободного программного обеспечения, но экземпляр кода, к которому он относится (ядро Linux) защищено авторским правом я и другие, кто на самом деле написал это.
Также обратите внимание, что единственная действующая версия GPL, поскольку ядро касается данной конкретной версии лицензии (т.е. v2, а не v2.2 или v3.x или что-то еще), если явно не в противном случае указано.
Линус Торвальдс
Обратите внимание, Линус специально говорит, что использование заголовков ядра и интерфейса системных вызовов не составляет производного (как в измененном) или комбинированного (как в простом использовании) работы. Это, помимо прочего, является частью разрыва между Linux и GNU. Я упоминаю об этом только потому, что вы косвенно упоминаете разветвления GPL. Линус (иногда) хочет код, изменяющий ядро, но выбрал GPL, чтобы гарантировать (иногда) его выбор.
Короче говоря, если вы связываете или загружаете библиотеку, на которую распространяется GPL, вы должны сделать свой код доступным под той же лицензией. Если вы связываете или загружаете библиотеку, на которую распространяется LGPL, условия лицензирования остаются на ваше усмотрение.
Обратите также внимание на то, что LGPL может многое сказать, особенно относительно модификаций, статических ссылок и т. Д. То, что я описал, - это лишь часть ответа на ваш вопрос.
Наконец, GPL применяется только тогда, когда вы распространяете или передаете программу. Вы можете делать все, что хотите, со своим программным обеспечением на своем компьютере, и вы не обязаны делиться им с другими пользователями вашего компьютера (или сервера, или чего-то еще). В AGPL есть что сказать по этому поводу, если программное обеспечение взаимодействует с сетью ... но это тема для другого вопроса.
FSF принимает вопросы, связанные с GPL, по адресу (скрыто) - если вы когда-нибудь сомневаетесь в каком-то конкретном случае и хотите убедиться, что у вас не возникнут проблемы, они довольно дружелюбны и с радостью ответят на вопросы ... даже если вы делаете несвободные программы.Им нравится, когда люди прилагают определенные усилия, чтобы гарантировать, что они должным образом соблюдают лицензию, что, к сожалению, время от времени не происходит.
Эта тема по-прежнему остаётся такой же чувствительной, как и в начале 90-х.
Linux - это ядро, ни одно приложение не будет использовать ядро напрямую, а через библиотеку, обычно GLIBC, которая выпускается под LGPL. Это немного нарушает цепочку GPL, потому что GLIBC вызывает ядро, но это, кажется, согласовано. Так что, боюсь, вы не получите код от Oracle :-).
Если приложение, однако, использует какой-либо код под лицензией GPL, то вы ДОЛЖНЫ сделать исходный текст этого приложения доступным (но не только открытым по лицензии по вашему выбору) под лицензией GPL. Это делает GPL фактически довольно ограничительной лицензией, которая "загрязняет" продукты, поэтому она также известна как вирусная лицензия.
Ключевым отличием от лицензии GPL является то, что составляет «использование» пакета программного обеспечения, выпущенного по этой лицензии. GPL проводит это различие как «включение» или выпуск «параллельно» программного обеспечения под лицензией GPL, независимо от того, составляет ли последнее отношение «на расстоянии вытянутой руки».
Большая часть программного обеспечения, использующего программное обеспечение под лицензией GPL, вероятно, «включает» его, и, следовательно, оно само должно быть выпущено под GPL, если оно будет выпущено. (GPL не требует выпуска, скорее она просто определяет, как должны происходить выпуски.) Например, использование библиотеки на основе GPL квалифицируется как включение.
FAQ , упомянутый в предыдущем ответе , содержит точное обсуждение этой проблемы и дает пример того, где компилятор и ядро квалифицируются как имеющие независимая связь, и, таким образом, компилятор может быть выпущен отдельно без какой-либо лицензии GPL, которая может быть у ядра, при условии, что выпуск будет выполнен правильно. Однако я думаю, что это скорее исключение, чем правило, когда речь идет о GPL.
Также важно понимать, что лицензия GPL значительно отличается в этом отношении от лицензии LGPL , которая является гораздо более либеральной в отношении выпусков.
Я считаю, что большинство ваших вопросов должны быть рассмотрены в FAQ .
Вкратце: Нет, все приложения Linux не обязательно должны иметь открытый исходный код. Нет, вы не можете запросить исходный код для Oracle DB.
Действительно, очень упрощенная GPL гласит, что если вы распространяете двоичные файлы, вы также должны предлагать распространять исходный код. Таким образом, если вы распространяете двоичные файлы ядра Linux, вы также должны предложить распространить исходный код для этих двоичных файлов.