Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

Red Hatの「RHCE 認定試験」にはEX300とEX294がある

Linux RHEL RHLS

Red Hatの「RHCE認定試験」には、RHEL7向けのEX300*1とRHEL8向けのEX294*2がある。同じ「RHCE」という名前の資格だけど、「試験の内容」を読むとぜんぜん別物みたい*3。

EX300の試験自体はすでに受けられなくなっている（Retired）けど、EX300試験を対象にした「RHCE 認定ラボ」がRH299*4や、EX300の前提となるRH254 Red Hat システム管理 Ⅲ*5は残っているので、資格取得の対策をしている場合は受講するコースを間違って選ばないよう気をつけよう。

Red Hat Enterprise Linux 8 向け RHCE 認定試験*6 Red Hat Enterprise Linux 7 向け RHCE 認定試験*7
コースコード EX294 EX300
SKU EX294V8K -
対象OS RHEL 8 RHEL 7
試験時間 4時間 3.5時間
前提資格: RHCSA Y Y
前提コース: RH124 Y Y
前提コース: RH134 Y Y
前提コース: RH199 Y Y
前提コース: RH294 Y N
前提コース: RH254 N Y
認定ラボ: RH299 N Y
Ansibleが試験範囲の説明に ある（9項目中8項目） ない（3項目中0項目）

*1:https://www.redhat.com/ja/services/training/ex300-retired-red-hat-certified-engineer-rhce-exam

*2:https://www.redhat.com/ja/services/training/ex294-red-hat-certified-engineer-rhce-exam-red-hat-enterprise-linux-8

*3:EX294では9項目中「Ansible」が8項目に記載されている。EX300ではAnsibleは一言も出てこない

*4:https://www.redhat.com/ja/services/training/rh299-rhce-certification-lab

*5:https://www.redhat.com/ja/services/training/rh254-red-hat-system-administration-iii

*6:https://www.redhat.com/ja/services/training/ex294-red-hat-certified-engineer-rhce-exam-red-hat-enterprise-linux-8

*7:https://www.redhat.com/ja/services/training/ex300-retired-red-hat-certified-engineer-rhce-exam

Javaアプリケーションサーバのライセンスに関する考察

Java

GlassFishはEPL 2.0とGPLv2のデュアルライセンスである。ここで、GPLv2にはクラスパス例外が付いている*1。わざわざクラスパス例外が付いているってことは、「クラスパス例外が付いていないGPLのJavaアプリケーションサーバでは、その上で動かすプログラムも、GPLと互換性のあるライセンスとする必要があるのでは？」という疑問が生じる。 「IoT 時代におけるOSS の利用と法的諸問題 Q&A 集」p.135 *2にも「共有アドレス空間上で実行されるもの（動的リンクおよび共有ライブラリ）の場合、サブプログラムのソースコードを提供する必要があると規定しており」という記載がある。

そこで、各種アプリケーションサーバ（フリーソフトウェアのもの）のライセンスを確認してみた。リストはList of application serversによる。

これを見ると、怪しいのはClasspath ExceptionのないResinくらいでしょうか。

*1:https://glassfish.org/LICENSE

*2:https://www.softic.or.jp/ossqa/all_180328_mc.pdf#page=141

*3:http://geronimo.apache.org/

*4:https://glassfish.org/LICENSE

*5:https://www.redhat.com/en/about/agreements

*6:https://www.eclipse.org/jetty/licenses.php

*7:https://jonas.ow2.org/view/Main/License

*8:https://github.com/lucee/Lucee/blob/6.0/License.txt

*9:https://github.com/payara/Payara/blob/master/LICENSE.txt

*10:WikipediaにはGPLと書いてあるけれど、リポジトリにはGPLのライセンスファイルがないみたい。

*11:https://caucho.com/products/resin/download

*12:https://gitbox.apache.org/repos/asf?p=tomcat.git;a=blob_plain;f=LICENSE;hb=HEAD

