2024-03-16

ライセンス(利用規約)の問い合わせ対応は難しい

先日の合成音声界隈の騒動にはびっくりしました。 → ずんだもん立ち絵の件 - Togetter

最初に訂正を入れるときに「これは間違ってて」的な文章ではなく「利用方法としては問題ないのだけど、ツイートされてる解釈は間違ってて」的な言い方ならここまでこじれることもなかったのではないかなあと思いますが、同時に「利用方法としては問題ない」と個別の事例に踏み込むのが難しいことは僕自身の過去の失敗からわかっており、つまり難しい問題なのです。

10年以上前ですが「あなたのアプリの紹介記事を書いてよいか？その中でスクリーンショットを使ってよいか？」という問い合わせを受けて、おおむね

個別に許可を出していません。ライセンスをご覧ください。

のような返信をしたら話が立ち消えてしまいました。自分としては「いいですよ、勝手にやってください」程度のつもりだったので当時は相手方がバカだなあと思ってましたが、これは返信が悪いですね。

なぜこういう返信を書いてしまうかというと、個別に許可を出すと

意図より広い範囲について許可したことになっちゃうかも。この記事について許可したつもりが、文面をよく読むと相手が今後書く全ての記事に対する許可を与えたことになっちゃうとか。
ライセンスの一般的な解釈とズレてしまうかも。GPLのようなライセンス自体の解釈は専門家にやってほしいことで、権利を持ってるからといって開発者個人に聞かれても困る。
以前は許可を出したのに今度のには出さないのか、基準はどうなっているのかと追求されるかも。
たくさん問い合わせが来ると処理しきれなくなるかも。

といった懸念があります。何かのロイヤリティを受け取るための審査ならともかく無料で配ってほぼなんでもしていいソフトウェアについてこんなことはやってられません。

じゃあ今ならどのように回答するかというと、たぶん

個別の審査はしていません。ライセンスを読んでご自身で判断してください。万が一問題があれば改めて連絡することがあります。

くらいでしょうかね。ただこれが

無料素材と有料サービスの組み合わせによるビジネス
相手の解釈の一部を否定し、残りを「判断しない」にする場合
第三者からの規約違反の「通報」
第三者から規約違反だと叩かれているところに「違反ではない」と割って入る場合
今回のようにトラブルが発生していて沈静化を図らねばならない場合

となると格段に難易度が上がると思います。

OSSライセンスの教科書

作者:上田理
技術評論社

Amazon

2024-03-13

暗証番号を暗号化するPythonスクリプトとAndroidアプリ

クレジットカードとか銀行のキャッシュカードとか数が多いと暗証番号を覚えるのも一苦労です。僕は合計20枚持っているようです。全部同じにしちゃうという作戦もありますが、なるべく分けておきたいですね。でも普段使っていないカードは忘れるでしょ。メモしておくとセキュリティが不安だし。というわけで暗証番号を暗号化すればちょっと安心じゃないでしょうか。

暗証番号を4643とします。ビョウキ、トシヨリ、ヨロシサンなので覚えやすいですね。でもこれをそのままメモするのは危険です。パスワードninjaで暗号化すると2556となるので、これをメモすればちょっと安心な気がします。暗証番号を忘れてしまったときは2556とninjaを入力して復号すると 4643 6235 7754 という3つの候補が現れます。候補がいくつ出るかは元の暗証番号とパスワード次第。あとは記憶を頼りに4643という暗証番号を思い出せばよいというわけ。

暗号化した暗証番号のリストが流出した場合、パスワードが同じだと1つ復号に成功すれば芋蔓式に全部解読されてしまうので、本当の意味で安全かというとあんまりそんなことはないんじゃないでしょうか。自己責任でご利用くださいね。

クレジットカードケース／キーケース一体型本革黒財布RFIDケース5枚付スキミング防止磁気防止じゃばら大容量

LEAUX

Amazon

2024-01-14

独自ドメインのGmailのDMARCとかの設定

Gmailに「Gmail を使用して他のメールアドレスからメールを送信します」って機能があるけど、これってGmailのSMTPサーバーから送信してるから送信元を証明するあれこれのDNS設定と合致しなくてエラーになるよね、って話。Gmailの問題なんだからGmailがちゃんと対応すべきだと思うんだけど、中の人の気持ちになって考えるとなんの設定もせずGmailのSMTPサーバーが使えてたのは10年前とかなので、いい加減現代の設定でやり直せよってことかもしれない。

DNSの設定

正直よくわからないのでこの辺を見て適当に。

DKIMのツールだけど、公開鍵？を生成してもすぐにUIに反映されないので、もう1回生成すると1つ前の文字列が出てきて、それをDNSに設定してもダメという挙動をしてて、気がつくのにだいぶ時間がかかりました。

