システムアーキテクトに苦戦する組込みエンジニア午後Ⅱ オープンソースソフトウェア

私は組込みソフトウェアエンジニアです。

2021年4月18日の情報処理試験システムアーキテクトを受ける予定です。

ですが、午後Ⅱの論文が非常に難しく、合格を諦め始めています^^;

しかし、私なりに幾つかの過去問題に対して、組込みエンジニアとして、言いたいことがあります。

同じような業務の方で、システムアーキテクトを受験しようと考えている方に、なにかしらの参考・ヒントになればと思います。

システムアーキテクト試験の受験は考えていない方でも、組込みシステムのシステムアーキテクトが、どのようなことを考えているのかを記載しているので、そちらでも参考になればと思います。

っていうのも、過去の問題と、参考書の回答が酷すぎる。

組込みシステムにおけるオープンソースソフトウェアの導入

平成２８年度システムアーキテクト午後Ⅱ 問３になります。

組込み製品におけるオープンソースソフトウェア導入の前提

ちょっと要約します。

問題文としては、以下のような内容が前提として記載されています。

組込みシステムに要求される機能は、年々専門化、高度化している。
その一方で開発期間は短縮化が求められる
プラットフォームの採用に際し、顧客からAndroidなどのOSSを使うように要求される。
OSSの使用許諾条件には、利用においての注意点がある。

28年度は内容薄いです。

この前提を読み込んだ上で、回答者の業務内容と、業務においてOSSの採用可否に悩んだこと等を記述することを求められます。

まず、AndroidをOSSとひとくくりに扱う傍若無人ぶりには恐れ入ります。*1

実際の業務におけるOSSとの関わり

それはさておき、

私は、現在勤める職場で、市販製品に向けて製品のPlatformを当時のWindowsCEからLinux OSへの転換を行う作業を数名のメンバーと共に実施しました。もちろん社内でLinuxを利用した製品開発は初になります。私自身は学生時代はUNIXを利用していましたので、それほど高いハードルは感じていませんでした。

Linuxについての勉強会を実施し、OSSについても専門家の話を聴くなどして、社内ルールの整備、開発者が注意しなければならないこと等をまとめました。

現在の製品開発においても、このLinuxを利用した製品群は主力の製品として継続しています。

システムアーキテクトを受験する方で、このような経験をすることができた方は、それほど多くないのでは無いかと思います。会社でLinuxを利用することを検討するというテーマになってしまうと、一つの会社で数名という割合になってしまいます。

ですから、実際に職場でLinuxを全面的に使うことに対しての作業でなくても、RTOS上で開発する中でOSSの利用を検討したようなケースに宛はめて考えるのが良いと思います。

例えば、画像を表示するために利用するJPEGやPNGのライブラリはOSSが公開されています。音楽ファイルのWAV、MP3をデコードするOSSもありますし、QR コード解析、作成のためのOSSもあります。

もちろん、これらは仕様が開示されていますので、仕様書を読みながら一からコードを作成することは可能です。しかし、OSSを利用することで、複雑な仕様書の理解も程々に、機能を実現することが可能になるのです。

そう考えると、何かしらのOSSを利用した経験はきっとあるのではないかと思います。

OSSを利用する上で必要な注意事項

OSSを利用するメリットは、開発期間の短縮ができます。無料で入手できます。

しかし、OSSには使用許諾条件というものがあるケースが存在します。

この使用許諾契約というのは、OSSを公開している方が決定することができるものです。契約と言っても紙でハンコおして法務通して行う契約とは違います。何もサインは必要ありません。ただ、「このOSSを利用するときは、なになにしてね。」というお願い事項のようなものです。守らないからといって罰則があるかというと、ありません。

しかし、作者は裁判を起こすことができます。お金を請求できませんが、会社としての名誉は傷を負います。

OSSの中には、以下のように記載されているものもあります

このOSSは商用利用してはいけません
このOSSを利用する場合は、このOSSを利用していることを明記しなければなりません。

作成したOSSに、どのような使用許諾をつけるのも自由です。ですから、不利益になる条項がないかを必ず十分注意してください。危ないものは無料でも使わない方が良いです。

そして、従来のOSSで作者毎に自由に定義されていた使用許諾を体系化して、雛形がいくつかの団体で作成されてきました。これが現在のオープンソースライセンスと呼ばれるものです。

オープンソースライセンス - Wikipedia

それでも、無数のLicenceが存在しています。特に主要なものには、以下のものがあります。

Apatch HTTP Server等に主にライセンスされている
Apache License 2.0
Linux Kernelにライセンスされている (GPL)
GNU General Public License, version 3
LinuxのLibraryやMiddlewareにライセンスされる（LGPL）

GNU Lesser General Public License v3.0 - GNU Project - Free Software Foundation

特にGPLのライセンスは非常に難解です。GPLをこれから利用を検討される方は、ぜひ専門家の意見を伺ったほうが良いです。専門用語も非常に多いですし、守らなければいけない事項も多いですので、特に注意が必要です。実際に世界中で裁判の凡例がいくつもあります。

営業部門にもライセンスに対しての理解をしてもらう必要があります。

マニュアルにはライセンス条項の記載を調整、ソースコードの公開を求められた場合の開示方法を社内として定義しなければならないです。

ソースコードの開示範囲の定義というのも、人によって解釈が異なります。十分読み込んで、社内でのルール化をしましょう。

また、開発者がOSSを利用しているつもりはなくても、OSSを利用してしまっているケースというのも存在します。もし、そのようなケースが発覚した場合にも、該当するOSSのLicenceを確認して、問題がなければLicenceに従い、問題があればソースコードを破棄する等の判断も必要です。このようなOSSを製品のコード群から検出するツールも存在していますので、採用の検討もしましょう。

GPL v3では、改変されたバイナリを機器にインストールする方法も開示する必要ありです。誰にでもできるようにする必要はありませんが、求められたら開示しなければならないのです。

セキュリティに厳しい昨今、こんなLicence定義されたLinux Kernel使って大丈夫ですか？社内で、しっかり協議して、個人の責任にならないようにしましょう。