パスワードを忘れた? アカウント作成

m_nukazawaさんのトモダチの日記みんなの日記も見てね。 アカウントを作成して、スラドのモデレーションと日記の輪に参加しよう。

13265992 journal
日記

m_nukazawaの日記: Edge of exceptional exception(草稿) 1

日記 by m_nukazawa

きっかけは、会社で昼休み中に見つけたTogetterのこのまとめ。曰く、bashシェルスクリプトを書く際、何も考えずに`set -e`を頼るのはよくないのではないか、という。

挙げられている理由は大きく2つ。
ひとつ目は、エラーこそが欲しい結果である場合。あるいはvariant型の偉大な力によって、出力がエラーに変換されてしまう等の場合があること。途中解で意図的にエラーを使うことが難しく、シェルスクリプトに書ける処理が制約を受けてしまう。
もうひとつは、`set -e`には思いもよらない挙動が多く、シェルスクリプト関数の中などでプログラマの思う通りにエラーを捕捉してくれない場合があるのだという。もしその通りであるのなら、確かにエラー処理として頼るには心もとないかもしれない。
まとめ中では、`set -e`を使ってまとめてエラーを処理しようとせず、コマンドまたはパイプ終端ごとにひとつずつ、確実にエラー処理を書くことを推奨していた。

一通りTogetterを読み終わり、得た情報を元に、いま使っているシェルスクリプトを精査すべきか少し考えてみた。
まず、仕事のプロジェクト。こちらは問題無さそうだった。
次に、趣味のプロジェクト群。vecterionでは、テストの一部やビルドシステムの外苑にbashシェルスクリプトが組み付けられている。またRuneAMN等のFont系のプロジェクトではbashシェルスクリプトがビルドシステムのグルーとして重要な役割を果たしている。vecterionのテストスクリプトはTDDよろしくエラーが出るのを確認しながら書いた。Fontのビルドシステムは、最終的にフォントが出力されれば良いのであって、多くの場合、結果を見れば問題があることは一目瞭然にわかる。
`set -e`は強力なエラー処理方法だ。エラー処理がスクリプト先頭のtrapにまとまるので、コードが読みやすくなる。コマンド行毎に終了コードのチェックを入れたら、シェルスクリプトの可読性が下がってしまう。
結論として、わたしは`set -e`を使い続けることにした。確かに危険はあるのだろうが、今のところ問題は起こっていない。たぶんコントロール可能な範囲だろう。bashシェルスクリプトで関数なんて書かないし(そうでもないかな...ちょっと心配)。
プログラマがエッジケースの存在を知ってさえいれば、問題にハマって時間をいたずらに費やしてしまう心配はない。次からは気をつけよう、というか、今度、予想と違うことが起こった時には`set -e`を疑って、Web上の情報を探しなおせば良い。具体的な問題と回避方法は、実例から失敗を学んだほうが覚えも良いだろう。
こうして『`set -e`不要論』は昼休みのネットサーフィンの収穫として、ちょっとしたAssertionとまあまあの満足感を与えてくれた。その時はそれで終わった。

帰宅後、ターミナルを叩いて謹製のMakefileが自作フォントを吐き出す様子を眺めていた。Makefileがotfフォントファイルを生成する様は若干倒錯的だ。わたしは小さな幸福感に浸っていた。
そのとき、ふと昼に見た『`set -e`費用論』を思い出した。例外的な状況では、`set -e`が意図通りに働かない場合があること。いや、例外的というほど特別な状況ではなくて、普通のシェルスクリプトを書いていて起こりうるシチュエーションなのではないか。学習効率は置いておいて、いちど、ケース集に目を通すべきだろうか。
そのとき脳内でWarningが上がった。エラー発生箇所、つまり直前の思考の文字出力へ意識がジャンプする。

例外的?
`set -e`は例外に似ている。

