hoehoe2
t-ashula / hoehoe2 てな形で,Tween ver. 1.1.0.0 GPLv3 版から fork して C# 化の区切りがついたのでエントリ起こし.
opentween ていう風にプロジェクトを構えて運用していくほどの気力はなくて,今のところは単純に自分用. twitter クライアントとしてどうこうというより .NET と mono,C# と VB.net の互換性みたいな技術的な題材として見ている面が強い.
実際公開はしたけれ,ライセンス的な問題,API キーの問題,多言語化,インストーラプロジェクトの変更,アップデート周りの整備と自分一人で使うには問題ないけど tween の oss fork プロジェクトとして野に放つには抱えてる問題は多い.なので,これまで維持してきた@kiri_feather たちはすげぇなと思うわけです.
で, 以下幾つかの抱えてる問題と技術的なお話.
issue
ライセンス的な問題
もともと v1.1.0.0 までは GPLv3 が適用されていたので,ココから GPLv3 に基づいて fork する分にはなんの問題もない.が,問題は幾つかのアイコン類のどこまでが GPLv3 の適用範囲になるかというところと Dynamic.vb .
アイコン類
アイコン類は実際には大した問題じゃない.
Tween v1.1.0.0 に同梱のLICENSE.ja.txt に,Tween/Resources ディレクトリに含まれるアイコンファイルは GPL でライセンスされないと書かれているが, これらのファイルがオブジェクトコード ( Tween.exe ) の生成に必要な 対応するソースコードである以上 GPL と互換性のないライセンスで頒布することは出来無いはず.
なので,強行的に GPL とみなして使い続けてもライセンス上の問題はないと思う.
が,そんな微妙な状態のまま使うより,アイコンなので Tween と別物であるという意味も含めてライセンス的に問題ないものに置き換えて行く予定.
Dynamic.vb
内部で使われている Dynamic.vb (取得元 ) が MS-PL でライセンスされている.
FSF はOSD 適合ライセンスだとしながらも, MSPL と GPL は 非互換との立場 をとっている.
ソースコードでの頒布時に MSPL にしないとダメだからというのが理由のようだが,(cf. http://lwn.net/Articles/254717/ ) 今ひとつはっきりしていない.
個人的には,ライセンス混在とか面倒なので正直避けたいのでいずれ置き換える予定.
API キーの問題
オリジナルの Tween が対応していた幾つかの Web サービスの API キーについては置き換える必要がある.ソースのどこにそのキーが書かれているかとか,どこに問い合わせればキーが得られるかは文書化されてないので,1つずつ調べて置き換えていくしかない.別に自分が使ってないサービスならどうでもいいかと思わんでもないので正直しんどい.
これを書いてる時点では,Twitter の ConsumerKey と ConsumerSecret 以外は置き換えてない.
多言語化
オリジナルの Tween だと英語と中国語のリソースがあって切り替えられるようになっていたのだけども,VB から C# に変換するときに,バッサリと切り替え周りの処理を切ってしまったのと,検証用の環境が無いので無用の長物になってるんじゃないかな.個人用なら別に問題ないので予定は未定.
インストーラ
InstallShield をつかったプロジェクトがオリジナルのソリューションにはあって,個人用なら別にインストーラ要らないし,InstallShield 有料だし,WiX とかで置き換えるのも技術的には面白いかもねとかあって決めかねてる.
アップデート周り
オリジナルの Tween の SourceForge.jp のプロジェクトの URL を参照してるのでこのへん削除するなり,置き換えるなりが必要.
TweenUp.exe の方も変換するなり削除するなりやらないとマズイ.
個人用なら別に(以下略
他
その他細かい技術的なことを言うと,
- テストコード無い
- 命名法がない
- 確たるコーディングスタイルがない
- WinForms べったり.せめて DataBinding を.
- etc
という話があったりなかったりで誰が幸せになるのか分からないけど,まあ楽しいからいいや.