デバッグが楽になる!ツクールMZでプラグインを作る上での最低限の心得

という記事を書きました。

https://qiita.com/katai5plate/items/362ec95a3053814764a4

基本的にこれだけ抑えておけば、デバッグが楽になるしクレームも減るよって感じの内容です。
中級者向けに書いたので、DevToolsなどのようなデバッグツールとかの情報とかではなく、
プラグインの「いろいろなことが楽になる書き方」について書いてます。
 
最後に編集:
こんにちは。
参考になる情報ありがとうございます。
記事にある「心得2: プラグイン名は currentScript で取れ」についてですが、私は現状反対派なのでそれについて書かせていただきます。

そもそもすごく基本的なことを言えば、ファイル名を変更できるようにするのは当たり前のことです。
しかし、これをやるとプラグイン名で検索してもプラグインが見つからなくなるというデメリットが生じます。
現在アツマールでは、投稿されたゲームに使われているプラグイン名の一覧が見られるようになっています。
他にも一応、よく使われているプラグインランキングみたいなものもあります。(最近更新されてませんが)
それらを見たツクラーが、「自分のゲームにもこのシステム取り入れたい」と思ってプラグイン名で検索してもプラグインが見つからないというのは、製作者にとっては大きなデメリットです。
他人に迷惑かかるわけではないのでやるやらないは自由ですが、やるとしてもこのデメリットを知った上でやるべきでしょう。

あと、こういった理由で変更できるプラグインとできないプラグインが混合してしまうのを避けたいというのもあります。
ツクールやアツマールが対応していない現状では、今まで通り「プラグイン名は変更できないもの」で統一しておいてよいのではと思います。
 
ご意見どうもです。

しかし、これをやるとプラグイン名で検索してもプラグインが見つからなくなるというデメリットが生じます。
現在アツマールでは、投稿されたゲームに使われているプラグイン名の一覧が見られるようになっています。
他にも一応、よく使われているプラグインランキングみたいなものもあります。(最近更新されてませんが)
それらを見たツクラーが、「自分のゲームにもこのシステム取り入れたい」と思ってプラグイン名で検索してもプラグインが見つからないというのは、製作者にとっては大きなデメリットです。
他人に迷惑かかるわけではないのでやるやらないは自由ですが、やるとしてもこのデメリットを知った上でやるべきでしょう。

あと、こういった理由で変更できるプラグインとできないプラグインが混合してしまうのを避けたいというのもあります。
ツクールやアツマールが対応していない現状では、今まで通り「プラグイン名は変更できないもの」で統一しておいてよいのではと思います。

プラグインの名前変更による弊害でアツマールのプラグイン表示がされなくなることを
デメリットと捉えるのは、人によって違うと思います。
また、名前変更を禁じたいのであれば、「ライセンスの規約」として、その旨を @help に書くなどすればよいのではないでしょうか。

例えば、皆さんがよくプラグインの定番のライセンスとして使用しているMITライセンスですが、
これによって縛れるのはあくまで
「著作権表示および本許諾表示をソフトウェアのすべての複製または重要な部分に記載しなければならない」
というルールのみです。ですから、それ以外の行為は何をやっても構わないということにプラグイン開発者は同意しているのです。

本許諾表示というのは要するに、このプラグインはMITライセンスで配布しているという事実を示す表示のことです。
また、著作権表示はソースコード内あるいは別ファイルとして内部に持っていればよいため、
コンテンツの利用者に向けて「このプラグインを使っています」と公表する必要もないです。

ですから、MITライセンスでリリースしている以上、
プラグイン名の変更を禁止できる権利はどこにもない
わけです。

どうしても木星ペンギンさんのように、MITライセンス外のルールを利用者に義務付けたい場合は、
それに合ったライセンスを選ぶか、自分でライセンスを作る
ことをおすすめします。
(実際、自分が使用しているライセンスの意味がわかっていない状態で運用するのは危険です。)

参考:
MITライセンスとは|「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
licensing - What is the point of including the MIT copyright text if you use someone's code licensed under MIT? - Open Source Stack Exchange


ちなみに僕は、アツマールのプラグイン表示がされなくなることはデメリットとは思っていません。
ライセンスを守った上でのあらゆる行動は、プラグイン利用者の当然の権利ですから、
ライセンスさえ守ってくれれば、何してくれても構わんです。
(また物によっては、完全にライセンスフリーのプラグインも配布しています。)
 
最後に編集:

fspace

ユーザー
そもそもすごく基本的なことを言えば、ファイル名を変更できるようにするのは当たり前のことです。
しかし、これをやるとプラグイン名で検索してもプラグインが見つからなくなるというデメリットが生じます。
現在アツマールでは、投稿されたゲームに使われているプラグイン名の一覧が見られるようになっています。
他にも一応、よく使われているプラグインランキングみたいなものもあります。(最近更新されてませんが)
それらを見たツクラーが、「自分のゲームにもこのシステム取り入れたい」と思ってプラグイン名で検索してもプラグインが見つからないというのは、製作者にとっては大きなデメリットです。
他人に迷惑かかるわけではないのでやるやらないは自由ですが、やるとしてもこのデメリットを知った上でやるべきでしょう。
こういった内部に含まれるソフトウェアをユーザが特定できるようにするためのものがMITライセンスなんかだと思ってますが、実際問題としてうまく機能していない感はありますね。ソースコード内に著作権表示が含まれていればいいという風潮によってユーザがそれを確認する方法を知らなかったり、アツマールでプラグイン名しか表示されなかったりするのが原因かなと思います。

