オープンソースプロジェクトをキャプチャ/保護する方法

Ars Technicaには、 GoogleがAndroidを徐々に閉鎖しているという興味深い記事があります。 これは、オープンソースコミュニティと対戦する古典的なCapture the Flagゲームです。 このキャプチャがどのように機能し、それを防ぐ方法を説明します。

フラグをキャプチャする理由

Ars Technicaは次のように述べています。「最初にAndroidで行ったように、市場シェアがゼロの最後の場所にいるときに何かを簡単に配ることができます。 最初に来たとき、とてもオープンでフレンドリーになるのは少し難しくなります。」

正直なところ、AndroidはおそらくGoogleにとって最大の投資でしょう。 開いているシステムを閉じたシステムに変える権利があるかどうかについて議論することができます。 ただし、これは、中央銀行が多すぎる紙幣を印刷して切り下げを作成する権利を持っているかどうかについて議論するのと同じです。 もちろん、彼にはそうする権限があります。 しかし、同時に、他の人が支払う価格があります。 問題は合法性ではなく、社会が支払う価格の受容性です。 そして、それが受け入れられない場合、どのようにこれを防ぐことができますか？

Androidは、これに基づいて市場に販売される他のオープンソースシステムと同様、公有財産です。 誰かがそれを民営化すると、中央銀行がお金を印刷するように、残りを犠牲にして利益を増やします。 検索、カレンダー、音楽などのAndroidアプリケーションをフォークし、それらの改良版を作成することにより、GoogleはデバイスでAndroidを使用する他の企業と競合します。

キャプチャの問題、これがどのように起こり、それを防ぐ方法は、あなたがGoogleでない場合、つまり重要です。 あなたがオープンソースプロジェクトのユーザーまたは参加者である場合。 Androidには、LG、Samsungなど、他社のパッチが多数あります。 Googleがオペレーティングシステムを個人の庭に変えると、これらのパッチは、それを作った人々に対して使用され始めます。

Googleがこの方法でゲームのルールを変更することにより、Androidのライバルを容認するという理由だけで大きな間違いを犯していると確信しています。 しかし、私はそれについて話していません。 私は自分の仕事やプロジェクトに役立つレッスンを学ぶことに興味があります。

次の2つのことに注意してください。

• まったくの興味から、私は参加者である私のオープンソースプロジェクトには参加しません。私のパッチや変更は他の誰かのものではなく、私に対して使用されないことを保証します。
• 倫理的な理由から、そのような保証をメンバーに提供しないオープンソースプロジェクトを作成することはありません。

ユースケース

ユースケースについて明確に表現しようとします。 私たちはAndroidについて話します。ある会社がオープンソースプロジェクトを開始し、それを「餌製品」として使用し、市場に浸透することを意図し、他からのサポートを求めています。 これは非常に成功できる古典的な戦略です。 ただし、これは学生の研究プロジェクトや「オープンソースの給与システムを作ろう」や「ガレージに集まって新しいフレームワークを作成することを決めた5人」などのゴミとはまったく異なります。

ここには部分的な偶然の一致があり、調査結果はより広く適用できると思います（そして間違いなく体系的に適用します）、再び、私のユースケースは「市場に侵入するオープンソース」です。

オープンソースプロジェクトを使用して市場に参入する成功は、それを行うコミュニティに依存することを知っておくことが重要です。 市場は、市場を支配する影響力のある複数のプレーヤーの行動に依存しており、他のほとんどのプレーヤーの努力は重要ではありません。 ボトムラインは、この方法で観客に無力から脱することを約束し、ゲームのルールを変更する可能性のある新しいオープンなものに投資するように説得することです。

ほとんどのオープンソースプロジェクトは失敗します（真剣に、GitHubでランダムなプロジェクトについて読んで、どれだけのプロジェクトが適切かを確認してください）。 権力に大きな変化が生じるまで、プロジェクトは非常に長い間、市場での潜在的な突破口であり続ける可能性があります。 彼は非常に安定して幸せそうに見えるかもしれません。 まあ、お金がかかっていないときは友好的になりやすいです。

プロジェクトが成功すると、ゲームのルールが変わり、画期的なプロジェクトを立ち上げた賢い人たちは、熟した果物を選んで自分でそれを拾おうとします。 そして、それだけが面白くなります。

競技条件が等しいフィールドは「禁止」の対象ではありません