*13:https://github.com/apache/tomee/blob/master/LICENSE

*14:https://github.com/wildfly/wildfly/blob/main/LICENSE.txt

英字姓をすべて大文字で書く風習の例

文化的まちがいさがし

名前を英字で表記する際に、姓（family name）をすべて大文字・名（given name）をcapitalizeした形で表記することについて「その書き方は通用しない場合が多い」としている資料*1*2、日本でしか使ってるのを見たことがないという意見*3、実際に通じなかった事例*4が散見される。

一方、実際に英字姓をすべて大文字で書くことになっている（と思われる）ケースもよく見受けるので、英字姓をすべて大文字で書いているウェブサイト等の例を列挙する。

  • 文化庁の国語施策・日本語教育資料 *5
  • 外務省の大臣・副大臣・政務官のページ（英語版） *6 たとえば茂木大臣は「Mr. MOTEGI Toshimitsu」となっている。
  • 文科省の大臣・副大臣・大臣政務官のページ（英語版）*7たとえば萩生田大臣は「HAGIUDA Koichi」となっている。
  • 世界知的所有権機関(WIPO)に提出する特許国際出願時の氏名*8「国際一郎」が「KOKUSAI Ichiro」となっている。英語版*9は「DAVIS, Catherine」、仏語版*10では「DUPONT, Alain」となっている。姓を最初に書くのがデフォルトということかな。
  • シクロクロス競技の選手リスト*11。ツール・ド・フランスでは大文字始まり*12、オリンピック自転車競技ではgiven nameのみスモールキャピタル*13なので、自転車競技だから一律でこう、というわけでもなさそう。
  • 2020東京オリンピックの選手ページ*14。米国の選手でも「姓が先」「姓が大文字」「カンマなし」という例。
  • 過去のリオオリンピックのメダリストページ*15*16。米国は「姓が後」「姓が大文字」「カンマなし」、日本の選手も「姓が後」「姓が大文字」「カンマなし」。
  • 2020東京オリンピックでメダリストに贈られる賞状*17。
  • MotoGPの選手名一覧*18。
  • フランスのパスポート*19。

以下は参考情報。

  • Medical journalでは姓を大文字にしているケースがある*20という情報を見かけたけれど、medRxiv*21では姓を大文字にしている論文は見つけられなかった。
  • フランスで多いという情報*22。given nameにもsurnameにも使われる名が多いという理由みたい。1993年まで残っていた子の名前に関する制限に起因するんでしょうかね。
  • 一般的ではないという意見として「Gregg's Manual of English」に「架空の名前、死んだ人の名前、偽名」は大文字にする*23という記載があると言っているページ*24*25があったのですが、The Gregg Reference Manualの第10版*26のPersonal Names (¶311）にはそんな記載はないんだよなぁ……（「基本的には本人の書いている通りに書け」と書いてある）。1977年の第5版にもなかった。というか「The Gregg Reference Manual」はあっても「Gregg's Manual of English」というタイトルの本は見つけられなかったので、これはちょっと怪しそう。
  • シカゴマニュアル*27では特に大文字にすべしという記載はない。日本人の名前(p.392)、フランス人の名前(p.389)、ドイツ人の名前(p.390)とも同様。
  • APAのスタイルマニュアル*28にも特に大文字にすべしという記載はない。名前に関する章はないが、Capitalization(p.101)にも6.27 Authro and Editior Information (p.184)にも見当たらなかった。
  • 1930年代の米軍のスタイルガイドによるものでは*29という意見があった。ただ、2021/06/02版の米国国防総省のスタイルガイド*30や、2017/08/10版の米国陸軍のスタイルガイド*31にはそのような記載はなかった。
  • 米国政府のスタイルガイド*32のp.261 "USE OF CAPS AAND SMALL CAPS"に「Mr. BROWN」のような例があるが、これは議事録を書くとき特有のルールなのかな？
  • 欧州委員会のEnglish Style Guide*33の5.1では"Surnames are not normally uppercased in running text (thus Mr Juncker not Mr JUNCKER), unless the aim is to highlight the names (e.g. in minutes)."とある。ただし"At the end of EU legislation, the surname of the signatory appears in upper case."（法律を作るときの署名では大文字にする）ということみたい。
  • OECDのスタイルガイド*34にはそもそも個人の名前に関する記載がない（bibliographyに関する記載くらい？）

