Open Dataというのがどのような定義になっているのか知らなかったので、教えてもらったところ、下記のスライドが分かりやすい。 20140725 オープンデータ化の価値 from Tomoaki Watanabe その8ページ目に各種openの定義が載っている。「オープン」の定義 参照先： Open Definition (OKF系、データ用) http://opendefinition.org/od/ Definition of Free Cultural Works(Wikimedia系、コンテンツ用) http://freedomdefined.org/ Open Source Definition (OSI系、ソフトウェア用) http://opensource.org/osd Free Software Definition (FSF系、ソフトウェア用) https://www
The Cathedral and the Bazaar: Japanese山形浩生 YAMAGATA Hiroo 訳 の「伽藍」をすべて「大聖堂」に置換してみた。（やっちゃいました） 伽藍とバザールの「伽藍」ってなんだろう。 - 未来のいつか/hyoshiokの日記 概要 この論文ではまず、大成功したフリーソフト/オープンソースプロジェクト fetchmail を分析する。このソフトは、Linux の歴史から導かれる、ソフト工学についての意外な理論を試すという意図で実施されたプロジェクトである。本論ではその理論を、二種類の根本的にちがった開発スタイルという形で論じている。一つは FSF やそのまねっ子たちの「大聖堂」モデルで、それに対するのが Linux 界の「バザール」モデルだ。この2つのモデルが、ソフトのデバッグ作業の性質に関する、正反対の前提からそれぞれ生じていることを示す。続いて
ハッカーズ、Hackers、スティーブン・レビー著、再読 - 未来のいつか/hyoshiokの日記で読んだハッカー達は、主に1960年代から70年代くらいまでの人たちだ。MITのテック鉄道模型クラブの連中とか、PC革命を引っ張っていった西海岸のハードウェアおたく達だ。 そして、70年代にソフトウェア産業が生まれ、ハッカー達がどんどん新興のベンダーに参加して、MITの研究所にあったようなコンピュータ好きというだけで生きていけたユートピアは消えた。 スティーブン・レビーは、ハッカーズのエピローグ「真正ハッカーの終焉」でリチャード・ストールマンが最後のハッカーとして孤軍奮闘している姿を描いている。AI研究所にいた多くのハッカー達がビジネスの世界に旅立っていったときに、彼だけが、最後までハッカー倫理を実現することを夢見て勝ち目のない戦いをしている。その悲観的な未来像でハッカーズは終わっている。80
先日文明塾の修了生のみなさまとお話したときのこと(コミュニティとしての大学 - 未来のいつか/hyoshiokの日記参照)。ハッカー文化とかオープンソースのことをあれやこれやお話したのだけど、その中で現役の学生さんから「ゼミでIT係を担ってからよくソースコードを何気なく閲覧してしいました。しかし、自由にソースコードが見れる環境が衝撃的で素晴らしいことであることに吉岡さんのお話を聞いて学ばせていただきました。」という感想をいただいた。 そうだ。すっかり忘れていた。オープンソースが当たり前じゃない時代があった。とてつもない衝撃を受けた自分がいたことをすっかり忘れていた。 1998年1月。Netscapeが自社のブラウザのソースコードを公開するということを発表した。当時のシリコンバレー日記にそのことを書いている。http://web.archive.org/web/19990423102903/
Microsoftの中の人で、OSSとWeb技術を推進するScott Hanselmanが書いたブログ記事 "Open Source is a thankless job. We do it anyway." を勝手に翻訳。 オープンソースは難しい。 セキュリティは難しい OpenSSLの最近の "Heartbleed" バグに関する記事がたくさん出回っている。技術的な分析をすべて読んだら丸一日つぶれてしまうだろうが、 その中にこれはと思う見出しがあった。『OpenSSLはオープンソースの大きな問題を示している。資金不足、人員不足』だ。インターネットを織りなす基本の部分は、ほとんどの場合たった一人によるもので、あとはたくさんのボランティアだ。 〝魅惑的で気が遠くなるような事実とは、ネットワークインフラストラクチャにはこのように重大な部品が存在していて、インターネットの大部分で実際に動いてい
Apache License, Version 2.0を読むの続き。 http://d.hatena.ne.jp/hyoshiok/20131224#p1 http://www.apache.org/licenses/LICENSE-2.0 Apache License, Version 2.0には下記のように特許条項というのがある。 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) p
先日、MIT licenseを読んだので、ついでにApache licenseもいってみよー。*1 http://www.apache.org/licenses/LICENSE-2.0 まづ全体の構成だ。 最初に"Apache License, Version 2.0, January 2004" のコピーライト宣言とURLがある。そして、TERMS AND CONDITIONSが全部で9項目ある。そして付録にApache Licenseを自分のソフトウェアに適応する場合の例がある。 TERMS AND CONDITIONSは下記からなる。 Definition Grant of Copyright License Grant of Patent License Redistribution Submission of Contribution Trademarks Disclaimer
MIT licenseはシンプルだ。3段落しかない。 最初の段落で、何を認めるか(grant)を述べている。2番目の段落で、どのような条件の時、上記の許可(permission)を与えるか、そして3段落目は無保証ということを宣言している。 ソフトウェアは著作権で保護されているので、第三者が勝手にコピーしたり、変更したり、何かにそのまま含めたり、出版したり、再配布したり、サブライセンスしたり、販売したりはできない。 そこでMITライセンスは、著作権者が自分の著作物に対して、第三者が上記のことをすることを許可している。"Permission is hereby granted" このライセンスは契約なのか、著作権の権利の不行使の宣言なのかという法律上の論争があるがここではそれに踏み込まない。 The MIT License (MIT) Copyright (c) Permission is h
コミュニティを形成するためにコピーレフトのライセンスが必要か？10年前の回答はおそらく「はい」だった。プロジェクトに貢献することを契約義務によって担保しているからだ。しかしながら、その質問を現在してみると、活気に満ち、活動的なコミュニティがパミッシブなライセンスモデルで作られるようにオープンソースが成長して来た。ライセンスモデルがどのようにオープンソースコミュニティに影響を与えているか、そしてそれがいかに進化して行ったかを解説する。 Do you need a copyleft license to build a community? Answering this ten years ago, the answer may have been yes, primarily driven by the contractual obligation to contribute back to
写真1●楽天テクノロジーカンファレンスでソースコード公開を発表するROMAの開発者 西澤無我氏（左）と、Rubyの開発者で楽天技術研究所フェローのまつもとゆきひろ氏（右） 楽天は2009年10月24日、同社が独自開発した分散キー・バリュー型データストア「ROMA」をオープンソース・ソフトウエアとして公開した。ROMAはスケールアウトが容易で、耐障害性の高いデータストア。「楽天市場」と「楽天トラベル」で、ユーザーによる閲覧履歴の保存にROMAを使用している。同日に開催した「楽天テクノロジーカンファレンス」に合わせて、「github」でソースコードを公開した。 ROMAは、楽天技術研究所フェローのまつもとゆきひろ氏（プログラミング言語「Ruby」の開発者）と協力して、2007年から開発してきた分散キー・バリュー型データストアである（写真1）。Rubyを使った大規模システムを実現するための分散処
どうして部屋を片付けたくなるのだろうか 来週に締切を控えているせいで片付けが進む。整理をしていたら、株式会社ネットスプリングの西武さんに頼まれて寄稿した同社の NSQuest という冊子 が発見された。記事は 2007年2月頃に発刊された Vol.1 と Vol.2 に分かれて掲載されている。ちなみに表題は自分で付けたものではない。 改めて読み返してみても考え方に変化はないが、1985-1995 頃の10年間というのは、シグマプロジェクトのおかげかそうでないのか、皮肉にも日本で UNIX エンジニアが最も増えた時期と重なっているとも思う。最後の部分は Google Code とかで解決する方向に進んでいるのだろうか? だとすれば次の課題は、部屋を片付けずに原稿を書く方法を考えることだ。 オープンソース文化考察 1993年の12月、情報処理学会の九州支部シンポジウムに呼ばれて「Unix オペ
自前主義というか、車輪の再発明というか、おれがおれがというか、そーゆー行動スタイルをNIH (Not Invented Here Syndrome)症候群と呼ぶ。 独自で作ったばりばりのソフトウェアなんてオープンソースにして公開したところで誰も使わないし、使ったとしても誰も改良してくれないし、従ってバザール開発にもならないにも関わらず何を勘違いしたかオープンソースにして、閑古鳥がなくなんてことがあるのかないのか知らないが、企業がオープンソースに関わろうとするなら、いきなり敷居の高い独自ソフトのオープンソース化なんてことはやめておいて、既存のOSSプロジェクトにおずおずと参加させてもらうというような方法がいいと思う。（もちろんわたしの個人的な意見であることは論をまたないけど） 個人の場合は、趣味で好きでやっているんで、どうでもいいのだけど、好きなものを好きに作って、自分の情熱の赴くままに作っ
セキュリティ＆プログラミングキャンプ2009のわたしの講義で、「オープンソースにすると企業は損をするんじゃないですか」という本質をとらえた質問がでて、講師陣が、いきなりいろいろ議論を始めた。 企業の行動原理は、利益の追求だから、利益を生まないアクティビティは原則として行わない。オープンソースも例外ではない。 利益＝売上-経費 なので売上が増えるか、経費が減るかという観点から投資判断をする。当たり前ですな。 例えばマイクロソフトが自社の製品をオープンソースにすると、売上が伸びるか、あるいは経費が減るかというと、どちらもそうとは言えないので、マイクロソフトが自社製品をオープンソース化することは考えられない。先日マイクロソフトがHyper-V向けのLinuxドライバをGPLで公開したことが話題になったが、Linuxドライバを公開する事が自社のHyper-Vの魅力を増し、売上向上を期待して公開した
Development, Translation, daily life, thoughts, and so on. http://www.oreilly.co.jp/books/9784873114125/ 前にもちらっと書いたのだけれども、僕と高木さんが全文の翻訳を手掛けた Producing Open Source Software の日本語版が、オライリー・ジャパンより今月の25日に出版されることになった。邦題は左のカバー画像にもある通り、「オープンソースソフトウェアの育て方」である。 内容をひとことで言えば、この本は オープンソースプロジェクト に働く力学と運営ノウハウを教えるものである。この本は全文がオープンソースとしてオンラインで公開されている(※1）ので、無料で読むことができる。よってまずはオンライン版を参照頂き、気に入ったら購入して頂ければ幸いである。 出版される内容は、
2009年07月26日18:00 カテゴリ書評/画評/品評Open Source 関係者必読! - 書評 - オープンソースの育て方 こちらもまたオライリー矢野様より定期便にて献本御礼。 オープンソースの育て方 Karl Fogel / 高木正弘/ 高岡芳成訳 [原著:Producing Open Source Software] 素晴らしい。脱帽。 理論に関しても、実践に関しても、オープンソースに関してこれ以上書かれているものは現時点で存在しない。オープンソースという言葉から利益を得ている人は必読。 本書を買わなくてもいいから。 そう。本書は原著のみならず、訳文も全文が CreativeCommons Attribution-ShareAlike (3.0) で公開されているのだ。 Producing Open Source Software オープンソースソフトウェアの育て方 本書「オ
2009/07/21 登場からわずか5年。Webアプリケーション開発のあり方を根底から変えてしまったと言われるWeb開発フレームワークの「Ruby on Rails」。なぜ5年という短期間で普及し、今なお驚異的スピードで進化を続けているのか。7月17日から3日間の予定で東京で行われたイベント「RubyKaigi 2009」の初日に講演したフリーランスのRails開発者、松田明氏は、自身のRails開発とコミュニティ参加の経験から“Railsという現象”についての考察を披露した。 開発者とユーザーの間にある「超えられない壁」 「Railsエコシステムの研究」と題した講演で松田氏が指摘するのは、Rails開発コミュニティの特異性だ。一般的なOSSコミュニティは中心にリーダー的存在と、少数のコア開発者がいて、それ以外の「ユーザー」は、開発者グループに容易に入っていくことができない。 「私はApa
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 注目される3勉強会合同で開催された「メインライン化記念勉強会」 「TOMOYO Linuxメインライン化記念勉強会」が7月3日、東京・恵比寿の日本SGIで開催された。 TOMOYO Linuxは、NTTデータが開発したLinuxのセキュアモジュールとして、Linux標準カーネル（メインライン）の「version 2.6.30」に採用され、6月10日にリリースされた。これを記念して企画された勉強会は開催前から多くの関係者の間で注目を集め、当日はTOMOYOのプロジェクトメンバーと知己の人々も含め、120名を越える参加者が会場に集まった。 今回、この勉強会が話題となった背景には、セキュリティやLinuxの分野でその活動が注目されている3つの
札幌オープンソースセミナーへ参加してきました 2009-07-11 世の中言ってみるもんだなぁと思いました 約２ヶ月程前の会議で、プライスウォーターハウスクーパースコンサルタント株式会社の偉い方とお話する機会 がありました。その時にOSS、Unix、Linux関連した業務説明時に、どのような情報を参考にしたのかということ で、最近読んだDebugHacksや2年くらい前に情報収集のためにミラクルリナックスの吉岡さんのblogの内容が良い 情報であり、自分の学習や仕事に役立ったという内容の話をしました。 偉い方は、吉岡さんとお知り合いだと言っておられましたので、ものは試しだということでもし会えるならお 願いしますと言ってみました。それから約2ヶ月後の7月11日に本当に札幌オープンソースセミナーという形で 実現してしまいました。プライスウォーターハウスクーパースコンサルタント株式会社の偉い方も
村田さんがニコニコ動画に札幌オープンソースセミナーの映像をアップしてくれた。ありがとう。 Sapporo Open SeminarView more presentations from Hiro Yoshioka. 墓参りをした。
ミラクルリナックスの吉岡さん（id:hyoshiok)が札幌で話すと聞いて参加してきました。開催の経緯とかは吉岡さんのエントリーに書いてあるので割愛。 内容としてはかつてのITベンダーの構造や吉岡さんの若い頃の話に始まり、今のIT技術者がどうオープンソースやコミュニティと向き合っていくべきか、といった内容でした。 オープンソース時代のエンジニアのあり方 かつては垂直統合型というビジネスモデルで企業が成り立っていた為、社内にて必要な技術もコミュニティも全てあったとの話です。しかし、現代では垂直統合型で生き残っている企業は少なく、ある分野に特化しているなど社内で全てをまかなえません。その代わりインターネットなどを使えば、誰でも何処ででも情報を入手でき、コミュニティにも参加できる時代になったわけです。 そんな時代のエンジニアとしては、特に言語化された情報はGoogleの検索でもすれば誰でも簡単に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く