オープンソース協会開源社

以下の記事は、Mulan が執筆した、Mulan オープンソース コミュニティからのものです。

以下の記事は、Mulan が執筆した、Mulan オープンソース コミュニティからのものです。

2024年3月下旬から4月上旬にかけて、オープンソース企業のインターン生が勤務時間中に提出したプルリクエスト（PR）が、Nightingale GitHubリポジトリ上でクローズを求められていました。このPRは、インターン生が署名した知的財産権契約に基づき、当該PRの知的財産権は個人ではなく企業に帰属すると主張し、クローズを要請しました。その後、当該PRはクローズされました。

このCEOが言及した知的財産権契約は、雇用契約や関連する秘密保持契約によく見られる「従業員が雇用期間中に開発したプロジェクト、特許、著作権は会社に帰属する」という条項に類似していると思われます。さらに、国内法では、コード、特許、著作権など、会社の事業範囲と重複するものはすべて会社に帰属するとされています。

ここで疑問が生じます。開発者がオープンソースプロジェクトに貢献する場合、通常、CLA（貢献者ライセンス契約）または類似の契約に署名することが求められます。この契約は一度署名するだけで、その貢献者が提出するすべてのプロジェクトに有効です。この契約の目的は、貢献者が所有する著作権および特許ライセンス権が、プロジェクト管理組織およびプロジェクトのユーザーに合理的かつ完全かつ取消不能な形で付与されることを保証することです。

上記のケースではオープンソース プロジェクトが PR を失っただけでしたが、前のケースでは開発者が自分のプロジェクトを失うことになりました。

2019年12月、ロシア警察はNGINX（nginxサーバープロジェクトを商用化する企業）のモスクワオフィスを家宅捜索し、NGINXの共同創設者であるイゴール・シソエフ氏とマキシム・コノヴァロフ氏を逮捕しました。シソエフ氏はnginxサーバープロジェクトの考案者でもあります。これは、ロシア最大の検索エンジンおよびインターネットポータルの一つであるrambler.ruの親会社であるRambler GroupがNGINXに対して提起した著作権侵害訴訟に端を発しています。Rambler Groupはnginxウェブサーバーコードの完全な所有権を主張し、シソエフ氏が同社のシステム管理者として勤務していた間にnginxを開発したため、プロジェクトの法的所有者は同社であると主張しました。

「スラッシュ・ユース」という言葉が今、流行しています。これは、自分の情熱と強みを活かし、興味のある業界や仕事に積極的に参加することで、スキルと収入を向上させたいと考えている人々を指します。オープンソースへの参加は、このスラッシュ精神に完全に合致しており、開発者はより多くのプロジェクトを学び、参加することでスキルを向上させ、履歴書を充実させると同時に、本業にも貢献し、企業にさらなる価値をもたらすことができます。

しかし、これら 2 つの事例により、オープンソースへの参加はリスクの高い取り組みとなりました。

開発者にとって特に興味深い次の 5 つのトピックに対処するために、Mulan オープンソース コミュニティは、OSPO、ホスティング プラットフォームの技術リーダー、弁護士、オープンソース プロジェクト リーダーの専門家を招き、多面的な洞察を提供してもらいました。

• 個人の CLA が雇用主に認められず、オープンソース プロジェクト コミュニティがそれに従わざるを得ない場合、それに署名する意味は何でしょうか?
• オープンソース プロジェクト コミュニティはどのようにしてこのリスクを回避すべきでしょうか?
• オープンソースへの貢献に専念するために仕事を辞めるのは明らかに非現実的です。では、企業に勤めながら、個人がオープンソースへの貢献に合理的に参加するにはどうすれば良いのでしょうか？
• 誰もが持つ職務は能力に直接関係しており、オープンソースへの参加や独自のオープンソースプロジェクトの作成は、主にこの点に左右されます。では、雇用されている立場で、どうすれば独自のオープンソースプロジェクトを成功させることができるのでしょうか？
• 中国の労働契約における知的財産関連条項は雇用期間との関係でどのように解釈され、また関連訴訟の判例は中国法ではどのように扱われているのでしょうか。

01 アント・ファイナンシャルのオープンソース技術委員会の副委員長であり、Kata Containersプロジェクトの創設者である王旭氏

