アカウント名:
パスワード:
これが全てでしょう
「金にならない」より、「GPLを使っていると高い金を出して作った成果物が法的にパーになる可能性がある」のほうが適切ではないかな。MIT/BSD/Apache系ライセンスの場合にはこういうことは起こらない。
「GPLを使っている」って、どういう意味よ?開発したソフトウェアをGPLで公開するって意味? GPLで公開されたソフトウェアのソースコードを自身のソフトウェアに取り入れるっていう意味?
後者なら言葉足らずで「そういう懸念があるためGPLで公開されたソフトウェアが取り入れられなくなってきている。それ故、人気が出にくい、GPLライセンスのソフトウェアの開発が減ってきている」とまで言わないと採用率減少の理由にはなっていない。けれど、そこまで言い切るには根拠が薄い。ライブラリのように他ソフトウェアに取り入れられること前提のものならともかく、そうでないソフトウェアにおいて、GPLを使っていることで「高い金を出して作った成果物が法的にパーになる」のがどういう場合で、それを理由にGPLライセンスのソフトウェアを避けなければならない場合がどれくらいあって、果たしてそれが、どれだけ開発元にGPL採用を躊躇わせる要因になるのかが全然見えてこない。
前者ならどうしてそんな話になるのか。開発元はそれをGPL以外で配布する権利を持っているし、自分で作ったものは非GPLソフトウェアに流用しても構わない。それにMIT/BSD/Apache系ライセンスで配布しても、一旦配布したのが自分の手を離れてライセンスの範囲内で自由に利用されることは避けられない。だったら、それらの中である意味一番制限が大きいGPLで配布するのが、一番、成果物を法的にパーにしにくいとも言える。
仕事でGPLライセンスのライブラリを使うかどうか検討したことがあるけど、一番の問題は、どうすればライセンスに抵触しないのか、どうやった場合に法的なリスクがあるのか問い合わせる先が無いこと。外部のコンサル入れて金かけて調べさせる手もあるけど、100%正確とは言えないし困った。結局そういう問題から、多少金出しても市販のライブラリの方が扱いやすいから採用は見送った。
GPLのライセンス形態がどうのというよりも、あの長々とした条文が故に誰も保証できないってのが最大の問題。簡潔なライセンスであれば法務部が答えを出せる。
GPLのライブラリなら、基本的には、リンクさせたらGPLにしないといけないって回答が一般的だと思われるけど。確かにライセンスが長く複雑なため、しっかり理解した上で利用するのが難しいってのはあるかもしれんね。
例外条項つきのGPLに従うとか、自身がGPLに例外条項をつけて配布するってのも高度な知識が要りそう。そういう意味で、シンプルなライセンスに流れてるというのなら、ありうるかもしれません。
> 仕事でGPLライセンスのライブラリを使うかどうか検討したことがあるけど、> 一番の問題は、どうすればライセンスに抵触しないのか、どうやった場合に法的なリスクがあるのか問い合わせる先が無いこと。
MIT/BSD/Apache系ライセンスの場合だと何処に問い合わせたの?w何処に問い合わせても「自己責任」って返って来るとは思うんだけど、後学のため教えて下さい。
だから、少々金を出しても市販ライブラリを使ったって言って居るのじゃないのかな?
簡潔なライセンスであれば法務部が答えを出せる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
金にならない (スコア:0)
これが全てでしょう
Re: (スコア:1)
「金にならない」より、「GPLを使っていると高い金を出して作った成果物が法的にパーになる可能性がある」のほうが適切ではないかな。
MIT/BSD/Apache系ライセンスの場合にはこういうことは起こらない。
Re:金にならない (スコア:0)
「GPLを使っている」って、どういう意味よ?
開発したソフトウェアをGPLで公開するって意味? GPLで公開されたソフトウェアのソースコードを自身のソフトウェアに取り入れるっていう意味?
後者なら言葉足らずで「そういう懸念があるためGPLで公開されたソフトウェアが取り入れられなくなってきている。それ故、人気が出にくい、GPLライセンスのソフトウェアの開発が減ってきている」とまで言わないと採用率減少の理由にはなっていない。
けれど、そこまで言い切るには根拠が薄い。ライブラリのように他ソフトウェアに取り入れられること前提のものならともかく、そうでないソフトウェアにおいて、GPLを使っていることで「高い金を出して作った成果物が法的にパーになる」のがどういう場合で、それを理由にGPLライセンスのソフトウェアを避けなければならない場合がどれくらいあって、果たしてそれが、どれだけ開発元にGPL採用を躊躇わせる要因になるのかが全然見えてこない。
前者ならどうしてそんな話になるのか。開発元はそれをGPL以外で配布する権利を持っているし、自分で作ったものは非GPLソフトウェアに流用しても構わない。
それにMIT/BSD/Apache系ライセンスで配布しても、一旦配布したのが自分の手を離れてライセンスの範囲内で自由に利用されることは避けられない。だったら、それらの中である意味一番制限が大きいGPLで配布するのが、一番、成果物を法的にパーにしにくいとも言える。
1を聞いて0を知れ!
Re:金にならない (スコア:3, 興味深い)
仕事でGPLライセンスのライブラリを使うかどうか検討したことがあるけど、
一番の問題は、どうすればライセンスに抵触しないのか、どうやった場合に法的なリスクがあるのか問い合わせる先が無いこと。
外部のコンサル入れて金かけて調べさせる手もあるけど、100%正確とは言えないし困った。
結局そういう問題から、多少金出しても市販のライブラリの方が扱いやすいから採用は見送った。
GPLのライセンス形態がどうのというよりも、あの長々とした条文が故に誰も保証できないってのが最大の問題。
簡潔なライセンスであれば法務部が答えを出せる。
Re:金にならない (スコア:1)
GPLのライブラリなら、基本的には、リンクさせたらGPLにしないといけないって回答が一般的だと思われるけど。
確かにライセンスが長く複雑なため、しっかり理解した上で利用するのが難しいってのはあるかもしれんね。
例外条項つきのGPLに従うとか、自身がGPLに例外条項をつけて配布するってのも高度な知識が要りそう。
そういう意味で、シンプルなライセンスに流れてるというのなら、ありうるかもしれません。
1を聞いて0を知れ!
Re: (スコア:0)
> 仕事でGPLライセンスのライブラリを使うかどうか検討したことがあるけど、
> 一番の問題は、どうすればライセンスに抵触しないのか、どうやった場合に法的なリスクがあるのか問い合わせる先が無いこと。
MIT/BSD/Apache系ライセンスの場合だと何処に問い合わせたの?w
何処に問い合わせても「自己責任」って返って来るとは思うんだけど、後学のため教えて下さい。
Re: (スコア:0)
だから、少々金を出しても市販ライブラリを使ったって言って居るのじゃないのかな?
Re: (スコア:0)
簡潔なライセンスであれば法務部が答えを出せる。