ownCloudがオープンソースプログラムオフィスを設立し、CLAを廃止する理由

本日、レーゲンスブルクから、Kiteworksは正式なオープンソースプログラムオフィス（OSPO）を立ち上げ、ガバナンス憲章 v0.1を公開し、Contributor License Agreement（CLA）の廃止、Developer Certificate of Origin（DCO）による貢献モデルの導入、正式なAI支援貢献ポリシーなど、多くの新施策を発表します。OSPOはガバナンス機関として機能し、現在は以下のプロダクションラインを運営しています：四半期ごとにリリースされるownCloud Infinite Scale、PHP 8.3へのアップグレードが予定されているownCloud Classic、iOSおよびAndroidクライアントの開発、ベータリリース中のMCP Serverなど、他にも多くのプロジェクトがあります。本記事では、本日提供される内容、進行中の取り組み、そして今後コントリビューター・顧客・パートナーが期待すべきことについてご案内します。

主なポイント

• OSPOは構造的なコミットメントであり、マーケティング活動ではありません。 ガバナンス憲章は、役割分担、意思決定、透明性へのコミットメントを定義しており、コミュニティ諮問委員会の意見を反映しながらv1.0への道筋を示します。
• 従来のCLAは廃止されます。 コントリビューターはDCOサインオフ（git commit -s）を利用し、自身の著作権を保持します。ownCloud GmbHへの著作権譲渡は不要となります。
• AI支援による貢献も歓迎します。 ポリシーは「開示」「理解」「テスト」「ライセンス遵守」の4要件を定め、他のPRと同じ審査基準を適用します。開発力以外の多様な参加も重視しています。
• セキュリティプログラムは稼働中です。 security.owncloud.comでのVDP、YesWeHackバグバウンティでは重大な発見に最大5,000ドルの報奨金を提供しています。
• 2つのプラットフォーム、1つのコミットメント。 ownCloud ClassicはPHP 8.3上で動作し、積極的にメンテナンスされています。oCISは最新のデータベースレス、Goネイティブアーキテクチャです。ownCloud ClassicからInfinite Scaleへの移行ツールは、https://github.com/owncloud/migrate_to_ocis およびownCloud 10 Marketplaceで近日中に提供予定です。
• コミュニティ諮問委員会の導入、公開製品ロードマップ、年次OSPOレポートは、達成済みではなく、確実に実施するためのマイルストーンとして設定されています。

ownCloudはこれまでに2度のフォークを経験しました — 2016年のNextcloud、2025年のOpenCloudです。私たちはその両方を振り返り、商業的に運営されるオープンソースプロジェクトには、包括的なガバナンスと一貫した公開コミュニケーション（意図だけでなく文書による）が不可欠だと認識しました。OSPOはそのための実践的な答えです。

OSPOはKiteworksの傘下にあり、Kiteworksが資金提供しています。私たちは財団が運営するプロジェクトではなく、そのふりをするつもりもありません。私たちが約束するのは、運営が公開の場で行われ、すべての根拠が文書化され、コミュニティが方向性に影響を与える実質的なチャネルを持ち、すべてのガバナンス文書がコメント・修正可能であることです。この関係性を表す言葉としてスチュワードシップ（stewardship）を選びました。Kiteworksは、持続的なエンジニアリング・セキュリティ・ガバナンス投資の企業スチュワードとして、オープンソースプロジェクトと商用エンタープライズ層（人とAIのデータガバナンス・制御・コンプライアンス）の間に明確な境界を設けています。

今回のローンチでは、複数の文書からなるマニフェストスイートを公開します：ビジョン＆ミッション、マニフェスト、Kiteworks CSO Tim Freestoneによる前書き、oCISのプロダクトビジョン、ガバナンス憲章、行動規範、貢献ガイド、AI支援貢献ポリシー、セキュリティ開示ポリシー、エンパワーメントとエンゲージメント文書です。これらはすべて本日公開され、今後の変更には憲章が定める30日間のパブリックコメント期間が適用されます。

CLA廃止：DCOがコントリビューターにもたらす実際の変化

従来のContributor License Agreement（CLA）は、コントリビューターに著作権をownCloud GmbHへ譲渡することを求めていました。これは法的には機能していましたが、エンタープライズの調達チームや独立したコントリビューターにとって障壁となり、私たちが目指すガバナンス姿勢とも一致しませんでした。

今後の貢献はDeveloper Certificate of Origin（DCO）を採用します。これは、リポジトリのライセンスのもとで作業を提出する権利があることを、コミットごとに証明するものです。具体的には以下のようになります：

git commit -s -m "Add this awesome implementation to ownCloud Infinite Scale"

-s フラグを付けると、Signed-off-by:という行に自分の名前とメールアドレスが追加されます。これだけです。著作権は自分に残り、出所を証明します。レビュワーはCIでサインオフを確認できます。このモデルはLinuxカーネルでも20年以上採用されています。過去のCLA下での貢献は元の条件が維持され、今後はすべてDCO方式となります。

新しいリポジトリはApache License 2.0がデフォルトとなります。既存リポジトリも今後Apache 2.0へ再ライセンスされる予定ですが、すべての過去コミットや署名済みCLA、使用ライセンス、出所の個別確認が必要なため、一定の時間を要します。

ガバナンス憲章では4つの役割を定義しています：コントリビューター、レビュワー（PR承認権限）、メンテナー（マージ権限とアーキテクチャ上の意思決定）、OSPO（ガバナンスポリシー・10営業日以内の紛争解決）。メンテナーの判断に納得できない場合はエスカレーションが可能で、OSPOが審査・協議し、期限内に拘束力のある決定を下します。90日もかかる貢献紛争解決はガバナンスとは言えず、むしろ消耗戦です。

