はじめに
2022年もまもなくおしまい…ということで、ここ1年くらいで話題になったトピックを振り返ってみようと思った…というのが発端。
と言ったものの、やはり以下に集約されるといっても過言ではないと思う。
- Apache log4j 脆弱性（CVE-2021-44228）問題
- 米国防総省のソフトウェア調達におけるOSSを第一優先とする指針
- GitHub Copilot 集団訴訟
Apache log4j 脆弱性（CVE-2021-44228）問題
ことの発端自体は2021年11月下旬から…でしたが、12月10日頃のCVE-2021-44228を修正したバージョン（2.15.0）の公開とともに大きくニュース等に取り上げられるようになり、また、この1度の修正/アップデートでは騒動が収束せず相次いで脆弱性が発覚したことで（特に日本では時差の関係もありいち早く）年末年始の休日に差し掛かってしまったため、多くの組織では越年して今年最初の騒動になっていたのではないでしょうか。
この脆弱性問題を機に、
- 米連邦取引委員会（FTC）が適切な対処を怠った企業に対し法的措置の可能性 (ZDNet)
- グーグルとIBM、重要なオープンソースプロジェクトの特定を呼びかけ--「Log4j」問題を受け (ZDNet)
- 米バイデン政権、「Log4j」問題などを受けGAFAやOpenSSFなどを招いたOSSセキュリティ会議開催 (ITMedia)
-
Linux FoundationとOpenSSF、Open Source Security Summit Japanを開催
OSSセキュリティ改善に向けて日本の企業、政府機関、研究機関のサイバーセキュリティ専門家を招集 (The Linux Foundation)
など、多くの混乱と課題を残しました。
米国防総省がソフトウェア調達で「OSSを第一優先とする」指針
米国の国防総省が、ソフトウェア調達において「OSSを第一優先とする」と言う方針を打ち出したのも印象に残っていますね。
これは、このOSSを優先するということ自体も勿論ですがそれ以上に、国防総省の職員による公務としてのOSSプロジェクトの参加や貢献、国防総省固有のフォークの作成の極力禁止やアップストリームへの貢献の推奨といったところまで踏み込んで言及されていたところがインパクトが大きかったように思います。
出典：https://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev-OpenSource.pdf
SUBJECT: Software Development and Open Source Software
4. CONTRIBUTION TO OPEN SOURCE SOFTWARE PROJECTS
A. Employee participation in OSS projects used by DoD is often in the Government's interest, and is typically a legitimate use of government resources when the Government uses the software in question, either directly, as a component of a larger government system, or as a component of underlying government infrastructure.
(1) Government employees may contribute to existing OSS projects (including being the primary maintainer) as part of their official duties, so long as they consult with their supervisor first to ensure a common-sense approach for contributions that preserve Operations Security (OPSEC) and further the Government's interests.
(2) Contractors may contribute to OSS projects at government expense when the government task monitor authorizes such activity as being in the Government's interest, subject to the scope and provisions of the contract.
B. Creating a separate, DoD-specific version of any OSS project, for any reason, increases support risk and should be avoided whenever possible. Creating such a DoD-specific fork creates risk by requiring separate maintenance, reducing access to software capabilities from the OSS community, and may require the Department to assume full management responsibility of the software's source code, thereby increasing costs.
C. Any improvements or new capabilities added to an OSS project should be contributed back to the upstream open source project via pull/merge request, in accordance with the processes used by that project
このままじゃ分かりづらいので翻訳してみましょう。
ソフトウェア開発とオープンソースソフトウェア
4. オープンソースソフトウェアプロジェクトへの貢献
A. 国防総省が利用する OSS プロジェクトへの従業員の参加は、多くの場合、政府の利益につながるものであり、政府が当該ソフトウェアを直接、大規模な政府システムの構成要素として、または基礎となる政府インフラの構成要素として使用する場合、通常、政府リソースの正当な利用となる。
(1) 政府職員は、運用セキュリティ（OPSEC）を維持し政府の利益を促進する貢献のための常識的なアプローチを確保するために上司と最初に相談する限り、公務の一環として既存のOSSプロジェクトに貢献（主要なメンテナーになることを含む）することができる。
(2) 政府のタスク・モニター(※)が、契約の範囲および条項に従って、当該活動が政府の利益となることを承認した場合、請負業者は、政府費用でOSSプロジェクトに貢献することができる。
(※) 契約管理を行う専門職？のようですB. いかなる理由であれ、OSS プロジェクトの国防総省固有の別バージョンを作成することは、サポートリスクを高めるため、可能な限り回避されるべきである。そのような国防総省固有のフォークの作成は、個別の保守を必要とし、OSSコミュニティからのソフトウェアの機能へのアクセスを減少させ、ソフトウェアのソースコードの完全な管理責任を省が負うことを必要と場合があり、それによってコストが増加するため、リスクを生じさせる。
C. OSSプロジェクトに追加された改良または新しい機能は、そのプロジェクトで使用されているプロセスに従って、プル／マージ要求を通じて上流のオープンソースプロジェクトにコントリビュートされるべきである。
www.DeepL.com/Translator（無料版）で翻訳しました。
ちなみに日本でも公正取引委員会が官公庁のシステム調達においてベンダロックインを問題視＆オープンシステム化を推奨するという動きがありましたね。
GitHub Copilot の集団訴訟
関数名やコメントから関数のコードを自動補完するAIプログラミング機能として2021年に鮮烈デビューを果たしたGitHub Copilotですが、その出力はOSSのコードスニペットを含んでいるにもかかわらず著作権帰属やライセンス（情報・文書）が削除されておりライセンス違反にあたるのではないかという指摘がされていました。この問題が今年ついに集団訴訟につながるという事態に発展しました。
GitHub Copilotに集団訴訟 AI訓練データで初 (クラウドWatch)
GitHub CopilotにかぎらずAIと訓練データとしてのオープンソース・オープンデータの問題は以前から議論がされていましたが、この集団訴訟により一つの判例=結論がでるということになりそうなので継続して注視が必要そうです。
GitHub CEOが来日、会見で開発者体験の重要性をアピール 「開発者を幸福にすることで成功をおさめられる」 (クラウドWatch)
質疑応答では、Copilotで書かれたコードの著作権やライセンスについての質問が記者陣から出た。Dohmke氏はまず、GitHub上で公開されているコードを元にした提案をブロックするCopilotの設定があることを紹介。
とか言ってるみたいだけど、それ以外の出力は大丈夫なのか？権利上問題あるけどコメント行が消されてる＆公開されてないコードだからバレようがないとかそんなんじゃなかったりしないのか？とか疑問がありまくります。
その他＆番外編
以下、ネタ的に無責任に不用意なこと言えないのでリンクのみの紹介。
- SFC、GPL違反めぐる対VIZIO訴訟で大きな一歩 (ZDNet)
OSSとは無関係ですが著作権関連で話題になったものとしてこんなのもありましたね。
いわゆるJASRAC 対 音楽教室、教師の演奏については著作権使用料の請求対象、生徒の演奏については対象外ということで確定しました。
- 音楽教室における著作物使用に関わる請求権不存在確認請求事件 (最高裁判所)
あとがき
今年も結構大きめのトピックがちらほらありましたね。思えばもうLog4j脆弱性問題の発覚から1年以上経っているということに今頃気づいて打ち震えています。時が経つのは早い…。
Introduction
The year 2022 will soon come to an end, so I thought I would take a look back at the topics that have been discussed over the past year or so....
However, I think it is no exaggeration to say that the topics can be summarized as follows.
- Apache log4j vulnerability (CVE-2021-44228)
- U.S. Department of Defense's guideline to give first priority to OSS in software procurement
- GitHub Copilot class action lawsuit
Apache log4j Vulnerability (CVE-2021-44228)
The issue itself started in late November 2021... but with the release of the version (2.15.0) that fixed CVE-2021-44228 around December 10, it was widely reported in the news and other media, and the uproar was not resolved with this single fix/update. The vulnerabilities were discovered one after another without being resolved in a single fix/update, and because of the time difference, especially in Japan, the vulnerabilities were discovered during the year-end and New Year holidays, many organizations probably had to wait over the New Year's holidays to see the first disturbances of the year.
The vulnerability issue left a lot of confusion and challenges, including the following
- Possible legal action by the Federal Trade Commission (FTC) against companies that fail to take appropriate action (ZDNet)
- Google and IBM call for identification of critical open source projects -- in response to "Log4j" problem (ZDNet)
- U.S. Biden administration holds OSS security conference with GAFA, OpenSSF and others in response to "Log4j" and other issues (ITMedia)
-
The Linux Foundation and OpenSSF Host Open Source Security Summit Japan
Convening Cyber Security Experts from Japanese Companies, Government Agencies and Research Institutions to Improve OSS Security (The Linux Foundation)
U.S. Department of Defense Guideline to "Make OSS First Priority" in Software Procurement
The U.S. Department of Defense's policy of "giving first priority to OSS" in software procurement has also left a lasting impression.
This policy was more than just the priority given to OSS, of course, but the fact that it went as far as to prohibit DoD employees from participating in and contributing to OSS projects as part of their official duties, to prohibit the creation of DoD-specific forks as much as possible, and to encourage contributions to upstream.... I think the impact was significant.
Source: https://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev-OpenSource.pdf
Software Development and Open Source Software
4. CONTRIBUTION TO OPEN SOURCE SOFTWARE PROJECTS
A. Employee participation in OSS projects used by DoD is often in the Government's interest, and is typically a legitimate use of government resources when the Government uses the software in question, either directly, as a component of a larger government system, or as a component of underlying government infrastructure.
(1) Government employees may contribute to existing OSS projects (including being the primary maintainer) as part of their official duties, so long as they consult with their supervisor first to ensure a common-sense approach for contributions that preserve Operations Security (OPSEC) and further the Government's interests.
(2) Contractors may contribute to OSS projects at government expense when the government task monitor authorizes such activity as being in the Government's interest, subject to the scope and provisions of the contract.
B. Creating a separate, DoD-specific version of any OSS project, for any reason, increases support risk and should be avoided whenever possible. Creating such a DoD-specific fork creates risk by requiring separate maintenance, reducing access to software capabilities from the OSS community, and may require the Department to assume full management responsibility of the software's source code, thereby increasing costs.
C. Any improvements or new capabilities added to an OSS project should be contributed back to the upstream open source project via pull/merge request, in accordance with the processes used by that project
Incidentally, in Japan, there was a move by the Fair Trade Commission to consider vendor lock-in as a problem in procuring systems for public offices & to encourage open systems.
GitHub Copilot Class Action Lawsuit
GitHub Copilot made a strong debut in 2021 as an AI programming function that automatically completes function code from function names and comments, but its output has had its copyright attribution and license (information and documentation) removed even though it contains OSS code snippets, and It has been pointed out that this may be a violation of the license. This issue finally led to a class action lawsuit this year.
GitHub Copilot Sued in Class Action First for AI Training Data (Cloud Watch)
The issue of open source and open data as AI and training data has been discussed for a long time, not only for GitHub Copilot, but it seems that this class action lawsuit will set a precedent and conclusion, so we will have to keep an eye on it.
During the Q&A session, reporters asked about copyright and licensing of code written in Copilot, and Dohmke began by saying that There is a setting in Copilot that blocks proposals based on code published on GitHub.
He seems to be saying that the rest of the output is ok? Isn't it possible that there is a rights issue but the comment line has been erased & the code is not publicly available so it can't be discovered or something like that? I have so many questions.
Other & Extra
The following are links only, as I cannot say anything irresponsible or careless in terms of material.
This is not related to OSS, but there was also this one that became a hot topic in copyright-related issues.
The so-called "JASRAC v. Music Schools" case was decided, in which teachers' performances are subject to copyright royalty charges, while students' performances are not.
- Case of claim for confirmation of non-existence of claim relating to use of copyrighted works in music schools (Supreme Court)
Postscript
There have been quite a few big topics here and there this year. I am trembling now that I realize that it has already been more than a year since the Log4j vulnerability was discovered. Time flies...
www.DeepL.com/Translator（無料版）で翻訳しました。