2010年の日本OSS奨励賞をいただきました

IPAが毎年行っている日本OSS貢献者賞／奨励賞というやつがあり、今年その奨励賞を受賞しました。

受賞理由は、簡単に言うと「コミュニティ活動や勉強会への学生の参加、情報発信を頑張った」ということで、2009年中に電設部のつかだとして勉強会に参加＆自分で開催＆周りの学生をたくさん誘致したのがよかったね！ということみたいです。情報発信は、ブログとか@ITとかでわいわい書いてました。あとは勉強会で登壇したりとか。中学生から大学生まで揃ってOSCで勉強会に
関するセミナーしてみたりとか。発表したものはSlideShareにタメてみたりとか。

でも、勉強会に参加して学生層／若い層に輪を広げたことが評価されるというなら、それの原動力になった各勉強会の運営者（「この勉強会に友達連れてきたい！」と思っちゃうような場をたくさんいただきました。それに、「参加したらブログに書いて恩返し」ということも学びました）や参加者のみなさん（「この人に会わせたい！」と思う魅力的な人ばかりでした）、電設部やかまってくれた学生のみんなが居たからこその結果なので、去年関わっていただいた全ての方に心から感謝です。全員で受賞した気持ちです。受賞を知ったとき、そう思いました。たくさんの方（数えきれないのでここで列挙はできない）に直接会ってお礼を言いたいです。どうもありがとうございました。

というわけで、今年ももちろん勉強会に参加したり開催したりしておりますし、今はSetucoCMSの開発に注力しております。SetucoCMSも、現在電設部の現役学生と私のようなOBでやっておりますが、学生と一緒にやるということをずっと大事にしていきたいです。

では、今後ともよろしくお願いします。

zf create project ⇒ Cannot redeclare class PHPUnit_Framework_TestSuite_DataProvider in /usr/share/php/PHPUnit/Framework/TestSuite/DataProvider.php

zf create project path

を実行したとき、

Cannot redeclare class PHPUnit_Framework_TestSuite_DataProvider in /usr/share/php/PHPUnit/Framework/TestSuite/DataProvider.php

というエラーが発生。
スタックをたどってみると、

/usr/share/php/PHPUnit/Framework.php

の中で大量にphpファイルをrequireしていたので、ファイル内のrequireを全てrequire_onceに置換して解決。

git rebase -i で編集をミスったとき

git rebase -i で過去のコミットを編集、まとめたりするとき、
途中で操作をミスると再度 git rebase -i を実行しようとしても

"Interactive rebase already started"

と出ることがある。
このときは一度

$ git rebase --abort

を実行して、「今のrebase無しよ」としてから
再度git rebase -i を実行すれば上手くいく。

Hello, world.

I had written the blog in the title "[Susume] of school IT study meeting" before. My name is [tsukadaakihiro]. It is shifting gradually to akitsukada though I had acted by the pen name named atcorp before.

The place of employment is domestic SIer, and I am employed as SE apprenticeship. Even if it is private, the programming is done. The programming is a hobby.

The CMS development project of open source named SetucoCMS is started up with the classmate, the junior, and the senior in the school days now. A real activity has not started yet though the page of the project is made in SourceForge. The future is the enjoyment.

SetucoCMS合宿中のHTML勉強会めも

今立ち上げ中のオープンソースプロジェクト「SetucoCMS」の合宿中に、HTML勉強会を行った。講師はプロジェクトリーダーの@skyguild。走り書きのようだけど、内容をメモったのでここに記録。

SetucoCMS HTML勉強会

hタグについて

h6まである。html4ではh1は一つのページに一つまで、となっていたが、html5ではその辺の事情が変わりつつある。単純に太い大きい文字で表示するタグじゃない。見出しの意味を持つのが重要。

リストタグ（ul ol dl）について

