lgpl-java.html - en to ru translation catalogue (17 entries)

en: The LGPL and Java
ru: LGPL и Java

en: by <a href="mailto:licensing@fsf.org">David Turner</a>
ru: <a href="mailto:licensing@fsf.org">Дэвид Тернер</a>

en: This article was written in November 2004, when <a href="/licenses/old-licenses/lgpl-2.1.html">LGPLv2.1</a> was the most current version of the license.  Since then, <a href="/licenses/lgpl-3.0.html">LGPLv3</a> has been published.  The main points of this article remain true about LGPLv3, but some of the details, such as section numbers, have changed.
ru: Эта статья написана в ноябре 2004&nbsp;года, когда <a href="/licenses/old-licenses/lgpl-2.1.html">LGPLv2.1</a> была самой новой версией лицензии. С тех пор была опубликована <a href="/licenses/lgpl-3.0.html">LGPLv3</a>. Основные тезисы статьи остаются верны и для LGPLv3, но некоторые детали, такие, как номера разделов, изменились.

en: It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code.  The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as &ldquo;hereditary.&rdquo; So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL.  By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications.
ru: ФСПО всегда утверждал, что результатом динамического подключения библиотек к приложениям является единое произведение, производное как от текстов библиотеки, так и от текстов приложения. GPL требует, чтобы все производные произведения были лицензированы по GPL&nbsp;&mdash; эффект, которые может быть описан как &ldquo;наследственность&rdquo;. Итак, если приложение подключает библиотеку, лицензированную по GPL, приложение тоже должно быть лицензировано по GPL. Библиотеки, лицензированные по Меньшей стандартной общественной лицензии GNU (LGPL), в отличие от этого, могут подключаться к несвободным приложениям.

en: In July of 2003, Slashdot published a story claiming that I had claimed that the LGPL did not function as intended in the case of Java.  This story was based on a misunderstanding of a response to a question sent to licensing@gnu.org, and many attempts to clarify the issue in the Slashdot story did not get across.  I have recieved numerous questions about the story since, via both licensing@gnu.org and personal email.
ru: В июле 2003&nbsp;года на Slashdot был опубликован рассказ, в котором утверждается, будто я утверждал, что LGPL функционирует не так, как было задумано, в случае с языком Java. Этот рассказ основан на неверно понятом ответе на вопрос, посланный на licensing@gnu.org, и многочисленные попытки разъяснить ошибку в рассказе со Slashdot не достигли своей цели. С тех пор я получил множество вопросов об этом рассказе, как через licensing@gnu.org, так и по личному адресу электронной почты.

en: FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java.  Applications which link to LGPL libraries need not be released under the LGPL.  Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
ru: Позиция ФСПО все это время оставалась неизменной: LGPL работает, как задумано, со всеми известными языками программирования, включая Java. Приложения, которые подключают библиотеки LGPL, не обязательно выпускать по LGPL. Приложения должны только следовать разделу&nbsp;6 LGPL: допускать подключение новых версий библиотеки к приложению и разрешать проведение обратной разработки, чтобы отлаживать это.

en: The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file.  Applications use Java's &ldquo;import&rdquo; functionality to access classes from these libraries.  When the application is compiled, function signatures are checked against the library, creating a link.  The application is then generally a derivative work of the library.  So, the copyright holder for the library must authorize distribution of the work.  The LGPL permits this distribution.
ru: Типичная для языка Java организация предполагает, что каждая библиотека, которой пользуется приложение, распространяется в виде отдельного файла JAR (архива Java). Приложения пользуются средством &ldquo;импорта&rdquo; языка Java для доступа к классам в этих библиотеках. Когда приложение компилируется, сигнатуры функций сопоставляются с функциями библиотеки и создается связь. Следовательно, приложение, вообще говоря, является производным от библиотеки произведением. Итак, правообладатель библиотеки должен санкционировать распространение произведения. LGPL дает разрешение на это распространение.

en: If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL.  Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications.  This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application.  You don't need to worry about that&mdash;people who modify the library are responsible for making it work.
ru: Если вы распространяете приложение на языке Java, которое подключает библиотеки под LGPL, соблюсти требования LGPL нетрудно. Лицензия вашего приложения должна позволять пользователям изменять библиотеку и проводить обратную разработку вашей программы для отладки этих изменений. Это не значит, что вы должны предоставлять исходный текст или какие бы то ни было сведения о внутреннем устройстве вашего приложения. Конечно, какие-то изменения, которые пользователи могут внести в библиотеку, могут нарушить порядок обмена, сделав работу библиотеки с вашим приложением невозможной. Вас это не должно беспокоить&nbsp;&mdash; те, кто вносят изменение в библиотеку, отвечают за то, будет ли она работать.

en: When you distribute the library with your application (or on its own), you need to include source code for the library.  But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.
ru: Когда вы распространяете библиотеку со своим приложением (или саму по себе), вам нужно предоставить исходный текст этой библиотеки. Но если ваше приложение требует вместо этого, чтобы пользователи получили библиотеку сами, то вам не обязательно предоставлять исходный текст этой библиотеки.

en: The only difference between Java and C from the LGPL's perspective is that Java is an object-oriented language, supporting inheritance.  The LGPL contains no special provisions for inheritance, because none are needed.  Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.
ru: Единственное различие между языками Java и Си с точки зрения LGPL состоит в том, что Java&nbsp;&mdash; объектно-ориентированный язык и поддерживает наследование. В LGPL нет особых указаний о наследовании, потому что они не нужны. Наследование приводит к созданию производных произведений точно таким же образом, как традиционная компоновка программ, и LGPL допускает производные произведения этого типа точно так же, как она допускает обычные вызовы функций.

en: Please send FSF &amp; GNU inquiries to <a href="mailto:gnu@gnu.org"><em>gnu@gnu.org</em></a>.  There are also <a href="/contact/">other ways to contact</a> the FSF.  <br /> Please send broken links and other corrections or suggestions to <a href="mailto:webmasters@gnu.org"><em>webmasters@gnu.org</em></a>.
ru: Пожалуйста, присылайте запросы фонду и GNU по адресу <a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Есть также <a href="/contact/">другие способы связаться</a> с фондом. <br /> Пожалуйста, присылайте отчеты о неработающих ссылках и другие поправки или предложения по адресу <a href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.

en: Please see the <a href="/server/standards/README.translations.html">Translations README</a> for information on coordinating and submitting translations of this article.
ru: Сведения по координации и предложениям переводов этой статьи см. в <a href="/server/standards/README.translations.html">&ldquo;Руководстве по переводам&rdquo;</a>.

en: Copyright &copy; 2004 Free Software Foundation, Inc.,
ru: Copyright &copy; 2004, 2011 Free Software Foundation, Inc.

en: Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice, and the copyright notice, are preserved.
ru: Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice, and the copyright notice, are preserved. <br /> (Буквальное копирование и распространение всей этой статьи разрешено по всему миру безвозмездно на любом носителе при условии, что это примечание и примечание об авторских правах сохраняются)

note: TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.
en: *GNUN-SLOT: TRANSLATOR'S CREDITS*
ru: <em>Внимание! В подготовке этого перевода участвовал только один человек. Вы можете существенно улучшить перевод, если проверите его и расскажете о найденных ошибках в <a href="http://savannah.gnu.org/projects/www-ru">русской группе переводов gnu.org</a>.</em>

note: timestamp start
en: Updated:
ru: Обновлено:

en: Translations of this page
ru: Переводы этой страницы
