GitHubのJavaコードで発生する可能性のある借用およびライセンス違反の調査

私の名前は私が仕事で、ヤロスラフGolubevあるJetBrainsの研究実験室で、ソフトウェア工学における機械学習方法の。私の同僚の何人かはすでに彼らのプロジェクトについてここに書いています（例えば、オンラインコースのヒント）。私たちのグループの全体的な目標は、人々が何をどのようにプログラムするかに関するデータを使用することにより、プログラマーの作業をより簡単に、より便利に、より効率的にすることです。ただし、ソフトウェア製品を作成するプロセスは、コードの記述だけでなく、ドキュメント、コメント、作業中のディスカッションなどもあります。これらすべての人々が支援することができ、支援する必要があります。



ソフトウェア開発のこれらの側面の1つは、コードライセンスです。一部の開発者にとって、ライセンスはやや暗い森のように見えます。彼らはそれに侵入しようとせず、一般的な違いやライセンスルールを理解していないか、表面的にそれらを知っているため、さまざまな種類の違反を犯す可能性があります。最も一般的なそのような違反は、その作成者の権利に違反してコードをコピー（再利用）および変更することです。



人々への支援は、現在の状況を調査することから始まります。まず、さらなる自動化の可能性のためにデータ収集が必要です。次に、彼らの分析により、人々が間違っていることを正確に見つけることができます。この記事では、まさにそのような研究について説明します：ソフトウェアライセンスの主なタイプ（およびいくつかのまれですが注目に値するもの）を紹介し、コード分析と大量のデータの借用の検索について説明し、コード内のライセンスを適切に処理する方法についてアドバイスします。よくある間違いを避けてください。

コードライセンスの概要

インターネット上、そしてハブレ上でも、ライセンスの詳細な説明がすでにあるので、研究の本質を理解するために必要なトピックの簡単な概要だけに限定します。オープンソースソフトウェアの



ライセンスについてのみ説明します。第一に、これは、利用可能なデータを簡単に見つけることができるのはこのパラダイムであるという事実によるものです。第二に、まさに「オープンソースソフトウェア」という用語です。誤解を招く可能性があります。会社のウェブサイトから通常の独自プログラムをダウンロードしてインストールする場合、ライセンスの条件に同意するよう求められます。もちろん、あなたは通常それらを読みませんが、一般的にあなたはこれが誰かの知的財産であることを理解しています。同時に、開発者がGitHubでプロジェクトに参加し、すべてのソースファイルを表示する場合、それらに対する態度は完全に異なります。はい、そこにはある種のライセンスがありますが、それはオープンソースであり、ソフトウェアはオープンソースです。あなたがやりたいことをしますよね？残念ながら、すべてがそれほど単純なわけではありません。



ライセンスはどのように機能しますか？最も一般的な権利の分割から始めましょう：







右から左に進むと、最初は商用シークレットになり、次に独自のライセンスが続きます。これらは考慮されません。オープンソースソフトウェアの分野では、3つのカテゴリを区別できます（自由度の増加の程度に応じて）：制限付きライセンス（copyleft）、非制限付きライセンス（許可、許可）、およびパブリックドメイン。（これはライセンスではありませんが、権利を付与する方法です）。それらの違いを理解するには、なぜそれらがまったく現れたのかを知ることが役立ちます。パブリックドメインの概念は世界と同じくらい古いものです。作成者はすべての権利を完全に放棄し、自分の製品でやりたいことを何でもできるようにします。しかし、奇妙なことに、この自由から不自由が生まれます-結局のところ、別の人がそのような創造物を取り、それをわずかに変更し、それを閉じて販売することを含めて「何でも」行うことができます。オープンソースのcopyleftライセンスは、自由を保護するために正確に作成されました。写真の位置から、バランスを維持することを目的としていることがわかります。製品の使用、変更、配布を許可しますが、ロックせず、無料のままにします。また、ライターがクローズアンドセルのシナリオを気にしない場合でも、パブリックドメインの概念は国ごとに異なるため、法的な問題を引き起こす可能性があります。それらを回避するために、単純な許可ライセンスが使用されます。



