【最大10000ポイント】当たる!!質問投稿キャンペーン!

GPLライセンスについて調べています。
考え方がまちがっていたらご指摘いただきたいです。

1.GPLライセンスのライブラリを用いたシステム開発を行った場合
  ソースの開示を求められたら、開示しなければいけない?

たとえば、Javaで開発したシステムの場合、ここでいうソースコードとはjavaファイル郡になるのでしょうか?
jarファイルとかwarファイルだけでは駄目 ということですよね?

2.GPLライセンスのライブラリを用いたソフトを作って売る場合も
  同様で、ソースの開示を求められたら、開示しなければいけない?

つまりは、Javaで開発したソフトをパッケージ販売したいなら、
ソースコードをお客に開示するつもりでいなければならない ということでいいですか?

また、ソースコードを開示する先 は、お客だけでいいのでしょうか?
まったく関係のない人から開示を求められた場合も、ソースコードを渡さなきゃいけないのでしょうか?

以上です。
よろしくおねがいします。

このQ&Aに関連する最新のQ&A

A 回答 (4件)

僕もあまり詳しくはないですが、


GPLで配布について求められていることは、
バイナリを直接配布する場合、そのバイナリを入手するのと
同じ手順でソースコードも入手できるようにすることだったと思います。

つまり、サイト経由でバイナリを配布するならば同じページでソースコードを配布しないとだめだし、CDで配るのなら、同じCDの同じディレクトリに同梱しないといけません。

ちなみに、GPLには、LGPLというライブラリ用の劣化したGPLがあります。
この場合、動的リンクをする場合にはGPL汚染はしなかったと思います。
利用しようとしているライブラリのライセンスを確認して、実際に利用している人に聞いてみるのがよいかと。。

参考URL:http://www.opensource.jp/lesser/lgpl.ja.html
    • good
    • 0

もう一度GPLを読み直してきました。


私自身、理解が足りていなかったようです。

http://www.opensource.jp/gpl/gpl.ja.html.euc-jp
GPL v2の『複製、頒布、改変に関する条件と制約』3は、要するに「バイナリと一緒にソースを渡すのでなければ、第三者にもソースを渡さなくてはならない」ということのようです。
パッケージにソースも同梱するのであれば顧客にのみ開示で良いですが、要求に応じて開示(要求がなければ開示しない)の場合には誰の要求でも開示する必要があるわけですね。

http://sourceforge.jp/magazine/07/09/02/130237
GPL v3の『6. ソース以外の形式における伝達』ではもう少し複雑ですが、販売する場合でソースを渡す相手を顧客に限定したければ、パッケージにソースを同梱するしかないように読めます。
    • good
    • 1

『バイナリを受け取った人がソースを受け取ることもできる』がGPLの要求です。


というわけで、
1.開示する必要があります。もちろんjarでは×
2.顧客のみで良いです

なお、再配布が可能なので、購入者がコピーを売ったり無料配布しても、文句を言えません。
LGPLなら話は全然違ってきます
    • good
    • 0
この回答へのお礼

ありがとうございました。

開示の対象については、顧客のみでいいのですね。
GPLライセンスのライブラリを取り扱っている会社に問い合わせたところ
「GPLであれば、顧客に限らず任意の人から要求に従って公開する必要があります。」

という回答をもらったので・・・混乱しています。

お礼日時:2009/04/16 13:25

こんばんわ。



興味深かったのと、ちょっと前になにかのIT系のニュースでGPLはデメリットばかりしかない...ような旨のメールマガジンを読んだ記憶があったので、ちょっと調べてみました。

http://www.ibm.com/developerworks/jp/opensource/ …
直接その時の記事はみつからなかったのですが、IBMサイトでの説明からすると、GPLライセンスのソフトウェアを使用した場合、公開するのは基本的に提供先である顧客のみで良いようです。
私もてっきり、GPLを使った場合、GPLライセンスのソフトウェアユーザ全てに公開しなければならないのだと思っていましたが、どうやらそうではないようです。
    • good
    • 1
この回答へのお礼

ありがとうございました。
参考URLについても確認してみます。

