WiX Toolset、オープンソースの「メンテナンス費用」ポリシーを導入
(github.com/wixtoolset)- WiX Toolset プロジェクトは、長期的な持続可能性を確保するため、Open Source Maintenance Fee（オープンソースのメンテナンス費用）ポリシーを導入
- ソースコードはライセンスに従って無料で提供されるが、Issue登録・意見投稿・新規リリースのダウンロードなど、ほとんどの作業にはメンテナンス費用ポリシーが適用される
- 特に、このプロジェクトを利用して収益を上げている場合は、必ず該当するメンテナンス費用の支払いが必要
- 費用の支払いは GitHub Sponsor になる形で支援可能
- 小規模組織（20人未満）: $10/mo
- 中規模組織（20〜100人）: $40/mo
- 大規模組織（100人以上）: $60/mo
- ポリシーの詳細は Open Source Maintenance Fee 公式サイト で確認可能
2件のコメント
実質的にRHELと同じですね。
Hacker Newsの意見
私は今回のやり方が気に入っている。基本的な考え方は、誰もこれをクローズドソースにしてほしいわけではなく、コードは誰にでも自由に公開されていて、誰でも自由に活用できるということだ。コードを配布する追加コストは実質ゼロだからだ。しかし、メンテナーは企業に無償で慈善事業のように提供したいわけではない。自分たちの時間には限りがある以上、収益を生む活動に貢献するなら、ある程度の対価を求めるのは当然だ。この方式が完全に強制されなくても構わない。これでメンテナーは、クレームに対して「こちらに対応してほしいなら費用を払ってください」と答える自由を得る。費用を払った企業は一定水準のサポートを受け、一般ユーザーはこれまでと同じ体験を得る。この警告を無視する企業だけが結果を引き受けることになり、特に「多くの重要なユーザーが影響を受ける」といった訴えに対して効果的だ。本当に必要なら費用を払うべきだ。AIが作ったコードやレポートなどが増えている今、オープンソースでよく起こる問題にかなりうまく対応する解決策だと思う
この点については複雑な気持ちだ。Wixのユーザーではなく、今回の件そのものに対する一般論だ。オープンソースプロジェクトは誰にも維持を強制できない。すべての修正は自発的に行われるものだ。どんな企業も、PRを受け入れたり作業したりすることを強制できない。FOSS開発者がしばしばストレスを抱えるのは分かるが、金銭的動機がないなら、ただ断ってよい。不満は出るかもしれないが、問題を必ず直す義務はない。スポンサー型モデルは、結局FOSSをビジネスモデル化するように感じる。そうなるともはやFOSSではなくなる。FOSSの本質は、誰でも複製し、改変し、ビジネスに発展させられる点にある。ほとんどのライセンスでは、それに同意しているはずだ。自分の意見は人気がないかもしれないが、この件で怒りを爆発させる必要はないと思う
この方針には2つの面で否定的な点があると思う。第一に、貢献者をさらに集めにくくなる可能性がある。有償の貢献者と無償の貢献者に分かれる二層構造が生まれうる。「自分は無償でバグ修正しているのに、他の人は金を稼いでいる」といった不満が出かねない。第二に、お金を受け取る瞬間に取引の性格が強まる。お金を受け取った以上、それに対する要求や作業が生じる。もちろん、ボランティアモデルにも継続性の問題はある
私はこれがそれほど革新的だとは思わない。無料で製品を配っていたのを、今度は有料で売る仕組みに変えたということだ。つまり、普通のビジネスのように運営しているように感じる
誰でも望む機能やサポートのためにお金を払えるようにして、コードは一定の閾値に達するまではクローズドソースのままにしておくほうがよいと思う。この閾値は関心度や収益に応じて数か月から数年かかるかもしれない。最終的にはオープンソースとして公開される。そうでなければ、皆が誰かが代わりにお金を払ってくれるのを待つことになる。もちろん、フォークが乱立しないようにうまく設計する必要はあるが、十分に可能な方法だ
すでにいくつものオープンソースプロジェクトがこうしたやり方を採用しているものだと思っていた。Busyboxを保守しているコンサルタントの事例がそれに当たると思っていたが、私が状況を誤解していたのかもしれない
Wixというウェブサイトビルダーとは何の関係もなく、ここで言っているのは WiX Toolset のことだ
「最も強力なWindowsインストール体験を作り出すツールセット。2004年からオープンソース！」という紹介文だ
ありがとう。最初はWixのことだと勘違いしていた。Wixは本当に高品質なReact Nativeライブラリをたくさん作っている
数か月前、自分のオープンソースプロジェクト向けインストーラーを検討しているときに、偶然この方針を知った。ソースコードがOSIライセンスの下にあるなら、バイナリ販売そのものには問題意識はない。ただ、READMEに書かれている次の文言が気になった。"このプロジェクトの長期的な持続可能性のため、WiX Toolsetの利用にはオープンソース保守費が必要です。ソースはライセンスの下で自由に提供されますが、Issueの作成・コメント、議論への参加、リリースのダウンロードなど、その他すべての機能も保守費に従う必要があります。つまり、収益目的での利用には保守費が求められます。" これは短い文で説明しづらい概念なので、善意で解釈することはできる。しかし、「収益利用なら金を払え」という要約はむしろ誤解を招きうる。MS-RLライセンス上、直接ビルドして使うなら商用目的でも制約はないので、これは商用利用者をスポンサーに変えようとする一種の「脅し」の手法に感じられる。オープンソースメンテナーが直面する苦労は理解しているが、このアプローチは自分には倫理的にしっくりこなかった。だから商用利用者ではないにもかかわらず、WiXの利用を見送った
これは商用利用者を無料でサポートしないという明確な意思表示だ。あなたは説明が明確ではないと言ったが、引用した文には「ソースはライセンスに従って自由に利用できる」とはっきり書かれている
スタートアップや資金の乏しい小規模企業は、オープンソースプロジェクトを持ってきて自分たちでビルドし、配布アーティファクトにして自前で管理する。ある程度の規模になると、そのプロセス全体を管理してくれる公式サポートに費用を払うほうが価値がある。今回の方針は、オープンソースのバイナリだけを取って使うことで生じる直接サポートのリスクを企業が負いたくない場合に、公式サポート費用を払うよう促すものだ
このアイデアを一文で短く説明するのは本当に難しい。オープンソースプロジェクトごとに期待値があまりにも違うからだ。テキストをどう改善すべきか提案があれば、ぜひ聞きたい
私の理解では、収益を上げる組織を代表して何かを要求する場合、対話するには必ず費用を払う必要があるということだ。収益上の利益を目的としてコミュニケーションするなら、費用を払う仕組みだ
GitHub Issueのコメントを読むと、チームはかなり理性的だと感じる。私の理解では、本当に収益を上げている場合にだけお金を求めている。完全な一人開発者や初期段階の製品なら、たぶんそれほど気にしないと思う。スポンサーシップページ もある
https://opensourcemaintenancefee.org/ のサイト自体についての話だ。ダークモードでしかまともに見えず、ライトモードではほとんど読めない。リポジトリでIssueも開けなくなっている。もしかすると作者がここでコメントを見るかもしれない（可能性は低いが）
Issue登録には保守費が必要だったんですね！ 冗談です
おお、深刻な問題だった。今はたまたま来た貢献者のおかげで修正されている！
うちの会社の法務チームなら、こういうEULA（エンドユーザーライセンス契約）を見たら、こちらに支払う代わりに、このツールの使用をただちにやめろと言うだろう。たいていの企業もこう対応すると思う。メンテナー側としてはそれでも構わないのかもしれないが、私はこういう形で商用利用を制限しつつオープンソースを維持したいなら、AGPLを付けるべきだとずっと主張してきた。AGPLはエンタープライズにとってほとんど毒物だ。私が勤めたどの会社も、商用製品にAGPLコードを使うことを認めなかった。その後で商用ライセンスを有料で売ればよい
オープンソースプロジェクトはしばしば慈善と名誉のシステムのように機能する。貢献者は名誉を得て、活用する企業は収益という利益を得る構造だ。こうして双方が利益を得て、間接的に人類にも役立つモデルになっている。私は個人的に――たぶんナイーブだが――この慈善が全人類にもう少し直接的かつ明確に還元されてもよいと思っている。たとえば、プロジェクトが公開ライセンスで公開されるとき、それを使って収益を得る企業は売上の1%ほどをグローバル基金、つまり "Decentralized Universal Kindness Income" (DUKI) に寄付する仕組みだ。主導的な貢献企業には、寄付の全部または一部の免除特権を与え、他の大企業が競争に使ってもある程度優位を保てるようにする（Redisがライセンスを変えたのもこうした理由だ）。貢献者は世界中でより大きな認知と名誉を得て、寄付する企業はオープンソース資源を広く活用できるだけでなく、マーケティング面でも評判向上の効果を得られる。利益だけを追う企業より、はるかに競争力がありうる。私はこれを「DUKIライセンス」と呼んでいる。要点は、MITライセンスに利益分配条件をひとつ加えることだ。残念ながら、私にはこれを売り込めるほどの影響力はなく、オープンソース生態系を率いる中核メンテナーや創業者たちが受け入れるかどうかも分からない
「ソースコードはライセンスの下で自由に公開されるが、Issue登録・コメント、議論への参加、リリースのダウンロードなど、他のすべての活動は保守費の順守を求める」という内容だが、リリースのダウンロードまで含まれているのには驚いた。弁護士ではないが、私にはライセンス自体と矛盾しているように見える。具体的には、「各貢献者は、非独占的・全世界的・ロイヤリティフリーの著作権ライセンスを受け、成果物および派生物を配布・使用・変更できる」という条項だ。こういうやり方ではむしろ混乱が増すだけで、事実上リリースを自動ミラーリングするフォーク生成の自動化を強いることになる。すでにrepoにはそのためのgithub actionsも提供されている
引用したライセンス条項は、そのコードをコピーし、変更し（あるいはコンパイルし）、配布する権利があるというだけだ。バイナリまで必ず配布しなければならない義務はない。実際、こうしたやり方はかなり一般的だ。オープンソースライセンスの多くはソースにしか適用されない。「自動ミラー・フォークを誘発する」という指摘にも一理あるが、実際にはソフトウェア開発者にとって、自分でクローンしてビルドするのはもともと簡単で自然なことだ。昔からソースを自分で複製して使うのが基本で、だからこそFOSSは人気を得た。これは「迂回」というより、FOSSそのものの本質だ
まったく同意する。ただ、現実はそうではなかった。ほとんどの企業は私たちの保守費を十分に妥当だと考え、プロジェクトの保守やフォークリスクを避けつつ公式サポートを受けるほうを好んだ
この件の「盛り上がり」を私が理解できていないだけかもしれない。ライセンスは変わらないのに、保守費を払わないとサポートを受けられないということか？ 誰かが脆弱性を報告しても、報告者が先に保守費を払わないとWiXはパッチを出さないのか？ あるいは企業ユーザーが良い機能案を出しても、保守費を払うまでは無視されるのか？ あまりに当たり前の話に思える。オープンソースの作者はもともと、どのPRを受けるか、どのIssueに関心を持つかを自分で決める。サポートに料金を請求することだってできた。保守費制度が何の革新なのか疑問だ。批判したいわけではない。オープンソースライセンスでツールを作ってくれるのは素晴らしいし、支援金を受け取るのも当然だと思う。貢献者が疎外感を覚えるなら、いつでもフォークすればよい。これは新しい概念ではない。もちろん、フォークは金銭的にも人的にもかなり資源の要る決断だ。Amazon級の大企業であっても、原著者に金を払って関心を引くほうが効率的だ。LibreOffice、io.js、OpenTofu、neovimのような例もある。LibreCADのようにうまく分化させられるなら、それもまた実力だ。io.jsはnodejsをより健全にしたのだから意味があった。コミュニティの力こそ、これがオープンソースの大きな強みだ。コード、文書、資金、アイデアなど、誰でも貢献できる。WiXもこういう形でコミュニティに参加してくれて感謝しているし、今後もうまくいってほしい
WiXインストーラーは複雑で、理解しづらいツールだ。無料という利点ひとつだけで使っていた。もし有料なら、もっと簡単でサポートの良い商用製品を使うだろう。Rob Menschingは年額$5,000のコンサルティングとサポートサービスで収益化を試みていたが、結局それでは足りないようだ
「無料だったのが唯一の利点だった」というのは、お金をかけずにインストールツールを使っていた人にとってはその通りだろう。しかし、WiXの最大の価値は単に無料であることではない。WiX Toolsetは、他のどのインストールツールでも実現できない形でWindows Installerの潜在力を活用できる。単純な機能しか不要でなければ、たしかに扱いにくく不足も多かった。しかし、難しいインストール問題に対しては、こうした鋭い機能こそがむしろ必要だった。「年額$5,000のコンサル収益化」について言えば、私は単にWiXそのものから年$5,000を稼いでいるわけではない。私たちのチームと私が数十年かけて蓄積したインストーラーパッケージのノウハウと、FireGiantが提供する高度なツールを活用した「WiX Developer Direct」プログラムを通じて、高価格帯のカスタムサービスを提供している。月次のオフィスアワー、SLA保証、年次コードレビュー、高度なツールなど、ハイエンドなサービスを提供しており、顧客も高く評価している。十分ではないという話ではなく、最近のXZ Utils事件を見て、オープンソースの持続可能性が本当に深刻だと実感した。だから何か方法を探そうとしていて、Open Source Maintenance Feeは私のプロジェクトのようなものにはかなり良い解決策のひとつだと思っている。WiX Toolsetは現在このモデルを最初に導入しており、試行錯誤を通じて実際にどう機能するかを試す実験場の役割も果たしている。今のところ非常にうまく回っている
WiXは実質的に、Windows Installerで使われる内部データベース構造を直接XMLで記述できるツールだ。MSIフォーマットとWindows Installerが非常に複雑なのでそうした評価になるが、WiX自身というより、MSIというフォーマット自体がもともと「複雑な迷宮」に近い
ライセンスはMSにあるものだと思っていたが、ライセンス全文 を参照すると、「GitHubとNuGet.orgで公開されたバイナリリリースには、保守費の支払いを求めるEULAが適用される」とある。私も弁護士ではないが、この場合、自分でビルドして配布すれば保守費を回避できるのではないか？ そして、そのビルド成果物を無料で配ることもできるのでは？
コードはMicrosoftではなく .NET Foundation の所有だ（経緯は複雑だ）。自分でビルドして保守費を回避することも、実際に完全に認められている。これからは50万行のコードを自分で責任を持つことになるだけだ。本物のフォークを楽しんでくれ！
repoのREADMEによれば、ソースコードはオープンソースだが、repoのIssue・リリース機能には保守費の支払いが必要だと明記されている