exceptionのイメージが脳裏に去来する。言語構文に定義された例外。C++は気が乗らない。エラー処理のベストプラクティス。握り潰し。OSによるエラーダイアログ。
`set -e`も例外も、戻り値のチェックからコードとプログラマを開放してくれる。エラー処理を正常系と書き分けることで、正常系の流れが読み取りやすいコードになる。可読性が高くなればコードの保守性も高まる。コード内のすべてのエラーを自動的に捕捉することで、プログラマのミスによるエラー処理漏れを起こさなくする。
完璧なコードを書けない私たち。不完全な人間のためのすばらしいソリューション。ただしそれは、人間に完璧なエラー処理のコーディングを要求する。
十分に理解のあるプログラマが扱うならば、例外は安全で有用なものであり、`set -e`は理想通りにすべてのエラーを捕捉してくれる。例外をハンドリングしきれずに握り潰してしまうプログラマと、`set -e`のエッジケースをすべて把握しておくことのできないプログラマの側に問題がある。だが、その考えは問題を言語から追い出しただけで、問題を解決したわけではない。でもエラー処理を書かなくて良いのは楽で良いよね。
例外を諦め、簡潔だった正常系が長大な異常系への対処コードに無残に切り刻まれて埋もれることを受け入れて、関数を呼び出す度に戻り値をチェックするコードを丁寧に書くべきだ。
『今度は例外なしでやりましょうよ』。自分が先週、言ったばかりのセリフを思い出す。

自分はどちらを支持しているのだ?

例外をことさらに嫌悪しておきながら、他方で似た機能である`set -e`を擁護している自分に気づく。少なからず心がざわついた。

両者には違いもある。例外はtry{}catch{}構文で、エラー処理は後に来る。例外は回復できる。通常処理に復帰するためにあるとも言える。
`set -e`は先に来る。わたしはtrapを一緒に使ってエラーの発生行を示し、そして通常処理に戻らず終了する。事実上のクラッシュ。
```
    3 set -ue¬
    4 ¬
    5 trap 'echo "$0(${LINENO}) ${BASH_COMMAND}"' ERR¬
```
『エラーが起こったら、直ちにけたたましく警告を出し、そして速やかにクラッシュするべし』というのはUnix思想のプラクティスだったか。
エラーに陥ると、通常処理への復帰は難しい。復帰したつもりになって、床に落ちたアイスクリームを塗り広げる掃除ロボットのようなことになっては目も当てられない。
`set -e`はクラッシュを起こすための仕組みであり、例外はエラーから回復するための構文だ。前者はシンプルで、後者は複雑になりやすい。複雑な例外処理はエラーにバグの上塗りをするリスクが高く、見た目にも汚いコードになる傾向が強い。小学校で雑巾が嫌われるのを見るようだ。床拭きにはクイックルワイパーを使って、掃除が終わったらゴミ箱に捨ててしまえばいい。
あのJoel社長がむかし書いていたような気がする。『やっつけのスクリプトを例外を使って書くのはすばらしい。そしてそのコードが翌朝クラッシュしていたら、その時はやれやれと言いながら人間が対処する。それで何の問題もない』

それはその日、同僚と話していた話を思い出させる。サーバのサンプルコードには、実用性に一歩足りないところがあるという話だ。サーバアプリケーションが立ち上がり、クライアントとソケットを生成する。クライアントが処理を終え、サーバとのソケットを切断し、サーバはクライアントへのサービスで使用したすべての資源をクローズする。そしてサンプルコードは終了する。
そして、現実のサーバプログラムはサンプルコードのようには終わらない。人生は続いていく。サーバは次のクライアントを、その次のクライアントを、次の次のクライアントを待ち受けるために、自分を最初の状態にResetできなければならない。すべての資源を綺麗にクローズして初期状態に戻り、無限にループしていなければならない。だが正しいクローズは正常系でも難しい。ファイルディスクリプタのクローズ、シェアードメモリの参照カウントのデクリメント、読みかけのシリアルの破棄、fflash(3)、mallocしたメモリのfree、立てたままのpthreadの停止と削除、閉じっぱなしのMutexの開放に、アプリケーション内部の状態遷移の初期化。サンプルコードは、それらをすべてほったらかしたままExitすることで、後始末をOSに移譲する。
サンプルコードとしては正しい。サーバとしての役割を終えるところまでを一旦説明する説明の順番も、わかりやすくてありがたい。だが実用コードへ向けてもう一歩、難しいところの解説が必要なはずなのに、サンプルコードは優しげな顔をしたまま、これがすべてで十分と言わんばかりに、一番難しくて大切なところを説明してくれないで終わっている。