開示の対象については、顧客のみでいいのですね。
GPLライセンスのライブラリを取り扱っている会社に問い合わせたところ
「GPLであれば、顧客に限らず任意の人から要求に従って公開する必要があります。」

という回答をもらったので・・・混乱しています。

お礼日時:2009/04/16 13:25

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QGPLv2のコピーレフト(改変したプログラムを頒布する行為)は、マスト事項ではなない?

GPLについてお尋ねしたいことがあります。

GPLとは、改変したプログラムを頒布する行為を奨励することによってプログラムの発展を促すために作成されたもの、という認識を持っています。

しかしながら、GPLv2の日本語訳(http://www.opensource.jp/gpl/gpl.ja.html.euc-jp)を見ると、

*********************
2. あなたは自分の『プログラム』の複製物かその一部を改変して『プログラム』 を基にした著作物を形成し、そのような改変点や著作物を上記第1節の定める条件の下で複製または頒布することが【できる】。ただし、そのためには以下の条 件すべてを満たしていなければならない:
(※隅つきカッコは、強調のために当方にて挿入されたものです)
*********************
と書かれています。つまり、「頒布しなくてはならない」とあればラインセシーは必ず改変したプログラムを頒布しなければならないと思うものの、「頒布することができる」と記載されているために、ラインセンシーは絶対に改変したプログラムを頒布(公開)しなくても良いと解釈できるのです。

 換言すれば、当方は、頒布することはライセンシーのマスト事項ではないと当条項に記載されているように解釈してしまうのです。

 となると、GPL準拠のOSSを利用している企業は、自身のWebサイトに改変したプログラムを載せなくても良いとも考えられます。

 つきましては、下記の二点の質問に答えていただければと思います。

1)改変したプログラムを頒布することは、GPLのラインセンシーにとって「しなければいけない」ことなのか、「しなくてもいい」ことなのか、どちらであるかを教えて頂けないでしょうか?

2)さらに、1)において、改変したプログラムを頒布することはGPLのラインセンシーにとって「しなければいけない」ことである場合、その根拠は、GPL内のどこに記載されているのでしょうか?

以上2点、宜しくお願い致します。

GPLについてお尋ねしたいことがあります。

GPLとは、改変したプログラムを頒布する行為を奨励することによってプログラムの発展を促すために作成されたもの、という認識を持っています。

しかしながら、GPLv2の日本語訳(http://www.opensource.jp/gpl/gpl.ja.html.euc-jp)を見ると、

*********************
2. あなたは自分の『プログラム』の複製物かその一部を改変して『プログラム』 を基にした著作物を形成し、そのような改変点や著作物を上記第1節の定める条件の下で複製また...続きを読む

Aベストアンサー

あなたは、GPLの下で受け取ったプログラムを「以下の条件すべてを満たすならば、頒布することができる」です。
改変したプログラムを頒布せずに、自分だけで使い続けることは可能です。
自分が会社であれば、自社から出さない限りは、改変したものを頒布する必要はありません。
頒布するのであれば、条件を満たすことはあなたのいうところの「マスト事項」です。

GPLは、頒布する行為を奨励することが目的ではなく、
プログラムが受け取った者が、そのプログラムを改変して利用できることを保証するためのものです。

元の質問に戻れば、1)は「しなくてもいい」、2)は前提が成立しないので答えられない、ですね。

Qapt-get install ****** でinstallしたものをuninstallするには?

御世話になります。
vncserverだけをinstallするつもりが
誤って
apt-get install vncとうってしまいました。
これをuninstallしたいのですが
どのようにすればよろしいでしょうか?

教えて下さい。

Aベストアンサー

# apt-get remove パッケージ名
では、設定ファイルは削除されずに残ります。

完全に削除するときは、
# apt-get --purge remove パッケージ名
です。

QApache License Version 2.0ライセンスについて、私の認識が間違っていないか確認させてください。

Apache License Version 2.0について、私の認識が間違っていないかを、確認させてください。(Apache License Version 2.0原文を見てみた(読む以前の問題)のですが、私の英語読解力ではそこに書かれている意味を正しく理解する自信がなかったので、Webの日本語サイト等で調べたうえでの認識です・・。)