場合によっては、dlタグを使うのか、それをhタグをpタグでやればいいのかと迷うこともある。見分け方、判断の仕方としては、「◎◎」は「〜だ」、「○○」は「〜〜だ」というときは「dl dt dd」だろうし、「◎○」について、「◎○◎○◎○◎○◎○◎○◎○◎○◎○◎○◎でhhhhhhasldkfja;slkdjfaだ」とかならhタグとpタグがいいかもね。

divタグについて

ブロックレベル要素（ほかにh,p,・・・など、文書構造としての意味を持つもの）。要素をまとめておけるタグ。divタグ自体は意味を持たないタグ。意味をなさないので、本来は「いかにdivを使わないか」という観点で見たり。

spanタグについて

divのインライン要素。（a,img・・・など、文中に使うもの）pタグで囲った中でも、一部だけ赤文字にしたいとか。ただし、これも本来文書としての意味をなさないので、使用には一考を要する。たとえば、赤文字にしたいのはなぜか=>強調したいから。=>それなら別のタグでは。

b, em, strong の違いについて

bはbold、emはemphasis、strongはstrongの略（strongは略じゃない＞＜）。emは文中で強調・重視したいところ、strongはさらにstrongなところ！

copyright表記について、addressタグを使うのは適切か

addressか？そうでもないだろ => pタグじゃね？という議論があったりした。でも、それも違わね？みたいな展開になって、さらにhtml5ではsmallタグを使うんだって。

HTML5では

divで一般的に表していたことをタグ化して、より適切に文書構造の意味を表現できるようにする。例えば ＜div id="header"＞というお決まりのタグは ＜header＞ タグにするとか。

例えば ＜a＞（アンカー）タグでページ内ジャンプを表現しているとき、音声読上げブラウザでは毎回不要な見出しを読上げられたりする。それが、HTML5なら＜navigator＞タグで適切な意味を持たすことができ、音声ブラウザに対する適切な配慮ができる。「セマンティックなマークアップ」方面に力を入れている。

CSS3について

やりすぎじゃないかな、という意見も。CSSは装飾を施すものであって、アニメーション関連はCSS本来の役目だろうか？

CSSの書き方について

dim#header と書くときの、divは意味があるか？ないけど、それをみたときに意味が分かりやすい。p#copyright と書いたときとか、#copyrightより分かりやすい。htmlソースを見て検索しないでも、cssだけ見れば分かるよね。私は結構すき。そもそも、要素はコーディングに設計／定義をすべきものなので、後から要素を変更しない前提で書くべきだし。

cssの一括書きと個別書き

たとえば、backgroundとbackground-image, background-position, background-repeat。3つ書くと3行消費しちゃうし読みにくくなるから、background一行で書こうね。あと、marginの指定はmargin-top、margin-bottomとか分けるんじゃなくて、margin:10px 0; みたいにまとめ書きしよう。

それに、margin/paddingの指定をするときに0pxとか書かないで。0は0であって、emでもpxでもないのだよ。

HTMLコーダーが魅せるのは、見えないところ

HTMLコーダーがアツくなるポイントとしては、alt属性。これは入れた方がいいとかじゃなくて「入れなきゃいけない」。音声読上ブラウザに対する配慮もそうだし、SEO的にも効果がある。imgタグにaltが入っていなければ、どちらもダメ。

imgで、画像に対する意味の補足としてやるとか。tips的には、＜h2＞＜a href="" title="*****"＞＜/a＞＜/h2＞みたいに書いたときのtitle属性。title属性は、多くのタグにつけられる要素。補助的な意味として、アツい。
HTMLって、見えないところにけっこうこだわるもんなんだよー。googleも、「ランキング上げるためじゃなくてユーザのことを考えてサイト作りなさい」って言ってるんだよ！

読み上げブラウザのtips

altに補足の文書を書いてあげるとき、「menu」って書くと「エム・イー・エヌ・ユー」とか読上げられちゃったりすることがあるので、カタカナで「メニュー」って書いてあげるほうがいいよ、とかね！

レイアウト

固定幅レイアウト、リキッドレイアウト、エラスティックレイアウト。

固定幅

横幅が変動しないレイアウト

リキッドレイアウト