では、許可ライセンスとコピーレフトライセンスの違いは何ですか？私たちのトピックの他のすべてのように、この質問は非常に具体的であり、例外がありますが、単純化すると、許容ライセンスは変更された製品のライセンスに制限を課しません。つまり、そのような製品を取得して変更し、別のライセンス（独自のライセンスであっても）の下でプロジェクトに入れることができます。ここでのパブリックドメインとの主な違いは、ほとんどの場合、作成者と元の作成者の言及を保持する義務です。最も有名な許容ライセンスは、MIT、BSD、およびApacheライセンスです。..。多くの研究では、MITが一般的に最も一般的なオープンソースライセンスであると指摘されており、2004年の開始以来Apache-2.0ライセンスの人気が大幅に高まっていることも指摘されています（たとえば、Javaの研究）。



Copyleftライセンスは、ほとんどの場合、副産物の配布と変更に制限を課します。特定の権限を持つ製品を取得し、すべてのユーザーに同じ権限を与えるために「さらに実行」する必要があります。これは通常、同じライセンスの下でソフトウェアを再配布し、ソースコードへのアクセスを提供する義務を意味します。この哲学に基づいて、Richard Stallmanは、最初で最も人気のあるコピーレフトライセンスであるGNU General Public License（GPL）を作成しました。）。将来のユーザーと開発者に最大限の自由の保護を提供するのは彼女です。リチャード・ストールマンのフリーソフトウェア運動の歴史を読むことをお勧めします。それは非常に興味深いものです。



コピーレフトライセンスには1つの問題があります。これは、従来、強力なコピーレフトと弱いコピーレフトに分けられます。強いコピーレフトはまさに上記のとおりですが、弱いコピーレフトは開発者にさまざまな譲歩と例外を提供します。このようなライセンスの最も有名な例は、GNU Lesser General Public License（LGPL）です。：以前のバージョンと同様に、このライセンスを保持している場合にのみコードを変更および再配布できますが、動的にリンクする場合（アプリケーションのライブラリとして使用する場合）、この要件は省略できます。つまり、ここからソースコードを借用したり、何かを変更したりする場合は、copyleftを確認してください。ただし、動的リンクライブラリとして使用する場合は、どこでも実行できます。



ライセンス自体を理解したので、それらの互換性について説明する必要があります。これは、防止したい違反が存在するためです（というより、ライセンスが存在しないため）。このトピックに興味を持ったことのある人は、次のようなライセンス互換性スキームに出くわしたはずです。







ライセンスを理解したいという願望は、そのようなスキームで一目で消えることがあります。確かに、多くのオープンソースライセンスがあります。たとえば、ここにかなり網羅的なリストがあります。同時に、以下の調査結果に示されているように、非常に限られた量（分布が非常に不均一であるため）を知る必要があり、すべての条件に準拠するために覚えておく必要のあるルールはさらに少なくなります。このスキームの一般的なベクトルは非常に単純です。すべてのソースはパブリックドメインであり、その背後には許容ライセンス、次に弱いコピーレフト、最後に強いコピーレフト、そしてライセンスは「右」で互換性があります。コピーレフトプロジェクトでは、許容ライセンスの下でコードを再利用できますが、その逆はできません。 -すべてが論理的です。



ここで疑問が生じる可能性があります：コードにライセンスがない場合はどうなりますか？それでは、どのようなルールに従うべきですか？このコードをコピーできますか？これは実際には非常に重要な質問です。おそらく、コードがフェンスに書かれている場合、それはパブリックドメインと見なすことができ、砂漠の島に釘付けされた（著作権なしで）ボトルに入った紙に書かれている場合、それは簡単に取得して使用できます。GitHubやStackOverflowのような大規模で確立されたプラットフォームの場合、それらを使用するだけで自動的に利用規約に同意するため、物事はそれほど単純ではありません。今のところ、それについてのメモを頭に残して後で戻ってきましょう-結局、これはまれであり、ライセンスのないコードは事実上ありませんか？

問題の説明と方法論

それで、すべての用語の意味がわかったので、知りたいことを明確にしましょう。

• オープンソースソフトウェアでのコードコピーはどのくらい一般的ですか？オープンソースプロジェクトのコードには多くのクローンがありますか？
• どのようなライセンスがありますか？最も一般的なライセンスは何ですか？ファイルには一度に複数のライセンスが含まれていますか？
• どのような最も一般的な可能性借入金、別のライセンスからのコード遷移ですか、？
• どのような最も一般的な違反の可能性、原稿や受信ライセンスの条項で禁止されているコード遷移ですか、？
• 個々のコードフラグメントの考えられる起源は何ですか？このコードが違反してコピーされた可能性はどのくらいですか？

