lgpl-java.html - en to ja translation catalogue (15 entries)

note: type: Content of: <title>
en: The LGPL and Java - GNU Project - Free Software Foundation
ja: LGPLとJava - GNUプロジェクト - フリーソフトウェアファウンデーション

note: type: Content of: <div><h2>
en: The LGPL and Java
ja: LGPLとJava

note: type: Content of: <div><address>
en: by <a href="mailto:licensing@fsf.org">David Turner</a>
ja: <a href="mailto:licensing@fsf.org">David Turner</a>著

note: type: Content of: <div><div><p>
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.
ja: この小論は、<a href="/licenses/old-licenses/lgpl-2.1.html">LGPLv2.1</a>が現行バージョンであった2004年11月に書かれました。それから<a href="/licenses/lgpl-3.0.html">LGPLv3</a>が発行されました。この小論の主要な点は、LGPLv3について正しいままですが、節の番号などは変わりました。

note: type: Content of: <div><p>
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 as a whole under the terms of 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.
ja: ライブラリへの動的リンクのアプリケーションは、ライブラリのコードとアプリケーションのコードの両方から派生した単一の作品を作る、というのが常にFSFの立場です。GPLはすべての派生作品に、全体としてGPLの条項でライセンスすることを要求します。「遺伝性」と述べられる効果です。ですから、あるアプリケーションがあるGPLでライセンスされたライブラリとリンクする場合、アプリケーションもGPLでライセンスされなければなりません。対照的に、GNU劣等一般公衆ライセンス(LGPL)でライセンスされたライブラリは、プロプライエタリなアプリケーションとリンクすることも可能です。

note: type: Content of: <div><p>
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 received numerous questions about the story since, via both licensing@gnu.org and personal email.
ja: 2003年7月、Slashdotは、わたしがLGPLはJavaのケースでは意図したように機能しないと主張したとする記事を公表しました。この記事は、licensing@gnu.orgに送られた質問への返答を誤解したものにもとづき、Slashdotの記事の問題をはっきり説明しようとする多くの試みは達成されませんでした。それ以来、この記事に関する多くの質問を、licensing@gnu.orgと個人的電子メールの両方で受けてきました。

note: type: Content of: <div><p>
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.
ja: FSFの立場は、一貫して不変のままです: LGPLは意図したとおりに、Javaを含めて、すべての知られているプログラミング言語で機能します。LGPLのライブラリとリンクするアプリケーションはLGPLでリリースされる必要はありません。アプリケーションはLGPLの第6節の要求事項に従うことだけが必要とされます。すなわち、新しいバージョンのライブラリがアプリケーションとリンクできるようにすること、および、アプリケーションをデバッグできるようにリパースエンジニアリングを認めることです。

note: type: Content of: <div><p>
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.
ja: Javaの典型的な配置は、アプリケーションが使用するそれぞれのライブラリを、別々のJAR(Javaアーカイブ)ファイルとして配布することです。アプリケーションはJavaの&ldquo;import&rdquo;機能を使って、これらのライブラリからクラスにアクセスします。アプリケーションがコンパイルされると、関数シグネチャがライブラリに対して確認され、リンクが作られます。この時、アプリケーションは一般にライブラリの派生作品となります。ですから、ライブラリの著作権者が、この作品の配布を認可する必要があります。LGPLはこの配布を認めます。

note: type: Content of: <div><p>
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.
ja: LGPLのライブラリをインポートするJavaアプリケーションを配布する場合、LGPLに従うのは簡単です。アプリケーションのライセンスは、ユーザにライブラリの改変を許し、これらの変更のデバッグのためにあなたのコードのリバース・エンジニアリングを許す必要があります。これは、ソースコードや、アプリケーションの内部の詳細について提供する必要を意味しません。もちろん、ユーザがライブラリに対して行い得る変更には、インタフェースを犯すものもあり得ますから、ライブラリをアプリケーションとともには動かなくしてしまうものもあるでしょう。これについては心配する必要はありません。ライブラリを変更する人々に、それを動くようにする責任があるのです。

note: type: Content of: <div><p>
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.
ja: ライブラリをアプリケーションとともに(あるいはそれだけで)配布する場合、ライブラリのソースコードを含める必要があります。しかし、アプリケーションがユーザ自身にライブラリを取得することを要求する場合、ライブラリのソースコードを提供する必要はありません。

note: type: Content of: <div><p>
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.
ja: LGPLの観点からのJavaとCの違いは、ただ一つ、Javaはオブジェクト指向言語で、継承をサポートすることです。LGPLは、特に必要ないので継承について特別な規程は何もありません。継承は伝統的なリンクと同じ方法で派生作品を作り、LGPLはこの種の派生作品を通常の関数呼び出しに認めるのと同じ方法で認めます。

note: type: Content of: <div><div><p>
en: Please send general FSF &amp; GNU inquiries to <a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>.  There are also <a href="/contact/">other ways to contact</a> the FSF.  Broken links and other corrections or suggestions can be sent to <a href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.
ja: FSFおよびGNUに関する問い合わせは<a href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>までお願いします(英語)。FSFへの連絡は<a href="/contact/">他の方法</a>もあります。リンク切れや他の修正、提案は<a href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>までお送りください。

note: TRANSLATORS: Ignore the original text in this paragraph, replace it with the translation of these two: We work hard and do our best to provide accurate, good quality translations.  However, we are not exempt from imperfection. Please send your comments and general suggestions in this regard to <a hr
en: Please see the <a href="/server/standards/README.translations.html">Translations README</a> for information on coordinating and contributing translations of this article.
ja: 正確で良い品質の翻訳を提供するよう努力していますが、不完全な場合もあるかと思います。翻訳に関するコメントと提案は、<a href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>におねがいします。</p><p>わたしたちのウェブページの翻訳の調整と貢献については、<a href="/server/standards/README.translations.html">翻訳 README</a>をご覧ください。

note: type: Content of: <div><p>
en: This page is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nd/4.0/">Creative Commons Attribution-NoDerivatives 4.0 International License</a>.
ja: このページは<a rel="license" href="http://creativecommons.org/licenses/by-nd/4.0/deed.ja">Creative Commons Attribution-NoDerivatives 4.0 International License</a>の条件で許諾されます。

note: timestamp start type: Content of: <div><p>
en: Updated:
ja: 最終更新:
