タグ付けされた質問 「licensing」

現在、商用コンテキストでのアプリケーションのGPLライブラリに対するリンクの可能性と影響を調査しています。 私が理解したGPLから、アプリケーションが内部で使用されている限り、そのコードをリリースする義務はありません（たとえコピーが管理下の子会社に移動されたとしても）。 私が理解していないのは、FAQからの次の点です： ライブラリが（LGPLではなく）GPLの下でリリースされている場合、それを使用するソフトウェアはGPLまたはGPL互換ライセンスの下にある必要があるということですか？はい。実際に実行されるソフトウェアにはライブラリが含まれているためです。 GPL互換ライセンスを見てみると、それらのいくつか（ブーストライセンスなど）がコードのリリースを課しているようには見えません。これを使用すると、コードを公開する義務を尊重することなく、GPLライセンスに準拠できる状況が作成されます（あまり信頼できないようです）。 （注：ブーストの下でライセンスされたAdobe Photoshopのコンポーネントがあり、コードはオンデマンドで利用できるとは思わない） 最も合理的な説明は、私が何かを見逃しているということです...私がどこでミスをしたか教えてください。

19 licensing 

私は、Javaプロジェクト用に配布可能なバイナリを作成しています。次の2つの方法でリリースしています。 メイヴン・セントラル Googleコードで配布可能なzip形式 私のプロジェクトは、Apache 2.0ライセンスの下でライセンスされています。私は少数のサードパーティを使用していますが、そのうちの1つはMITライセンスです。ライセンスの次のテキストに基づいて、プロジェクトのユーザーにライセンスの内容を認識させることが私の義務だと思います。 上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは大部分に含まれるものとします。 私の情報源と配布物内でこれをどのように参照するのが最善ですか？私は現在考えています： 私のソースファイルは何も参照する必要はありません。それらには、Apache 2.0の定型的な通知が含まれています。 Apache 2.0ライセンステキストを含むLICENSE.txtファイルをプロジェクトのルートに追加します。 zip形式の配布可能ファイルについては、コンポーネントがMITライセンスされていることを示すものも追加する必要があります。おそらくNOTICEファイルですか？ Maven Centralディストリビューションでは、アーティファクトが依存関係を宣言するだけで、実際にはそれらを含めないため、何もする必要はありません。 これは有効な計画のように思えますか？もしそうなら、誰でもポイント3を達成する方法をアドバイスできます。

19 java  licensing  mit-license  maven  apache-license 

ヘルプファイルの法的セクションを開いたときに、ポピュラーな音楽パッケージ（Ableton Live）を使用していましたが、プログラムには自由とビールの両方のように見えるコードライセンスが含まれていることがわかりました。残念ながら、オンラインコピーを見つけることはできませんが、必要な場合は、ライセンスパッケージを一覧表示できます。 私が見る限り、ここには3つの可能性があります： かなり大規模な会社がコードライセンスに違反している-非常にありそうもないが、もしそうであれば、なぜライセンステキストを含めるのか？ 実際には、何らかの理由で、オープンソースコードを含むパッケージにお金を請求し、ソースをクローズするのは合法です。これは間違いなく私にとってニュースです。 私は何かを誤解しています-非常に可能性が高い。

19 open-source  licensing  legal 

私の理解では、GPLは非GPLコードからGPLコードへの静的リンクを禁止していますが、非GPLコードからGPLコードへの動的リンクは許可しています。では、コードはインタプリタ言語（Perlなど）で記述されているため、問題のコードがまったくリンクされていないのはどちらですか？ 動的リンクと見なされた場合、ルールを活用するのは簡単すぎるように思えますが、一方で、静的と見なされた場合、非GPLコードからGPLコードを合法的に参照することも不可能と思われます！コンパイルされた言語は、少なくとも静的リンクと動的リンクを区別しますが、すべての「リンク」がスクリプトを実行しているだけの場合、明示的なライセンスなしでは意図が何であるかを伝えることは不可能です。 または、この問題に対する私の理解が間違っており、質問が議論の余地がありますか？動的リンクを含む「クラスパス例外」も聞いたことがあります。それはGPLの一部ではなく、代わりに追加できるものなので、動的リンクはライセンスにこの例外が含まれている場合にのみ許可されますか？

19 licensing  gpl  perl 

オープンソースとして最初にリリースされたプロジェクトをクローズドソースに戻すことは、どのようにして合法的に可能ですか？特に、GPLのすべてのバージョンでライセンスされているもの。

19 licensing  legal  closed-source 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 私は現在、オープンソースライセンスでリリースする予定の小さなプロジェクトに取り組んでいます（まだ決定していません）。私が抱えている疑問は、私が使用しているPythonモジュールの1つがGPLv3の下でライセンスされているということです。ライブラリに変更を加えていないので（そのまま使用）、選択したライセンスでプロジェクトのライセンスを取得できますか、それともGPLv3にする必要がありますか？

