headless 曰く、

Apache Software Foundation(ASF)は14日、OpenOfficeの20周年を記念するブログ記事を公開した(The Apache Software Foundation Blogの記事、 Phoronixの記事)。

OpenOfficeのベースとなったStarOfficeは1985年に誕生し、開発元のStarDivisionを買収したSun Microsystemsが2000年7月にオープンソース化を発表。www.OpenOffice.orgでソースコードが公開されたのは2000年10月13日、2002年にはOpenOffice.org 1.0がリリースされている。

2010年にはOracleがSun Microsystemsを買収し、2011年にOpenOffice,orgプロジェクトをASFへ寄贈した。OpenOffice.orgは「Apache OpenOffice」という名称に変更され、2012年に最初の正式版がリリースされている。

当初はOffice互換ソフトの先頭を走っていたApache OpenOfficeだが、2015年にはOpenOffice.orgをフォークしたLibreOfficeと比べて開発の遅れが目立ち始め、2016年にはプロジェクト終了を検討するに至る。その後プロジェクトは継続することになったものの、人手不足は続いているようだ。

あるAnonymous Coward 曰く、

セキュリティ研究者の報告によれば、ここ2週間ほどの間に、インターネット上に保護されずに公開されている脆弱なデータベースに対して、ほぼ全てのデータが削除された上に「Meow (ニャー)」という猫の鳴き声だけが書き残される「Meow Attack (ニャー攻撃)」が相次いでいるという（GIGAZINE、Slashdot）。

最初に発見されたのは香港のVPN業者UFO VPNのDBへの犯行で、研究者がDBがインターネット上に公開されている旨を企業とやり取りしていたところ、7月21日にDBのデータが削除され、「meow」の文字が残されているのを発見したという。ニャー攻撃はその後も拡大を続けており、27日現在までに、ElasticsearchやMongoDB、Apache Cassandraも含めて4000件以上が被害を受けたとのこと。

当然ながら、インターネット上に保護なく公開されたDBは以前から攻撃を受けているが、だいたいの場合はランサムウェアで身代金を要求されるか、単純に削除されるかとのことで、わざわざ「ニャー」とメッセージを残していく動機は不明。一方で手段については、スクリプトでProtonVPNを経由して行われているとの分析がされている。発見した研究者は「簡単に攻撃可能なほど無防備なので、面白半分でやっているのでしょう」と語っている。

情報元へのリンク

Anonymous Coward曰く、

JavaScriptで実装されたフロントエンドが主流でほとんど耳にする機会も少なくなった気がする統合開発環境（IDE）NetBeansだが、バージョン12 LTSがダウンロード可能になっている（OSDN Magazine、窓の杜）。

バージョン12からは長期サポート（LTS）が導入されたほか、JDKのバージョンによってエディタのコード入力補完の挙動が変わる、Java FX対応、Jakarta EEはまだ非対応、Gradle、Maven、PHP、JavaScript、HTML、C++をサポート、Look and FeelにFlatLAFを追加（Light、Dark、IntelliJ、Darcula）などなどわりと多め。

久々にダウンロードしてFlatLAFのIntelliJにしてみたら今風で実際、これが格好良いのだが、世の中Swingって今でも需要あるのかとも思う。実はタレこみ子の職場ではいまここって感じでSwingのGUIでちょこまかな業務用のちまちまアプリ作って使ってたりするんだが。

OpenOffice開発チームが5月17日付で「Apache OpenOffice needs your help」と題した助力を求めるブログ記事を公開している（窓の杜）。

Apache OpenOfficeについては以前開発が停滞していることが話題になったが、この問題は現在でも解決していないようだ。このブログ記事によると、ソフトウェアエンジニアやプログラマだけでなく、OpenOfficeを使って品質や翻訳に関する問題や不具合、バグレポートなどを報告したり、ドキュメントを作成する、といった作業での協力も歓迎しているという。

The Linux FoundationがLaboratory for Innovation Science at Harvardと共同で実施したフリー・オープンソースソフトウェア(FOSS)のセキュリティに関する調査報告書の暫定版「Preliminary Report and Census II of Open Source Software」を公開している(報告書: PDF、 The Registerの記事)。

The Linux Foundationは2014年、Heartbleed脆弱性の問題を受けてオープンソースプロジェクトを援助するCore Infrastructure Initiative(CII)を設立。2015年には調査プロジェクト(Census I)を実施して報告書を公開しており、今回のCensus IIはその第2弾となる。冒頭で「典型的なアプリケーションの80％～90%は(オープンソースの)コンポーネントでできている」というSonatypeによる2016年の報告書(PDF)からの引用を掲げている通り、セキュリティ上の問題点特定に活用するため、どのようなFOSSパッケージが幅広く使われているのかを特定することが主目的となっている。

報告書では付録として最も広く使われているFOSSパッケージ(JavaScript: 10、JavaScript以外: 10)がまとめられている。JavaScriptとそれ以外を分けたのは、使用したデータソースでJavaScriptが多くを占めており、どのようなランキングを作成しても使用したJavaScriptが上位を独占する状態になってしまうからだという。ただし、JavaScript以外のパッケージでも同じ問題があり、すべてがJavaのパッケージとなっている。

