12

私は現在、研究コンテキストでのデータ分析/情報学に焦点を当てて大学院研究を行っており、グローバルな研究コミュニティ向けのユーティリティツールを開発しています。対象ユーザーの圧倒的多数は、むしろコンピューター初心者です。言い換えれば、私のユーザーのほとんどは、必要な依存関係をわざわざ収集してクラスパスに入れることはありません。人々が私のソフトウェアを無視するのを避けるために、私はそれを「fat-jar」として配布し、すべての依存関係を1つの実行可能ファイルに含めました。

私はソフトウェアライセンスについて少し読んでいて、ライブラリの個々のライセンスにかなりの注意を払わずにそうすることは法的に難しいかもしれないことに気づきました。私はここStackOverflow(以下の完全なコレクション)でいくつかの質問を経験しましたが、ますます混乱することになりました。ソフトウェアライセンスについては他にも多くの質問があることを十分に承知していますが、自己完結型パッケージのコンテキストではありません。以下に、パズルの一部を提供するが、簡単な答えではない多くのすばらしい質問をリストしました。シナリオ。

この問題についてより経験豊富でよく読んでいる開発者が、以下のステートメントを確認または拒否することで、この問題に光を当てることができれば幸いです。プログラマーではなく職業であるが、プログラミングにますます興味を持っている人々にとって、それは役に立つかもしれないと思います。私の理解は:

  • 依存関係を再配布しない限り、自分のプロジェクトにどのライセンスを選択するかと比較して、依存関係がどのライセンスを持っているかは実際には重要ではありません。[残念ながら、このようにすることは、ユーザーベースのかなりの部分を疎外/脅迫することも意味します]

  • すべての依存関係を再配布する場合は、プロジェクトライセンスが依存関係と互換性がある必要があります。[したがって、開発者として、各依存関係のライセンスの詳細を知っている必要がありますか??]

  • GPLは(一般的なものから)最も厳格なオープンソースライセンスであるため、GPLライセンスの下でライブラリを使用する場合、自分のプロジェクトもGPLの下にある必要があり、理論的には他のライセンスと矛盾する可能性があります依存。

  • 私のプロジェクトがGPLの下にあると仮定すると、プロジェクトが非営利であるという事実は問題ではなく、オープンソースでなければなりません。[アルゴリズムと計算方法を公開するには「斬新」である必要があるため、これは私の状況ではかなり注意が必要です]

私は何か重要なことを誤解したり、単に見逃したりしましたか、それともこれは状況の良い要約ですか?私の状況を考えると、ここで言及/考えていない可能性のある他のオプションがありますか?たとえば、依存関係のライセンスに関する問題を回避することは可能ですか?


参照:

多数の依存関係を考慮する必要がありますか?

どのライセンスが相互に互換性がありますか?

オープンソースライセンスの信頼できる概要はどこにありますか?

オープンソースライセンスをどのように選択しますか?

ソースコードの非商用ライセンスを検索する

プラグインを介してクローズソースアプリケーションでGPLコードを使用することは合法的な方法ですか?

商用アプリで「無料」のソフトウェアライブラリを再利用できるかどうかはどうすればわかりますか?[閉まっている]

オープンソースライセンスを正しく適用する(特に@Michael Aaron Safyanによるこの回答)

プロジェクトに適したオープンソースライセンスを見つけるにはどうすればよいですか?

オープンソースライセンスの使用方法

オープンソースライセンスをどのように選択しますか?

4

5 に答える 5

5

依存関係を再配布しない限り、自分のプロジェクトにどのライセンスを選択するかと比較して、依存関係がどのライセンスを持っているかは実際には重要ではありません。

ええ、それは本当です...主流のライセンスを持つオープンソースの依存関係について。だが:

  • これにより、ユーザーはすべての依存関係をダウンロードする必要がありますが、これは悪い考えです。
  • プロプライエタリ依存関係(および「クレイジー」ライセンスを使用したオープンソース依存関係)の場合、ライセンスがこれを禁止している可能性があります

すべての依存関係を再配布する場合は、プロジェクトライセンスが依存関係と互換性がある必要があります。

はい。しかし、それは通常難しいことではありません。どのライセンスが他のライセンスと互換性があるかを調べるために行く場所があります。たとえば、FSFのGPLページ。

[したがって、開発者として、各依存関係のライセンスの詳細を知っている必要がありますか??]

はい。ただし、安全なライセンスを持つ依存関係のみを使用することで、これを単純化できます。(そしてほとんどのオープンソースライセンスはそうです。)

GPLは(一般的なものから)最も厳格なオープンソースライセンスであるため、GPLライセンスの下でライブラリを使用する場合、自分のプロジェクトもGPLの下にある必要があります...

はい。ただし、GPLとLGPLには大きな違いがあることに注意してください。LGPLにはこの制限はありません。

...理論的には、他の依存関係のライセンスと矛盾する可能性があります。

理論的にはそうです。実際には、GPLは他のほとんどのオープンソースライセンスでライブラリを使用することを許可しています。唯一の問題は、他の図書館のライセンスがGPLで禁止されているものを必要とする場合です。つまり、ダウンストリームユーザー、パッケージャーなどに追加の条件を設定するようなものです。

私のプロジェクトがGPLの下にあると仮定すると、プロジェクトが非営利であるという事実は問題ではなく、オープンソースでなければなりません。

それは正しいです。

