light-software-copyright

ソフトウェア著作権の申請資料

実際のプロジェクトをもとに、中国のソフトウェア著作権登録に提出する監査可能な資料のドラフトを作成します。 中心となる作業は「見栄えのよい文書を書くこと」ではありません。ソフトウェア名、バージョン、ソースコード資料、マニュアル、スクリーンショット、申請者の記入項目、ユーザーの確認事項に十分な一貫性を持たせ、ユーザーまたは専門サービス提供者がレビューできるようにすることです。

現行ルールや資料形式に関する作業を始める前に、 references/software-copyright-resource-map.md を読んでください。 ソースコードの選定、事業内容の理解、権利の根拠、サードパーティーコード、正式な出力に関する作業を始める前に、 references/materials-workflow.md を読んでください。

譲れない境界

1. このスキルは法的助言ではなく、申請を提出したり、資料が審査に通ると断言したりすることはありません。ローカルのドラフトとレビュー用の証拠のみを作成します。
2. コード資料は実際のプロジェクトのソースファイルから取得する必要があります。提出用のソースコードを捏造、書き換え、水増し、AI 生成してはなりません。
3. シークレットを漏えいさせないでください。ソースコード資料を書き出す前に、シークレット／プライバシースキャンを実行するか、実行を依頼してください。シークレットが見つかった場合は、マスキング方針が決まるまで作業を中断します。
4. 公式ルールに関する不確実性をそのまま保ってください。中国版権保護センターの現行の手続き、フォーム、料金、ページ形式、例外ルールを当日に確認できていない場合は、UNKNOWN または PLANNED と記載してください。
5. すべての正式資料のバージョンとソフトウェア名を申請用ワークシートと一致させてください。
6. このスキルをリサーチ DAG に含めないでください。light.findings.v1 は出力せず、ステージもチェックポイントゲートも再ルーティングもありません。

ワークフロー

1. 受付と範囲の確認

以下を記録するか、UNKNOWN と明記してください。

• 管轄区域：既定値は CN です。米国／EU の作業に CN のルールを黙って流用しないでください。
• ソフトウェアの正式名称、略称（ある場合）、バージョン、権利者／申請者、開発者、完成日、公開状況、開発形態。
• プロジェクトが独立開発、委託、共同開発、継承、派生、またはライセンスされたサードパーティーコードに基づくものかどうか。
• 出力言語、ドラフトを保存するローカルフォルダー、スクリーンショットが必要かどうか。

正式な文書を生成する前に、必ずユーザーの確認を得てください。

2. 実際のソーススナップショットと提出計画を確定する

ユーザーが対象として指定したプロジェクトのソースファイルを一覧にします。相対パス、SHA-256、選定理由を記録してください。以下は除外します。

• 生成されたビルド成果物、圧縮されたバンドル、ベンダー依存関係、ロックファイル。ただし、ユーザーがそれらを提出対象のソフトウェア表現であると明示した場合を除きます。
• シークレット、トークン、キー、認証情報、個人データ、および無関係なサードパーティーコード。
• 資料を長く見せることだけを目的に選んだ任意の中間部分。

プロジェクトの規模が小さすぎる場合は、水増しせず、実際のソースをすべて提出してください。

抽出前に、軽量プランナーを実行します。

python scripts/source_deposit_plan.py --root <project-root> --out 软件著作权申请资料/草稿/source-deposit-plan.json --software-name "<软件全称>" --version "<版本号>"
python scripts/source_deposit_plan.py --selftest

計画を使って、候補ファイル、ページ形式、選択したファイル数、シークレットスキャンの状況、計画の SHA を確認します。シークレットらしき内容が見つかった場合は、コード資料を書き出す前に作業を中断し、マスキングを行ってください。

3. 申請項目と事業内容の理解を確認する

ユーザーが確認するためのワークシートを生成します。

• ソフトウェア名とバージョン。
• 権利者／申請者と開発者の情報。
• 開発環境と実行環境。
• 主な機能、技術的特徴、利用シナリオ。
• ソースプログラムと文書資料の数量。
• 公開状況と日付。