1, 原著作者とは、Apache財団のことをいうのか。
2, 謝辞を表示とは、Apache Softwareを使用したプログラム内で、謝辞を表示しなければならないということなのか。また、謝辞とは、具体的にどういったものなのか。

3, 最後に、率直に質問しますが、Apache Softwareをモジュールとして使用して記述されたプログラムを、ソースコード非公開かつ有償の製品として営利目的で販売することは、ライセンス上合法ですよね?

Aベストアンサー

こんにちは。とりあえずわかる範囲で。
>1, 原著作者とは、Apache財団のことをいうのか。
違います(違う場合もある)。
Apacheライセンスの元で配布しているソフトウェア(ライブラリ)を
作成した自然人もしくは法人です。
もちろん対象のソフトウェアがApacheだったりすればその原著作者は
Apache Software Foundationになります。

>2, 謝辞を表示とは、Apache Softwareを使用したプログラム内で、謝辞を表示しなければならないということなのか。また、謝辞とは、具体的にどういったものなのか。

これはライセンスに明記されていると思いますが。

licenses/Apache_License_2.0 - Open Source Group Japan Wiki @ SF.jp
http://sourceforge.jp/projects/opensource/wiki/licenses%2FApache_License_2.0

にある参考日本語訳だとこの辺ですね。

成果物の一部として「NOTICE」に相当するテキストファイルが含まれている場合は、そうしたNOTICEファイルに含まれている帰属告知のコピーを、派生成果物のどこにも関係しないものは除いて、頒布する派生成果物に入れること。その際、次のうちの少なくとも1箇所に挿入すること。(i) 派生成果物の一部として頒布するNOTICEテキストファイル、(ii) ソース形式またはドキュメント(派生成果物と共にドキュメントを頒布する場合)、(iii) 派生成果物によって生成される表示(こうした第三者告知を盛り込むことが標準的なやり方になっている場合)。NOTICEファイルの内容はあくまで情報伝達用であって、本ライセンスを修正するものであってはなりません。あなたは頒布する派生成果物に自分の帰属告知を(成果物からのNOTICEテキストに並べて、またはその付録として)追加できますが、これはそうした追加の帰属告知が本ライセンスの修正と解釈されるおそれがない場合に限られます。

通常この手のライセンスで求められる「謝辞」というと、『誰それが作成したところの
××というライブラリを使用した』という感じの、ベースとなったものの
元の作者がわかるように記述されているものをさすことが多いと思います。

べつにありがとうとか感謝しているとかいう表現は不要です。
というか、「謝辞」という表現を使った訳ってどこにあったのでしょうか?

>3, 最後に、率直に質問しますが、Apache Softwareをモジュールとして使用して記述されたプログラムを、ソースコード非公開かつ有償の製品として営利目的で販売することは、ライセンス上合法ですよね?

ちょっと具体的なことをおたずねしますが、『Apache Softwareをモジュールとして使用』
とはどのような状態を指しているのでしょうか?

たとえば一群のライブラリ関数を集めたDLL(共有ライブラリ)がApace ライセンスを使用するものであって、
質問者さんのアプリはそれを呼び出して使うだけということであれば
まったく問題はありません。
また、データベースサーバのようなものであっても、定められたプロトコルにしたがって
呼び出しているようなものが質問者さんのアプリであるならこれも問題はありません。

>本ライセンスでは、成果物や派生成果物から分離できる製作物や、成果物や派生成果物の
>インタフェースへの単なるリンク(または名前によるバインド)を、派生成果物に含めません。

この辺が該当します。
この場合、質問者さんが自分の作成された部分はまったく好きに扱えます。
ただし、DLLなどそのものはあくまでApacheライセンスに縛られますので
注意してください。

しかし、たとえば、Apache(httpサーバ)のソースコードを改変したものを
まったく自由にできるかというとこれはちょっと疑問があります。

こんにちは。とりあえずわかる範囲で。
>1, 原著作者とは、Apache財団のことをいうのか。
違います(違う場合もある)。
Apacheライセンスの元で配布しているソフトウェア(ライブラリ)を
作成した自然人もしくは法人です。
もちろん対象のソフトウェアがApacheだったりすればその原著作者は
Apache Software Foundationになります。

