【License】ライセンス総合【利用許諾】
. / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ | ライセンスについての質問・批評・情報提供その他用スレなのれす♪ ' \___ _________________________ V ∋oノハヽo∈ ( ´D`)ノ これでも見れ。 ttp://blogs.msdn.com/b/shintak/archive/2012/09/09/10347542.aspx より、 重要なポイントだけ抜き出すと、 ・利用する場合は、著作権、特許権、商標、出所の表示をアプリ内のどこかに入れておく必要があります。 ・ソース コードを商用または非商用の目的で表示、変更、および再頒布できます。 おお、有難うございます。 大変参考になりました。 > ・利用する場合は、著作権、特許権、商標、出所の表示をアプリ内のどこかに入れておく必要があります。 ということは、 今利用しようとしている Microsoft Public License (Ms-PL) で公開されているソースコードに 著作権表示が書かれているので、それをそのまま何も変更せずにソースコードを使わせてもらえば良いのかな? でもコンパイルすると、そういうコメントは出来あがったバイナリの実行ファイルからは消えてしまうと 思うので、それじゃあダメかな。 この点に関してググってみたのだけれど、結局良く分らないのですが、結論としてはどうしたら良いのだろうか? > ・ソース コードを商用または非商用の目的で表示、変更、および再頒布できます。 安心しました。 このスレを案内されたので、教えてください。社内LANだけで使うシステムの場合GPLやLGPLでのソースやらリバースエンジニアリングやらの公開相手というのは、社内の人だけでいいのでしょうか? それとも、webで全世界公開しないといけないのでしょうか? >>594 GPL読めば解るだろ、バイナリ入手した相手に対してのソース公開義務があるって書いてあるじゃないか バイナリ入手経路が外部に出てないなら外部に公開するひつようなんざねぇよ 家電組み込みにlinuxが使われてるらしいがあれらも公開されてんのかな linuxってgplなんしょ >>596 その事実に最近気がついた企業は必死になって組み込みから linux を外そう、あるいは隠そうとしている うちの会社も製品に Debian Linux を使っていたが、最近ポート 80 を閉ざしたことは内緒だ 少なくともlinux自体に手を入れていればそのソースを公開する必要があるだろうが、 linuxとその上で動くプログラムを一緒に配布する場合、プログラムを含めた全体が GPLである必要があるんだっけ? 創業者ストールマン的には、全体が GPL になる、と言い切るだろうと思う 最近はアプリケーション部分の開示は必要ないというそうだが‥なんだかグレーだねえ linuxがプリインストールされてたLindowsってのが消えたのはそこらが理由か? FAQすら見てないような返答すんなよ ttp://www.gnu.org/licenses/gpl-faq.ja.html あと、これはGNUプロジェクトの見解であって、Linuxのような有名なGPLプロダクトでも、 これと同じでないこともある(BLOBの扱いとか)し、一般にそれは受け入れられている。 >>601 GNU-GPL を理解しているお前なら答えられる!ぜひ見解を教えてほしい 問:以下の文章が間違っている理由を述べる 1.GNU-GPL の元で公開されている Linux 上で動作するすべてのプログラムは GNU-GPL をそのライセンスとしなければならない 2.GNU-GPL の元で公開されている gcc が出力するオブジェクトコードおよび出力するオブジェクトコードを含む実行形式ファイルは、すべて GNU-GPL をそのライセンスとしなければならない。 3.GNU-GPL の元で公開されているライブラリを静的ないし動的にリンクするプログラムは、すべて GNU-GPL をそのライセンスとしなければならない BSDライセンスのソースコードのバイナリを配布したいのですが 著作権表示などはどのようにすればいいですか プロプラリのOSに、GPLのファイルシステムドライバを組み込んだ場合 OS自体はプロプライエタリを保てますか? 例えば、NTFS用のドライバがGPLであったとして、それをOSに組み込ん だ場合、OSはクローズドでも構わないんでしょうか? >>606 はドライバ開発者が自分のをGPLにしたいという質問 >>605 は OS をGPL・ソース開示にしたくないという質問 個別交渉してOKを貰うことは出来るかもしれないが 相手もまたGPLのコンポーネントに依存してるということが当然ありうるので 期待できない 俺なら自作のちゃちいファイルシステムを用意して 「このOSは同じI/Fの××と置き換えても使えますよ!!」 と逃げることを考える プロプライエタリなライブラリとリンクするコードはオープンソースライセンスに出来ない? >>610 できるライセンスもあるができないライセンスもある。 基本情報技術者試験のアセンブラ科目のCOMETII/CASLIIの仕様にそって自作VMとか作るのってライセンス的にセーフ?アウト? それとも↓のCASLIIシミュレータの二次創作物扱いになってアウトになる? https://www.jitec.ipa.go.jp/1_20casl2/casl2dl_001.html 日本の著作権法では仕様は保護対象ではないので、既存の実装と関係なく仕様のみを見て作られたものは問題ない。 ただし商標や特許などは別の話。 >>614 d 商標や特許になってないかを調べる必要があるってことか 面倒だな GPLとかBSDとかのライセンスってのは著作権のこと? 原作が英語の本を日本語に翻訳して出版するときは原作者の許可を取るけど JavaでかかれたソースをC#に移植したりするのもそれと同様? >>616 複製や翻案など、著作権者の許諾を得ないと著作権違反になる行為に対してライセンスというものを設定することで わざわざ著作権者に直接連絡をとって許諾を得なくても利用できるようにしている。 GPLのプログラムと他人の作ったCC-by-ncの画像ファイルを tar.gzやzip、msiなどの形式で配布することはできますか? オープンソース開発における一般的なライセンスだと、コンパイルしたバイナリを配布することも承諾しているのが普通ですよね? バイナリ配布のみ禁止している例など有りますでしょうか? 午後のこ〜だがいろいろライセンスがややこしくてバイナリ配布ができない例 オープンソースってのは 不特定多数にソースコードを公開するって意味? アプリやライブラリを使う人がソースコード開示を要求したら各人にソースコードを開示するって意味? GPLではオープンソースのアプリは有料で売ってもOKみたいなこと書いてあるけど ソースコード開示も有料ってオープンソースになる? あ、オープンソースだとGPL汚染とかで派生物でもソースコード開示だから ソースコードは不特定多数に公開するのがオープンソースで ソースコードは有料提供は意味ない感じか >>622-623 GPLのソースコード開示義務はあくまでも再頒布要件。 しかもバイナリを渡す相手にのみ、ソースを公開すればいい。 「GPLのコードを使う」=「バイナリをネットで一般公開する」 という感覚ってどこから来るのか不思議である。 質問はオープンソースという言葉の定義について聞いているのではないのか バイナリだけMITやBSDで配布してもソースコードの開示義務はないし、オープンソースの範疇にも入らない。 オープンソースやフリーソフトは、ソースを提供すればその他人類が勝手にソフトを発展させてくれるはずだという思想や戦略である。 GZIPはGPLだって話だけど ・GZIPの仕様をまとめてあるRFC1952に書かれている通りのフォーマットを実現するコードを書いたらGPLにする必要があるの? ・GZIPの仕様をまとめてあるRFC1952に書かれている参考のコードを使ったりしたらやはりGPL? >>631 GPLは著作権ベースの契約なので、仕様に関して効力を持ちません。 RFC1952の文書はGPLではないし >いかなる目的に対しても、多言語への翻訳、編集物への組み込みを含めて、本文書のコピーおよび配布を無償で許諾します。 とRFC文書中に書かれているので、文書内のコードを利用することに関する制限はありません。 gccというGPLなコンパイラでコンパイルして出来た生成物はgccのGPLの影響は受けないって聞くけど #include<stdio.h> とかで読み込まれるヘッダファイルやそれによってリンクされるオブジェクトファイル(ライブラリ)のライセンスはどうなってんの? gccのインストールで一緒に入ってくるヘッダファイル群とかのライセンスってどうなってんの? それらでGPL汚染ってあるの? コンパイルして出来た生成物には、 エラーメッセージなどのGPLの著作物を含むから、 GPLになるんじゃないの? それに機械的に作られた生成物自体も、 各コンパイラによって異なるから、 特徴もあるし著作物になるのじゃ? (機械翻訳された文章なども) それとも、gccの利用規約に、 生成物はGPLにならないと書いてあるの? LGPLなら、もう少し条件がゆるいよ 基本的には include <stdio.h> で必要となるライブラリが何なのかを確認する必要がある。 また、gccで問題なくても、 sygwinとmingwのランタイムライブラリのライセンスはそれぞれ違うことに 何らかの影響を受ける可能性もある。 linuxに関して本体がGPLなので、リンクやapi呼び出しはGPL汚染の範疇だが、 APIのヘッダファイルに例外規定が書いてあるので問題にならない。 d そのサイトの機械翻訳ぽいの分かりにくいね ともかくgccでは自由な開発は出来ないってことね 他のライセンスの使いやすそうなツール探すわ その「自由な開発」が何を意味してるかにも依るんだが GPLでライセンスされたライブラリをスタティックにリンクするなら 配布時にソースは開示しなければならない&ライセンスはGPLにしなければならないってだけで 配布しなけりゃそもそも誰かに許諾する必要が無いからライセンスは関係ないぞ。 日本語の文すら読もうとしない奴に説明したって無駄だろ (1) gccってライセンスで例外規定(?)っての設けてるらしいけど それってGPL系との互換性が無くなってたりしないの? (2) GPL系とのデュアルライセンスを取ってるものがあったりするけど GPL汚染のあるコードをGPL系とのデュアルライセンスで公開することは可能なの? それともGPL系とのデュアルライセンスで公開されてるものはGPL汚染のないクリーンな成果物だったりするの? (3) ゼロから自分で作り上げたものにどんなライセンスで提供するかは作成者本人の自由だし 既存のライセンスを適用して例外規定設けるとかそういうことも可能だけど 例えばゼロから作ったものじゃないGPL汚染した成果物の場合GPLで公開することになるだろうけど それに対して汚染部分を除外した範囲のコードに例外規定を設けることって可能なの? >>641 (1) もちろんgccと例外規定の異なるGPL製品を結合して配布する場合、ライセンスに矛盾が生じることになる。 gccを使って作られたバイナリは例外規定によりGPLの外にあるので好きに使えばいい。 (2) 不可能。 考え方が逆。 デュアルライセンスの場合、 儲けたい方をプロプライエタリなライセンスで販売し、 貧乏人にGPLでコードを提供する。 (3) 可能。全体としてライセンスに矛盾が出なければ問題ない。 >>641 2に関しては、バグなどに対してGPLとしてパッチが送られてきて、GPL側ではない方で面倒が起こることがある。 >>644 それはフリーライダーを修正パッチの実験台にして、 それからメジャーアップデートで正規の顧客に対応するというアレではないのか。 質問です @ フリーソフト自体のライセンスは明示されているが ライセンスが不明なライブラリが組み込まれていた場合 このフリーソフトで制作した成果物(Aのような)が ライセンス違反に問われることはあるの? A MITライセンスのような、ソースコードにライセンスを明記しろという条件は MITライセンスを使用したソフトウェアのソースコードを流用するときだけで MITライセンスのテキストエディタなどで打ち込んだ成果物 (一から自分で書いたテキストファイルやソースコード) にまで明記しなくて良いという解釈で正しいだろうか? >>645 パッチかGPLで送られてきてそれをそのまま当ててしまうと、コマーシャルライセンスで出せなくなってしまう。 >>646 @PDFにフォント埋め込むとライセンス違反になる例があるように、 フリーソフトとフリーじゃない素材をセットにするのは全然アリ。 ツールに誘導されるままにフリーじゃない素材を埋め込めば、ライセンスを気にする必要は当然ある。 Aそれは一から自分で書いたからエディタの派生物にならないというだけで、 リッチなエディタにありがちな補完、例文、スニペットをフル活用すれば一概に無関係とはいえなくなる。 外部から別ライセンスの素材を引っ張ってくることだってできるしな。 >>648 @成果物に混じらないもの 例えばエディタなら、文字を打ち込む機能がライブラリ依存だった場合 それを使用して作成した成果物は影響を受けたりしないのかな? Aソフトウェアの機能を使うとNGって訳ではないよね? 自分で設定したマクロやスニペットなら問題なさそうに思えるけど 取りあえず不明なライブラリをぶち込んでるフリーソフトは使わない MITライセンスのエディタ機能で 「bodyやdivなどのタグ入力補完を使用したらMITライセンスだと記載しないといけない」 っていうのはググっても似たような事例が出てこないし、ライセンスの記述方法についてもタグひとつひとつにMITライセンスを適用するってのも考えにくいので、基本的な補完機能については気にしないで使っていって、最悪手打ちで全て打ち直す レスくれた人thx 誰も明確な答えが分からんような質問でスマンかった 作ったものをオープンソースライセンスで公開したいんだけど Apacheライセンスv2がOSDNの日本語版やWikipediaを読んでもよく分からなかったので MITライセンスなら分かるので MITライセンスとApacheライセンスv2の主な違いを知りたい とりあえずapacheライセンスは商標を譲らない方針。 で、apacheの方がmitより厳しいということは、apacheとmitのライブラリを結合した成果物を apache v2で配ることはできても、mitで配ることはできないということになる。 BSLってBoost Software Licenseのことね 実行可能コードにライセンス表記をつけなくてもいいBSLの方が緩いよ。 緩いことが正義なら、パブリックドメイン以外はありえないけどな。 個人開発でオープンソースで公開するならパブリックドメイン1択だよな ライセンス(使用許諾)なんて設けたってライセンス違反者を法的に訴えたりするわけじゃないだろう? だったらライセンスなんて形で公開する意味はない まぁGPL汚染に限らずなんらかのライセンスの許で使ってるコードが混じってるなら安易にパブリックドメインには出来ないだろうけどな GitHubのGistみたいなコードスペニットを公開するサービスたくさんあるけど あれらで公開されているコードのライセンスってどういう扱いになるの? 数行程度のから数十行程度のコードばっかだから著作権法は適用されないって感じ? それってGitHubのリポジトリサービスについてしか言及してないけどGistにも適用されるのかなあ GitHubに直接問い合わせるしか方法は無さそうだね・・・ GitHubの日本向け窓口は法人向けだから訊くならやはりGitHub本社のほうだよねえ・・・英語かあ >>661 投稿物に勝手に再頒布OKなライセンス付けるサイトとか無いし、 書き込みがすべて第三者に再利用されること前提なわけもない。 投稿者自身が書き込みにライセンス設定をしていないのであれば、ただ著作権によって保護されるのみ。 その上で、著作物性がないと判断できるなら、著作権による保護も働かないだろう。 俳句やツイートなどのように少ない文字数で著作権を発生させ得る場合もある。 文字数だけでは著作物性の判定はできない。 GitHubなりBitbucketなりプルリクエストを受けてマージするじゃん コントリビュータのリストにプルリクくれた奴の名前を追記するまでは普通の流れだが 気になるのはライセンス文(LICENSE.mdとか)はどうなるのかってとこ プルリクのコード部分はプルリクくれた奴の著作権になるわけじゃん 受け取ったコードのライセンスをどうするかはくれた奴と相談して決めて必要ならそいつのライセンスを表示する一文なり書けばいいんだけど 自分のライセンス文には自分の著作権だと明示してるわけだからプルリクをくれた奴との著作権やライセンスについてどう話をつけたとしても どこからどこまでが自分のコードでそれ以外は貰ったコードとか具体的に書いたほうがいいの? クリエイティブコモンズで提供されているjavascriptファイルを使用するとき 著作者のクレジットってどこに書いておけばいいの? jsファイルの頭にあるライセンス表記を消さなければいいレベル? それとも使用している全ページのどこかに名前書いとくレベル? ライセンスのことなら俺に聞け というタイトルがいい。 MITライセンスのライブラリAを含んだライブラリBをMITライセンスあるいはApacheライセンスで配布するとき、 ライブラリAの著作権をライブラリBのライセンスに明記するのに使われる英文の雛形などありますでしょうか? CodeProjectに掲載されているものって ライセンスが不明な場合は使えないのかな? 機械翻訳しながら調べたんだがライセンス不明な場合の扱いは読み取れんかった GitHubだとライセンスが不明なものの扱いも定められているみたいだけど CodeProjectではそういうのは無いのだろうか 一応以下のurlが、俺が見たページ Terms Of Service for CodeProject ttp://www.codeproject.com/info/TermsOfUse.aspx Licenses ttp://www.codeproject.com/info/Licenses.aspx >>671 ライセンスが不明のものなんて掲載してないでしょ。 投稿ガイドラインにもライセンスはしっかり選べと書いてあるし。 >>672 それが古いものだと選んでないのがあって(記事内やダウンロードしたファイル内にも書かれていない) ライセンス不明なものには以下のような文が記載されてる License This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below. A list of licenses authors might use can be found here これって「ライセンス不明だけどライセンスはあるから」って意味だよね? >>673 たぶんその通り。 本文中かダウンロードしたファイル中に書かれてるかもとしつつも、 最終的にはページ下部のコメント欄で作者に聞けと書いてる。 でも古いんじゃ作者の返答は期待できない。 使い物にならないと思うよ。 >>674 うわーやっぱりか 俺が英語を取り間違えてる可能性に掛けてたけどダメそうね…… レスサンクス 諦めて別のを探すわ たとえば他人のMITライセンスのソースコードからforkして改造したコードを元のライセンスから追加制限なしで公開したい場合、 オリジナルの人のライセンス文を含めるのは分かるけど 改造加えた部分に関して何か明示とかしたほうがいいの?そこの部分に関して俺の名でMITライセンスだって書いたほうがいいの?書かなくても大丈夫? 似たようなライセンス文がダブるとか邪魔くさいし >>676 追加制限なしなら、お前の改造した部分に関してはパブリックドメインにすることになるね。 MITだとお前の署名入りMITライセンスを同梱する条件がくっつくから、追加制限なしという条件に合わない。 流れとしては、お前の改造部分に関してはお前に著作権あるけど、お前はそれを主張しないってやつな。 改造加えた部分にコメント入れてもいいし、入れなくてもいい。README等に改造したってこと書いとけばいいだろう。 お前が書いた部分に関してはお前が著作権を主張して、その上でどのようにライセンスするか決めなきゃいけない。 >>677 分かりやすく説明ありがとう! つまり改造した部分についてパブリックドメインって明示したほうがいいってことか そうするよ オープンソース系のソフトを見ていると、黒に近いソースやライブラリが混ざっていても 大半のユーザーが気付いてない or 気付けないと思うんだが これらのソフトで作られたものってどうなるのかね? テキストファイルとか、テキストを打ち込んでコピペした文章とか、アカウントとか ググっても微妙な回答しか見当たらないのは、盗んだペンで紙に書いた文字は違法になるのかと同じようなレベルで何とも言えんのかもしれんけど >>679 作品を製造する過程と、作品そのものは分けて考えるべき。 死刑囚の手記は合法的に売れる。 他人のコードや著作物を勝手に作品に埋め込むようなツールならば 作品が著作権侵害あるいは特許侵害で訴えられる可能性はある。 割れphotoshopで絵を描いたからと言って、 単純に丸いだけのペンだけ使ってフリーハンドで描いたのであれば、 その絵自体は問題にならないだろう。(不正使用の点に関しては追及されるだろうが)。 複雑な形状のペン使ったとか、フォント使ったとか、素材使ったとかであれば、絵そのものにも影響が及ぶ。 つまり、著作権違反の可能性が出てくる。 裁判結果は書き込みの量と弁護士の腕次第。 >>680 上で書いたコピペみたいな データが混入しないと思われる単純なものなら問題なさそうな感じか >複雑な形状のペン使ったとか、フォント使ったとか、素材使ったとか 確かに他人の著作権が明確なものが含まれてたら不味そうだ レスthx 割れは兎も角OSSは自己責任とはいえリスクが怖いな OSSでは倫理観で善悪の判断をするが法律では白黒つけない もし訴訟という事態になっても和解で決着するのを最善とする 何故ならOSSの倫理観と裁判所の判決が同じとは限らないからである 裁判官の心証とか弁護士の腕などという不確かなものに依存して 倫理観を覆すような結果になったときの不利益は計りしれない >>681 たとえ正規でもツールや素材のライセンスを十分に理解して使ってる奴は少ない。 素材集で言えば、個人が年賀状に書く用とか、ウェブサイトに掲載できるもの、業者が雑誌とかで使う用とかではライセンスが全然違う。 特にWindowsでデフォルトで入ってるフォント等は罠がいっぱいだ。 例えばMSゴシックは本来画面で見ることしか想定されてないライセンスだ。 印刷して配布したりするとなると途端に怪しくなる。 >>683 黙認というかグレーというか そういのも結構あるんだろうね そこら辺のライセンスを考え始めたら かなり分かり難いのもあるから雁字搦めになる気もするし ただmsもmacみたいに一元管理になればと思う LGPLのリバースエンジニアリング条項について質問です。 ライブラリA (LGPL v3) dynamic link ライブラリB (MIT) dynamic link 製品C (プロプラ) この場合にリバースエンジニアリング条項が機能するのはBまでであってますか? >>685 プラグインなどのように自由に差し込めるものではなくて、 リバースエンジニアリング条項が有効になるようながっつりしたライブラリ利用をした場合、 ライブラリBをMITやパブリックドメインでリリースすることが不可能だろう。 ライブラリBの利用者にライブラリBを自由に使う権利(リバースエンジニアリングを禁止してリリースしたりとか)を与えることができないわけだから。 >>686 ありがとうございました ということは、そもそもBの時点でおかしい可能性があるんですね BはAを利用しているだけで二次著作物ではないという主張が通るならMITで問題ないし、リバースエンジニアリング条項も関係なくなる そうではないなら、Bはリバースエンジニアリングを許す条項を持った独自ライセンスが必要になる どちらにしても製品Cまで波及することはなさそうです CがBの二次著作物であると判定される場合、Cにもリバースエンジニアリング条項が適用されるかもね。 私も似たようなことで悩んでいるが ffmpeg(コンパイルオプションでLGPL2.1+) ↓ dynamic link FFmpegInterop library for Windows MS製(Apache2.0) ↓ dynamic link 自分のプログラム なんだが、MSだけに無謀なことやっていないだろうからApacheライセンスとして扱って良いんですかね? >>689 動的リンク以前の問題として、ソースで配布するのとバイナリで配布するのでは条件が変わってくる。 ソースコードによる配布の場合、GPLやLGPLを含もうと自作プログラムが影響を受けることは無い。 FFmpegInteropとやらがソースをapache2.0で配布するのは自由。 ただしlgplのバイナリとリンクしたバイナリを配布するのであればlgplの影響を受ける。 >>689 問題ない 難癖つけられるのを避けたいなら、 このプログラムを実行するにはMSのffmeginteropが必要です、 ライブラリ入手先はこちらです(URL) とか書いて、自分のプログラムはMSの製品を利用してるだけですよのスタンスを明確にする >>690 >>691 レスありがとうございます。PCがトラブって返事が遅くなったのをお詫びします まあライセンスはなかなか難しいものですね まあリバース・エンジニアリングするより新規で作ったほうが安上がりになる程度のものだから 気にせずにリバースエンジニアリングには特別触れないってことでお茶を濁しますか read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる