自由な Fedora Linux を作る GNU Linux-libre プロジェクトの「Freed-ora」が終了した (Alexandre Oliva 氏のメーリングリスト投稿、 Phoronix の記事)。

現在の Freed-ora は Fedora 環境にインストールすると非フリーの RPM がインストールされていないか確認し、GNU Linux-libre カーネルをセットアップしてデフォルトのカーネルに設定。以降は非フリーのパッケージがインストールされないよう RPM のライセンスタグを確認するとのこと。

メインテナーを務めた Free Software Foundation Latin America の Alexandre Oliva 氏によれば、Freed-ora 開始当時の Linux は現在よりも多くのブロブを使用していたという。しかし、Freed-ora を Fedora プロジェクトの一部として維持するという提案は断られ、ソフトウェアの自由に対する Fedora の姿勢を知ることになった。Fedora から名前を変更するように求められたこともあるそうだ。

Oliva 氏は既に Fedora を使っておらず、代わりのメインテナーを探しても見つからなかったため Fedora 35 のライフサイクルが終わるまでという条件で引き続きメインテナーを務めていたという。このたび、Fedora 35 のライフサイクルが終了し、Freed-ora も終了する運びとなった。当面 Freed-ora のリポジトリは残されるが、Oliva 氏は RPM Freedom への移行を推奨している。

オープンソースのバグ管理システムであるBugzillaは長い期間更新されていなかったが、プロジェクトリーダーのDave Miller氏は13日、公式サイト内でプロジェクトを再起動させる方針を示した。Dave Miller氏自身に人生の変化があり、このプロジェクトにこれまでより多くの時間を費やすことができるようになったためだとしている（Bugzilla公式、DEVCLASS）。

同氏は古いSSLライブラリが原因でIRCボットが機能しないといったいくつかの問題を既に修正しているという。リリース前に悪意のあるユーザーに公開されるのを避けるために、テストスイートの仕様も変更されたとしている。新しいバージョンは来年の1月中旬までには出したい意向であるとしている。

Tom's Hardwareの記事によると、IntelはArc Alchemist GPUの大規模なドライバアップデートをリリースし、DX9ベースのタイトルで2倍近いFPS向上を果たしたという。Intelは、最新のグラフィックスドライバに、SteamがWindowsゲームをLinux上で動作させるために使用している変換レイヤーDXVKを搭載したとしている。DXVKを使うことにより、一定のパフォーマンスアップの成果が出ることは過去記事でも取り上げられている。なおTom's Hardwareによれば、Intelの新しいドライバでは、DX12 エミュレーション技術より優れたパフォーマンスを提供可能な場合のみDXVKを使用しているそうだ（Intelドライバードキュメントテキスト、Tom's Hardware、Tom's Hardwareその2）。

blueflow 曰く、

dxvkはsteamdeckのprotonなどにも使用されている
vulkan-apiのオープンソースdirectx(11, 10, 9)実装(https://github.com/doitsujin/dxvk)

dxvkはwineと動かす他にも、ゲームのvulkan-apiへの移行などにも使われている
(
        portal-rtxはdxvkを使ったvulkan-apiへの移行 + vulkanのray-tracing拡張機能でリリースされた他,
        Portal 2 (Valve — Windows & Linux)
        Left 4 Dead 2 (Valve — Windows & Linux)
        Ys VIII, Ys IX (PH3 Games — Stadia)
        Trails of Cold Steel 3 & 4 (PH3 Games — Stadia)
        Perimeter (Linux)
　　,,,
)

-----------------------------------------------------------------------------------------------------------------
ちなみにdxvkのオリジナルは doitsujin( Philip Rebohle ) さんが個人プロジェクトとしてdx11->vulkan実装として開始され,
nier-automataなどが動くようになったぐらいの時期にvalveから正式に雇われ始めたようだ。
dx9->vulkan実装はあとから Joshua-Ashton さんによって追加された
ちなみにJosha-Ashtonの年齢はまだ20歳くらいである)

米GitHubのCEO、Thomas Dohmke氏が、2021年11月にCEOに就任後、初来日した。12月6日に事業戦略や今後のソフトウェア開発に対する展望を語る記者会見を開催し、その中でGitHub上の開発者は、2013年に280万人だったのが、現在は9400万人以上になったと述べた。そのうち日本の開発者は200万人以上であるという（ASCII.jp、クラウド Watch）。

Dohmke氏は「ソフトウェア開発者が幸福を感じ、よりクリエイティビティを高めていく」ためのプロダクトを提供するとし、今後は「4つの柱」を定めて戦略的な投資を進めると語った。具体的には「開発者向けクラウド」「AI」「コミュニティ」「セキュリティ」で、ドムケ氏は、これらは互いに関係し合っていて欠かせないものだと説明している。

JR秋葉原駅で、エスカレーターに立ち止まって乗っていた男性に「邪魔だ」と言ってトラブルになり、暴行を加えて大けがを負わせたとして61歳の男が逮捕されたそうだ。容疑者は下りのエスカレーターを歩いて降りている最中、立ち止まって乗っていた男性に「邪魔だ」と言って追い越そうとしたところ、被害者から「エスカレーターは歩くものではない」と注意されたことでカッとなった模様（NHK）。

hifun 曰く、

60代の男性（自称：会社役員）が、80代の男性を、秋葉の駅でエスカレータの使いかたで揉めてキレちゃって投げとばすだー蹴りを入れるだーして捕まったそうです。なんで揉めちゃうかな。

駅の客同士のトラブルなんてべつに珍しかないんで、へえニュースになるんだー、ってくらいですけど、ニュースで「秋葉原駅で」って見出しが載るとなんか胸がどきどきするようになっちゃったのは僕だけでしょうかねー。あーやだやだ。

openSUSE がローリングリリース版 Tumbleweed でシステム要件の x86-64-v2 移行を進めている (openSUSE Factory メーリングリスト投稿、 openSUSE News の記事、 The Register の記事)。

x86-64 マイクロアーキテクチャは 4 つの世代に区分され、Tumbleweed およびその他の openSUSE ディストリビューションは現在のところ第 1 世代の x86-64-v1 ハードウェア (AMD K8 以降) 用にビルドされている。今夏 SUSE ではシステム要件を一気に x86-64-v3 (Intel Haswell 以降) まで引き上げることを議論していたが、最終的に x86-64-v2 (Intel Nehalem 以降) への引き上げで落ち着いた。Tumbleweed の x86-64-v2 移行もこれに追従するものだ。

移行に伴い、i586 (32 ビット CPU) のサポートも終了する。openSUSE Factory リポジトリは x86-64-v2 に転用され、x86-64-v1 ハードウェアのユーザー向けには新たにレガシー x86 用のリポジトリが作られてボランティアが維持していくことになる。新しいリポジトリ名は確定していないが「openSUSE:Factory:LegacyX86」のような名前になるという。そのため、i586 / x86-64-v1 ハードウェアのユーザーは新しいリポジトリ公開後にリポジトリリストを更新する必要もある。

あるAnonymous Coward 曰く、

2014年のMaxwell-v2(第2世代Maxwell)以降、NvidiaはGPUの周波数変更などの電源管理機能にアクセスするため署名付きのFirmwareを必要とするようになった。しかし、Nvidiaのクローズドなドライバから暗号化鍵やFirmwareを抽出することは、技術的にも、それを配布することはライセンス的にも困難となり、オープンソースカーネルドライバでの周波数変更ができなくなり、起動時の低い周波数に固定されることで、性能を出すことが不可能になった（Phoronix、Phoronixその2、True DMABUF support、Clarification on GPU support for Maxwell/Pascal archs and binary/OS relationship）。

その他のAMD製GPUやIntelのGPUは、Firmwareを再配布可能なライセンスにし、また両者とも(AMDは2015年以降、Intelはもっと前から)カーネルドライバをオープン(GPL)にしているため、そのような問題はない。カーネルドライバがクローズドなことの問題点はセキュリティや、バグを直すことができないことの他にも、DmabufなどのカーネルのAPIはGPLでライセンスされているため、クローズドなカーネルドライバでは提供することができないという点もある。

Nvidiaは2022年、カーネルドライバのオープンソースバージョンを並行して提供するようになった。それは、GPUのメモリや電源管理機能の多くを、カーネルドライバから、GPUの内部Firmware(NvidiaはGSP(GPU System Processor)と呼ぶ内部CPU)に移したことで、可能になった(秘密にしておきたい内部を切り離した)。これにより、オープンソースカーネルドライバで周波数変更ができるようになり、また、DmabufなどのGPLライセンスされたAPIを実装しサポートすることを妨げるライセンス上の問題はなくなった。