>2, 謝辞を表示とは、Apache Softwareを使用したプログラム内で、謝辞を表示しなければならないということなのか。また、謝辞とは、具体的にどういったものなのか。

こ...続きを読む

QMPL2.0ライセンスのライブラリを使った開発

MPL2.0ライセンスをうたったライブラリを使って開発し、製品として出荷したい考えています。

http://www.mozilla.org/MPL/2.0/FAQ.html
のQ11をみると、
MPL2.0ライセンスをうたっている該当のライブラリを変更せずに使うのであれば
製品のソースコードは開示しなくてもよいと読み取れるのですが
この解釈で正しいのでしょうか。

教えて頂けると大変助かります。

Aベストアンサー

いえーすざっつらいと。

MPL2.0のライセンスで公開されているライブラリ(より正確に言えばMPL2.0のライセンスで公開されているのはライブラリではなくてソースコード)をリンクして実行するプログラムにはソースコード公開義務はない。
それはQ12にまとめられている
MPL: The copyleft applies to any files containing MPLed code.
LGPL: The copyleft applies to any library based on LGPLed code.
GPL: The copyleft applies to all software based on GPLed code.
の方が理解しやすいかも知れない。

つまり、MPLなライブラリを使用して開発するにあたり、そのライブラリの一部を改変して再コンパイルした場合はその修正されたソースコードファイルについてはソースコードを公開し、かつそのソースコードはMPLでライセンスされる必要があるが、それの中に書かれてあるルーチンを呼び出すプログラムが書かれたファイルは何もしなくてOKだ。
・library.c ←MPL2.0
・mysource.c ←あなたが作った
の2ファイルを1つのEXEにして配布する場合でもmysource.cは公開義務はない。library.cを改変したとしても、公開義務があるのは改変されたlibrary.cのみであり、mysource.cには影響しない。

いえーすざっつらいと。

MPL2.0のライセンスで公開されているライブラリ(より正確に言えばMPL2.0のライセンスで公開されているのはライブラリではなくてソースコード)をリンクして実行するプログラムにはソースコード公開義務はない。
それはQ12にまとめられている
MPL: The copyleft applies to any files containing MPLed code.
LGPL: The copyleft applies to any library based on LGPLed code.
GPL: The copyleft applies to all software based on GPLed code.
の方が理解しやすいかも知れない。

つま...続きを読む

Qinterface,extend,implementのちがい

お世話になります、

Javaを勉強しているのですが、
interface,extend,implementの使い分けがわかりません。

私の解釈としては、
(1)interfaceは、グローバル変数の定義、グローバルメソッドの定義(実装はしない)。

(2)extendは、extendクラスを親クラスとして親クラスの機能を使用できる。

(3)implementは…,implementもextendと同じような意味だと解釈しているんですが、違う点は、implementで定義してあるメソッドは、使用しなくても、実装しなければならないという点でしょうか?

とにかくこの3つのを使い分けるコツとかあれば教えてください。
よろしくお願いします。

Aベストアンサー

バラバラに理解してもしょうがないッス。

まず、
(1)interface と implements
(2)class と extends

が対応しているわけっす。

JavaはC++と違って、比較的言語仕様を「簡単」にしたので「多重継承」という
概念がないです。
多重継承っていうのは、複数のクラスを親クラスにして継承するってことですね。

たとえば、 「TextFieldクラス」と「Japaneseクラス」を多重継承すると、
「JTextFieldクラス」ができるっていうのが自然な考え方でしょう?

まぁ、例えば、日本語クラスであれば、getStringLength()メソッドなどが
あったほうが良いでしょうか。
このgetStringLength()メソッドは、2バイト文字も1バイト文字も「1文字」
と数えてくれると言う点で、まさに、日本語クラス用のメソッドだと言えるでしょう。

例えば、Java的に記述すると、、、
class Japanese {
public int getStringLength() {
  ・・・
return strlength;
 }
 ・・・
}

class TextField {
・・・
}

class JTextField extends TextField, extends Japanese {
・・・・
}

C++ではそのように実装するでしょう。
しかし、Javaにはこのような高度な機能はありません。

そこで、生まれた苦肉の策が、「interfaceとimplements」です。

interface Japanese {
public int getStringLength(); // interfaceは実装を含まない!
                 // すなわち「実装の継承」ができるわけではない。
}