SMTPサーバーの設定

理屈としてはこの辺の合わせ技です。

手順としてはこんな感じ。

Google Workspace 側のユーザーでアプリパスワードを生成。こういうのOAuth的なやつで必要な権限だけ渡すとかできないんですかねえ
Gmail側のユーザーで「Gmail を使用して他のメールアドレスからメールを送信します」からSMTPサーバーを設定する
テストメールを送ってみたらFromが Google Workspace 側のユーザーになってる(Fromにしたかったものが X-Google-Original-From になってる)ので、ちょっといじりたい
Google Workspace の管理者ツールで「予備のメールアドレス」を設定。複数設定するときには複数まとめて設定しないとダメ
Google Workspace 側の「example.com メールを使用して他のメールアドレスからメールを送信します」から予備のメールアドレスを登録
テストメールを送ってみたらFromが出したかったアドレスになってる。ソースを見ても Google Workspace 側のユーザーのアドレスは出てない
予備のメールアドレスはエイリアスなので、そのアドレスに送ると Google Workspace 側のユーザーに届く。必要に応じて転送設定を調整する

でもまあいろいろ考えると Google Workspace 側のユーザーからメールを送信するのが一番シンプルでよさそうなので、そのようにした。

うずまきエアメール【ワンタッチ】封筒洋型２号 10枚入り

うずまき

Amazon

2023-11-27

近所のスーパーのレジの分岐が本当に嫌

疑似コードで書くと

if 「ポイントカードはお持ちですか？」と聞かれる {
    // 嫌なルートに入りそうだなと思って嫌な気分になりつつ
    say("はい")

    if こっちを覗き込んで「ポイントカードはお持ちではないですか？」と聞かれる {
    // 嫌なルートほぼ確定だなとすごく嫌な気分になりつつ
    say("持ってますよ")

        if 「ポイントカードを出してください」と言われる {
            // 嫌なルートほぼ確定だなとすごくすごく嫌な気分になりつつ
            ポイントカードを渡す

            if 「支払い方法はどうしますか？」と聞かれる {
                // 本当に嫌な気分で
                tmp := 「合計金額を見て決めます」という主旨のことをその場で考えて捻り出す
                say(tmp)
            }
        }
    }
}

if 合計金額がポイントカードを使った方が得な場合 {
    say("ポイントとクレジットカードで")
} else {
    say("クレジットカードで")
}

みたいな感じ。予め決めてあった言葉、しかも20年近く使ってきた決まり文句を言うならともかく、その場で考えて会話しなけりゃならないの嫌で嫌で仕方ない。毎回聞かれるならまだ諦めもつくが、人によって聞かれたり聞かれなかったりするため分岐が増えるのも嫌だ。

セガトイズ(SEGA TOYS) アンパンマンおさつスイスイ! セルフでピピッアンパンマンレジスター

セガトイズ(SEGA TOYS)

Amazon

2023-08-20

東京近くのナマズ料理のメモ

ナマズは普通の白身魚なんですが、食感がよくて味にクセがなくて美味しいです。何箇所か行ったのでメモ。

埼玉県吉川市

養殖ナマズの生産地で、ナマズ料理を出す店もたくさんあるのですが、何種類もの料理があるのはこの御三家だけのようです。

東京からだと武蔵野線でぐるっと回っていったりして微妙に遠いんですよね。駅からも微妙に遠いのでタクシーに乗ろうとしたら乗り場で待ってなかくて時間がかかったことも。たぶん車で行くと便利なのだと思います。

コース料理なら分量考えつつ注文しなくていいし、いろんな料理が出てくるので初心者にはお勧めの店です。

ますや

2回行ったのかな。ボリュームがあるのでご飯追加しない方がいいですよって言ってたけど実際そうでした。1人だったので予約なしで行ったのですが、本当は予約した方がいいのかな。

糀家

クラシックな料亭。予約なしで行ったこともありますが予約した方がいいと思います(1人でも大丈夫)。たぶん一番多く行ってるんじゃないかな。

福寿家

最近リフォームしたのかモダンな料亭です。ここも予約すべきでしょう(完全個室のように書いてありますが1人でも大丈夫です)。

なまずの薄造り(刺身)は4名以上となっていますが、どうも生食用のナマズを捌くので1人分だと余りが出て困るからということのようです。店員さん曰く1人で4人前食べるなら注文してもいいですよとのこと。他にも料理があるので1人では食べ切れないと思いますが、2人で2人前ずつ食べる人はいるそうです。4人未満の場合は海の魚のお刺身になりますが、隠し包丁？が入っててなんかすごかったです。