しかし、GSPはTuring-architecture以降に導入されたものであり、NvidiaのオープンカーネルドライバではPascal以前はサポートできない。したがって、PascalとMaxwell-v2はオープンソースドライバでは周波数変更できず、クローズドソースドライバでは、Dmabufなどがサポートされていないという現状にある。さらに、それらの制約は技術的なハードの問題ではなく、ライセンスとNvidiaの反オープンソース的経営方針によるものだ。

この間、Intelはオープンソースカーネルドライバを提供し続け、またユーザースペースでも(Mesaでのi965, Iris, ANV)などオープンソースに貢献し続けた。また、AMDも2015年からカーネルドライバをオープンにし、ユーザースペースドライバを作るための情報を提供し、コミュニティベースのMesaでのRADVなどが販売中 - Steam Deなどにも使われている。このまま、PascalやMaxwell-v2は数年後Nvidiaのサポート対象から外れ、オープンソースカーネルドライバでの周波数変更もできないまま、死んだハードウェアになっていくのだろうか？

AWSはLinuxコンテナの構築、実行、公開のためのクライアント「Finch」をオープンソースで公開した。Finchはローカルマシンにコンテナを用いた開発環境を導入するためのDocker Desktopのようなツールで、コンテナを用いた開発環境をオープンソースのソフトウェア群を組み合わせることで簡単に構築し、コマンドラインから利用できるようになるという。Docker Desktopによる簡単な環境構築を代替できるとしている。現時点ではIntelプロセッサもしくはAppleシリコン搭載のMacにのみ対応している（AWSリリース、Publickey）。

あるAnonymous Coward 曰く、

現時点ではMacのみ対応だが、今後WindowsやLinuxも対応予定とのこと。Docker自体は無償だが、"> 、開発ツールとしてのDocker Desktopは昨年に有償化されていたため、代替ツールが登場するのはユーザー的にはありがたいことであるが、また揉めそうな話である。

Metaが自社で使用してきたソースコード管理システム「Sapling」をオープンソース化した。2022年11月15日から一般向けに公開されている。Metaで使われるような大規模リポジトリの管理は一般的なソースコード管理システムでは難しいことから、このツールは同社が10年間にわたり開発・使用してきたという。リポジトリの把握、コミット、ミスの回復といったワークフローが大幅に容易になるよう作られていると説明している（Sapling公式、Engineering at Meta 、GIGAZINE）。

あるAnonymous Coward 曰く、

>Git互換で基本的なコマンドなどもGitに類似しているとのこと。Git一強な感じの昨今だが、比較してどうだろうか？

Linux Foundation (LF) の支援を受けることの是非について、FOSS コミュニティで意見が分かれているそうだ (The Register の記事)。

LF の Open Source Security Foundation (OpenSSF) では、20 年以上にわたって重要な FOSS 開発者ツールをサポートしてきた Sourceware に支援を申し出ているという。OpenSSF の目的はモダンな IT インフラを Sourceware プロジェクトに提供することでオープンソースソフトウェアのセキュリティを改善することだ。

Red Hat が提供する Sourceware のインフラを利用してきた GNU Toolchain Infrastructure (GTI) は 9 月、LF の提供するインフラに移行する計画を示している。しかし、Sourceware コミュニティのメンバーの中には OpenSSF の支援を受けることで企業からの影響が強まることを懸念する人もいるようだ。そのため、よりソフトウェアの自由に一致するとの考えで、Software Freedom Conservancy (SFC) の支援を受けることも提案されている。

LF は非営利組織だが、Microsoft や Oracle などがプラチナメンバーに名を連ねる。そのため、非営利組織の中でも営利企業の共通の利益を追求する業界団体のようなものだと SFC の Bradley M. Kuhn 氏は指摘する。また、オープンソースの定義を書いた Bruce Perens 氏は 2017 年、LF の状況を「樹木の代弁者だと主張する木こりのようだ」と評している。

一方、SFC は Google や Mozilla などがスポンサーに名を連ねているが、組織としては慈善団体だ。Kuhn 氏はソフトウェアの自由が保てるかどうかについて、非営利組織とのガバナンスの違いが重要だと述べている。なお、Red Hat は LF のプラチナメンバーであり、SFC のスポンサーでもある。

GitHubのコードを学習データとして用いたAIコード補完サービス「GitHub Copilot」が訴訟の対象となったそうだ（GitHub Copilot litigation、Joseph Saveri法律事務所、GIGAZINE）。