class TextField {
・・・
}

class JTextField extends TextField implements Japanese {
・・・・
public int getStringLength() {
  ・・・
return strlength; //implementsの実装を「各クラスで」実装してやる必要がある。
 }
}


結局のところ、Javaでは、複数のクラスを親クラスには持ち得ないため、継承できなかったクラスは「各クラスで実装してやる必要性」があるのです。


ではどのように使うのが効果的か?

なまえのままです。「代表的なインターフェイス」にたいしてinterfaceを使うのが良いと思います。

例えば、プレイヤー系であれば、ビデオ・コンポ・ウォークマン・などにかかわらず、
interface controlpanel {
public play();
public stop();
public next();
public back();
}
というような基本的インターフェイスを「持っているべき」です。

こうすることで、それぞれのクラス宣言の際に、これらの「インターフェイスを持っているべきであり、実装されるべきである」ということを「強く暗示」することができます。
class videoplayer extends player implements controlpanel {
public play() {・・・}
public stop() {・・・}
public next() {・・・}
public back() {・・・}
}

こうすることで、同様のクラスを作成するユーザーは、
「プレイヤー系は、4つ操作が出来るコントロールパネルをインターフェイスとして持つべきなのだな!?」という暗示を受け取り、自分のクラスでもそれを模倣するでしょう。

class mp3player extends player implements controlpanel {
public play() {・・・}
public stop() {・・・}
public next() {・・・}
public back() {・・・}
}

また、これらのクラスを使用するユーザーも、「implements controlpanel」という
表記を見て、「4つの基本操作は押さえられているのだな!」という基本中の基本動作を抑えることが出来ます。

まとめると、クラスに「こういう特徴もたしてください!」「こういう特徴持ってますよ!」という一種の暗示的警告や方向性を与えることができるわけですね。

バラバラに理解してもしょうがないッス。

まず、
(1)interface と implements
(2)class と extends

が対応しているわけっす。

JavaはC++と違って、比較的言語仕様を「簡単」にしたので「多重継承」という
概念がないです。
多重継承っていうのは、複数のクラスを親クラスにして継承するってことですね。

たとえば、 「TextFieldクラス」と「Japaneseクラス」を多重継承すると、
「JTextFieldクラス」ができるっていうのが自然な考え方でしょう?

まぁ、例えば、日本語クラスであれば...続きを読む

Qsedの置換文字に変数を使用したいのですが・・・

あるファイルの特定の文字を変換し、上書きをする処理を行いたいのですが、sedの置換文字に変数が渡せなくて困っています。

例:
X="a"
Y="b"
echo test.txt | sed 's/${X}/${Y/g}' >test.txt

sedでは置換文字に${X}といった変数を使用することはできないのでしょうか?

Aベストアンサー

' ・・・' で囲まれた中の$はそのままドルマークです。変数展開をするなら、'・・・'で囲んではいけません。

何も囲まないか、"・・・"で囲むかです。

QGPLによるソース公開の回避方法

GPLライセンスの下で頒布されているソフトウェアライブラリなどをリンクして作成したプログラムを頒布する再には、当該プログラムのソースコード入手経路を確保しなければならないことになっていますが、これを回避するための方法はありますか?

Aベストアンサー

別のプロセスに分離する。GPLをリンクしたプロセスだけは公開する必要あり。
この分離についても実のところはグレイゾーン。あと動的リンクもグレイゾーンとされている。判例は今のところありません。

QGPL版 の MySQL を使ったソフトウェアについて

こんばんは。


教えていただきたいことがあります。
最近、GPL という言葉に遭遇して悩んでいます。


フリーのデータベースとして、MySQL を使っていますが、
ライセンス上、GPL という扱いになっております。
GPL というのを少し調べてみますと、フリーソフトのライセンスの
1つである、ということがうたわれています。
あとは、オープンソースということで、二次著作物はソースコードも
公開しないといけない、ということもウィキペディアなどで書かれています。


さて、そこでご質問となりますが、
上記の場合、MySQL に接続して動くソフトウェアは、
GPL としてソースコードまで公開しなければいけないのでしょうか?
それとも、そもそも有償ライセンスが必要になってしまうのでしょうか?


