タグ付けされた質問 「bsd-license」

BSD(Berkeley Software Distribution)ライセンスは、寛容なオープンソースライセンスのファミリです。

2
MIT vs. BSD vs.デュアルライセンス
私の理解は: MITライセンスのプロジェクトは、BSDライセンスのプロジェクトで使用/再配布できます。 BSDライセンスのプロジェクトは、MITライセンスのプロジェクトで使用/再配布できます。 MITとBSD 2条項のライセンスは基本的に同一です。 BSD 3条項= BSD 2条項+「承認なし」条項 デュアルライセンスを発行すると、ユーザーはこれらのライセンスから選択できます。両方にバインドされることはありません。 上記のすべてが正しい場合、デュアル MIT / BSDライセンスを使用する意味は何ですか?BSDが3条項バージョンを参照している場合でも、ユーザーはMITライセンスのみを遵守することを合法的に選択することはできませんか? 「裏書きなし」条項を本当に適用したい場合は、BSD(デュアルではない)としてライセンスする必要があります。「承認なし」条項を気にしない場合は、MITだけで十分であり、MIT / BSDは冗長です。 同様に、MITライセンスとBSDライセンスは両方とも「GPL互換」であり、GPLライセンスのプロジェクトで再配布できるため、MIT / GPLのデュアルライセンスも冗長のようです。

3
BSDの「非推奨条項」が良いアイデアである場合、なぜ人々はBSDよりMITライセンスを選ぶのですか?[閉まっている]
この質問と回答によると New BSDライセンスの「非推奨条項」の目的は何ですか? 不要な方法であなたの名前を使用する人々を防ぐために、MITよりもBSDライセンスを選ぶ方が賢明です。 その場合、なぜ人々はまだBSDライセンスよりもMITライセンスを選ぶのですか?

1
サードパーティのライブラリライセンス「ペーパーワーク」を整理するためのベストプラクティスは何ですか?
私は小さなオープンソースプロジェクトを開発しています。このアプリケーションは、Apache、MIT、BSD、LGPL、CDDLなどのさまざまなライセンスでリリースされた多くのサードパーティライブラリを使用します。 これらの各ライセンスには、独自の「事務処理」要件があります。たとえば、Apacheライセンスv2.0には次のように記載されています。 作品にその配布の一部として「NOTICE」テキストファイルが含まれている場合、配布する派生作品には、そのようなNOTICEファイルに含まれる帰属通知の読み取り可能なコピーを含める必要があります。 MITライセンスには著作権表示が含まれており、次のように記載されています。 上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは大部分に含まれるものとします。 BSDライセンスには著作権表示も含まれており、次のように記載されています。 バイナリ形式での再配布では、上記の著作権表示、この条件リスト、および以下の免責事項を、配布物とともに提供されるドキュメントおよび/またはその他の資料に複製する必要があります。 LGPL v.3によると: (あなたは)ライブラリが使用されていること、およびライブラリとその使用が本ライセンスの対象であることを、結合著作物の各コピーとともに目立つように通知する必要があります。 LGPLおよびCDDLライセンスでは、ソースコードをライブラリのバイナリ形式とともに提供する必要があるため、ソースコードの入手方法に関する情報はどこかで提供する必要があります。 このすべてのデータを整理するためのベストプラクティスは何ですか?テキストファイルを作成し、すべてのNOTICEファイル、MITおよびBSDライセンスなどのコンテンツをそのファイルにコピーする必要がありますか?...または、ライブラリごとに個別のディレクトリを作成し、ライブラリに関連するすべてのデータをそのディレクトリに配置する必要がありますか?… または、他の何か? 公開されたプロジェクトでこの「ペーパーワーク」の例を見るのも面白いでしょう。 更新: 私が読んでいるあなたは、すべてのソースファイルとライセンス通知を含める必要がありますか?、しかしそれは私の問題に対処しません。私の質問は、プロジェクトで使用されているサードパーティのライブラリに関するものであり、その質問はプロジェクト独自のソースコードのヘッダーに関するものです。