リキッドレイアウト

エラスティックレイアウト（ゴムのように弾力性のあるレイアウト）

文字サイズを基準に各所のサイズを決める（単位にemを使うなど）

リキッド+エラスティックレイアウト

最大幅／最小幅などを指定したり、外部のバナー等固定幅でなければならない部分がある場合は、柔軟にがんばる。

エラスティック+固定幅の活用例⇒http://www.jec.ac.jp/design-w/

お役だち情報

役立つサイト

Another HTML-lint gateway
http://htmllint.itc.keio.ac.jp/htmllint/htmllint.html
HTMLの構造上の正しさを採点してくれるよ！

W3C Markup Validation Service
http://validator.w3.org/

役立つアドオン - Firefox

Web Developer
http://lab.tubonotubo.jp/tools/webdeveloper/index.html

HTMLバリデータ
https://addons.mozilla.org/ja/firefox/addon/249
検証してくれます。

Semantic Checker 0.8.0
https://addons.mozilla.org/ja/firefox/addon/13560
Sugamo.CSSで教えてもらったアドオン。
要素ごとに色分けして一目で分かるように表示してくれるよ。

質疑応答

Q:brタグってどうなの

A:改行であって空白ではない。改行なのだよ。p使うべきときはp使うべきだし、あくまでも意味としての改行に使うべき。レイアウト調整のために使うことは許されない。いっさい。ダメ、絶対。

Q:idとかclassの名前を付けるのめんどくさいんですけど。

A:逆に、必要なところ以外はidやclassをつけないようにコーディングを頑張っては。たとえばulタグ自体にcssを指定すればいいのにわざわざdivでラッピングしたりは無駄っすよね。あとは、＜div id="container"＞とか、ある程度お決まりの構造や名前を使っていけます。まぁ、正直迷うこともあるけど。

関連して、命名ルールの一般的な参考例

本文全体を囲む

container、wrapper、page、pagebody、all

ヘッダー

header、header-area

ナビゲーション

nav、navi、navigation

グローバルナビゲーション

global-nav、gnav

ローカルナビゲーション

local-nav、lnav

補足ナビゲーション

assist-nav、utility、utility-nav

パンくずナビゲーション

topicpath、breadcrumbs

コンテンツ全体

content(s)、container、wrapper

メインコンテンツ

main、maincontent(s)、content(s)、alpha、primary

サブコンテンツ

sub、subcontent(s)、beta

サイドバー

sidebar

見出しと本文のまとまり

section、entrybody、article(s)

記事単体

article(s)、entry(-ies)

フッター

footer、footer-area、copyright、publication

ロゴ

logo

キービジュアルやメインビジュアル

keyvisual、mainvisual

画像や写真、グラフなど

image、photo、fig、figure

検索

search、search-area、search-box

注釈、ヒント

aside、hint、note

商品一覧

products、item-list、shopitems

オープンソースの定義を読む

最近、オープンソースのライセンスについて勉強している。以前からオープンソースソフトウェア（以下、OSS）の恩恵に預かっていたり、その世界や人に魅力を感じまくってはいたのだが、そのライセンス体系や、オープンソース自体の定義について、これまでほとんどまともな理解をしてこなかったことを、今さらながら痛感している。今日は、「オープンソースの定義」について、知ったことをまとめておく。正直言ってよく分からなかった部分も中にはあるので、突っ込み歓迎の意を表しておく。

「オープンソースの定義」の生い立ち

今日で言う「オープンソース」を定義したのは、ブルース・ペレンスという人物である。彼はその後、非営利団体であるオープンソース・イニシアティブ（OSI）を設立した。ここで言う「オープンソースの定義（The Open Source Definition…以下、OSD）」とは、彼の書いた"The Open Source Definition"である。原文はここ、八田真行氏による日本語訳はここで読むことができる。この記事では、日本語訳版の文章を逐次引用しつつ、解釈を進めていこう。