コード配布時に法的拘束力を持つオープンソースライセンスとは異なり、CLA（貢献者ライセンス契約）は、プロジェクトにコードが貢献された際に締結される契約です。一般的に、CLAは将来のライセンス変更を容易にするなど、特定の権利をプロジェクトオーナーに譲渡します。プロジェクトのメンテナーや開発者にとって、CLAに明示的に署名することは、少なくとも法的に明確な権利譲渡となります。予期せぬ事態に直面するよりも、将来のライセンス変更について最初から明確にしておく方が常に望ましいでしょう。

一般的に、ライセンス（CLA）は、個人開発者向けの個人ライセンス（ICLA）と組織向けの企業ライセンス（CCLA）の2つのカテゴリに分類されます。企業で勤務中に開発された知的財産は企業に帰属するため、理論上は企業ライセンスのみが法的に有効であり、個人ライセンスは適用されません。したがって、手続き上、このPRにはライセンス上の問題があります。もちろん、このアプローチはオープンソースコミュニティと企業の社会的イメージの双方にとって、明らかに双方にとって不利な状況であり、CCLAの再締結など、より良い解決策があった可能性があります。

しかし、近年、コミュニティ内で CLA を放棄する傾向があります。多くの貢献者は、CLA に署名した後、プロジェクト管理者がソフトウェアを恣意的に変更してオープンソースでなくなることを望んでいません。プロジェクトが無期限にオープンソースのままでいるつもりであれば、CLA に署名しないか、その要件を緩和する方が良い場合があります。たとえば、Fedora は CLA を FPCA に置き換え、すべての貢献にオープンソース ライセンスが適用され、貢献者に署名しない権利があることを保証しました。2017 年に Kata Containers プロジェクトを作成したときも、CLA が必要かどうかについて議論しました。最終的に、財団は、Apache 2.0 ライセンスで既にコードの無償配布が保証されているため、コードの著作権はオープンソースとしての使用に影響を与えることなく元の作者に帰属させることができると判断し、プロジェクトには CLA がありませんでした。

したがって、商用オープンソースプロジェクトであっても、CLAは必須ではありません。CLAを悪用してプロジェクトの将来的なオープン性に疑問を抱かせることは推奨しません。しかし、CLAに関する事例は、オープンソースソフトウェアにおける著作権の存在と複雑さをより深く理解する助けとなり、ソフトウェアの知的財産権に関する皆様の理解を深める一助となるでしょう。皆様がオープンソースについてより深く学び、愛着を持っていただけることを願っています。

02 CCFオープンソース開発委員会副事務局長、TrustieおよびGitLinkオープンソースプラットフォームのテクニカルリーダー、Wang Tao氏

オープンソースプロジェクトの成功は、オープンソースコミュニティの積極的な貢献に起因します。CLA（Licensed Access Decision）は、オープンソースプロジェクトへの最初の貢献者が発行するライセンス契約であり、貢献者に貢献内容の使用を許可するものです。CLAに署名することで、オープンソースプロジェクトにおける潜在的な知的財産コンプライアンスリスクを軽減できますが、貢献者の権利保護という点では依然として不十分です。オープンソースの知的財産管理には、貢献者、オープンソースプロジェクト、そして貢献者が所属する組織の利益のバランスを取ることが求められ、更なる探求と実践が必要です。

GitLinkプラットフォームは、コミュニティ貢献の公証、所有権の確認、そしてインセンティブを実現するために、ブロックチェーン技術の活用を模索しています。貢献への事前参加とプロセス中の合意形成のプロセスを簡素化し、その後の法的追跡の基盤を提供することを目指しています。この点において、有益な研究成果を提供できることを期待しています。

03 タオ・イェ、グランダル法律事務所（南京）パートナー

これは多くのオープンソース愛好家が非常に懸念している問題です。個人貢献者の多くは、主に個人的な興味からオープンソースに貢献しており、そのような貢献に伴う訴訟のリスクは、彼らの熱意を著しく削ぐ可能性があります。

我が国では、「コンピュータソフトウェア保護規則」に基づき、以下のソフトウェア作品の著作権は会社に帰属します。「職務上明確に定められた開発目標のために開発されたソフトウェア、職務上予見された結果または当然の結果として開発されたソフトウェア、法人またはその他の組織の資金、特別な設備、未公開の専門情報、その他の物質的および技術的条件を主として利用して開発され、かつ、法人またはその他の組織が責任を負うソフトウェア」。これは従業員の権利に対する法的制限です。