4
New BSDライセンスの「非推奨条項」の目的は何ですか?
注:この質問は、「不快なBSD広告条項」に関するものではありません。New BSDライセンスにはその条項は含まれておらず、GPLと互換性があります。 私は自分のプロジェクトのNew BSDライセンスとMITライセンスのどちらかを選択しようとしています。BSDライセンスに次の条項が含まれていることを除いて、これらは基本的に同じです。 <組織>の名前もその貢献者の名前も、書面による事前の許可なしに、このソフトウェアから派生した製品を推奨または宣伝するために使用することはできません。 なぜこの節を使用したいのでしょうか?誰かがあなたのコードを使って有名なソフトウェアを作った場合、悪評を得るのは何が悪いのですか また、特定の名前でユーザーができることとできないことを決定することは、知的財産の領域外になりますか?



2
ライセンスのコンテキストでのServiceStackベースのソリューションの将来
Demis Bellotが数週間前にServiceStackの商用化を発表したので、次の質問を誰かに明確にしてほしいです。以下のリンクを参照してください。 https://plus.google.com/app/basic/stream/z12tfvoackvnx1xzd04cfrirpvybu1nje54 (ServiceStackまたはSSと言うときは、ServiceStack.Textなどの関連するすべてのSSライブラリを参照することに注意してください。) 現在、ServiceStackを使用して既に開発されたソリューションがある場合、SSバイナリを商用リリースバージョンにアップグレードしなくても、SSが商用になったらライセンスを購入する必要がありますか? SSの以前のバージョン(商用ライセンスの前)は常にオープンソースであり、以前と同じライセンスを使用しますか? 今日、GithubでSSをフォーク(商用ライセンスの前に)する場合、SSが商用になった後にそれを維持することは違法ですか? 質問2の答えが「はい」の場合、商用ライセンスを気にせずにSSが商用になった後でも、以前のバージョンをフォークできます(ソースを維持し、一般に公開する間)。

4
BSD 2/3節のコードをGPLに再ライセンス
新しいBSDライセンスでいくつかのソースコードをリリースしたとします。他の誰かがこのコードを取得し、変更を加え、GPLの条件に基づいて配布することは許可されていますか?ウィキペディアから: 元のMIT / Xライセンス、BSDライセンス(現在の2句形式)、LGPLなど、最も一般的なフリーソフトウェアライセンスの多くは「GPL互換」です。つまり、それらのコードはGPLの下でプログラムと競合することなく組み合わせることができます(新しい組み合わせではGPLが全体に適用されます)。ただし、一部のフリー/オープンソースソフトウェアライセンスはGPL互換ではありません。 これは、新しいBSDライセンスコードをGPLに再ライセンスできることを意味していると思いますか?
11 gpl  bsd-license 

3
GPLとBSDライセンスコードを組み合わせるときに、実際にライセンスファイルを管理する方法は?
私は、GPL(LGPLではない)ライセンスを持つ1つのライブラリと、3条項のBSDライセンスを持つ1つのライブラリを使用するコードを書いています。私はGPLライセンスのライブラリにリンクしているので、私のコードもGPLである必要があります。実際には、BSDライブラリの元のLICENSE.txtをどのように扱うべきですか? (A)メインのソースコードがGPLライセンスで、一部のサブディレクトリがBSDライセンスになるようにプロジェクトを配布できますか? (B)ライブラリにリンクするだけでなく、BSDおよびGPLコードをより複雑な方法で使用および結合する場合、LICENSE.txtをどうすればよいですか? 3節のBSDテキストは、「ソースコードの再配布では、上記の著作権表示、この条件のリスト、および次の免責事項を保持する必要があります。」どうやら私は著作権表示とその条件のリストをどこかに保持する必要があります。ただし、GPLライセンスのtxtファイルをどこかに置く必要もあります。 さらに、明らかに、次の条件が満たされている場合にのみ、「次の条件が満たされていれば、「ソース形式とバイナリ形式での再配布と使用、変更の有無にかかわらず、許可される」を保持する必要はありません。他の部品はそのままにしておきます。 では、どのように、そしてどのテキストファイルで、GPLライセンステキストと、BSDライセンスの一部および私が保持する著作権を実際に整理する必要がありますか? 編集:したがって、ケースBでは、3句のBSDライセンスコードを取得し、それをGPLの下で再配布します。これは、3句のBSDライセンスがGPLと(一方向)互換であるためです。ライセンステキストとテキストファイルを実際に処理する方法を尋ねているだけです。

