ソフトウェアに対して選択するライセンスに関する推奨事項と経験

ソフトウェアの開発者は、作業の目標に応じて適切なライセンスを選択することができます。

誰がソフトウェアのライセンスを選択するかについて、いくつかの推奨事項/経験を提供できますか？

すべてのコード化された作業をオープンソースコードとして「与える」ことの長所と短所は何ですか？

研究コードの恩恵を受けたい産業のプレーヤーに対処する方法は？

誰がソフトウェアのライセンスを選択するかについて、いくつかの推奨事項/経験を提供できますか？

どのライセンスを選択したかは、コードをどれだけ自由にしたいかによって異なりますが、無料とは人によって異なることを意味します。

• 寛容なライセンスの支持者にとって、無料とは、 将来の派生がどれだけ自由であるかを心配することなく、今すぐ人々がソフトウェアを使用できるようにすることを意味します。
• 支持者のためにコピーレフトライセンス、自由な手段は、ソフトウェアとそれのいずれかの導出があることを保証する無料にてご利用いただけますいくつかの犠牲に準備されて、すぐに自由をそれを確実にするために。

ライセンスがより寛容であるほど、より多くの人々がそれを使用できるようになりますが、それに対するあなたのコントロールはより少なくなります。ただし、制限が厳しいほど、そもそもソフトウェアの使用を延期する可能性が高くなります。

GPL <= 2、GPL 3、LGPL、BSD、Eclipseなど、無料でオープンソースのライセンスが数多くあります。それぞれに長所と短所がありますので、それらがコードに課す制限について読んで、誰がそれを使用できるようにしたいかを決めてください。警告、どちらを選んでも文句を言うでしょう-これは 聖戦の領域です。

全体として、それは微妙なバランスをとる行為であり、ソフトウェアの対象読者に大きく依存します。

• どのライセンスが適切なライセンスであるかを判断するための優れたリソースは、Oxford University OSS Watchの非常に包括的でインタラクティブなライセンス差別化ツールです。

私の意見では、寛容なライセンスとコピーレフトのライセンスの両方が科学コードに適しています-重要なことは、コードがそもそもオープンソースであることです。科学はオープンであるべきであり、その科学をサポートするために使用されるコードもオープンであるべきだと思います。

すべてのコード化された作業をオープンソースコードとして「与える」ことの長所と短所は何ですか？

あなたのソフトウェアを配るという考えは、他の人がそれを役に立つと思うなら、彼らはそれを使うということです。

彼らがそれを使用する場合、彼らはバグを見つけ、報告し、しばしば修正し、同じことをするあなたの努力を節約します。

彼らがそれを気に入っていて、あなたのソフトウェアが望んでいることをほぼしているなら、彼らはあなたのソフトウェアを強化し、それらの強化を元に戻すかもしれません。

それは多くのifsです。

研究コードの恩恵を受けたい産業のプレーヤーに対処する方法は？

まず、コードの商用利用を禁止する場合は、商用の再利用条項のないライセンスを選択できます。

第二に、誰かがあなたのソフトウェアを使って実際にコードを他の人に配布することなくサービスを強化するかもしれないと思うなら、その特定のコピーレフトの抜け穴を塞ぐAffero GPLを検討することができます。

第三に、上記を実行して、デュアルライセンスオプションを提供できます。GPLまたはAGPLライセンスをパブリックダウンロードに提供し、商用ライセンスを有料で提供すると、両方の長所が得られます。また、科学活動をサポートするのに役立つソフトウェアの商用販売から収益を得ることができる場合もあります。

これを行う場合は、最初から提供することに注意してください。これは、後で商用ライセンスの提供を開始するよりも、オープンソースの貢献者からの摩擦が少なくなる可能性があります。コミュニティが人気を博した場合、後で商業的搾取の可能性について真っ直ぐでなければ、売り切れだと非難されることは望ましくありません。コードベースへのサードパーティの貢献を受け入れる前に、適切な貢献者ライセンス契約（CLA）をセットアップすることが理想的です。

この質問に対するこの回答は、このオプションに関する良い情報も提供します。