さらに、多くの雇用契約書には「従業員が雇用期間中に作成したソフトウェアの著作権は会社に帰属する」という条項が含まれており、これも従業員が合意によりソフトウェアの著作権を取得することに対する制限となっています。

しかし、このような制限は私の国に限ったものではなく、その存在がすべてのオープンソースへの貢献を自動的に否定するわけではありません。米国にも同様の規制があり、米国著作権法第201条(b)は「職務著作」のルールを規定しています。しかし、Roeslin v. District of Columbia, 921 F. Supp. 793において、原告のRoeslinはコロンビア特別区の職員でした。最終的に裁判所は、Roeslinが権利を主張したソフトウェア作品は、雇用主から直接委託されたものでも、彼の日常業務から予見可能な成果物でもなかったと判断しました。さらに、当該作品は主に勤務時間外およびオフィス外で完成されたため、「職務著作」のルールには該当しませんでした。これにより、米国の開発者は余暇にオープンソースへの貢献に参加することが可能となります。

国内開発者の場合、オープンソースコントリビューターの多くは職務経験に関連したプロジェクトを選択しますが、必ずしもそれが職務に直接関連しているとは限りません。コントリビューターは、使い慣れた技術スタック内の他の技術をコントリビュートすることもできます。さらに、コントリビューターは職務に直接関連するコードのコントリビューションを避け、勤務時間中に業務用コンピュータを使用してコードをコントリビュートすることも避けることが推奨されます。

04 ライ・ウェイ、Kuaimao Nebula CEO

オープンソースプロジェクトがプルリクエスト（PR）を提出する際にライセンス契約（CLA）に署名し、企業が採用時に適切な知的財産契約に署名することは、合理的かつ標準的な慣行だと私は考えています。前者は、オープンソースプロジェクトが知的財産紛争を回避し、受け入れた貢献が自らのライセンス要件に準拠していることを保証するのに役立ちます。後者は、企業が知的財産を保護するために必要な措置です。

両者の衝突は偶然ではありません。オープンソースプロジェクトへの貢献は、いずれの当事者の正当な利益も損なってはなりません。この原則に基づき、開発者の自己実現、オープンソースプロジェクトの健全な発展、企業の知的財産権の保護、そして企業がオープンソースプロジェクトから得られる利益という観点から、衝突を回避し、Win-Winの関係を築く方法を見つけることができます。

多くの大手企業がオープンソースプロジェクトオフィスを設立しているのを目にしています。彼らは、自社のビジネスニーズとビジネスモデルに基づき、オープンソースに関する戦略、外部プロジェクトへのコード貢献手順、そしてオープンソースプロジェクトの活用に関する評価基準を策定しています。これは、企業が自社の権利を守りながらオープンソースを活用し、貢献していくための良い実践例と言えるでしょう。

オープンソースは大きな社会的価値と競争優位性を持っています。コミュニケーション不足や二重基準が主な論点となるケースもありますが、それがオープンソースのコラボレーションモデルを否定するものではありません。

転載元：Mulanオープンソースコミュニティ

編集者：nomi

関連資料

AI が生成したコードは高速で優れていますが、信頼してよいのでしょうか?

信頼できるオープンソースと業界の進歩を共に – 2024年OSCARオープンソース業界カンファレンスが正式に開始

オープンソース協会の紹介

2014年に設立されたオープンソース協会（KAIYUANSHE）は、オープンソースの理念に献身的に貢献する個々のボランティアで構成されるオープンソースコミュニティであり、「貢献、合意、そして共同統治」の原則に基づき活動しています。KAIYUANSHEは、「ベンダー中立性、公益性、非営利性」の原則を堅持し、「中国を拠点とし、世界に貢献し、新時代のライフスタイルとしてオープンソースを推進する」というビジョンを掲げています。その使命は「オープンソースのガバナンス、国際的な連携、コミュニティの発展、そしてプロジェクトのインキュベーション」であり、健全で持続可能なオープンソースエコシステムの共創を目指しています。

オープンソース協会は、オープンソースを支援するコミュニティ、大学、企業、政府機関と積極的に連携しています。また、世界的なオープンソースライセンス認証組織であるOSIの中国初の会員でもあります。

2016年以降、中国オープンソースカンファレンス（COSCon）が毎年開催され、「中国オープンソース年次報告書」が継続的に発表されています。また、「中国オープンソースパイオニアリスト」と「中国オープンソースコードパワーリスト」も共同で立ち上げ、国内外で幅広い影響力を発揮しています。