お刺身の隠し包丁？もそうなんですけど、前菜の盛り付けとか、日本酒を氷で冷やすワインクーラーにお花が入ってるとか、料亭というだけあってモダンで高級感あるお店です。部屋によっては近くに流れる中川がよく見えます。

東京下町のなまず鍋

東京下町の郷土料理らしいです。料理自体に個性があるので、あまり初心者向けではないように思います。

駒形どぜう

冬季限定だからかメニューに載ってないですね(あるいはもう扱ってないのかも)。床の高さに鍋を置く席になったので食べにくかったのを覚えてます。

どじょっこ

なまず鍋となまず唐揚げがあります。いまホームページを見たら「本日20日は(略)天然なまずの入荷有りません」と注意書きがあったので日によるようです。珍しく天然なまずを取り扱ってます。なまずの唐揚げはここでしか食べてないですね。

鹿島神宮周辺

霞ヶ浦でナマズの養殖をしているそうで、霞ヶ浦をぐるっと周ればいろんなお店があるのですが、電車やバスでの移動を考えるとなかなか難しいです。やはり自動車で来るべきではないでしょうか。今回は交通の便がよかった鹿島神宮周辺に行きました。

東京駅から高速バスで2000円くらいです。電車より高速バスの方が本数が多いという。鹿島神宮駅を拠点にしてタクシーで移動してると片道2000円みたいな場所も平気であって、バスの安さを感じます。

昼と夜で2店舗ハシゴするというのがケチでダメな発想で、一泊二日でがっつり食べるべきでした。いずれリベンジしたい。

鈴章

昼だったので「なまずミニコース」にしたのですが、「なまずコース」でがっつり行くべきでした。確かミニコースしかメニューになかったんですよね。ランチだったからかなあ。

レストパーク四季

量がわからなかったのでなまず天定食(しじみ汁付き)になまずこく汁を追加しただけにしたのですが、これも作戦ミスでした。定食ではなくナマズ料理単品で全種類食べるみたいな構成にすべきでしたね。なまずこく汁は特においしかったです。

本気で駅から遠いのでタクシー必須です(帰るときはお店の人に呼んでもらいましょう)。

外国料理

地域別に分類したいのですが神奈川・東京・埼玉に複数店舗あるお店のため。

チンタジャワカフェ

インドネシア料理です。ナマズを開いて1匹丸ごと？揚げたものです。ご飯がつきます。ソースは無茶苦茶辛いので僕はつけませんでした。全体的にはカレイの空揚げみたいな感じでした。

撒椒小酒館

中華料理(四川料理・重慶料理)です。メニューには明記されてないけどたぶんナマズだと思います。ナマズを開いて一匹丸ごと？揚げてスープで煮込んだものです。辛いけど後に残るような辛さではなくおいしかったです。他の料理を頼まないのであれば1人で鍋1つ食べ切れます。ベトナムから輸入しているそうです。

パンガシウスキャットフィッシュフィレ骨皮なし 850g 総重量1㎏なまずナマズ白身魚

ラス

Amazon

2023-08-04

FANBOXのAI生成作品取り扱い禁止の建前と本音を考える

7月末にpixivFANBOXでAI生成作品の取り扱いが禁止になったのですが、そこに至るまでの理論武装がよくわからなくて困惑してたんですよね。改めて考えてみました。

具体的には方針の告知の

FANBOXは、ファンからの継続的な支援によって、クリエイターの創作活動をより良いものにしていきたい、そのような思いで始まったサービスです。

クリエイターの皆さまには作品の公開に限らず、作品づくりの過程や考えなどを発信することを通して、ご自身を応援してくれるファンの皆さまとコミュニティを作っていただきたいと思っています。

しかし現在のFANBOXでは、生成AI技術により短期間で大量に作成されたコンテンツを販売することのみを目的に利用されることが多く、今後もその傾向はより強まっていくと感じています。それは本来私たちが目指していたサービスの姿とは異なり、このまま見過ごすことはできないと判断しました。

そのため、FANBOXにおいてAI生成作品の取り扱いを当面のあいだ禁止させていただくことにいたします。

が全ての理由になってると思うのですが正直意味がわからないので頑張って解読していこうと。

困惑してたこと

方針の告知では「継続的な支援をするところなので、コンテンツを販売を目的とするのはダメ」と読めたのに、規約改訂の予告では「支援金を集めるばかりでコンテンツを出さないのはダメ」と読めて、え？どっちなの？ということ
方針の告知では「大量に画像をアップロードするので困ってます」という話なのかと思ってたらAI生成コンテンツの定義ではアイコンなども対象になっていて意図がわからないということ。これはAIユーザーが記事を消したのにクリエイターアカウントが停止されたと騒いでたので気付きました。アイコンが対象であるというのは規約改定の予告には書いてないし、直接リンクもされてないので気付かない人が多かったと思います

