Как правило GPL о статических и динамических связях применяется к интерпретируемым языкам?

19

В моем понимании, GPL запрещает статическое связывание кода не-GPL с кодом GPL, но разрешает динамическое связывание кода не-GPL с кодом GPL. Так что же происходит, когда рассматриваемый код вообще не связан, потому что код написан на интерпретируемом языке (например, Perl)?

Казалось бы, было бы слишком легко использовать правило, если бы оно рассматривалось как динамическое связывание, но, с другой стороны, было бы также невозможно юридически ссылаться на код GPL из кода не-GPL, если он считался статическим! Скомпилированные языки, по крайней мере, имеют различие между статическим и динамическим связыванием, но когда все «связывание» - это просто выполнение сценариев, невозможно сказать, что это такое, без явной лицензии!

Или мое понимание этой проблемы неверно, что делает вопрос спорным? Я также слышал об «исключении classpath», которое включает в себя динамическое связывание; Разве это не часть GPL, а что-то, что можно добавить к нему, поэтому динамическое связывание разрешено только тогда, когда лицензия включает это исключение?

ekolis
источник
Вы читали gnu.org/licenses/lgpl-java.html ?
2
@delnan lgpl! = gpl
Иоганн
softwareengineering.stackexchange.com/questions/87446/…
Сиро Сантилли 新疆 改造 中 at 法轮功 六四 事件

Ответы:

16

Что касается конкретного вопроса, касающегося переведенных языков, то в GPL FAQ очень ясно сказано :

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

Что касается общего вопроса о динамическом и статическом связывании. Прежде всего, по мнению FSF и Столлмана, не имеет значения, является ли связывание статическим или динамическим, GPL заражает в любом случае. Из FSF GPL FAQ:

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

и

Статическое или динамическое связывание [имени вашей программы] с другими модулями создает совместную работу на основе [имени вашей программы]. Таким образом, условия GNU General Public License распространяются на всю комбинацию

Однако это сомнительно с юридической точки зрения. В единственном деле, которое фактически было передано в суд в отношении динамического связывания - Galoob v. Nintendo - Апелляционный суд постановил, что производное произведение «должно включать часть защищенного авторским правом произведения в какой-либо форме» . Что не относится к динамическим связям.

В любом случае, независимо от того, действительно ли динамическое связывание заражает или нет, существует обходной путь. Например, он используется Nvidia для предоставления бинарных драйверов для Linux. Вы создаете (L) оболочку GPL, но как автор вы можете добавить специальное исключение для связи с конкретным закрытым исходным кодом. Vide FSF GPL FAQ .

Vartec
источник
Одна из сущностей производного произведения заключается в том, что невозможно четко отделить оригинальное произведение правообладателя. Если Боб Foo()статически связан с вызовом Джо Bar(), к какому владельцу авторских прав следует CALLотнести указание между ними? Такое взаимодействие было бы достаточно, чтобы составить «производную работу». Если, однако, работа Джо остается полностью в одном файле, а работа Боба - полностью в другом, простое появление этих файлов в разных каталогах на одном диске представляет собой агрегацию, а не вывод.
суперкат
2
@thepaul: уже существует правовой прецедент, который гласит, что по крайней мере часть работы, защищенной авторским правом, должна быть включена в произведение, чтобы составлять производное произведение. Верования Столлмана часто имеют очень мало основ в действительном реальном праве.
vartec
1
@thepaul: с одной стороны, у вас есть юридическая практика, используемая компанией на 9 миллиардов долларов, с другой стороны, парень, который любит носить шляпу из фольги. Вы утверждаете, что последнее более надежно, и вы полностью вправе верить в это.
vartec
1
Вы цитируете не ту часть GPL FAQ, это очень ясно . Часть, о которой вы цитируете, о том, что если переводчик языка программирования выпущен под лицензией GPL, означает ли это, что программы, написанные для интерпретации, должны быть под лицензией, совместимой с GPL? ! Следовательно, к [GPL-лицензированному] интерпретатору . Соответствующая часть - это последние 2 абзаца: [...] Еще один похожий и очень распространенный случай - предоставить библиотекам интерпретатор, который сам интерпретируется. Например, Perl поставляется со многими модулями Perl [...]
Крис Весселинг
1
«Интерпретируемая программа для переводчика - это просто данные; лицензия на свободное программное обеспечение, например GPL, основанная на законе об авторском праве, не может ограничивать данные, на которых вы используете переводчика. Вы можете запускать его с любыми данными (интерпретируемой программой) любым удобным для вас способом, и нет никаких требований в отношении лицензирования этих данных кому-либо ». Речь идет о запуске программ в любой лицензии, даже если права интерпретатора GPL существуют? Который не охватывает тему использования плагина non-libre в программе GPL на интерпретируемом языке.
Tuxayo
4

