して取出すことができる。した場合、次のような処理になるでしょう。false}泥臭いですねwあとは関数(メソッド)化するなり色々書き方はありますが、数学的なアプローチをかけない場合、突き詰めれば上記のようなロジックになるかと思います。これだと著作物として主張できない。厳密にいうと主張はできるが、それって誰もが思いつきますよね?仮にゼロから書いていたとしてもみんなここにたどり着きますよね?という質問に反論できなければならない。おいおい、それってどこだよ...。一度世に出した物はパクられる覚悟をその後悪戦苦闘の末に何とか書面にまとめ、相手方に弁護士名義で内容証明を送付。示談へと話は進行するのですが、その頃にはすでに相手システムがリニューアルされているという事態になったりとまたややこしい感じになるのですが、これ以降はデリケートな部分も含みますので、お話はここまでとしておきます。勉強になったのは、著作権で守られているのは「表現」の部分だということですね。「料理のレシピ」は著作権の保護になりにくいとされているそうです。レシピは表現ではなく、実現するための手段というか方法であって「表現」ではないからという論理のようです。感情的にはそんなバカなって思いもありますが、逆に権利で縛ってしまうと例えばカツ丼を食べるためには毎回遠く離れた特定地域に行かなければならないといった問題も発生するんだと思います。これはプログラムも同様ですね。著作物しとして主張したら、C言語使えなくなっちゃいます。話はつきませんが最後にこの出来事から得られた教訓をまとめて終わりにしたいと思います。一度世に出した物はパクられる覚悟を仮にコピペされなかったとしても、お金と時間があればサービスを複製することはいくらでもできます。パクられることを防止する、もしくは報復することにこだわって貴重な自社のリソースを消費するくらいなら、別のことで勝つ方法を考えた方が有意義と言えるかもしれません。その瞬間はハラワタが煮えくり返っても、結果的にサービスで勝てばいいのです。オープンソースとして公開するどうせパクられるなら、自社のフレームワークやソフトウェアを公開してはどうでしょう?もし本当に価値のある物であれば、それが縁で優秀なエンジニアを獲得できるかもしれません。エンジニアがいれば、いくらでも素晴らしいサービスの開発に着手できます。コアな部分はサーバに持たせる当たり前ではありますが、本当に公開しなくない物の場合はサーバサイドに置きましょう。オープンに出来るもの、出来ないものの仕分けは本当に重要です。DeNAもサーバサイドのフレームワークを公開してはいますが、例えばゲームロジックなどはもちろん公開していません。ここがサービス(ビジネス)の根幹とも言える部分だからです。