19 python  licensing  gpl 

ソフトウェアをフリーウェアとしてリリースしているのに、ソースコードをリリースしない人がいるのはなぜだろうか。何故ですか？いくつかの理由を考えることができますが、それらのほとんどはあまり意味がありません。なぜソースを閉じたまま、プログラムを自由に利用できるようにしたいのですか（無料で、無料のように無料ではありません）？

19 open-source  free-software  licensing  freeware 

たとえば、オープンソースイニシアチブの3条項BSDライセンスおよびMITライセンスのテンプレートには、全額保証免責事項が含まれていますが、ライセンスの残りの部分は通常の大文字で書かれています。 これには本当の理由がありますか？または、保証の免責事項を読みにくくするのは単なる伝統ですか？

19 licensing 

私は弁護士のSEサイトを見つけられなかったので、ここに投稿するのがベストだと思いました。 /* * ...subject to the following conditions: * * The above copyright notice and this permission notice shall be included in all * copies or substantial portions of the Software. * * The Software shall be used for Good, not Evil. * * THE SOFTWARE IS PROVIDED "AS IS"... …

19 licensing  open-source  ethics 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 新しい（DSP）アルゴリズムを作成したとします。コピーレフトライセンス（GPLなど）の下でアルゴリズムをオープンソース化すると、いくつかの利点がありますか？私がライセンスについて知っていることから、これはクローズドソースとまったく同じコードを使用することから人々を締め出すはずですが、彼らはアルゴリズムをクローズドソースとして「書き直す」ことができるでしょうか？ 注：アルゴリズムが新しいかどうかはわかりませんが、まだオープンソースとしてリリースされていません。私は欧州連合出身なので、コピーレフトしたい場合、ソフトウェア特許を探す必要がありますか？

18 algorithms  licensing  gpl 

choosealicense.comは、MITライセンスは「短く、要点を示す許容ライセンスです」と主張しています。これにより、人々はあなたのコードを適切な属性で保証なしで何でもすることができます。しかし、ライセンスを読んで、元の著者への帰属はどこにでもあるべきだと主張するものは見当たりません。

18 licensing  mit-license 

たとえば、GPLソフトウェアを使用しています。私はこのGPLソフトウェアの著者です。このGPLソフトウェアには、コード間にDoxygenコメントがあります。これらのDoxygenコメントは、CC-BY-SAライセンスの下でプロジェクトWebサイトにこの生成されたドキュメントをアップロードするために、CC-BY-SA htmlページを生成するために書かれています。 しかし、Doxygenのドキュメント出力は「派生物」ですか？結局のところ、このドキュメントは私のGPLソースコードに基づいています。この場合、ドキュメントはGPLでなければなりません。しかし、ドキュメントであるため、ドキュメントはCC-BY-SAである必要があります。GFDLは役に立ちません。GPLコードをGFDLにすることはできません（その逆）。 この出力が本当に派生的な作品である場合、奇妙な状況になると思います。作品を配布する場合、受信者のユーザーは生成されたドキュメントを合法的に配布できないためです。 t、したがって、彼らは私が提供する同じライセンスで派生作品を配布する必要があります。 解決策は何ですか？

18 licensing  gpl  creative-commons 

MITオープンソースライセンスの基本的な違いは何ですか： これにより、このソフトウェアおよび関連ドキュメントファイル（「ソフトウェア」）のコピーを取得するすべての人に、使用、コピー、変更、マージの権利を含むがこれらに限定されないソフトウェアを許可する許可が無料で付与されます。ソフトウェアのコピーを発行、配布、サブライセンス、および/または販売し、以下の条件に従って、ソフトウェアの提供先にソフトウェアの提供を許可します。 上記の著作権表示およびこの許可通知は、ソフトウェアのすべてのコピーまたは大部分に含まれるものとします。 本ソフトウェアは、商品性、特定の目的への適合性、および非侵害の保証を含むが、これに限らず、明示または黙示を問わず、いかなる保証もなしに「現状のまま」提供されます。いかなる場合でも、作者または著作権者は、契約、不法行為、またはその他の行為、ソフトウェアまたは使用またはその他の取引に起因する、または関連するいかなる請求、損害またはその他の責任についても責任を負わないものとしますソフトウェア。 およびBoostオープンソースライセンス： これにより、ソフトウェアの使用、複製、表示、配布、実行、および送信を行うために、このライセンス（「ソフトウェア」）の対象となるソフトウェアおよび付属文書のコピーを取得する個人または組織に許可が無料で付与されます。ソフトウェアの二次的著作物を準備し、ソフトウェアの提供先であるサードパーティにそのようにすることを許可すること。 ソフトウェアの著作権表示および上記のライセンス交付、この制限および以下の免責事項を含むこの声明全体は、ソフトウェアのすべてまたはすべてのコピー、およびソフトウェアのすべての派生物に含まれなければなりません。コピーまたは二次的著作物は、ソース言語プロセッサによって生成されたマシン実行可能オブジェクトコードの形式のみです。 本ソフトウェアは、商品性、特定の目的への適合性、権利、および権利の非侵害の保証を含むがこれに限らず、明示または黙示を問わず、いかなる種類の保証もなしに「現状のまま」提供されます。いかなる場合においても、著作権者またはソフトウェアを配布する人は、契約、不法行為、その他のいずれにおいても、ソフトウェアまたはソフトウェアの使用または他の取引に起因または関連する責任を負わないものとします。 「この著作権表示を保持する」ビットの例外を受け入れます。

18 licensing  mit-license 

既存のソフトウェアパッケージを別の言語に移植するというアイデアを模索しています。Apache License 2.0の下でリリースされており、無料で配布されています。ただし、ライブラリの使用とそのコピーの作成には大きな違いがあります。もちろん、私は完全な信用を与えて、それがどこから来たのかについて正直に言うでしょう。そして、私は確かにポートからお金を稼ぐつもりはなく、他のプロジェクトでそれを使うだけです。 もちろん、私はライセンスを読みました。 著作権ライセンスの付与。このライセンスの条件に従い、各コントリビューターは、派生的作品の複製、準備、公開、公演、サブライセンス、および著作物およびそのような派生著作物をソースまたはオブジェクト形式で配布します。 [...] 再配布。次の条件を満たす場合は、改変の有無にかかわらず、ソースまたはオブジェクトの形式で、作品またはその派生作品のコピーを複製および配布できます。 a。作品または派生作品のその他の受領者には、このライセンスのコピーを提供する必要があります。そして b。あなたは、変更されたファイルに、あなたがファイルを変更したことを示す顕著な通知を表示させる必要があります。そして c。配布する派生著作物のソース形式で、派生著作物のいかなる部分にも関係しない通知を除く、著作物のソース形式からのすべての著作権、特許、商標、および帰属通知を保持する必要があります。そして d。作品に配布の一部として「NOTICE」テキストファイルが含まれている場合、配布する派生作品には、そのようなNOTICEファイルに含まれる帰属通知の読み取り可能なコピーを含める必要があります[...] 修正に独自の著作権表示を追加することができ、修正の使用、複製、または配布のための追加または異なるライセンス条項を提供することができます。それ以外の場合、作品は本ライセンスに記載されている条件に準拠します。 私は、ライセンス、既存の著作権表示、帰属などのコピーを熱心に保持している限り、ポート（「派生著作物」として）は著者の許可の有無にかかわらず完全に許可されます。 しかし、だからといって、その意味をすべて理解しているわけではありません。たとえば、ポートは必ず元のライセンスと同じライセンスを共有する必要がありますか？ 私はまだ作業を開始していませんし、パッケージの作者とはまだ連絡していません（ただしそうします）。多くの作業が無駄になるリスクがあるかどうかを確認したいと思います。また、APIのみに基づいてクリーンルーム実装を作成する必要があるかどうか、または既存のソースコード（まだ見ていない）に基づいて作業を行うことができるかどうかを知る必要もあります。

17 licensing  apache-license  porting 

サードパーティのコードにいくつかの微調整や修正を加えるのが一般的な方法です（単純な要点でも、ライブラリ全体でも）。しかし、これらのコードの多くには独自のライセンスルールがあり、最終的には著作権情報を含むすべてのファイルにヘッダーが付いていることもよくあります。 これらの変更を行った後、次に行うべきことは何ですか？ライセンス情報を変更できないようにする@authorか、自分自身や@revisionタグなどで更新しようとしますか？ もう1つの一般的な問題は、サードパーティの名前空間/パッケージをプロジェクトの規則に合わせて変更することです。一部のライセンスタイプでは、ライセンスブロックにこの種の情報が含まれていますが、自由に変更できますか？ 私はこれらの質問に対する答えが各ライセンスの種類に依存することを知っているので、私の質問をより具体的にするため... 一般的なライセンスルールを考慮すると（通常、それらはマイナーな側面で異なりますよね？）、倫理上の（または少なくとも許可されている）私の変更に関する情報をライセンスブロックに自由に追加し、おそらくコードでそれを参照する方法も変更します（例：YACorp.YALibとして使用Utils.YALib）？

17 licensing  language-agnostic