本音を想像する

おそらく「不正利用」を防ぐことが目的だと思います。ここでいう不正利用は2つの類型があって

フィッシング等によって取得したカード情報を使って現金化するケース。この被害は加盟店側(=pixiv)が負担することになる
送金ツールとして使われると行政から資金移動業とみなされて規制を受ける恐れがあるのではないか。将来的に制度が変わったら免許証等で本人確認しないと支援できないとかになるかもしれない

どちらも現金化の受け口としてFANBOXを使う想定です。不正利用かどうかを判断するのは難しいですが、それぞれのパターンごとに

お手軽に適当なコンテンツをアップロードしてガンガン支援してたら怪しい。コンテンツなしでの支援も怪しい。十分に時間をかけて作った十分な品質のコンテンツならたぶん大丈夫という近似的判断
十分に時間をかけて作った十分な品質のコンテンツを見るための支払いであって送金ではないですよという理論武装

で対抗するんじゃないかと思います。どちらも「十分に時間をかけて作った十分な品質のコンテンツ」を期待しているので、短時間で作った(=あんまりガチャ引いてない・修正してない)質の低い(=細部が破綻している)AIイラストは排除したいと。ただし絵の品質に基準を設けると審査が難しいし、人間の描いた絵にも波及しかねないからAIイラストは一律禁止。あとコンテンツが外部にあるとFANBOXを送金ツールとして使ってることになるのでそれもダメ。

一方で「十分に時間をかけて作った十分な品質のコンテンツを出せ」と言ってるとクリエイターにプレッシャーがかかるし、支援者もコンテンツの質や量が不足すると支援をやめてしまうだろうから「支援サイトです。支援に対してお例のイラストがもらえることがあります。品質は問わないし毎月更新しなくていいです」と言う必要もあって、なかなか強い言葉で説明できないのだと思います。

別の話としてアップロードされる画像が大量にあって(実写ポルノ画像が紛れてないかなどを)チェックするのが大変じゃなんじゃないでしょうか。ストレージや通信量のコスト増加もあるかもしれません。

想像した本音で告知を読み直す

想像に想像を重ねると

方針の告知では「1枚あたりの作成時間が少ないコンテンツを投稿するのはダメ」と言いたい
規約改訂の予告では「送金ツールとして使うのはダメ」と言いたい
AIイラストをアイコンにしているアカウントは、どうせ十分に時間をかけて作った十分な品質のコンテンツを投稿できないだろうから予防的に停止する

ということなんじゃないかと思います。

建前の不明瞭さ

肌感覚ではAIユーザーは自らをクリエイターと考えていて、FANBOXはそうではないと考えているのでそこに齟齬があるようには思ってます。なので「AIユーザーは本サービスでいうところのクリエイターではないので」と明言すれば

AIイラストを投稿するのはダメ
外部で活動するAIユーザーが支援金を受け取るのはダメ
AIイラストをアイコンにするのはダメ

が全部説明できて一本筋が通ると思うのですが、AIの技術解説はOKという基準とは矛盾するので無理があるかな。当初は「漫画家やイラストレーターがAIの技術解説を書く分にはOK」くらいの基準なのかと思ってたのですが、どうやらAI専門の人でも生き残ってるようなので。

この記事で書いた本音はただの想像なので、建前の世界で筋が通っていてほしいのですけれども。方針の告知を見ると

AIイラストだけではなく日記的な記事を書けばセーフと読める (一般的には日記だけどAIユーザーに対してはそれが技術解説なのか？)
作品の公開・販売を主目的にする一般のクリエイターにも飛び火しないか？

というあたりがどうにも謎ですね。

AIアートの新時代: CLIPとStable Diffusionを活用した画像生成技術とその応用

作者:koshian2
Independently published

Amazon

2022-12-04

友達(ときに幼馴染)が恋人になる漫画や小説

最近恋愛漫画を読むようになったのだけど、たぶんこれは老化現象だなと。いままでは「敵と戦ううちに進展する主人公とヒロインの関係がいいよな」みたいな見方をしてたんだけど「読むの疲れるからそこだけ煮詰めて出してくれ」って感じになっているのではないか。煮詰めて濃くなったスープを飲んでるのでそれはそれでダメージが大きいのだけど。で、ある意味当然なのだけど、友達(ときに幼馴染)が恋人になる作品を度々目にするので、今年読んだものを並べてみる。