各省の大臣・副大臣・政務官のページは、大文字になっているものとなっていないものを並べると面白いかもしれませんね。

続き：国ごとの比較をする方法を思いついたので比べてみた。

satob.hatenablog.com

*1:https://www.eigo-nikki.com/article/14686339.html

*2:https://ameblo.jp/renderrender/entry-10503813143.html

*3:https://boards.straightdope.com/t/why-all-capital-letters-for-surnames/309165

*4:https://srad.jp/story/20/02/10/1212240/

*5:https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kakuki/22/tosin04/17.html

*6:https://www.mofa.go.jp/about/page22e_000390.html

*7:https://www.mext.go.jp/en/about/member/index.htm

*8:https://www.wipo.int/export/sites/www/pct/ja/forms/request/filled_request.pdf

*9:https://www.wipo.int/export/sites/www/pct/en/forms/request/filled_request.pdf

*10:https://www.wipo.int/export/sites/www/pct/fr/forms/request/filled_request.pdf

*11:https://youtu.be/yf0xaRLX6IA?t=75

*12:https://youtu.be/qkMtzxd1D1M?t=21057

*13:https://youtu.be/UgS-_E70P64?t=39

*14:https://olympics.com/tokyo-2020/olympic-games/ja/results/athletics/athlete-profile-n1458024-jewett-isaiah.htm

*15:https://olympics.com/en/athletes/michael-phelps-ii

*16:https://olympics.com/en/athletes/kaori-icho

*17:https://twitter.com/masaru_fencing/status/1421487378598744068/photo/1

*18:https://www.motogp.com/en/Results+Statistics

*19:https://www.1101.com/tonomariko/2020-03-03.html

*20:https://forum.wordreference.com/threads/last-name-first-name-capitals-lastname.2866240/

*21:https://www.medrxiv.org/

*22:https://frenchly.us/why-are-french-last-names-in-all-caps/

*23:"A name spelled in all capital letters or a name initialed, is not a proper noun denoting a specific person, but is a fictitious name, or a name of a dead person, or a nom de guerre."

*24:https://notfooledbygovernment.com/all-capitalized-name/

*25:https://aetherical.blogspot.com/p/p-margin-bottom-0_15.html

*26:William A. Sabin, "The Gregg Reference Manual, Tenth Edition", MacGraw-Hill/Irwin, 2005.

*27:The University of Chicago, "The Chicago Manual of Style SIXTEENTH EDITION", The University of Chicago Press, 2010.

*28:American Psychological Association, "Publication Manual of the American Psychological Association Sixth Edition", American Psychological Association, 2010.

*29:https://boards.straightdope.com/t/why-all-capital-letters-for-surnames/309165/2

*30:https://www.esd.whs.mil/Portals/54/Documents/DD/iss_process/standards/DoD%20Issuance%20Style%20Guide.pdf

*31:https://www.army.mil/e2/downloads/rv7/armydotmil_style_guide.pdf

*32:https://www.govinfo.gov/content/pkg/GPO-STYLEMANUAL-2000/pdf/GPO-STYLEMANUAL-2000.pdf

*33:https://ec.europa.eu/info/sites/default/files/styleguide_english_dgt_en.pdf

*34:https://www.oecd.org/about/publishing/OECD-Style-Guide-Third-Edition.pdf

ISMSに基づく契約書の署名と、個人データの削除

Computer Security

