あるAnonymous Coward曰く、

AWSやAzureでマネージドサービスも提供されるなどNoSQLサーバーとして広く使われている「Redis」だが、開発元のRedis Labsは22日、これまでAGPLで提供していた同社開発の拡張モジュールを、今後はクラウド事業者による商用利用に制限のかかるCommons Clause条項付きのApache 2.0ライセンスに移行することを発表した（プレスリリース、OSDN Magazine、ZDNet、Register）。

移行の対象となるのは「RediSearch」「Redis Graph」「ReJSON」「Redis-ML」「Rebloom」などの拡張モジュールで、コア部分には引き続きBSDライセンスが採用される。Redis Labsでは変更の理由として「クラウド事業者はほとんどこれらのオープンソースプロジェクトに貢献していない」と述べており、クラウド事業者によるフリーライドに耐えかねた事を吐露している。Redis Labsは自身でもRedisのマネージドサービスを提供しており、こうした競合他社に圧迫されていることが伺える。

なお、商用利用に制限がかかる事から新ライセンスはOSSライセンスとは適合しなくなっている。これに対して、OSS界隈では反発の声もあるようだ。

あるAnonymous Coward 曰く、

Apache HTTP Serverに複数の脆弱性が発見された。この問題を修正したHTTP Server 2.4.33が公開されており、アップデートが推奨されている（JVNVU#95818180、窓の杜）。

タレコミ人の使うDebianではsid（開発ブランチ的位置付け）でさえまだ対策版が存在しない。影響範囲の大きいWebサーバーの脆弱性ですが、ディストリの対応を考慮せず公開してしまうという慣例はなんとかならんもんでしょうかね。

問題の脆弱性は、悪用することでDoS攻撃を可能にするものや、認証を回避される可能性があるといったもの。危険性はセッション改ざんのおそれがある「CVE-2018-1283」が「medium」で、残りはいずれも「low」となっている。なお、CHANGELOGなどではバージョン2.4.30でこれらが修正されたとなっているが、バージョン2.4.30～2.4.32は開発者向けのみにリリースされている。

headless曰く、

やや旧聞となってしまったが、Java EEの新名称がJakarta EEに決まったそうだ（Life at Eclipse、 ADTmag、Register、OSDN Magazine）。

OracleではJava EEをEclipse Foundationへ移管するにあたり、名称に「Java」を含まない新しいものにすることを求めていた。これを受けてEclipse Foundationでは昨年11月にGitHubで新名称候補を募集し、「Jakarta EE」と「Enterprise Profile」を最終候補として選定、2月にオンライン投票を実施している。投票の結果は総計6,959票のうちJakarta EEが64.4%を占めたという。

JakartaはJava関連のオープンソースプロジェクトとしてApache Software Foundation（ASF）が商標権を保持しており、Eclipse FoundationではASFの許可を得て使用することになる。コミュニティからはJakartaが妥協だと反対する意見も多かったが、投票開始後は弱まっていたそうだ。Jakarta EEは「JEE」「EE」などと略せるだけでなく、「J」を含む略称を自由に使うことができるようになり、Jakartaブランドの拡張も可能になるとのことだ。

Eclipse FoundationがJava EEの新名称を決めるため、オンライン投票を実施中だ(Brand name selection; Phase 2、 The Registerの記事、 投票ページ)。

OracleはJava EEをEclipse Foundationに移管する一方で、名称については「Java」を使用しない新しいものにするよう求めている。Eclipse FoundationではJava EEを引き受けるにあたって「EE4J (Eclipse Enterprise for Java)」プロジェクトを開始しているが、EE4J自体はJava EEだけでなく、より幅広いJavaのオープンソースプロジェクトを含む。そのため、Java SEのオープンソース実装がOpenJDKと呼ばれるように、Java EEにも新しい名前が名称が必要になるとのこと。

EE4Jは昨年11月15日～30日にGitHubで新名称候補の募集を行っており、その中から「Jakarta EE」と「Enterprise Profile」の2点が候補として選ばれている。「Jakarta」はApache Software Foundationがかつて運営していたオープンソースのJava関連プロジェクトで、現在もApacheが商標権を保持しているが、使用しても差し支えないとの回答を得ているようだ。

