【License】ライセンス総合【利用許諾】 (836ﾚｽ)
上下前次1-新
747: 2018/07/03(火)01:32 ID:PWcH5OG4(2/2) AAS
黙って使ってもバレなさそうな気がしたから念のため聞いてみたけど
ライセンス文読めって言えばそれはそうだよな
こたえてくれてありがとう
748: 2018/07/04(水)21:52 ID:gFgZc5FG(1) AAS
Z8I
749: 2018/07/05(木)16:26 ID:AeL6VB/V(1) AAS
Z8I
750: [age] 2018/07/16(月)15:52 ID:PbI2boh/(1/2) AAS
ブラウザから見えるJavaScriptのライブラリで、
使用したいコードがMITライセンスなのですが、使いたい部分は全体の10％で、
コードの90％は不要なので削りたいです。
MITはコピーレフトNOで、コピーレフトの要件はwikipediaによると、
＞ 著作物の利用、コピー、再配布、翻案を制限しない
＞ 改変したもの（二次的著作物）の再配布を制限しない
＞ 二次的著作物の利用、コピー、再配布、翻案を制限してはならない
＞ コピー、再配布の際には、その後の利用と翻案に制限が無いよう、全ての情報を含める必要がある（ソフトウェアではソースコード含む）
＞ 翻案が制限されない反面、原著作物の二次的著作物にも同一のコピーレフトのライセンスを適用し、これを明記しなければならない
であり、上記の要件をすべて否定すると改変も出来ないことになりますが、
MITがコピーレフトでないのは、
＞ 二次的著作物へのライセンス適用や、使用可能なソースコードのコピーを義務づけていないため、コピーレフトではない
からであって、コードを削るなどの改変については制限されていないという解釈で良いのでしょうか？
また削った場合の作者はオリジナルの作者のままでいいのでしょうか？
もし不具合があってそちらに連絡がいくのも困るので、
併記してmodified by meのようなことを書けばいいのでしょうか？
別に元のプログラムに問題があるわけではないので、modifiedの部分が適切かはわかりませんが。
751(1): 2018/07/16(月)22:10 ID:wWxntUKE(1) AAS
コピーレフトなんて横道逸れる前にMITライセンスを読め
752: 2018/07/16(月)23:15 ID:PbI2boh/(2/2) AAS
>>751
では質問を変えます。
改変したコードのライセンス表記はどのようにしたらいいのでしょうか？
753: 2018/07/17(火)18:14 ID:XyGXHE5O(1) AAS
ライセンス文書は丸ごとそのまま引き継ぐ
混ざって訳わからなくならんようにそれと区別して改変云々を書いておく
754: 2018/10/17(水)15:11 ID:09vqJ2WQ(1) AAS
Apache License, Version 2.0って、Twitterみたいに
アプリのヘルプとかでずらっと箇条書きにしてあればいいのかな？
別途LICENSE.txtや取説にも書く必要ってある？
755: 2018/10/28(日)12:50 ID:qLO82WYC(1) AAS
外部ﾘﾝｸ:github.com
The icon "beasts-48.png" is taken from Aha-Soft’s Free Retina iconset, and used
under the terms of its license (外部ﾘﾝｸ:www.aha-soft.com
with a link back to the website: 外部ﾘﾝｸ:www.aha-soft.com
aha-softのURLが開かないんだがbeasts-48.pngを再配布に使っていいのか？
756(4): 2018/11/09(金)22:00 ID:IlEU8oxs(1) AAS
GPLについて、以下使用パターンでググっていろいろ読んだ結果の解釈、合ってるか教えてほしい。
・素性不明だが、libgccみたいなライブラリのソースの一部を改変・流用
・当該ソースには「GPLランタイムライブラリ例外」の記載
・非GCC、プロプライエタリなコンパイラ利用
・商用利用
・バイナリはエンドユーザーまで配布(販売)
この場合、次の処置が必要という認識でいい？
・ReadmeにGPLソフトを利用している旨とライセンス条件ファイルを添付
・流用ならびに改変したソースを添付するか、要求があれば送付する旨の書面を添付
・ランタイムライブラリ例外が適用されるので、当該ファイル以外は公開不要
商用なので正確には法務担当に確認すべきなのは分かってるが、
前任から引き継いだらこんなことになっていた。
リリースまで余裕はあるので上に報告するための話を考える情報にしたい。
757(2): 2018/11/10(土)03:47 ID:KUkgOOuF(1/3) AAS
問題ありそうね
条件を読む限り、一部のソースを流用してランタイムライブラリの形ではなくプログラムに直接組み込んでいると思う
それでは製品プログラムは独立モジュール（Independent Module）とはみなされないはず
外部ﾘﾝｸ[html]:www.gnu.org
に『GCCライブラリからなんのソースも含まない限り、それぞれのファイルは「独立モジュール」です』と書いてある
ランタイムライブラリ例外は独立モジュールが
ランタイムライブラリの形でのGPLソフトウェアを利用している場合に対しての許可なので
独立モジュールじゃなければ、例外に該当しない
プログラム全体がGPLになるはず
758: ◆QZaw55cn4c 2018/11/10(土)13:53 ID:gF+s2COR(1) AAS
スタティックライブラリかシェアードライブラリかで該非がかわるのですか？
759(1): 756 2018/11/10(土)15:21 ID:yu0Mb9WU(1) AAS
>>757
ご指摘のとおり、ライブラリから切り離したであろう.c/.hをプロジェクトに組み込んで使っています。
この形だともはや「ランタイムライブラリ」じゃないという解釈ですね。
つまり、今回のパターンをクリアにするなら例えば
・libgccから不要な機能を削除したスタティックリンクライブラリlibgcc_dietを作成し
・開発中のソフトウェア(独立モジュール)からlibgcc_diestをリンクする
とすればランタイムライブラリ例外が適用できる可能性がある、ということでしょうか。
当然、libgcc_dietはGPLに従いソース含めて公開することを前提とします。
760: 2018/11/10(土)15:42 ID:KUkgOOuF(2/3) AAS
いや、
LGPLの話ではないのでスタティックかシェアードかは関係ない
（FAQにも静的リンク、動的リンクであってもランタイムライブラリ例外は利用可能とある）
外部ﾘﾝｸ[html]:www.gnu.org
に独立モジュール（Independent Module）という用語が定義されている
> A file is an "Independent Module" if it either requires the Runtime Library for execution after a Compilation Process, or makes use of an interface provided by the Runtime Library, but is not otherwise based on the Runtime Library.
Google翻訳
> ファイルは、コンパイル・プロセスの後に実行するためにランタイム・ライブラリを必要とするか、またはランタイム・ライブラリによって提供されるインタフェースを使用するが、そうでなければランタイム・ライブラリに基づいていない場合、「独立モジュール」である。
ランタイムライブラリ例外の対象はランタイムライブラリと独立モジュールを組み合わせて作られたターゲットコードへの許可のみ
独立モジュールはコンパイル後だけランタイムライブラリを使う（リンクする）か、
ランタイムライブラリのインターフェースを使用するか、
ランタイムライブラリと一切関係ないかのどれかである必要がある
（いずれの場合も独立モジュールのソースコードにGPLのソースは直接流用されてはいない）
761(4): 2018/11/10(土)16:08 ID:KUkgOOuF(3/3) AAS
うお、レス書いてたら間に挟まった
>>759
ランタイムライブラリ例外が導入された経緯を考えると、
ランタイムライブラリがGPLなので、GCCで作った実行ファイルもGPLになるというのを回避するためだけのはず
libgcc_diet の案は一見よさそうに見えるが、
プロプライエタリからの利用を極端に嫌うFSFが
ランタイムライブラリ例外付きGPLのコードを、GPL迂回のための抜け道となるように作るとは思えない
例えば、libgcc_diet がランタイムライブラリを名乗れるのかがちょっと分からない
ランタイムライブラリは著作権者がファイルにランタイムライブラリ例外付きとしてライセンスする必要があるが、
著作権者ではない改変者が libgcc_diet をランタイムライブラリ例外付きGPLでリリースできるのかあたりがとても怪しい
762(1): 756 2018/11/10(土)18:42 ID:Hrms6Af2(1) AAS
>>761
>著作権者ではない改変者が libgcc_diet をランタイムライブラリ例外付きGPLでリリースできるのかあたりがとても怪しい
なるほど。この点は要確認ですね。
ちなみに使っているのは、アーキテクチャ依存のスタートアップコードとCPU固有命令をCからコールするためのインライン化コード。
ちょっと特殊なCPUなので代替コードはなさそう。
多分一から書ける人はほとんど居ないので詰んだ感がする。
763: 761 2018/11/11(日)11:48 ID:EA8uP50L(1) AAS
>>762
スタートアップコードとCPU固有命令のCラッパー部分なら、
756 の libgcc_diet の方法で作った場合、
757 で指摘した『製品プログラムは独立モジュールとはみなされない』
という指摘は当てはまらないね
（libgcc_diet のコンパイルと製品プログラムのコンパイルを別にして、後からリンクするだけ）
ただし依然としてランタイムライブラリ例外付きGPLで libgcc_diet をリリースできるかは不透明
764: 2018/11/12(月)14:18 ID:uNoTWhhe(1/2) AAS
横から失礼
むしろ改変して、例外を適用出来るの？
765: 2018/11/12(月)16:22 ID:uNoTWhhe(2/2) AAS
>>756をまとめると、
「GPLライブラリを改変して、LGPLとして使いたい」
ってことになってしまうのかな？
766: 761 2018/11/12(月)16:28 ID:J2E4eo6X(1/2) AAS
GPLのソースコードを改変したコードだったり、
GPLのソースコードと自分のソースコードを混ぜてコンパイルしたら、
757 で言ったとおり「独立モジュール」にならないので例外を適用できないよ
リンク段階なら適用できる
767: 2018/11/12(月)21:17 ID:Ff8BWBdH(1/2) AAS
書き方の問題だと思うけど、GPL+リンク例外のコードを改変したものを同じGPL+リンク例外で
リリースする分には問題ない。もちろん純粋なGPLのコードからはダメだが。
768: 2018/11/12(月)22:46 ID:J2E4eo6X(2/2) AAS
ランタイムライブラリ例外で追加された許可は、
「独立コードであればランタイムライブラリのGPL違反とはならない」という一つのみなので、
派生コードをランタイムライブラリ例外付きGPLでリリースすることは許可されていない
という可能性がありそうに見えます
（ただのGPLなら可）
（どのライセンスもそうだけど）ランタイムライブラリ例外付きGPLにするには著作権者全員の同意が必要で、
libgcc_diet の著作権者として libgcc の著作権者が含まれる訳だけど、
libgcc_diet をランタイムライブラリ例外にするには libgcc の著作権者の同意が必要なんじゃないかと
自分が見落としてるGPLの条項とか、GNUやFSFの見解とかあれば教えてください
769: 2018/11/12(月)23:22 ID:Ff8BWBdH(2/2) AAS
GPL系のライセンスでは複製物/派生物は基本的に元のライセンスと同じライセンスで配布することを要求する。
LGPLなどリンク例外付きのものはGPLを選択してもよいというオプションが追加されているだけ。
>（どのライセンスもそうだけど）ランタイムライブラリ例外付きGPLにするには著作権者全員の同意が必要で、
それを同意するのがまさにライセンス条項なわけで。
770: 756 2018/11/13(火)00:45 ID:pJjYkbMl(1) AAS
休日で見れない間に進んでた。
・GPLライブラリ例外となっているライブラリ内のソース抜き出し利用
→ライブラリ例外適用不可
・GPLライブラリ例外のライブラリを変更し、ソース公開しつつそのライブラリにリンク
→ライブラリ例外適用可
ということだと解釈した。
今日さらに調査をした結果分かったこと。
最初のレスで「libgccみたいなライブラリのソースの一部」と書いたが、コレはどうもコンパイラに付属しているCランタイムライブラリのようだ。
ライブラリ全体はlibgccをベースに、アーキテクチャ向け変更を入れ込んでソースごと公開されている。
LICENSEにはランタイムライブラリ例外の旨も付いていた。
これを見ると上で議論のある「GPLランタイム例外が適用されているライブラリを改変し、同じライセンス形態のまま公開」が成立しているように見える。
有料で売ってるコンパイラなのでそこはメーカが問題無いと判断した上で販売していると認識したが、果たして。
というか、この理論が成立しないとlibgccをさまざまなCPU向けに作り変えてもライブラリ例外が適用できなくなってしまうが、そういうものなのだろうか。
771: 761 2018/11/13(火)01:19 ID:MDYcKLdV(1) AAS
ふー、GPLv3内の該当の条項を探した
7. Additional Terms.
より、適当抜粋
・追加条項はGPLv3のライセンス本体に含めるとあった
・ランタイムライブラリ例外のような許可の追加条項（Additional permissions）は引き継いでも破棄してもいい様子
・許可の追加条項の条項に記載することで、例えば改変された場合に追加条項の削除もできる
・非許可の追加条項は許されていない
GCCランタイムライブラリ例外の条項には改変時の追加条項の削除の条項は見当たらないので、
ランタイムライブラリ例外付きGPLは、ソースをランタイムライブラリ例外付きGPLとしてリリースできるっぽい
まじか……
ランタイムライブラリ例外付きGPLは、シェアードライブラリにする必要がないからLGPLより緩いのか
772: 2018/11/14(水)13:49 ID:zV35UnwU(1) AAS
FSFの文章読んでると
「今後はAGPLv3に統合してく、特例としてLGPLは作ったが出来ればGPLv3にしろ。
なお他のライセンスは一切使うな。」
って感じだけどなぁ
773: 2018/11/22(木)15:34 ID:E6QgRurq(1) AAS
Apache License 2.0の最後に定型文があって「添付してください」って書いてあるけども、
これってAppendixだから「適用する時の例」であって、
「絶対にこの書き方をしなければならない」って意味では無いですよね？
774: 2018/11/27(火)00:37 ID:UTcZY4wX(1) AAS
いつの間にかWineがLGPLになっているけど、これを使ってリバースエンジニアリング禁止のプロプラアプリを動かしたらライセンス違反になっちゃうんじゃないの？
775: 2018/11/27(火)09:14 ID:xYQjSs88(1) AAS
動かすだけなら問題無いんじゃ？
776: 2018/11/27(火)18:20 ID:DvtoPeYG(1) AAS
どういう理屈？
アプリAがLGPLのライブラリBを呼んだらアプリAはリバースエンジニアリングを禁止できないだろ
Wineの場合ライブラリBがWineになるんだからアプリAがリバースエンジニアリングを禁止している場合は
ライセンス違反になっちゃうんじゃないの？
上下前次1-新書関写板覧索設栞歴
あと 60 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.016s