【License】ライセンス総合【利用許諾】

**デフォルトの名無しさん** · 2010/02/16(火) 00:24:21

. ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
｜　ライセンスについての質問・批評・情報提供その他用スレなのれす♪
' ＼＿＿＿　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　Ｖ
∋oノハヽo∈
　 (　´ⅴ｀)ノ

**デフォルトの名無しさん** · 2016/11/03(木) 13:59:30.98

>>679
作品を製造する過程と、作品そのものは分けて考えるべき。
死刑囚の手記は合法的に売れる。

他人のコードや著作物を勝手に作品に埋め込むようなツールならば
作品が著作権侵害あるいは特許侵害で訴えられる可能性はある。

割れphotoshopで絵を描いたからと言って、
単純に丸いだけのペンだけ使ってフリーハンドで描いたのであれば、
その絵自体は問題にならないだろう。（不正使用の点に関しては追及されるだろうが）。
複雑な形状のペン使ったとか、フォント使ったとか、素材使ったとかであれば、絵そのものにも影響が及ぶ。
つまり、著作権違反の可能性が出てくる。
裁判結果は書き込みの量と弁護士の腕次第。

**デフォルトの名無しさん** · 2016/11/03(木) 16:24:47.03

>>680
上で書いたコピペみたいな
データが混入しないと思われる単純なものなら問題なさそうな感じか

>複雑な形状のペン使ったとか、フォント使ったとか、素材使ったとか
確かに他人の著作権が明確なものが含まれてたら不味そうだ

レスthx
割れは兎も角OSSは自己責任とはいえリスクが怖いな

**デフォルトの名無しさん** · 2016/11/03(木) 18:54:45.84

OSSでは倫理観で善悪の判断をするが法律では白黒つけない
もし訴訟という事態になっても和解で決着するのを最善とする

何故ならOSSの倫理観と裁判所の判決が同じとは限らないからである
裁判官の心証とか弁護士の腕などという不確かなものに依存して
倫理観を覆すような結果になったときの不利益は計りしれない

**デフォルトの名無しさん** · 2016/11/03(木) 22:10:12.00

>>681
たとえ正規でもツールや素材のライセンスを十分に理解して使ってる奴は少ない。
素材集で言えば、個人が年賀状に書く用とか、ウェブサイトに掲載できるもの、業者が雑誌とかで使う用とかではライセンスが全然違う。
特にWindowsでデフォルトで入ってるフォント等は罠がいっぱいだ。
例えばMSゴシックは本来画面で見ることしか想定されてないライセンスだ。
印刷して配布したりするとなると途端に怪しくなる。

**デフォルトの名無しさん** · 2016/11/04(金) 11:02:18.54

>>683
黙認というかグレーというか
そういのも結構あるんだろうね

そこら辺のライセンスを考え始めたら
かなり分かり難いのもあるから雁字搦めになる気もするし

ただmsもmacみたいに一元管理になればと思う

**デフォルトの名無しさん** · 2016/11/10(木) 08:36:21.62

LGPLのリバースエンジニアリング条項について質問です。

ライブラリA (LGPL v3)
dynamic link
ライブラリB (MIT)
dynamic link
製品C (プロプラ)

この場合にリバースエンジニアリング条項が機能するのはBまでであってますか？

**デフォルトの名無しさん** · 2016/11/10(木) 22:54:08.13

>>685
プラグインなどのように自由に差し込めるものではなくて、
リバースエンジニアリング条項が有効になるようながっつりしたライブラリ利用をした場合、
ライブラリBをMITやパブリックドメインでリリースすることが不可能だろう。
ライブラリBの利用者にライブラリBを自由に使う権利（リバースエンジニアリングを禁止してリリースしたりとか）を与えることができないわけだから。

**デフォルトの名無しさん** · 2016/11/11(金) 01:12:47.74

>>686
ありがとうございました
ということは、そもそもBの時点でおかしい可能性があるんですね
BはAを利用しているだけで二次著作物ではないという主張が通るならMITで問題ないし、リバースエンジニアリング条項も関係なくなる
そうではないなら、Bはリバースエンジニアリングを許す条項を持った独自ライセンスが必要になる

どちらにしても製品Cまで波及することはなさそうです

**デフォルトの名無しさん** · 2016/11/11(金) 09:25:17.34

CがBの二次著作物であると判定される場合、Cにもリバースエンジニアリング条項が適用されるかもね。

**デフォルトの名無しさん** · 2016/11/13(日) 09:07:23.50

私も似たようなことで悩んでいるが

ffmpeg(コンパイルオプションでLGPL2.1+)
　↓　dynamic link
FFmpegInterop library for Windows MS製(Apache2.0)
　↓　dynamic link
自分のプログラム

なんだが、MSだけに無謀なことやっていないだろうからApacheライセンスとして扱って良いんですかね？