正常終了して正常処理に復帰するのは、かように難しい。いわんや、異常状態から正常処理へ復帰することの困難さよ。

思えば例外は、C++とJavaの目玉機能だった。エラー処理を簡略化する、銀の弾丸。少なくとも、わたしが例外を知ったのはC++には例外が有るという紹介からだ。
Javaは銀行のバッチシステムに採用された。それは、決してクラッシュしてはいけないシステムだった。大量の量産型Javaプログラマは例外を憎むことを知らなかったが、産業プログラミング業界にとっては新しいアイデアだった例外を彼らに教えるときに、例外の正しいハンドリング方法を教え損ねた。結果、無垢な量産型Javaプログラマたちは、あらゆるJavaの例外を単に『握り潰した』。
結果としてJavaの例外は、`set -e`したやっつけのbashスクリプトに劣る安全性を、銀行のバッチシステムにもたらした。少しは出来るシステムエンジニアが、再現性の低いデータ破壊を起こすJavaアプリケーションをデバッグしていて、まったく関係ないはずの箇所の関数呼び出しの奥底で、Javaプログラマがゼロ除算例外を握り潰しているのを発見した時の感情は、察するに余り有る。
C++はシステムプログラミング言語だった。`set -e`と異なり、あらゆるエッジケースで動作する回復可能な例外を実現するために、C++の例外はシステムプログラミングにはとてもではないが採用できない重装備なギミックになった。
組み込みエンジニアはC++の例外と、ついでにC++に対して期待を寄せることをやめた。無言で静かに首を横に振り、穏やかなC言語の世界に戻っていった。

結果的に、例外はその真価を発揮できない用途で、使い方が周知される前に普及してしまった。神速の重装騎兵に馬を降りて城塞拠点を守らせるようなミスマッチが、例外というアイデアから力を奪った。関数の戻り値を処理することのできない無知なプログラマが書いたゴミコードの責任を、例外は押し付けられた。
この状況下で、プログラマが例外を愛することは難しい。業界が、例外への強く深刻な嫌悪を生み出した。

例外というアイデアが過去の汚名を払拭し、古くて新しいアイデアとして再び脚光を浴びる日がきっとくる。それは、私たちが思うほど遠い未来ではないのだろう。だが、その日は明日にはまだ来ない。

まだエラー処理とそうでない何かを混同している気がするけれど、まあ間違っていれば指摘があるだろうから、これくらいで。

結論。
`set -e`不要論から始まった一連の連想のおかげで、例外に対する不要な嫌悪感に気づき、それを払拭することができた。例外は実は良いものだった。ただし、ただちにクラッシュするために使い、ただちにクラッシュできる用途に用いるならば。
さもなければ、例外は福音よりも多くの災厄を産み出すだろうから。

====
今年も夏がやって来ます。そろそろproject daisy bellに新しいメニューを増やしたいという機運もあり、ポエム、はじめました。
皆様のお口に合いますよう。ご愛顧頂ければ幸いです。

13263381 journal
日記

m_nukazawaの日記: RuneAMN PixelArticデザイン中

日記 by m_nukazawa

間隔pixelを指定する引数を書き換えては画像出力を確認する繰り返しは、確かにデザイン作業なのだけれど、一般に想像されるデザインの工程とは違う気がする。

というわけで、ドット絵風なルーン文字フォント、RuneAMN_PixelArticを製造しています。
進捗等はtwitterに上げているであるとか、最近話題だったので作ったmastdon/pawooに上げたりしています。