JIS Q 27002:2006の「A.8 人的資源のセキュリティ」の「A.8.1 雇用前」において、「従業員，契約相手及び情報処理施設の第三者の利用者は，セキュリティの役割及び責任についての契約書に署名することが望ましい」とされている*1。

ここで、本人の署名は個人データに含まれる*2。一方で、個人情報保護委員会では個人データは「利用する必要がなくなったときに当該個人データを適切に消去する」ことが重要としている*3。

そのため、以下のタイミングで削除しなければならないのでは？という疑問が生じる。

  • 請負開発のプロジェクト参画時に作成した署名は、プロジェクト終了時には「利用する必要がなくなった」ものとして削除するのでは？
  • 請負開発のプロジェクト参画時に作成した署名に対し、署名した本人がプロジェクト終了をもって削除するよう依頼したら、削除されてしまうのでは？

もちろん、削除してしまうと後でセキュリティ上の問題が発生したときに責任を問えなくなるおそれがあるので、ここで削除されてしまうのはまずい。

調べてみたら、ISMS-ACでも個人情報保護委員会でもJIPDECでもなく、国民生活センターにかなり近い回答があった*4。

利用する必要がなくなった個人データについては、事業者は遅滞なく消去するよう努めなければならないと定められています。ただし、利用者がサイトを退会するときが、事業者が個人データを利用する必要がなくなったときと判断できるかについてはケース・バイ・ケースです。例えば、退会後も個人情報を5年間保管すると事業者が定めている場合には、5年を経過するまでは個人データの削除には応じてもらえない可能性があります。

つまり「ISMSに従って個人の氏名を永年保存する必要がある」と事業者側が判断した場合、その個人データはどうやっても削除されずにずーっと残るということですね。

*1:"法規適合性に関するISMSユーザーズガイド -JIS Q 27001:2006(ISO/IEC 27001:2005)対応-", 財団法人 日本情報処理開発協会, 平成21年4月, 2021/07/23参照, https://www.jipdec.or.jp/archives/publications/JIP-ISMS115-20

*2:https://satob.hatenablog.com/entry/2021/07/23/195939

*3:https://www.ppc.go.jp/news/careful_information/data_syokyo/

*4:http://www.kokusen.go.jp/t_box/data/t_box-faq_qa2018_28.html

JNSA「想定損害賠償額の解説」に例示のない個人データ

Computer Security ないものねだり

個人データが漏洩した際に、個人データの価値の算出に使用する方法としては、JNSAの資料「想定損害賠償額の解説」*1の図2-3に分かりやすい例が載っている。

ただ、最近調べてみようと思った例がこの図の中になかったのでメモしておく。

  • 本人署名の画像データに関する記載がない。
    • 生体認証情報（静脈、声紋、虹彩、網膜、顔画像等）」が経済的損失レベル1-精神的苦痛レベル2にある*2けれど、個人情報保護委員会では署名は「広く特定の個人を識別するに足りる精度で利用されている実態がない」として個人識別符号としていない*3ので、ここでは「氏名」と同等として経済的損失レベル1-精神的苦痛レベル1と考えるのが妥当だろう。
  • 犯罪歴はあるが、犯罪被害の情報がない。

*1:NPO 日本ネットワークセキュリティ協会 セキュリティ被害調査ワーキンググループ, "情報セキュリティインシデントに関する調査報告書 別紙 第1.0版", NPO 日本ネットワークセキュリティ協会, 2019/06/10, 2021/07/23参照, https://www.jnsa.org/result/incident/data/2017incident_survey_sokuhou_attachment_ver1.0.pdf

*2:「音声、声紋」が経済的損失レベル1-精神的苦痛レベル1に含まれており、それとは別に「生体認証情報（静脈、声紋、虹彩、網膜、顔画像等）」が経済的損失レベル1-精神的苦痛レベル2に含まれているのはバグかな？

*3:https://www.ppc.go.jp/files/pdf/280916_siryou1-1_bessi2.pdf#page=7