このような分析を実行するには、次のものが必要です。

1. 多数のオープンソースプロジェクトからデータセットを収集します。
2. それらの中からコードスニペットのクローンを見つけます。
3. 実際に借りることができるクローンを特定します。
4. コードの各部分について、2つのパラメーター（ライセンスと最後の変更時刻）を決定します。これは、クローンのペアのどのフラグメントが古く、どちらが若いかを確認するために必要です。したがって、誰が誰からコピーできるかを確認します。
5. ライセンス間で許可される移行と許可されない移行を決定します。
6. 上記の質問に答えるために、受け取ったすべてのデータを分析します。

それでは、各ステップを詳しく見ていきましょう。

データ収集

最近では、GitHubを使用して多くのオープンソースに簡単にアクセスできるので、非常に便利です。コード自体だけでなく、その変更の履歴も含まれています。これは、この調査にとって非常に重要です。誰が誰からコードをコピーできるかを見つけるには、各フラグメントがいつプロジェクトに追加されたかを知る必要があります。



データを収集するには、学習するプログラミング言語を決定する必要があります。事実、クローンは1つのプログラミング言語のフレームワーク内で検索されます。ライセンス違反について言えば、既存のアルゴリズムの別の言語への書き換えを評価することはより困難です。このような複雑な概念は特許によって保護されていますが、私たちの研究では、より一般的なコピーと変更について話しています。 Javaを選択したのは、Javaが最も広く使用されている言語の1つであり、商用ソフトウェア開発で特に人気があるためです。この場合、潜在的なライセンス違反が特に重要になります。



2018年の初めに、50を超える星を持つGitHubのすべてのプロジェクトをまとめた、既存のPublic GitArchiveを基礎としました。Javaで少なくとも1行あるすべてのプロジェクトを選択し、変更の完全な履歴とともにそれらをダウンロードしました。移動した、または使用できなくなったプロジェクトをフィルタリングした後、約1.25TBのハードディスク領域を占める23,378のプロジェクトがあります。



さらに、プロジェクトごとに、フォークのリストをダンプし、データセット内にフォークのペアを見つけました。これは、フォーク間のクローンには関心がないため、さらにフィルタリングするために必要です。データセット内にフォークを含む合計324のプロジェクトがありました。

クローンを見つける

クローン、つまり同様のコードを見つけるには、いくつかの決定を行う必要もあります。まず、同様のコードにどの程度、どの程度の容量で関心があるかを判断する必要があります。従来、クローンには4つのタイプがあります（最も正確なものから最も正確でないものまで）。

• 同一のクローンはまったく同じコードであり、インデント、空白行、コメントなどのスタイル上の決定のみが異なる可能性があります。
• 名前が変更されたクローンには最初のタイプが含まれますが、変数名とオブジェクト名がさらに異なる場合があります。
• クローズクローンには上記のすべてが含まれますが、式の追加、削除、移動など、フラグメントがまだ類似している、より重要な変更が含まれる場合があります。
• , — , ( ), ().

コピーと変更に関心があるため、最初の3つのタイプのクローンのみを検討します。



2番目の重要な決定は、どのサイズのクローンを探すかです。同一のコードフラグメントは、ファイル、クラス、メソッド、個々の式の間で検索できます...これが最もバランスの取れた検索の粒度であるため、私たちの作業では、メソッドを基礎として採用しました。多くの場合、コードをファイル全体ではなく小さなフラグメントでコピーしますが、同時にメソッド-それはまだ完全な論理ユニットです。



クローンを見つけるために、選択されたソリューションに基づいて、我々は使用SourcererCCのクローンの検索が使用していることをツール-単語の袋方法を：各メソッドはトークン（キーワード、名前、リテラル）の頻度リストとして表され、その後、そのようなセットが比較され、2つのメソッドのトークンの特定の割合以上が一致する場合（この割合は類似性しきい値と呼ばれます）、そのようなペアはクローンと見なされます。このメソッドは単純ですが（メソッドの構文ツリーやプログラム依存関係グラフの分析に基づくはるかに複雑なメソッドがあります）、その主な利点はスケーラビリティです。私たちのような膨大な量のコードでは、クローンの検索を非常に迅速に実行することが重要です。 ..。



