【License】ライセンス総合【利用許諾】
. ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
｜ ライセンスについての質問・批評・情報提供その他用スレなのれす♪
' ＼＿＿＿ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
Ｖ
∋oノハヽo∈
( ´ⅴ｀)ノ
元のソースのライセンスに縛られないよね？
【殺しの】ライセンス【道で拾った】
http://pc12.2ch.sc/test/read.cgi/tech/1045006087/
ついでに関連スレ。
ライセンスあれこれ
http://pc12.2ch.sc/test/read.cgi/unix/1032702590/
GPL/LGPL等ライセンスとゲーム製作_2
http://pc11.2ch.sc/test/read.cgi/gamedev/1036512390/
自由なゲーム製作を阻害する特許ってある？
http://pc11.2ch.sc/test/read.cgi/gamedev/1107928429/
>>1乙すぐる
裁判になったら、クリーンルームでやっていないと負けるだろうね。
・GNUソフトウェア、Linuxなどが採用
・自由な再配布、修正、派生的作業を妨げる行為を禁止
・派生的作業によって生まれた派生物にもGPLが適用される
・商業利用も理論的には可能。RedHat Linuxとか。
GNU Lesser General Public License(LGPL)
・LGPLはGPLの制限を緩めたもの
・商業ソフトウェアにおいて、LGPL に従うライブラリやツールキットへのリンクを
可能にした
BSD License
・派生的作業に関してはソースコードの公開を義務づけない
・派生物を商業ソフトウェアにすることが可能
・bind、sendmail、Apacheなど、多くのオープンソースソフトウェアが採用
Artistic License
・どこからオリジナルが入手できるか明記されている場合と、派生物の実行ファイ
ルがオリジナルとまったく違う名前を持ち、その違いが明らかにされている場合
には、実行ファイルのみで配布できる
・派生物を1つの組織内だけで利用できる
・その存在が完全に隠されている場合、商業ソフトウェアの一部として利用できる
Mozilla Public License
・派生的作業のうち、追加的作業についてはオープンソースでなくてもよい
NYSL
煮るなり焼くなり好きにしろライセンス。
・ttp://www.kmonos.net/nysl/
PGM 組み込ま 派生物 生成物 採用
本体 れたソフト ソフト
GPL ○ ○ ○ × Linux
LGPL ○ × ○ × glibc
BSDL ○ × × × Apache
Artistic △ △ △ × Perl
MPL ○ × △ × Gecko
>>ttp://linux.ascii24.com/linux/news/today/2000/04/21/440416-000.html
GPL の日本語訳
ftp://ftp.sra.co.jp/pub/gnu/local-fix/GPL2-j/gpl.text.gz
LGPL の日本語訳
ttp://www.debian.or.jp/~mhatta/lesser.ja.txt
Artistic License の日本語訳
ttp://www.bekkoame.ne.jp/~bero/docj/artistic.html
NYSL もともと日本語
ttp://www.kmonos.net/nysl/
Creative Commons Japan - クリエイティブ・コモンズ・ジャパン
http://creativecommons.jp/
とかについても語り合ってください。
仕様を把握する奴と、コードを書く奴を分けろって奴か。
まあいいや、大人しくGPLに従うか。
やっていたとしても、
そのアイディアや技術が特許になっていたら
全然負けると思うぜ。
▼▼ApacheライセンスとMITライセンスは、
「これらでライセンシングされたソースコードを使っても
両方ともオープンソースからクローズドソースまで
混ぜてもOK。」
というのが共通点だと思いますが、これらの相違点を教えてください。
よろしくお願い申しあげます。
▼▼まぜてもＯＫというのは誤解を招く。
どちらのライセンスも満たすべき条件（著作権表示、ライセンス文書の添付など）がある。
それが貴方のビジネスにおいて許容できる条件なのかどうか私は知らない。
MITライセンスは「著作権」に基づき、利用や再頒布を許可するのに対し、
Apacheライセンスは「特許権」に基づいた利用、再頒布もカバーしている。
またApacheライセンスでは「NOTICE」を頒布物に含めなければならない。
▼▼
分かりやすいご説明ありがとうございます。
助かりました。
まぁ著作権は別な問題なので置いとくとして、ライセンスとかも全く読まずに勝手に
転用・利用してリードミーにも記述なしとか平気であるしね。
自分も子供になんて言って教えていいかよく分からん。
そもそも契約書自体が分かりにくく作られているし。
おおざっぱには理解できても、細かいニュアンスの違いが大問題になることもあるし
例えば、ソース公開が義務づけられている派生物と言われても、DLLで配布する場合、
①自分のソフトからインポートする
②他人のソフトのプラグインとして実装する
③自分のソフトのプラグインとしてあかの他人に実装させる
とかあるとどこまで公開の範囲なのかよくわからん
①はソフトとDLL共に公開の義務ありな気がするけど、
②なら、まさか他人様のソースまで公開させるわけにはいかないだろうし、
それならば①を③の形式にすればDLLソースだけの公開でOKなのか、とか
学校で教えるのもちょっと変だし、親が教えるもんでもないようなｗ
この辺りはなんか微妙だよね。
著作権だったら、学校で教えるべきだと思うけどね。
>>17
そうなんだよね、有名なGPL/LGPL辺りだと日本語訳もあるので、いいのだけど
マイナーなライセンスとか提示されててもよくわからんしｗｗｗ
まあ、ライセンス理解できないやつは使うな（ｷﾘｯと言われるのがオチなんだろうけど。
GPLだと組み込まれたＡＰと派生物まで公開義務が及ぶけど、派生物が組み込まれた
ＡＰはどうなんだろ。
GPL v3 日本語訳
ttp://sourceforge.jp/magazine/07/09/02/130237
GPL-FAQ(最終更新:2005/5/5)
ttp://www.gnu.org/licenses/gpl-faq.ja.html
>ＡＰはどうなんだろ。
GPLでライセンスされたプログラムの派生物はGPLでしか配布できない。
その派生物を組み込んだアプリもGPLでしか配布できない。
（自分で書いたプログラムをGPLで公開する場合、
特定のアプリに対してGPLが伝播しない例外事項を設けることはできる。）
バンドル出来ないもんだから、お茶を濁している。
確かに、GPLが影響するのは配布時だけだから、
各々のユーザーがGPLと非互換ライセンスを組み合わせようが
問題がない。
実際、JavaとかFirefoxとか入ってるでしょ。
Adobe Readerなどの場合はVectorなんかで言うところのフリー（無料）ソフトであって、
誰でも再配布できるような性質のものじゃない。
有料ディストリビューションならAdobeに金払って交渉することも可能だろうけど。
おっしゃるとおり、
俺が間違ってました。
明確な回答ありがとう。
そうか、GPL派生物を組み込んだやつもGPLか。
勘違いしそうな点だった
これは組織内で伝達するときにも必要ですか？
たとえば、Ａ課が作ったGPLなプログラム（Ｃ）をB課の個人ＰＣまたはＢ課のＰＣで利用する場合、
A課はB課にソースを公開しないといけませんか？
Ｂ課にプログラムＣを実行するための専用端末をＡ課が設置する場合、ソース公開は必要ないと理解しています。
裁判してみないと結局はわからないのでは？
あと、
> Ａ課が作ったGPLなプログラム（Ｃ）
ってのは
1.Ａ課が自分で作ったソース
2.ソース公開義務のないライセンスのライブラリ
の組み合わせだけから出来ているの？
もしそうなら必要ないだろｊｋって話になる。
GPLでライセンスされたライブラリを利用してツールを作成することを想定していました。
したがってプログラムＣをGPL以外でライセンスすることは不可能です。
無いのだとすれば、実質的に裁判の心配はしなくて良いと判断できるかもしれない。
話が違ってくると思うが
> A課はB課にソースを公開しないといけませんか？
しなくてはなりません。
ライセンス的には
個人的には、同じ組織でありながらソースが隠蔽されるような
怪しいものは使いたくないな
ソースを求められた時、会社の方針としてこれを禁じることは認められるのか？
競争ならバイナリでも渡さない
Linuxカーネルを使ったMy_Kernelというものを私が作ったとします。
My_Kernelを自分で使い、他人には全く配布していない場合、
他人にソースを見せないことは当然OKですよね。
では
My_Kernelを自分が使い、またAさん(赤の他人)にバイナリで配布し、
それ以外の人には全く配布していない場合、
ソースを公開しGPLライセンスしなければならないのは
Aさんに対してでしょうか？それとも他人(Bさん)にも公開しなければならないのでしょうか？
状況としては、自分が作った物をAさんだけに使ってもらい、
Bさんには使ってもらいたくないなどが考えられます。
AさんにGPLで公開しなければいけない。
GPLだから、AさんがBさんにそれを公開することを妨げることはできない。
ありがとうございます。
ということは、自分とAさんの間で共謀していれば
強制力はないですが実質的にこの2人だけが使えるわけですね。
そんな状況になったことはないですが。
ライセンス違反なことしたいのなら、わざわざ相談することもないと思うのだが。
ライセンス違反ではありませんよね？
違反じゃない。Googleもそうしてる。
ありがとうございます。
具体例出せ
googleはどうかしらんがコード共有者間の合意で他者に配布しないのはGPL違反にはならないだろ
バイナリの入手経路をふさぐのはGPLとは別の事項なんだから
一流の愚者
>>34の例だとコード共有者ってことになって無いぞ。
赤の他人にバイナリで配布って書いてあるし。
おもっきしGPL違反じゃねーか。
>>36の件がなけりゃな
本人とAの間で他に配布しないという了解があればBは受け取れない
もちろんAはGPL的にそれをしないでもよいがここでは「共謀」と書かれている
もしいきなり第三者でスーパーハカーの
Cさんが、Aさんか>>34さんのPCをハッキングして
My_Kernelのバイナリを盗み出したとします。
そしてその国においてはそう言った（ハッキングで盗む）行為は
不正アクセス禁止法違反になる国とします。（日本とか。）
この場合、
Aさんか>>34さんはCさんに
My_KernelのソースをGPLで公開する義務は生じるのでしょうか？
ってことが前々から気になっていたのですが、
いかがなのでしょうか？
ライセンスはあくまで契約なので、
双方の合意が無ければ契約（ライセンス）もまた成り立っていないと考えられるのでは。
なるほど。
私としましては、>>46の状況を
状況1.
として、それ以外にも
状況2.自分のPCで立てたサーバーにMy_Kernelのソースをアップロードし、
Aさんにしかわからないようにパスワードをかける。
しかしそのパスワードは容易に推測できるものとする。
(例:"aaaa", "My_Kernel"など)
状況3.自分のPCで立てたサーバーにMy_Kernelのソースをアップロードし、
誰でも技術的には容易にDLできるようにする。
ただしDLはAさんだけがしてください、他の方はDLすることを禁じます。
と明示する。
というものを考えました。
だんだんうさんくさく再配布に近づいているものですが、
はてさて、いったいどう解釈されるのでしょうか。。。
状況2.自分のPCで立てたサーバーにMy_Kernelのバイナリをアップロードし、
Aさんにしかわからないようにパスワードをかける。
しかしそのパスワードは容易に推測できるものとする。
(例:"aaaa", "My_Kernel"など)
これと同時に別経路（メールなど）でAさんにだけMy_KernelのソースをGPLで公開する。
状況3.自分のPCで立てたサーバーにMy_Kernelのバイナリをアップロードし、
誰でも技術的には容易にDLできるようにする。
ただしDLはAさんだけがしてください、他の方はDLすることを禁じます。
と明示する。
これと同時に別経路（メールなど）でAさんにだけMy_KernelのソースをGPLで公開する。
公開はしていないけどみんな知っているという状態はあり得ると思います。
どういう状態の話をしているの？
特種企業秘密なのに
RSAの実装じゃないのが出回っているが、公式には企業秘密ということになっている。
Microsoftとか大手企業はRSAからライセンスを受けてる場合が多いようだけど、そうじゃない場合どうなるかは不明。
以下はGPLv3の解説であってGPLv2ではどうなっているのか知らないのですが、
要するに、社内利用については、自分で改変して自分で使ってる場合と同じ
ということみたいです。
GNU GPL v3 解説書
http://ossipedia.ipa.go.jp/legalinfo/
p.27
重要な例外として、著作物をコンピュータ上で実行する行為と内部的な改変行為は「プ
ロパゲート」に含まれない。そのため、GPLv3 プログラムの使用形態が実行と内部的な改
変のみに限られるのであれば、受領者はGPLv3 が定めるソースコードの配付義務や特許非
係争義務などの義務を負うことはない。
(中略)
SFLC によれば、同一企業グループ間での行為も「内部的」とみなされる。例えば、
グループ内のシステム開発子会社がGPLv3 プログラムを改変したソフトウェアを開発し、
それを親会社やグループ内の他の企業に配付して、グループ企業が使用するような場合も、
「内部的」な改変に当たり、プロパゲートに該当しない。政府の複数の省庁間でのプログ
ラムの授受も同様に「内部的」な行為であり、プロパゲートに該当しない。
これに対して、「プロパゲート」に該当する行為を行う者は、GPLv3 に定める条件を遵守
すべき義務を負うこととなる
根拠を「SFLCによれば」って丸投げしてるのが若干不安
でもＧＪ
こんな話もあってSFLCはキナ臭い
少なからずあるわけだし、少なくとも2chで
決定打を期待するのは無茶だ。
でも>>54さん乙！
× ダウンロードも合法
○ ファイル共有も合法
バンドルしたとしたらアプリのソース公開まで波及しますか? LGPL ではどうですか?
アイコンがCC表示ならソース云々はまったく問題ない。
アイコンがLGPLならリソースファイルとかexeに統合しない限り問題ない。
と、思う。
再配布可能な適当なライセンスで公開したいと思います。
GPLみたいな感染性のあるライセンスもOKです。
CCも確認しました。
これら以外で、
画像ファイル.jpgに適用できるライセンスを、
いくつか教えてくださいませんでしょうか。
よろしくお願い申し上げます。
LGPLの場合は、リバースエンジニアリング禁止条項の禁止条項があるので、アプリのライセンスにリバースエンジニアリング禁止条項を入れられなくなるのが問題になる事がある。
普通の人間が読める文章ではないです。
自分で読むよりその道のエキスパートに要点だけ教えて貰った方が
正確で確実かと思います。
皆様のご質問に誠心誠意お答えいたしますので
どうぞ気兼ねなくライセンスのお悩みをご相談ください。
> ライセンス文は法的に穴がないことを重視して書かれている
うむ、だから自作のライセンス使うよりも、
どっかのえらい団体が作ったライセンスを使った方がいいと
言われるよね。
あえて現状の日本に限定するが、リバースエンジニアリング禁止条項は
どの程度有効性があるんだろうか？
LGPLで指示されているようなリバースエンジニアリングを禁止しても、法的には意味がないという説が有力のようだね。
それでも、実務的には、禁止されていることをやることをやるときにはそれなりの覚悟はいるな。
普通に読めば解るとは思うけどな。
つかGPLv2の八田真行氏訳の表現は一点だけ変だと思う。気のせいか(SRA版には無い)
> 表明されたか言外にかは問わず、
(普通は表明されているか言外であるかどうかは問わず・・・だと思うんだが)
もしかすると2002年から誰も指摘していないのか...。
つかGPLv2文章がロクに読まれていないかのどちらかだな。gkgkbrbr
SRA 版とのズレも気にはなるところではあるんだよね。
参考元が何であったのかも明示する必要あるんですかね？
「元にして」、「参考」が二次派生物にあたるのであればGPL適用の上、明示も必要。
ほとんど原型がないほどまで消化できていればそれはもう貴方のオリジナル。
遅ればせながらサンクス。
BSDライセンスのプログラムを拾ってきて拡張した場合、著作権の表記はどうなるのでしょうか。
また、100%自分が書いたBSDライセンスのプログラムと、他人が書いたBSDライセンスのプログラムを
統合して1つのファイルにまとめた場合のライセンスはどう表記するのでしょうか。
拡張した部分は、元にしたものがわかるようにすること、と自分の著作権表示を。
BSDライセンスにもとづく、そのままのライセンスによる再配布、になるから、
全体のライセンス表示としてはBSDライセンス（権利者を author と書くと、
うまくぼやかせる）。
拡張した後もBSDライセンスにするつもりなので、
・拾ってきたBSDプログラムを拡張の場合
・自分のBSDプログラムを他のBSDプログラムと統合する場合
のどちらも
Copyright (C) 2009 ORIGINAL-AUTHOR. All rights reserved.
Copyright (C) 2010 MY-NAME. All rights reserved.
＜ライセンス文＞
みたいにしちゃっていいのでしょうか。(後者は逆の順番で自分が先)
それとも、オリジナルの文章を改変してはならないようにも読めるので、
Copyright (C) 2009 ORIGINAL-AUTHOR. All rights reserved.
＜ライセンス文＞
Copyright (C) 2010 MY-NAME. All rights reserved.
＜ライセンス文＞
とするのでしょうか。
テンプレhttp://www.opensource.org/licenses/bsd-license.phpだと
ライセンス本文の<ORGANIZATION>のところ。
たとえばFreeBSDのカーネルのkern/kern_cons.cを見ると
* Copyright (c) 1988 University of Utah.
* Copyright (c) 1991 The Regents of the University of California.
* All rights reserved.
*
* This code is derived from software contributed to Berkeley by
* the Systems Programming Group of the University of Utah Computer
* Science Department.
(以下3条項BSDライセンス本文）
となっている。そんな感じでいいと思われる。
GPLに感染します？
アルゴリズムだけ拝借したなら感染しない。
ただし移植の場合、GPLv2以前では特許権侵害の可能性がある。
GPLv3以降でも無いという保証はないけど。
それで感染しないならC言語からアセンブラ言語に移植しましたとか、C'言語に移植しましたという詭弁が使えてしまう。
翻訳は派生物だよな？
アルゴリズムが同じだけでゼロから書いたものならいいんじゃないかと思うけど
ありがとう
販売したり想定された用途以外の使用はライセンス違反とかの販売あれば面白いのに。
ソフトウェアだけどうして勝手に見えるライセンスを付けて販売できるのだ？
100～のスレッドの続きを読む