pawooのほうは少し期待したのですが、力量不足によるものか、肝心のターゲットであるレトロゲームファンやドット絵風のデザインをしている方に反応がもらえなくて悲しい。
それはともかく。

ざっくりデザインしてみて思ったのは、ピクセル風デザインをモノクロ2値で作るとき、簡単な要素でそれらしく見えるよう、ピクセルを示す四角の間隔をあけるデザインにしているのですが、この間隔の幅が難しい。
画面に比較的大きく表示する場合、間隔を開けすぎるとルーン文字らしく見えなくなってしまう。その一方で、幅を狭めすぎると、SNSなどで縮小画像で表示された際に、間隔が潰れて、単なるルーン文字になってしまい、肝心のドット絵風デザインにならない。
ある意味、とてもわかりやすいトレードオフ。

今はもう、諦めて両方のサイズを用意すれば? という意見に傾きつつあります。もし良いアイデアがありましたら、教えてください。

// サイズ可変なフォントにすれば、というのはちょっとパスの方向で...根本的には2~N種類のサイズのフォントを個別に用意するのと変わらないですし。

13261578 journal
日記

m_nukazawaの日記: AndroidSDK触るだけ 3

日記 by m_nukazawa

いまさら周回遅れながらAndroidSDK。ネットワークからのダウンロードに失敗することが多く、デフォルト設定ではネットワーク接続できず、同じことを何度か再施行すると上手く行く。

AndroidSDK、落ちるわけではないし、マルチプラットフォームなのはすごいけれど、皆さんよくこれで開発しているなあと関心する次第。
Install Android Studio 2.3.1 to Ubuntu16.04LTS

// コレ以外のgoogleプロダクトでもいろいろあった結果、「google、もしかしてネットワーク周り弱い会社なのか?」 という感覚が芽生えつつあり、困惑している。

13258314 journal
日記

m_nukazawaの日記: 募集:Androidとgoogle音声入力で長文を書きたい 5

日記 by m_nukazawa

どなたか良いアプリケーションをご存知でしたら教えてください。
要望としては、
- 改行できる
- 句読点"。"等が入れられる
- google音声入力を使っている(独自の音声入力エンジンとか使っていない...精度が良いならまあ可)

といったところです。

通勤中とか移動中に、ブログとか、メモより長い文章の下書きをしたいのです。

自分でAndroidアプリケーションで作ったほうが早いでしょうか?
// 簡単そうなので作ろうかと思っている、が、簡単すぎるので絶対に既にあると考えている。

13249202 journal
日記

m_nukazawaの日記: cudaと再会 4

日記 by m_nukazawa

機械学習、やれるようになっておいてよ、という要望もあって、でもしばらくぼうっとしていたらzi2ziが出てきたので、おっとり刀で駆けつけた次第。

とりあえず1050Tiを購入。
前回外付けGPUを個人的に買ったのも、もう昔のこと(オンボードグラフィック派)。

cuda、インストールが楽になってる。
昔はドライバとドライバツールキットか何かとcudaの3つを別々にインストールしなければならなかったし、その時はXを切らなければならず、インストールの順番を間違えるとやり直しだった。

今はUbuntu向けにパッケージがある。

サンプルコード群は足りないライブラリがあるそうでビルドが途中で落ちたけれど、deviceQueryと対面してインストール成功を確認。

zi2ziと数式フォントの組み合わせは、twitterにお試し結果を上げてみたら、興味を持った方が本格的に回し始めてくださったので、さてどうしようかなといったところ。
https://twitter.com/mimighost008/status/854751340433596416

とりあえず、いまさらTensorFlowのチュートリアルを読む。

13223185 journal
日記

m_nukazawaの日記: 技術書典行ってきました 1

日記 by m_nukazawa

レポートというわけでもないですが、まあ。
他の人の感想も聞きたい。

動機は、外出の理由付け、技術系同人誌に興味がある(が公式サイトだと出展内容が一覧できない)、使っていた会場がいつも有料イベントで使われていて見たことなかったから中を覗く機会だと思ったetc。
特に確保したい本があったわけではなく。

