Это перевод страницы, написанной на английском языке.

LGPL и Java

Дэвид Тернер

Эта статья написана в ноябре 2004 года, когда LGPLv2.1 была самой новой версией лицензии. С тех пор была опубликована LGPLv3. Основные тезисы статьи остаются верны и для LGPLv3, но некоторые детали, например номера разделов, изменились.

ФСПО всегда утверждал, что в результате динамического подключения библиотек к приложениям получается единое произведение, производное как от текстов библиотеки, так и от текстов приложения. GPL требует, чтобы все производные произведения были лицензированы в целом на условиях GPL — эффект, который может быть описан как “наследственность”. Итак, если приложение подключает библиотеку, лицензированную по GPL, приложение тоже должно быть лицензировано по GPL. Библиотеки, лицензированные по Меньшей стандартной общественной лицензии GNU (LGPL), в отличие от этого, могут подключаться к несвободным приложениям.

В июле 2003 года на Slashdot был опубликован рассказ, в котором утверждается, будто я утверждал, что LGPL функционирует не так, как было задумано, в случае с языком Java. Этот рассказ основан на неверно понятом ответе на вопрос, посланный на licensing@gnu.org, и многочисленные попытки разъяснить ошибку в рассказе со Slashdot не достигли своей цели. С тех пор я получил множество вопросов об этом рассказе, как через licensing@gnu.org, так и по личному адресу электронной почты.

Позиция ФСПО все это время оставалась неизменной: LGPL работает, как задумано, со всеми известными языками программирования, включая Java. Приложения, которые подключают библиотеки под LGPL, не обязательно выпускать по LGPL. Приложения должны только следовать разделу 6 LGPL: допускать подключение новых версий библиотеки к приложению и разрешать проведение обратной разработки, чтобы отлаживать это.

Типичная для языка Java организация предполагает, что каждая библиотека, которой пользуется приложение, распространяется в виде отдельного файла JAR (архива Java). Приложения пользуются средством “импорта” языка Java для доступа к классам в этих библиотеках. Когда приложение компилируется, сигнатуры функций сопоставляются с функциями библиотеки и создается связь. Следовательно, приложение, вообще говоря, является производным от библиотеки произведением. Итак, правообладатель библиотеки должен санкционировать распространение произведения. LGPL дает разрешение на это распространение.

Если вы распространяете приложение на языке Java, которое подключает библиотеки под LGPL, соблюсти требования LGPL нетрудно. Лицензия вашего приложения должна позволять пользователям изменять библиотеку и проводить обратную разработку вашей программы для отладки этих изменений. Это не значит, что вы должны предоставлять исходный текст или какие бы то ни было сведения о внутреннем устройстве вашего приложения. Конечно, какие-то изменения, которые пользователи могут внести в библиотеку, могут нарушить порядок обмена, сделав работу библиотеки с вашим приложением невозможной. Вас это не должно беспокоить — те, кто вносят изменение в библиотеку, отвечают за то, будет ли она работать.

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

Единственное различие между языками Java и Си с точки зрения LGPL состоит в том, что Java — объектно-ориентированный язык и поддерживает наследование. В LGPL нет особых указаний о наследовании, потому что они не нужны. Наследование приводит к созданию производных произведений точно таким же образом, как традиционная компоновка программ, и LGPL допускает производные произведения этого типа точно так же, как она допускает обычные вызовы функций.