以前はRaspbianと呼ばれていたRaspberryPi OSだが、2021年1月25日に行われたアップデートによりオープンソースファンから反発されている。ユーザーがアプリまたはOS自体を更新するたびに、Microsoftサーバーにpingを送信していたためだという（PCMag、GIZMODO）。

Raspberry Pi Foundationは、RaspberryPi OSにデフォルトでMicrosoftのVisual Studio Codeエディターを導入した。しかし、その結果、Visual Studio Codeエディタが格納されているリポジトリに接続確認するようになったようだ。ユーザーへの確認を取らない形で接続する仕様になっていたことから、強い批判が起きている模様。

Microsoftは長年利用してきたNoSQLデータベースエンジン「Extensible Storage Engine」（ESE）のソースコードが公開された（GitHub、ESE、Publickey、Petri、＠IT）。

このデータベースは様々なMicrosoft製品に利用されてきたもの。ESEは「JET（Joint Engine Technology）API」を実装したもので、以前は「JET Blue」と呼ばれていたという。JET APIには「JET Red」という実装もあり、このJET RedはMicrosoft Accessに使われてきたものだという。

今回ソースコードが公開されたのはこの2種類のJET APIのうち、ExchangeやActive Directoryなどで利用されてきた「JET Blue」を実装したものだそう。＠ITによれば、JET BlueとJET、JET Redは名称的な混乱が起きる可能性があることから、今回JET BlueはESEに改称されたとのこと。

headless 曰く、

シンガポール政府がCOVID-19検査結果証明書とワクチン接種証明書をデジタル化して世界規模で相互運用可能にするオープン標準「HealthCerts」を開発したそうだ(Smart Nationのプレスリリース、 CNAの記事、 Straits Timesの記事、 The Registerの記事)。

HealthCertsはシンガポール政府のSmart Nationと保健省(MOH)が共同開発したもので、GovTech Singaporeが開発したブロックチェーン技術を用いるオープンソースの文書公証フレームワーク「OpenAttestation」をベースにしているという。HelthCertsの公証システムは医療機関が発行した証明書を認証し、検証システムが真正性の確認を可能にする。Smart Nation担当大臣のVivian Balakrishnan氏は2月26日、デジタルIDシステムSingPassのモバイルアプリ「SingPass Mobile」でHealthCertsの公証による出国前テスト(PDT)結果証明書が利用可能になることを発表した(動画)。ワクチン接種証明書への拡大も計画しているという。なお、PDTを行うシンガポールの医療機関では、3月10日からHealthCertsに準拠したデジタル証明書の発行を開始するとのことだ。

headless 曰く、

1月19日にリリースされたオープンソースの暗号ライブラリLibgcrypt 1.9.0で深刻なヒープバッファーオーバーフロー脆弱性(CVE-2021-3345)が見つかり、29日に修正版のバージョン1.9.1がリリースされた(アナウンス、 Project Zero - Issue 2145、 The Registerの記事)。

GoogleのProject Zeroが発見した脆弱性は汎用ブロックバッファー抽象化コードに含まれており、ブロックバッファー内で占有されたスペースがアルゴリズムのブロックサイズを超えることがないという誤った前提が原因で、データを復号する際に発生する。オーバーフローするバッファーは直後に呼び出される関数のポインターと隣接しているため、容易に悪用が可能だという。

Project Zeroから1月28日に連絡を受けたGnuPG Projectは翌29日に使用中止の呼び掛けを行い、数時間後にバージョン1.9.1をリリースしている。バージョン1.9.0がリリースされたのは1月19日だが、脆弱性は1.9の開発段階でおよそ2年前に導入されていたそうだ。そのため、1.8 LTSブランチは影響を受けないが、GnuPG Projectでは少なくともバージョン1.8.5以降を使用するよう求めている。

リリース直後ということもあって影響範囲は広くないが、既にバージョン1.9.0を使用していたGentooや、macOS用パッケージマネージャーのHomebrewでは対策が行われている。Fedora 34にもバージョン1.9.0が含まれていたが、正式リリース前だったため影響は小さかったとのこと。ただし、バージョン1.9.1では脆弱性修正と無関係な変更も行われており(リリースノート)、Intel CPUでコンパイルエラーが発生するという問題も確認されているとのことだ。

オンラインバージョンのVSCodeで、GitHubの任意のコードを表示できる「GitHub1s」というサービスが始まったそうだ。使用方法は簡単でURLのhttp://github.comをhttp://github1s.comに変更するだけでいいという。これによりgithubにあるファイルをオンライン版VS Codeに読み込んでくれる（kabukawaさんのツイート、GitHub1sプロジェクトアドレス、tproger.ru、Sina.com）。

統合用WebIDE「Gitpod」のようなより高機能なものも存在しているが、こちらは読み込みに数分を必要とすることもある。一方でGitHub1sは読み込み時間は数秒程度と非常に高速。またChromeユーザーの場合は、GitHub1sに対応した専用の拡張機能も用意されている。この拡張機能を追加すると、GitHubインターフェースに[Open withGitHub1s]ボタンが表示される。それを押せば、URLが追加されてVSCodeのオンラインバージョンでリポジトリを開くことができるそうだ（ITnews）。

headless 曰く、

Open Source Initiative(OSI)がCERN Open Hardware License Version 2(CERN-OHL V. 2)をオープンソースライセンスとして承認し、1月28日に承認済みライセンスのリストへ追加した(The Registerの記事)。

CERNが策定したCERN-OHLは2011年に最初のバージョンが公開された。昨年3月に公開されたバージョン2.0では用語がより平易になっており、ライセンス条件の異なる3つのバリアント「CERN-OHL-P(パーミッシブライセンス)」「CERN-OHL-W(弱い相互主義ライセンス)」「CERN-OHL-S(強い相互主義ライセンス)」が用意されている。CERN-OHLを適用することで共有するハードウェア設計の利用・コピー・改変・配布条件や、設計に基づく製品の製造・配布条件を定めるもので、知的財産侵害のリスクを低減しつつ、利用の自由度を高めることが可能だ。

CERNでは既存のオープンソースライセンスがソフトウェアを対象としているため、ハードウェアに適用する場合は読み替えが困難なこともあるとして、ハードウェアとソフトウェアの組み合わせに適用可能なOHLを策定したという。ただし、OHLはソフトウェアライセンスとしてのみ使用することもできるよう作られており、OSIではOHLをソフトウェアライセンスとして承認したそうだ。実際のところ、OSIが扱うのはソフトウェアライセンスのみであり、OHLのハードウェアライセンスとしての有効性については保証できないとのことだ。