異なる類似性のしきい値を使用して異なるクローンを検索し、類似性のしきい値を100％にして別の検索を実行しました。この場合、同一のクローンのみが識別されました。さらに、借用できない可能性のある些細で一般的なコードを破棄するために、調査対象の最小メソッドサイズが設定されました。



この検索には66日間の連続計算が必要で、3,860万のメソッドが特定され、そのうち1,170万が最小サイズのしきい値を超え、そのうち760万がクローニングに参加しました。合計12億ペアのクローンが見つかりました。

最終変更時刻

さらに分析するために、プロジェクト間のクローンのペア、つまり、異なるプロジェクトで見つかった類似のコードフラグメントのペアのみを選択しました。ライセンスの観点から、同じプロジェクト内のコードフラグメントにはあまり関心がありません。独自のコードを繰り返すことは悪い習慣と見なされますが、禁止されていません。合計で、約5億6100万のプロジェクト間ペア、つまりすべてのペアの約半分がありました。これらのペアには380万のメソッドが含まれており、最後の変更の時刻を決定する必要がありました。これを行うために、git blameコマンドが各ファイルに適用され（ファイルには複数のメソッドが存在する可能性があるため、898千であることが判明しました）、ファイルの各行の最終変更時刻を示します。



したがって、メソッドの各行の最終変更時刻がありますが、メソッド全体の最終変更時刻をどのように決定するのでしょうか。これは明らかなようです-あなたは最新の時間を取ってそれを使用します：結局のところ、それはメソッドが最後に変更されたのはいつかを実際に示しています。しかし、私たちのタスクにとって、そのような定義は理想的ではありません。例を考えてみましょう：





それぞれ25行のフラグメントがいくつかある形のクローンを見つけたとします。ここでより飽和した色は、より遅い修正時間を意味します。左側のフラグメントが2017年に一度に書き込まれ、右側のフラグメントで2015年に22行が書き込まれ、2019年に3行が変更されたとします。右側のフラグメントは後で変更されたことがわかりますが、誰が誰からコピーできるかを判断したい場合は、反対のことを想定する方が論理的です。左側のフラグメントは右側のフラグメントを借用し、右側のフラグメントは後でわずかに変更されました。これに基づいて、コードの一部が最後に変更された時刻を、個々の行が最後に変更された最も頻繁な時刻として定義しました。突然そのようなことが何度かあった場合は、後の方が選ばれました。



興味深いことに、データセット内の最も古いコードは、Javaの黎明期の1997年4月に書き戻され、2019年に作成されたクローンを見つけました。

ライセンスの定義

2番目の最も重要なステップは、各チャンクのライセンスを決定することです。このために、次のスキームを使用しました。まず、Ninkaツールを使用して、ファイルヘッダーに直接示されているライセンスが決定されました。存在する場合は、その中の各メソッドのライセンスと見なされます（Ninkaは複数のライセンスを同時に認識できます）。ファイルに何も指定されていない場合、または情報が不十分な場合（たとえば、著作権のみ）、ファイルが属するプロジェクト全体のライセンスが使用されました。それに関するデータは、元のPublic Git Archiveに含まれており、それに基づいてデータセットを収集し、別のツールであるGo LicenseDetectorを使用して決定しました。ライセンスがファイルまたはプロジェクトにない場合、そのようなメソッドは次のようにマークされます。GitHubは、GitHub利用規約（すべてのデータがダウンロードされた場所）の対象となるためです。



このようにすべてのライセンスを定義したので、最終的にどのライセンスが最も人気があるかという質問に答えることができます。合計94の異なるライセンスが見つかりました。多くのメソッドで非常に大きなファイルが原因で発生する可能性のあるねじれを補正するために、ここでファイルの統計を提供します。



このスケジュールの主な特徴は、ライセンスの最も強力な不均一な配布です。グラフには3つの領域があります。10万ファイルを超える2つの「ライセンス」、1万から10万ファイルの別の10、および1万ファイル未満のライセンスのロングテールです。