GitHubとその親会社であるMicrosoft、開発に携わったOpenAIに対して集団訴訟が提起された。記事によればAI生成サービスにまつわる訴訟はこれが初めてらしい。訴状によればMITライセンス、GPL、およびApacheライセンスなど11の一般的なオープンソースライセンスでは、作者の名前と著作権の帰属表記が必要だと主張。しかし、GitHub Copilotではこれらのライセンスの帰属要件に違反しているうえ、月額10ドル(約1480円)または年額100ドル(約1万4800円)のサービスを展開、運営者らはオープンソースライセンスを侵害し、さらにはオープンソースプログラマーの仕事から利益を得ていると主張している。

あるAnonymous Coward 曰く、

確かにAI学習にオープンソースのコードを使用しており、出力されるソースコードもコピペ感があるものが多い状況だが、果たしてこれがOSSライセンス侵害と認められるか？議論を呼びそうである。

maia 曰く、

市バスのドライバーが出勤途中に蒸しパンを食べてアルコールが検知されて勤務できなかったという話がある (日テレNEWS の記事)。

酒気帯びの基準は呼気中アルコール濃度 0.15mg/L だが、市バスの内規は0.07で、検知されたのは0.11だった。日テレが実際に蒸しパンを食べて測定してみたところ、0.05と出たという。食品製造には酒精 (=エタノール) が使われる事がある。体重や体質、パンの製法、保存性、個数にもよるだろうが、すぐ運転する予定があるなら、どんなパンをどれだけ食するのか注意した方が良さそうだ。パンのほか、漬物も要注意。

The GNOME Project がメーリングリストの 10 月末廃止をアナウンスしている (The Register の記事)。

メーリングリスト廃止の理由として、他のプロジェクトと同様にメーリングリストで Mailman を使用しており、Python 2 に依存するプログラムは持続可能でないこと、プロジェクトで Discourse を導入してからの数年間は Mailman の使用が減少していることが挙げられている。メーリングリストのサブスクライバーは Discourse に招待される。

新プラットフォームでは Mailman にはなかったゲーミフィケーションやマークダウンサポート、RSS フィード、まともなスパム対策、複数の認証タイプといった機能が利用可能になるという。なお、Mailman 3 はPython 3.7 以降を使用するが、プロジェクトで使用しているのは Mailman 2 のようだ(よくある質問)。

廃止は各メーリングリストで案内(例: desktop-devel-list)されているが、多数のメーリングリストの中には今回の廃止案内が投稿されるまで数か月間投稿がなかったリストもみられる。なお、10 月末の期限を過ぎるとリストはリードオンリーになるが、i18n 関連のリストは 11 月半ばまで残る見込みとのことだ。

国際捕鯨委員会（IWC）に破産の恐れがでているという。IWCは10月13日、2019年に日本が脱退して以降、初めての対面形式での総会を実施した。朝日新聞の記事によれば、この総会ではいつもの捕鯨の規制についての議論のほか、新たに財政状況が課題として浮上しているという。財政難の背景には日本の脱退による影響のほか、分担金の未納問題などが浮上しているようだ（朝日新聞、EIA）。

EIAの記事によると、27か国が分担金の支払いを滞納しており、87万7000ポンド（約1億4800万円）以上の未払い残高が残っているという厳しい状況に直面している。会費の未納は世界的なパンデミックによって悪化しており、最初の議題として会費未納の締約国政府の議決権を回復するかが議論される予定とのこと。

VideoLAN のウェブサイトや VLC Media Player のダウンロードリンクがインドでブロックされている問題について、VideoLAN 議長の Jean-Baptiste Kempf 氏が組織を代表してインド通信相電気通信局 (DoT) に法的な通知書を送付したそうだ (通知書、 Internet Freedom Foundation の記事、 Ars Technica の記事、 The Register の記事)。

通知書ではインド政府が VLC を推奨オープンソースソフトウェアに指定 (PDF) しているにもかかわらずブロッキング対象になったこと、ブロッキングにあたって政府の担当者が対象者への通知など適切な処理を行っていないこと、ブロッキングが言論の自由の制限にあたることなどを問題点として挙げている。

そのため、Kempf 氏は DoT にブロッキングを再考し、ブロッキング命令の発行理由が記載された文書の写しやビデオ会議などを通じた反論の機会を提供するよう求めている。要求が満たされない場合、法的手段をとることも辞さないとのことだ。