PETScはこのライセンスを使用します。これは、BSDの制限の少ない形式です。GPLとの決定的な違い、ソフトウェアが商業的に使用できることです。多くの人々は閉じられたソフトウェアに原則的に異議を唱えていますが、私の経験では、GPLライセンスがあればあなたのコードに近づきません。さらに、PETScの産業ユーザーは非常に貴重です。彼らは非常に複雑な問題を抱えている傾向があり、ほとんどの学者は出版物に保証されるよりも難しいと感じるでしょう。また、通常のサポートチェーンに入るように、PETScに多くのコードを戻しました。商用利用の可能性のないライセンスに対して助言し、実際、可能な限り制限の少ないライセンスを推奨します（PETScを間違いなくCDに焼いて、それをだましやすいものに売ることができます）。

私はGPLを使用します。これは主に、元のオープンソース運動に対する感情のためです（したがって、その普及に役立つことを願っています）。さらに、これは逆説的に不道徳な資本家からあなたの可能な収益を保護するための最良の方法です-著者として、あなたは常に並行して異なるライセンスでコードを配布し、こうしてホワイトラベルのビジネス使用のために独自のバージョンを維持することができます。
ただし、これは短所かもしれません-あなたの資金源はあなたのすべての作品がパブリックドメインになるべきであるという免責事項を作ったかもしれません。

とにかく、そのトピックの中で最も重要なことは、ということである任意のライセンスは、科学の発展の世界では、残念ながらかなり頻繁にある、良くないよりある-そして私はすべてのものを嫌い、彼は公表さはありませんでしたJohn Smithのプログラムから/ *盗まれたの* /またはCIは、1995年にジェーンスミスのあるグループに関する投稿でこれを見たと思います...または1993年ですか？

まず、オープンソース化の賛否両論：

プロ：より多くの人々があなたのコードを使用し、フィードバック、修正、改善などを提供します。あなたはより良いコードとそれを信頼するより多くの人々を持つことになります。

短所：コードでビジネスの基盤を作りたい場合、選択肢は少なくなります（ただし、コンサルティングサービスの販売など、まだいくつかあります）

ライセンスの選択に関しては、次の順序で進めます。

1. 雇用主/助成機関は何かを課していますか？その場合、選択肢はありません。コードへのすべての貢献者については、これを確認してください。
2. 選択を制限する特定のライセンスを持つコードを再利用しますか？その場合、選択も制限されます。実際には、GPLライセンスコードの一部を統合することが、こうした制限の最も頻繁な原因です。
3. GPLおよび同様のライセンスの背後にある、すべてのコードをオープンにするべき哲学、またはBSDライセンスの背後にある最も可能性の高い使用を奨励する哲学：あなたがより重視するものを決定してください。
4. 2つの大きなオープンソースライセンスファミリのそれぞれで、コミュニティで最も一般的/受け入れられているものに応じて選択します。

私の研究のほとんどは公的資金によって賄われているため、可能な限り制限の少ないライセンスを使用する義務があると感じています。私の国の他の人々がこの研究の支払いを手伝っている場合、私は自分のコードをクローズドソースおよび/または商用ソフトウェア配布に統合できないことを彼らに伝える権利を本当に持っていますか？私のコードを使用するほとんどの人が学術研究者になると期待していますが、他の（おそらく市販の）ソフトウェアと統合したり、GUIを置いたりして製品を提供することで、ソフトウェアを改善するビジネスに哲学的な問題はありませんそれは彼らが利益を上げるのに役立ちます。

そうは言っても、適切な帰属を必要とするライセンスを使用しようとします。たとえば、会社が私のコードをより大きな商用製品に折りたたむ場合、自分から自分のコードを自由に入手できることを明確にしてもらいたい。しかし、それ以外は、できるだけコードのユーザーに最小限の要件を課したいと思います。

納税者の資金で賄われていないソフトウェア開発については、他のライセンスがより適切であることを理解しています。

誰もこれを非常に明確に綴っていないので、言う価値があると思います：

一部のオープンソースライセンス（特にGPL）は、コードが新しいプロジェクトで使用されるたびに、新しいプロジェクトも同じ方法でライセンスされる必要があるという意味で「バイラル」です。また、（特定の方法で）別のライセンスコードにリンクすることはできません。

