Что означает лицензия с открытым исходным кодом (например, GNU-GPL)?

Ответ 1

Важно понимать, что "GPL" может ссылаться на две лицензии.

• Общая публичная лицензия GNU
• Лицензия GNU Lesser General Public (aka) Общая публичная лицензия библиотеки

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

Теперь различия между двумя лицензиями становятся очень важными.

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

К счастью (или нет? в зависимости от ваших взглядов), библиотека GNU C не покрывается GPL. Он покрыт LGPL. LGPL говорит, что просто загрузка и использование библиотеки C системы представляет собой комбинированную работу, но делается исключение, которое позволяет проприетарным приложениям делать это, не выполняя требования к дистрибуции GPL. Итак, в этом случае Oracle может свободно использовать библиотеку системы C (необходимую для запуска своего кода), не будучи обязанным выпускать исходный код.

Если Oracle выпустила программное обеспечение, необходимое для загрузки или ссылки на GPL-библиотеку, скажем, readline(), то да, они будут обязаны делиться этим кодом. Oracle (как и многие другие, которые пишут программное обеспечение для UNIX-подобных операционных систем) тщательно выбирает библиотеки, выпущенные под более разрешительной лицензией (aka 2 или 3-BSD) или реализует свои собственные.

Что касается ядра, просто использование его интерфейса syscall не представляет собой комбинированную работу. Хотя большинство из нас просто позволяет библиотеке системы C абстрагировать эти сложности, вы можете полностью реализовать свои собственные системные вызовы под любые условия, которые вы хотите. Это иллюстрирует, почему LGPL для библиотеки System C был очень стратегическим выбором. Если бы это было наоборот, GNU/Linux удержала бы больше разработчиков, чем они привлекали. Обратите также внимание на то, что многие заголовки Linux, которые определяют магические числа, необходимые для взаимодействия с интерфейсом syscall ядра, не имеют никакой лицензии. См. linux/sysctl.h, например, или это примечание от самого Линуса в файле COPYING, распространяемом вместе с ядром:

ВНИМАНИЕ! Это авторское право не охватывать пользовательские программы, которые используют ядро услуг обычными системными вызовами - это просто считается нормальным использованием ядро, и не подпадает под заголовок "производной работы". Также обратите внимание, что GPL ниже защищен авторским правом Фондом свободного программного обеспечения, но экземпляр кода, который он ссылается на (ядро Linux) защищено авторским правом меня и других, которые на самом деле его написали.

Также обратите внимание, что единственная действительная версия GPL, поскольку ядро это конкретная версия лицензии (то есть v2, а не v2.2 или v3.x или что-то еще), если явно в противном случае.

                    Linus Torvalds

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

Короче говоря, если вы связываете или загружаете библиотеку, на которую распространяется GPL, вы должны сделать свой код доступным под той же лицензией. Если вы связываете или загружаете библиотеку, на которую распространяется LGPL, условия лицензирования зависят от вас.

Отметим также, что LGPL имеет гораздо больше возможностей, особенно в отношении изменений, статической привязки и т.д. То, что я описал, - это только бит, который отвечает на ваш вопрос.

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

FSF принимает вопросы, связанные с GPL, по адресу [email protected] - если вы когда-либо сомневаетесь в конкретном случае и хотите убедиться, что у вас нет проблем, они довольно дружелюбны и счастливы ответить на вопросы. даже если вы создаете несвободное программное обеспечение. Им нравится, когда люди прикладывают определенные усилия, чтобы обеспечить надлежащее соблюдение лицензии, что, к сожалению, не случается время от времени.

Этот вопрос по-прежнему так же чувствителен, как и в начале 90-х.

Ответ 2

Linux - это ядро, никакое приложение не будет использовать ядро ​​напрямую, а через библиотеку, как правило, GLIBC, выпущенный под LGPL. Это немного разрывает цепочку GPL, потому что GLIBC выделяет Kernel, но это, похоже, согласуется. Так что, боюсь, вы не получите код от Oracle: -).

Если приложение, однако, использует любой лицензионный код GPL, вы ДОЛЖНЫ сделать исходный код для этого приложения доступным (но не только открытым исходным кодом по лицензии по вашему выбору), лицензированным в GPL. Это делает GPL фактически довольно ограничительной лицензией, которая является "заражающей" продукцией, поэтому она также известна как вирусная лицензия.

Ответ 3

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

Большинство программ, в которых используется программное обеспечение, лицензированное GPL, вероятно, "включит" его, и поэтому оно должно быть освобождено под GPL, если оно будет выпущено. (GPL не требует освобождения, а просто управляет тем, как должны происходить выпуски.) Например, использование библиотеки на основе GPL относится к инкорпорации.

FAQ, который упоминался в предыдущем ответе содержит точное обсуждение этой проблемы и дает пример того, где компилятор и ядро ​​квалифицируются как имеющие отношение длины руки, и, следовательно, компилятор может быть выпущенный отдельно без лицензии GPL, которую может иметь ядро, при условии, что выпуск выполнен правильно. Это, однако, я считаю скорее исключением, чем правило, в котором участвует GPL.

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

Ответ 4

Я считаю, что большинство ваших вопросов должно быть покрыто FAQ.

Вкратце: Нет, все Linux-приложения не должны быть открытыми. Нет, вы не можете запросить исходный код для Oracle DB.

Действительно, упрощенная GPL говорит, что если вы распространяете двоичные файлы, вы также должны предлагать распространять источник. Поэтому, если вы распространяете двоичные файлы ядра Linux, вы также должны предлагать распространять источник для этих двоичных файлов.