全10項目があるのだが、ちょっと僕の足りない知識では分かりにくい部分があり、咀嚼するのに時間がかかってしまった。なんとか理解できたような気がするので、それを忘れないようにメモしておきたい。また、文章がややこしいのが分かりにくい原因なのではないかと思うので、できるだけ各項目について要点を箇条書きでまとめていくことを試みたい。

以下の項目

多いので、いったんここで項目を挙げておく。

1. 再頒布の自由
2. ソースコード
3. 派生ソフトウェア
4. 作者のソースコードの完全性（Integrity）
5. 個人やグループに対する差別の禁止
6. 利用する分野に対する差別の禁止
7. ライセンスの分配（distribution）
8. 特定製品でのみ有効なライセンスの禁止
9. 他のソフトウェアを制限するライセンスの禁止
10. ライセンスは技術中立的でなければならない

一つずつ見ていこう。

※なお、日本語訳を見ると、各項目に「理由：～」という文章が書いてある。この記事では基本的に各項目の解釈に焦点を絞っているが、項目についての理解が進んだ後は、ぜひ「理由」を読んでおいてほしい。

再頒布の自由

「オープンソース」であるライセンス(以下「ライセンス」と略)は、出自の様々なプログラムを集めたソフトウェア頒布物(ディストリビューション)の一部として、ソフトウェアを販売あるいは無料で頒布することを制限してはなりません。ライセンスは、このような販売に関して印税その他の報酬を要求してはなりません。

「『オープンソース』であるライセンスは（略）販売あるいは無料で頒布することを制限してはなりません。（略）印税その他の報酬を要求してはなりません。」とある。

箇条書きにすれば、

• オープンソースライセンスは
• 再頒布時に、無料か有料で販売するかは、利用者の自由にすること
• もし利用者が販売することを選んだ場合でも、報酬や印税を求めないこと

こうだ。言い換えると、

• OSSの利用者は、そのOSSを利用して作ったものを
• 無料で再頒布してもOKだし
• 売ってもOK
• そのとき、利用者はもとのOSS（の作者）に対して
• 報酬とか印税を支払う必要はない

こういうことになる。

ソースコード

「オープンソース」であるプログラムはソースコードを含んでいなければならず、コンパイル済形式と同様にソースコードでの頒布も許可されていなければなりません。何らかの事情でソースコードと共に頒布しない場合には、ソースコードを複製に要するコストとして妥当な額程度の費用で入手できる方法を用意し、それをはっきりと公表しなければなりません。方法として好ましいのはインターネットを通じての無料ダウンロードです。ソースコードは、プログラマがプログラム を変更しやすい形態でなければなりません。意図的 にソースコードを分かりにくくすることは許されませんし、プリプロセッサや変換プログラムの出力のような中間形式は認められません。

文章は長いが、言っていることは簡単だ。

• OSSは、そのソースコードを頒布していなければならない
• コンパイル済みのバイナリファイル（たとえば.exeファイルとかの）形式で頒布している場合も、ソースコードを一緒に頒布すべし
• もしバイナリファイルとソースコードを一緒に頒布できないとしても、簡単にソースコードが入手できるようにしておくこと
• できればインターネットで公開して、無料ダウンロードできるようにしておくこと
• ソースコードは、プログラマが改変しやすいようにしておくこと
• ソースコードを中間形式で配布するのはダメ。要するにテキスト形式で、ちゃんと人間がいじれる状態で配布すること

とにかく、テキスト状態のソースコードをちゃんとオープンにしておけということだ。分かりやすい。

派生ソフトウェア

ライセンスは、ソフトウェアの変更と派生ソフトウェアの作成、並びに派生ソフトウェアを元のソフトウェアと同じライセンスの下で頒布することを許可しなければなりません。

「～と同じライセンスの下で頒布することを許可しなければなりません。」あたりの言い回しが多少分かりにくく感じた。要するに、

• あるOSSの利用者は、
• そのOSSの内容を変更してもよい
• そのOSSを元にした、いわば「派生ソフトウェア」を新たに開発してもよい
• その派生ソフトウェアの頒布時に、
• 元のOSSと同じライセンスを適用してもよい
• 元のOSSと違うライセンスを適用してもよい

