アカウント名:
パスワード:
> GitHub 上のプロジェクトのうちだいたい半分は「all rights reserved (転載禁止)」だ。
all rights reserved (著作権保有)だ。
Githubをざっと調べると、プロジェクトの半分はライセンス情報がない。30%はソース内に書いてる。20%は明確なライセンスファイルがある。ベルヌ条約加盟国では何もしなくても著作権が発生し、コピーして使ったり改良したりするのは著作権侵害になる。著作権法ではデフォルトで著作物の権利は著作者が保有するので、ライセンスの無いコードは法律上共有できない。ライセンスの無いプロジェクト内のコードを使用すると、将来的に著作権侵害の訴訟になる可能性がある。だからオープンソースライセンスが考えられた。(訳注:オープンソースライセンスは著作者が著作権を保有した上で、著作者の権限で利用者にコードを共有する権利を与える。)Githubのプロジェクトをforkする人は、そのコードを使う権利があると思ってるが、そうじゃないpullリクエストをacceptする人は、そのコードを使う権利があると思ってるが、そうじゃないサービス利用規約で「Githubにコードを置いたら誰にでもviewとforkを許可するとみなす」っつてるけど、そんなん法的にあやふやで、いつか大問題になる "blow someone's leg off."。仲良く共有してる間はいいけど、PeopleSoftとTomorrowNowがそれぞれOracleとSAPに買収されて対立した結果、それまで権利があやふやなまま2社で共有されていたものが著作権侵害で訴訟になったように、同様のことがおきるかもしれん。Githubは、(訳注:コードを共有できるということを法的に明確にするために)デフォルトでApache V2かCC-BYライセンスにするように規約を変更するとか、OSIオープンソースライセンスから選べるようにするとかしたらいんじゃね。それまでは、ライセンスが無いプロジェクトは用心して避けろ。
Githubをざっと調べると、プロジェクトの半分はライセンス情報がない。30%はソース内に書いてる。20%は明確なライセンスファイルがある。
ベルヌ条約加盟国では何もしなくても著作権が発生し、コピーして使ったり改良したりするのは著作権侵害になる。著作権法ではデフォルトで著作物の権利は著作者が保有するので、ライセンスの無いコードは法律上共有できない。ライセンスの無いプロジェクト内のコードを使用すると、将来的に著作権侵害の訴訟になる可能性がある。
だからオープンソースライセンスが考えられた。(訳注:オープンソースライセンスは著作者が著作権を保有した上で、著作者の権限で利用者にコードを共有する権利を与える。)
Githubのプロジェクトをforkする人は、そのコードを使う権利があると思ってるが、そうじゃないpullリクエストをacceptする人は、そのコードを使う権利があると思ってるが、そうじゃない
サービス利用規約で「Githubにコードを置いたら誰にでもviewとforkを許可するとみなす」っつてるけど、そんなん法的にあやふやで、いつか大問題になる "blow someone's leg off."。
仲良く共有してる間はいいけど、PeopleSoftとTomorrowNowがそれぞれOracleとSAPに買収されて対立した結果、それまで権利があやふやなまま2社で共有されていたものが著作権侵害で訴訟になったように、同様のことがおきるかもしれん。
Githubは、(訳注:コードを共有できるということを法的に明確にするために)デフォルトでApache V2かCC-BYライセンスにするように規約を変更するとか、OSIオープンソースライセンスから選べるようにするとかしたらいんじゃね。
それまでは、ライセンスが無いプロジェクトは用心して避けろ。
3行まとめ
Githubのプロジェクトの半分はライセンスが無い著作権法では、ライセンスが無いものを使うと著作権侵害になるGithubはライセンスが無いものはデフォルトでApacheV2かCC-BY扱いにするとか何とかしろ
著作権はどんなライセンスにしてもあるだろう。All rights reservedが即、転載禁止になるのも違うが。「その権利で他人にどんなことを許すか」が書かれていれば問題ないんだろうが、それを一言で済ますのがCC。
書いてないということは、禁止とも明記していないんだから必ず問題になるわけじゃない。「forkしていい?」と聞くこともできるだろう。(メッセージ専用の機能はGitHubにないけど)「法的に真っ白じゃないと使わない」という姿勢はどうなの。
pullリクエストをacceptする人は、そのコードを使う権利があると思ってるが、そうじゃない
そんなばかな。デパートの食品売り場で「どうぞ」と言われて貰ったカマボコのかけらでも請求されるかもよ???あり得ない。
>「法的に真っ白じゃないと使わない」という姿勢はどうなの。そのへんのニュアンスは誤訳してるかもしれないので原文を当たって下さい。俺は訳しただけなので本人の意図はわかりませんが、想像するに:
RMS(ストールマン)はEmacsを開発していて、ゴスリング(Javaの作者)が拡張したのでメールで「取り込んでいい?」って聞いて了解もらって取り込んだのですが、後で「やっぱ売るからダメ」と言われたので書き直しました。これに懲りたRMSは後に(OSSLの中で最も厳しい条件のライセンスである)GPLを作ります。またGNU Softwareにcontributeするときは書面(紙)の誓約を求めるなど慎重にも慎重です。GNU GPL登場前夜 [osdn.jp] リチャード・M・ストールマン スウェーデン王立工科大学講演 [gnu.org]
一方BSDはAT&T UNIXにcontributeしてましたが、UNIXが配布条件を変えたのでAT&T部分を捨てて書き直しました。が、AT&T部分が残ってるという裁判になります。UNIX:歴史 [wikipedia.org]
かつてソフトウェアは、ビジネス面ではハードウェアのおまけ的な扱いで権利をうるさくいう言われることもなく、開発者同士の暗黙の了解や口約束で共同開発してたらしい。しかしソフトのビジネス面に着目されると、上記のような権利問題が起き、ソースは社内に秘匿され、共同開発もできなくなったらしい。そこでライセンスでビジネス社会と法的に折り合いをつけつつ、コミュニティによる共同開発を復活させようとしたのがフリーソフトウェア運動であり、後のオープンソース運動につながります。
そういった過去の経緯を知る人からは、ライセンスなしで暗黙の了解や口約束に頼る昔のような状態は危うく見えるのかもしれません。
著者のSimon Phippsを調べると元Sun MicrosystemsのChief Open Source Officerで、Java(OpenJDK)、NetBeans、OpenOffice、OpenSolaris、ZFS、MySQL等、オーブンソースとビジネスの境界に関わっていた人物であり、ビジネス視点からより慎重な態度なのかもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
タレコミ本文は微妙に誤読してるような (スコア:3, 参考になる)
> GitHub 上のプロジェクトのうちだいたい半分は「all rights reserved (転載禁止)」だ。
all rights reserved (著作権保有)だ。
Re:タレコミ本文は微妙に誤読してるような (スコア:2)
3行まとめ
Githubのプロジェクトの半分はライセンスが無い
著作権法では、ライセンスが無いものを使うと著作権侵害になる
Githubはライセンスが無いものはデフォルトでApacheV2かCC-BY扱いにするとか何とかしろ
Re: (スコア:0)
著作権はどんなライセンスにしてもあるだろう。All rights reservedが即、転載禁止になるのも違うが。
「その権利で他人にどんなことを許すか」が書かれていれば問題ないんだろうが、それを一言で済ますのがCC。
書いてないということは、禁止とも明記していないんだから必ず問題になるわけじゃない。
「forkしていい?」と聞くこともできるだろう。(メッセージ専用の機能はGitHubにないけど)
「法的に真っ白じゃないと使わない」という姿勢はどうなの。
pullリクエストをacceptする人は、そのコードを使う権利があると思ってるが、そうじゃない
そんなばかな。
デパートの食品売り場で「どうぞ」と言われて貰ったカマボコのかけらでも請求されるかもよ???あり得ない。
Re:タレコミ本文は微妙に誤読してるような (スコア:1)
>「法的に真っ白じゃないと使わない」という姿勢はどうなの。
そのへんのニュアンスは誤訳してるかもしれないので原文を当たって下さい。
俺は訳しただけなので本人の意図はわかりませんが、想像するに:
RMS(ストールマン)はEmacsを開発していて、ゴスリング(Javaの作者)が拡張したのでメールで「取り込んでいい?」って聞いて了解もらって取り込んだのですが、後で「やっぱ売るからダメ」と言われたので書き直しました。
これに懲りたRMSは後に(OSSLの中で最も厳しい条件のライセンスである)GPLを作ります。またGNU Softwareにcontributeするときは書面(紙)の誓約を求めるなど慎重にも慎重です。
GNU GPL登場前夜 [osdn.jp] リチャード・M・ストールマン スウェーデン王立工科大学講演 [gnu.org]
一方BSDはAT&T UNIXにcontributeしてましたが、UNIXが配布条件を変えたのでAT&T部分を捨てて書き直しました。が、AT&T部分が残ってるという裁判になります。
UNIX:歴史 [wikipedia.org]
かつてソフトウェアは、ビジネス面ではハードウェアのおまけ的な扱いで権利をうるさくいう言われることもなく、開発者同士の暗黙の了解や口約束で共同開発してたらしい。
しかしソフトのビジネス面に着目されると、上記のような権利問題が起き、ソースは社内に秘匿され、共同開発もできなくなったらしい。
そこでライセンスでビジネス社会と法的に折り合いをつけつつ、コミュニティによる共同開発を復活させようとしたのがフリーソフトウェア運動であり、後のオープンソース運動につながります。
そういった過去の経緯を知る人からは、ライセンスなしで暗黙の了解や口約束に頼る昔のような状態は危うく見えるのかもしれません。
著者のSimon Phippsを調べると元Sun MicrosystemsのChief Open Source Officerで、
Java(OpenJDK)、NetBeans、OpenOffice、OpenSolaris、ZFS、MySQL等、
オーブンソースとビジネスの境界に関わっていた人物であり、
ビジネス視点からより慎重な態度なのかもしれません。