投票の締め切りは2月23日まで。投票するにはGoogleアカウントにサインインする必要がある。スラドの皆さんはどちらが良いだろうか。

headless曰く、

セキュリティ企業UpGuardのCyber Risk Teamは17日、米軍が過去8年にわたり収集した大量のインターネット投稿を含む3つのAmazon S3バケットが公開状態になっていたことを公表した（UpGuard — Breach Analysis Blog、The Register、Ars Technica）。

3つのバケットのAWSサブドメインは「centcom-backup」「centcom-archive」「pacom-archive」となっており、AWSアカウントでログインすれば誰でも閲覧可能な状態になっていたという。CENTCOMは米中央軍、PACOMは米太平洋軍の略称だ。データは米政府の委託業者「VendorX」が管理していたものとみられている。

VendorXに関する情報は少ないが、従業員のLinkedInページによれば、米中央軍および米国防総省の委託を受けて「Outpost」という多言語のソーシャルアナリティックスプラットフォームを開発・運用していたようだ。Outpostは世界の不安定な地域で（テロリストになる）リスクの高い若者に良い影響を与えることを目的として作られたとされる。

インターネット投稿はニュースサイトのコメント欄やソーシャルメディアなどからスクレイプされたもので、centcom-backupおよびcentcom-archiveでは中東や南アジアからの投稿が中心だが、米国市民による投稿も含まれていたそうだ。一方、pacom-archiveでは東南アジアや東アジアからの投稿が中心で、オーストラリアからの投稿も含まれていたとのこと。ただし、投稿の中には紛争とは無縁な地域からのものや、全く無害な内容のものも多数含まれており、無関係な投稿を大量に収集していた理由は不明だ。

centcom-backupにはスクレイピングされたインターネット投稿のほか、Outpost関連とみられるファイルや、諜報対象者のつながりを分析する「Coral Reef」関連とみられるファイル、Apache Luceneのインデックスファイルも含まれていたという。一方、centcom-archiveとpacom-archiveには未処理のインターネット投稿が大量に含まれており、centcom-archiveだけで少なくとも18億件に上るそうだ。

AWSでは誤設定によりデータが公開状態になるトラブルが繰り返し発生しており、警告表示などの対策が追加されているが、UpGuardが問題を発見したのは対策適用前の9月6日だったという。UpGuardは問題を米軍に通知し、現在バケットは非表示化されている。UpGuardのChris Vickery氏によれば、米軍に対する連絡は一方通行になるものだが、今回は珍しく感謝の返信が届いたとのことだ。

Apache OpenOfficeプロジェクトが10月19日、Apache OpenOffice v4.1.4をリリースした（窓の杜、Apache OpenOfficeブログでの告知）。リリースノートによると、重要なバグ修正やセキュリティ修正などを含むメンテナンスリリースとなるとのこと。

ただ、このバージョンは昨年9月にリリースが告知されていたもので、昨年10月時点で「現在はv4.1.4とそれに続く大型アップデートの準備が進められている」と言われていた。メンテナンスリリースに1年近い歳月を費やしたわけで、窓の杜の記事では「同プロジェクトは人員不足による存続が危ぶまれていたが、状況は依然厳しそうだ」と評されている。

あるAnonymous Coward 曰く、

Facebookは23日、ライセンスが問題になっていたJavaScriptライブラリ「React」について、特許条項付きBSDライセンスからMITライセンスに移行することを発表した(Facebook Codeの記事、 The Registerの記事)。

Reactのほか、JestやFlow、Immutable.jsもMITライセンスに移行する。Reactでは来週リリースされるReact 16以降でMITライセンスが適用されるとのことだ。

MITライセンスはApache製品で使用可能なライセンスと認められることから、Apache Software Foundation傘下のプロジェクトではReact 16以降を使用できるという方向で話がまとまっているようだ。

多数のオープンソースソフトウェア開発プロジェクトを傘下に持つApache Software Foundation（ASF）が、Facebookの「オープンソースソフトウェアライセンス風のソフトウェア」は利用すべきではないという方針を定めた（Facebookの特許条項付きBSDライセンスが炎上している件について）。

