0

自分用に残しておきたいクローズド ソース コード (私が作成したもの) がいくつかあります。しかし、私はそのコードの一部をオープン ソース プロジェクトで使用したいと考えています。これも私だけが作成し、誰でも使用できるようにどこかに投稿します。

どうすればこのようなことを達成できますか:

  1. オープン ソース バージョンのコードをリリースします。これは誰でも自由に変更でき、保持または返却できます (これは zlib ライセンスだと思います)。
  2. 同時に、自分用のコードのバージョンを用意して、#1 からのコードの変更を組み込むことができるようにしたいと考えています (誰かが私がリリースしたコードを修正することを決定した場合)。

これは、2 つのコード ツリーがあり、両方に異なるライセンスが関連付けられているという単純なものですか? 1 つの zlib ライセンスと 1 つの自分のライセンス?

注意してください、私は短いので zlib ライセンスを使用することに少し偏っています。私はそれを理解し、適切であることに同意します (誰かが商用目的でコードを使用してもかまいません)。

4

2 に答える 2

2

最初の部分では、実際に 2 つのコード ツリーが必要です。git、mercurial、bazaar などの分散 SCM を使用している場合は、それほど複雑ではありません。

  1. 1 つのレポは公開されており、オープン ソースです。open-foobar
  2. 1 つのレポは非公開のクローズド ソースです。enterprise-foobar
  3. 私の意見では、プライベート リポジトリがフォークして拡張するメインリポジトリ (アップストリーム)としてオープン リポジトリを使用する方がよいと思いますが、それはプライベートに保持したいコードの量によって異なります。コミットのほとんどがプライベート プロジェクトに送られる場合、それをメイン リポジトリにすることは理にかなっていますが、これは適切に管理するのが難しくなります。
  4. ローカル クローンは、両方のリポジトリをリモートとして追加する必要があります。また、2 つのリポジトリのいずれかで個別のローカル ブランチを追跡する必要があります (たとえば、master-opentrack open-foobar/master、 while master-enterprisetrackなど)。enterprise-foobar/master
  5. ブランチで新しいオープンなものをコミットしmaster-open、それをオープン リポジトリにプッシュします
  6. にマージmaster-openしmaster-enterpriseます。つまり、オープン リポジトリからのすべてのコミットをプライベート リポジトリに含めます。
  7. ブランチで新しいプライベートなものをコミットし、それをオープン リポジトリにプッシュして、誤ってこれらのコミットをブランチmaster-enterpriseにマージしないようにします。master-open
  8. プライベート コミットをオープン バージョンに含めたい場合はgit cherry-pick <commit-id>、プライベート フォークからのものであるという事実を公開せずにコミットをコピーするだけで済みます。

このワークフローは git を中心にしていますが、他の SCM システムにも簡単に適用できます。

2 番目の部分については、既定では、作成されたコードのすべての著作権を明示的に付与する契約に基づいて支払われていない人からのパッチは、コードの元の作成者に著作権を保持します。これは、コードのライセンスが付与されない限り、プライベート フォークに含めることができないことを意味します。通常、プロジェクトのライセンスまたはパッチの送信プロセスで何らかの形で言及されていない限り (送信ボタンをクリックしてライセンスを付与する...）。パッチが提出されたことを明示的に言及しているので、Apacheライセンスはここで良いですプロジェクトに自動的にライセンスされ、コードに含めることができます。私は zlib ライセンスを読んでいないので、同様の条項があるかどうかはわかりません。プロジェクトのライセンスに基づいて、オープン ソース プロジェクトにパッチの提出を含める権利をユーザーに付与することに同意するようユーザーに要求するテキストを含めることが確実でない場合。

提出されたパッチをプライベート プロジェクトにも含めたい場合は、そのコードのプライベートな派生物に含めるために、コードの著作権ライセンスを要求する必要があります。詳細といくつかの例については、ウィキペディアの CLA に関する記事を参照してください。いくつかの「標準」CLA については、Project Harmony を参照してください。

于 2013-01-03T04:29:10.153 に答える