なぜ脱OSSが増えているのか？
はじめに TerraformやVaultを開発するHashiCorpは自社製品をOSSのMPL(Mozilla Public License v2.0) から、ソースコードは公開するも一部の利用に制限があるBSL(Business Source License) への変更をアナウンスしました。 これは2018年のRedisを皮切りにMongoDBやCockroachDB、ElasticSearchなど多くのプロダクトで進められている脱OSSの流れです。商用のオープンソース[1]と言われてしまうこともある最近のこの動きの理由は何故なのか？ という点を以下の動画で解説しました。 動画中では尺の都合で端折った個所も多いので、こちらの記事の方にもまとめておきたいと思います。 OSSとは？ OSSの定義 まず、OSS（オープンソース）とはなんでしょうか？ これはRMSのフリーソフトウェアを源流とする
オープンソースビジネスの挑戦と現実｜Rui Ueyama
いい感じのオープンソース・ソフトウェアを書いて、それを元に起業することを考えてみたことがある人は結構いるようだ。実際に僕はここ1年半ほど、自作のオープンソース・ソフトウェアを元にビジネスを立ち上げようと試行錯誤してきた。その経験についてここでシェアしてみようと思う。 あらすじ薄々予期していたことではあったけれど、結論から言うと、そんなにはうまくいかなかった話ということになる。要点をまとめると次の通りだ。 「moldリンカ」というオープンソースのツールを開発して、それを元にビジネスを行おうとしていた そこそこ稼ぐことはできたものの、大きなリターンを得るのは難しかった ほとんどの企業はオープンソースを大々的に活用していても「無料のソフトウェア」にはお金を払うつもりはないし、払いたくても社内制度上できない 大きなリターンを得たいのならば、自作のオープンソース・ソフトウェアを元にサービスを立ち上げ
Apache Log4jの脆弱性とともに浮かび上がったオープンソースのメンテナの責任範囲の問題 - YAMDAS現更新履歴
www.jpcert.or.jp piyolog.hatenadiary.jp 先週は Apache Log4j の脆弱性問題が大きな話題となった……と過去形で書いてはいけないのかもしれない。危機はまだ続いている。 今回、脆弱性の破壊力のヤバさとともにクローズアップされたのは、今日、多くのビジネスの生命線となっているオープンソースソフトウェアのメンテナンスが、無報酬であり感謝されない仕事になっており、「オープンソースは壊れている」んじゃないの？ という問題である。 20年以上みんなずっと同じ話してるなと思ってしまうが、オープンソースが壊れている、壊れていないの話がやたらに流れている。この文脈ならフリーソフトウェアの時代からずっと壊れてるんだよ。それでも動いているのは自由だからだよ。— Shuji Sado (佐渡 秀治) (@shujisado) December 14, 2021 dev
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
最近見かける新しいライセンスについて - Kengo's blog
Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。 なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。 新しいライセンスが誕生している背景 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。 Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。 既存のライセンスが難解なため、理解しやすいライセンスが求められた。 OSS活動を収入に繋げるためのモデルが試行錯誤されている。 新しいライセンスを導入しているプロジェクト（一例） プロジェクト ライセンス Elastic SSPLと独自ライ
WeKan ® — Open-Source kanban
WeKan ® Open-Source Kanban Experience efficient task management with WeKan - the Open-Source, customizable, and privacy-focused kanban. Boards You can make many boards for different projects or tasks. Each board can have columns to show the different stages of your work, such as "To Do," "Doing," and "Done." You can also add cards to each board to represent tasks, with titles, descriptions, and du
OSSのライセンスを理解する（「使用」と「利用」の違い、知っていますか？） - Qiita
最近、私的にDockerで遊んでいるのですが、Dockerを使っていると様々なライセンスを有したオープンソースソフトウェア（OSS）と遭遇します。自分が知らない間に著作権に抵触してしまうことが怖かったので、OSSのライセンスについて以下の流れでまとめてみました。 「ライセンス関連用語」を理解する 「オープンソースの定義」を理解する 「コピーレフト」を理解する 「主要ライセンス」を理解する 1.「ライセンス関連用語」を理解する OSSを理解するにあたって、まずは主要なライセンス関連用語の定義を理解することが重要です。私の場合は、「使用」と「利用」の違いや「オープンソースソフトウェア」と「フリーウェア」の違いについて、恥ずかしながら明確に理解できていませんでした。。。 【オープンソース・ソフトウェア（Open Source Software, OSS）】 ソースコードが無償で公開されており、誰
Open Source Initiative OSI - Licensing
OSI Approved Licenses Open source licenses are licenses that comply with the Open Source Definition – in brief, they allow software to be freely used, modified, and shared. To be approved by the Open Source Initiative (also known as the OSI) a license must go through the Open Source Initiative’s license review process.
GitHubの docker/docker は moby/moby になりました。 | DevelopersIO
ども、大瀧です。 昨日から開催されているDockercon 17では、Docker関連の多くの発表がありました。 その中のひとつにMobyプロジェクトがあり、プロジェクト発足に合わせてGitHubのdocker/dockerリポジトリがmoby/mobyリポジトリに移動しました。今後Docker CE(Community Edition)のソースやIssueなどを見るときは、こちらのリポジトリにアクセスしましょう。 このブログでお伝えしたいことは以上なのですが、「Mobyってなんだよ?!Dockerが名称変更したの?」と言われそうなので、ちょっとだけ解説します。経緯についての一次情報は、以下をご覧ください。 Transitioning to Moby by shykes · Pull Request #32691 · moby/moby ほどなくちゃんとした説明がDocker社のブログなど
Web翻訳の結果を公開のメーリングリストに投稿する場合は注意が必要という話 - いくやの斬鉄日記
オープンソースからハイスクールフリート、The Beatlesまで何でもありの自称エンターテインメント日記。 Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話で紹介した事例は現在進行中で落とし所は見えていません。 UbuntuにはCode of Conduct (CoC)というルールがあり、これを遵守した振る舞いを求められます。もちろん私もこれに署名しています。 署名していようがしてなかろうが、UbuntuのコミュニティではCoCを遵守する必要があります。 hitoさんから現在でもアクティブな翻訳者であるところの私からコメントが欲しいと言われたので、最初は淡々と書こうかなと思ったのですが、やっぱりちょっと茶化した感じにしようかと思い、書き終わったらただの洋楽好きのおっさんを披露した形になりました。本文はこれです。いくつかの単語の辞書を引いた以外は
Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話 - いくやの斬鉄日記
オープンソースからハイスクールフリート、The Beatlesまで何でもありの自称エンターテインメント日記。 最近TransifexとかLaunchpad (のRosetta)とかPootleなどなどを採用し、オープンソースソフトウェア(OSS/FLOSS)の翻訳がWebでできるようになっています。 同時にWebの翻訳サービスも多数存在し、どんどん精度が上がってきています。 ではWeb翻訳の結果をOSS翻訳に突っ込めばいいのではないかというと、それは違います。Web翻訳にも当然利用規約があり、そのようなことは禁止されてることが多いです。世の中すべてのサービスのライセンスを確認するのは不可能ですが、概ねその傾向にあるのは事実でしょう。具体的にはExcite翻訳の利用規約だと第6条で明記されています。 OSSの翻訳にするということは、そのOSSのライセンスに従うということで、それは > 私的利
オープンソースプロジェクトとの距離のとりかた
オープンソースプロジェクトに参加したいな、と思った時、まず最初に問題だと感じるのは英語だと思う。構成員が日本人だけで、日本人に向けてのみ出しているそソフトウェアでない限り、プロジェクトの共通語はふつう英語だ。植山さんの記事には英語で物事を進めることの利点が体験談とともに書かれている。他の記事にも、オープンソースプロジェクトで上手いことやっていくためのひとつとして英語の話が出てくる。一方、英語のせいで参加したくても二の足を踏んでしまう、というのもよく聞く話だ。結論から言ってしまうと、やっぱり読み書きだけでも習得しないと話に入っていくのは難しい。ソフトウェア開発者の多くは多様性に対して寛容なので、英語が不得意という理由で拒絶されることはないだろう。ただ、特別な配慮もしてくれない。 しかし英語の前に、プロジェクトとの距離のとりかたを学ぶべきだと思う。いままでわたしが見てきたり、自分自身がやって良
Sphinx のメンテナになって一年が経過した話 - Hack like a rolling stone
クリスマスが過ぎてから始まる Sphinx アドベントカレンダーへようこそ (嘘) Sphinx 大型連載第二夜です。 タイトルにある通り、Sphinx のメンテナ活動をして一年が過ぎたので、その話をします。 OSS 開発者のひとつのサンプルケースとして、何かの参考になれば幸いです。 Sphinx のメンテナ活動をはじめました 去年の 12月から Sphinx のメンテナ活動をはじめました。 Python のリリースマネージャ活動が忙しかったからか原作者の Georg の活動が鈍り、 また、その後を継いだ清水川さんも忙しくて身動きが取れなくなっていたことから、 コミット権をもらっていたことだし、パートタイムで手伝うかと思ったことがきっかけでした。 以前からコミット権は持っていたものの、一切メンテナとしての活動をしていなかったので、 徐々にチケットが溜まっていく様子に後ろめたくなったのかもし
非英語ネイティブにとってのOSSのメンテナンスコスト - once upon a time,
disclaimer: この記事を書いている人はClouderaというHadoop/Sparkのディストリビューターの会社にいます。 codelunch.fmの20回目を聞いていろいろ思うところがあったのでつらつら買いてみます。 codelunch.fm この回のcodelunch.fmでは、前職の同僚である丸山さん（@h13i32maru）と@hokacchaさんが、お互いの家庭環境の変化を交えながら個人プロダクトの開発について話しているエピソードです。これ自体なかなかおもしろい回なので、趣味でプロダクト開発している人は聞いてみるといいんじゃないかなと思います。 丸山さんはJasperやESDocを精力的に開発していますし、hokacchaさんはnodebrewやadventarを作られています。彼らの話していた、個人で趣味プロダクトを開発するモチベーションは何かというところは、以下のよ
任天堂製品に関連するオープンソースソフトウェアのソースコード配布ページ｜サポート情報｜Nintendo
Some Nintendo products include open source software ("OSS") distributed under the terms of various open source licenses, including the GNU Library General Public License 2.0, the GNU Lesser General Public license 2.1, the Mozilla Public License Version 1.1, and the Mini-XML License (collectively, the "OSS Licenses"). This website is the OSS source code distribution page for such Nintendo products.
オープンソースな製品でどうセキュリティバグをハンドルするか？
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. 自分がFirefox 26で直した話でSecurity Bugとしてマークされているのがあったんだけど、それの話。バグ自体は、CVE番号は振られているけどただのクラッシュなのでSecurity Advisoriesには載ってないものね。 今までもたまにSecurity bug自体は直してたり (面倒であればバグを登録。最近もした) するんだけど、ほとんどの場合はリリース版になっていないベータとかTrunkのものでの話のバグを直すことばかりなので現在のプロセスに疎いことがあるんだけど (今の日本のオフィスで働いている人達に、いまってこういうプロセスになってたって知ってた？って聞いたら、「えっ？」って言わたのは内緒)、こんな感じで対応する。 commit時
デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
プログラマーは"一線"を超えると急激に伸びる - Linux/Ruby 小崎氏(後編)
「プログラマーのスキルはある一定のラインを超えたところで急激に伸びるんです。そのラインは早く超えるには、OSSの開発に参加していろんな人が書いたソースコードをたくさん読むというのは有効な手段の一つだと思います」――こう語るのはLinuxカーネルおよびRubyの現役コミッターである小崎資広氏だ。 小崎氏には前回、LinuxカーネルやRubyの開発に関わった経緯や、コミュニティ活動を円滑にするポイントをうかがった。今回は、これからOSSコミュニティに参加しようと考えている若手エンジニアに向けたアドバイスをお願いしよう。 関連インタビュー 【インタビュー】コミュニケーション力向上に役立ったOSS活動 - Linux/Ruby 小崎資広氏 【インタビュー】言語は思考にも影響を及ぼす、だからRuby開発を選んだ--まつもとゆきひろ氏 【インタビュー】Rubyが大きくなれたのは、私に隙があるからかな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【海外ITトピックス】 GitHub Copilotに集団訴訟 AI訓練データで初
オープンソースライセンスの基礎と実務
