作ったら公開したい。それが人情ってものです。ここでは公開の仕方について適当にまとめます。
配布するファイルは実行可能プログラムだけではありません。通常、以下の物が含まれます。
ソフトによってあったりなかったりですが、これらをzipなどで固めて公開するのが普通です。
Readmeとは、解凍したとき一番最初に読んでもらうことを目的としたテキストファイルです。フリーソフトを落としてきたときは、たいていこのファイルがついていると思いますがちゃんと読んでますか？
Readmeには作者の情報、連絡先、動作環境、簡単なインストールの仕方、簡単な使い方、改変履歴、ライセンスなどを書きます。書き方はいろんなソフトの物を参考にするといいと思います。
まずWindowsの場合はzipで公開するのが簡単です。zipならWindowsの標準機能で解凍できます。lzhでもいいですが、主に日本で普及した規格ですので、海外のユーザーが解凍できないかもしれません。
Windowsの場合、よくわからない初心者がユーザーになることもあります。その場合ZIPによる配布は難しい場合もあります。その場合にはインストーラーを用意しましょう。
それこそ自分で作ってもいいんですが、結構手間なので専用のソフトを使うのがいいと思います。しかしVectorって最近ひどくありません？ Vector -インストーラ
最近は dmg 配布（dmgを更に圧縮することも）が多い。dmg の作成は Disk Utility.app を使うべし。以下標準的な Cocoa Application について。
dmg には app をそのまま入れるか、インストーラ の pkg（or mpkg） で入れるか。インストールの手続きが面倒なら、PackageMaker.app で固めた方がいい。そこはライブラリをどのように構成するかにかかってる。pkg なら Installer.app で自動的にインストールできるので。pkg の作り方はどうもいろいろあるみたいだから、調べてみるといい。pkg ではファイル毎のアクセス権設定とインストール先の指定、バージョン管理、ライセンス確認、スクリプトの実行とかができる。pkg は Bundle だからローカライズ可。
リソースは基本的には Application Bundle に入れるから特に問題にならないだろうけど、ライブラリに分離した時、~/Library/Application Support などに入れて置きたいのならば、pkg でインストール先を指定した方が簡単。ちなみに mpkg は multi-package の意で、pkg を幾つか纏め、インストール時に不要な物は排除できる。Mac OS X のインストールの時、詳細な設定を行えば、必ずインストールしなければならない部分と、プリンタドライバの様に指定できる部分とがあったはずで、mpkg にすればこういう選択肢を用意することもできる。
ヘルプファイルは Mac OS からの伝統で Help Viewer.app で閲覧する。Mac OS の頃はバンドルではなかったからヘルプファイル（.help）は別の所にインストールされたけれど、最近は Application Bundle 内に入れる事の方が多い。/Library/Documentation/Help に MacHelp.help などがあるから、参考にするといいけれど、ヘルプファイルもバンドルにしておけばローカライズできる。Help Indexer.app でインデックスを作れるらしいけれど、作った事がないからよくわかんねえ。ヘルプファイルがバンドルではないこともあるけれど、それは .app/Contents/Resource/Japanese.lproj に入れておけばヘルプファイルをローカライズできるから。ヘルプファイルは必ずしもこうしろってわけではないけれど、Spotlight の全文検索が利用できるのでそうした方がお得ですよ、って話。
他にもいろいろあるけれど、Apple の Software のインストーラでも眺めて考えてみるといい。ソースは developer とでもフォルダを作って、そこに Xcode のProject Folder を丸ごとコピーしておけばいいでしょう。ちなみにインストーラで実行できるスクリプトは、コンパイル済みでも Shell Script なんかでもいいらしい。
newApplication.app/Contents/Library/Spotlight/fileImporter.mdimporter と入れておけば、システムがこれを認識してくれる。わざわざ Mac OS X のライブラリに入れなくてもいいことがあったりする。
ほかにも newApplication.app/Contents/Resources/README.rtf と入れておけば、Main Menu の「このアプリケーションについて」で表示させることができたり（FancyAbout 参照）。Framework や PlugIn は newApplication.app/Contents/Frameworks などバンドルのフォルダに入れておいても、NSBundle で取得して利用できたりする（複数の共通ライブラリならシステムに入れた方がいいけれど、一つだけならバンドル内というわけ）。
古い Carbon のソースコードを利用すると Resource Fork を参照したいことがある。だいたいそういうのは .rsrc で入ってるけど、最近あまり見かけない。Resource Fork と云えば、Mac OS からの伝統で、Mac OS X でも一つのデータには二つ以上の Fork がある。これが Mac で圧縮したファイルが Win で解凍すると二つ増える原因なんだけど、Resource Fork はデータにくっついた Mac 用のメタデータで、喩えば同じ XML ファイルでも絵柄が異なることがある。これは Resource Fork で開いて欲しい Application を指定してるからで、Unique ID を指定する（APPL の指定）ことで決定できる。APPL の値は newApplication.app/Contents/PkgInfo で指定できるので、Unique な文字列を考えておくといい。Mac OS X から UTI（Uniform Type Identifier）が追加され、更に複雑な指定ができる。
Application ごとに実は開けるファイルは宣言されていて、昔は Resource Fork で全て指定したけれど、今は newApplication.app/Contents/Info.plist と UTI で指定できる。Info.plist はかなり重要なファイルで、どの拡張子にどの絵柄（.icns）をというGUIの設定から、UTI の指定まで、全てを一括指定できる。Mac OS X はどこにどの Application があるか全て把握しているらしく、ファイルを発見すると、APPL を確認、一致する Application があれば Application の設定を参照したり、APPL が無かったりすると、拡張子から最優先の Application で開ける様にしてくれるわけ。Finder でカラム表示をした時の種類についての情報や、「このアプリケーションでひらく」の情報もこれで管理される。ちなみに UTI は Spotlight や Quick Look なんかでも利用するらしい。
とまあ Mac では Windows と勝手が違うことが多い。その目的は利用者の手間を少なくすることであるけれど、反面、開発者は手間をかけてその補塡をしてやれねばならない。だから公開する前に Mac OS X Application の設計を、Mac らしくできたのか、確認してみるとよい。最初は TextEdit なんかで確認してみるのがいいだろうね。
ソースコードとMakefileを.tar.gzで。
CやC++の場合は作られたexe(Windowsの場合)と、使ったDLLを必ず一緒に入れましょう。DLLは場合によっては一緒に配布してはいけない場合があるので、ライセンスはよく確認しましょう。
一応VSを前提に話します。配布する実行可能ファイルは \プロジェクトの場所\bin\Release にあります。Debugではありません。必要であればリソースやDLLなども忘れないように入れましょう。
.Netのアプリはexeだけでは実行できません。実行するマシンにはMicrosoft .NET Framework 再頒布可能パッケージが必要になります。これはVistaには標準で入ってますがXpには入っていません。なので必ずこれを入れるように明記しましょう。
.NET専用のインストーラを使うと.NET frameworkとかも入れてくれるみたいです。
またClickOnceを使うと.NET frameworkが入っていない場合自動でインストールしてくれます。自動アップデート機能とかあるみたいです。
Javaは実行には仮想マシンが必要です。Javaの仮想マシンは比較的簡単に入れられます。これも明記しておきましょう。
もうひとつJavaはexeが作れません。exeでラップするソフトなんかはありますが。なので実行しやすいようにバッチファイルを用意したりJARファイルに固めたりすると良いでしょう。EclipseにはJARで出力できる機能があります。
これはブラウザからJavaのソフトウェアを実行できる技術です。
（ライセンス、法律に詳しい方加筆お願いします。）
ライセンスとはソフトウェアをどのように扱って欲しいかを指定するものです。
たとえば自由に改造してもいいよとか、コピー自由だよとか。逆に改造は絶対だめ、商用利用はだめという風にいうこともできます。基本的に法律の範囲内であれば自由です。
言うまでもないですが、ライセンスへの同意はソフトウェアの利用者と開発者の間で交わされるものであって、利用者でない人はこれに関係しません。
つまり、GPLのソースコード開示に関しても、ソフトウェアの利用者でない人からソース開示してって言われても、知るかヴォケと突っぱねることができると考えられるでしょう。
利用者と開発者の間で交わされる約束ってところがミソだから、よく覚えておきなさいよね！
PDとはパブリックドメインの略です。著作権を完全に放棄した状態です。日本の著作権法には概念がないので日本での扱いはよくわかんないですが。 PDの物はどのように使おうが自由です。改造、コピー、それで対価を得ることもできます。
GNU General Public LicenseはこのWikiのライセンスでもあります。簡単に言うと
だいたいこんな感じですが実はもっと複雑ですのでよく調べてください。
BSDライセンスはOSSで使われるライセンスの一つ。
オープンソースだが、GPLと違い複製・改変した物を、
クローズドソースで公開できる。
の３つをドキュメントに書いておけば、 BSDライセンスのコードを組み込んだりして使える。
煮るなり焼くなり好きにしろライセンス。国産のライセンスで、GPLのような汚染がない。ライセンス文自体は文書向けの派生ライセンス、元々はNYSDL(=煮るなり焼くなり好きにしろドキュメントライセンスの略と思われる)の下で頒布されていたがCC0に変更された。日本での法の運用に基づいて記述されている、名前よりもしっかりしたライセンス。たぶん準拠法が日本国法である旨を明記すれば完璧。
紹介した以外にも、多種多様なオープンソースライセンスが存在する。
数が存在すると言うことは、それだけ違いもあるわけで、さらにその違いが細かい違いだったりするからややこしい。
例えば修正でないBSDライセンスは、宣伝条項というちょっとした違いがあるために、GPLと矛盾すると解釈されたりしている。
冒頭にもあるとおり、ソフトウェアを利用するユーザとの間で交わされる契約な訳だから、違いをよく把握して、ライセンスを付与するようにしたい。
以下のサイトが、表形式でオープンソースライセンスの特徴をまとめていてわかりやすいと思うから、参考にするといいんじゃないのかな。
http://en.wikipedia.org/wiki/Comparison_of_free_software_licences
スレに公開したり、短い期間だけ公開したりするときはアップローダにあげるのがいいでしょう。Vipperならやり方は知っているでしょうから詳しくは書きません。
このスレ専用アプロダVIP Programming Uploaderもご利用ください。
この際、自分のサイトを持ってみてはいかがでしょう？長期間公開するのであればお勧めです。
SourceForgeはオープンソース向けのサービスです。ただ公開するだけでなくいろんなサービスを受けることできます。ギコナビとかありますね。
分散バージョン管理システムGitを使ってファイルをアップロードできるサービスです。
分散バージョン管理システムMercurial、Gitを使ってファイルをアップロードできるサービスです。