色々なサイトを調べあさりましたが、
グレーゾーンのように思えて困っています。


宜しくお願いします。

Aベストアンサー

MySQLそのもののソース(の一部)をつかっていなくとも、
そのDB連携のときにどのように呼び出しているかで、
GPLに「汚染される」可能性があります。

#1であげたFAQにこういう部分があります。

---ここから---
これまで、MySQL クライアントライブラリは LGPL (Lesser General Public License) に基づいてライセンスされていましたが、現在は GPL (General Public License) でライセンスされています。この変更の理由は何ですか。

MySQL が目標とするのは、すべての自社ソフトウェアをフリーソフトウェア・オープンソースライセンスに基づいて提供することです。2001 年にクライアントライブラリのライセンスが LGPL から GPL に変更されたのは、MySQL 4.0 の開発にあたり、商用ライセンスを購入すべき独占使用ユーザと GPL ライセンスを使用すべきフリーソフトウェアユーザを、MySQL AB がより簡単に区別するためでした。それ以前は、GPL を誤使用し、自らのアプリケーションと MySQL サーバを緊密に組み合わせて頒布し、クライアントライブラリが無償で使用できるので GPL の適用が及ばないと主張するユーザが存在していました。

LGPL から GPL への変更により、ソースを非公開にして MySQL ソフトウェアを使用する事例を容易に区別できるようになり、MySQL がデュアルライセンスモデルを採用できるようになりました。MySQL はオープンソースの理想を支援する一方で、「対価」、つまり公平な交換という観念をも信じています。なお、クライアントライセンスのポリシー変更は、 MySQL を使用してオープンソースアプリケーションを構築する開発者に一切影響を及ぼしません。
---ここまで---

> さらに言うとLinux上で動く商用アプリでもすべてにソース開示をする必要が出てきてしまいます

システムコールを通じてのOS呼び出しは
例外で、GNU GPLの条文にも明記されています。
あまりに酷い拡大解釈は止めてください。

また、状況に関する情報が少なかったので
書きませんでしたが、
PHPのように例外規定がある場合もあります。

---ここから---
PHP 用の GPL ライセンス除外規定とは何ですか。

PHP と MySQL は互換性のない別々のオープンソースライセンスを導入しているので、PHP コミュニティでの MySQL の使用を奨励・促進するために特別な除外規定を設けています。これにより MySQL AB では、GPL でライセンスされた MySQL ソフトウェアと、PHP ライセンスのバージョン 3.0 でライセンスされたソフトウェアで作成される派生物の頒布を許可しています。この際、お客様には、PHP ライセンスのバージョン 3.0 に基づいてライセンスされたコードを除くすべてのコードにおいて、GNU General Public License の規定をすべての面で順守することが義務付けられます。
---ここまで---

MySQL AB :: MySQL のライセンスポリシー
http://www-jp.mysql.com/company/legal/licensing/index.html


---ここから---
オープンソースプロジェクトでの使用:

* GPL ライセンスに基づくオープンソースアプリケーションを開発・頒布する場合、お客様は MySQL を GPL ライセンスに基づいて無償で使用することができます。詳細 »
* GPL ライセンスではなく、OSI 承認ライセンスに基づくオープンソースアプリケーションを開発・頒布する場合は、GPL ライセンスと FLOSS 除外規定に基づいて、MySQL をご利用いただくことができます。詳細 »

営利目的の使用が発生する OEM、ISV、VAR での使用:

* GPL に基づいてソースコードをライセンシング・頒布することなく、MySQL を自社製品とともに頒布したいと考える OEM、ISV、VAR のお客様は、MySQL を柔軟な OEM 商用ライセンスでご利用いただくことができます。詳細 »

---ここまで---
ってあるんだから危ないことは明白でしょう。




#1の繰り返しになりますが、自分のソースの公開をしたくないのなら
遠ざけておくのが一番です。
#2の方の回答にあるような、PostgreSQLなら
このような心配をせずに使うことができます。

MySQLそのもののソース(の一部)をつかっていなくとも、
そのDB連携のときにどのように呼び出しているかで、
GPLに「汚染される」可能性があります。

#1であげたFAQにこういう部分があります。

