  |
はてなキーワード: GNUとは
また、プライバシーの問題に強い意識を抱いていることでも知られている。
さらに、「個人的な理由」から、GNUやFSFの自分のページかそれに関連するページ以外は自分のコンピューターから直接ブラウズすることはないと述べている。
そして、その代わりとして、wgetを動かしているサーバーにメールを送り、見たいページをメールで送らせるという方法を用いているという。
プロキシーサーバーを建てて、（スクリプトを殺した状態で）閲覧／解読すれば安全ですね？
新しい連合型SNS「Pleroma」はMastodonを置き換える？
ラズパイで動くほど軽いというのが特徴。
http://www.itmedia.co.jp/news/articles/1711/12/news018.html
Elixirで書かれたOStatus互換のSNSでGNU socialおよびMastodonと互換性がある
内部的には最初からActivityPubで、外部との通信もActivityPubにする計画
Raspberry Piでも動作する軽量性と高いパフォーマンス
Mastodon用モバイルクライアントのいくつかで動作する（Twidere、Tusky、Pawoo、Subway Tooter、Amaroq、Tootdon）
もう作られつつある。
日本国内に限れば、mstdn.jp と pawoo.net が2大インスタンスで、
ここがトラフィックに掛かる費用を負担し続けている限り、わりと長期に続きそうな気がする。
企業だけでの費用負担が難しくなって、インスタンス内外ユーザからの課金で賄うモデルへ移行する可能性もありそう。
インスタンスが大きくなりすぎると、トラフィックの問題で潰れるという教訓をもとに、
GNU socialのBitTorrentバージョンみたいなアプリを誰かが作って一気に普及する…のもありそう。
こういうことをmastodonでtootせずに増田で書くというのもmastodonに対する距離感が出てるようで何なのだけど。
mastodonがそのまんまTwitterに取って代わる未来というのは「ちょっとないなあ」と思う。
その一方で、これが3年後に「あれ、なんだったんだろ？」みたいに消えてしまう未来も考えにくい。
じゃあどうなるのか。上記2つも含めて複数の予想。
A. Twitterの没落で、その後をmastodonが占める。
技術系とエロ系の人々がmastodonに流れる。両方兼ねてるひと？
C. 発展的解消。
「え、まだmastodon？」みたいに。
ブラウザの変遷とか、そんな感じかな。システムとアプリではだいぶ違うけど。
この場合、GNU socialのプロトコルが生き残るのかな。
Cに似てるけど、既存のSNSを超えてもっと完全にちがったコミュニケーションツールが現れる。そのベース技術となって、mastodonそのものは消滅。
E. 一時の流行
セカンドライフみたいに一気に盛り上がって、そのまましぼむ。
ま、そういう例は少なくないので。
さて、どうなるんだろ。
現実は、常に予想を超えるんだけど。
あぁ、これは流行らないなと思った。
ASCII.jp：Twitterのライバル？ 実は、新しい「マストドン」（Mastodon）とは！｜遠藤諭のプログラミング＋日記
記事をまとめると、Mastdonの特徴は次の4つに集約されると思う。
・ほぼTwitter
・サーバーの分散化によるリスク回避（中央集権体制に対するアンチテーゼ）
いうなれば、Windowsに対するLinux郡の構図である。
だが、いまだかつてWindowsより流行ったLinuxなど存在しない。
人類の歴史は、中央集権→革命→群雄割拠→中央集権→革命を繰り返すことで進歩してきた。
Twitterという中央集権に対するアンチテーゼたるMastdon、ないしGNU Socialは「革命→群雄割拠」に当たる。
しかし、Mastdonに「革命→群雄割拠」を起こし、Twitterに取って代わる素晴らしい特徴があるかと言われれば無いだろう。
OSS化されただけのTwitterのクローンである以上、結局Windowsに取っては変わらないLinux同様、Twitterに勝つことは出来ないと思う。
また、群雄割拠の先には新たな中央集権体制があることも忘れてはいけない。
Windowsという中央集権のアンチテーゼであるLinuxは現状どうなったかと言えば、
ほぼUbuntuとAndroidに集約されたと行って過言でない。
UbuntuとAndroidは明確に用途が異なるから交わることはないけども、群雄割拠の末にたどり着いた中央集権の構図である。
同様に鯖とか研究用とか用途ごとにディストリビューションはあれどとりあえず集約されている。
Mastdonも、最終的にはLinux群と同様に集約されるだろう。
おそらく、".cloud"（＋".jp"）しか残らない。だってLinuxのディストリビューション以上に差がないもん。
集約された時点で、「サーバーの分散化によるリスク回避」という特徴が死ぬ。
じゃあどうすればいいのって話だけど、
＝鯖ごとにアカウント作る必要あり、鯖ごとに切り替えて投稿する必要あり
→ .cloudへの集約による中央集権化
→ 特徴が死ぬ
↓
↓
→ 面白そうだけど、なんかアレ感がある
つまり、
・サーバーの分散化によるリスク回避（中央集権体制に対するアンチテーゼ） → 意味がない
・テーマごとにサーバーを変えることも出来る → Google+の二の舞い
うーん…OSS大好きおじさん(老害)しか残らない未来しか見えないなぁ…
とりあえず誰かﾏｽﾀﾞﾄﾞﾝ鯖早く立てればいいんじゃないの
全く役にたたなくてもいい。
ただの自己満足なんだけど、フフフ///ってなるコンピュータ技術（用語・名称）のトリビアが知りたい。
諸説あってもいい。誰か、URL貼り付けるだけでもいいから教えて欲しい。
例えばこんな感じ）
GNU → "GNU's Not Unix!"（「GNUはUNIXではない」）の再帰的頭字語
boot → 「pull oneself up by one's own bootstraps」
MySQL → 共同創設者 Monty Widenius の娘の名前にちなんでいる
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
免責： これは法律の専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。
「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辺りのライセンスになっていたからだということ。
ここまで書いておいてなんなんだけど飽きた。
GitHubの謎生物が気になり、せっかくなのでIT界隈の動物(?)を用いた名前やロゴの由来など調べてみた。
※追記あり：Gopherファンに襲われそうなので。ごめんねGopher君
Q.どうしてタコなのに8本足じゃないの？
A.なにも考えずに描いたからね！
もともとデザイナーはoctopussと呼んでいたが、いくら訂正してもGitHubの社員がoctocatと呼ぶため、octocatで落ち着いた。
octocatはあの生物種の名称であり、monalisaという名前は社員の娘が学校の課題で名付けたもの。
種類：ニシキヘビ
名前： -
イギリスのコメディ番組『空飛ぶモンティ・パイソン』より。
またPythonという英単語はニシキヘビを意味するため、マスコットとしてヘビが用いられる。
オライリーの本とかすごい表紙だよね。
種類：ゾウ
種類：ゾウ
名前：slonik
「動物のロゴにしたいなら、象なんてどうだい？アガサ・クリスティの小説にもある『象は忘れない』だ」
― PostgreSQL発足時のメーリスより
種類：ゾウ
名前： -
象は記憶力が非常に優れた動物のため。PostgreSQLと同じで、象の優れた能力にあやかっている。
種類：ヌー
名前： -
種類：キツネ
名前： -
もともとPhoenixという名前だったが、商標権を侵害していたので、公募でFirebirdという名前に決定。
しかし今度はDBに同じ名前があったので、Firefox（レッサーパンダの別名）に改名。
みなさん命名は慎重に。
種類：クジラ
『白鯨（Moby-Dick）』より。クジラを採用した理由はデザイン見れば納得。
種類：ペンギン
名前はタキシード（Tuxedo）を着ているように見えるから。
ロゴコンテストで決定されたが、他の作品を見ればなぜ選ばれたのかよくわかる。デザインって大事。
https://www.cs.earlham.edu/~jeremiah/linux-pix/linux-logo.html
種類：鳥
名前：ラリー・バード
名前はNBAのラリー・バード選手より。社員がファンだったらしい
ちなみに初期のTwitterのデザインはGitHubのデザイナーが手掛けたもの。すごいっすね。
種類：シーサー
名前： -
種類：イルカ
名前：Sakila
種類：ネコ
名前： -
オライリーの本に載ることを考慮して動物をマスコットにしようと考え、「自立した強かさ」を持つという意味でTomcat（雄猫の愛称）を採用。
しかし、猫はオライリーのUML本で使われてしまい、念願のTomcat本にはユキヒョウが使われたという…。
種類：Dogcow（イヌ＋ウシ）
名前：Clarus
昔々、Mac OSで用紙の向きや色を表示するために使用されていたらしい。
知らんわ。
種類：ウサギ
名前：Glenda
OSの名前である「Plan 9～」はエド・ウッドの『Plan 9 from Outer Space』に由来。
ウサギの名前であるGlendaはエド・ウッドの『グレンとグレンダ』に由来。
どんだけエド・ウッド好きなんだよ。
ニュージャージーのWFMUラジオで、Renee Frenchによって宣伝用のTシャツに描かれたのが、彼の初登場。
その後、Bell labsのメールシステムでアバターとして起用もされた。
(ちなみにReneeはBell labsのGlendaを描いた人。Glendaもアバターの一員だった)
そうして2009年、Goプロジェクトが発足し、ロゴを検討していたメンバーにReneeが無償で描いてあげたのが「Go gopher」である。
みんなGo Gopherと呼ぶので、特に固有の名前は無いらしい。
由来は下記サイトにありました。
https://blog.golang.org/gopher
http://togetter.com/li/1020412
マジで消えねーかな、こういう輩。
バカがGNU GPLに噛み付いてる「よくあるやつ」以前の程度の低い内容を自分でまとめてる無様さもさることながら、このタイトル。
フリーソフトって書くんじゃねーよスカタン。無料ソフトウェアじゃねーんだよ、GIMPはよぉー。
でもこういう輩に「自由ソフトって書け」って言っても伝わらないだろうし、消えてくんねーかなー。
次に消えてほしいのが自由ソフトウェアをフリーソフトウェアって書くやつな。てめーらも同罪だよ。
なんのためにGNUがあちこちに「ビール飲み放題ではなく言論の自由」って書いてると思ってんの？
わざわざフリーソフトウェアってカタカナで書いて意味を曖昧にしてんじゃねーよ。
「自由ソフトウェア」でいいじゃねーか。ここにも載ってるし。https://www.gnu.org/philosophy/fs-translations.ja.html
こんな優れた訳語があるのに、なんで無料という意味にとられかねないフリー（free）の語を使うのか。
特に自由ソフト依存症の雑誌ライター共な。てめーらがフリーフリー言ってるからいつまでも自由って意味が伝わんねーんだよノミどもがよ。
慣れ以上の理由が無いならさっさと「フリーソフトウェア」と呼ぶのを止めろ。もしくはライター辞めちまえ。
自由ソフトウェアなら自由ソフトや自由ウェアと省略されても、無料ソフトウェアって意味にはならない。明確な利があるじゃねーか。