Facebookが公開しているソフトウェアのライセンスはBSDライセンスをベースとしているが、それに加えてFacebookやその傘下の企業などとの間で特許紛争が発生している会社はそのソフトウェアを利用できないという条項が追加されている。これは「PATENTS」というファイルに記載されており、以前から話題にはなっていたのだが（参考：2016年にQiitaに投稿されたスライド）、今年7月にASFがこの条項を問題視し、この条項が付いたソフトウェアはASF傘下のオープンソースソフトウェア開発プロジェクトでは利用を認めないことが表明された（Register）。

これにより、特にFacebookが開発するJavaScriptフレームワーク「React.js」を使用しているプロジェクトが影響を受けるという。そのため、Reactを利用しているASF傘下プロジェクトに関わるソフトウェア開発者がFacebookにライセンスの変更を求めていたが、Facebookはこれを却下したという（Register、マイナビニュース）。

なお、オープンソースの定義では特定の個人やグループ、分野に対してのみ制限を加えることを禁止しており、これに則るとFacebookの「特許状況付きBSDライセンス」はオープンソースライセンスとは認められない。

あるAnonymous Coward曰く、

国土交通省は6月6日、Apache Struts 2の脆弱性により、同省の「土地総合情報システム」サイトからアンケートや登記情報など最大約20万件の情報が流出した恐れがあることを明らかにした（プレスリリース、時事通信、ITpro）。

Struts 2の脆弱性を利用した攻撃は3月上旬より相次いでおり、国交省も同月には運営委託業者の調査により同サイトがStruts 2を利用していることを認識していたという。しかし、肝心の脆弱性対策は2017年度予算での機能追加と合わせて行うものとされてしまい、5月の契約後にシステム改修が着手されたものの、既に悪意のあるプログラムが仕込まれていたことが判明、というお粗末な結果となった。

漏洩に対して同省の担当者は「もっと早く手を打てばよかった」と話しているという事だが、ネット社会において余りにも遅すぎる対応と言わざる得ないだろう。ただ、登記情報は公開もされており、アンケートも4月6日以前の分はサーバーから取り除かれていたということで、被害が限定されたのだけは救いである。

Apache Struts 2の脆弱性を狙った攻撃でクレジットカード情報を流出させ、一時停止されていた「都税クレジットカードお支払サイト」が復旧した（ITmedia）。しかし、今度はこのサイトが新たに「https://zei.metro.tokyo.lg.jp/」というドメインを利用することになっている点や表記などが不正確である旨が批判されている（セキュリティ研究者・高木浩光氏によるTogetterまとめ）。

lg.jpは地方公共団体を対象としたドメイン（JPRSの説明）。このドメインを登録できるのは地方公共団体とそれらの組織が行う行政サービスのみとされている。を運営するのはトヨタファイナンスであり、地方公共団体ではない。また、問題の都税クレジットカードお支払サイトにアクセスすると組織名として「東京都」として表示されるようにもなっている。

特に大きな問題点として、情報の取得主体が誰なのかが不明瞭になっている点がある。さらに、個人情報保護法の義務である「利用目的の公表」をしていないとも指摘されている。なお、このサイトは都が運用をトヨタファイナンスに委託しているものではなく、トヨタファイナンス自体が運営主体とのこと。

あるAnonymous Coward 曰く、

ぴあが運営する、プロバスケットボールリーグ「Bリーグ」の公式チケットサイトおよびファンクラブサイトが不正アクセスを受けた。最大で15万4599件の個人情報流出の可能性があるという（ITmedia、ぴあの発表）。

攻撃はApache Struts 2の脆弱性を狙ったもの。攻撃されたサーバーにはセキュリティコードを含むクレジットカード決済情報も含まれていたという。流出した情報を使ったクレジットカードの不正利用があり発覚した。

あるAnonymous Coward 曰く、

AdobeおよびGoogleが、オープンソースの明朝体フォント「源ノ明朝」および「Noto Serif CJK」をリリースした。