**デフォルトの名無しさん** · 2016/11/13(日) 22:59:03.02

>>689
動的リンク以前の問題として、ソースで配布するのとバイナリで配布するのでは条件が変わってくる。
ソースコードによる配布の場合、GPLやLGPLを含もうと自作プログラムが影響を受けることは無い。
FFmpegInteropとやらがソースをapache2.0で配布するのは自由。
ただしlgplのバイナリとリンクしたバイナリを配布するのであればlgplの影響を受ける。

**デフォルトの名無しさん** · 2016/11/16(水) 08:20:40.24

>>689
問題ない
難癖つけられるのを避けたいなら、
このプログラムを実行するにはMSのffmeginteropが必要です、
ライブラリ入手先はこちらです(URL)

とか書いて、自分のプログラムはMSの製品を利用してるだけですよのスタンスを明確にする

**デフォルトの名無しさん** · 2016/11/18(金) 20:24:21.03

>>690
>>691
レスありがとうございます。PCがトラブって返事が遅くなったのをお詫びします
まあライセンスはなかなか難しいものですね
まあリバース・エンジニアリングするより新規で作ったほうが安上がりになる程度のものだから
気にせずにリバースエンジニアリングには特別触れないってことでお茶を濁しますか

**デフォルトの名無しさん** · 2017/04/09(日) 07:37:24.91

forkや移植ではなく
同じ挙動をするプログラムをゼロからコード書き上げて(フルスクラッチ？)公開のってライセンス的にアウト？

例えばlinuxのテキストファイル表示するcatと同じ挙動するプログラム(コマンドライン引数の受け取り方も同じにして)を作って公開するとか

**デフォルトの名無しさん** · 2017/04/09(日) 13:24:50.29

>>693
ライセンスに適合するように公開すれば、ライセンス的には問題ない。
ただライブラリも使わずフルスクラッチで作ったのなら、他のライセンスに関わる要素はないように思う

**デフォルトの名無しさん** · 2017/04/09(日) 13:58:44.25

クリーンルームで作り上げたのならおｋ

**デフォルトの名無しさん** · 2017/04/09(日) 18:45:48.88

>>694-695
ありが㌧

**デフォルトの名無しさん** · 2017/04/09(日) 19:45:02.38

>>696
念のため補足するよ
ソフトウエアライセンスは、自分が作ったものをどう使ってよいか他人に許諾するもの。
他人が作ったものを含まないのであれば、そもそもライセンスが含まれない。

**デフォルトの名無しさん** · 2017/04/09(日) 20:31:04.60

>>693
「同じ挙動」っていうのが
画面のデザインや素材を含んでる場合著作権が怪しくなる。
特許を侵害する場合は特許権が怪しくなる。

あと、基にしたプログラムが商品として販売されている場合、
不正競争防止法によって差し止められる可能性もあるだろう。

**デフォルトの名無しさん** · 2017/04/24(月) 23:28:54.50

APIの利用ってAPI提供側のライセンスの影響受けたりする？

↓マストドンってAGPLだからAPI利用もAGPLにしないとダメ？

documentation/API.md at master ・ tootsuite/documentation ・ GitHub
https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

**デフォルトの名無しさん** · 2017/04/25(火) 09:54:50.95

日本においてはAPIそのものは著作物ではないとされている

**デフォルトの名無しさん** · 2017/04/25(火) 22:53:37.89

じゃあ静的リンクも動的リンクもAPI使うだけだからGPL無視しても問題ないっすね

**デフォルトの名無しさん** · 2017/04/26(水) 09:11:53.60

>>699-700
その「マストドンのAPI」はネット越しのRESTだから、
マストドン側はクライアントにソースコードを提供する義務があるが、
クライアント側はどこの国だろうとAGPLによる義務はないよ。

**デフォルトの名無しさん** · 2017/04/30(日) 15:15:51.67

mcppはBSD 3-clause licenseで、GNU binutilsはGPLのようですが、
mcppとGNU binutilsのwindresを自分のプログラムRisouEditorに組み込んで使用したい場合、
RisouEditorのライセンスはどのようにすればいいでしょうか。よろしくお願いいたします。

mcpp http://mcpp.sourceforge.net/
GNU binutils https://www.gnu.org/software/binutils/

**デフォルトの名無しさん** · 2017/04/30(日) 15:16:39.50

バイナリーとしてバンドルする予定です。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/04/30(日) 15:41:38.62

GNU binutilsはGPLv2のようです。

**デフォルトの名無しさん** · 2017/04/30(日) 16:05:18.32

なんだクソコテかよ
どうでもいいがGPLv2のGNU binutilsはかなり古そう

**デフォルトの名無しさん** · 2017/04/30(日) 20:30:22.31

>>703
RisouEditorのライセンスをどうしたいのかによる。
GPLが理想と考えているならGPLにすればよい。