あと、こういった理由で変更できるプラグインとできないプラグインが混合してしまうのを避けたいというのもあります。
ツクールやアツマールが対応していない現状では、今まで通り「プラグイン名は変更できないもの」で統一しておいてよいのではと思います。
MZでは@base@orderBefore/@orderAfterが追加されたことで、currentScriptを利用してもプラグインのリネームができないケースが発生するようになりました。このため、自分もユーザに対しては「プラグイン名は基本的に変更できないもの」と周知した方がいいと思います。そのうえで、シンプルに書くか一応リネーム可能にしておくかは製作者次第かなと。

また、名前変更を禁じたいのであれば、「ライセンスの規約」として、その旨を @help に書くなどすればよいのではないでしょうか。
これについては本当にその通りで、ユーザに守ってもらいたいことがあるのであればきちんと伝えるべきです。もし伝えずにMITライセンスでリリースしたのであれば、プラグイン名と関連部分のコードだけ書き換えて使われても文句は言えません。

本許諾表示というのは要するに、このプラグインはMITライセンスで配布しているという事実を示す表示のことです。
また、著作権表示はソースコード内あるいは別ファイルとして内部に持っていればよいため、
コンテンツの利用者に向けて「このプラグインを使っています」と公表する必要もないです。
これについてはちょっと怪しいんじゃないかと思います。確かに条文中に書かれているのは著作権表示と許諾表示を含めることだけですが、著作権表示にしても許諾表示にしても、「何に対する」という情報が無ければ意味をなさないもので、暗黙的にこれは含まれるものだと思います。対象を示すための方法がプラグイン名の表示に限定されるとは思わないので、リネーム自体が問題だとは思いませんが、誰のどのプラグインを使っているかを公表する義務はあると思います。
 
返答ありがとうございます。

プラグインの名前変更による弊害でアツマールのプラグイン表示がされなくなることを
デメリットと捉えるのは、人によって違うと思います。
確かにその通りですが、私が言いたかったのはデメリットを知らずに名前を変更できるようにする人が出てきてしまうのを防ぎたいということです。
それについてはこうして書かせていただいた時点で達成できているので問題ないです。

また、名前変更を禁じたいのであれば、「ライセンスの規約」として、その旨を @help に書くなどすればよいのではないでしょうか。
言われてみればその通りです。
勝手にRPGツクールのプラグインでは暗黙の了解みたいに思っていました。

MZでは@base@orderBefore/@orderAfterが追加されたことで、currentScriptを利用してもプラグインのリネームができないケースが発生するようになりました。
これは私も先ほど気づきました。
私が書いた理由よりもこっちの方が重要そうですね。

ですから、MITライセンスでリリースしている以上、
プラグイン名の変更を禁止できる権利はどこにもない
わけです。

どうしても木星ペンギンさんのように、MITライセンス外のルールを利用者に義務付けたい場合は、
それに合ったライセンスを選ぶか、自分でライセンスを作る
ことをおすすめします。
(実際、自分が使用しているライセンスの意味がわかっていない状態で運用するのは危険です。)
仕事でプログラミングをしている人には怒られそうな意見ですが、趣味で無料でやってる私にとってMITライセンスって自分の作ったものを守るものではなく、自分で作ったものによって問題が生じても一切無責任でいたいものなんですよね。
なのでこの場合、名前を変更するのは利用者の勝手だけど動かなくなっても私は知らないよという意見が貫ければいいみたいな感じです。
もちろん、これは最悪の場合の話です。
無料でやってもいいと思える範囲のことは私もやるつもりです。
 

fspace

ユーザー
仕事でプログラミングをしている人には怒られそうな意見ですが、趣味で無料でやってる私にとってMITライセンスって自分の作ったものを守るものではなく、自分で作ったものによって問題が生じても一切無責任でいたいものなんですよね。
ちょっと話がずれるような気もしますが、自分の名誉を守りたいのでなければ別のライセンスを使うといいですよ。自分はどうでもいいものについてはCC0を使ってます。このあたりの用途だと、他にUnlicenseとかWTFPLなんかがよく使われてる気がします。
 

もふもふ

ユーザー
ライセンスのお話、興味深く勉強させて頂きました。
プラグインや素材も含めてライセンスの指定をする側、守る側、
いろいろ難しくて、やっかいなことに大事です。

はやくゲーム作りしたいけど、ライセンス違反が
後で発覚すると大変なので後回しにできない。
でも難しいし、管理面倒だし、作業として面白味が少ない(個人の意見です)し。

なんかオンラインでプラグインのライセンス情報(+その他の情報)の登録とかしたら
後でライセンスの形式とかを判別して著作権表記テキストとか自動で作ってくれる
サービスとかあったらいいのに・・・。
そしたらプラグイン一覧とかとしても機能して
さらに公式のプラグイン宣伝場所としても機能するのに。
ねっ、ツクールさん?
 
これについてはちょっと怪しいんじゃないかと思います。確かに条文中に書かれているのは著作権表示と許諾表示を含めることだけですが、著作権表示にしても許諾表示にしても、「何に対する」という情報が無ければ意味をなさないもので、暗黙的にこれは含まれるものだと思います。対象を示すための方法がプラグイン名の表示に限定されるとは思わないので、リネーム自体が問題だとは思いませんが、誰のどのプラグインを使っているかを公表する義務はあると思います。
根拠はこれです。

Open source licensing notices in Web applications | Engelfriet | Journal of Open Law, Technology & Society

Linking to open source licenses (オープンソースライセンスへのリンク)から抜粋