マニュアルでは、レビュー担当者やユーザーがソフトウェアをどのように操作するかを説明する必要があります。画面、コマンド、ワークフローと結び付かない一般的な機能一覧にしてはなりません。正式に書き出す前に、権利の根拠と、サードパーティーコード／オープンソース／生成コードの確認結果を記録してください。プロジェクトが委託、共同開発、継承、派生、またはライセンス上の制約を受ける可能性がある場合、独立した権利保有を前提にしてはなりません。

4. コードとドキュメントの資料を準備する

中国国内の一般的な資料のルールに従い、公式の冒頭・末尾ルールを適用します。

• ソースプログラムとドキュメント資料は、資料全体が60ページ以上の場合、それぞれ冒頭と末尾から連続する30ページを使用します。
• 資料全体が60ページ未満の場合は、ソースまたはドキュメントの全ページを含めます。
• 公式に認められた例外が文書で確認できる場合を除き、ソースの全ページは通常、1ページあたり50行以上、ドキュメントの全ページは1ページあたり30行以上必要です。

抽出マニフェストとページ数を保持してください。例外的な提出が求められた場合は、その旨を明示し、現行の公式ルールをユーザーに確認するよう求めてください。

5. ローカルでドラフトを作成し、確認後に正式資料を作成する

软件著作权申请资料/ のようなローカルフォルダーを使用します。

• 草稿/：申請ワークシート、マニュアルのドラフト、コード選定メモ。
• 正式资料/：確認後にのみ作成する、最終版のDOCX/TXT/PDF形式のファイル。
• マニフェスト／レポートのJSON：ファイルパス、SHA-256、ソースのスナップショット、確認の根拠、ルールの適用状況。

スクリーンショットの使用は任意です。使用しない場合は、その理由を記録してください。使用する場合は、実際に動作しているUIまたはユーザーから提供された画像に各スクリーンショットを対応付け、ハッシュを記録します。

6. 「レビュー可能」と伝える前に機械的なゲートを実行する

templates/software-copyright-materials.example.json に従ってパケットを作成し、次を実行します。

python scripts/source_deposit_plan.py --selftest
python scripts/materials_gate.py --packet software-copyright-materials.json --base <project-root> --as-of 2026-07-05
python scripts/materials_gate.py --selftest

パッケージをユーザー／専門家のレビュー用として準備完了と判断する前に、ゲートに合格する必要があります。ゲートに失敗した場合は、ソースの計画、ソースとの対応付け、権利の根拠、第三者レビュー、確認、ページ規則、バージョンの整合性、秘密情報の取り扱い、または出力ハッシュを修正します。

実行する／確認する／決してしない

実行する：

• 実際のソースファイルを使用し、SHA-256を記録します。
• 申請項目、事業の背景、コードの選定、ドラフト、最終出力について、ユーザーに確認を求めます。
• ソースコードとドキュメントのページ数を明記します。
• すべての資料でソフトウェア名とバージョンを一致させます。
• ソースコード資料をエクスポートする前に、秘密情報や個人データをスキャンします。
• 権利の根拠と、第三者／オープンソース／生成コードの除外事項を記録します。

確認する：

• 権利者／申請者と開発形態に関する事実。
• 第三者からの委託、受託、継承、派生コードが含まれているかどうか。
• スクリーンショットを含めるかどうか。
• 例外的な提出や墨消しが必要かどうか。
• ソフトウェアが独自開発、委託開発、共同開発、継承、派生のいずれに該当するか、または第三者／生成コードを含むかどうか。
• ドラフトの段階で止めるか、正式なローカルファイルを作成するか。

決してしない：

• ユーザーに代わって資料を提出したり、登録システムを操作したりしません。
• 承認、証明書の発行時期、または「包过」を約束しません。
• ソースコードを捏造したり、行数を水増ししたり、恣意的に断片を選定したりしません。
• 認証情報、個人データ、無関係な第三者のコードを漏えいしません。
• サードパーティレビューの注記を付けずに、ベンダー提供コード、生成コード、またはライセンス上の制約があるコードを黙って含めません。
• このスキルをLightの調査DAGに振り分けません。