npm install 実行時に以下のエラーが発生。
AngularMyDatePickerModule' does not appear to be an NgModule class.
This likely means that the library (angular-mydatepicker) which declares AngularMyDatePickerModule is not compatible with Angular Ivy. Check if a newer version of the library is available, and update if so. Also consider checking with the library's authors to see if the library is expected to be compatible with Ivy.
angular-mydatepicker を使用していたが、Angular 16 から動作しなくなった。
このパッケージはすでにメンテナンスが終了しており、後継を探さなくてはならない。
先に結論を言うと、@nodro7/angular-mydatepicker を後継版として採用する。
その判断に至った調査方法を残す。
代替パッケージの探し方
以下の2つの探し方がある。
- フォーク版から探す
- 全く別のパッケージを探す
フォーク版（後継）から探す
フォーク版（後継）から信頼できるパッケージを選定する。
フォーク版とは？
「フォーク」とは、GitHub などで公開されているオープンソースのソースコードを、 他の開発者が自分のアカウント下で複製（fork）し、 独自に改良・開発・保守を始めることである。
個人アカウントのフォーク版を信頼できる？
OSS の世界では、個人アカウントによるフォークや後継プロジェクトが 「事実上の標準」になるケースは珍しくない。
信頼性をどのようにして確認する？
OSS のフォークは、自主的に開発が別の開発者へ引き継がれるため、 正式な後継と宣言されないことがほとんどである。
後継として扱われるかどうかは、ユーザーによって判断される。
以下が判断材料となる。
- フォーク版の開発者が、フォーク版であることを宣言しているか
- npm に公開されているか
- ダウンロード数
- リリース履歴
フォーク版の開発者が、フォーク版であることを宣言しているか
もとのパッケージの Issues を見ると、 「このパッケージはメンテナンスされていないのではないか」 というコメントが多数見つかる。
フォーク版が作成されている場合、 開発者がここにフォーク版を作成した旨を宣言している場合がある。
npm に公開されているか
npm アカウントを作成すれば、誰でもパッケージを公開可能。
パッケージ名が既に他の人に使われていなければ、申請後すぐに公開される。
パッケージ名や内容が npm のポリシー（禁止ワードやマルウェアでないかなど）に引っかからなければ、自動的にそのまま公開される。
問題のあるパッケージは、後から npm 運営により削除・公開停止されることもある。
＞禁止ワードやマルウェアとして検知されておらず、長期間公開されているため信頼できる。
ダウンロード数とリリース履歴
元パッケージの Issues などで複数のフォーク版が見つかった場合は、ダウンロード数とリリース履歴を確認する。
ダウンロード数の確認方法
npm の公式ページからフォーク版のパッケージを確認する。
ここからダウンロード数を確認できる。
リリース履歴の確認方法
フォーク版の GitHub の Releases を確認する。
Angular の最新版までメンテナンスを実施していることを確認する。
全く別のパッケージを探す
フォーク版も無視して、もっと信頼できるパッケージを探すこともできる。
例えば、今回の Datepicker 機能は、ng-bootstrap の Datepicker や、Angular 公式の Datepicker（Angular Material Datepicker）でも実装できる可能性が高い。
ただし、コーディングはほぼ確実に新しいパッケージに合わせて書き換えることになる。
保守性で言えばこれが一番なのだが、テスト工数の増加などとトレードオフで考える必要がある。
ライセンスの確認は必須
OSS（オープンソース）のパッケージを使用する場合、ライセンスの確認を怠ると以下のリスクがある。
- 訴訟リスク
- ソースコードの開示請求
- 所有権
ほぼ無いが、OSSを使用したアプリケーションの所有権がOSS作成者に帰属するなんてことも考えられる。
ライセンスの確認方法
GitHubでパッケージをみると、大抵rootにLICENSEというファイルが配置されている。
ライセンス比較表
ライセンスの種類は以下のようなものがある。
ほとんどがMITかApacheなので取り急ぎそれだけ覚えておけばよい。
| ライセンス | 商用利用 | 改変 | 配布 | ソース公開義務 | 派生物のライセンス |
|---|---|---|---|---|---|
| MIT | ○ | ○ | ○ | × | 自由 |
| Apache 2.0 | ○ | ○ | ○ | × | 自由 |
| BSD | ○ | ○ | ○ | × | 自由 |
| LGPL | ○ | ○ | ○ | △（改変時） | 自由（リンク時） |
| MPL | ○ | ○ | ○ | △（ファイル単位） | 自由（他ファイル） |
| GPL | ○ | ○ | ○ | ○ | GPL強制 |
| AGPL | ○ | ○ | ○ | ○ | AGPL強制 |
OSSを使用する側の義務
OSSを使用する開発者は以下の義務を果たす必要がある。
先ほど挙げたApacheとMITは非常に緩い制限で、OSSの一般的な選択肢となっている。
| 義務 | MIT | Apache | LGPL | GPL | AGPL |
|---|---|---|---|---|---|
| 著作権表示 | ○ | ○ | ○ | ○ | ○ |
| ライセンス文 | ○ | ○ | ○ | ○ | ○ |
| 改変箇所明記 | × | ○ | ○ | ○ | ○ |
| ソースコード公開 | × | × | △ | ○ | ○ |
| 派生物も同ライセンス | × | × | △ | ○ | ○ |
| SaaSでもソース公開 | × | × | × | × | ○ |
結局何を確認すれば良いの？
ここまで聞くととても大変な作業に聞こえるが、以下を意識するだけで、実はやることはそんなに多くない。
- MITもしくはApache2.0ライセンスを使用したパッケージを選定する
- パッケージを改変しない
- LICENSEを同梱する
MITもしくはApache2.0ライセンスを使用したパッケージを選定する
この2パターンであればOSSとしてほぼ使用できる。
この他の種別であった場合は、特別注意してライセンスに記載されている内容を確認し、制限を満たせる場合のみ選定する。
MITも完全に安全ではない
Apacheフォーマットでは定型条文が厳密で、明確に『自由に使ってよい』と書かれており安全なのだが、MITは20行程度と短くやや簡素。
ライセンスの中身を見て、条文が空になていないか？追加条項で理不尽な要求が無いか？くらいは確認する。
パッケージを改変しない
OSSの一般的な用途としては、自身のアプリケーション内で、OSSパッケージをそのまま使用するだけなので、特別意識する必要はない。
フォークして再配布、などを検討している場合は注意が必要になる。
LICENSEを同梱する
これも、メジャーなパッケージを使用していればあまり意識する必要が無い。
たとえば、最近のビルドツール（webpack、Vite、Angular CLI など）は、 以下のようなライセンスファイルを自動生成する。
- LICENSE.txt
- 3rdpartylicenses.txt
- main.js.LICENSE.txt
Angular CLI の場合はdist/3rdpartylicenses.txt が生成される。ここに使用している OSS のライセンス情報がまとめて出力される。
多くの場合は自動生成されるが、ツールや設定によって動作が異なることは覚えておく。
ベストプラクティス
基本的には新規パッケージ導入時のみの確認なので負担は少ないと思うが、より安全に管理するのであれば定期的に監査を実施する。
npx license-checker --production --summary
- 想定外のライセンスが混入していないか確認する。
npx license-checker --production --failOn "GPL;AGPL;LGPL"
- CI/CD に組み込んで自動検知する。
- PR ごとに自動チェックする。
コメント