Zopfcode

かつてない好奇心をあなたに。

失われた「フリーソフト」の哀愁と、今を生きる開発者への願い。

かつて、窓の杜や Vector へウキウキでダウンロードしに行ったような「フリーソフト(フリーウェア)」たち。これら「フリーソフト」たちの中には、利用についての明示的な許諾がないソフトが多く存在する。

これらの公式な入手手段が生きている間は何も問題はない。しかし最近は、サイトが閉鎖されるばかりか、連絡先すらわからず困るケースが多くなっている。このように公式の配布手段が失われると何が困るのか。そこには大きく2つの問題がある。再利用の許諾を欠くことと、ソースコードがないことだ。

2022/12/29 追記: unasuke が「コードを公開する側」から見て同じ話題を解説した記事を公開しているので、私の記事とは別な視点が欲しい、あるいは疑問を持った方がいれば是非こちらも参照して欲しい。

blog.unasuke.com

問題1. 再利用の許諾がない(あっても曖昧)

再利用の許諾が書かれていなければ、第三者は勝手にコピーも再配布もできない。たとえばいわゆる「フリーソフト」の場合、無料ではあるが、自由ではないから*1だ。

Internet Archive で掘り返したページにさらっと「他の場所で配布してもいいですよ」と書いてあることも多い。しかし、この程度の表記では、多くの問題が未解決のまま残る。配布方法を定義する 5W1H や免責事項を曖昧さなくカバーしなければ、他人からすると安心してコピーしたり、再配布したりできない。

もちろん、製作者が自ら厳密な日本語を考える必要はない。「型」に則ってソフトウェアを配布すれば解決できる。型とはすなわち、よく知られた OSS ライセンス達のことだ。一般に、OSS ライセンスはソースコードに限ったものではなく*2、バイナリの配布でも同様に作用する。仮にバイナリしかなくても、よく知られた OSS ライセンスのもとで配布されたソフトウェアなら、原著作者と連絡が取れなくても誰でも安心して再配布できる。

問題2. バイナリしかない

ソースコードがないとバグが直せない。知見を他に応用することもできない。

コンパイルされたソフトウェアは、コンパイラの知っている API や ABI に則って実行ファイルにまとめられているため、手元の環境で動かないことがある。たとえば Windows の場合は異常なほどの後方互換性があるが、周囲の依存ライブラリや命令セットの違いは乗り越えられないし、Linux のように libc が統一されていない OS でも問題が発生する。

作者が知っていた時代の環境は急速に廃れていく。その変化を耐えるにはソースコードが不可欠だ。公開後の作者のメンテナンスや継続的な進化は必要ない。ライセンスには免責事項があるので、不備による責任を負うこともない。利用者が機能改善を作者に打診することはあるが、本当に必要なら自らソースコードを改良して使うというのが OSS の基本的な文化である。

私も現に、電子辞書ハックのために古のソフトウェアたちに日頃多く触れる。きちんとライセンスとソースコード付きで配布されたソフトウェアに助けられ、また、バイナリしかないソフトウェアにやきもきしている。コミュニティレベルでこういった活動をするにも、コンプライアンスが保たれた場にするために仕方なく「触らないようにしよう」と説得することもある。できれば二度とこういう事は起こって欲しくない。

www.zopfco.de

今、ソフトを配布する皆さんへ

過去の有益なソフトウェアたちを活用したくてもできない悲しき人間を減らすために、公開の場で配布する無料のソフトウェアを開発している皆さんには、今一度以下を検討して欲しい。

  • ソースコードもバイナリも GitHub といった長期の配布に耐えそうな場所で配布する*3
  • どうしても隠したい強い理由がなければ、ソースコードは公開する*4
  • 自分の言葉で再利用を許諾するのではなく、MIT License, BSD License, GNU GPL, CC0 のように、よく敲かれ磨かれたライセンスを使って許諾する
  • あるともっと良いこと: ソフトウェアのビルドを GitHub Actions 等の CI に乗せる
    • 開発者にとってみれば、無駄な時間の削減や再現性のあるビルドなど CI 一般の利点が享受できる
    • 利用者にとってみれば、ビルドの敷居が大きく下がり、同時に貢献の敷居も下がる

