コメント&トラバ

トラックバックを送る

トラバURL : http://suin.asia/trackback/445

コメントを書く

トラックバック

コメント

minahito(2010.03.07) #

> そもそも、XOOPS Cubeが修正BSDライセンスだと勘違いしている人がいるように思います。

XOOPS Cube は修正BSDライセンスです。

> XOOPS CubeはXOOPS Cube LegacyとXOOPS Cube Coreの内包関係があって

これは誤解があるような……
XOOPS Cube は XOOPS Cube Legacy を内包していません。

XOOPS Cube と Legacy は循環依存の関係を完全に廃してあり、
（もともと別々に開発してますから当たり前ですが）
コードが汚くて分かりにくいということを除けば ^^、プログラムの境界線自体は非常に明瞭だと思ってます。

> xoopscube.jpにはXOOPS Cube Coreのみが修正BSDライセンスとの旨を
> 誤解なく書いています。

XOOPS Cube はコアレイヤー以外のプログラムを含ませていないので、
XOOPS Cube が修正BSDということと、 XOOPS Cube Core のみが修正BSDということは同じ意味です。

XOOPS Cube はもともとスタンドアロンアプリケーションではなく、 XOOPS Cube Core は非技術者向けに説明上作られた言葉で、もともと XOOPS Cube はスタンドアロンアプリケーションではなく（そもそもメインシーケンス自体持ってない）、コアレイヤーしかないんです。なのでプロジェクト側では、コアレイヤーという意味で Core は使いますが、正式な名称として XOOPS Cube core という言葉は使ってません。
(Proper Noun = XOOPS Cube. Common Noun = core)

ただプロジェクトページを作るときに話し合った結果、説明が一般向けではないという理由で、プロジェクトページでも、この prefix をつけるようになりました。

XOOPS Cube は CMS の名前ではなく、 TYPO3 の FLOW3 にあたるものです。今後新しい BASE が出てもそれは XOOPS Cube ではありません。

minahito(2010.03.07) #

うう、変な感じになっちゃった (つoT)

> XOOPS Cube はもともとスタンドアロンアプリケーションではなく、 XOOPS Cube Core は非技術者向けに説明上作られた言葉で、もともと

ここは削除して読んでください

suin(2010.03.07) #

> minahitoさん

詳しいご指摘ありがとうございます^^。

「XOOPS Cube Core」は説明の道具といったところでしょうか。
プログラムとしては、内包関係をきっぱり断ち切っているという点、理解いたしました。

しかし、言葉としては、内包ではないにしても、含意があるように感じます。
「XCL は、 ”XOOPS Cube でもあり、」「XOOPS Cube が修正BSDということと、 XOOPS Cube Core のみが修正BSDということは同じ意味です。」などを総合すると、トートロジーにならないでしょうか？（たぶん、このあたりの論理的な整理はminahitoさんにしかできないような気がします…。私はちゃんと理解できたか自信がないです。）

XOOPS Cube, XOOPS Cube Core, XOOPS Cube Legacyの「言葉の問題」はあるものの、「多くのモジュールがGPL汚染をうける」という事実には相違はないですよね。

あと、ツイッターのほうのフォローもありがとうございました。

ちなみに、「修正BSDのXOOPS Cube」というのはこれですよね？
http://sourceforge.net/projects/xoopscube/files/xoopscube/snapshot_20071208/Core_XCube_20071208.zip/download

minahito(2010.03.07) #

対 XOOPS Cube Legacy のモジュールである限りGPLになるのは間違いないと思いますが、あとは本体がMITやBSDで、LegacyベースへのアダプターがGPLというパターンが考えられるくらいかなぁと思います。
（licenseのところにはその旨を書く）

> しかし、言葉としては、内包ではないにしても、含意があるように感じます。