開始は11時から。わたしは秋葉原には12時半に着いたのだけれど、思ったより人が並んでいて(といっても入り口前の天井のあるスペースに収まる位だったと思う)、とりあえず1時間ほど秋葉原の方を散策。13時半にもう一度行くと、人はそれなりに並んでいたけれど減っていた。
行列に並んでから入場まで、10分も待たなかったと思う。

パンフレットは買わず。公式サイトが、一覧を見てもサークル毎の出展内容がわからず、会場内を直接見て回ったほうが早そうだと思っていたので。
ところで、公式サイトが見づらいのは、PCによる閲覧よりモバイルに最適化されていたりするのだろうか。

会場は、見た目に狭いように見えたけれど、それなりにサークルスペースが確保できる広さはあった。

内容は、Web系(といっても言語等とサーバ等はまったく別物だけれど)とIoT(FPGAとかボードとか)が多かったように思う。あとは、機械学習で何かやってみた本がちらほら、あとはネタ集等も少し。
個別には、Webサービス本はJavaScriptで作る本やPubyのチューニング本が目についたから実用傾向が多かったかもしれない。クラウド本は入門が多かったような。IoTは、きいたことのないボードの本があった(タイトルだけでは何の本かわからず、拝読させていただいた)。ボードの本は実用性高そうなものがちらほら。

思ったより、環境や開発手順などの周辺技術本が少ない。(テストが2冊と、Babel本が一冊、新人教育等を扱うサークルが1つあったくらいか。)

QtもGtkも触れる自分(Gtk派)としては、Qtの本はあったけれどGtkの本は無かったので、まあそういうことなのだろうと思った次第。
閑話休題。

1時間も見て回ると一通りのサークルを回れたので、離脱。

会場の外で、収穫物を見せ合っていた方々が目に入ったのだけれど、そこで見えた本が、会場には「完売しました」的表記もなくて、不思議だったりした。(見落としただけだと思うけれど、実用系と思われる、SQL系のチューニング本)

わたしの収穫としては、カラーマネージメントの本を買わせていただきました。
内容は基礎知識の入門。
以前から興味があったし、(あるいはいずれ)Vecterionで使うかもと思ったのだけれど、本当に使うかどうかは不明。
会場を回っていて、Vecterionばかりやっていたせいか、自分の興味が狭まっているかなと思ったのは事実。

まあそんな感じです。

13186128 journal
日記

m_nukazawaの日記: ベクター・グラフィックス・エディタ Vecterionをリリース 6

日記 by m_nukazawa

リリースしました。よろしくお願いします。

Pixiv/BOOTHのページ
GitHubのリポジトリ

本体のソースコードが17000行くらい。
GTK3、C言語のデスクトップ・アプリケーションの経験がかなり溜まったと思う。

リリース後、早速いくつか反応を頂いた。感謝。
しばらくはフィードバック内容をissueとして解決する等するつもり。

開発作業をTwitterにあげていたので雑にTogetterまとめを作ったのだけれど、200viewちょっとで、ダウンロード数にも影響はなかった模様。
Togetterの編集画面にバグっぽい挙動もあって編集が面倒くさいし、次回はまとめは作らなくてもいいかな、といったところ。

GitHub上にあげたVecterion配布パッケージがあるので、GitHubでダウンロード統計を取る方法を調べないと。

で、Vecterionリリース後は別のことをするつもりだったのだけれど、何をするかはまだ決めていない。
フォント作りたいけれど、作るならフォントデザインはドッグフード兼ねてVecterionでやりたい。

13178631 journal
日記

m_nukazawaの日記: gumroadからpaypal送金で受け取る話 2

日記 by m_nukazawa

gumroadからpaypal送金で受け取る話。作業開始した旨。
オフトピ気味ではあるが、「マネタイズの話」でもある。