1つの実用的な結果は次のとおりです。

• Cで新しい数値メソッドを実装すると、ライセンスでは、MATLABやMathematicaなどの一般的なソフトウェアから呼び出すことができません。

• 新しい画像処理アルゴリズムを実装する場合、ライセンスではPhotoshopプラグインを作成できません

• 等々 ...

これにより、商業的な再利用が防止されるだけでなく、他の学者による便利な再利用も可能になります（閉じたソフトウェアを使用している場合）。 -それをどうするか」という方法。

これは、ライセンスの策定を完了する前に考慮する必要があるものです。

このことを知らなかった、またはこの角度からそれを考慮していない人々（オープンソースライセンスにあまり詳しくない）に会ったので、私はこのように言います。

^{（これは単なる個人的な意見ですが、（公的資金による）学界からの仕事にこのような制限を適用することは適切ではないと考えています。そのため、コードを保持するか、または提供します。）}

どのライセンスを選択するかにかかわらず、すべての資金提供契約を注意深く確認し、ソフトウェアのライセンス供与の方法を指示または制限する条項がないことを確認してください。

私の場合、私のプロジェクトの多くは、ここと少しそこにある資金のいくつかの層から成り立っていることを知っています。 照明をつけている人たちが自分のものライセンスできる実行中のマシンはかなり複雑です。

大量のコードについては、他の回答で説明されているライセンスの1つ、通常はLGPLを使用します。ただし、通常はソフトウェアには推奨されませんが、業界の同僚に送信する可能性のある小さな自己完結型のスクリプトについては、クリエイティブコモンズライセンスを選択することがよくあります。これは、コードの送信先の個人にとってより明確になる傾向があり、誤解の潜在的な問題を防ぐためです。これは私にとって過去にうまく機能しました。

ここで答えているほとんどの人々（学術機関や公的機関で働いている）とは異なり、私は商業分野で働いています。

私の製品の場合、コードは閉じられており、これを行うことによるビジネス上の大きな利点が引き続きあります。しかし、もちろん他の方法もあります（たとえば、MySQLで実証されているように）。LGPL +ライブラリの商用ライセンスのアプローチをよく見ます。私はまだ商用システムでそのようなライブラリを使用していませんが、それを除外しません（これまでのところ、そのようなライブラリ、例えばALGLIBをR＆Dレベルでしか使用していません）。これはGPL製品とは対照的です。GPL製品は社内で使用する場合がありますが、主にウイルス性のために製品には使用しません。

ソースコード（ハウツーサンプル、無料プログラムなど）をリリースするときは、通常Berkeleyライセンスを使用します。これは、「無料」コードの精神にあり、属性はありますが、GPL文字列と政治はありません。おそらくこれが、大学（およびMITライセンスなどの同様のライセンス）が大学や公共機関で非常に人気がある理由です。ソースコードは「無料」の本当の意味で与えられます（ここにコードがあります、あなたがそれでやりたいことをしてください）が、著者はまだ信用/属性を取得します。

これは古い質問ですが、Mozilla Public Licenseは許容ライセンス（BSD、MIT）と強力なコピーレフトライセンス（GPL）の中間点として言及する価値があると思います。MPLコードは使用および再配布できますが、MPLコードとその変更は利用可能にする必要があります。たとえば、企業は、元のMPLコードの修正バージョンを利用可能にする限り、MPLコードを取得し、独自の改善を行い、独自のクローズドソースソフトウェアパッケージで配布できます。GPLの場合のように、独自のソースコードをすべてリリースする義務はありません。

BSDライセンスでは、企業があなたのコードを取得し、それを改善することで競争上の優位性が得られるという論理的根拠の下で、これらの貢献をあなたやコミュニティ全体に還元することなく、コードを改善できる恐れがあります。（Matt Knepleyの答えは、すべてがこのように行動するわけではないことを示唆しています）一方、多くの人々はGPLコードを完全に避けているかもしれません。MPLは、少なくとも原則として、これらの潜在的な落とし穴の両方を回避します。