最初に最も人気のあるものを考えてみましょう。最初の2つの領域を線形スケール







で示します。最も人気のあるライセンスの間でも不均一性が見られます。 Apache-2.0は、そもそも大きな差であり、すべての許容ライセンスの中で最もバランスが取れており、すべてのファイルの半分強をカバーしています。



その後、悪名高いライセンスの欠如が続きます。この状況は中規模および大規模のリポジトリ（50を超える星）の間でも非常に一般的であるため、さらに詳細に分析する必要があります。コードをGitHubにアップロードしただけでは開かないため、この状況は非常に重要です。-そして、実用的なものがあり、この記事から覚えておく必要がある場合は、これがそれです。コードをGitHubにアップロードすることにより、コードを表示およびフォークできることを示す利用規約に同意したことになります。ただし、これを除いて、コードに対するすべての権利は作成者にあるため、配布、変更、さらには使用には明示的な許可が必要です。すべてのオープンソースが完全に無料であるだけでなく、GitHubのすべてのコードも完全にオープンソースであるとは限りません。そして、そのようなコードがたくさんあるので（ファイルの14％、そしてデータセットに含まれていないあまり人気のないプロジェクトの中で、おそらくそれ以上）、これはかなりの数の違反の原因となる可能性があります。



上位5つには、すでに述べたMITとBSDの許容ライセンス、およびcopyleftGPL-3.0以降も表示されます。 GPLファミリのライセンスは、バージョンの数が多い（それほど悪くはない）だけでなく、ユーザーがこのライセンスまたはそれ以降のバージョンの条件を使用できるようにする「以降」の追記も異なります。これは別の質問につながります：これらの94のライセンスの中に、明らかに類似した「ファミリー」があります-それらのどれが最大ですか？



3番目はGPLライセンスです。リストには8種類あります。このファミリは最も重要です。これらを合わせると、ファイルの12.6％をカバーし、Apache-2.0に次ぐものであり、ライセンスがないためです。第二に、意外にもBSD。従来の3段落バージョンと2および4段落バージョンに加えて、非常に特定のライセンス-11個のみ。これには、たとえば、BSD 3-Clause No Nuclear Licenseが含まれます。これは3つの条項を持つ通常のBSDであり、このソフトウェアを使用して核を作成または操作すること



はできません。このソフトウェアは設計されていないことを認めます。核施設の設計、建設、運用、または保守での使用が認可または意図されています。



最も多様なのは、クリエイティブコモンズファミリーのライセンスです。これについては、こちらをご覧ください。それらは13もあり、少なくとも1つの重要な理由から、ざっと目を通す価値があります。StackOverflowのすべてのコードはCC-BY-SAでライセンスされています。



まれなライセンスの中には、たとえば、いくつかの注目すべきものがあります。529ファイルをカバーし、名前がコードで言うことを正確に実行できるようにする、パブリックライセンス（WTFPL）に必要なことを実行します。たとえば、ビールウェアライセンスもあります。これは、何でもできるようにし、会議時に著者にビールの購入を促すものです。私たちのデータセットでは、このライセンスのバリエーションにも出くわしましたが、これは他のどこにも見つかりませんでした-Sushiwareライセンス。したがって、彼女は著者に寿司を買うように勧めます。



もう1つの奇妙な状況は、1つのファイル（つまりファイル内）に複数のライセンスが見つかった場合です。私たちのデータセットでは、そのようなファイルは0.9％しかありません。 7.4千のファイルが一度に2つのライセンスでカバーされ、そのようなライセンスの合計74の異なるペアが見つかりました。 419個のファイルが3つのライセンスでカバーされ、そのようなトリプレットは8つあります。そして最後に、データセット内の1つのファイルには、ヘッダー内の4つの異なるライセンスが記載されています。

可能な借入

ライセンスについて説明したので、ライセンス間の関係について説明します。最初に行うことは、借用できないクローンを削除することです。現時点では、コードフラグメントの最小サイズと1つのプロジェクト内のクローンの除外という2つの方法でこれを考慮に入れようとしたことを思い出してください。次に、さらに3つのタイプのペアを除外します。