「たかが小さいソフトにそんなマジになっちゃってどうするの」「クソ真面目乙」「なんでソースコードまで配らなきゃいけないんだよ」「人のためにやってるわけじゃないよ」と非難も少なからず飛んできそうだが、どのようなソフトウェアであっても、安心して再利用できる形で公開されている方が良い。さらにソースコードまであれば何倍も世界にとって得だ。これは本当に間違いない。

お願いだから、作ったソフトはバイナリだけじゃなくてソースコードも一緒に配布して欲しい。適切な OSS ライセンスの下で!

有益な情報集

なぜライセンスを改造しちゃいけないの? - Qiita
よく知られた OSS ライセンスとは何か、それらをなぜ使うべきかが解説されている。

オープンソースの定義 (v1.9) 注釈付 – Open Source Group Japan – オープンソース・グループ・ジャパン
OSI によるオープンソースの定義。「よく知られた OSS ライセンス」たちはこの定義の範疇にある。

ブコメレシーブ欄

今フリースソフトとか言わないで無料ダウンロードって言い方してるの多い気がする

フリー素材なんかでも曖昧な許諾しかしてないのが大半。独自ライセンスほど厄介なものはない。

その通り!Creative Commons とか GFDL とか使いましょう。CC も実際には利用者が表示までちゃんとしてくれるパターンは残念ながら少ないですが、許諾内容をカスタマイズできて実益に沿っているので便利です。

それはもう個々で考え方が違うのだから仕方ない

それはそう(それはそう)。私は OSS 信奉者なので OSS に寄った文章になっています。きちんとした形で公開されてればされてるほど誰にとっても良いと思っています。

お願いしているスタンスの文章なのに、自分(たち)の利益ばかり訴えて開発者の利益には脚注でほんの少し触れるだけ。

OSS において開発者側は常に与える側にあり、利用者は常にもらう側にあるので開発者側の「利益」というのは実際ほとんど目に見えないし計測もできないです。いつかお世話になった OSS にお返しする感じのメンタリティが必要っす。利用者から貢献者が出ることを願いながら。

自分の場合は自分が死んだときのことを考えて、へぼアプリも含めて全部オープンソースにしてたり。というか誰かメンテ手伝って・・・みたいな。

きっと見えないとこで誰かの役に立ってますよ。

これ、現代だと各アプリストアで無料配布されてるツール類どうですかってのがなあ

ストアアプリは署名付きのソフトってだけなので、開発者によっては同様に GitHub にコードが置いてあったりします。

私の場合JavaScriptで書いていたので、隠すよりもパクられて「自分のモノ」と主張されるのがイヤだったので、私が書いたという証拠を残すのが最初の目的だったな。

過去私がやられた悪質な例として license agreement 以外コピーした輩がいました。残念ながら透かし等のやり方がない以上剽窃を防ぎ切ることはできませんが、動機は大きく削げますし、いざという時はコードの類似性で検証できます。コードの構造や名付けのクセは指紋みたいなものなので。

私の場合、クローズソースの無料ソフト公開しててそこそこ評判良かったけど、ゲームだったんで、あんまりメンテの意味ないし今後もソース公開はしないだろうな。

完全に個人的な視点でいえば、それでもやっぱり公開したほうがプラスだと思っていますが、まあ選択は人それぞれなのでそうですね…て感じです。

わかる。「開発者に何の利益が?」みたいな意見もわかるので強制できないけど、長い目で見れば使えるフリーソフトやフリー素材が蓄積されていく社会の方が豊かになるのは間違いないと思う。

OSS の考え方そのものを推す人の考え方はだいたいこれですね。自分もそうです。

ソフトウェアをソフトやアプリと略すのは日本だけで、アプリはappと同じだけど、ソフトはsoftwareでない牧歌的なものを指す気がする。OSSより古く自由なので、OSSにならず消えて完成して、0からクローンを作るのがイイ

言葉の解釈はさておき、牧歌的であった時代、遡れば MIT のハッカー文化の隆盛の時代くらいまで少なくとも行けます。OSS という「形式化」は実際それより後です。90年代に入る頃には既にその形式(ライセンス)たちがあったことも事実であり、これらへの理解と啓蒙と拡大とが当時はまだ小さく、今現在も進んでいる最中であると解釈しています。