Примечание: это юридический вопрос. Programmers.SE - это не юридический форум, а форум по программированию. Хотя люди здесь знают немного о программировании, они ничего не знают о законе. Если вы хотите задать юридический вопрос, вы должны задать его на юридическом форуме, где есть люди, которые действительно что-то знают о предмете.


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

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

В своем вопросе вы говорите о «устных языках». Но этот термин не имеет смысла: не существует такой вещи, как интерпретируемый язык. Язык - это абстрактный набор математических правил и ограничений. Язык не интерпретируется и не компилируется. Язык просто есть . Термин «интерпретируемый язык» не просто неверен , он бессмысленен . Если бы английский был типизированным языком, это была бы ошибка типа.

Интерпретация и компиляция - это черты интерпретатора или компилятора (дух!), А не языка. Каждый язык может быть реализован с помощью интерпретатора, и каждый язык может быть реализован с помощью компилятора. У большинства языков есть оба. Большинство современных языковых реализаций даже объединяют оба в одном механизме исполнения.

Например, реализация Rubinius Ruby содержит статический заблаговременный компилятор, который компилирует код Ruby в байт-код Rubinius, интерпретатор, который интерпретирует байт-код Rubinius, и динамический компилятор Just-in-Time, который компилирует байт-код Rubinius в LLVM. IR, который, в свою очередь, инфраструктура LLVM компилируется в машинный код. Реализация MacRuby Ruby вообще не содержит интерпретатора, она компилирует код Ruby прямо в LLVM IR, а затем в машинный код.

С другой стороны, есть интерпретаторы для C или C ++.

Все это только технические детали. Это совершенно не имеет отношения к авторскому праву.

Просто не имеет смысла, если кто-то нарушает чужие авторские права или нет, зависит от того, решит ли какой-либо третий человек запустить программу с интерпретатором или сначала скомпилировать ее.

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

Йорг Миттаг
источник
Что насчет интерпретируемых языков с промежуточным кодом? Один из принципов, лежащих в основе GPL, заключается в том, что любой должен иметь возможность адаптировать программу к любой разумной машине, которая имеет те же языковые инструменты, что и оригинал. Если кто-то выпустит исходный код для интерпретатора промежуточного кода, вместе с набором кода промежуточной формы, который он может запустить, каковы будут правила выдачи информации, связанной с этим BLOB-кодом промежуточного кода? В отличие от скомпилированных исполняемых файлов, которые являются машинно-зависимыми, блок промежуточного кода будет полностью переносимым.
суперкат
Сожалею; Я собирался спросить на stackoverflow.com, и он предложил вместо этого спросить здесь, когда я использовал тег "gpl"! Такого рода обсуждение здесь тоже запрещено? exec ("адвокат killall -9"); : D
еколис
И да, я согласен, что нет никакого смысла в том, что детали реализации не должны влиять на правовой статус повторного использования; Я просто подумал, что такое различие и просил разъяснений!
Эколис
2
@ekolis: это не запрещено, как таковое. Это просто , что это не идея хорошо задавать юридические вопросы людей , которые ничего о юридических вопросах не знают (как программисты, например), когда есть люди , которые действительно знают о юридических вопросах (аки адвокатов) вы могли бы спросить вместо этого. Я ничего не имею против адвокатов, как раз наоборот. Но я бы не стал просить советника по алгоритму и не попросил бы у программиста юридической консультации.
Йорг Миттаг
ЯНАЛ: Это может быть техническая деталь, но она все же имеет большое значение, потому что она меняет то, что распространяется юридически значимым образом. Со статической связью вы создаете комбинированную работу, которая, согласно правилам GPL, не может распространяться за пределами GPL. С динамическим связыванием вы также можете делать это, например, если вы упаковываете библиотеки с вашим программным обеспечением в ZIP-файл. Но с динамическим связыванием вы можете распространять его без библиотек, и это на 100% ваша работа, даже если она не работает сама по себе. И вы все еще можете, конечно, предлагать библиотеки под лицензией GPL.
flarn2006
0

Понятия не имею, сколько в этом правды, IANAL и т. Д .; но в моей интерпретации важно, является ли библиотека, с которой вы ссылаетесь, в той или иной форме включенной в «двоичный» (где «двоичный», в случае динамических языков программирования, представляет собой просто распределенный исходный код; это что я делаю из определения ФСФ «двоичный» в этом контексте).

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

tdammers
источник