回答編集履歴
6
頒布
answer
CHANGED
|
@@ -61,4 +61,14 @@
|
|
|
61
61
|
|
|
62
62
|
スマートフォン向けゲームなんかだと、プログラムのあるdirectoryを見に行くのは現実的ではないのでプログラム中からLICENSEを確認できるべきですし、PC向けのプログラムなら、単にbinaryとおなじdirecoryにライセンスを記したファイルを置いておけばいいです。
|
|
63
63
|
|
|
64
|
-
ソースコード公開は上述のとおりです。
|
|
64
|
+
ソースコード公開は上述のとおりです。
|
|
65
|
+
|
|
66
|
+
# 追記
|
|
67
|
+
|
|
68
|
+
頒布方法ですが、たとえLICENSEでソースコード開示が義務付けられていてもソースコードを同梱する必要はなく、**請求があったときに**開示すればよいです。極端な例でいえば請求されたらDVDとかにソースコードを焼いてDVD代および輸送費実費と引き換えに渡す、とかでも構いません。
|
|
69
|
+
|
|
70
|
+
が、さすがにそれはお互い面倒なので、普通はソースコードがある場所のURLを記載するかソースコードを同梱します。
|
|
71
|
+
|
|
72
|
+
注意点として、ソースコード開示が義務付けられているLICENSEで、ソースコードがある場所の**URLが死んだ場合**、その成果物たる実行ファイルを頒布・再頒布することはできません。
|
|
73
|
+
|
|
74
|
+
例としては、AviSynthのとあるプラグインでGPLなライセンスを採用していたが、ソースコードを公開するのに使っていたWebサービスが終了し、かつ作者との連絡手段も喪失したことで、そのプラグインを二次配布することもできなくなってしまった例があります。
|
5
notice
answer
CHANGED
|
@@ -1,3 +1,9 @@
|
|
|
1
|
+
# 注意事項
|
|
2
|
+
|
|
3
|
+
通常の回答と同様、改めて書くまでもないのですが、下記の回答について一切の保証はできません。必要なら、法律の専門家(いるのか？)に相談してください
|
|
4
|
+
|
|
5
|
+
# 回答
|
|
6
|
+
|
|
1
7
|
> LGPLと認定されるには**LGPL用のファイルがあり**、所定のサイトから取得して、DLLまたは実行可能ファイルのような、LGPLを付与したいプログラムがある
|
|
2
8
|
ディレクトリに入れ、
|
|
3
9
|
LGPLと認識させる部分とそれを使う部分を公開する必要がある。
|
4
告知方法
answer
CHANGED
|
@@ -47,4 +47,12 @@
|
|
|
47
47
|
|
|
48
48
|
---
|
|
49
49
|
|
|
50
|
-
各国の著作権法制で解釈があいまいなのは、動的リンクするものにコピーレフトが及びうるのか(GPL的には及ぶという見解)、という部分で、これが二次的著作物か二次利用かで明快な結論を得ていません。Be on the safe sideの原則から言ってGPLの見解を採用し、動的リンクするものにコピーレフトが及ぶと思って行動するべきと思っています。
|
|
50
|
+
各国の著作権法制で解釈があいまいなのは、動的リンクするものにコピーレフトが及びうるのか(GPL的には及ぶという見解)、という部分で、これが二次的著作物か二次利用かで明快な結論を得ていません。Be on the safe sideの原則から言ってGPLの見解を採用し、動的リンクするものにコピーレフトが及ぶと思って行動するべきと思っています。
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
LICENSE告知を頒布時にどうするかですが、ようは**現実的な手段でLICENSEを確認できればいい**です。
|
|
55
|
+
|
|
56
|
+
スマートフォン向けゲームなんかだと、プログラムのあるdirectoryを見に行くのは現実的ではないのでプログラム中からLICENSEを確認できるべきですし、PC向けのプログラムなら、単にbinaryとおなじdirecoryにライセンスを記したファイルを置いておけばいいです。
|
|
57
|
+
|
|
58
|
+
ソースコード公開は上述のとおりです。
|
3
二次創作か二次利用か
answer
CHANGED
|
@@ -43,4 +43,8 @@
|
|
|
43
43
|
|
|
44
44
|
---
|
|
45
45
|
|
|
46
|
-
なおLGPLなQt本体にバグを見つけたなどの理由で改変を加える場合は、改変patchはLGPLで公開されなければなりません
|
|
46
|
+
なおLGPLなQt本体にバグを見つけたなどの理由で改変を加える場合は、改変patchはLGPLで公開されなければなりません
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
各国の著作権法制で解釈があいまいなのは、動的リンクするものにコピーレフトが及びうるのか(GPL的には及ぶという見解)、という部分で、これが二次的著作物か二次利用かで明快な結論を得ていません。Be on the safe sideの原則から言ってGPLの見解を採用し、動的リンクするものにコピーレフトが及ぶと思って行動するべきと思っています。
|
2
m
answer
CHANGED
|
@@ -27,7 +27,7 @@
|
|
|
27
27
|
|
|
28
28
|
---
|
|
29
29
|
|
|
30
|
-
また、今は基本的なlibqtusing.aを作っている最中ですが、最初は自分用のソフトになると思います。
|
|
30
|
+
> また、今は基本的なlibqtusing.aを作っている最中ですが、最初は自分用のソフトになると思います。
|
|
31
31
|
その場合でも公開義務はあるのでしょうか?
|
|
32
32
|
|
|
33
33
|
binaryないしソースコードを**頒布する必要が出たときに**初めて考慮するのがLICENSEだと思われます。頒布というのは公開の場にソースコードないしビルドした実行ファイルを晒すことです。
|
1
patch
answer
CHANGED
|
@@ -39,4 +39,8 @@
|
|
|
39
39
|
1. libqtusingをQt依存部分とそれ以外で分け、非依存部分は一般的なOSSライセンスを適用する(MIT, BSD, BSLなど)。依存部分はLGPLにする
|
|
40
40
|
2. 最終成果物は上記3で述べた通り
|
|
41
41
|
|
|
42
|
-
です。
|
|
42
|
+
です。
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
なおLGPLなQt本体にバグを見つけたなどの理由で改変を加える場合は、改変patchはLGPLで公開されなければなりません
|