ということだ。

最後の、「元のOSSと違うライセンスを適用してもよい」のくだりが、一見すると原文に含まれていないような感じがしてややこしい。

作者のソースコードの完全性(integrity)

バイナリ構築の際にプログラムを変更するため、ソースコードと一緒に「パッチファイル」を頒布することを認める場合に限り、ライセン スによって変更されたソースコードの頒布を制限することができます。ライセンスは、変更されたソースコードから構築されたソフトウェアの頒布を明確に許可していなければなりませんが、派生ソフトウェアに元のソフトウェアとは異なる名前やバージョン番号をつけるよう義務付けるのは構いません。

10項目中、最も分かりにくいと思う。箇条書きで内容をまとめられるのか心配である。

まず、この項目は、「派生ソフトウェア」の再頒布時の形態について、二つのケースを想定している。すなわち、

1. あるOSSのソースコード + その利用者が作ったパッチファイル
2. あるOSSのソースコードを、その利用者が改変したもの

の2パターンである。では、一つ目のケースから見ていこう。

「1. あるOSSのソースコード + その利用者が作ったパッチファイル」の場合について、

• あるOSSのライセンスは、
• 元のOSSのソースコードを変更した状態で再頒布することを禁止してもよい
• ただし、同時に「パッチファイル」を頒布することを認めなければならない

ということが書かれている。

ここで「？！」となるのが、「元のOSSのソースコードを変更した状態で再頒布することを禁止してもよい」というくだりではないだろうか。これが、前項である「派生ソフトウェア」で定義されていた「そのOSSの内容を変更してもよい」という内容と相反するように感じられるのが、個人的にはOSDややこしポイント第一位である。

この項を理解するには、まず「パッチファイル」について知っていなければならない。かいつまんで言えば、パッチファイルとは、「ソースコードの『変更点』をまとめたファイル」である。「変更点」とは、たとえば「○行目を削除」とか「△行目の"public"という単語を"private"に変更」とか、文字通りソースコードを変更する内容である。

このパッチファイルを、元のソースコードに「適用」することによって、パッチファイルにまとめられた「変更点」の情報がソースコードに一気に反映される。

つまり、「あるOSSのソースコード + その利用者が作ったパッチファイル」が一緒に頒布された場合、それを手に入れた第三者は、「あるOSSのソースコード」に「その利用者が作ったパッチファイル」を「適用」することによって、結果的に「その利用者が開発した派生ソフトウェア」を得ることができるわけだ（書いててもややこしい）。

なんでこんな面倒なことをわざわざするかというと、こうすることによって、「元のOSSの作者が書いたソースコード」自体はそのまま再頒布されるため、「元の作者のソースコード」と「派生ソフトウェアの作者が書いた変更点」とが明確にできるからである。作者や場合によっては、「自分はここまで書いたんだ」ということをはっきりさせておきたいかも知れない。そのための項目といえる。

では次に、「2. あるOSSのソースコードを、その利用者が改変したもの」の場合を見てみよう。

• あるOSSのライセンスは、
• （パッチファイルでなく）ソースコード自体を改変した「派生ソフトウェア」の再頒布を許可すべし
• その再頒布時に、「派生ソフトウェア」には元のソフトウェアとは違う名前、違うバージョンをつけることを強制してもよい

となる。

これは、「元のOSS」と「派生ソフトウェア」の名前やバージョンをしっかり区別させることによって、「元のOSSの作者が書いたソースコード」を明確にしておくためである。たとえば、あるOSSの作者が、そのOSSの「派生ソフトウェア」には「元のOSS」とは違う名前をつけるように強制することで、その二つが明確に違うものであり、「自分が書いたのは『元のOSS』のソースコードだ」と主張しやすくなるわけだ。

この2つのケースに共通するのは、どちらも

• オリジナルな作者が書いた範囲（ソースコード）を、明確に分かるようにする