However, open source software is not public domain. The software is protected by copyright and one must accept the license terms before the software may be modified and distributed. With open source licenses it is not required to explicitly sign an agreement with the author. Typically the author merely adds a license statement in the source code to put recipients on notice.
(ただし、オープンソースソフトウェアはパブリックドメインではありません。 ソフトウェアは著作権によって保護されており、ソフトウェアを変更して配布する前に、ライセンス条項に同意する必要があります。 オープンソースライセンスでは、作成者との契約に明示的に署名する必要はありません。 通常、作成者はソースコードにライセンスステートメントを追加するだけで、受信者に通知します。)

Including complete license texts in source code is of course sufficient
(もちろん、完全なライセンステキストをソースコードに含めるだけで十分です。)
The BSD license(BSDライセンス)から抜粋

> Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
(条文:ソースコードを再頒布する場合、上記の著作権表示、本条件一覧、および下記免責条項を含めること。)

This makes it clear that the license text must be in the file to which the license applies. Furthermore, the BSD license is typically offered as a template so that linking to that text results in an incomplete license. This reinforces the interpretation that one must copy the license text (and substitute one’s details as copyright holder) before the BSD license can apply.
(これにより、ライセンステキストをライセンスが適用されるファイルに含む必要があることが明確になります。さらに、BSDライセンスは通常テンプレートとして提供されるため、そのテキストにリンクするとライセンスが不完全になります。これは、BSDライセンスを適用する前に、ライセンステキストをコピーする{そして著作権所有者として詳細を置き換える}必要があるという解釈を強化します。)

Arguably one can interpret the word “retain” as “do not remove” without an obligation to actually include the notice and the conditions in any source file. Under this interpretation it could be sufficient to refer to the BSD license elsewhere on the World-Wide Web. One would still need to make a copy of the BSD license template and substitute one’s details.
(間違いなく、「保持する[=retain]」という言葉は、通知と条件をソースファイルに実際に含める義務なしに「削除しない[=do not remove]」と解釈できます。この解釈の下では、WWWの他の場所でBSDライセンスを参照するだけで十分である可能性があります。それでも、BSDライセンステンプレートのコピーを作成し、詳細を置き換える必要があります。)
The MIT license(MITライセンス)から抜粋

> any person obtaining a copy of this software and associated documentation files
(条文:本ソフトウェアおよび関連文書のファイルの複製を取得するすべての人に対し)

but also requires that
(それも必要ですし、)

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
(条文:著作権表示および本許諾表示をソフトウェアのすべての複製または重要な部分に記載しなければならない。)

This requirement makes it hard to comply without actually including the verbatim text of the license in the Javascript file. We could follow the same approach as with the BSD license and interpret “shall be included” as “must not be removed”
(この要件により、Javascriptファイルにライセンスの逐語的なテキストを実際に含めずに準拠することは困難になります。 BSDライセンスの場合と同じアプローチに従い、「含める[=shall be included]」を「削除してはならない[=must not be removed]」と解釈することもできます)

「逐語的なテキストを実際に含めずに準拠するのは困難」というのは、
逆説的に「ライセンステキストをそのまま維持すればよい」と言えるでしょう。

以上のことから、僕の解釈で問題ないと考えています。

ただまあ、実際のところ解釈によって左右されやすい問題だとも思います。
実際、企業製のブラウザゲームでも表記方法は完璧には統一されていません

例えばあの「艦これ」こと「艦隊これくしょんでは、MITライセンスのPixi.jsを使用していますが、
内部のソースコードにライセンス文を残すだけの対応をしており、
コピーライトにオープンソースライセンス表記は見当たりません。
1613192576649.png

しかしながら、「シャニマス」こと「アイドルマスター シャイニーカラーズでは、
MITライセンスのbabelを使用していますが、
コピーライト表記に、きちんとbabelを使用している旨とそのライセンス表記を行っています
ただし、このコピーライトにも載っていないJavaScriptライブラリ(pixi-particles.js)もあり
それらはライセンス表記を維持しています。
(これは予想ですが、開発には使用しているがデプロイされたデータにライセンス表記を含めることができないものや、
 開発に使用しているツールなどのライセンスを、コピーライト表記に「一応」含んでいるのだと思われます。
 ソースコードの一部を使用したり、ライブラリそのものが組み込まれている可能性もありますが。)
1613192429269.png

そして、みなさん愛用のRPGツクールMV/MZでは、
Windowsデプロイを行うと内部に credits.html が出力され、開くとソフトウェアライセンス一覧が表示されますが、
JavaScriptで使用されているソフトウェアのライセンスは含まれていません
そしてもちろん、ブラウザでデプロイする場合は、credits.html も出力されません。
バイナリではビルド前コードに残すだけでは見ることが出来ないので別に表記する必要があるが、
 JavaScriptならそのまま見れるのでライセンス表記を維持するだけで十分
と考えているからでしょう。
 それと、コアスクリプトには // prettier-ignore というコメントが書かれた箇所があり、
 開発にMITライセンスのPrettierを使用している可能性が高いですが、シャニマスのbabelのような表記は行われていません。)
1613192656851.png

ゲーム
対応方法
艦これJavaScriptコードのライセンス維持
シャニマスJavaScriptコードのライセンス維持
ゲーム内クレジットにライセンス表記
ツクールのデプロイJavaScriptコードのライセンス維持
バイナリに含まれるものは内部 credit.html にライセンス表記

なのでプラグインなどのMITライセンスは最低限、著作権表示はソースコード内あるいは別ファイルとして内部に持っていればよく
もし不安だったらより詳しく明記するなどすればよいのではないでしょうか。

また開発の過程でなにか Prettier や babel などのようなツールを使ったとしても、
そのツールのソースコードの一部を拝借したり、ソフトウェアに組み込んだりしたとかそういうわけではないのならば、
特別な規約が無い限り、ライセンス表記の必要はないでしょう。(するのは勝手です。)
 