vecterionリリース関連の作業で、久しぶりにgumroadを見てみたら、RuneAMN_Fonts_Proが1件売れているのを発見。
paypalアカウントに送金されると書いてあったのだけれど、paypalの取引記録には無かった。
調べたところ、paypalを受け取りが可能なアカウントにアップグレードする必要があり、送金されていない金額があるなら、paypal上でgumroadに送金依頼を投げるのだとのこと。

とりあえずpaypalのアカウントをプレミア(だったと思う。個人向け)にアップグレード。
必要な書類として、保険証前後と水道料金の領収書をUP。
2MB制限だったため、写真撮って縮小して上げるの地味に面倒だった。
(スマホで撮ってUSB接続してPCに転送しGIMPで縮小した。)

paypal側は審査後、書類が郵送されてくるからキー番号か何かを入れて手続き終了だとのこと。

RuneAMN_Fonts_Proは1600円で売っていて、12.13USDがpaypalに送金される。これは手数料0.90USDが引かれた額。そこからさらにpaypalの手数料が引かれると思われるので、受け取りはそれ以下になると思われる。

Pixiv/BOOTHでも1600円で販売している。
Pixiv/BOOTHは、ダウンロード販売サイトとして群を抜いて手数料が低い。(Pixivの戦略的なものと思われる。)
そのため、手数料を引いても1500円が入金される(入金手数料は別に引かれる)

販売サイトをPivix/BOOTH一本にしていないのは、単にPixiv/BOOTHが会員登録しないと買えないから。
というか、Pixiv/BOOTHは会員登録していないと無料ダウンロードもダウンロードできない。だからproject daisy bellのフリーフォントはOSDNにも置かれている。
(お世話になっています。)

BOOTHほどではないが、gumroadも手数料が安い。
DLSite、DLMarket、とらのあな通販、メロンブックス通販などは、手数料が収益の30〜33%。
(名前も利率もよく覚えていないから各自確認のこと)

最終的な入金額から見てGumroadが良いかどうかは、paypalからの振込額を見て比べたい。というか、paypalの受け取り手数料を調べていない。

この際だからここに紛れて書いておくけれど、DLMarketに商品を出店すると、1件も売れていないのに「ウチのプラットフォームの広告を買いませんか?」というスパムメールが飛んでくるので、気分を害するにはもってこいのサービスになっている。gmailのフィルタで全部スパムに飛ばしている。1円の利益にもならないからアカウントを放置している。理由がなければ使わないほうがいい。

閑話休題。心がまったく休まらない話題だったが。

しかし今回、1000円受け取れるとして、書類手続きやらpaypalのアカウント設定やらで2時間くらい使ったから、利益は吹き飛んでマイナスになってしまったと思う。
次回以降で取り返せることを期待。
(しかしそれを言うならRuneAMN自体、正直プラス収支とは言えないのだが。)

というわけで、gumroadから売上を受け取る話でした。何か問題が発生したらまた日記に書くと思う。

みんなマネタイズの話しようぜ!

// paypalもgumroadも、サイトの応答が遅いので、操作するときは勘を頼りにリンクから機能を探しまわるのはやめたほうがいい。

13178073 journal
日記

m_nukazawaの日記: Vecterionライセンス草案(更新)

日記 by m_nukazawa

自作ベクターグラフィック・アプリケーションVecterionのライセンス文草案。

m_nukazawaの日記: License of vecterion for General Public 草稿
m_nukazawaの日記: Vecterionライセンス草案(更新)

リリーステストは済ませました。
あとはライセンスを決めるだけ。
機能的にはまだまだ足りていないし、GitHubにソースコードを上げてしまいたいだけなので、もうライセンス未定のままでいいかなと。