MIT/BSDライセンスが理想ならwindresバンドルは避けるべきだ。
リンクしなければRisouEditor本体はGPLにしなくてもよいけど、
windresをバンドルすると結局ユーザーがGPLに振り回される。

iResEditorというJavaScriptで書かれたリソースエディタがある。
MITライセンスなのでこれを参考にしてwindresクローンを作れば
RisouEditorをGPLフリーにできる。

iResEditor
http://www.petitmonte.com/labo/iResEditor/
Win32 Binary Resource Formats
http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc/resfmt.txt

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/04/30(日) 21:14:14.14

>>707
ありがとうございます。

**片山博文MZ** ◆T6xkBnTXz7B0 · 2017/04/30(日) 21:20:41.45

マクロ定義を出力できるプリプロセッサがGPL以外でないんだな。

**デフォルトの名無しさん** · 2017/05/03(水) 18:56:59.87

>>699

API - AGPLライセンスのライブラリを組み込んだメインプログラムと、API通信でメインプログラムと通信するフロントプログラムを作り、エンドユーザがフロントプログラムにのみアクセスできる場合のライセンスの範囲(14716)｜teratail
https://teratail.com/questions/14716

**デフォルトの名無しさん** · 2017/05/07(日) 13:52:01.58

あるA氏が書いた MITライセンスの Cライブラリを元に、
B(私)が C#に書き換えて CC0でリリースしようと思っています
(A氏のMITライセンスについて書かれた LICENSE.txt を添付)

C氏がC#のライブラリを使用する場合も、A氏の LICENSE.txt を添付する
必要があるという認識ですが合っているでしょうか？
（つまり、B(私)のCC0ライセンスというのは C氏にとっては意味がなく、
C#ライブラリは A氏の MITライセンスと同等）

この場合、GitHub でプロジェクト登録する際には MITライセンス扱いにするべきでしょうか？
（リポジトリ作成時の一覧には CC0 がなかった）

**デフォルトの名無しさん** · 2017/05/08(月) 23:30:15.37

移植におけるライセンス問題については俺も気になってはいる(が結局どうすればいいのかの知見がないな)

GPLライセンスについての質問です。 GPLで公開されているソフト… - 人力検索はてな
http://q.hatena.ne.jp/1159847609

GPL適用のソースコードを他言語に移植してBSDライセンスに変更できるか | オープンソース・ライセンスの談話室
http://www.catch.jp/oss-license/2011/11/19/gpl2bsd/

licensing - License terms when porting free software to another language - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/278094/license-terms-when-porting-free-software-to-another-language

legal - When porting code, must I follow the original license? - Software Engineering Stack Exchange
https://softwareengineering.stackexchange.com/questions/58338/when-porting-code-must-i-follow-the-original-license

Code ported from one to another language - licensing - Stack Overflow
http://stackoverflow.com/questions/10952689/code-ported-from-one-to-another-language-licensing

**デフォルトの名無しさん** · 2017/05/09(火) 01:46:52.98

ソースコードを流用するなら翻訳扱いで著作権の対象

ソースコードを見るだけならリバースエンジニアリング扱いで
著作権的には問題ない（アイディアとアルゴリズムには著作権はない）

って感じかな？

元のMITライセンスのライブラリのCコードを書き換えていく形で移植するつもりなので、
B(私)がCC0にしても、C氏からはMITライセンスのままってことになりそうですね
(あれ？ MITライセンスが感染してる？)

