このドキュメントは、ASF の公式リリース ガイドに基づいて、リリース プロセスで最も見落とし/間違いやすい部分に焦点を当てて抽出および簡略化しています. 初めてリリースに参加する学生、特に担当者各倉庫/モジュールを完了する必要があります。よく読んでください。不明な場合は、時間内に連絡してください。
注: この記事では、インキュベーターに参加したプロジェクト、つまりインキュベーション中のプロジェクトを主に説明し、卒業プロジェクトやその他の種類の追加説明は行いません。
※掲載ガイドライン：
https://infra.apache.org/release-distribution.html
0. 序文
ASFにとって初めてのインキュベーションプロジェクトの場合 、最初のリリースでは多くの小さな問題やトラブルが発生すると思いますが、特に 典型的な代表者としてライセンス/通知/著作権 に関連する問題について考えてみると、主な理由はする：
ASF の公式ドキュメントは散在しており、リリースに参加していないコミュニティの一般的な開発者や学生は、多くの場合、すべてのドキュメントを読んで重要な問題に気付く (または逸脱を理解する) ことに忍耐力がありません。
ASF の公式文書は、一部の説明がまだ曖昧であるか、PMC/Mentor/Mail が決定について話し合うことを直接推奨していますが、通常、結論のこの部分は更新されず、文書に記録されていません。
ASF 関係者は、 skywalking-eye (ヘッダー/依存関係)に似た自動検査ツールを推奨していません 。これらのツールは、初めて出版する学生にとって非常に役立つ可能性があります。
ASF 文書の一部の規範/規則は厳密に要求されているわけではありませんが、異なるレビュアーは、公開および投票する際の習慣/好みが異なる可能性があるため、改善のためにいくつかの「提案」を提出します。
「中国語/英語」言語/意味理解の逸脱で、一部のコンテンツの誤解につながります。
Apache HugeGraph の最初のリリースの機会を利用して 、PR/メールで遭遇した問題と経験をまとめました. 個人的な理解のため、不正確な場所があるかもしれません. 類似点を避けるために、皆さんを歓迎し、一緒に確認し、補足し、改善してください.問題は、 インキュベータ プロジェクトのリリース プロセスで繰り返し発生しました。
*Apache HugeGraph:
https://github.com/apache/incubator-hugegraph
0.1 名詞
本文中に現れる一般的な名詞の略語:
ASF: アパッチ ソフトウェア ファンデーション
ASL2.0: アパッチ ソフトウェア ライセンス 2.0
0.2 ASF & アパッチ
新入生は、 ASF メール/ドキュメントで Apache プロジェクトを直接使用するのではなく、 ASF プロジェクトの使用を提案/カスタマイズする という説明を頻繁に目にすることに戸惑うかもしれません。これは、Apache プロジェクトが曖昧になりがちなためです。Apache には他の多くの意味があるため、 Apacheソフトウェア ライセンスを使用するプロジェクトを指す場合があります が、ASF (Foundation) プロジェクトにはいくつかの個別の要件/制限があり、説明で区別されます。誰もが対応する意味を誤解しないようにし、 Apacheソフトウェア ライセンス を使用する非 ASF プロジェクトを導入すること と、 ASF名の下にプロジェクトの依存関係を導入することの違いをよりよく理解できるようにします。
1 . ライセンス
LICENSE は 小さな問題が発生しやすい場所です。必ず 1 つずつ確認して確認してください (わからない場合は、公式の指示/メール/メンター通信を参照してください)。
すべてのソースおよびバイナリ パッケージ(リリースされたjar パッケージを含む)は、 LICENSE + NOTICE + DISCLAIMERファイルを提供する必要があります。
ソース パッケージは、プロジェクトのルート ディレクトリに配置する必要があります。
バイナリ パッケージは通常、ルート ディレクトリにもあります (注: この項目は他の ASF プロジェクトを参照しており、ASF は今のところ厳しい要件を見つけていません)。
LICENSE ファイルの元のバージョンは完全で、形式/内容が正しい必要があります。公式バージョンを直接ダウンロードして、プロジェクト ディレクトリに配置してください (手動でテキストをコピーして貼り付けることは避けてください)。
LICENSE/NOTICE ファイルには不要な情報を含めないようにすることをお勧めします.たとえば、使用していない依存関係の LICENSE は含めないでください.依存関係を削除/更新する場合は、対応する LICENSE/NOTICE 情報を更新/削除する必要があります.間に合います。
参照されるサードパーティライセンスについては、詳細情報をLICENSE ファイルに添付する必要があります。参照されるLICENSEが非常に長い場合は、別のファイルを保存して指定する必要があります。
例LICENSE-<依存関係名>.txt。
参照コードのソースが標準 (変更されていない) APL2.0契約である場合、相手が標準バージョンであることを示すことができ、コピーを繰り返すことなくルート ディレクトリにあるAPL2.0 LICENSEを直接参照できます。
バイナリ パッケージにも特別な注意が必要です. 通常,含まれる LICENSE + NOTICE ファイルの内容はソース パッケージとは異なります. 同じファイルを直接再利用しないでください:
ソース コード パッケージは通常、バイナリ/jar パッケージ/画像などの依存関係を持たないため、その LICENSE と NOTICE は はるかにシンプルでクリーンです. 主にソース コードの参照を宣言します.
バイナリ パッケージは通常、ソース パッケージの 2 つのファイル参照に基づいており、参照されているすべてのサード パーティの依存関係/画像/バイナリ ファイルと、それに対応する LICENSE ファイルを補足する必要があります。
サードパーティが複数のLICENSEライセンス ( ASL2.0 & GPLなど ) に依存している場合は、すべてを一覧表示するのではなく、1 つのLICENSE参照のみを選択することをお勧めします(他のユーザーが確認するのは不便です)。
一般に、複数選択の基本的な基準は、B タイプが考慮されていない場合、ASF 文書に記載されているA タイプの緩やかなライセンスを選択することです。
依存する LICENSE ファイルが独立して存在する場合は、選択したコンテンツのみを選択する必要があります (たとえば、 GPL またはその他の冗長な宣言の参照を削除します)。
実際、一部の ASF プロジェクトではLICENSE ファイル内のすべての LICENSE エントリに依存関係が導入されていることがわかりますが、これは推奨される書き込み方法ではない可能性があります (コピーを参照することは避ける必要があります)。
*公式説明:
https://infra.apache.org/licensing-howto.html
* LICENSE ファイルの公式バージョン:
https://www.apache.org/licenses/LICENSE-2.0.txt
* クラス A パーミッシブ ライセンス:
https://www.apache.org/legal/resolved.html#category-a
ドキュメントを読む以外に、公式の例や他のインキュベータ プロジェクトを参照し、それでもわからない場合はメンターやコミュニティに尋ねるのが最善の方法の 1 つです (自分で推測しないでください)。
httpd - ソース
https://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE
シートトンネル - ソース
https://github.com/apache/incubator-seatunnel/blob/dev/LICENSE
シートトンネル - バイナリ
https://github.com/apache/incubator-seatunnel/blob/dev/seatunnel-dist/release-docs/LICENSE
リンクス - ソース
https://github.com/apache/linkis/blob/master/LICENSE
リンク - バイナリ
https://github.com/apache/linkis/blob/master/linkis-dist/release-docs/LICENSE
注: Linkis は 卒業しました。最新のドキュメントを注意深く参照してください。卒業前のスナップショットにジャンプできます。
2. ライセンス ヘッダー
上記でプロジェクト全体のLICENSE参照を終了したので、多くの学生が混乱するかもしれない ライセンス ヘッダーについて話しましょう(たとえば、グローバルに宣言されている理由と、各ファイルを個別に宣言する必要がある理由など)。
まず第一に、ほとんどのオープンソース組織は、プロジェクトの各ソース ファイルに明確なライセンス ステートメントを含めることを要求しています。
第 2 に、元のLICENSEファイルは一般に非常に長いため、簡潔にするために、ライセンス ヘッダーと呼ばれるファイル ヘッダーで省略版を引用し、完全版をルート ( LICESEN ) の下に配置することを規定しています。 file )、参照関係を形成します。
したがって、同じプロトコルがASL2.0であっても、異なるプロジェクトの ライセンスヘッダーは 完全に同じではないことがわかり、一部のコンテンツが追加/削除されているのは正常です(自分で「統合」しないでください) 。.
*元のライセンス:
https://www.apache.org/licenses/LICENSE-2.0.txt
2.1 コア
ASF は、名前の下のプロジェクトの ライセンス ヘッダー (ファイル ヘッダー) に著作権ステートメントを含める ことはできないと規定しており、この部分を考慮する必要があります。
寄贈前の著作権の自発的な放棄など、不要な場合は、直接削除してください。
必要に応じて、 NOTICE ファイルの先頭で別途宣言してください。
サードパーティのコードを引用している場合は、特に注意してください。相手のヘッダー とそれに含まれる著作権 ステートメントを削除/変更したり、 ASL2.0 ヘッダーを追加したりしないでください。
誰もが通常、プラグイン/スクリプトを介してフォーマットをバッチ処理するために使用されます. 現時点では、サードパーティのコードが追加の ASL2.0 宣言を追加していないことを確認する必要があります。
もう 1 つのよくある問題は、コードの一部しか参照されていないことです。
-
軽微な変更/追加 (サードパーティ コードの場合)。通常、元のファイルのライセンスを使用する必要があり、 元のライセンス/作成者のコンテンツは変更しないでください。
メジャー リビジョンについては、ASF は PMC が具体的に話し合い、対処することを推奨します (「大/小」リビジョンの厳密な定義はないため、必要がない場合はマイナー リビジョンとして扱います)。
内部構造/クラス (数十行) が大きなファイル (数千行) で参照されている場合、この時点でそのライセンス ヘッダー参照を保持するにはどうすればよいですか? (可能な限り回避する必要があります。詳しくは記事の最後）
サードパーティ コードの ヘッダー 形式/文法/句読点に問題がある場合や、不完全 (簡易版) であっても、元のLicense Headerを変更しないでください。
上記のように、ソフトウェア/コード全体に複数のオプション ライセンスが含まれている場合は、次のいずれかのオプションを検討してください。
不必要なトラブルを避けるために、Apache の最も適切なクラス A ルース ライセンスを ライセンス ヘッダーとして優先します。
元のコードのライセンス ヘッダーに複数のオプション ライセンスが記載されている場合は、変更する必要はありません (通常、元のコードの作成者が変更する権利を持っているため)。
*クラス A パーミッシブ ライセンス:
https://www.apache.org/legal/resolved.html#category-a
2.2 特殊なケース
ASFでは、一部のファイルについてはライセンスヘッダーを追加する必要がないと規定しています.その原則は「内容/構造に創造性はありません」に基づいています.確信が持てない場合は、デフォルトで追加する必要があります.必要な 例追加した：
短いテキスト情報 (典型的なREADME、CONTRIBUTING、*.txt、*.md、*.logおよびさまざまなlintファイル);
エラーを報告する可能性のあるヘッダー コメントを追加しました (典型的な json ファイル)。
.github 、 .git または同様のファイルの下にある専用のアクション ファイルなど、ソース コードをパッケージ化するときに除外できるファイル。
以下は、推奨される (ただし必須ではない) 追加のより一般的な例です。
Makefile/pom.xmlなどのパッケージ管理/依存関係構成ファイル 。ASF は、論争を避けるために、必要でない場合はそれらを追加することをお勧めします(電子メールの議論を参照してください)。
プログラムによって生成されたテンプレート/ユーザーが使用する *.conf および *.properties ファイルは、特定の状況に応じて PMC で議論することができ、不確実または単体テストで使用される構成ファイルは、デフォルトで持ち込むことが提案されています。（または相談された）;
圧縮されたcss/js などのファイルがある場合、独自のプロジェクト開発によって生成された場合は、元のヘッダー バージョンではなく、短いバージョンの宣言を使用することをお勧めします。
つまり、ASF では、明らかに使用されていない/追加が困難な場合を除いて、許可を示す ライセンス ヘッダー を追加することを推奨しています。
*ライセンス ヘッダーを追加する必要のない一部のファイル:
https://www.apache.org/legal/src-headers.html#faq-exceptions
*ライセンス ヘッダーをパッケージ管理/依存関係構成ファイルに追加するかどうかについてのメール ディスカッション:
https://lists.apache.org/thread/l6w0ytfodywfsb6ky0gd41qfzb148r50
*圧縮されたcss / jsおよび自己開発プロジェクトによって生成されたその他のファイルの短いバージョンの宣言：
https://www.apache.org/legal/src-headers.html#is-a-short-form-of-the-source-header-available
3. 注意事項
LICENSE/Header には 、独自の + サードパーティ ライセンスが保存されていることを理解するのが簡単です. NOTICE ファイルは何をし ますか? 簡単に言えば、著作権 + (法的) 必須のライセンス要件を保存できます。
NOTICE ファイルは ASF 標準仕様に準拠する必要があり、形式を自由に変更することはできません (公開されているインキュベーション プロジェクトを参照することをお勧めします。卒業プロジェクトには歴史的な理由がある場合があります。直接コピーしないでください)。
NOTICE ファイルの著作権 年は可能な限り一貫している必要があり (たとえば、複数のリポジトリがある場合)、最終年はリリースで更新する必要があります (たとえば、2017-20xx、リリースでは xx年を確認する必要があります)。
他の ASF プロジェクトを参照する場合は、こちらを参照してください ( https://infra.apache.org/licensing-howto.html#bundle-asf-product 、これは通常の Apache2.0 プロトコルを参照するプロジェクトと同等ではないことに注意してください ) ;
NOTICE はできるだけ簡潔にしてください . 不確実な参照については、コミュニティ/メンターに相談してください. ここでその必要性を想定しないでください. ユーザー (下流) に追加の負担 (推移的) がもたらされるためです.
BSD/MIT ライセンスに埋め込まれた著作権表示は、暗唱を必要としません (LEGAL-59)。
第三者が依存しているNOTICE ファイルがLICENSEまたはその他の情報を誤って引用している 場合、どのように選択すればよいですか?
一般に、間違った部分をコピーする必要はありません。必要な/コンプライアンス部分を選択するだけです (問題を参照してください: https://github.com/apache/incubator-hugegraph-computer/pull/227#discussion_r1081107569 );
よくわからない場合は、チューターに相談するか、 インキュベーター コミュニティにメールを送信してください。
*LEGAL-59：
https://issues.apache.org/jira/browse/LEGAL-59
3.1 公式 + インキュベーターの例:
公式の最小限のテンプレート (推奨)
https://www.apache.org/licenses/NOTICE-2.0.txt
シートトンネル (推奨)
https://github.com/apache/incubator-seatunnel/blob/dev/NOTICE
HTTP サーバー (非推奨)
https://www.apache.org/licenses/example-NOTICE.txt
4.免責事項
インキュベーション中のプロジェクトの配布パッケージ (Web サイトを含む) には、 DISCLAIMER (免責事項) ファイルを含める必要があります . この合法的なファイルには 2 つのオプションがあります: (詳細については、公式の説明を参照してください)
標準バージョン: ASF のすべてのリリース ポリシーに従うことができるインキュベーション プロジェクト。DISCLAIMER ファイルという名前 ( 条件が許せば優先順位を付ける必要があります)。
WIP (Work In Progress) バージョン: リリース プロセス中に ASF の要件を満たすことができないいくつかのリリース ポリシーが存在することを意味し、 DISCLAIMER-WIP と呼ばれ、「満たされていない」条件が緩い*GPL/CCなどです。 -BY など。 X クラスの互換性のないライセンスは許容されます (より特殊なケースでは、インストラクター/電子メールに相談するのが最善です)。
2 つの説明のテンプレートの内容は異なり、特に WIP バージョンでは、「既知の問題のリスト」を具体的にリストする必要があります。卒業前にインキュベーション プロジェクトを更新する必要があること 標準的なDISCLAIMER ステートメントに変換されます (つまり、 WIP バージョンでは、関連するリリースの問題が解決されていることが言及されています)。
*公式説明:
https://incubator.apache.org/policy/incubation.html#disclaimers
5. 著作権
著作権表示は、ソフトウェア グラントの一部として ASF に寄贈された場合にのみ再配置されます。
著作権に関する別の注意:
ASF プロジェクトでは、著作権を ライセンス ヘッダーの代わりにNOTICEファイルに配置する必要があります. これは ASF だけで必要であり、著作権を自由に使用および追加する他のプロジェクトとは何の関係もありません. これはApache ライセンスの本来の要件 ではありません ( ASL2.0)。誤解を避けるために、これも冒頭で述べた ASF プロジェクトと Apache プロジェクトの大きな違いの 1 つです。
6.GPL
基本的に、 *GPLライセンスで表されるコード/バイナリ参照は ASF プロジェクトに含めることはできません。つまり、配布/商用化を厳密に制限するライセンス/基本的に導入を許可されません (詳細なリストについては、公式の禁止された参照リストを参照してください)。 )
ここでインクルードできないのは、ソース コードがインクルードされないだけでなく、コンパイルによって生成されたバイナリ パッケージが理論的にインクルードできないため、同様の依存関係/プラグインを使用する一部のコードは削除/リファクタリングする必要があり、そうしないと非常にトリッキーになります。 . 以下が利用可能です: 参照用の一般的なプラクティス:
オラクルのojdbc.jar パッケージなど、ASF が許可していないこの種の参照をオプションにして、 必要なユーザーに自分でダウンロードして関連付け/有効化するように指示するドキュメントを作成できます。
プロジェクト契約で複数のライセンスが許可されている場合は、 ASL2.0 互換のライセンスが含まれていて、選択したライセンスがプロジェクトの LICENSE ファイルで指定されている限り使用できます。
また、CC（クリエイティブ・コモンズ）ライセンスに注意 ASF単体での登場は禁止（https://www.apache.org/legal/resolved.html#cc-by）（見落としやすい）プラグイン スキャンを使用することをお勧めします)。
*ASF は、サードパーティのオープン ソース ライセンス契約のソフトウェア リストを引用することを正式に禁止しています。
https://www.apache.org/legal/resolved.html#category-x
7. バイナリ/アーカイブ
バイナリ ファイル + 個別の jar パッケージ ( アーカイブ ファイルと見なされる) にも特別な注意が必要です。これにより、公開時に多くの不要なトラブルを回避できます。
バイナリ ファイルはソース コード パッケージにできるだけ表示しないでください.既存のものはダウンロードまたはコンパイル/テスト中に一時的な生成によって置き換えられると考えられる場合 (新しい PR は再導入を避ける必要があります);
比較的巨大でレビューが難しい圧縮ファイル (たとえば、 swagger-ui は Apache によってライセンスされているフロントエンド パッケージです) の場合は、それらをソース コードに直接インポートするのではなく、コンパイル時にダウンロードして解凍してください。
ほとんどの画像もバイナリファイルとみなされますが、この部分がソースコードに必要ない場合は、パッケージ化の際に除外されると見なすことができます。
必要なピクチャ/バイナリの場合は、LICENSE ファイルに別の参照記述が必要です (例は追加予定)。
8. Git/GitHub/公式サイト関連
以下は、主に誤解されやすい雑多な詳細ですが、間違いによってリリースが元に戻る可能性もあります。
リリース ブランチは個別に更新できますが、リリースVOTE メールが送信されたら、それを確定するか、その後の更新の送信を停止する必要があります (そうしないと、非準拠と見なされます)。
バージョンをリリースするときは、複数のラウンドが発生する可能性があるため、タグに rc サフィックスを使用することをお勧めし ます 。返されました (必須ではありませんが、推奨されます)。
ASF メール(https://lists.apache.org/thread/k08vq5r4nfos2ptn69w2fbm2mvmkb91n)に記載されているように、ブランチ (ブランチ) は必要ないため、再利用のために release-1.0.0 を保持します。
簡単に確認できるように、投稿メールにタグの最新の Commit-ID (省略形)を含めることができます。
リリースが完了する前に、公式 Web サイトのダウンロード ページに一時的なダウンロード アドレスを掲載することはできません (同様に、Github のリリース ページでは、最新リリースではなくプレリリースを使用する必要があります。
公式 Web サイトのダウンロード ページまたはプロジェクトのREADME に、基本的な「整合性チェック」+「ソース コードのコンパイル方法」のドキュメントを用意しておくことをお勧めします(必須ではありませんが、推奨されます)。
8.1 自動チェック (強く推奨)
手動/手動操作の過失によって引き起こされる多数の不必要な小さな問題や隠れた危険を回避するために、自動化された CI /アクションを 追加して、検査を支援することを強くお勧めします。
maven RATチェック バイナリ/ヘッダー/アーカイブ (maven プラグイン、Java のみ - 必須);
skywalking-license-header チェック (PR でコメント リマインダーを提供することもできます。すばらしい - 必要です);
skywalking-dependencies の生成とチェック (少なくともチェック部分を有効にすることをお勧めします。ドキュメントは上記と同じです - オプション);
リリース パッケージを検証する (HugeGraph によって記述された自動検証 アクションを参照し、GPG/SHA/バイナリ ファイル/空のファイル(フォルダー) を事前に確認するなど - 推奨);
dependency-review-action (GitHub は、ライセンスをチェック/除外できる Action を公式に提供しています - オプション)。
次に、主な手動検査は、スクリプトではカバーできないいくつかの場所に焦点を当て、「LICENSE + NOTICE + サードパーティ依存のヘッダー宣言」などの問題に焦点を当て、多くの労力を削減できます。
*skywalking-license-header チェック：
https://github.com/apache/skywalking-eyes
*HugeGraph によって記述された自動検証アクション:
https://github.com/apache/incubator-hugegraph-doc/blob/master/.github/workflows/validate-release.yml
*依存性レビューアクション：
https://github.com/actions/dependency-review-action
9. トラブルシューティング
ここでは、ASF の職員が直接説明しない/明確な定義を欠いているが、実際に遭遇する可能性があるいくつかの厄介な問題/提案を示します. 参照用の結論がいくつかあります .
サードパーティ コード (ソース コード) を引用した後、ソースとバイナリ リリースの異なる LICENSE ファイルに同時に引用を追加する必要がありますか?
A: はい、両方とも必要です (問題を参照してください)。
ライセンス ヘッダー に関するいくつかのポイント:
(原則) サードパーティのコードを断片的に使用することは推奨されません. 分離または自分で書き直すことを優先する必要があります. 引用する必要がある場合は、元のコードのライセンスヘッダーを保持する必要があります .
(原則) サードパーティ コードをあるプログラミング言語から別のプログラミング言語に変換することは大きな変更ではなく、元の ライセンス ヘッダーを保持する必要があります (一部のアルゴリズム関連のコードでは一般的です)。
(特殊なケース) インポートされたサードパーティ コードがコード ファイルのほんの一部である場合、そのライセンス ヘッダーをファイル全体のヘッダーとして使用する必要がありますか?
-
インターフェイス定義/サブクラス/構造をインポートする場合、コード フラグメントのこの部分でそのライセンス ヘッダーを直接インポートできますか。
コードの途中でライセンス ヘッダーを導入できない場合、ヘッダーに 2 つのライセンス ヘッダーを保持できますか (1 つは ASF で、もう 1 つはインポートされます)。
ライセンス ヘッダーが1 つだけ予約されている場合、インポートするコード行の範囲をLICENSEファイルで指定する必要がありますか? インポートしないと、他の人はコードのどの部分が参照されているか分からないようです。
A: 上記の状況は、可能な限りヘッダーファイル/独立したクラスを通じて個別に導入する必要があります.少量のコード/関数を参照する必要がある場合は、書き換えを優先することをお勧めします.上記の問題に該当します）。
上にスワイプして、この記事の参考文献を表示します
https://incubator.apache.org/guides/releasemanagement.html (Incubator プロジェクトのリリースガイド①)
https://www.apache.org/foundation/preFAQ.html (ASL2.0 プロトコルの使用に関するよくある質問)
https://www.apache.org/legal/src-headers.html (サードパーティの参照を含む、一般的なライセンス ヘッダー参照の問題)
https://infra.apache.org/licensing-howto.html (LICENSE/NOTICE ファイルの書き方)
https://www.apache.org/legal/resolved.html#category-x (CC-BY を含む禁止された参照の公式リスト)
https://lists.apache.org/[email protected] (ASF インキュベーター メーリング リスト)
…
丨ALC北京より転載
Author丨imbajin
編集丨羅瑞岩
関連資料 | 関連資料
開元社諮問委員会の2023年第1四半期の会議が成功裏に開催されました！
ChatGPT のようなオープン ソース ソフトウェア、開発者はそれを使用できますか?
開元社の紹介
2014年に設立されたKaiyuan Societyは、オープンソースの大義に自発的に貢献する個々のメンバーで構成され、「貢献、合意、および共同統治」の原則に従って形成され、常にベンダー中立の特性を維持してきました。公益、非営利。国際統合、コミュニティ開発、プロジェクト インキュベーション」を使命とするオープン ソース コミュニティ フェデレーションです。開元社は、オープンソースをサポートするコミュニティ、企業、政府関連部門と積極的に緊密に協力し、「中国に拠点を置き、世界に貢献する」というビジョンのもと、健全で持続可能なオープンソース エコシステムを構築し、中国のオープンソース コミュニティを促進することを目指しています。グローバルなオープンソース システムで積極的な力になること。参加と貢献者。
2017 年、開元社は、ASF などのトップの国際的オープン ソース財団のガバナンス モデルを参照して運営される、完全に個々のメンバーで構成される組織に変わりました。過去 9 年間で、何万人ものオープンソースの人々を結び付け、何千人ものコミュニティ メンバーとボランティアを集め、国内外で何百人もの講師を集め、何百ものスポンサー、メディア、コミュニティ パートナーと協力してきました。