• フォークとオリジナルのペア（および、たとえば、同じプロジェクトの2つのフォークの間）には関心がありません。このために、それらを収集しました。
• また、同じ組織またはユーザーに属する異なるプロジェクト間のクローンには関心がありません（著作権は同じ組織内で分割されていると想定しているため）。
• 最後に、2つのプロジェクト間で異常に多数のクローンを手動でチェックすることにより、重要なミラー（別名間接フォーク）、つまり、無関係のリポジトリにアップロードされた同一のプロジェクトを見つけました。

不思議なことに、残りのペアの11.7％が、類似性のしきい値が100％の同一のクローンです。おそらく、GitHubには完全に同一のコードが少ないはずだと直感的に思われます。



このフィルタリングの後に残っているすべてのペアを次のように処理します。

1. ペアの2つのメソッドの最後の変更の時間を比較します。
2. , : .
3. , «» «» . , 2015 MIT, 2018 — Apache-2.0, MIT → Apache-2.0.

最後に、潜在的な借用ごとにペアの数を合計し、降順で並べ替えました。







ここでは、依存関係がさらに極端になっています。Apache-2.0内のコードの借用の可能性は、クローンのすべてのペアの半分以上を占め、ライセンスの最初の10ペアはすでにクローンの80％以上をカバーしています。2番目と3番目に頻繁なペアがライ​​センスのないファイルを処理することに注意することも重要です。これもそれらの頻度の明らかな結果です。最も人気のある5つのライセンスについて、遷移をヒートマップとして表示できます。

ライセンス違反の可能性

私たちの研究の次のステップは、潜在的な違反であるクローンのペア、つまり、元のライセンスとホストライセンスの条件に違反する借用を特定することです。これを行うには、上記のライセンスのペアを許可または禁止された移行としてマークする必要があります。したがって、たとえば、最も一般的な移行（Apache-2.0→Apache-2.0）はもちろん許可されますが、2番目の移行（GitHub→Apache-2.0）は禁止されます。しかし、非常に多く、そのようなペアは何千もあります。



これに対処するには、レンダリングされた最初の10ペアのライセンスが、すべてのクローンペアの80％をカバーすることに注意してください。この不均一性のために、クローンのペアの99％をカバーするために、176ペアのライセンスのみを手動でマークするだけで十分であることが判明しました。これは、かなり許容できる精度であるように思われました。これらのカップルの中で、私たちは禁止されている4つのタイプのカップルを検討しました。

1. ライセンスなしでファイルからコピーします（GitHub）。すでに述べたように、そのようなコピーにはコードの作成者からの直接の許可が必要であり、ほとんどの場合、そうではないと想定しています。
2. ライセンスなしでファイルにコピーすることも禁止されています。これは本質的にライセンスを消去して削除するためです。Apache-2.0やBSDのような許容ライセンスでは、コードを他のライセンス（独自のライセンスを含む）で再利用できますが、これらのライセンスでも、元のライセンスをファイルに保持する必要があります。
3. .
4. (, Apache-2.0 → GPL-2.0).

ライセンスのないコードが表示される（コピーできない）ものを除いて、クローンの1％をカバーする他のすべてのまれなライセンスのペアは（不必要に誰かを非難しないように）許容としてマークされました。



その結果、値上げ後、借入の72.8％が許可され、27.2％が禁止されていることが判明しました。次のグラフは、最も違反しているライセンスと最も違反しているライセンスを示しています。







左側は、最も違反されたライセンス、つまり、考えられる違反の最大数の原因です。その中で、そもそもライセンスのないファイルで占められています。これは重要な実用上の注意です。ライセンスのないファイルを特に注意深く監視する必要があります。..。このリストでApache-2.0許容ライセンスが何をするのか不思議に思うかもしれません。ただし、上記のヒートマップからわかるように、約2,500万件の禁止された借用は、ライセンスなしのファイルへの借用であるため、これは人気の結果です。



右側は違反でコピーされたライセンスであり、ここではほとんどすべてが同じApache-2.0とGitHubです。

個々の方法の起源

最後に、私たちは研究の最後のポイントに到達します。この間ずっと、そのような研究で通例であるように、私たちはクローンのペアについて話しました。しかし、そのような判断の特定の一方的な、不完全さを理解する必要があります。実際のところ、たとえば、1つのコードに20人の「兄」（または知っている「親」）がいる場合、20組すべてが潜在的な借用と見なされます。そのため、「潜在的な」借用と「可能性のある」借用について話しているのです。特定のメソッドの作成者が20か所から借用した可能性は低いです。それにもかかわらず、この推論は、異なるライセンス間のクローンに関する推論と見なすことができます。



