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

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

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

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

Что касается конкретного вопроса, касающегося переведенных языков, то в 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 .

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

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

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

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

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

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

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

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

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

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

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

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