商標や特許など、オープンソースプロジェクトを取り込む方法はいくつかあります。 これは最も一般的なケースであるため、著作権のみを考慮します。 オープンソースプロジェクトの著作権を管理する主要な契約は、a）ライセンスおよびb）参加ポリシーです。

よくある誤解は、オープンソースプロジェクトをハイジャックできないということです。 これは完全に間違っています。 大まかに言うと、3種類の著作権契約があります。

1. 「クローズド」ライセンス。素材の再処理、古典的な著作権、およびいくつかの制限付きライセンスを許可しません。
2. Apache / BSD / MITなどの材料の片側処理を許可する「無料で利用できる」ライセンス。
3. share-alikeライセンス。GPL、LGPL、cc-by-saなどの素材の双方向処理が可能です。

人気の無料テイクビートをリリースするDJを想像してください。 大手音楽レーベルがビートをリミックスしてリリースします。 彼はヒットになります。 そして今、この新しいバージョンは閉じられています。 DJはこの新しい作品をリミックスできず、おそらくリミックスを再生することさえできません。 もちろん、彼は古いバージョンを使用して改善することはできますが、商用バージョンにはお金がかかります。

私が何をしているのか理解してほしい。 優秀な個人の才能でさえ、その大規模な企業とマーケティングおよび財務リソースで平等に競争することはできません。 開発管理のための戦争で平等な競争条件を保証する唯一の方法は、二国間材料加工協定です。 両側とは両側を意味します。

人々がこれを制限を保証と呼ぶとき、これはただため息をついているだけです。 それは私の車のロックを「制限」と呼ぶようなものです。これは、残りの車が自分の車を占有するのを止めるからです。 泥棒の保護を「制限」と呼ぶのは…。 まあ、少なくとも分析できない。 ルールが両側で機能する場合、これは制限ではありません、OK ?!

キャプチャはどのように行われますか？

もう一度目標を決めましょう。 プロジェクトの開発または作成を支援したコミュニティを犠牲にして、個人的な利益のためにプロジェクトを収穫することを目的とした、多くのお金と権力を持つ誰かによるオープンソースプロジェクトのキャプチャを防ぐ必要があります。 この発作がどの程度「正当」であるかは気にしません。それを防ぐ方法を説明するだけです。
ライセンスと参加ポリシーは、同じパズルの2つの半分です。

著作権の所有者は誰ですか？ 彼らはプロジェクトの創設者の間で「集中している」のですか、それともすべての参加者の間で分けられているのですか？ これは重大な問題です。 それらが集中している場合、これは著作権を購入し、プロジェクトを分岐し、ライセンスを一方的に変更するという些細な作業です-そして、あなたは閉じた方向に進むことができます。 ただし、権利が分配されている場合、つまり 多くの人々が作品を所有し、共同で所有しているため、ライセンスを変更するには、すべて（大多数ではなく、100％全会一致）の承認が必要です。 そして、これはロジスティック的に不可能です。

ちなみに、ZeroMQの商用ライセンスに対して私にお金を提供している人の数を知っているだけであれば、驚くでしょう（多くの場合）。 申し出は簡単です：私は彼らに非LGPLライセンスを販売し、彼らは私に良いお金を支払い、ZeroMQのバージョンを作ります。 私がずっと前にこのオプションの不可能性を特に気にかけていなかったら、私は非常に金持ちだったでしょう。 そして今、私はZeroMQが私を生き残るために貧困に耐えるのに役立ちます。

商用コラボレーションライセンスを再度提供する問題を見ていきましょう。 DJを招待し、ビートをミックスするクラブを想像してください。 その後、クラブは著作権を確保し、レコード会社に販売します。レコード会社は、オリジナルのDJが無料で再生できないリミックスのアルバムを独自に作成します。 そのため、デュアルGPL /商用ライセンスを悪い慣行と考えています。

「無料」プロジェクトの商用ライセンスに対しては、誰もコードを取得して使用できないため、誰も支払いません。 ある意味では、これはすでに間違っていると思います。 誰にとってもゲームのルールの平等に違反します。 大企業が小さなチームよりもこの恩恵を受けることは明らかです。 繰り返しになりますが、独立したDJがすべてのマーケティングおよびメディア接続とコンサート収入でレコードレーベルに対抗することを想像してください。

次に、開発者を雇うというステップ2のキャプチャに進みましょう。