// Pixiv/BOOTHにWindowsバイナリを上げるなら、そのためのスクリーンショットを取らないと。

  + LICENSE.md
    1 The Vecterion License (Version 0.1a+)¬
    2 ====¬
    3 pending.--¬
    4 ¬
    5 # Contact¬
    6 [michinari.nukazawa@gmail.com](mailto:michinari.nukazawa@gmail.com)--¬
    7 [@MNukazawa](https://twitter.com/MNukazawa)--¬
    8 ¬

13168539 journal
日記

m_nukazawaの日記: Vecterionライセンス草案(更新) 5

日記 by m_nukazawa

/*
前回、スラド上で頂いた指摘を反映しつつ、自作ベクターグラフィック・アプリケーションVecterionのライセンス文草案を書き換え。
前回の:
m_nukazawaの日記: License of vecterion for General Public 草稿

# 主な変更
* 英語に雑に対応。
* OSSとかFLOSS(?)でないことを明記。
* プライバシ系の内容は冒頭の免責事項に含むということで削除。
* バグレポート強制を自動バグレポート妨害禁止に緩和。
* 章立て的なものにして可読性をあげたつもり。

その他ざっくばらんに変更。

# TODO
"ここにいい感じの免責事項を書いておく"と書いてある箇所をなんとかする。

*/
The Vecterion License (Version 0.1a+)
====

# English
This is not Free Software License.
This is not Open Source Software License.
Please read japanese License text.

# 目標

このライセンスは以下の優先順位の複数の目標に基づき策定されました。
この目標の内容と優先順位は事前の告知なく変更されることがあります。
  * daisy bellが収益を得て幸福に暮らし活動を続けるため
  * daisy bellが本物のアウトラインフォント・デザイン・アプリケーションを得るため
  * linuxデスクトップに本物のベクター・グラフィック・アプリケーションを提供するため
  * すべてのデベロッパに、自由に改造できるベクター・グラフィック・アプリケーションを提供するため
  * すべてのデザイナに、実用的なベクター・グラフィック・アプリケーションを提供するため

以下、本文

# The Vecterion License

[ここにいい感じの免責事項を書いておく]

本ライセンスは事前の告知なく改定されることがあります。

## ユーザ向けライセンス
Vecterionのユーザはテスタとして扱い、テスタ向けライセンスに従うものとします。

## テスタ向けライセンス

### 最新版使用の義務
あなたは最新のバージョンのVecterionを使用することができます。
あなたは最新のバージョンより1バージョン古いVecterionを使用することができます。
あたなはこれらより古いバージョンのVecterionを使用することはできません。

### バグレポート
あなたはVecterionの自動バグレポートを意図的に妨害してVecterionを使い続けてはいけません。

### ライセンス違反の場合
テスタ向けライセンスに違反した場合、Vecterion有償ライセンスをお買い上げいただく場合があります。

## 開発者向けライセンス

Vecterionのディストリビューションおよび拡張およびパッチおよびVecterionディストリビューションの実行ファイルを、以下成果物と呼びます。

### Linux対応の義務
成果物は、Linux環境で動作しなければなりません。
(Linux以外の環境のみをターゲットとしたものを一般公開してはいけません。)

### 一般公開の義務
成果物を、開発した本人以外が使用する場合、広く一般に公開および配布しなければなりません。
本ライセンスによる制限を超えて、利用および再配布を制限してはいけません。

### ソースコード公開の義務
ソースコードを公開しなければなりません。
(ソースコードを公開すること無くバイナリを配布してはいけません。)
ただし、開発した本人のみが使用する場合は、この限りではありません。

### daisy bellの特権
Vecterionにあなたのパッチを取り込むことがあります。
daisy bellがプロプライエタリ開発ライセンスの許諾権を持つことと、ライセンスを販売することに同意するものとします。

### ライセンス違反の場合
開発者向けライセンスに違反した場合、Vecterion開発にかかった実費の一部または全部をお支払いいただく場合があります。

## 有償ライセンス(プロプライエタリ開発ライセンス)
プロプライエタリ開発ライセンスを使用するには、daisy bellから同ライセンスを購入する必要があります。
プロプライエタリ開発ライセンスを使用することで、開発者向けライセンスに規定された条件に従わないVecterionディストリビューションを開発・配布することができます。

以上。

typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

読み込み中...