両社は同じくオープンソースのゴシック体フォント「源ノ角ゴシック」および「Noto Sans CJK」を2014年にリリースしており、これらフォントの明朝体バージョンという位置付けだ。書体としてはどちらも同じで、デザインの著作権はAdobeが所有する。配布ライセンスはNoto Serif CJKがApache License、源ノ明朝はSIL Open Font Licenseで、どちらも自由にダウンロード/再配布/使用/改変などが可能。

Googleによると、中国語簡体字（GB18030および中国の通用规范汉字表）および繁体字（BIG5）、日本語（JIS X 0208、JIS X 0213、JIS X 0212 Adobe-Japan1-6）、韓国語（古ハングル文字、1万1,172の最新文字、KS X 1001、KS X 1002）のすべてをサポートするとのこと。また、フォントウェイトは7種類が用意されている。

両者の違いはほとんどないと思われるが、ウェイトの名称が若干異なっているようだ（源ノ明朝はExtraLight/Light/Regular/Medium/SemiBold/Bold/Heavy、Noto SansはExtraLight/Light/Regular/Medium/SemiBold/Bold/Black）。

Googleが「Google日本語入力 プチプチバージョン」を発表した。キーボードのように表面に文字が印刷された気泡緩衝材（エアーキャップ、プチプチ）を潰し、それを読み込ませることで日本語の入力を行えるというデバイスとなっている。

「スタンダートタイプ」と「ハンディタイプ」の2種類が用意され、ハードウェアの設計図や回路、ファームウェアはApache Licenseで公開されている（GitHub）。

OpenSSLがライセンス変更に向け、特設サイトで貢献者の合意を求めている(Core Infrastructure Initiativeによるアナウンス、 OpenSSL Blogの記事、 The Registerの記事、 Phoronixの記事)。

現在、OpenSSLにはOpenSSL LicenseとオリジナルのSSLeay Licenseの両方が適用されている。これを標準的なApache Software License v.2.0(ASLv2)に変更することで、幅広いFOSSプロジェクトや製品で利用できるようにすることがライセンス変更の目的とされる。OpenSSLプロジェクトではコミットした人全員に電子メールで通知しているが、半数が送信エラーで返ってきているという。メールアドレス変更によりメールが届いていない貢献者は、特設サイトで情報を入力すれば意見を表明できる。なお、23日午後の時点で変更に合意した人は265人、反対者も7人いるそうだ。

OpenSSLの貢献者でもあり、OpenSSLプロジェクトをフォークしてLibreSSLプロジェクトを立ち上げたOpenBSDのTheo de Raadt氏のように、変更プロセスに不満を感じる人もいる。de Raadt氏は開発者コミュニティーに相談せず、いきなりメールで合意を求めてきたことや、回答がなければ合意したとみなすとされている点などを批判している。The Registerの記事によれば、大企業(OracleやIntelが変更を支持している)やLinux Foundationなどに都合のいいライセンスだけが選択肢となっている点にも懸念を示しているという。また、現在のライセンスと比べ、ASLv2の制約の方が大きいとも考えているようだ。

3月9日、Webアプリケーションフレームワーク「Apache Struts」の脆弱性を狙った攻撃に対する注意喚起が出ていたが（過去記事）、この脆弱性を狙った攻撃や実際の被害が多数報告されている。

すでに特許情報プラットフォーム（過去記事）や都税支払いサイトおよび住宅金融支援機構（過去記事）、日本郵便（Security NEXT記事）などで問題の脆弱性を付いた攻撃が行われて情報流出が発生したことが報じられているが、これ以外にもニッポン放送の音声サービス「Radital」や（ニッポン放送の発表）や沖縄電力（発表PDF）などでも攻撃が確認されている。

当初は「Content-Type」ヘッダを利用して攻撃ができるという話だったが、これ以外の「Content-Disposition」や「Content-Length」といったヘッダを利用した攻撃も可能であることも判明している（Securty NEXT）。また、今回の脆弱性の対応としてパーサーを変更するというものが提案されていたが、この対応を行った場合でも攻撃が可能であることが確認されており、確実な対策としては脆弱性を修正したバージョンにアップデートするしかないようだ（INTERNET Watch）。