ビジネスとオープンソースの狭間で 〜 Embulk の場合 (前編)
2023 年はビジネスとオープンソースの関係が難しくなった年であったように思います。 6 月には、フルタイムの Ruby コミッターとして研究開発を行っていたお二人がクックパッド社の人員削減の影響を受けたことに端を発して、オープンソースに深く関わってきた一部のソフトウェア・エンジニアを中心に、ビジネスとオープンソースの関係について議論がありました。 8 月には HashiCorp 社が自社のオープンソース製品群のライセンスを Business Source License 1.1 (BSL) に変更したことも話題になりました。 また 2023 年は、一年を通して大規模言語モデル (Large Language Models; LLM) が話題になった年でもあり、ビジネスにも大きな影響がありました。 大規模言語モデルとオープンソースの関係に焦点を絞っても、「非オープンソースのライセンスで公開
jq 1.7をリリースしました - プログラムモグモグ
jqがjqlang organizationに移譲され、数名の新たなメンテナーを入れた開発体制に移行してから三か月が経ちました。 私にとってこの三か月はとても濃厚で、これまでのOSS活動の中でも特に大変な期間でした。 itchyny.hatenablog.com github.com リポジトリの管理権限をいただいてからまずやったことは、既存のissueやPRの整理でした。 500ほどのissueとPRに目を通し、ラベルをつけて、解決済みのものを閉じて、直近で入れたいものを独断でリリースマイルストーンに入れていきました。 この整理がついた頃には他のメンテナの活動も活発になり、私の作ったマイルストーンのissueやPRを確認してくれました。 そして先日、ようやく1.7をリリースしました。 1.6から実に五年弱、一時は開発が完全に止まってしまいプロジェクトの存続を危ぶむ声も上がるような状況から
AlmaLinux、ソースコードの公開方針を変更したレッドハットとの関係に暗雲
Red Hatが「Red Hat Enterprise Linux」（RHEL）のソースコードの配付対象を顧客のみにすると発表したことで、RHELのソースコードが簡単には入手できなくなり、「AlmaLinux」や「Oracle Linux」、「Rocky Linux」などのRHELクローンのディストリビューション作成工程は大きな影響を受けることになった。これに対し、Oracle LinuxやRocky Linuxは争う姿勢を見せているが、AlmaLinuxは穏健な手段を選択した。しかしその方針は、期待されていたほどどうまくいっていない。 AlmaLinuxは、RHELとのソースコードの互換性を100％保証することを放棄した。その代わり、AlmaLinuxの開発者は、アプリケーションバイナリインターフェイス（ABI）レベルでの互換性を確保することを選んだ。ほとんどの場合、実用的な目的にはこれ
OSSへの寄付のススメ ~ サイボウズのOSSへの寄付戦略 - Cybozu Inside Out | サイボウズエンジニアのブログ
はじめに こんにちは、OSS推進チームのsatです。本記事はサイボウズが5年間取り組んできたOSSへの寄付をする取り組みについて紹介します。具体的には寄付をする理由、どのようなポリシーで寄付額や各プロジェクトへの寄付額の配分をするのかについて共有します。 なぜ寄付をするのか サイボウズでは様々なOSSを利用していることもあり、以前お伝えしたようにオープンソースソフトウェアポリシーというものを定めています。 blog.cybozu.io cybozu-oss-policy.readthedocs.io この文書の中で、次のような記述があります。 本規程の第二の目的は、当社がオープンソースコミュニティにおける良き一員であるために必要な規定を定めることである。 この「良き一員」となるためにOSSに貢献するには様々な方法があります。直接的にはバグ報告、修正、機能追加、ドキュメント追加などによって人
Ubie がスタートアップだからこそ OSS に寄付をする理由 | Yuku Kotani
いま働いている Ubie で OSS に寄付していくことを決め、まず手始めに JavaScript トランスパイラの Babel に$500 の寄付を行いました。日本のスタートアップが OSS に寄付をするのはまだあまり目にしないため、Ubie がスタートアップだからこそ OSS に寄付しようと考えた理由をご紹介します。 スタートアップにこそ OSS が必要 時間も体力もないスタートアップは、とにかく最速で事業を成長させなければならず、OSS が高速道路としてそれを支えてくれています。 これは極論ですが、OSS が全てなくなったとき、そのまま事業を続けていく自信が皆さんにはありますか？少なくとも僕にその自信はありません。体力のある大企業であれば内製する選択もできそうですが、スタートアップでは OSS なしにはビジネスを成し得ない場合が殆どではないでしょうか。 OSS が持続せずに困るのは、
私とOSSの25年
2. • 自己紹介 • 会社紹介 • 普段の生活 • プログラミング歴（昔話） • 午後のこ～だ • 数学から暗号へ • 楕円曲線とペアリング • 関わっているプロジェクト • Xbyak • Intel oneDNN • ブロックチェーン • スーパーコンピュータ富岳 目次 2 / 48 3. • サイボウズ・ラボで主に暗号と最適化関係のR&D • Twitter : @herumi • GitHub : https://github.com/herumi/ • 資料 : https://slideshare.net/herumi/ • 主な活動 • OSS（オープンソースソフトウェア）を介在した 様々なプロジェクトとのゆるやかなつながり 自己紹介 暗号研究 ブロックチェーン Intel oneDNN スーパーコンピュータ富岳 Xbyak 3 / 48
Elastic 社による Elasticsearch および Kibana のライセンス変更にともなう AWS の対応方針のご案内 | Amazon Web Services
Amazon Web Services ブログ Elastic 社による Elasticsearch および Kibana のライセンス変更にともなう AWS の対応方針のご案内 先週、Elastic 社が Elasticsearch および Kibana のライセンス変更に関するアナウンスを実施しました。これによりバージョン 7.11 以降の Elasticsearch と Kibana は、Apache License, Version 2.0 (ALv2) での提供が行われません。これを受けて AWS は、2021/1/21 (PST) に対応方針を発表いたしました。本発表の要点は以下のとおりです。 AWS は Elasticsearch と Kibana のバージョン 7.10 をベースに fork した Elasticsearch と Kibana を ALv2 ライセンスにて公
OSS の持続可能性
ここ最近の COVID19Radar https://github.com/Covid-19Radar/Covid19Radar 上でのゴタゴタにより、開発者の @kazumihirose さんが https://twitter.com/kazumihirose/status/1274616019420471296 疲弊してしまいっているのを見て、(今回の揉め事の根本的な原因はソフトウェアがOSSとして公開されているのが原因ではないと思うが)いたたたまれない気持ちになったので書く。書いてみた結果ただのとりとめもないOSSへの愚痴になってしまった。 増田についていくつかのOSSプロジェクトのメインコントリビュータとして関わっています。 star数1000~2000の中堅プロジェクト2つほどと、他にもいくつかstar数~100程度の小規模なプロジェクトがいくつか 日々やっていることといえば 質
個人開発者とCovid-19 Radarプロジェクト - laiso
Endless road | During our roadtrip we turned off the highway… https://www.flickr.com/photos/98063470@N00/326044514 GitHubリポジトリ Covid19Radar に対して起ったことがかなり特殊な状況だったため、開発を追い掛けていた視線からレポートをします。 この記事の著者について 代表作のない個人アプリ開発者(かなしい) Covid-19 Radar Japan の人ではない GAFAMやCode for Japan の人でもない 4/8 Covid-19 Radarを発見する Covid-19 Radarとは、この時点ではシンガポールのTraceTogetherの日本版を目指した個人開発者 廣瀬一海さんのアプリのリポジトリ 4月にContact Tracing技術について
接触確認アプリの不具合という問題の所在は、OSSコミュニティではなくリリースプロセスの不備にあるのでは｜Hal Seki
接触確認アプリの不具合という問題の所在は、OSSコミュニティではなくリリースプロセスの不備にあるのでは いよいよリリースされた厚生労働省の接触確認アプリですが、「ストアで接触確認アプリと検索しても見つからない」「利用開始の日付が更新されてしまう」「初期設定時にBluetoothの許可をしないとアプリが立ち上がらない」などといった不具合が見つかり、Twitter 等で、接触確認アプリのベースとなるコードをオープンソースで開発し提供した Covid19Radar コミュニティ（以下OSSコミュニティ）に対して批判が出ています。 しかし、接触確認アプリの不具合に対して、問題の所在をOSSコミュニティそれ自体と捉えて、殊更これを責めるというのは、日本のOSSコミュニティの文化醸成のみならず、IT業界にとっても良いことでは無いと考えます。 「誰が悪い」といった責任論は問題の所在の全容を見えにくくして
コロナ接触を通知する日本版｢接触確認アプリ｣を作ったのは誰か？…｢6割普及｣への挑戦
厚生労働省は現在、新型コロナウィルス感染症（COVID-19）の“感染が疑われる濃厚接触”を通知する｢接触確認アプリ｣の開発を進めている。 開発を受注したのは日本国内のベンダー。一部で｢米マイクロソフトが受注した｣と報道されたが、これは間違いだ。とは言え、マイクロソフトが無関係というわけではない。そこには多少事情がある。 実は、日本で使われるアプリのベースとなる部分は、個人が中心となったボランティアベースのプロジェクトで、オープンソースとして開発されたものを利用している。 そのアプリは、なぜオープンソースで開発されたのか？ そして、そこに人々はどう関わっているのか、開発にかかわった関係者を取材した。 接触確認アプリがどういうものか、おさらいしておこう。 接触確認アプリは、スマートフォンのBluetooth機能を使い｢一定以上の長い時間、スマホを持っている人同士が近くにいた｣情報を記録するア
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blog
今回はソフトウェアエンジニアじゃない人や学生にも、ソフトウェアエンジニアという職業には夢があるかもしれないと思ってもらうために書いています。そのため既に詳しい方からすると回りくどい説明も多いと思いますがご容赦下さい。 基本的に記事とかには技術的なことしか書かないスタンスでやってきましたが、今回の件はさすがに誰かに伝えておくべきだろうということで長々と垂れ流しました。 概要 GW中に趣味で開発したソフトウェアを無料で公開したところAqua Securityという海外企業（アメリカとイスラエルが本社）から買収の申し出を受け、最終的に譲渡したという話です。さらに譲渡するだけでなく、Aqua Securityの社員として雇われて自分のソフトウェア開発を続けることになっています。つまり趣味でやっていたことを仕事として続けるということになります。 少なくとも自分の知る限り一個人で開発していたソフトウェ
オープンソース活動がフルタイムの仕事になる仕組みの話｜Rui Ueyama｜note
僕の仕事をひとに説明するときに、「Googleで仕事をしているけどオープンソースなのでGoogleのプロダクトを作っているわけではないし、むしろアップルとかソニーの人と一緒に仕事している」と言うと、「？？？」という反応になることが多いので、僕はこういう仕事をしているんだよということをここでちょっと説明してみようと思います。 （2016年の僕のFacebookの投稿の転載です。） 僕のいるチームはLanguage Platform Teamというところで、プログラミング言語や開発ツールの開発をしています。LPTの中にもいろいろ細かいチームが分かれているのですが、僕がいるのはC++チームで、Googleで主要開発言語になっているC++言語の開発環境を担当しています。 C++で開発をするときには、C++ツールチェインと呼ばれる一連のツールを使います。ツールチェインの一番大きなコンポーネントは、人
サイボウズのオープンソースソフトウェアポリシーを紹介します - Cybozu Inside Out | サイボウズエンジニアのブログ
OSS準備室長を務めていた ymmt (@ymmt2005) です。 過去形なのは、OSS準備室は 7 月末で解散したためです。 OSS準備室では、サイボウズ社員がオープンソースソフトウェアに関する活動を行いやすくすることを主な目的として、会社の基本方針を「OSSポリシー」という文書にまとめる作業を行いました。 完成したOSSポリシーはCC0 (いかなる権利も保有しない、いわゆるパブリックドメイン)で広く他の企業の方々にも活用いただけるよう以下で公開しました。本記事ではその内容と、サイボウズにおけるオープンソース活動のこれまでとこれからを紹介いたします。 OSSポリシー(日本語) (GitHub) OSS Policy (English) (GitHub) オープンソースについて オープンソースソフトウェア(Open Source Software, OSS)とは、オープンソースの定義に基
そのサーバはいったい誰にサーブするのか? - GNUプロジェクト - フリーソフトウェアファウンデーション
インターネットでは、プロプライエタリなソフトウェアだけがコンピューティングの自由を失う唯一の方法ではありません。ソフトウェア代替としてのサービス(SaaSS)は、ほかの誰かにあなたのコンピューティングに対する支配力を与えてしまう、もう一つの方法です。 基本的なポイントは、(それが自由であれば)ほかの誰かが書いたプログラムのコントロールをあなたは得られますが、ほかの誰かが実行しているサービスのコントロールをあなたが得ることは決してない、ということで、原理的に実行するプログラムが為すサービスを決して使わないようにしましょう。 SaaSSとは、ほかの誰かによって実装されたサービスを、あなたのプログラムのコピーを実行する代替として使うことを意味します。この用語はわたしたち(独自の)もので、論説や広告では、これは用いられませんし、かれらはサービスがSaaSSかどうかを言わないでしょう。おそらく、かれ
Google翻訳をオープンソースプロジェクトに使うのはダメなのか？
免責： これは法律の専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。 最近プログラマの間で 「Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」 http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace が、話題になってますね。 Ubuntuの翻訳プロジェクトで発生したトラブルの話です。 この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSSの翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます。 ですが、プログラマの間で単にWeb翻訳をOSSに使ってはいけないんだという認識が広まってるように見えます。個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いてい
OSS（オープンソース・ソフトウェア）鳥瞰図2017年版【第1回】 | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ OSS ＞ OSSを理解する ＞ OSS（オープンソース・ソフトウェア）鳥瞰図2017年版【第1回】 OSS OSS記事一覧へ [OSSを理解する] OSS（オープンソース・ソフトウェア）鳥瞰図2017年版【第1回】 2017年2月15日(水)高橋 千恵子（日本OSS推進フォーラムクラウド技術部会長） リスト 本誌は2012年5月にオープンソースソフトウェア（OSS）のカオスマップ「OSS鳥瞰図」を作成・公開した。様々な分野ごとに多岐にわたるOSSを俯瞰的に把握できるように、という意図である。しかしOSSの進化は急ピッチであり、新たなソフトウェアが次々に生まれている。この点に問題意識を抱いたのが日本OSS推進フォーラム。クラウド技術部会が中心になって、「OSS鳥瞰図」を完全リニューアルする作業を実施した。（IT Leaders編集部）
OSSコミュニティの継続性
力武さんがこういう記事を書いている。自分自身BSD界隈に関わって15年は経つし、コミュニティ運営についてはいろいろと経験を積んだつもりなので、意見を書いてみることにした。書いてみたらまとまりのない文章になってしまったけれど、残しておくことにする。 目的のないコミュニティは続かない 「コミュニティに参加している人の年齢が高くなって、そのうちなくなるんじゃないか」という懸念は、少なくともFreeBSDには当てはまらない。活動がなくなる開発者もいるが、若いcommitter（ソースコードの変更権限を持っている開発者）は定期的に入ってきていて、人材の流動性は入口も出口も高い。CSRGの時代に活躍していた人が最近になって開発に再参加するケースも増えた。これらは国際会議の運営などを通じて交流を深める努力をしている成果でもある。50代や60代でコードを書いて参加しているひとはたくさんいて、特別なことでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SIOS Tech. Lab - エンジニアのためになる技術トピックス
Google will open-source its Earth Enterprise on-premises software in March