最後に編集:
仕事でプログラミングをしている人には怒られそうな意見ですが、趣味で無料でやってる私にとってMITライセンスって自分の作ったものを守るものではなく、自分で作ったものによって問題が生じても一切無責任でいたいものなんですよね。
なのでこの場合、名前を変更するのは利用者の勝手だけど動かなくなっても私は知らないよという意見が貫ければいいみたいな感じです。
もちろん、これは最悪の場合の話です。
無料でやってもいいと思える範囲のことは私もやるつもりです。
まあ、ライセンスはあくまで「許可する範囲を明記するもの」なんで、「サポート範囲」に関しては別の話だと思います。
不具合に関して責任を持ちたくないなら、応対しなければいいだけの話ですし、
書面でどうしても伝えたいのであれば、「免責事項」としてその旨を書けばいいんじゃないですかね。

一切の知的財産権を放棄したいという場合は、そういうライセンスを使うことをおすすめします。

自分はそういうものに関してはWTFPLを使ってます。
WTFPLは日本語訳すると「どうとでも勝手にしやがれクソったれライセンス」で、
条文も次のような感じです。
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
(このライセンスドキュメントの逐語的なコピーは、誰でも複製して配布することを許可されていますが、
 変更することは許可されていません。)

Ok, the purpose of this license is simple
and you just
(オーケィ。このライセンスの目的はシンプルだ。
 君はタダ、)

DO WHAT THE FUCK YOU WANT TO.
(ヤりたいことをヤれ。)
そこまで言うつもりはないけど、自由にやってほしいなら CC0 を使えばいいと思います。
パブリックドメインを提供する「著作権なし」ライセンスです。
ちなみに、国家や企業以外なら自由に使っていいというアナーキーなライセンスもありますよ。

なんかオンラインでプラグインのライセンス情報(+その他の情報)の登録とかしたら
後でライセンスの形式とかを判別して著作権表記テキストとか自動で作ってくれる
サービスとかあったらいいのに・・・。
実際そういうサービスは需要ありそうですね。

ツクールの開発に使用されたであろうNode.jsでは、そのような仕組みがすでにあって、
使用しているライブラリのライセンス情報を package-lock.json というデータに一括で残すという機能があります。

ただ、そういうものって npm と呼ばれる、JavaScript のライブラリを登録するサイトで、ライセンスを登録していて、
実際に使うときもこの npm からダウンロードしてくる仕組みになっているから成立するんですよね。

なので、ツクールのプラグインも、ライセンスありきで登録できるサイトがあって、
基本的にそこから全部のプラグインを引っ張ってこれるようなシステムになるといいですね。
 
最後に編集:

fspace

ユーザー
なのでプラグインなどのMITライセンスは最低限、著作権表示はソースコード内あるいは別ファイルとして内部に持っていればよく
もし不安だったらより詳しく明記するなどすればよいのではないでしょうか。
自分も著作権表示をソースコード内に残しておけば問題ないという部分に異論はなくて、引っかかったのはその後に書かれていた
コンテンツの利用者に向けて「このプラグインを使っています」と公表する必要もないです。
の部分です。