GoogleがAndroidにおいてJava APIと互換性のあるAPIを無断で提供していることについて、Javaを所有するOracleは同社の権利を侵害していると主張、裁判となっている（過去記事）。いっぽうで、OracleはAmazon Web ServicesのS3 APIと互換性のあるAPIを自社のクラウドサービスで提供している。これは著作権侵害ではないのか、との問題提起を行う記事がArs Technicaに掲載されている。

ここで指摘されているAPIは、Oracle CloudのAmazon S3 Compatibility APIというものだ。ドキュメントでもこのAPIがAmazon S3互換である旨が明示されている。

OracleとGoogleの裁判では、APIは著作権保護の対象になるという判断が下されている。そのため、同じように考えればOracleが他社が権利を持つAPIと互換性のあるものを無断で提供することは著作権侵害になる可能性がある。

これに対しOracleはS3 APIについて、Apache License 2.0で提供されているためこういった利用は問題ないと主張しているようだ。ただ、公開されているのはあくまでS3 APIを使用するためのSDKであり、S3 APIを提供するAWS側のコードがApache Licenseで公開されているわけではないことから、記事ではこの釈明について否定的だ。

Anonymous Coward曰く、

9月21日、満を持してApache OpenOffice 4.1.7がリリースされました（リリースノート）。バグフィックスが中心。

• Possible crash in Freetype code
• Crash in Writer when linking frames on OS/2
• Apache OpenOffice TM in Splash screen has different background

アナウンスには脆弱性の修正情報はありません。これを見て「更新しなきゃ」と思った方は、迷わずLibreOfficeへの移行を検討しましょう。

headless曰く、

Microsoftは16日、MSVCのC++標準ライブラリ（STL）のオープンソース化を発表した（C++ Team Blog、Phoronix）。

MSVCチームではオープンソース化の理由として、ユーザーが最新の変更を試すことが可能になり、レビューによるプルリクエストのレビューによる改善も期待できることを挙げている。またC++の標準化が加速する中、主要な機能をオープンソースとして受け入れることが重要だと考えているほか、逆にMSVCチームによる実装をオープンソースとして利用できるようにすることでC++コミュニティーに貢献したいとも考えているとのこと。

MSVCのSTLはGitHubでソースコードが公開されている。ライブラリ間でのコード共有を容易にするため、ライセンスにはlibc++と同じApache License v2.0 with LLVM Exceptionを選択したとのことだ。

あるAnonymous Coward曰く、

米国と中国の貿易摩擦が激しくなっているが、中国のソフトウェア開発者の一部でGitHubへのアクセスも米国の規制によって制限されるのではないかとの懸念が出ているという。

GitHubのルールの冒頭には、GitHub上にアップロードされた情報は、米国輸出管理規制（EAR）を含む米国輸出管理法の規制を受けると記載されている。これは、Huaweiへの制裁に使われたものとまったく同じものだ。

これに対しオープンソースソフトウェア開発を支援しているApache Software Foundation（ASF）は、オープンソースのコードを使ったソフトウェアに関してはEARの対象とならないとの公式発表を行った。にもかかわらず、一部のコミュニティのユーザーはまだ懸念を持っているようだ（abacus、Slashdot）。

英国の諜報機関・GCHQが、過去にドイツや英国などで使われた暗号装置「Enigma」「Typex」「Bombe」による暗号化および復号を簡単に試せるシミュレータを公開した（CNET Japan）。

これにより、GCHQがオープンソース（Apache License 2.0）で公開している「CyberChef」というデータ処理ツールで「Enigma」「Typex」「Bombe」による暗号化および復号が可能になる。GitHub上でデモが公開されているが、「Encryption / Encoding」の選択肢に「Enigma」や「Bombe」「Multiple Bombe」「Typex」が用意されており、これらをダブルクリックで選択し、「Input」に暗号化したい文字列を入れると「Output」に暗号化された結果が出力される。

米国家安全保障局(NSA)が5日、リバースエンジニアリングツール「Ghidra」を公開した(特設サイト、 NSAの紹介ページ、 RSA Confereneのセッション紹介、 The Registerの記事)。

GhidraはNSAがマルウェア解析などを目的として開発したもので、1月に公開が予告されていた。ライセンスはApache 2.0となっており、ソースコードも公開予定のようだが、GitHubのリポジトリは現在のところプレースホルダーのみとなっている。バイナリは特設サイトからダウンロード可能で、実行にはJavaが必要だ。

NSAのシニアアドバイザー、ロバート・ジョイス氏は同日、RSA Conference 2019でGhidraを紹介している。ジョイス氏はGhidraがバックドアを備えていないと主張したが、デバッグモードで実行するとローカルネットワーク上からコマンドを実行可能なバグらしきものが見つかっているとのことだ。

ある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アカウントにサインインする必要がある。スラドの皆さんはどちらが良いだろうか。