OSSとapp storeに挟まれて"フリーソフト"文化は滅びかかってるよなぁ。GNU信者だけど、そこのごちゃ混ぜ無法な場の自由さが開発者とコンシューマの橋渡しになってたと思うんだよなぁ…

OSS とマネタイズというよくある主題に1つの解決策を与えたのがアプリ市場で、これは素朴に良いことです。上記のような楽しいカオスは滅びず昔も今もあって、では何が変わったのかというとそれは交流手段と場所と内容です。

開発者はソフトウェアを公開することで承認欲求をある程度満たすことができるのではないだろうか。それに知名度のあるものを作ると匿名でなければ名刺代わりになったり仕事で「すごい人」の地位・特権を得られる。

承認欲求は活動の重要なエネルギーになるので同意です。悲しいかなそれが注目されるケースはまれなので、知名度は副次的な目標にするのがいいですが、それが達成できなくても少なくとも「こういうことやってるよ〜」とアピールする具体的材料にはなってくれるでしょう。

ここでいう「いわゆるフリーソフト」の文脈、割とよくわかってない

この記事を書くに至った発想元の「フリーソフト」でいうと、このあとのブコメにあった「フリーソフト(無料ソフト)であるがソースがクローズドな有用ソフトウェアというのは普通にあって、ここでいうフリーソフトっていうのはWindows95とかの時代に流行ったそういうソフト群のことだと思うよ」が感覚近いです。GNU のいう「自由ソフトウェア」や、OSI のいう「オープンソース」とは関連付けてないです。ちょっとそこが伝わりにくかったですね。すみません。

LHAとかFDとか素晴らしいフリーソフトに学生時代どれだけ助けられたか。FDはアセンブラだけど、クローンがあるのでこれがコードとともに引き継がれて故人のDNAのように遺っていくと嬉しい

コードそのものの系統は違うかも知れませんが、LHA 形式に端を発する +Lhaca や Lhasa なんかのアーカイバは小学生の頃 Windows 98 でよく使っていました。私もリスペクトしています。

長期的な目線で見て界隈が健全な方に向かうと最終的に自分に得が返ってくる、という思想にみんながならないとなかなか浸透しないよね。

ですね。実例を伝え続けるしか無いなと私も思っています。

ソースコードがあったほうがいいのはそうだが、バイナリしかなくてもバグが直せないということはない。やる気の問題

分岐命令を nop で置き換えるくらいで済んでくれるならそうですね。ただ、万人にできる方法ではないです。

「メンテしないならコードをプライベートにしてよ」と言ってる人をTwitterで見かけて、それは違うやろと思ってたところにこういうエントリが出てきてありがたい。

お、このコンテキストは私も嬉しいです。書いてよかったです。メンテとソースの公開は全く別の事象ですからね。

ソースコードがあってもビルド方法が分からないとかツールが揃わないとか謎のコンパイルエラーとか、他人のプログラムをなんとかする際のはまりポイントは多い。

そうなんですよね。だから作者はドキュメントを頑張って書く等の自分にとっては不要な作業をコード公開時にやるわけですが、実は数年も経てば自分も「わからない側」の人間になってるのが常なので、結果自分に返ってくると思えば動機付けになります。

?何がしたいのか分からん。OSS化しても結局維持するの開発者だけという状況は変わらんぜよ。OpenSSLですらあんなに基幹製品だったのに脆弱性で騒がれた時フルコミットしている人1人だけだったからね。

「メンテナーの数」と「ソースコードを公開する」という事象は別個のものであることだけ記載させてください。確実ではないのが残念ですが、コードを公開すればその1人が2人になる可能性は常にあります。これが増えてくれるかどうかは作者の意向、コミュニティ作りのやり方、その他いろんな要素があります。ですから、ソフトウェアの有名さとはあまり相関がないです。

フリーソフトはOSSが浸透する前のソフトウェアも多く、そのくらいの人たちはバイナリは公開するけどソースは公開したくないという人が一定数いると思う。メンテしてない人なら手間は掛けたくないだろう。

金というか報酬もないのに開発者が維持管理する理由ないからなんも言えんよね。