MITライセンスの先頭に
Copyright <YEAR> <COPYRIGHT HOLDER>
があるんだけど、これもそのままにしなきゃいけないんだよなー
(A氏の名前でC#ライブラリの著作権宣言するのか……バグ報告とか行きそうだなー)

**デフォルトの名無しさん** · 2017/05/12(金) 01:31:01.36

ライセンス明示してるのは、コードを利用するのに利用許可を取るための連絡相談しなくていいよ、的なモノだから

元コードの人に別途にMITライセンスではない移植の許可を貰えばいいんじゃねーの？

**デフォルトの名無しさん** · 2017/05/12(金) 08:28:53.92

>>711-713

>>533-539 あたりの話をカブってるんじゃね？

**デフォルトの名無しさん** · 2017/06/04(日) 18:45:00.72

著作権放棄は日本ではできないという話を聞いたけど

**デフォルトの名無しさん** · 2017/06/06(火) 02:41:12.32

規定がないから放棄自体はできないけど
権利を行使しないことで実質放棄になる

**デフォルトの名無しさん** · 2017/06/15(木) 11:51:27.75

>>717
権利を行使しないと最初に言っておきながらやっぱ行使しまーすってのはNG？

NGなら実質放棄とみなせるんだが

**デフォルトの名無しさん** · 2017/06/18(日) 14:53:01.36

>>718
普通は「権利を行使しません」っていう契約書にサインする。
で、やっぱり権利を行使しますとなったらその時点で契約は取り消しとか終了とかそんな感じになる。
契約内容によっては損害賠償を請求されるかもしれない。

**デフォルトの名無しさん** · 2017/08/23(水) 12:47:24.42

Facebookの特許条項付きBSDライセンスが炎上している件について
https://note.mu/konpyu/n/nc0d2f49676ba
Facebook、React.jsのライセンスを維持 - Apacheとの衝突を回避せず
http://news.mynavi.jp/news/2017/08/22/050/
Facebook、Reactの「真のオープンソース化」を拒否
https://it.srad.jp/story/17/08/22/0727207/

> FacebookのライセンスはBSDに独自の特許条項が付いたもので、
> 今回はこの特許条項が問題になった。
> 「Facebook及びFacebookの関連会社を特許で訴訟した場合、
> ライセンスは破棄され、Facebookのコードを使う権利を失う」というものだ。

React逝ったー！？

**デフォルトの名無しさん** · 2017/09/23(土) 08:14:38.29

フリーソフトで音声ファイルのエンコードやデコードをしたいんだけど
コーデックよってはロイヤリティが発生するものがあるんだよね？
商用/非商用の場合は以下の解釈で合ってる？

mp3　→　LAMEならOK？
ogg　→　OK
aac　→　非商用ならOK
m4a　→　OK？
flac　→　OK
wav　→　OK？

**デフォルトの名無しさん** · 2017/09/30(土) 17:49:02.34

mp3ってちょっと前に特許きれなかったっけ？

**デフォルトの名無しさん** · 2017/12/30(土) 22:43:45.33

GPLって自分にも効力及ぶの？
自分で書いたライブラリ(A)をGPLで公開
その後(A)を使った自分で書いたアプリ(B)を公開、配布する場合とかだと(B)もGPLじゃないといけない？

**デフォルトの名無しさん** · 2017/12/30(土) 22:53:52.32

>>723
当然だよ、GPL で後悔したものはずっと後悔（改造の自由を与える余地に配慮）しなければならない

**デフォルトの名無しさん** · 2017/12/30(土) 23:01:02.32

GPLのなかに「著作権者の特権」なんて項目は無いからな

**デフォルトの名無しさん** · 2017/12/30(土) 23:01:47.32

(A)の著作権が100%自分にあるならGPL以外のライセンスで配布するのも自由。
そもそもライセンスというのは利用を許諾してもらう条件なわけで、権利者本人が縛られる必要はない。

**デフォルトの名無しさん** · 2017/12/30(土) 23:23:11.37

著作権者全員の同意が取れる場合も (B) は GPL じゃなくていい
また、(A) 自身も著作権者全員の同意が取れる場合、GPL 以外のライセンスにすることができる
実際 GPL から BSD ライセンスに変更したプロジェクトもいくつかある
ただし、(A) を一回でも外部の人に見せた（ライセンス契約・許諾した）場合、
該当するバージョンの (A) は GPL としてしばらく公開しておく必要はある

**デフォルトの名無しさん** · 2017/12/30(土) 23:29:30.42

GPLに公開の義務は無い

**デフォルトの名無しさん** · 2017/12/30(土) 23:50:00.22

バイナリ配布を停止してもしばらくはソースを受け取れることを保証しなければならないという話かな。
ただ実際のところ、配布者=権利者の場合はそれが守られなくても他人はどうすることもできない。
あとそもそも、ソース同梱での配布なら即時停止も可、ってのがFSFのガイドラインだったと思う。

**デフォルトの名無しさん** · 2017/12/31(日) 22:15:38.40

GPLで配布してしまった後は、出回ったGPLなソフトをGPL以外に変更する術はないし再配布も拒否できないということじゃない？
配布終了に関しては禁止することは無理だろうし
それとは独立して、完全自作であれば同じソフトの非GPL版を自分で設定して、そっちを利用したソフトBのライセンスは非GPL版のライセンスを受け継ぐということでは

**デフォルトの名無しさん** · 2018/01/17(水) 18:15:52.03

MIT Licenseで公開した後にライセンスを取り消して、既に作られた改変物の公開を禁止させることはできますか？

たとえばApache License2.0だと「“取り消し不能な”著作権ライセンスを付与します」とありますが
MIT Licenseには取り消し不能といった文が見当たりません
これだと後から取り消しが出来てしまうのか、それとも法律や別の理由で取り消しは不可能なのか知りたいです

**デフォルトの名無しさん** · 2018/01/17(水) 18:51:57.79

ライセンス契約は相手の同意があれば破棄（解除）できるよ
また、相手に債務不履行があるケース（ライセンス違反）とかも対象になるね
相手に瑕疵がなく相手が同意しない場合は破棄はムリだと思う

ttps://ja.wikipedia.org/wiki/%E8%A7%A3%E9%99%A4

不特定多数に公開している場合、ライセンス契約をすべて解除するのは実質ムリだろうね

**デフォルトの名無しさん** · 2018/01/17(水) 23:05:57.48

>>732
MIT Licenseで公開されたものを自分のプログラムに取り込んでも
突然公開を禁止させられたりする心配はないということですね
ありがとうございます

**デフォルトの名無しさん** · 2018/01/17(水) 23:14:51.92

ライセンサーの意思で勝手に契約を破棄するってのは無理だろうけど、それ以外の理由で
利用を禁止されることがないわけじゃない。
第三者の権利(著作権、特許権)を侵害していた場合とか。

**デフォルトの名無しさん** · 2018/02/12(月) 11:11:43.46

>>1 からずっと読破したんですけど
誰もMPLについてあまり語ってないので教えてください

趣味でプログラム作ってフリーウェアとしてEXEのみ公開している者です
当然そのEXEのCopyright表示には自分のハンドル名を書いています
自作コードの中の処理で困ってググっていたら、とあるライブラリのソースを見つけました
そのソースコードのライセンスはMPL1.1だと書いてありました

このライブラリの中の一部のメソッドを自作プログラムで使った場合
私は今後も引き続き黙ってEXEのみ公開し続けられますか？
それとも今後の公開に当たり、何か別の義務を負いますか？

色々なサイトを読んでもズバッと書いてあるところが見つからない
特にフリーウェア作ってるような草の根プログラマには難解の一言です

どなたか教えてくださると幸いです

**デフォルトの名無しさん** · 2018/02/13(火) 00:51:06.95

アゲてやろう

**デフォルトの名無しさん** · 2018/02/13(火) 01:09:23.55

wikipediaにズバっと書いてあるような気もするけど

Mozilla Public License - Wikipedia
https://ja.wikipedia.org/wiki/Mozilla_Public_License

**デフォルトの名無しさん** · 2018/02/13(火) 15:14:55.04

>>737

Mozilla Public License - Wikipedia　より
被許諾者には主に再頒布に関する責任が要求される。
被許諾者は、MPLで保護されるソースコードすべてに対するアクセスあるいは
提供手段を確保する必要がある。

問題は「私は今後も引き続き黙ってEXEのみ公開し続けられますか？」の部分だと思う
この作者は具体的に何をすれば「再配布に関する責任」をまっとうできるのか？

**デフォルトの名無しさん** · 2018/02/13(火) 18:00:43.26

ライブラリのソースコードをコピペで自分のプログラムのソースに貼り付けたんならその部分を公開すりゃいいだろ
ライブラリ単体で弄らずビルドしたもんとリンクしてんならライブラリ提供元のソースコードへのリンクでも貼り付けてりゃいいだろ
ライブラリ弄ってビルドしたんなら弄った部分含めたライブラリ部分のソースコード公開すりゃいいだろ
そんくらいwikipediaから読めるだろＪＫ

**デフォルトの名無しさん** · 2018/02/16(金) 16:13:23.40

>>739
口は悪いが案外優しいww

**デフォルトの名無しさん** · 2018/04/28(土) 22:09:51.08

外部プロジェクトの一部のファイル（CC 3.0）を自分のプロジェクト（Apache等）に含める場合、
LICENSEファイルはどのように記載すればよろしいでしょうか？

**デフォルトの名無しさん** · 2018/04/29(日) 12:07:09.74

LICENSEファイルというものに厳密な決まりがあるわけではないと思うが、普通は
あなたが配布するソフトウェアを他人に使用許諾する条件を書くものだろう。
つまり全体をApacheライセンスで配布するのか部分的に異なるライセンスで
配布するのかそれ次第。

**デフォルトの名無しさん** · 2018/05/15(火) 21:51:13.45

国鉄方向幕書体が話題になってるから見に行ったらホントにヤバくて草
いくら個人事業主だからって法務適当なまま強気に出すぎだろ・・・

**デフォルトの名無しさん** · 2018/05/23(水) 20:26:19.26

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

IURCO

**デフォルトの名無しさん** · 2018/07/03(火) 00:34:21.68

サーバーサイドのバックエンドのプログラムで
OSSのライブラリやフレームワークを使う場合
サイトのページ生成やサービス(WedAPIなど)として公開する場合
使用したOSS等のライセンス表示したほうがいいの？

**デフォルトの名無しさん** · 2018/07/03(火) 00:45:20.42

それはそこについているライセンス読め
特定のライセンスで扱いがわからないのならそれを提示しないとエスパーにしかわからない

**デフォルトの名無しさん** · 2018/07/03(火) 01:32:37.73

黙って使ってもバレなさそうな気がしたから念のため聞いてみたけど
ライセンス文読めって言えばそれはそうだよな
こたえてくれてありがとう

**デフォルトの名無しさん** · 2018/07/04(水) 21:52:28.97

Z8I

**デフォルトの名無しさん** · 2018/07/05(木) 16:26:05.25

Z8I

**デフォルトの名無しさん** · 2018/07/16(月) 15:52:36.58

ブラウザから見えるJavaScriptのライブラリで、
使用したいコードがMITライセンスなのですが、使いたい部分は全体の10％で、
コードの90％は不要なので削りたいです。
MITはコピーレフトNOで、コピーレフトの要件はwikipediaによると、

＞著作物の利用、コピー、再配布、翻案を制限しない
＞改変したもの（二次的著作物）の再配布を制限しない
＞二次的著作物の利用、コピー、再配布、翻案を制限してはならない
＞コピー、再配布の際には、その後の利用と翻案に制限が無いよう、全ての情報を含める必要がある（ソフトウェアではソースコード含む）
＞翻案が制限されない反面、原著作物の二次的著作物にも同一のコピーレフトのライセンスを適用し、これを明記しなければならない

であり、上記の要件をすべて否定すると改変も出来ないことになりますが、
MITがコピーレフトでないのは、

＞二次的著作物へのライセンス適用や、使用可能なソースコードのコピーを義務づけていないため、コピーレフトではない

からであって、コードを削るなどの改変については制限されていないという解釈で良いのでしょうか？
また削った場合の作者はオリジナルの作者のままでいいのでしょうか？
もし不具合があってそちらに連絡がいくのも困るので、
併記してmodified by meのようなことを書けばいいのでしょうか？
別に元のプログラムに問題があるわけではないので、modifiedの部分が適切かはわかりませんが。

**デフォルトの名無しさん** · 2018/07/16(月) 22:10:57.11

コピーレフトなんて横道逸れる前にMITライセンスを読め

**デフォルトの名無しさん** · 2018/07/16(月) 23:15:23.16

>>751
では質問を変えます。

改変したコードのライセンス表記はどのようにしたらいいのでしょうか？

**デフォルトの名無しさん** · 2018/07/17(火) 18:14:59.97

ライセンス文書は丸ごとそのまま引き継ぐ
混ざって訳わからなくならんようにそれと区別して改変云々を書いておく

**デフォルトの名無しさん** · 2018/10/17(水) 15:11:42.26

Apache License, Version 2.0って、Twitterみたいに
アプリのヘルプとかでずらっと箇条書きにしてあればいいのかな？
別途LICENSE.txtや取説にも書く必要ってある？

**デフォルトの名無しさん** · 2018/10/28(日) 12:50:30.62

https://github.com/mdn/webextensions-examples/blob/master/beastify/icons/LICENSE
The icon "beasts-48.png" is taken from Aha-Soft’s Free Retina iconset, and used
under the terms of its license (http://www.aha-soft.com/free-icons/free-retina-icon-set/),
with a link back to the website: http://www.aha-soft.com/.

aha-softのURLが開かないんだがbeasts-48.pngを再配布に使っていいのか？

**デフォルトの名無しさん** · 2018/11/09(金) 22:00:52.58

GPLについて、以下使用パターンでググっていろいろ読んだ結果の解釈、合ってるか教えてほしい。

・素性不明だが、libgccみたいなライブラリのソースの一部を改変・流用
・当該ソースには「GPLランタイムライブラリ例外」の記載
・非GCC、プロプライエタリなコンパイラ利用
・商用利用
・バイナリはエンドユーザーまで配布(販売)

この場合、次の処置が必要という認識でいい？
・ReadmeにGPLソフトを利用している旨とライセンス条件ファイルを添付
・流用ならびに改変したソースを添付するか、要求があれば送付する旨の書面を添付
・ランタイムライブラリ例外が適用されるので、当該ファイル以外は公開不要

商用なので正確には法務担当に確認すべきなのは分かってるが、
前任から引き継いだらこんなことになっていた。
リリースまで余裕はあるので上に報告するための話を考える情報にしたい。

**デフォルトの名無しさん** · 2018/11/10(土) 03:47:58.93

問題ありそうね

条件を読む限り、一部のソースを流用してランタイムライブラリの形ではなくプログラムに直接組み込んでいると思う
それでは製品プログラムは独立モジュール（Independent Module）とはみなされないはず

https://www.gnu.org/licenses/gcc-exception-faq.html
に『GCCライブラリからなんのソースも含まない限り、それぞれのファイルは「独立モジュール」です』と書いてある

ランタイムライブラリ例外は独立モジュールが
ランタイムライブラリの形でのGPLソフトウェアを利用している場合に対しての許可なので
独立モジュールじゃなければ、例外に該当しない
プログラム全体がGPLになるはず

◆QZaw55cn4c · 2018/11/10(土) 13:53:47.49

スタティックライブラリかシェアードライブラリかで該非がかわるのですか？

**756** · 2018/11/10(土) 15:21:42.96

>>757
ご指摘のとおり、ライブラリから切り離したであろう.c/.hをプロジェクトに組み込んで使っています。
この形だともはや「ランタイムライブラリ」じゃないという解釈ですね。

つまり、今回のパターンをクリアにするなら例えば
・libgccから不要な機能を削除したスタティックリンクライブラリlibgcc_dietを作成し
・開発中のソフトウェア(独立モジュール)からlibgcc_diestをリンクする
とすればランタイムライブラリ例外が適用できる可能性がある、ということでしょうか。
当然、libgcc_dietはGPLに従いソース含めて公開することを前提とします。

**デフォルトの名無しさん** · 2018/11/10(土) 15:42:23.89

いや、
LGPLの話ではないのでスタティックかシェアードかは関係ない
（FAQにも静的リンク、動的リンクであってもランタイムライブラリ例外は利用可能とある）

https://www.gnu.org/licenses/gcc-exception.html
に独立モジュール（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のソースは直接流用されてはいない）

**デフォルトの名無しさん** · 2018/11/10(土) 16:08:47.51

うお、レス書いてたら間に挟まった

>>759
ランタイムライブラリ例外が導入された経緯を考えると、
ランタイムライブラリがGPLなので、GCCで作った実行ファイルもGPLになるというのを回避するためだけのはず

libgcc_diet の案は一見よさそうに見えるが、
プロプライエタリからの利用を極端に嫌うFSFが
ランタイムライブラリ例外付きGPLのコードを、GPL迂回のための抜け道となるように作るとは思えない

例えば、libgcc_diet がランタイムライブラリを名乗れるのかがちょっと分からない
ランタイムライブラリは著作権者がファイルにランタイムライブラリ例外付きとしてライセンスする必要があるが、
著作権者ではない改変者が libgcc_diet をランタイムライブラリ例外付きGPLでリリースできるのかあたりがとても怪しい

**756** · 2018/11/10(土) 18:42:19.95

>>761
>著作権者ではない改変者が libgcc_diet をランタイムライブラリ例外付きGPLでリリースできるのかあたりがとても怪しい
なるほど。この点は要確認ですね。

ちなみに使っているのは、アーキテクチャ依存のスタートアップコードとCPU固有命令をCからコールするためのインライン化コード。
ちょっと特殊なCPUなので代替コードはなさそう。
多分一から書ける人はほとんど居ないので詰んだ感がする。

**761** · 2018/11/11(日) 11:48:37.51

>>762
スタートアップコードとCPU固有命令のCラッパー部分なら、
756 の libgcc_diet の方法で作った場合、
757 で指摘した『製品プログラムは独立モジュールとはみなされない』
という指摘は当てはまらないね
（libgcc_diet のコンパイルと製品プログラムのコンパイルを別にして、後からリンクするだけ）

ただし依然としてランタイムライブラリ例外付きGPLで libgcc_diet をリリースできるかは不透明

**デフォルトの名無しさん** · 2018/11/12(月) 14:18:07.97

横から失礼
むしろ改変して、例外を適用出来るの？

**デフォルトの名無しさん** · 2018/11/12(月) 16:22:28.53

>>756をまとめると、
「GPLライブラリを改変して、LGPLとして使いたい」
ってことになってしまうのかな？

**761** · 2018/11/12(月) 16:28:25.36

GPLのソースコードを改変したコードだったり、
GPLのソースコードと自分のソースコードを混ぜてコンパイルしたら、
757 で言ったとおり「独立モジュール」にならないので例外を適用できないよ

リンク段階なら適用できる

**デフォルトの名無しさん** · 2018/11/12(月) 21:17:49.64

書き方の問題だと思うけど、GPL+リンク例外のコードを改変したものを同じGPL+リンク例外で
リリースする分には問題ない。もちろん純粋なGPLのコードからはダメだが。

**デフォルトの名無しさん** · 2018/11/12(月) 22:46:04.69

ランタイムライブラリ例外で追加された許可は、
「独立コードであればランタイムライブラリのGPL違反とはならない」という一つのみなので、
派生コードをランタイムライブラリ例外付きGPLでリリースすることは許可されていない
という可能性がありそうに見えます
（ただのGPLなら可）

（どのライセンスもそうだけど）ランタイムライブラリ例外付きGPLにするには著作権者全員の同意が必要で、
libgcc_diet の著作権者として libgcc の著作権者が含まれる訳だけど、
libgcc_diet をランタイムライブラリ例外にするには libgcc の著作権者の同意が必要なんじゃないかと

自分が見落としてるGPLの条項とか、GNUやFSFの見解とかあれば教えてください

**デフォルトの名無しさん** · 2018/11/12(月) 23:22:35.32

GPL系のライセンスでは複製物/派生物は基本的に元のライセンスと同じライセンスで配布することを要求する。
LGPLなどリンク例外付きのものはGPLを選択してもよいというオプションが追加されているだけ。

>（どのライセンスもそうだけど）ランタイムライブラリ例外付きGPLにするには著作権者全員の同意が必要で、

それを同意するのがまさにライセンス条項なわけで。

**756** · 2018/11/13(火) 00:45:43.57

休日で見れない間に進んでた。

・GPLライブラリ例外となっているライブラリ内のソース抜き出し利用
　→ライブラリ例外適用不可
・GPLライブラリ例外のライブラリを変更し、ソース公開しつつそのライブラリにリンク
　→ライブラリ例外適用可

ということだと解釈した。

今日さらに調査をした結果分かったこと。
最初のレスで「libgccみたいなライブラリのソースの一部」と書いたが、コレはどうもコンパイラに付属しているCランタイムライブラリのようだ。
ライブラリ全体はlibgccをベースに、アーキテクチャ向け変更を入れ込んでソースごと公開されている。
LICENSEにはランタイムライブラリ例外の旨も付いていた。
これを見ると上で議論のある「GPLランタイム例外が適用されているライブラリを改変し、同じライセンス形態のまま公開」が成立しているように見える。
有料で売ってるコンパイラなのでそこはメーカが問題無いと判断した上で販売していると認識したが、果たして。

というか、この理論が成立しないとlibgccをさまざまなCPU向けに作り変えてもライブラリ例外が適用できなくなってしまうが、そういうものなのだろうか。

**761** · 2018/11/13(火) 01:19:18.61

ふー、GPLv3内の該当の条項を探した

7. Additional Terms.
より、適当抜粋

・追加条項はGPLv3のライセンス本体に含めるとあった
・ランタイムライブラリ例外のような許可の追加条項（Additional permissions）は引き継いでも破棄してもいい様子
・許可の追加条項の条項に記載することで、例えば改変された場合に追加条項の削除もできる
・非許可の追加条項は許されていない

GCCランタイムライブラリ例外の条項には改変時の追加条項の削除の条項は見当たらないので、
ランタイムライブラリ例外付きGPLは、ソースをランタイムライブラリ例外付きGPLとしてリリースできるっぽい

まじか……
ランタイムライブラリ例外付きGPLは、シェアードライブラリにする必要がないからLGPLより緩いのか

**デフォルトの名無しさん** · 2018/11/14(水) 13:49:00.33

FSFの文章読んでると
「今後はAGPLv3に統合してく、特例としてLGPLは作ったが出来ればGPLv3にしろ。
なお他のライセンスは一切使うな。」
って感じだけどなぁ

**デフォルトの名無しさん** · 2018/11/22(木) 15:34:31.25

Apache License 2.0の最後に定型文があって「添付してください」って書いてあるけども、
これってAppendixだから「適用する時の例」であって、
「絶対にこの書き方をしなければならない」って意味では無いですよね？

**デフォルトの名無しさん** · 2018/11/27(火) 00:37:44.31

いつの間にかWineがLGPLになっているけど、これを使ってリバースエンジニアリング禁止のプロプラアプリを動かしたらライセンス違反になっちゃうんじゃないの？

**デフォルトの名無しさん** · 2018/11/27(火) 09:14:42.46

動かすだけなら問題無いんじゃ？

**デフォルトの名無しさん** · 2018/11/27(火) 18:20:02.40

どういう理屈？

アプリAがLGPLのライブラリBを呼んだらアプリAはリバースエンジニアリングを禁止できないだろ
Wineの場合ライブラリBがWineになるんだからアプリAがリバースエンジニアリングを禁止している場合は
ライセンス違反になっちゃうんじゃないの？

**デフォルトの名無しさん** · 2018/11/27(火) 19:18:31.09

GPLは著作権を土台としているため頒布や改変(と二次的著作物の頒布)を利用条件の元に許諾を与えてる
自分が使うために利用することに制約は無い

**デフォルトの名無しさん** · 2018/11/28(水) 15:16:18.69

Wineで何をどう動かすかくらい書かないと、エスパーじゃないとわからんな
Wineのソースコードを改変して配布しようとしているのか？

**デフォルトの名無しさん** · 2018/11/29(木) 16:17:55.80

GPLの著作権って、いつ切れるのかな？
実質改変され続ける限りは無限？
（そして50年以上改変しないアプリなんて価値が無いし）

**デフォルトの名無しさん** · 2018/11/29(木) 18:58:30.47

TPPで著作権の保護期間が50年から70年に延長
GPLはライセンスでプログラムを書いた人が自由に決めてるもので
著作権は法律で決まってて自由に決めれないものだろ
ライセンスは無期限じゃね
ライセンス違反で訴えられるなら使用時に同意した契約に違反したってことになるのかな