2
BSDライセンスプロジェクトへの貢献者からの著作権表示を管理する方法
LICENSEファイルには次のBSDライセンスがあります。 Copyright (c) 2006-2016 SymPy Development Team All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: a. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. …

2
BSDライセンスのプロジェクトには、各貢献者からの署名入りの声明が必要ですか?
今日、Fossil SCMのメーリングリストを読みました。 BSDの問題は、貢献者がBSDであることを示す署名済みのフォームを各貢献者から実際に取得する必要があることです。GPLでコードを表示するためには、互換性のあるライセンスでコントリビューションをリリースすることが前提条件であるため、これはGPLでは自動的に行われます。これにより、GPLは多くの貢献者がいる高度なコラボレーション環境に最適です。BSDは読者にとって寛容です(負担が少ない)が、執筆者が書類を提出する必要があるため、執筆者にとっては少し厳しいものになります。 誰かがその理由を説明してもらえますか?また、プロジェクトの貢献者からのそのような署名された声明がないことによって起こり得る結果は何ですか?

3
BSDライセンスのプロジェクトをフォークするときの法的考慮事項は何ですか?
2節のBSDライセンスでリリースされたプロジェクトをフォークすることに興味があります。 Copyright(c)2010 {著作権者}無断転載を禁じます。 以下の条件が満たされている場合に限り、変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用が許可されます。 (1)ソースコードの再配布では、上記の著作権表示、この条件のリスト、および最後の免責事項を保持する必要があります。バイナリ形式で再配布する場合は、上記の著作権表示、この条件のリスト、および次の免責事項を、配布物とともに提供されるドキュメントやその他の資料に複製する必要があります。 (2){著作権者}の名前またはその寄稿者の名前は、特定の事前の書面による許可なしに、このソフトウェアから派生した製品を推奨または宣伝するために使用することはできません。 免責事項 このソフトウェアは、著作権者および寄稿者によって「現状のまま」提供され、商品性および特定の目的に対する適合性の黙示の保証を含むがこれに限定されない、明示または黙示の保証は否認されます。いかなる場合も、著作権者または寄稿者は、直接的、間接的、偶発的、特別、例示的、または派生的な損害(代替商品またはサービスの購入、使用、データ、または利益の損失を含むが、これらに限定されない)に対して責任を負わないものとします。またはビジネスの中断)責任の理論にかかわらず、契約、厳格責任、または不法行為(過失またはその他の場合を含む)にかかわらず、このソフトウェアの使用のいかなる方法においても、その問題の助言があったとしても これまでにプロジェクトをforkしたことはありませんが、このプロジェクトは、私が必要とするものと非常に似ています。ただし、どこまで到達できるかは不明なので、最新のものをリポジトリから取得して作業を開始する予定です。たぶん、最終的には、私が望んでいる場所に到達し、リリースできるようになるでしょう。これは正しいアプローチですか? 正確には、これはプロジェクトの分岐にどのように影響しますか?どのコンポーネントまたはセクションを誰が所有しているかを追跡するにはどうすればよいですか(私が著作権を所有している、元の作成者がコードベースを踏み始めたら、著作権を所有している)。このプロジェクトをフォークできますか?リリースする前に何をする必要がありますか。また、いつこのBSDライセンスの作品から派生したソフトウェアをリリースすることにしたのですか?


1
BSDライセンスのオープンソースプロジェクトを管理している場合、誰かがGPLライセンスのコードを不法に寄贈しないようにするにはどうすればよいですか?
BSD、MIT、または他の寛容なライセンスの下でライセンスされたオープンソースプロジェクトは、コミュニティからのコードの寄付を受け入れます。 自分が所有していないGPLライセンスのコードを誰かが取得してそれをBSDライセンスのプロジェクトに提出するのを防ぐにはどうすればよいですか?寄付がGPLライセンスのプロジェクトから盗まれたことを知りませんし、それを受け入れます。 プロジェクト全体をGPLにしないために、私はそのような貢献を受け入れたくありません。しかし、貢献者が貢献しているコードの著作権を実際に持っているかどうかを知る方法はありません。そのため、誰かがGPLライセンスのコードを私のプロジェクトに不法に寄付した場合、それらを止める方法はわかりません(寄付をまったく受け入れないことを除けば)。 確かに、BSDとMITでライセンスされたプロジェクトはたくさんあるので、解決策があるはずです。 ありがとう!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.