公開そのものについては、個人の選択がもちろん一番尊重されます。公開に際してメンテは必要ありません。これからコードを公開するときに必須なのは、適切なライセンスを付与することだけです。本文「問題2. バイナリしかない」に追記したのでご覧ください。

たまにこういう「他人の創作物に後から他所のルール押し付けようとする」人いるよね。悪気ないつもりなのがさらにな。作者さんが創造主兼王様の方がずっと利益を得やすいし、利用者としてもそこは持っててほしい。

後から確立されたライセンスの概念は、牧歌的な過去と、その後開発者が遭遇した事が積み重なってできていて、知見が結集しています。私がリスペクトをもちつつも過去のソフトウェアを例に挙げて啓蒙する原点はここです。ところで、創造主兼王様な OSS は Linux を筆頭に実例がたくさんあります。「伽藍とバザール」や「優しい終身の独裁者」で調べてみてください。

ソフトウェアが200以上ダウンロードされてもあんまり反応はないな。

同じ OSS 開発者として応援します。拝見したところライセンスがないリポジトリが多く見られたので、他の人が「反応しやすくする」ためにライセンスの追記をおすすめします。

確かにいにしえのソフトはライセンスがアバウトだしソースコードが公開されていたりいなかったりしますね。ジオシティーズ終了などホームページサービス終了で消えていったソフトも多そうです。

Geocities 終了は本当に悲しい事件の1つでした…。

別の話な「許諾」と「ソース公開」を一緒にして著者の文化側に我田引水してるので説得力が無い。「クローズドソース用のライセンスの『型』を出せ」と「作者の自由だし公開デメリットから目を逸らすな」と思う。

まず、「クローズドソース用のライセンスの『型』を出せ」について。本文で「仮にバイナリしかなくても、よく知られた OSS ライセンスのもとで配布されたソフトウェアなら、…」とあるように、一部のライセンスはソースコードがないソフトウェアにも使えます。たとえば MIT License は本文で "Software" という語を使っていますが、その形式がソースコードでなければならないとは書いていません。一般に許諾とソースコードの公開は暗示的に同伴することが多いので、私の考え方としてそれを一緒にしているきらいはあります。一方で GNU GPL なんかは明示的にそれらが同伴するので、私の提示のやり方として破綻はしてないかなと思います。 次に、「作者の自由だし公開デメリットから目を逸らすな」について。作者の自由については、このブコメレシーブ欄で述べている通りです。公開することによるデメリットは「ライセンスの追記作業が必要」以外に私は思い浮かばないですが、どのようなものがあるでしょうか。

いまだったら動くOSイメージとセットでdockerhubに上げとけば残っていく気がする

コンテナの元になる Dockerfile があればものすごくベターですね。近年ではコンテナごと配布するソフトも多いです。

好きで作っておすそわけ感覚で配布してるのに、こうした方がみんなのためになるなんて知らんがなって感じじゃね?

「おすそわけ感覚」に対してだと、たしかにこの記事はゴテゴテした話に聞こえるかなーと思います。ただ、そのおすそ分けは海をも超え、どこかの人や企業がそれにあずかる可能性もあったりします。そうすると、ライセンスという約束があるとみんな心置きなくコピーしたりできるので、とっても嬉しいわけです。

個人的には理解できる。(公開したくない人にどう説明するかは難しいと思う) 違う話題を書く。有償ソフトを含む、フェアユースを(拡大する方向で)明文化するとバイナリや意匠を含め使える範囲が増える。

アメリカでいうフェアユースを日本の著作権法にも取り込んでくれたら、OSS だけじゃなくていろんなことが萎縮せずスムーズに回ってくれるのにな〜と日々思ってます。

*1:OSS 一般よりは GNU 視点の解説になるが、GNU による自由ソフトウェアの解説 の冒頭に明確な説明がある。

*2:GNU GPL のようにソースコードの配布を前提に含むライセンスもある。

*3:仮にインターネットが滅んでも、GitHub なら定期的に北極にコードがバックアップされるので安心!これはマジメに言っている。

*4:積極的に言えば、インターネットの知見によってコードを永遠に存続させられるかもしれないし、あなたのプレゼンスも高まるかもしれない。消極的に言えば、隠したところで得るものはなく、失うものしかない。