これを都合よく解釈すると、ソースコード上の著作権表示を読めなくしたうえで、readmeか何かにこんな感じに書けばいいとも読めるので、使用プラグインを隠蔽しようとする人が現れそうだなと思って指摘しました。
このゲームはMITライセンス(https://...)のプラグインを使用しています。
Copyright (c) 2021 XXX
Copyright (c) 2021 XXX
Copyright (c) 2021 XXX
著作権表示や許諾表示だけ書かれても、その表示がどの部分に適用されているのかわからないので、それを理解できるだけの情報は提示する必要があるという意味です。
 
このゲームはMITライセンス(https://...)のプラグインを使用しています。
Copyright (c) 2021 XXX
Copyright (c) 2021 XXX
Copyright (c) 2021 XXX
その表記方法って、ツクールMV/MZの credits.html の表記方法となにか違うんですかね?

ツクール側でWindowsデプロイを行った時に作られるフォルダの中にあるHTMLデータです。
そこにはオープンソースライブラリ名・ライセンス条文・配布元の表記しかなく、どの部分に適用されているか等の表記はありません
僕がさっき書いたコメントのシャニマスも同様で、ゲーム内コピーライトに書かれたライセンス表記には、
オープンソースライブラリ名・ライセンス条文しか書かれていません。

僕は、逐語的な条文テキストを含んでいるなら、別に一箇所にまとめられていても構わないと思いますし、
その表示がどの部分に適用されているのかを示す必要はないが、不安なら入れてもいいんじゃないの程度です。

条文にだって、「または」って書いてますし。「かつ」ではないです。
JavaScriptコードだったら必ずライセンス表記の位置を考えて配置しろとも書いてないわけですし。

Open source licensing notices in Web applications | Engelfriet | Journal of Open Law, Technology & Society
Wikipedia - MIT License

readmeか何かにこんな感じに書けばいいとも読めるので、使用プラグインを隠蔽しようとする人が現れそうだなと思って
書いてないよりはいいんじゃないかと思いますけど。逆にそれじゃいけないっていうデータあるんですかね?

ちなみに僕がさっきから上げてる英文記事はNLnet財団Mozzilla財団などが出資しているサイトなので、十分に信頼に足る情報源だと思います。

都合よく解釈
都合よく解釈されたことが不服なのであれば、争えばいいんじゃないでしょうか。
曲解されたくないなら、曲解されないようにライセンスを組めばいいだけの話です。

むしろ曖昧に解釈可能なライセンスを使っているのに、自分が思う一つの解釈しか認めないのはヘンじゃないですか?
 
最後に編集:
これは余談です。

基本的に条文に書いてあること以上のことは要求できないですし、
条文が曖昧なら、解釈が人によって異なる上、対応方法も変わってしまうのは仕方のないことかと。

個人的解釈で「~するべきだ」とか言われても、自分がその解釈に同意しなければ守る義理はないですし、
結局は利用者に条文を読んでもらって解釈してもらうほかないです。

そういうところまでひっくるめて考えられないなら、
・配布するのをやめるか
・完全許可制で配布するか
・有料販売して購入者しか利用できないようにするか
・自分でライセンス作るか
・著作権を放棄するか
みたいなのを選んだほうが楽なんじゃないですかね。

実際、「書面による契約書を交わした人しか利用できない」という感じなら、
利用者の行動もいくらか強制や制限ができるんじゃないでしょうか。
そこまでのことを要求したいなら、オープンソースライセンスを使うべきではないことは分かると思います。

それに、どうせライセンスを注意して厳しく設定したとしても、利用者がそのとおりに利用するとは限りません
ライセンスの条文を曲解されて、守ったつもりになっているようなケースも当然あるでしょうし、
そもそも読んでない、理解していないっていうケースもあるでしょう。
なんか私怨とか不正なお金儲けのために、わざと違反して使う人が出てくる可能性も否定できません。

そういう場合は話し合いで解決するなり、相手が認めないなら裁判をするなりして争うしかないんじゃないですかね。
答えを決めるのは裁判所です


なんなら、JSONライセンスを見てください。
The Software shall be used for Good, not Evil.
(このライセンスは良いことに使うべきで、悪いことに使うべきではありません。)
「悪いことに使うべきではない」ですよ?

逆の立場に立って考えてみてください。
あなたが悪気なく作ったゲームにJSONライセンスのプラグインが使われていたとき、そのプラグインの作者から
「あなたのゲームは私のプラグインを、私にとって"悪いこと"に使っているから、訴えます!
とか言われたらどう思います?

なんやねんそれ。って思うでしょ

いろいろ解釈できてしまうライセンスを使うっていうことは、そういうことなんです。
 
最後に編集:

fspace

ユーザー
その表記方法って、ツクールMV/MZの credits.html の表記方法となにか違うんですかね?
直後に書かれている部分から拾うと、「オープンソースライブラリ名」や「配布元」あたりの記述がありません。

「どの部分」と書いたのが誤解させたかもしれませんが、主張としては最初に書いたときと同じで、「何に対する」という著作権表示や許諾表示の対象を明確に示す必要があるというものです。

「オープンソースライブラリ名」や「配布元」が書かれていればユーザは対象を特定できますし、プラグイン中にコメントで書かれている場合も、そのプラグインの内容が対象だとわかります。一方で、外部ファイルとして著作権表示や許諾表示だけを記述した場合、ゲーム中の何に対してその人が権利を持っているのかわかりません。これは著作権表示や許諾表示の意味をなしておらず、正当な表示とみなされないのではないかという主張です。


僕は、逐語的な条文テキストを含んでいるなら、別に一箇所にまとめられていても構わないと思いますし、
その表示がどの部分に適用されているのかを示す必要はないが、不安なら入れてもいいんじゃないの程度です。

条文にだって、「または」って書いてますし。「かつ」ではないです。
JavaScriptコードだったら必ずライセンス表記の位置を考えて配置しろとも書いてないわけですし。
一箇所にまとめてはならない、ソースコード中の該当コードを容易に特定できなければならない、ソースコード中のみならず重要な部分に記述しなければならない、ソースコード中の特定の場所に記述しなければならない、といった主張はしていません。


書いてないよりはいいんじゃないかと思いますけど。逆にそれじゃいけないっていうデータあるんですかね?
ありません。逆もまたしかりです。

明確な判例を自分は知りませんが、MITライセンスの目的からしてその使用方法はトラブルの原因になりそうだ、という意味で「ちょっと怪しい」と書きました。


ちなみに僕がさっきから上げてる英文記事はNLnet財団Mozzilla財団などが出資しているサイトなので、十分に信頼に足る情報源だと思います。
特に記事に反する主張をしたつもりはありません。一部の記述と結論くらいしか読んでいませんが、特に問題としている内容を扱った記事のようにも見えませんでした。もし該当する部分が存在するのであれば引用してもらえると助かります。


都合よく解釈されたことが不服なのであれば、争えばいいんじゃないでしょうか。
曲解されたくないなら、曲解されないようにライセンスを組めばいいだけの話です。

むしろ曖昧に解釈可能なライセンスを使っているのに、自分が思う一つの解釈しか認めないのはヘンじゃないですか?
「都合よく解釈」する対象ははどはどさんの書いた
コンテンツの利用者に向けて「このプラグインを使っています」と公表する必要もないです。
という記述であって、ライセンス条文ではないです。

「はどはどさんが記述した際の意図と一致しているかどうかは別として」という意味で書きました。


基本的に条文に書いてあること以上のことは要求できないですし、
条文が曖昧なら、解釈が人によって異なる上、対応方法も変わってしまうのは仕方のないことかと。

個人的解釈で「~するべきだ」とか言われても、自分がその解釈に同意しなければ守る義理はないですし、
結局は利用者に条文を読んでもらって解釈してもらうほかないです。

そういうところまでひっくるめて考えられないなら、
・配布するのをやめるか
・完全許可制で配布するか
・有料販売して購入者しか利用できないようにするか
・自分でライセンス作るか
・著作権を放棄するか
みたいなのを選んだほうが楽なんじゃないですかね。

実際、「書面による契約書を交わした人しか利用できない」という感じなら、
利用者の行動もいくらか強制や制限ができるんじゃないでしょうか。
そこまでのことを要求したいなら、オープンソースライセンスを使うべきではないことは分かると思います。

それに、どうせライセンスを注意して厳しく設定したとしても、利用者がそのとおりに利用するとは限りません
ライセンスの条文を曲解されて、守ったつもりになっているようなケースも当然あるでしょうし、
そもそも読んでない、理解していないっていうケースもあるでしょう。
なんか私怨とか不正なお金儲けのために、わざと違反して使う人が出てくる可能性も否定できません。

そういう場合は話し合いで解決するなり、相手が認めないなら裁判をするなりして争うしかないんじゃないですかね。
答えを決めるのは裁判所です

これはその通りで、MITライセンスは記述が曖昧だから使うべきでないと言ってしまうことはできますが、実際問題としてよく使われるライセンスですし、その解釈について考え、実際にトラブルが起こった際に裁判所がどう判断するのか推測しておくことは意味があると思います。

また、利用者側としては曖昧な部分に引っかからないように配慮して使用した方が安全です。その意味で、使用プラグインを隠蔽するのは結構危険なんじゃないかと思ってます。
 
「何に対する」という著作権表示や許諾表示の対象を明確に示す必要があるというものです。
では、僕が示した3つの例全てに、その要件が満たされていると思う根拠を教えていただけますか?

明確な判例を自分は知りませんが、MITライセンスの目的からしてその使用方法はトラブルの原因になりそうだ、という意味で「ちょっと怪しい」と書きました。
事実の話と気持ちの話は全く違うと思います。
実際にトラブルになった判例などがあれば議論できると思いますが、
なければ想像での終わりのない議論になるので、これ以上この件について話すのは意味ないかと。
「曖昧に解釈可能なライセンスを使うときは、それに伴うリスクに気をつけましょう」でおしまいです。

特に記事に反する主張をしたつもりはありません。一部の記述と結論くらいしか読んでいませんが、特に問題としている内容を扱った記事のようにも見えませんでした。もし該当する部分が存在するのであれば引用してもらえると助かります。
その事実確認ができなかったので、僕の提示したソースでは不十分だと感じているのかなと思っていました。

「都合よく解釈」する対象ははどはどさんの書いた
> コンテンツの利用者に向けて「このプラグインを使っています」と公表する必要もないです。
という記述であって、ライセンス条文ではないです。

「はどはどさんが記述した際の意図と一致しているかどうかは別として」という意味で書きました。
公表とは「世間一般に対し、表向きに発表すること」です。
内部ファイルにてライセンステキストの維持や一括リストアップを行うことは、「公表」であるとは思いません。
それは「記載」です

これはその通りで、MITライセンスは記述が曖昧だから使うべきでないと言ってしまうことはできますが、実際問題としてよく使われるライセンスですし、その解釈について考え、実際にトラブルが起こった際に裁判所がどう判断するのか推測しておくことは意味があると思います。

また、利用者側としては曖昧な部分に引っかからないように配慮して使用した方が安全です。その意味で、使用プラグインを隠蔽するのは結構危険なんじゃないかと思ってます。
僕も意味はあると思いますし、安全だとも思います。
しかし、提示している行為が使用プラグインの「隠蔽」に当たるかどうかは、データが足りないので判断しようがありません。
それが「隠蔽」に当たるという事実に基づく根拠が必要です。
 
最後に編集:

fspace

ユーザー
では、僕が示した3つの例全てに、その要件が満たされていると思う根拠を教えていただけますか?
すべて「オープンソースライブラリ名」が記載されているのではないでしょうか。

実際、はどはどさんがどのライブラリを対象とした著作権表示や許諾表示か特定できていますし。


事実の話と気持ちの話は全く違うと思います。
実際にトラブルになった判例などがあれば議論できると思いますが、
なければ想像での終わりのない議論になるので、これ以上この件について話すのは意味ないかと。
「曖昧に解釈可能なライセンスを使うときは、それに伴うリスクに気をつけましょう」でおしまいです。
まあ、これはそうですね。門外漢がいくら議論したところで裁判所がどう判断するかはわかりません。

「曖昧に解釈可能なライセンスを使うときは、それに伴うリスクに気をつけましょう」という結論にも異論ありません。元々指摘したのはこのリスクが高いと考えたからで、他の人がリスクを認識せずに使ってしまうとまずいと思ったからです。


公表とは「世間一般に対し、表向きに発表すること」です。
内部ファイルにてライセンステキストの維持や一括リストアップを行うことは、「公表」であるとは思いません。
それは「記載」です
法律周りで「公表」というと、「広く一般国民その他不特定多数の人々が知り得る状態に置くために一定の事項を示し、明らかにすること。」という意味がでてきますが、これとは違うということでしょうか。すみませんが、何をもって「公表」でないと判断していて、「記載」であることで何がどう変わるのかよく理解できませんでした。

「コンテンツ利用者に向けて『このプラグインを使っています』と記載する必要はある」という点で意見は一致しているということでしょうか。


しかし、提示している行為が使用プラグインの「隠蔽」に当たるかどうかは、データが足りないので判断しようがありません。
それが「隠蔽」に当たるという事実に基づく根拠が必要です。
念のため補足しておくと、「隠蔽」という目的や行為自体を問題視しているのではなく、その結果、著作権表示や許諾表示の対象がわからなくなってしまうことを問題視しています。それが「隠蔽」であったかどうかはここではどうでもいいのです。
 
すべて「オープンソースライブラリ名」が記載されているのではないでしょうか。
あー、意図していることがなんとなくわかってきました。

このゲームはMITライセンス(https://...)のプラグインを使用しています。
Copyright (c) 2021 XXX
Copyright (c) 2021 XXX
Copyright (c) 2021 XXX

この表記のXXXの中に著作者名とオープンソースライブラリ名が入るのなら、別に良いのではないかと僕は思っていたのですが、
そうではなく、XXXの中に著作権者しか入っていない状況のことを考えていた感じですかね。

僕が考えていたXXX適用例
このゲームはMITライセンス(https://opensource.org/licenses/mit-license.php)のプラグインを使用しています。
Copyright (c) 2021 トリアコンタン (BattleBalloon.js)
Copyright (c) 2021 トリアコンタン (AttackChain.js)
Copyright (c) 2021 くらむぼん (AudioSource.js: 特定の位置から音を鳴らすプラグイン)

あなたが意図していたと思われるXXX適用例
このゲームはMITライセンス(https://opensource.org/licenses/mit-license.php)のプラグインを使用しています。
Copyright (c) 2021 トリアコンタン
Copyright (c) 2021 くらむぼん

もし、この解釈で合っているのでしたら、紛らわしいので次から省略しないでいただけますか?
違う場合は、省略しない全文の例を書いてください。

法律周りで「公表」というと、「広く一般国民その他不特定多数の人々が知り得る状態に置くために一定の事項を示し、明らかにすること。」という意味がでてきますが、これとは違うということでしょうか。すみませんが、何をもって「公表」でないと判断していて、「記載」であることで何がどう変わるのかよく理解できませんでした。
逆にお聞きしますが、技術的なことがわからないツクールのブラウザゲームのプレイヤーが、
わざわざDevToolsやソースコードを開いて使用されているライブラリのライセンス表記が維持されているかどうかを
簡単に確認できると思いますかね?
僕はできないと思います。それは「人々に知り得る状態に置いている」とは思えません。

「広く一般国民その他不特定多数の人々が知り得る状態に置く」というのをツクールのブラウザゲームで行う場合、
ゲームの説明文に「使用したライブラリ/プラグイン一覧」と書いて記載したり、
ゲーム内の目立つところに常に著作権表記を行う所までやらなければ、
「広く一般国民その他不特定多数の人々が知り得る状態」に置かれているとは言えないのでは?

僕は、そこまでする必要は全く無いと思います。
公表とは、事前知識も何もいらず、表面から見ることが出来る状態のことを言うのではないでしょうか。

ちなみに、著作権法での「公表」は更に「著作者の許諾」が前提です
もしこの「公表」の定義を使用する場合も、例えばMITライセンス(許諾条件)に合意した以上ライセンスの記載は義務付けられていますし、
それを行った上で使用したライブラリやプラグインのライセンス情報を、
発行・上演・演奏・上映・公衆送信・口述・展示の方法で公衆に提示(=公表)するのは、人の自由であり義務ではないかと。
そうしろとライセンスに書いてるなら別ですけどね。

「コンテンツ利用者に向けて『このプラグインを使っています』と記載する必要はある」という点で意見は一致しているということでしょうか。
はい。

その結果、著作権表示や許諾表示の対象がわからなくなってしまうことを問題視しています。
この返信の頭で書いた解釈違いから察するに、
「対象」と「”わからなくなる”が誰目線なのか」という部分が僕の考えているものと違う可能性があるので、書いてもらえますか。

僕は「対象」については、「コンテンツに何のライブラリを使用しているか」だと考えていて、「どの行のどの文字から使用しているか」まで事細かに書く必要はないと考えています。
たとえばWebpackやUglifyなどを使用している場合、開発中のソースコード上では上部で使用されていたものが、難読化の結果どの部分に使用されているのか使用者自身でもわからなくなるケースもあると思います。
そういった場合でも、ライブラリに記載されていたライセンス文章を残したり、一括で1つのテキストファイルに書き出すなどすれば良いと思います。

そして「わからない」とは、「ライセンスの確認方法を知っている人が確認できない」状態だと考えています。
これに関しては上述のDevToolsのくだりを参照してください。
ゲームではなくプラグイン自体を編集する側の場合、ツクールのプラグイン設定画面の @help にMITライセンス文章が書かれていなくても、
プラグインそのもののコメントにきちんとMITライセンス文章が書かれていれば、MITライセンスに則っていると言えると思います。
 
最後に編集:

fspace

ユーザー
この表記のXXXの中に著作者名とオープンソースライブラリ名が入るのなら、別に良いのではないかと僕は思っていたのですが、
そうではなく、XXXの中に著作権者しか入っていない状況のことを考えていた感じですかね。
その通りです。


もし、この解釈で合っているのでしたら、紛らわしいので次から省略しないでいただけますか?
著作権表示を構成するのは著作権マーク、著作権者名、発行年の三つで、その他"Copyright"の文字や最終更新年を追加することはありますが、それ以上のものが含まれるのは特殊です。

また、XXXは省略ではなく伏字です。ひとつの伏字に複数の内容が含まれていると解釈される可能性までは考慮できませんし、考慮すべきとも思いません。


逆にお聞きしますが、技術的なことがわからないツクールのブラウザゲームのプレイヤーが、
わざわざDevToolsやソースコードを開いて使用されているライブラリのライセンス表記が維持されているかどうかを
簡単に確認できると思いますかね?
僕はできないと思います。それは「人々に知り得る状態に置いている」とは思えません。

「広く一般国民その他不特定多数の人々が知り得る状態に置く」というのをツクールのブラウザゲームで行う場合、
ゲームの説明文に「使用したライブラリ/プラグイン一覧」と書いて記載したり、
ゲーム内の目立つところに常に著作権表記を行う所までやらなければ、
「広く一般国民その他不特定多数の人々が知り得る状態」に置かれているとは言えないのでは?

僕は、そこまでする必要は全く無いと思います。
公表とは、事前知識も何もいらず、表面から見ることが出来る状態のことを言うのではないでしょうか。
なるほど、概ね理解しました。

その意味で公表する必要はないと言ったのであれば、特に異論はありません。


ちなみに、著作権法での「公表」は更に「著作者の許諾」が前提です
もしこの「公表」の定義を使用する場合も、例えばMITライセンス(許諾条件)に合意した以上ライセンスの記載は義務付けられていますし、
それを行った上で使用したライブラリやプラグインのライセンス情報を、
発行・上演・演奏・上映・公衆送信・口述・展示の方法で公衆に提示(=公表)するのは、人の自由であり義務ではないかと。
そうしろとライセンスに書いてるなら別ですけどね。
著作権法の「公表」は「著作物の公表」なので、ライセンス情報に適用するのはおかしいのでは?


この返信の頭で書いた解釈違いから察するに、
「対象」と「”わからなくなる”が誰目線なのか」という部分が僕の考えているものと違う可能性があるので、書いてもらえますか。

僕は「対象」については、「コンテンツに何のライブラリを使用しているか」だと考えていて、「どの行のどの文字から使用しているか」まで事細かに書く必要はないと考えています。
たとえばWebpackやUglifyなどを使用している場合、開発中のソースコード上では上部で使用されていたものが、難読化の結果どの部分に使用されているのか使用者自身でもわからなくなるケースもあると思います。
そういった場合でも、ライブラリに記載されていたライセンス文章を残したり、一括で1つのテキストファイルに書き出すなどすれば良いと思います。
一番初めに書いた通り、対象は「誰のどのプラグインを使っているか」です。

また、これも前に書きましたが、「ソースコード中の該当コードを容易に特定できなければならない」という主張はしていません。こう書いた意図は、はどはどさんが想定しているケースと同じです。


そして「わからない」とは、「ライセンスの確認方法を知っている人が確認できない」状態だと考えています。
これに関しては上述のDevToolsのくだりを参照してください。
ゲームではなくプラグイン自体を編集する側の場合、ツクールのプラグイン設定画面の @help にMITライセンス文章が書かれていなくても、
プラグインそのもののコメントにきちんとMITライセンス文章が書かれていれば、MITライセンスに則っていると言えると思います。
誰目線というよりも「確認する手段がない」という感じですね。

あるいは「確認する常識的な手段がない」と言った方が正確かもしれません。もちろん、条件を満たすためにソースコード内にMITライセンス文章を含めることは一般的なため、これを確認することは常識的な手段とみなされるという前提です。
 

温州みかん

ユーザー
宗教戦争が始まった(>_<)

眺めている分には楽しいので、もっとやってください


「著作者の権利」によって「保護」される「著作物」と認められるためには

1「思想又は感情」
2「創作的」
3「表現したもの」であって、
4「文芸、学術、美術又は音楽の範囲」に属するもの

以上の要件をすべて満たす必要があります(著作権法 第2条第1項第1号)

誰が書いても似たような構造や処理になってしまうメソッドの集合は、現行法の解釈上「著作物」として認められません
copyright ©マーク を付けて主張することは可能です
例 Copyright (C) 2021 Unshumikan All Rights Reserved.
アノテーションのauthorは著者というより記述者の意
プラグインを含むコンピュータ・プログラム全般も著作物として認められていますが、かなり高いハードルを越えたものに限られます
興味のある方は→https://system.jpaa.or.jp/patents_files_old/200706/jpaapatent200706_087-094.pdf (私はめんどくさくて途中で読むのをやめた それなりに古い情報 2000年代からはゲーム(特にグラフィック関連)を映画と同じ くくり で解釈することがおおい)

ときどき「一行追加プラグイン」を寄せていますが、私が著作権を主張しない、あるいはできないと考えているむねを表記しているのはこのような理由からです

なお、まるっと盗用はマナー違反で、別の問題です
 
著作権表示を構成するのは著作権マーク、著作権者名、発行年の三つで、その他"Copyright"の文字や最終更新年を追加することはありますが、それ以上のものが含まれるのは特殊です。

また、XXXは省略ではなく伏字です。ひとつの伏字に複数の内容が含まれていると解釈される可能性までは考慮できませんし、考慮すべきとも思いません。
よくわかりました。まあそこは本題じゃないのでもういいです。

著作権法の「公表」は「著作物の公表」なので、ライセンス情報に適用するのはおかしいのでは?
はい。まさか言ってこないだろうなとはおもいつつ、一応書いておいただけです。
それをおかしいと考えているのであれば、問題ありません。

誰目線というよりも「確認する手段がない」という感じですね。

あるいは「確認する常識的な手段がない」と言った方が正確かもしれません。もちろん、条件を満たすためにソースコード内にMITライセンス文章を含めることは一般的なため、これを確認することは常識的な手段とみなされるという前提です。
「対象」の定義については僕と同意ということで問題ないですか?

宗教戦争が始まった(>_<)

眺めている分には楽しいので、もっとやってください
別に宗教戦争をやっているつもりはないですよ。
「何を言っているのかよくわからない」部分を一つ一つ潰していっているだけです。

たぶん、基本的な考え方そのものは同じだと思うんですよね。
微妙な解釈・捉え方・話の切り込み方・話の聞き方・言い方・善悪や道理の定義等が違うというだけで。
別に対立するつもりもないですし、むしろ歩み寄っていますよ。
 
最後に編集:
トップ