---ここから---
これまで、MySQL クライアントライブラリは LGPL (Lesser General Public License) に基づいてライセンスされていましたが、現在は GPL (General Public License) でライセンスされています。この変更の理由は何ですか。

MySQL が目標とするのは、すべての自社ソフトウェアをフリーソフ...続きを読む

QJavaMailを使って有料アプリ公開してもOK?

初めてのアプリ公開で色々自身がなく、教えてください。

OracleのJavaMailライブラリを使ったアプリを作ったのですが、ライセンスを見ると3つも書いてあり、何をしなければいけないのか、これでどこまで出来るのかがよくわかりません。
・CDDL-1.0
・GPL-2.0
・BSD
具体的にはこのライブラリを利用して制作したソフトウェアを有料で販売しても良いのでしょうか。
jarのまま仕様しており、展開などは一切してません。
またクレジット表記などどう書いて良いのかもよくわかりませんので
ご教示いただけたらありがたいです。

Aベストアンサー

JavaMail API 1.4.7をダウンロードする際に表示されるライセンス(Oracle Binary Code License Agreement for Java EE Technologies)によると、展開して中身を書き換えていないのであれば、無料で使えると書いてあります。ただし、JavaMail APIの一部ファイルを削除して配布したり、JavaMail API単体で譲渡したりするのはアウトのようです。
「2. LICENSE TO USE. Subject to the terms and conditions of this Agreement including, but not limited to, the Java Technology Restrictions of the Supplemental License Terms, Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs.」

参考URL:http://download.oracle.com/otn-pub/java/licenses/OTN_JavaEE_Legacy_Binary-Code-License_30Jan2012.txt

JavaMail API 1.4.7をダウンロードする際に表示されるライセンス(Oracle Binary Code License Agreement for Java EE Technologies)によると、展開して中身を書き換えていないのであれば、無料で使えると書いてあります。ただし、JavaMail APIの一部ファイルを削除して配布したり、JavaMail API単体で譲渡したりするのはアウトのようです。
「2. LICENSE TO USE. Subject to the terms and conditions of this Agreement including, but not limited to, the Java Technology Restrictions of the Supplemental ...続きを読む

Qpingでポートの指定

pingでIPアドレスを指定して、通信できるかどうかというのは
よく使いますが、pingでポートを指定して応答するかどうかは調べられるのでしょうか?

よろしくお願いします

Aベストアンサー

pingを含むICMPというプロトコルは、OSIの7レイヤで言うところのL2(同一セグメント内通信)とL3(IPルーティングされた通信)の両方にまたがる、ちょっと珍しいプロトコルです。

IPアドレスは指定できますが、別サブネットに属するIPアドレスに到達できればL3通信、できなければゲートウェイと呼ばれる同一サブネットに属する中継装置からの回答を得るという点でL2(MAC通信ではなく、同一セグメント内通信という意味)通信です。

ポート番号はL4で使用されるアドレスですから、L4機能の疎通確認はping(を含むICMP)ではできません。

FTPの疎通確認であれば、クライアントからサーバに対するTCP/21通信(FTP-CMD)が可能であること(サーバからクライアントへのTCP/21からの応答を含む)+サーバからクライアントに対するTCP/20通信(FTP-DATA)が可能であること(クライアントからサーバへのTCP/21からの応答を含む)が必要でしょう。

監視ソフトによるものであれば、
・クライアントからサーバへのログイン(TCP/21)
・クライアントからサーバへのlsの結果(TCP/20)
で確認すればよいでしょう。

pingを含むICMPというプロトコルは、OSIの7レイヤで言うところのL2(同一セグメント内通信)とL3(IPルーティングされた通信)の両方にまたがる、ちょっと珍しいプロトコルです。

IPアドレスは指定できますが、別サブネットに属するIPアドレスに到達できればL3通信、できなければゲートウェイと呼ばれる同一サブネットに属する中継装置からの回答を得るという点でL2(MAC通信ではなく、同一セグメント内通信という意味)通信です。

ポート番号はL4で使用されるアドレスですから、L4機能の疎通確認はping(を含む...続きを読む


このQ&Aを見た人がよく見るQ&A

人気Q&Aランキング