ソースコードの著作権(Copyright)の記述方法ついて

ソースコード資産を管理する上で、ソースコードの著作権(Copyright)の記述方法について調査、検討しました。

 

日本の法律では、著作権を明示的に記述せずともソースコードを書いた時点で著作権が発生しているので著作権の表示は無くても良いようです。

ただ、Webサイトの場合は世界中からアクセスされる可能性がありますし、オープンソースとして公開した場合には誰がどのように使うか予測しきれません。

この様な背景から、ソースコードに著作権を記述し著作権を主張することは無断流用を抑止する方法として無駄ではないと思います。

 

著作権は非常に奥深く、難しい法律がいっぱい出てきますが私は法律の専門家ではないので、ポイントを押さえてまとめて行きたいと思います。

 

著作権を示すには、「©」、「年号」、「著作権者」の3点が必要となります。

© <年号> <著作権者>

「©」は、Copyrightを表す記号です。「©」は環境依存の文字なので「(c)」という文字列で代替することも可能です。

「<年号>」は、著作権が発生した年です。ユーザーが見るWebサイトやソフトウェアのバージョン情報において、継続して更新されていることが分かるよう「<著作権発生時の年> – <現在の年>」という表記しているのを目にすることがありますが、あくまでも分かりやすくするのが目的ですし、ソースコード内の年号をいちいち毎年更新することはあり得ないので著作権が発生した年を「<年号>」に記述します。

「<著作権者>」は、著作権を所有する企業は著者です。

 

Copyright © <年号> <著作権者>. All rights reserved.

のような、著作権の記述を目にすることもあります。「©」が既にCopyrightを意味するのであえて「Copyright ©」と記述する必要はありませんが、「©」を誰もが知っている訳ではないので、これも分かりやすくするために記述方法です。

「All right reserved.」は、ブエノスアイレス条約に基づく著作権保護を受けるための著作権表示だそうだが、現在では著作権表示がなくでも著作権が保護されるベルヌ条約というのにブエノスアイレス条約の加盟国が皆加盟したので意味を持たない。また、日本はそもそもブエノスアイレス条約の非加盟国なのでまったく効力を持たないそうだ。このあたりの歴史の話は、wikipediaの「著作権表示」にまとまっている。ただ、慣習として記述されている様である。

 

これらを踏まえ、auxakの著作権表示は以下のようにすることにしました。

Copyright © 2014 auxak. All rights reserved.

 

また、ソースコードにはライセンスヘッダーとして以下を記述します。

======================================================================
Project Name    : <Project Name>
File Name       : <File Name>
Encoding        : <Encoding>
Creation Date   : <Creation Data>

Copyright © <Year> auxak. All rights reserved.

This source code or any portion thereof must not be  
reproduced or used in any manner whatsoever.
======================================================================

Read More

auxak コーディング規約

auxakでは、開発効率の向上と保守性の高い可読性の良いプログラムを開発するため、以下に定める各プログラミング言語のコーディング規約に基づきコーディングを行うものとする。

 

≪PHP≫

www.php-fig.orgが定めたPHPのコーディング規約である「Proposing a Standards Recommendation(PSR)」に準拠ものとする。

株式会社インフィニットループの技術ブログにて日本語訳が公開中。

 

[補足]

変数の命名規約

PSRでは、変数の命名規約に関して指定の記法は推奨しておらず、合理的な範囲内で一貫性の記述であれば”$StudlyCaps”、”$camelCase”、”$under_score”のどの記法でも良いとされています。そのため、auxakでは”$under_score”を変数名の命名規約に採用するものとする。

(参考:PSR-1, 4. Class Constants, Properties, and Methods, 4.2 Properties)

$age;
$first_name;

 

単一行コメント

「//」を用いで記述する。「//」とコメントの先頭文字との間にはスペースを1文字挿入すること。

// single-line comment

 

ブロックコメント

複数行に渡るコメントはコメントブロック(「/* <コメント> */」)を用いる。

「/*」及び「*/」はそれ単体で1行として記述し、その間に記述した「*(アスタリスク)」で始める行に記述する。

「*」とコメントの先頭文字との間にはスペースを1文字挿入すること。

「*」の位置を統一すること。

/*
 *  block comment
 */

 

≪データベース≫

テーブル名称

・複数形の英単語で命名する。但し、不加算名詞は例外とする。

・アルファベットは、全て小文字で表記する。

・複数の英単語で構成される名称は、スネークケースで表記する。

 

フィールド名称

・単数形の英単語で命名する。

・アルファベットは、全て小文字する。

・複数の英単語で構成される名称は、スネークケースで命名する。

・主キーは、「id」とする。

・外部キーは、「<参照元のjoinテーブル名称の単数形の英単語>_id」とする。

・DATE型の場合、

末尾に「_at」を付加する。過去の日時を表現する場合は、過去形で「xxxed_at」のように命名する。

・BOOLEAN型の場合、下表のような、「~able」や受動態、形容詞を使った名称とする。

xxx_accepted 承認されている
xxx_allowed 許可されている
xxx_available 利用可能である
xxx_canceled キャンセルされている
xxx_capable 可能である
xxx_enabled 有効にする
xxx_present 存在する
xxx_suspended 一時停止されている
xxx_valid 有効である
xxx_visible 表示可能である

 

≪HTML≫

後報

 

≪CSS≫

後報

 

≪JavaScript≫

後報

 

Read More

auxak システム開発プロセス

auxakにおけるシステム開発のプロセスを検討しました。個人や小規模開発の場合は、システム開発のプロセスを明確にしなくても何とかなってしまうこともありますが、将来的な大規模開発や分業を考慮した場合、システム開発のプロセスを明確にしておくことは必須でしょう。

調べてみるとやはりウォーターフォールモデルが一般的で安全なようですが、これからスタートアップするシステムのような場合には仕様が100%決定しにくい点や仕様変更に柔軟に対応したい点から工程を前後しながら試行錯誤のうえシステム開発をする可能性がありますが、ウォーターフォール・モデルでは基本的に前工程に戻るのはNGのため不向きな感じが否めません。ただ、受託開発をする場合には、各工程が明確に分割してスケジューリングできるため見積もり金額を明確にしやすい点でウォーターフォール・モデルは優れていると思います。

そこで、私なりにウォーターフォールモデルにアジャイルの概念を導入した独自のシステム開発プロセスを設計しました。

プロジェクトの最初と最後、また大きなフローはウォーターフォール・モデルですが、設計や実装、テスト等の工程はスプリントとしてグループ化し、フィードバックを反映してスプリントを繰り返すことで仕様変更への柔軟性を確保しました。

まだまだ、改良の余地が多々あるシステム開発プロセスですが運用する中で少しずつ改善をしていこうと思います。

 

ダウンロード先:auxak システム開発プロセス Rev.A(初版)

Read More