  |
はてなキーワード: gplとは
AをBに変換するというルールを作るにあたって、
gccの出力結果がGPLのものを含まないかと言えば、100％含んでるだろ当然。
でもその辞書に特例を設けることによって、
gccのアウトプットにはGPLが適用されないような配慮がされてる。
免責： これは法律の専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。
「Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」
http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace
この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSSの翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます。
ですが、プログラマの間で単にWeb翻訳をOSSに使ってはいけないんだという認識が広まってるように見えます。個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています。
どういう話かというと、自分が個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースのライセンスで公開しています)
念のため言っておきますが、これは元記事で問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります。
コミュニティの思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。
もとの記事のとおり、Excite翻訳の利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。
ここでは、Google翻訳に焦点を当てた話をします。Google翻訳の利用規約はどうか？というと、Googleの利用規約については翻訳結果の利用についての記載がありません。
https://www.google.com/intl/ja/policies/terms/
記載がないということは、使用してよいのか？使用してはいけないのか？いったいどちらなのでしょうか？
機械翻訳の権利問題と似た構造の話に、GPL（GNU一般公衆ライセンス）で許諾されたコンパイラによってコンパイルした結果の利用があります。
GPLの本文には、GPLのプログラムの出力結果自体にGPLのものを含む場合にのみその出力結果にGPLが適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているかの記載はありません。
これについては、コンパイラによるコンパイル結果に対して、コンパイラの著作者はなんら権利を持たないと考えるのが一般的です。
https://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput
著作権法は人々があなたのプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。
コンパイラと機械翻訳ツールとの違いが、対象が人工の言語であるか、自然言語かので違いしかないと考えるならば、Google翻訳の結果をOSSに利用することも問題ないということになります。
ウィキメディア財団の法務チームは、Google翻訳した文書のウィキペディア内での利用についての見解を公開しています。
https://meta.wikimedia.org/wiki/Wikilegal/Copyright_for_Google_Translations
これはアメリカの法律に基づく話ですが、CC-BY-SA 3.0やそれに類似するライセンスのコンテンツをGoogle翻訳で翻訳してウィキペディアで使用してもGoogleの著作権を侵害する可能性はとても低い(very unlikely)と結論づけています。
要点をまとめると以下の通りです。
ウィキメディア財団の見解には含まれていませんがアメリカの法律でいえば、さらにもう一つ「フェアユース」にあたるのではという話があります。これはGoogle自体がよく知っている話かもしれません。
これはAndroidのAPIにJavaのAPIが流用されていることについて、OracleがGoogleを訴訟したものです。
これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコの地裁では著作権使用料支払いの対象にはならないという判決が下っています。
「フェアユース」というのは、アメリカの著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権の侵害とはしないと考えるものです。
ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidのJava APIの流用と比べても、さらにフェアな利用であるように見えます。
(ちなみにGoogleの利用規約には、「カリフォルニア州の抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州の法律が適用されます。」と書かれています)
著作権情報センターのサイトに、 コンピュータ創作物についての文化庁の報告書が記載されています。
http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html
この報告書は、機械翻訳のユーザーが機械翻訳システムを使用するために行う原文の編集や出力の編集が創作的寄与となりうることを認めている一方で、機械翻訳の開発者が翻訳物の著作者になるということについては否定的です。
なお、原文解析等のプログラムの作成者及び汎用的な辞書データベースの作成者は、一般的に翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定の翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。
これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳の技術は大幅に進歩しましたが、創造的個性の表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます。
これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者の著作物。機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間の二次著作物になるということになりそうです。
これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているかを説明してきました。
では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。
だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。
著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。
有名なところでいうと、Monoが思いつきます。AndroidのDalvikがJavaのAPIを真似したものであるのと同じように、MonoはMicrosoftの.NETフレームワークを真似しています。つまり、Monoについても訴訟リスクはあっただろうということです。
しかし、OracleとGoogleが対立したのとは対照的な道をMonoはたどります。
2016年、Monoのプロジェクトを運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoがMicrosoft公認のプロジェクトになったというわけです。
権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。
すこし元の記事に話をもどします。冒頭にも書いた通り、Ubuntuの日本語化プロジェクトに対してWeb翻訳の結果を突っ込むという行為は、批判されるべきだと思っています。
まずは質の問題です。現在のGoogle翻訳などは、UIの翻訳に向いていません。UIのほとんどは、意味合いが文脈に依存する単語や短文です。UIの翻訳は、実際にその機能を動かしながら、動作にあった訳語を割り当てていくべきです。
Google翻訳などを使って一括で、訳語を割り当てても良いUIの翻訳はできません。
（ UIにとっての良い訳については、元記事のいくやさんがとても良い話を書いています: https://github.com/ikunya/howtotranslatelibo/blob/master/howtotranslatelibo.md#ふさわしい翻訳の考え方 ）
次に、白に近かろうがリスクのあるものを入れることになるということです。Ubuntuの日本語化ローカライズであれば、すでに多くのユーザーが使用しているでしょうし、そういうものについてリスクのあるものを後から入れることになります。
そういったことを独断で黙ってやるというのは、歓迎されたものではありません。少なくとも、コミュニティに対して事前に方針を聞いたりすべきだったでしょう。
つまり、クオリティが低い上にリスクのあることを黙ってやったわけで、もちろん批判されるべきでしょう。
とはいえ、OSSには個々の事情があります。次は自分の場合の話をしてみます。
まずは質の話です。
自分のプロジェクトの場合、Google翻訳を使ったのはドキュメントです。日本語で書いたドキュメントをあたらしいGoogle翻訳に入れてみたところ、そこそこのクオリティの翻訳が出力されており、自分でゼロから翻訳するよりも、原文を翻訳しやすく修正したり結果に対して修正を加えていったほうが質と速さの両面でよいと判断したので、Google翻訳を使用しました。
次にリスクの話です。
OSSが企業に権利問題で訴訟されるということはめったにありません。OSSは公益性の高いものなので、むやみに訴えれば社会からの反感を買いますし、ほとんどの場合は訴えても大した金になりません。
訴えられるとすれば、そのOSSが十分に儲かっている場合です。もしOSSで大金が儲かったらGoogleから訴えられてしまう！どうしよう！と考えるのは、宝くじに当たったら強盗におそわれてしまう！どうしよう！と考えるのに似ています。
まず宝くじは当たらないですし、宝くじが当たったらそのお金で対策を行えば良いだけの話です。
実際Linuxでは、特許周りの対策としてOpen Invention Network(OIN)を設立しています。Linuxなどソフトウェアに対して特許を主張しないことに同意した企業から特許を買収して、そういった企業に対してロイヤルティー・フリーで許諾を行っている会社です。
これによって、Linux関連のソフトウェアに対して訴訟をしてきた、いわゆる「パテント・トロール」に対して訴訟をやり返すなどの対抗手段を得ているわけです。
権利問題で訴訟されたことによって失敗に終わったOSSというのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業にうんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます。
結局のところ、自分の場合はGoogle翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Googleも翻訳を改善するためのデータを得られます。
わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。
結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか？というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェアの翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。
質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります。
各OSSの翻訳者のコミュニティは機械翻訳の利用についてそのプロジェクトで使って良いかの方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合はコミュニティの方針を確認した上でやっていくしかないんだろうなあと思うところです。
2010年ごろにニコニコ動画上で有名になったしょぼんのアクションってゲームがあるんだけど今どうなってるのか調べてみた。
そうしたらとんでもないことになっていた。
結論から言えばあからさまに怪しいデベロッパーが二次配布のソースコードを使って
itunes.apple.com/jp/app/shobonnoakushon-orijinaru/id894330337?mt=8
www.gatobros.com/
play.google.com/store/apps/details?id=com.gorkaramirez.syobonactionhalloween
www.pipletas.com/syobon/syobon.html
デベロッパーは『Gorka Ramirez Olabarrieta』というらしい。 ドメインWhoisガード適応済みで情報漁れず。
で、サポートURLのページをよく見るとOpenSource扱いになっていた
Original Source. Ported by @jezng using Emscripten.
sourceforge.net/projects/opensyobon/
Mathew Velasquezと呼ばれる人物が作者に許可無くSourceForgeにアップロードしたようだ。
sourceforge.net/u/twoscomplement/profile/
で、SourceForgeのプロジェクト開設日が下記のとおりになっているが
Registered 2010-05-16
原作者のサイトにはもっと過去の時点でゲームが公開されている。下記のInternet Archiveのもの。
wayback.archive.org/web/20091223043445/http://www.geocities.jp/z_gundam_tanosii/home/Main.html
このSourceForgeのプロジェクト、再配布人が下記のライセンスで公開している。
www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#DoesTheGPLAllowMoney によると
としている。
SourceForgeに公開されているプロジェクトがGPLv2で公開されているので、どうやらスマホアプリとして登場したようだ。
が、まずこれ色々と問題がある
プロジェクトで配布されているソースコード内にはDXライブラリがそのまま含まれているが、規約を守っていない可能性が高い。
dxlib.o.oo7.jp/dxlicense.html より引用する。
<<ＤＸライブラリのライブラリファイルやソースコードの再配布について>>
ＤＸライブラリのライブラリファイル( 拡張子が lib や a のファイル )や、プログラムソースファイル( DxGraphics.cpp や DxLib.h などのファイル )を配布する場合は一部、全部問わず
クレジット表示は探した限り見つからなかった。検証ファイル:SyobonAction_v0.9_src.tar.gz
なお、作者のサイトに商用利用に関する規約が無いとはいえ、さすがに普通に連絡するべきではないだろうか？
（配布ソースコード内には改変可という言葉はあるが商用利用可とは書いていない。）
なお、実行ファイル形式で配布されている物の英語のReadMeには原作者のクレジットなし。
どうやらゲームファイルとソースコードが転載されたようだが、少々違和感がある。
Internet Archive内にあるソースコードとSourceForge内のソースコードが違う。
tiku氏のそのまま配布するなを遵守したのだろうか？ （配布されているソースコードには日本語が混じっているので非常に怪しいけど）
ただ、言えることはしょぼんのアクションがスマホアプリとして公開されたのはGPLv2辺りのライセンスになっていたからだということ。
ここまで書いておいてなんなんだけど飽きた。
「悪意を持ってこっそりライセンスを変更してユーザーを陥れる」
最初はMITやApacheみたいなゆるいライセンスにしたい。
Githubのスターも1000や2000を楽に超えてゆきたい。
そしてある日、ライセンスをGPLにする変更をいつものコミットの中にコッソリ入れたい。
それに気づかず更新してそのままストアに公開してるマヌケなアプリを探したい。
そして使用している証拠を保存してからソース公開を要求したい。
そして当然のように拒否されたい。
そしてまた当然のように棄却されたい。
最終的に日本におけるGPLライセンスは事実上無効となり、他国が必死にそれを順守している一方で日本の全てのプロパライエタリソフトは当然のようにGPLなコードを組み込むようになり、日本だけが全てのIT技術において独走する世の中となるという、そんな終わらない黄金時代を作った最も偉大な愛国者として名を刻みたい。
FSFのGPLソフトだって勝手にフォークして公開してプルレク受け付けられるよ (GPLでさえあれば。派生物に追加の著作者が増えてくだけ)。
それにGPL以外のOSSライセンスだって法的にbindingなライセンスには違いなかろう。(NO WARRANTY項目が有効かどうか、ってのはまだ議論があるんだっけ?)。あと、他者の特許および知的財産権を侵害してません、と一筆取っとくのは企業にとっては重要だね。FSFも場合によってはその文書も求めることがある。結局、本家が法的係争に備えて同意を集めておきたいとする点では同じでしょ。
http://www.demap.info/tetsudonow/
確認したところ、今年3月に開通した北陸新幹線が走っているので、今になってもデータはメンテナンスされているようである。
ところで、列車を走らせるにあたり時刻表データが必要なはずだが、そのデータはどこから入手しているのだろうか？
まさか日本全国およそ9000の駅に全て訪問し、時刻表を撮影してデータ化しているわけではあるまい。
誰でも思いつくのは、駅探・ジョルダン・NAVITIME・Yahoo乗換案内など、公共サービスに備わっている時刻表検索サービスを機械的に収集して時刻表を抽出する方法である。
確かにこの方法で日本全国のデータを網羅できる。しかし、このデータをもとにサービスを行ったり、商売を始めるのはNGである。
なぜなら、上記のサービスベンダーは「JR時刻表」と「JTB時刻表」の内容を交通新聞社およびJTBに許諾をもらって掲載している。
https://www.navitime.co.jp/pcstorage/html/help/etc01.html
上記リンク先にある「弘承平成14年82号」という記述は交通新聞社(旧弘済出版社)の承諾済みであること、「(J)02-7」という記述はJTBの承諾済みであるということである。
これが無いということは、少なくとも交通新聞社・JTBのいずれの承諾も得ていないということである。
無断転載でないとすれば、いったいどうやってデータを作ったのか？
=
「鉄道Nowは、時刻表データを直接売買しておらず、広告を掲載することによって間接的に金銭を得ているのだから問題ない」という意見もあるだろう。
確かにその通りかもしれない。
しかし、仮に無断転載禁止のデータをもとに作成したサービスで広告収入を得ているのだとしたら、それはいわゆる「アフィカス」なのではないか？
「時刻表の無断転載有無など誰も知らないから大丈夫」とタカを括られているのであれば、なおさら悪質な部類に入るのではないか？
ソースコードで言うならばGPL違反と同等かそれ以上の悪質さではないか？
私は別に鉄道Nowを潰したいのではなく、あれだけ注目されたサービスなのだから、権利関係について袖を正すこと提案しているのだ。
当たり前だが、時刻表だけがあってもあのサービスは提供できない。なかなか苦労して開発したはずである。
=
ところで、駅.lockyという、「日本全国およそ9000の駅に全て訪問し、時刻表を撮影してデータ化」を地で行くサービスが存在する。
このサービスを端的に表現するなら「時刻表版Wikipedia」である。時刻表データを作成しているのは有志である。
このデータは交通新聞社・JTBが作成したものではないため、駅.locky内で利用する限りにおいては交通新聞社・JTBの束縛を受けない。
ありがたいことに誰でも閲覧できる状態になっている。
しかしだからといって権利フリーではなく、有償、無償を問わず、再配布することは禁じられている。
http://eki.locky.jp/site/about
=
東京メトロが公開したオープンデータAPIでも、時刻表データが入手できる。
https://developer.tokyometroapp.jp/terms.html
=
線路に沿わせて列車を走らせる動きを再現するにあたり、線路形状データに国土地理院のデータを使っているのであれば、これも商用利用NGである。
http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-N05.html
=
回答をお待ちしております。
アサインされた案件のjqueryのバージョンが古すぎて死にたい
/* * jQuery JavaScript Library v1.3.2 * http://jquery.com/ * * Copyright (c) 2009 John Resig * Dual licensed under the MIT and GPL licenses. * http://docs.jquery.com/License * * Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009) * Revision: 6246 */
アサインされた案件のjqueryのバージョンが古すぎて死にたい
/* * jQuery JavaScript Library v1.3.2 * http://jquery.com/ * * Copyright (c) 2009 John Resig * Dual licensed under the MIT and GPL licenses. * http://docs.jquery.com/License * * Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009) * Revision: 6246 */
仕事でやる以上、金払ってライセンスと安心買うか、GPL避けるか
だと思う。
MIT LicenseやBSD License並にさっぱりした奴がわかりやすくて好きです。
http://anond.hatelabo.jp/20140722001658
上で意味不明なことを言ってるので指摘しておく。
こういう勘違いする奴が多いが、これはMySQLサーバーが、デュアルライセンスだから大丈夫だという話。
ちなみにMySQLのGPLはv2なので、そもそも間違ってるが、内容は対して変わらんので、細かい指摘は無し。
クライアントにある。
MySQLの接続は独自でドライバでも実装しない限り、limbysqlclient.soやそれをリンクしたConnectorを利用することになる。
・商用ライセンス
商用ラインセンスを選ばない場合、GPL(FOSS除外規定)になるが、これを選択した場合、お前らの納品物はGPL適用になる。
もしお前らの納品物に、プロプライエタリのライブラリとの結合があれば、その時点でライセンス違反だし、そもそも納品物を勝手にGPL適用してよいか確認して契約しないと完全にもめる。
これは、MySQLが許可したオープンソースライセンスを適用するならGPLv2にしなくても良いという例外規定だ。
許可一覧はこれ。
http://www.mysql.com/about/legal/licensing/foss-exception/
これはGPL汚染を防ぐための例外規定で、詳しくはここを読め。
http://nippondanji.blogspot.jp/2009/05/foss-license-exception.html
このおかげでPHPからMySQLを使ったりするのはセーフになってる。
だが、FOSS除外規定は、あくまでもMySQLが許可したオープンソースライセンスに限る。
お前らの納品物をオープンソースライセンスにするなら許す。という意味だ。
結局のところ、
プロプライエタリのライブラリとの結合があれば、ほぼ間違いなくライセンス違反だ。
それりなりの規模の案件でオープンソースライセンスなんか適用できない。
結局、納品物をプロプライエタリライセンスにするためには、お金を払う必要がある。
ユーザー企業のみなさん、糞Web屋は平気でオープンソースライセンスにして
安心ですと言い切るでしょうが、待ってください。あいつらは作り逃げしようとしてますよ。
http://anond.hatelabo.jp/20140722142248
そもそもFOSS除外規定で使えてるケースが多いのに、GPLで縛っちゃダメだろ。という無粋なアレは置いといて
今後絶対に、プロプライエタリなライブラリとリンクしない前提の
超小規模案件なら、ライセンシーの意図とは異なるが選択肢にはなるけど
webシステムでも絶対にソースコードが流出したらダメな場合はライセンスを買った方が良いです。
http://anond.hatelabo.jp/20140722001658
「Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの？ソースコードはこちら、みたいなの。ありえないよね？」
これは大丈夫です。
GPLではソフトウェアの配布時に関係してくるので関係ないです。
これはグレーです。
なんとも言えません。
というのが脅し文句。
ようするに「裁判でどういう判決が出るのか（俺は）分からないので、怖かったら買え」ということ。
でもよく考えるとMySQLが出て長い年月が経ってるのにそういう事例が無い（少なくとも俺は知らない）って時点でリスクなんて無いと思う。
でもいまだにwebシステムでも前者の勘違いをして買ってくれる人が意外に多い。
http://anond.hatelabo.jp/20140722034243
これはMySQLクライアントを利用してDBに接続する多くのwebシステムではグレー。
MySQLに同梱されているクライアントソフトを使わずに自前でクライアントを作って接続してる場合は確実にGPL汚染しない。
前述の通りグレー。わからない。
一端GPL汚染したバージョンが出回った後でライセンスを変更するのは不可能だけど、
次のバージョンからGPL汚染しないように作り直して、ライセンスを変更すれば、
http://anond.hatelabo.jp/20140722143245
個人的な考えでは、著作権者全員の合意がとれれば可能という結論。著作物をGPLに書かれた通りに扱ってよいとしただけで、著作権者によって著作物の扱い方は変更可能だという考えから。無論、GPLでライセンスされたプログラムを受け取った人はソースコードの請求は依然として可能。
それであってる。
かつてのGhostscriptが、当初GPLで開発→途中から商業利用制限のライセンス、ってパターン(但し、GPL版もメンテされ、先端のバージョンの機能が遅れて実装されていた。今は独自ライセンス版はなくなってGPLオンリーなのかな?)
有益な話だし、GPL関係でググってこのページを見た人のために勝手に補足と個人的な疑問を放流してみる。
適当に調べてた知識を記憶をたよりに書いているので、間違いがあれば容赦なく指摘して欲しい。
# どうでもいいけど、元増田の話でOSがLinuxだったりしたら笑うw
GPLは元増田で書かれている通りで、WEBシステムを閲覧しただけではソースコードを請求することはできない。RMSらもこれには気づいていて、この穴を塞ぐためにAGPLというライセンスができた。このライセンスのソフトウェアを利用した場合、WEBシステムであろうと利用できる人はソースコードの請求を行えるようになる。
これは別にWEBシステムに限らず、ユーザーが何らかの形で利用できるシステムなら、ソースコードの請求が行える。
申し訳ないが詳しい所は知識不足でよくわからない。だけど、下記の記事の通り現在の開発元のOracleの見解である。すなわち、MyODBC(GPLのMySQL用ODBCドライバ)を使わず、GPLでないドライバを用いて接続してしまえば、開発したソフトウェアがGPLにならない。
http://plaza.rakuten.co.jp/matsunopage/diary/201011300000/
# 個人的にGPLがRMSの著作権Hackなら、OracleのコレはGPL Crackだと思っている。「GPL汚染が嫌なら有償ライセンスで契約しろ」と言われた話を聞いた事があるからだ。
おそらく持ち帰れないのではないかと思う。なぜそう思うかというと、普通、プログラマが書いたコードの著作権は会社に取られるし、GPLでライセンスされたソフトウェアを受け取ったのは会社であってプログラマ個人ではない。GPLでライセンスされたソフトウェアを物理的にもっていく事は可能でも、きちんとライセンスを受けた訳ではないので機密情報の漏洩にしかならないと思う。
単純な興味なのだけど、例えば最初はGPLだったが途中からはプロプライエタリ(ないし、GPL非互換なライセンス)に変更可能なのか知りたい。個人的な考えでは、著作権者全員の合意がとれれば可能という結論。著作物をGPLに書かれた通りに扱ってよいとしただけで、著作権者によって著作物の扱い方は変更可能だという考えから。無論、GPLでライセンスされたプログラムを受け取った人はソースコードの請求は依然として可能。
http://nippondanji.blogspot.jp/2010/06/gpl.html
http://d.hatena.ne.jp/karasuyamatengu/20110126/1296004598
なんで、グレーなのか。なんで、無理なのか。どのような考えでグレー、無理という結論を出しているのかきちんと書いてもらえますか？ 私の考えが間違っているならなぜ間違っているか指摘していただけますか？ あるいは、下記の増田さんのように具体事例を出してもらえますか？ プロプライエタリに戻せないというのなら下記の具体事例はどのようにお考えですか？
http://anond.hatelabo.jp/20140722071548
とした場合に、PHPを飛び越えて(間接的にしか接続していないにも関わらず)開発したシステムにGPLが適用されるということですか？ その場合、PHPにもGPL汚染が発生するということになると思いますが、間違いありませんか？(FOSS除外規定を設けているのはMySQLであって、FOSS除外規定と無関係な開発したシステムがGPLになってしまうと、開発したシステム側からGPL汚染が発生するという考えから。)
元のパラグラフは下記の通りです。
あと、MySQLのデータベースサーバに接続しただけではGPL汚染は発生しません(AGPLはそのためのものなのは前述の通り)。また、PHPは接続するクライアントになりますよね。ということは、MySQLと一緒に開発システムを一つのパッケージとして納品しない限りはGPL汚染は発生しないのではないでしょうか？(WEBシステムでそんなこと普通しませんよね。yumとかでインストールするし)
根本的な問題として、FOSS除外規定はGPLソフトウェアと他のFLOSSをリンクする際の問題を解決する物であって、MySQLのデータベースサーバに接続する場合には関係のない話だと思います。おそらく、問題だとお考えなのは、PHPのドライバがOracle製のGPLプログラムをリンクしていたためPHPのドライバを利用すればそのような問題が発生するという事だと思います(さらに追記。この通り書かれていますね。よく読んでおらず、失礼いたしました)。現状、PHPライセンスとなっているMySQL Native Driverを利用すればそのような問題は発生しないはずです。
http://php.net/manual/ja/mysqlnd.overview.php
かりに、おっしゃる通り、開発システムもFOSS除外規定に含まれるFLOSSにしなければGPLになってしまうとした場合、それはMySQL独自の問題であり、他のFLOSSに一律で当てはまる問題ではないということでよいでしょうか？ なぜこのような質問をするかというとMongoDBが同じような問題を抱えているからです。下記のURLの通り、MongoDBのコアサーバはAGPLですが、ドライバにApache licenseを適用し、開発システムにAGPL感染が発生しないようにしています。
http://www.mongodb.jp/mongo/licence
上記の様なケースにも実用的に対応する為、（AGPLを採用しつつも）我々はあなた方の（MongoDBを利用する）クライアントアプリケーションは（MongoDBとは）別物扱いする事を約束します。これを円滑に行う為、mongodb.orgサポートのドライバー（あなたのアプリケーションとリンクする部分）はApache licnese（コピーレフト）の元公開します。
返信お待ちしております。
冒頭に書いた通り、間違いがあれば容赦なく指摘してください。
MySQLに限らないけど、「GPLは営利目的では使えない的な思い込み」は止めて欲しい。
先週、システム開発の提案で客先に行ってきた。
当方、30前半のSE。対応してくれた担当者は40代後半の情報システム部門の方。
提案したシステムの規模はそれほど大きくはなく、お客さんからもあまり予算はないと言われていたため、RDBMSに「MySQL」を使ったWebシステムを提案したところ、「それほど可用性は求めてないし、無料で使えるDBの方がいい」と言われた。
あぁ、商用ライセンスを購入すると勘違いしたんだな、と思ったので、「MySQLはGPLライセンスもあるので無料で使うことができますよ」と説明したところ、担当者の顔が険しくなった。
「GPLだとソースコードを公開しないといけないんだよ？たとえMySQLのソースコードを改変していなくても、MySQLを使ったソフトウェアであればソースコードを公開しないといけないし、それを企業で使おうとすると犯罪になるよ。」
「だからウチでは重要なシステムはOracleを使っているし、重要度が低いシステムPostgreSQLを使ってる。」
「たまたま提案先がウチだからいいものの、他の企業にそんな提案すると恥をかくし、あなたの会社の信用も堕ちる。」
いろいろ言われたけど、要約するとこんな感じ。
「確かにGPLだと他の誰かにMySQLを使ったソフトウェアを頒布する場合はソースコードも渡さないといけないですが、今回は御社に導入するWebシステムですから問題ないですよ」
とは返したものの、
「Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの？ソースコードはこちら、みたいなの。ありえないよね？」
「システムを使った社員がソースコードを持って帰って公開したらどうなるの？機密情報の流出だよ。」
と捲し立てられてしまった。
心の中では「Webシステムだと利用者全員にソースコード公開とか、なわけねーだろ」と思いつつも、相手の勢いがスゴいし反論するための明確な情報を持っていなかったので一旦持ち帰って再検討することになりました。
http://www.ipa.go.jp/files/000028332.html
英語が苦手なのでIPAが公開しているGPLv3の日本語訳で確認したところ、「0. 定義」の項目に以下の文言があった。
著作物の「コンベイ」（convey)とは，プロパゲートに当たる行為のうち第三者が複製すること又は複製物を受領することを可能にする行為をいう。ただし，コンピュータネットワーク上での単なるやりとりであって複製物の伝送を伴わない場合は，コンベイに当たらない。
そりゃそうだよね。てかWebシステム利用者にソースコードを公開しないといけないとか誰が言い出したんだよ。
で、結局提案はPostgreSQLに変更しました。ライセンス云々関係なくPostgreSQLに統一されているんだったら運用コスト面でその方がいいし、MySQLを提案したのは俺がPostgreSQLより得意だからってだけだから。
ライセンスについては調べたことを担当者に伝えるかどうか思案中…。
ここまで捲し立てられたのは初めてだったけど、今までもお客さんから「GPLだけど商用ダメなんじゃないの？」って言われたことが多いんだよね。
もう一度言うが
https://www.gnu.org/licenses/gpl-faq.ja.html
GPLのプログラムをプロプライエタリのシステム・ライブラリとリンクしてよいでしょうか? (#SystemLibraryException)
GPLの両方のバージョンがコピーレフトに対する例外を有しています。一般にシステムライブラリ例外と呼ばれるものです。使いたいGPLと両立しないライブラリがこのシステムライブラリの範疇にある場合、これを使うのになにか特別のことは必要ありません。たとえこのライブラリを含むリンクされた実行形式を配布したとしても、全体のプログラムのソースコードを配布する要求にはこのライブラリは含まれません。
「システムライブラリ」になにがあたるかという範疇はGPLの異なるバージョン間で異なります。GPLv3は「システムライブラリ」を第一節で明確に定義して、「対応するソース」の定義から除外しています。GPLv2では第3節の終わり近くで少し違ったやり方でこの問題を扱っています。
というかこの例外事項がなったから おっしゃっているApacheライセンスなんかも成り立たないものが殆どになる。
ヘッダに書かれているライセンス条項や、リンクされるシステムライブラリは、それ自体を改変しない限りは、GNUライセンスは及ばない。というかそうでなかったら意味が無い。
MikuMikuPenguinというMikuMikuDanceのクローンソフト？ があるらしい
MMDはソースコードは公開されてないが、MMPはオープンソースらしい。で、開発者はアメリカ人。
詳しくはググって欲しいんだが、私はこれに関してなんか妙な違和感を覚えてる。とくにいわゆるMMDerの反応に。
あ、ちなみに私はMMDerじゃないけどMMDの動画を見るのは好きだし、第12回MMD杯はすげー楽しみにしてる、OSSにもちょっと関わりのある人間なんで、そういう目線で書くことになるかも？ わかんない。
何が違和感を覚えるかって、うまく言えないんやけど、「お前はお前でMMDを自由にしてあげたいんやな？ おk。俺はお前のやり方は気に食わないが、まあ文句は言わん。俺の迷惑にならん程度にやればええ。俺もお前の迷惑にならん程度に動画作るから」って感じで、俺は俺、お前はお前って感じで、さくっと割り切れないのかなぁって。まあ私もこういうの書いてる時点で割り切れてないけど。けど、なんやろ、やりすぎなんじゃないかなって、思うんだよね。MMPのニコニコ大百科見ててそう思った。
たしかに、「自由にしてあげる」って言い方は気に食わないのはわかる。自由ってめんどいし、場合によっては危ない。モデルを勝手に配布されちゃった経緯もあって、警戒するのはわかる。
けどこれって、モデルを配布するとかやなくて、単にアプリケーション作るだけでしょ？
オープンソースだからいやなの？ だったらMMDAIはどうなるの？
それともGPLが嫌い？ 嫌いなら使わなければいいじゃん。もう使いやすいMMDクローンソフトは存在してる。MikuMikuMovingとか。
それとも、作者の言い分が嫌い？ まあ、動画とか小説とかその辺って、作者の人格とその人の作品は分けて考えんと辛いよね。。。
私は両方好きだからさ。MMDを取り巻くあれこれも、OSSの考え方の一部も。
だから、なんかうまく丸くまとまらんかなぁって、そう思っちゃう。
いちいち新しいものをボコボコにしてたら、育つものも育たない、第二第三の樋口Mさんみたいなプログラマは育たないんじゃないかなって、そう思っちゃうのでした。
認めるのも自由、認めたくないのも自由。けどなんか、もっと仲良くするなり放っておくなりして、上手く回せたらもっと楽しいんじゃないかなって。辛い思いしてMMDやオープンソースの世界から去る人が減れば、なんか幸せな気がしてる。