AI支援貢献ポリシー：ツールを歓迎し、品質基準を引き上げる

また、多くの商業的オープンソースプロジェクトがこれまで避けてきた「AI支援による貢献」について、正式な立場を公開します。私たちの方針は明確です。AI支援による貢献は歓迎し、他の貢献と同じ品質基準で審査します。 レビュープロセスはコードの作成方法ではなく、動作・テスト・ドキュメント・保守性を重視します。

AI支援によるプルリクエストには4つの要件があります：

1. 開示。 PRの説明欄でAIツールを使用したこと、ツール名（Claude Code、GitHub Copilot、Cursorなど）を明記してください。これはスティグマではなく透明性のためであり、レビュープロセスの改善にも役立ちます。
2. 理解。 コードの動作を理解している必要があります。レビュワーから「なぜこの関数はこうエラー処理しているのか」と聞かれ、「AIがそう書いたから」と答える場合はPRは未完成です。
3. テスト。 AI生成コードにはテストが必要です。ロジックにはユニットテスト、UIには探索的テスト。CIは見落としを検出しますが、コードの本来の目的を考える代わりにはなりません。
4. ライセンス遵守。 PR内のすべてのコードの出所に責任を持ってください。AIツールが非互換ライセンスからコードをコピーしていないか確認してください。

oCISでは既にこのワークフローでマージが行われており、開発手法の詳細はowncloud.devで公開しています。社内エンジニアリングチームも同じ基準でツールを活用し、適切な開示・生成コードの完全な理解・マージに対する人間の責任を徹底しています。

この方針の背景も重要です。AI支援開発が、経験の浅いコントリビューターを排除する口実として使われるリスクが現実にあります。私たちは逆の姿勢を選びます。ownCloudをより良くしたいというビジョンがあり、AIがその実現を助けるなら、ぜひ貢献してほしいと考えています。唯一受け入れられないのは、レビュー中に姿を消すコントリビューターです。人間の責任こそがポリシーの核心です。しかし、上級レベルのコーディング能力が排除の道具になるべきではありません。オープンソースは、そして今も、包摂のためのものです。

2つのプラットフォーム、1つのコミットメント：oCISで未来を築き、Classicで信頼を守る

OSPOの立ち上げは、ポートフォリオについて明確にする良い機会でもあります。ownCloud Infinite Scale（oCIS）は現行のプラットフォームで、Go言語で書かれたApache 2.0ライセンス、データベースレスのGoネイティブアーキテクチャを採用し、メタデータはDecomposedFS抽象化を通じてノード上のメッセージパックファイルに保存されます。中央のSQLデータベースにプラットフォーム状態を保持しないため、データベース関連の運用課題（アップグレード時のスキーマ移行、負荷時のSQLボトルネック、データベースレベルの権限昇格経路）が排除され、ファイルシステム操作でメタデータがファイルと一緒に移動します。

同じコンパイル済みバイナリが、小規模サーバーでの単一プロセスからKubernetes上の分散マイクロサービスまでスケールします。プロダクションストレージバックエンドはPOSIX/NFSやS3互換オブジェクトストレージ（AWS、MinIO、Ceph）に対応。CERN EOSは技術プレビューとして利用可能ですが、プロダクション用途ではありません。認証はOIDC専用。ポリシーはFile Firewall経由でOPA/Regoによりプログラム可能。フェデレーションはOpen Cloud Meshを使用。オフィス統合はCollaboraとONLYOFFICEによる強化WOPI経由。監査ログはSIEM取り込み用の構造化JSON形式で出力されます。プラットフォームが公開するすべてのインターフェース（WebDAV、OIDC、OCM、CS3APIs、LibreGraph、OPA/Rego）は、オープンスタンダードまたは公開仕様です。CERNで10億ファイル・マルチペタバイト規模の研究コンピューティングや、バイエルン州の学校クラウド（ByCS）など、公共部門でも本番運用されています。

ownCloud Classicは、Linux・Apache・SQL・PHPベースのプラットフォームで、PHP 8.3へアップグレードされ、引き続きセキュリティ・メンテナンスリリースが提供されています。ClassicからoCISへの移行ツールも間もなくリリース予定です。コミュニティ・エンタープライズの顧客は、移行ツールが一般提供され次第、自身のタイミングで移行できます。

参加方法

まだ存在しない仕組みこそ、今後皆さんの参加が必要となります。具体的な次のステップ：

• github.com/owncloud のGitHubリポジトリをウォッチ： oCIS、Classic、クライアント、Web拡張機能など。good-first-issueやhelp-wantedラベルのIssueは本当に協力を求めています。
• 公開ポリシーを読む。 ガバナンス憲章、AI支援貢献ポリシー、セキュリティ開示ポリシー、貢献ガイドなど。
• 脆弱性レポートを提出 VDPまたはYesWeHackバグバウンティにて、何か発見した場合はご報告ください。
• コミュニティ諮問委員会の設立に応募 2026年第4四半期に外部メンバー5〜9名を12ヶ月更新制で公募します。ノミネーションは公開で行われます。
• OSPOへの連絡はospo@kiteworks.comへ。 行動規範に関する連絡はcoc@owncloud.comへ。エンタープライズサブスクリプションを検討中の組織はお問い合わせページをご利用ください（ただしこれは補足情報です）。