ために定義されているということだ。これが、「作者のソースコードの完全性（integrity）」ということである。

個人やグループに対する差別の禁止

ライセンスは特定の個人やグループを差別してはなりません。

これは大変わかりやすい。言葉どおりなので、詳しい説明は不要だろう。なお、OSD日本語訳のこの項目に添えられた「理由」には、

進化の過程から最大の恩恵を引き出すためには、可能な 限り多種多様な人々やグループに、平等にオープンソースに貢献する資格が与 えられている必要があります。そこで、オープンソースなライセンスによって 誰かを進化の過程から締め出すことは禁止されています。
（後略）

と書かれている。個人的には、これこそオープンソースの思想であると思う。

利用する分野(fields of endeavor)に対する差別の禁止

ライセンスはある特定の分野でプログラムを使うことを制限してはなりま せん。 例えば、プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはなりません。

これも、その言葉どおりだ。あえて言い換えるなら、

• このOSSをどんな分野で使ってもいいよ
• でも、うまくいかなくっても泣かないでね＞＜

ということだろうか。

ライセンスの分配(distribution）

プログラムに付随する権利はそのプログラムが再頒布された者全てに等しく認められなければならず、彼らが何らかの追加的ライセンスに同意することを必要としてはなりません。

これまでの項目において、「再頒布」とは「あるOSSに何らかの改変を加えた派生ソフトウェアを頒布すること」という意味で述べることが多かった。しかし、ここで言う「再頒布」とは、特に「あるOSSを入手した後、そのままの形で（改変を加えず）他の人に頒布すること」と考えればよい。

• あるOSSが、あるライセンスの下で頒布された場合
• そのOSSを、そのまま再頒布するとき、ライセンスを変更してはならない

ということである。

特定製品でのみ有効なライセンスの禁止

プログラムに付与された権利は、それがある特定のソフトウェア頒布物の一部であるということに依存するものであってはなりません。プログラムをその頒布物 から取り出したとしても、そのプログラム自身のライセンスの範囲内で使用あるいは頒布される限り、プログラムが再頒布される全ての人々が、元のソフトウェア頒布物において与えられていた権利と同等の権利を有することを保証しなければなりません。

これも、言い回しが難しい気がするが、意味はそう難しいものではない。ここでいう「プログラムに付与された権利」とは、「OSSのライセンスの内容」である。それが「ある特定のソフトウェア頒布物の一部であるということに依存するものであってはならない」。つまり、

• 「あるソフトウェアの一部である場合のみ、OSSとしてのライセンスが有効になるよ」はNG
• そのOSSが「あるソフトウェア」の一部であろうがなかろうが、OSSとしてのライセンスは絶えず有効である

ということである。

この定義によって、たとえば「ある特定の商用ソフトウェア"A"」に「あるOSS"B"」が含まれていた場合（それ自体は悪いことではない）、「商用ソフト"A"の一部として"B"を入手した場合のみ、あなたは"B"をOSSとして利用できますよ。魅力的でしょう。だから"A"を買ってください。」という行為を防ぐことができる。

他のソフトウェアを制限するライセンスの禁止

ライセンスはそのソフトウェアと共に頒布される他のソフトウェアに制限を設けてはなりません。例えば、ライセンスは同じ媒体で頒布される他のプログラムが全てオープンソースソフトウェアであることを要求してはなりません。

• OSSライセンスは、
• どんなソフトウェアと一緒に頒布するかは、頒布者の自由にすべし
• たとえば、「このソフトウェアは、一緒に頒布されるソフトウェアがすべてOSSである場合のみ、OSSとして利用してよい」とかはNG

一緒に頒布される他のソフトウェアがOSSだろうとプロプライエタリだろうと関係ない。それらに依存した内容をライセンスに盛り込んではならない、ということだ。

ライセンスは技術中立的でなければならない

ライセンス中に、特定の技術やインターフェースの様式に強く依存するような規定があってはなりません。

これは、読んだ当初は例えば「このソフトウェアは、Linux上で動作する場合のみOSSとなる」とかいった規定を禁止するものがと思った。今でも、文章のみを見るとそう思う。だが、OSD日本語訳の「理由」を見てみると、どうもそれとは少し違ったニュアンスのことを想定しているようだ。

理由: この規定で特に念頭に置いているのは、ライセンサーとライセンシーの間で 契約を成立させるために明示的な同意の意思表示を必要とするような ライセンスです。いわゆる「クリックラップ(click-wrap)」を要求する規定は、 ソフトウェア頒布において重要な手法であるFTPダウンロードや CD-ROM アンソロジー、ウェブのミラーリングなどと衝突する可能性がありますので、 このような規定もコードの再利用を妨げてしまいます。よって、本定義に 準拠するライセンスは、(a) ソフトウェアの再頒布が、ダウンロード時の クリックラップをサポートしないようなウェブ以外の経路で起こりうるという 可能性 (b) ライセンスで保護されるコード (あるいは保護されるコードの 再利用された部分) はポップアップダイアログをサポートできない非GUIの 環境でも実行されれうるという可能性、を認めなければなりません。

つまり、OSSを利用する際に、利用者が利用許諾の内容について間違いなく同意の意思を表示できるようにするための規定ということである。箇条書きにしてみよう。

• OSSを利用するとき、以下のような場合についても、利用者がライセンスの内容に同意を示せるようにすべし
• 例えば、GUI環境がなくて、「同意しますか？はい/いいえ」といったポップアップが出せない場合
• 例えば、Webからのダウンロード、CD-ROM等の媒体等々、複数の手段で頒布される場合

特に二つ目、「複数の手段で頒布される場合」が面白い。これは、例えば「Webからダウンロードしたことを以って同意したとみなす」とか、「パッケージの包装を破ったことをもって同意したとみなす」など（こういった利用許諾確認をクリップクラップという）、ライセンスの中で利用意思の確認手段を特定してしまうと、それだけOSS再頒布/再利用のチャンスを制限してしまうことになる。だから、特定の媒体やインターフェース環境下でのみ正常に利用意思が確認されるようなライセンスであってはならない。と、いうことのようだ。

ふう、やっと終わった。

これは数ある具体的なライセンスの大枠

以上で、OSD10項目の解釈を終える。しかしこの10項目は、具体的なライセンス（GPLとかBSDとか）の基礎となるものに過ぎない。各ライセンスは、このOSDに反しない中で、また独自に種々の取り決めを行っている。いわば、OSDは日本国憲法、各ライセンスは法律のようなものだろうか。いや、違うか。

とにかく、今回これをまとめたことによって、OSDの概要はつかめたように思う。今後は、各ライセンスについて、その内容や特徴、違いを勉強していきたい。

こんにちは、世界

以前、はてなダイアリーで「学内IT勉強会のススメ」という身もふたもないタイトルのブログを書いていた。つかだあきひろです。atcorpというHNで活動していたが、これを徐々にakitsukadaに移行中である。

この2010年4月に晴れて新社会人となり、これまでのブログのタイトルが現状とそぐわなくなった。タイトルを変えて、はてなダイアリー運用を続けていくかどうかほんの少しだけ迷ったのだけれど、この際気分転換も含めて、思い切ってBloggerに移行してみようと思う。

就職先は国内のSIerで、僕はSE見習いとして採用された。今後は仕事でシステム開発に携わっていくわけだが、プライベートでもプログラミングが趣味である。また、学生時代の同期や後輩、先輩とともに、SetucoCMS（せつこしーえむえす）というオープンソースのCMS開発プロジェクトを立ち上げている最中だ。SourceForgeにプロジェクトのページは作ってあるが、まだ本格的な活動はスタートしていない。

これまでのはてなダイアリーでは、そのタイトルのとおり学内外の勉強会に参加または開催したエピソードを中心に綴ってきたが、このブログは、日記の意味も含めて、興味のある技術を中心に、もう少し緩く全般的なことを記していきたい。