技術的、設計的な事実がすべてです。
もし、「XCLはXOOPS Cubeでもあり」という表現が「"XCLはXCの別名である"という技術的な解説以外に読めない」ということであれば削除しないとまずいですが、あの１文は恐らく XOOPS Cube Legacy は XOOPS Cube のシリーズである、ということが言いたかったんではないかと思うんです。
あのページを作った頃からWikiシステムが移行してしまっていますが、また別途プロジェクトページとWikiのシンクロ機構を作ります。そしたらまた誰でもページ作りに参加できるようになりますので、まずい表現があったら適宜修正お願いします。(^^

> ちなみに、「修正BSDのXOOPS Cube」というのはこれですよね？

修正BSDとGPLはコンフリクトしないのです。
なので Package_Legacy の中に入っている XOOPS Cube も修正BSDです。

suin(2010.03.07) #

> なので Package_Legacy の中に入っている XOOPS Cube も修正BSDです。

たしかにそうですね。GPLでリリースしたとしても、GPLと競合しない修正BSDの規約が消滅するわけではありません。しかし、Package_Legacyはパッケージ自体がGPLなので、その中のXOOPS Cubeが修正BSDだとしても、そのXOOPS CubeがGPLによってもライセンシングされることは間違いありませんよね？

＞ 技術的、設計的な事実がすべてです。

ライセンスの話題から横道にそれましたが、あの文は技術者向けなのでしょうか？そうでなければ、あの文を読むのは技術者だけじゃないと思います。「XOOPS Cube Legacy は XOOPS Cube のシリーズである」と言うのなら、その通りに書いた方が伝わると思います。

OSCでもXOOPS CubeとXOOPS Cube Legacyの違いを聞かれましたし、このブログにも検索キーワード「XOOPS Cube Legacy 違い」などでしばしば訪れる人もいます。この現状から察するに、XOOPS Cubeとは何か、XOOPS Cube Legacyとは何か、など定義をはっきりする必要性も感じます。

言い出しっぺの法則で私がそれを整理してもいいのですが、というか以前試みましたが(http://suin.asia/2008/06/28/xoops-cube-legacy-defference.html)、minahitoさんの話を聞いていると、自分もちゃんと理解できてないようです^^; たぶん、XOOPSを今から始める人なんて、もっと理解できてないと思います。

minahito(2010.03.10) #

> しかし、Package_Legacyはパッケージ自体がGPLなので、
> その中のXOOPS Cubeが修正BSDだとしても、そのXOOPS CubeがGPL
> によってもライセンシングされることは間違いありませんよね？

違います。
Cubeはデュアルライセンスではありません。修正BSDの単一ライセンスなのでLegacyパッケージがそのライセンスを上書きすることは出来ません。
「コンフリクトしない」というのは「共存可能」という意味であって、
「GPLによってライセンスが変更される」という意味ではありません。

言い方を変えます。
「GPLアプリやGPLパッケージが
　GPLと衝突しない非GPLのライブラリに依存していて、
　ライセンスはGPLとしてリリースしている（中のものはそのまま生きている）例は、
　Linuxを初めとして、この世の中にゴマンとあります。
　XOOPS Cube Legacyはそのうちのひとつです」
こ、これでどうでしょうか？

これで分かってもらえないなら、
XOOPS Cubeの無い世界へ旅立ちます（しばらく）

> ライセンスの話題から横道にそれましたが、あの文は技術者向けなのでしょうか？

一般向けということで作られています。

> XOOPS Cubeとは何か、XOOPS Cube Legacyとは何か、など定義を
> はっきりする必要性も感じます。

XOOPS Cube は極小コアライブラリ、 XOOPS Cube Legacy はアプリケーションということで、この設計に決まった時点から定義ははっきりしてます。

一番目立つところの説明がアレなのはよくないとしても、数え切れないくらい色んなところに書いてきてるんで、定義そのものがどこにも存在しないとか、はっきりしていないということはないと思います。
が、suinさんがアクセスできてないということは、普通にやってはそこにたどりつけないということだと思うのでorz
そこは今度直しておきます。

> 言い出しっぺの法則で私がそれを整理してもいいのですが、というか以前
> 試みましたが

読ませて貰いました。プロジェクトページの説明の1,000倍くらい良いです。(^^)b

……ただ、どうなんでしょう。
シンプルに、Cubeはコア、Legacyはアプリ、でいいかなと。
これ別にXCがこの世で初めて採用したアーキテクチャではなくて、一般的な、普通の話、普通の進め方ですよね。
ライセンスにしても全然普通の話で。
分からない人は、どこかで書物を読むなりぐぐるなりしてもらえばよいのであって、XCプロジェクトが責任持ってお教えします！(--)b!!みたいな傾向になってるから、無闇に混乱を招くのかな、と今回改めて思いました。

suinさんはどちらかというと、「モジュールの名称をアプリとかソフトに変えれば分かりやすくなるのでは」という提案の方だと思いますけど、そのあたりはどう思われますか？

suin(2010.03.10) #

> Cubeはデュアルライセンスではありません。
> 修正BSDの単一ライセンスなのでLegacyパッケージがそのライセンスを上書きすることは出来ません。
>「コンフリクトしない」というのは「共存可能」という意味であって、
>「GPLによってライセンスが変更される」という意味ではありません。

Cubeがデュアルライセンスではないことは知っています^^;
「上書きする」という言い方が悪かったです。上書きというよりGPLの制約が付け加えられると言った方が良かったかもしれません。
私の理解が正しければ、GPLと修正BSDを同居させたパッケージの場合、修正BSDの箇所にもGPLのコピーレフトなどの要項が付け加えられると思ったのですが、そもそもこの理解が誤りでしょうか？
GPLの要項が付け加えられないなら、GPL互換・非互換という言葉も必要なさそうに思えます。
基本的に制約の弱いライセンスは制約の強いライセンスに引っ張られるものと理解しています。

LegacyパッケージはGPLで配布されていますから、それがデュアルライセンスでない以上、Legacyパッケージとして入手したcoreはGPLと修正BSDの規約の両方が適用されるのではないでしょうか？
修正BSDの無保証・著作表示、GPLのコピーレフト・制限追加の禁止など。
（もちろん、シリアルナンバーなどで配布を管理していないかぎり、Legacyパッケージに入っていたcoreをコピーして、これはcoreだけダウンロードしたんです、と言ってしまえば、それがGPL＋BSDだったかどうかは証明する手立てはありませんがｗ）

GPLの和訳を一生懸命読んだつもりでしたが、
全然GPLを理解してなかったらごめんなさい^^;;;;


使ったことはないですが、Linuxのだいたいの事情も知っております。
それに、GPLの和訳にもGPLと衝突しないライセンスは一緒に頒布できると書いてありますし。
私は「混ぜるな危険」とは言っていないです。


> 全然普通の話で。
> 分からない人は、どこかで書物を読むなりぐぐるなりしてもらえばよい

これについては私も同意です。
分からない人はググッてもらって、公式で責任を取る事でもないと思います。
先日、「もっとわかりやすくかいたほうがいい」と言ったのは、そう書く義理があるというのではなく、単にそうあったらいいかも、というレベルでした。別に公式じゃなくてもいいと思ったので、このブログにまとめるのを試みた次第です。(このブログだって、のちのちググられる対象になるわけですし。) 他のコミュニティサイトでもいいわけですよね。

今回のライセンスの話にせよ、Cube・Legacyの話にせよ、分からない人なりにググってみて、いろいろ考えをめぐらせみた結果でした。「知る者は語らず 語る者は知らず」の後者だと思ってください。


> suinさんはどちらかというと、「モジュールの名称をアプリとかソフトに変えれば分かりやすくなるのでは」という提案の方だと思いますけど、そのあたりはどう思われますか？

横道ですが、ラベルを変えるだけで、ユーザの理解がすすむなら有益だと思います。
技術的に理由があってとか、インパクト/斬新さ/伝統の意味をこめてとか、それなりの信念で「モジュール」と呼び続けるのなら、それはそれで尊いです。

もし、他に似た意味の何かがあって、それがごく一般に浸透しているのなら、その名前をつかったほうが明解かなと思います。

日本に限って言ったら、iPhoneアプリ、mixiアプリ、携帯アプリ、などよく聞きます。
なので、XOOPSのモジュールに関しては、「アプリ」あたりが妥当じゃないかなと個人的に思う次第です。
他の人がどう考えているかはわかりませんが。

ちなみに、最近こんなのも書きました↓
http://suin.asia/2010/03/09/xoops_cube_terms_vs_other_cms

minahito(2010.03.11) #

> 修正BSDの箇所にもGPLのコピーレフトなどの要項が付け加えられると思ったのですが、そもそもこの理解が誤りでしょうか？

はい、そこは誤解されているところかと思います。

> 基本的に制約の弱いライセンスは制約の強いライセンスに引っ張られるものと理解しています。

これはありません。
ライセンスは著作権者がその権利を元に出す使用許諾（契約）です。
その使用許諾が、その文言のあり方でライセンサーの同意無く制約や条件を追記されたり変更されることはありません。

> GPLの要項が付け加えられないなら、GPL互換・非互換という言葉も必要なさそうに思えます。

互換/非互換ではなく、矛盾ある/なしで解説されていなかったでしょうか？
GPL互換というとAGPLくらいしか思いつきません。互換非互換でいうなら修正BSDは非互換です。矛盾がない（コンフリクトしない）だけです。

> これについては私も同意です。
> 分からない人はググッてもらって、公式で責任を取る事でもないと思います。

やっぱりそうですよねぇ
もっかいコンセンサスをとりつけてプロジェクトページのレギュレーションを変えたほうがよさげですね。

> 別に公式じゃなくてもいいと思ったので、このブログにまとめるのを試みた次第です。他のコミュニティサイトでもいいわけですよね。

ですです。がんがん書いちゃってください！
ありがとうございます。 m(__)m

suin(2010.03.11) #

> その使用許諾が、その文言のあり方でライセンサーの同意無く制約や条件を
> 追記されたり変更されることはありません。

なるほど。ひとつ勉強になりました。
この学習をふまえて、ブログで誤りがあったら訂正しておきます。

> しかし、あなたが同じ部分を『プログラム』を基にした著作物全体 の一部と
> して頒布するならば、全体としての頒布物は、この契約書が課す条件 に従わ
> なければならない。というのは、この契約書が他の契約者に与える許可 は
> 『プログラム』丸ごと全体に及び、誰が書いたかは関係なく各部分のすべて
> を保護するからである。

ここの「(GPLで）各部分を保護する」というのがどういう風に解釈したらいいのかわからないのですが、全体G(=GPL)が一部B(=修正BSD)を含んだ場合、一部BもGPLによって保護、つまりGPLが保証する自由などの要項が付け加えられると誤解してました。

minahitoさんの話を聞いていると、どうやら
・全体G(=GPL)が一部B(=修正BSD)を含んだ場合
・全体B(=修正BSD)が一部G(=GPL)を含んだ場合
の二つでGPL汚染のされかたが違うと言うはなしのようですが、合ってますでしょうか？
前者の場合、一部BにはGPLが波及しない。
後者の場合、全体BにGPLが波及。この場合、全体Bは修正BSDでライセンスしようと思っても、GPLでライセンスしないといけないので、結局GPLになるということですよね。

> 互換/非互換ではなく、矛盾ある/なしで解説されていなかったでしょうか？
> 互換非互換でいうなら修正BSDは非互換です。

矛盾以外に、互換(compatible)ということばはGNUで使われてますよ。
修正BSD(Modified BSD license)は互換(GPL-Compatible)です。
修正じゃないBSD(Original BSD license)は非互換ですが。

> What does it mean to say a license is “compatible with the GPL?”
> It means that the other license and the GNU GPL are compatible; you
> can combine code released under the other license with code released
> under the GNU GPL in one larger program.

http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

minahito(2010.03.12) #

> ここの「(GPLで）各部分を保護する」というのがどういう風に解釈したらいいのかわからない

原文をあたるとややこしいので、Linuxなどの先例にならって「あぁ成立するんだ」くらいに思っておけばいいのではないでしょうか(^^)
Linuxなどのソースを手に入れたとき、GPLでないコードが入ってるってことはそういうことです。

> ・全体G(=GPL)が一部B(=修正BSD)を含んだ場合
> ・全体B(=修正BSD)が一部G(=GPL)を含んだ場合
> の二つでGPL汚染のされかたが違うと言うはなしのようですが、合ってますでしょうか？

そういうことです。GPLは自身の派生物に関する規定はしています（ゆえに後者は成立しない）が、自身が派生物に回る場合の派生元のライセンス波及には触れてません。そんなこと法律上不可能ですから触れることができないと言ったほうが正確かもしれません。

> 矛盾以外に、互換(compatible)ということばはGNUで使われてますよ。

なるほど、原文のほうであればこれは「矛盾しない」「両立できる」のほうの訳をあてて読んだほうがいいと思うんですがどうでしょう。
compatibleを互換と訳すのはコンピュータ用語寄りのときです。これは契約条項なので「矛盾なし」「両立可」のほうで読み取ったほうが良いかと。
英語へぼい僕が言うことじゃないですが……(^^;;

suin(2010.03.12) #

> minahitoさん

> これは契約条項なので「矛盾なし」「両立可」のほうで読み取ったほうが良いかと。

なるほど。おっしゃるとおり、そうのほうが良さそうですね。
今後は、そういうふうに言いまわそうと思います。

> 原文をあたるとややこしいので、Linuxなどの先例にならって「あぁ成立するんだ」くらいに思っておけばいいのではないでしょうか(^^)

原文は本当にややこしいですよね(^^;
# BSDやCCみたいに簡潔にしてほしいものですけどｗ

Linuxの先例に倣うのもひとつのめやすですが、
ただ、GPLはOSについて「特例」を設けているので、
Linux(OS)がやってるから自分もできるとばかり思っていると知らず知らずにGPL違反なんてこともありそうです。

minahito(2010.03.12) #

> Linuxの先例に倣うのもひとつのめやすですが、

メジャーどころの代表格として単にLinuxを挙げただけ（知ってるだろうから）で、もちろんアプリケーションのほうを参考にしています。
もしどうしても信じ難い、minahito間違ってんじゃねーのってことであれば、zlib、MIT、修正BSDを使ってるGPLアプリのソースを入手すればsuinさんの疑問点もスッキリすると思いますよ。

suin(2010.03.12) #

いろいろ教えて下さりありがとうございました。

> 修正BSDを使ってるGPLアプリのソースを入手すればsuinさんの疑問点もスッキリする

実装方法なども含めて、見てみたいです。

minahito(2010.03.12) #

たぶん例の検索にはzlibが一番いいと思います
zlibは修正BSD,MITより緩いライセンス
.zipファイルを扱うアプリでは静的/動的にか関わらずまず間違いなく採用されています。