[アルゴリズムと計算方法を公開するには「斬新」である必要があるため、これは私の状況ではかなり注意が必要です]

私はあなたがまったく問題ではないはずの何かから大きな問題を作っていると思います:

  • 公開する前に他の人があなたのアイデアを盗むことを心配している場合は、公開するまでコードの配布を延期してください。これは明白な常識です...そしてライセンスの問題ではありません。

  • アルゴリズムとメソッドが以前に配布されたソフトウェアに組み込まれている場合、編集者/レビュー担当者があなたの作業を公開のために拒否することはないと思います。あなたの出版物は、出版メディアに関して斬新でなければなりません...

...依存関係のライセンスに関する問題を回避することは可能でしょうか?

  • 独自のコードをすべてゼロから作成することも、他の誰かを雇って作成することもできます。(現実的ではありません)

  • すべての依存関係に商用ソフトウェアを使用し、再配布する権利を支払うことができます。

  • 依存関係の著作権所有者に連絡して、別のライセンス契約を交渉することができます。(それは彼らが連絡可能であり、交渉する用意があることを前提としています。)

しかし、この問題を無視することはできません。

肝心なのは、オープンソースの依存関係を使用してコードをビルドすると、無料で何かを手に入れることができるということです。ルールが気に入らない場合は、オープンソースを使用しない別の方法を見つけてください。

于 2012-10-01T15:49:56.663 に答える
1

最大の問題は、一般的なオープンソースライセンスを使用していないソフトウェアを扱っているかどうかです。簡単に言えば、これらのライセンスがソフトウェアの再配布を禁止している場合、それはその場での議論をほとんど止めます。

ユーザーが自分で適切なライセンスを取得した場合に、ユーザーがライセンスされたライブラリをシステムに簡単に組み込むことができるようにソフトウェアをパッケージ化できます(クラスパスを適切に更新するか、ファイルをにコピーするなど)。既知の場所など)。優れたドキュメントまたは自動化されたスクリプトと組み合わせると、これらのライブラリを使用してソフトウェアをインストールすることで、ユーザーの負担を軽減できます。

オープンソースライセンスソフトウェアのみを使用している場合は、はるかに簡単です。

あなたが言ったように、GPLは最も厳格ですが、そこにあるほとんどのOSSライセンスはGPLv3と互換性があります。Apache、BSD、MIT、MPL、X11/MIT。

そして、はい、特にGPLでは、すべてのライセンスを理解する必要があります。実用的でGPLを回避できれば、これらの問題はほとんどなくなります。先に述べたように、LGPLはGPLよりもはるかに厳格ではなく、このパスを実行する多くのライブラリはその理由でLGPLを選択しますが、代わりに純粋なGPLを使用するライブラリもあります。

今日の美しさは、ライセンスに関して少し断片化されていても、OSSコミュニティはかなり成熟していますが、それでも実際には相互運用可能です。ほとんどの人は、これらの質問をすることさえせず、陽気な道を進みますが、それでも問題を抱え続けることができます。

しかし、要約すると3つの概念になります。

  • プロプライエタリライブラリを使用している場合、配布に関して選択肢はかなり限られています。

  • GPLライブラリを使用している場合は、ソフトウェアもGPLする必要があります。

  • 上記のいずれでもない場合は、心配する必要はありません。

于 2012-10-02T03:55:28.297 に答える
1

ライセンス重要ですが、商用ソフトウェアと直接競合しないオープンソースの非商用ソフトウェアを作成する場合、誰かがライブラリライセンスの1つの誤用の可能性について不平を言うリスクはゼロに非常に近いです(そしてそのようなあなたのマイレージはあなたの「出身国」によって異なるかもしれませんが、不平は法廷ではそれほど遠くには行きません。

だから、あまり心配しないで、ゲームの精神に固執してください:

  • 商用ライブラリを使用している場合は、ライセンスを取得してください(それらの多くは、実際にはオープンソースプロジェクト用の無料の再配布可能なライセンスを持っています)

  • GPLライブラリを使用する場合は、プロジェクトをGPLにします(とにかくこれを実行します)

于 2012-10-02T05:43:02.437 に答える
0

申し訳ありませんが、プロプライエタリライブラリを使用している場合、これには解決策がありません。

「作者との合意がない限り」ソフトウェアに含めることができない無料のプロプライエタリライブラリを使用する場合、クライアントは作者のWebページまたはリポジトリからそれらをダウンロードする必要があります。そうしないと、ライブラリを再配布し、著作権侵害が発生しました。

同様のケースがいくつかありますが、最近ではLinuxでのJavaのOracleです。


GPLの問題:

アルゴリズムの可能な解決策は、依存関係のない別のライブラリに配置し、メインの「GPL」プロジェクトに追加することです。これは、ほとんどの企業が行っていることです。

于 2012-10-01T14:40:47.830 に答える
0

4点は正解だと思います。

プロジェクトが再配布に関して互いに矛盾する依存関係を使用している場合でも可能なことの1つは、プログラムを配布せず、代わりに、プログラム(または問題の依存関係を使用する部分)を独自にホストされる(Web-)サービスとして提供することです。サーバ。そうすれば、必要なほとんどすべての依存関係を使用でき、何もオープンソースにする必要はありません。ただし、一部のライセンス(主に商用ライセンス)ではサーバーの使用が制限される場合があることに注意してください。

于 2012-06-14T13:32:22.493 に答える