タグ

OSSに関するnakunaruのブックマーク (5)

  • t32k、怒られる!セマンティック バージョニングしてますか?

    どうも、バンクーバーでぶらぶらしている@t32kです。最近は暇なのでもっぱらOSS活動に勤しんでおります。そんなわけで日々のアプリケーション開発において重要になってくるのがバージョニングです。 今日はセマンティック バージョニングについて解説します。自身が公開しているライブラリやパッケージのコードを何かしら修正したら、それに伴いバージョンを上げるのが一般的だと思うのですが、実はどのようにバージョンを上げるのが適切なのか、昔の私は理解していませんでした。 『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』などと、なんとなくにバージョニングをしていました。 If the plugin’s API changes dramatically (for example, when sortOrder option is renamed

    t32k、怒られる!セマンティック バージョニングしてますか?
    nakunaru
    nakunaru 2014/12/09
  • 30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場

    「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので3分で書く。 オープンソースライセンスは、以下の3種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い(そしてどちらを選んでも問題ない)。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ: ライセンスの解釈については、

    30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
  • OSS監視ツールZabbixの改良版「MIRACLE ZBX 2.0」、ミラクル・リナックスが無償公開

    OSS監視ツールZabbixの改良版「MIRACLE ZBX 2.0」、ミラクル・リナックスが無償公開 ミラクル・リナックスは2013年8月15日、オープンソースのシステム監視ソフトZabbixの改良版「MIRACLE ZBX 2.0」を無償公開した。Zabbixの不具合を修正したほか、拡張機能を追加している。 ZabbixはラトビアZabbix社が開発しオープンソースソフトウエア(OSS)として公開しているシステム監視ソフト。ミラクル・リナックスはサポート契約を結んだユーザーに対し、Zabbixの不具合を修正して機能を追加したパッケージをMIRACLE ZBXとして提供していた。 MIRACLE ZBXにのみ搭載されている機能には、Zabbixプロセスを停止せずにログレベルを変更する機能、AIXのディスクI/O監視機能などがある。 無償提供に踏み切った狙いは「一般公開することでユーザーか

    OSS監視ツールZabbixの改良版「MIRACLE ZBX 2.0」、ミラクル・リナックスが無償公開
  • たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ

    GitHubが、どのオープンソースライセンスを選択すればよいのか指針となるサイトを公開したので、それぞれの特徴を翻訳してまとめてみました。 Choosing an OSS license Apache v2 License GPL v2 MIT License Mozilla Public License Version 2.0 LGPL v2.1 BSD (3-Clause) License Artistic License 2.0 GPL v3 LGPL v3 Affero GPL Public Domain (Unlicense) No License Eclipse Public License v1.0 BSD 2-Clause license 備考:各項目の補足説明 最後の「備考:各項目の補足説明」に各項目の補足となる説明をまとめました。 Apache v2 License ソ

    nakunaru
    nakunaru 2013/07/25
  • Git にパッチを送って取り込まれた話

    Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調

    Git にパッチを送って取り込まれた話
  • 1