「しかし、コードはまだ無料です！」と人々は言います。 もちろん。 ラベルvs djに戻る。 レーベルが主要な従業員であるDJを1人だけ雇って、それを使ってアルバムのコマーシャルミックスを進めるようにします。 それでは、一般の人々はどこへ行くのでしょうか？

コミュニティ内のすべてのメンバーを雇ってキャプチャする必要はありません。 ランダムに選ばれたプロジェクトでは、2〜3人のトップ参加者と若い参加者が大量にあります。 トップを2つ雇うと、どこからでもプロジェクトをピックアップできます。 結果を再処理できる（リミックス可能）場合、この旅は、以前にプロジェクトに参加した人との関係で完全に公平になります。 そして、リミックスできない場合、他のすべての参加者は、彼らの投資が彼らに対して使われていることに気付くでしょう。

キャプチャの防止

私は、オープンソースソフトウェアプロジェクトのキャプチャを防ぐモデルを1つだけ知っています。

1. GPLファミリライセンス（または同様の方法で機能するMPLv2）。
2. 分散著作権。

これは私が最初からオープンソースプロジェクトを構築する方法であり、これは私が参加するコミュニティの要件です。 お金を稼ぐ権利には、相互に利益がない限り、私の仕事を競争上の優位性として使用する権利は含まれません。

継続するには...

---

著者について

「残念ながら、私たちは自分自身のために死を選ぶことはしませんが、男性として記憶されるために尊厳をもって死に会うことができます。」
-映画「グラディエーター」



ピーター・ヒンチェンス（ピーター・ヒンチェンス）-ベルギーの開発者、作家。 彼は、 ZeroMQライブラリ（ライブラリがデータのバッファリング、キューイング、接続の確立と回復などを処理します）、OpenAMQ、 Libero 、 GSLコードジェネレーターなどのフリーソフトウェアを生産するiMatixの CEOおよびチーフソフトウェアデザイナーを務めました。およびXitami Webサービス。

• 30以上のプロトコルと分散システムの作成者。
• 完全に安全な匿名のグローバルP2Pネットワークを作成するEdgenetプロジェクトの創設者。
• 特許法と闘った無料情報基盤財団（FFII）協会の会長 。
• ウィキドット独自のウィキプロジェクトの CEO。
• 彼は、 オープンスタンダードの活動家であり、 Digital Standards Organizationの創設者でした。
• 2007年のピーターは、「知的財産」の分野で最も影響力のある50人の一人に選ばれました。

詳細はこちら： 35年間、ネクロマンサーとして、コードを使用して死んだ鉄に命を吹き込みました

最後の記事の時間です。 もっと書くことができますが、時間はありますが、それから他のことについて考えます。ベッドに入るのがいかに便利か、鎮痛剤をいつ飲むか、そして隣の人々について。

...最後のモデルである、最後のプロトコルを作成します。これは、いくつかの知識と時間を残して、亡くなる方法に専念しています。 今回はRFCをフォーマットしません。 :)
ライフプロトコル

Peter HinchensのWebサイト
ウィキペディアの記事

プロジェクトについて

私は、 Filtech-acceleratorの支援を得て、Habréで（そしておそらくは紙で）本「Social Architecture」の翻訳を公開する予定です。 私見、これは、 製品の作成に焦点を当てたコミュニティの管理/構築/改善のための（適切なだけではないにしても）最高の手当です （リーダー、スポーツクラブなどの相互グルーミングや「崇拝」のためではありません）。

HabréのPeter Hinchensの考えとアイデア：

• ライフプロトコル
• 楽観的マージ：最初に人、次にコード。 適切なコミュニティを構築し、必要なコードを作成します
• ソーシャルアーキテクチャ：オープンソースプロジェクトの成功のための戦略
• コミュニティを構築する方法。 本「ソーシャルアーキテクチャ」の翻訳：第1章ツールキット

行動を促す

そもそも公共財を目的とし、補助機能として利益を上げることを目的とした技術の高いシェアを持つプロジェクト/スタートアップを念頭に置いている場合（たとえば、Wikipediaのような）、個人的なメッセージを書くか、アクセラレータプログラムに登録します。

製品の作成に焦点を当てたコミュニティの管理/構築/改善に関するCourseraの記事、ビデオ、コースへのリンクを送信すると、チョコレートバーがあります。