このような不完全な判断を避けるために、同じ写真を別の角度から見ることができます。クローン画像は実際には有向グラフです。すべてのメソッドはその上の頂点であり、シニアからジュニアへの有向エッジによって接続されています（同じ日付のメソッドを考慮しない場合）。前の2つのセクションでは、エッジの観点からこのグラフを確認しました。各エッジを取得し、その頂点を調査しました（ライセンスのペアを取得します）。それでは、頂点の観点から見てみましょう。グラフの各頂点（メソッド）には、祖先（「シニア」クローン）と子孫（「マイナー」クローン）があります。それらの間のリンクは、「許可」と「禁止」に分けることもできます。



これに基づいて、各方法は次のカテゴリのいずれかに起因する可能性があり、そのグラフは画像に示されています（ここでは、実線は禁止された借用を示し、破線は許可







されています）：提示された構成の2つは、ライセンス条件の違反を構成する可能性があります。

• 重大な違反とは、メソッドに祖先があり、それらからのすべての移行が禁止されていることを意味します。これは、開発者が実際にコードをコピーした場合、ライセンスに違反してコピーしたことを意味します。
• 弱い違反とは、メソッドに祖先があり、禁止された遷移の背後にあるのはそのうちの一部のみであることを意味します。これは、開発者がライセンスに違反してコードをコピーした可能性があることを意味します。

その他の構成は違反ではありません。

• , , .
• — , — , .
• , , — , . , , — , . : , , , , ( , , ).

では、メソッドはデータセットでどのように分散されていますか？







メソッドの約3分の1にはクローンがまったくなく、別の3分の1にはリンクされたプロジェクトにのみクローンがあることがわかります。一方、メソッドの5.4％は「軽度の違反」を表し、4％は「重大な違反」を表します。これらの数はそれほど大きくはないように思われるかもしれませんが、多かれ少なかれ大規模なプロジェクトにはまだ数十万の方法があります。

TL; DR

この記事には多くの経験的な図やグラフが含まれているため、主な調査結果のいくつかを次に示します。

• クローンの数は数百万であり、それらの間には10億を超えるペアがあります。
• , Java- 50 , 94 , : Apache-2.0 . Apache-2.0 .
• , 27,2%, .
• 35,4% , 5,4% «» , 4% «» .

?

結論として、上記のすべてが必要な理由についてお話ししたいと思います。少なくとも3つの答えがあります。



まず、おもしろいです。ライセンスは、プログラミングの他のすべての側面と同じくらい多様です。ライセンスのリスト自体は、一部のライセンスの特異性と希少性のために非常に興味深いものであり、人々はさまざまな方法でそれらを作成および操作します。これは間違いなく、コード内のクローンと一般的なコードの類似性にも当てはまります。クローンが数千あるメソッドもあれば、クローンが1つもないメソッドもありますが、一見しただけでは、それらの根本的な違いに気付くのは簡単ではありません。



次に、調査結果を詳細に分析することで、いくつかの実用的なヒントを作成できます。

1. - . Apache-2.0, MIT, BSD-3-Clause, GPL LGPL.
2. : . - , , .
3. GitHub, . . — , . : - , , , , . , .

ライセンスの明確な説明、および新しいプロジェクトのライセンスの選択に関するアドバイスについては、tldrlegalやchoosealicenseなどのサービスを利用できます。



最後に、取得したデータを使用してツールを作成できます。現在、私たちの同僚は、機械学習方法（多くの特定のライセンスが必要なだけです）とIDEプラグインを使用してライセンスをすばやく決定する方法を開発しています。これにより、開発者はプロジェクトの依存関係を追跡し、起こりうる非互換性に事前に気付くことができます。



うまくいけば、あなたはこの記事から何か新しいことを学んだでしょう。基本的なライセンス条項への準拠はそれほど面倒ではなく、最小限の労力でルールに従ってすべてを行うことができます。一緒に教育し、他の人を教育し、「正しい」オープンソースソフトウェアの夢に近づきましょう！