◀一般トップへ
  • 6404 zlib/libpngライセンス適用へ
    • 6405 Re:zlib/libpngライセンス適用へ
    • 6406 独自ライセンス案
      • 6408 Re:独自ライセンス案
      • 6409 Re:独自ライセンス案
        • 6410 Re2:独自ライセンス案
        • 6411 Re2:独自ライセンス案
          • 6417 Re3:独自ライセンス案
            • 6422 Re4:独自ライセンス案
        • 6412 Re2:独自ライセンス案
          • 6413 Re3:独自ライセンス案
          • 6414 Re3:独自ライセンス案
          • 6415 Re3:独自ライセンス案
            • 6419 Re4:独自ライセンス案
              • 6421 Re5:独自ライセンス案
                • 6423 Re6:独自ライセンス案
      • 6416 Re:独自ライセンス案
        • 6420 Re2:独自ライセンス案
          • 6425 Re3:独自ライセンス案
            • 6426 Re4:独自ライセンス案
            • 6427 Re4:独自ライセンス案
              • 6429 Re5:独自ライセンス案
            • 6428 Re4:独自ライセンス案
      • 6430 独自ライセンス案取り消し
      • 6432 独自ライセンス案取り消し 追記
    • 6407 zlib/libpngライセンス弊害
      • 6424 RE: zlib/libpngライセンス弊害
        • 6431 Re2: zlib/libpngライセンス弊害
  • [6404] zlib/libpngライセンス適用へ maru 2007年10月28日 13:21

    サクラエディタはソースコードの利用について、ライセンス形態が不明確な部分があります。
    そこでzlib/libpngライセンスでまとめられないか、と思い提案です。
    (1)今後の開発参加についてはzlib/libpngライセンスを前提とする
    (2)これまでに提供されたソースコードについてもzlib/libpngライセンス適用を呼びかける

    もちろん(2)については、ソースコードのすべてをzlib/libpng化するのは難しいかもしれませんが、ライセンス不明確なソースコードが少しでも少なくなれば、それだけでも成果だと思っています。

    とりあえず(1)だけでも全体合意が得られれば、細かい断片は年月とともにある程度浄化されるでしょうから、まずは(1)から。
    (1)が通過しそうな手ごたえがあれば、(2)についてさらに積極的にアナウンスしていく展開で。

    皆さんのご意見をお願いします。
    • [6405] Re:zlib/libpngライセンス適用へ kobake 2007年10月28日 22:28

      ライセンスのことは、自分も、明確な基準が欲しいなぁ、と思っていました。
      後で考えを述べさせていただきます。

      ところでこれって一般掲示板向けの話題でしょうか。
      自分などは主に開発掲示板しかチェックしてなかったので、この記事の発見が遅れました。

      あと、zlib/libpngライセンス文書へのリンクを張っておきます。
      http://www.nk2.org/d/amzip/LICENSE-ja.html
    • [6406] 独自ライセンス案 kobake 2007年10月28日 22:50

      自分の考えを述べさせていただきます。
      zlib/libpngは文章が短く理解しやすいですし、
      GPLのような感染性も無く、採用は好ましいと思われます。

      ただ、zlib/libpngライセンスの第2項、第3項の「程度」をどう解釈して良いのか、
      つまり、たとえば関数内のインデントを修正した程度の変更も「変更」とみなされ、
      いちいち「そのことを明示」するコメントを付加しなければならないのか、
      などという細かいことを考えていると、作業の弊害を感じていました。

      個人的に、以下のような独自のライセンスを考えてみたのですが
      どうでしょうか。
      下記ライセンスでは「特約」と書いていますが、元のライセンス文よりも
      特約のほうが長いので、むしろzlib/libpngライセンスとは別のライセンスと
      考えてもらったほうが良いのかもしれません。

      プロジェクト独自のライセンスを採用することは、
      プロジェクトに関わろうとする方に、いちいちライセンス文を読んでもらう手間が生じてしまう、
      という不経済な欠点があります。
      ただ、今回、主に自分が行っておりますUNICODE化の際に、
      プロジェクト全体のソースを見直す作業の過程の中で、
      ライセンスに足を引っ張られているなぁ、と感じる箇所が多々あり、
      どうしても、下記ライセンスのような条項が欲しいなぁ、と感じた次第であります。

      下記ライセンス内で、特に重要だと考えている条項が、特約4です。
      お手数ですが、目をお通しいただき、皆様のご意見をいただけますでしょうか。
      よろしくお願い致します。


      以下、独自に考えました、ライセンス案です。

      -- -- -- --
      zlib/libpngライセンスを採用します。
      http://www.nk2.org/d/amzip/LICENSE-ja.html

      特約として、ライセンスコメントが作業の支障にならないよう、
      以下の「自由」を定めます。

      1.不要コード削除に伴う、それに付随するライセンスコメントの削除を、無承諾で行って良いものとします。
      「コードの解釈のために」必要なコメントがあれば入れてください。

      2.コードに付随するライセンスコメントの位置やフォーマットを無承諾で変更して良いものとします。
      ライセンスコメントの意味が失われなければ、それが別ソースやソース外ドキュメントであっても構いません。

      3.元のライセンスコメントの意味が失われなければ、
      分散した複数のライセンスコメントを、要約して少数にまとめることを認めます。
      元の効果が減少するほどの大規模な要約である場合は、権利者の許可を得てください。
      事後承諾でも構いません。その際、承諾が得られなかった場合は、速やかに元に戻してください。

      4.権利者との連絡が3ヶ月以上とれない場合、
      ライセンスに関わる作業上の制約をすべて無効とします。常識の範囲内で、自由に作業してください。
      ただし、それ以降に再び連絡が取れる状態に復帰した場合は、制約を再度有効とします。
      制約無効期間中の変更に対しては一切の権利を主張しません。

      5.コード的な意味が変わらない変更を、変更とみなすかは作業者の判断に委ねます。
      たとえば、関数内のインデント修正をした場合に、その変更に関する
      ライセンスコメントを追記するかどうかは自由です。
      「コードの解釈のために」必要なコメントがあれば入れてください。
      • [6408] Re:独自ライセンス案 kobake 2007年10月28日 23:24

        追記です。
        個人的には、ライセンスに執着は無くは無いですが、強い執着はありません。

        上記ライセンス文は、あくまでも自分個人の思想を元に作成したため、
        基本的に制限が「ゆるゆる」です。
        たとえば特約2、3などは、嫌がる人はいるかもしれません。

        皆様のご意見を洗い出し、ライセンスに関する最小公倍数的なスタンスが定まれば良いな、と思います。
        その時点で、そのスタンスに近い、既存のライセンスが存在したとしたら、
        上に挙げたような、「いちいち独自ライセンスを読ませるような」不経済を避けるため、
        その既存ライセンスを採用するのも良いかな、と考えています。
      • [6409] Re:独自ライセンス案 ラスティブ 2007年10月29日 00:11

        ラスティブです。zlib/libpngライセンス庇護派です。

        手持ち行動時間がなくなりつつあるので、
        恐縮ですが、先走って突っ込んだコメントをさせて下さい。

        > 特約として、ライセンスコメントが作業の支障にならないよう、
        > 以下の「自由」を定めます。
        >
        > ・・・・(以下略)・・・・

        1について:
        “不要コード”という用語の意味を際限なく拡大解釈することにより、
        改ざんする事をも容認する特約と解釈することができます。

        5について:
        コード的な意味が変わらないものなら変更と見なされないと解釈する
        ことを、事実上、無条件で許可する特約みたいですけれど、コード的な
        意味が変わらない変更が同時多発的に蔓延ることを公式に容認して
        しまっては、代表者さんが更に多忙になるような・・・(^^;)


        いずれも「zlib/libpng ライセンスの既定する範囲で」という一言が
        あれば、個人的に納得できます。(・・・特約だったらこの一言が
        全部にあるのと同じなんでしょうか(^^;))その一言を入れると
        まるで自己矛盾してるみたいに見えますけれど、個人的には
        それくらいのほうが安心できます。

        以上です。
        • [6410] Re2:独自ライセンス案 maru 2007年10月29日 01:15

          私の意見ですが結論から言うと、基本路線は「Unicode化のついでにどんどん書き換えてください」です。

          オープンソースで共同開発のプロジェクトの場合、
          A.作者不詳のソースコードや細かい修正の断片が散りばめられるのを嫌って、“わざわざ別の書き方をしてでも"管理上都合の良いソースコードに置き換えるのが望ましい

          B.度重なる修正でどこが誰のソースコードなのか判別できなくなるケースでは、著作権はプロジェクトが保有する

          C.比較的小さな変更で、誰が書いても同じ書き方になるケースでは、著作権はプロジェクトが保有する

          これらA~Cはほぼ社会通念じゃないでしょうか。ただしAについては、そこまで手が回っていない、というのが実情だと思います。
          この路線でご提案の内容と照らし合わせコメントいたします。

          >1.不要コード削除に伴う、それに付随するライセンスコメントの削除を、無承諾で行って良いものとします。
          Aの考え方により、現状のままでも削除OKだと思います。

          >2.コードに付随するライセンスコメントの位置やフォーマットを無承諾で変更して良いものとします。
          これも、今までにも用語の統一やDoxygen対応、ファイルの分割などいろいろな理由で変更されている事例があるようですが、特に問題になっていないと思います。

          >3.元のライセンスコメントの意味が失われなければ、
          考え方は2と同様でよいのではないでしょうか。
          逆にBのようにライセンスとしての意味が失われれば、(ライセンス上は)コメント削除もOKかと。履歴として残したほうが合理的な場合も多いですが。

          >4.権利者との連絡が3ヶ月以上とれない場合、
          >ライセンスに関わる作業上の制約をすべて無効とします。常識の範囲内で、自由に作業してください。
          >ただし、それ以降に再び連絡が取れる状態に復帰した場合は、制約を再度有効とします。
          >制約無効期間中の変更に対しては一切の権利を主張しません。
          これは難しいですね。連絡が取れない場合、理想としては「元のコードが跡形も無くなるくらい書き換える」でしょうね。
          『再び連絡が取れる(~略~)有効とします』のくだりは、プロジェクトの運営に支障を来たす可能性があり危険では?とんでもない偏屈物が現れなければ普通は大丈夫でしょうけど。
          あと、これは原則としてソースコード提供時に了解が必要だと思いますが、すでにコードが利用されている過去の開発者については、そもそも『3ヶ月以上・・・』の合意が取れません。

          >5.コード的な意味が変わらない変更を、変更とみなすかは作業者の判断に委ねます。
          >たとえば、関数内のインデント修正をした場合に、その変更に関する
          程度にもよりますが、インデントの変更くらいなら変更と見なさない、でいいと思います。
          程度の判断は、やはり「コード的な意味が変わらない」あたりがベースだと思います。

          ~続く~
        • [6411] Re2:独自ライセンス案 kobake 2007年10月29日 01:34

          ▼ ラスティブさん
          > 1について:
          > “不要コード”という用語の意味を際限なく拡大解釈することにより、
          > 改ざんする事をも容認する特約と解釈することができます。

          ある部分を(ライセンスコメントごと)削除した時点で、
          その部分を包括する、ひとまわり大きな部分が変更されたとみなされるため、
          変更内容が明記されない変更が不可能です。
          「不要コード」という言葉には、たしかに解釈のされ方に危険性を孕んでいる気がするので、
          もうちょっと良い言い回しを考えたほうが良いかもしれません。

          自分的には下記のような作業手順を想定しています。

          //2007.10.01 kobake 作成
          int Hoge()
          {
          int n = HogeHoge();
          if(n==1)
          printf("1でした");

          //2007.10.02 anonymous Helloを出力するようにした
          printf("Hello");
          }

          ↓ Hello部分を削除したい

          //2007.10.01 kobake 作成
          //2007.10.10 kobake Helloを出力しないように変更 (※2)
          int Hoge()
          {
          int n = HogeHoge();
          if(n==1)
          printf("1でした");

          (※1)
          }

          解説:
          (※1)特約1により、Hello部分の処理を、「コメントごと」削除。
          (※2)Hoge()が変更されたので、zlib/libpngライセンス第2項により、Hoge()が変更されたことを明記。

          これを許す場合、anonymousさんが関わったという記録は、跡形も無く消えるという、
          ちょっと残念な結果になります。ただ、「自分は」それで構わないと思っています。
          人によっては、それは嫌だと感じるかもしれません。
          (跡形も無く、と書きましたが、実際には
          リポジトリの履歴にanonymousさんの記録は残ります)


          > 5について:
          > コード的な意味が変わらないものなら変更と見なされないと解釈する
          > ことを、事実上、無条件で許可する特約みたいですけれど、コード的な
          > 意味が変わらない変更が同時多発的に蔓延ることを公式に容認して
          > しまっては、代表者さんが更に多忙になるような・・・(^^;)

          代表者さん(げんたさん?)が変更箇所を全部チェックするのでしたっけ?
          そのような管理方針のことを、どこかで目にした覚えはあるのですが、
          どこであったか分かりますでしょうか。探し直してみたのですが、見つかりませんでした。
          すみませんが、ご案内していただけると助かります。

          代表者さんお一人に大きな負担が掛かることは避けたいですね。。。


          > いずれも「zlib/libpng ライセンスの既定する範囲で」という一言が
          > あれば、個人的に納得できます。(・・・特約だったらこの一言が
          > 全部にあるのと同じなんでしょうか(^^;))その一言を入れると
          > まるで自己矛盾してるみたいに見えますけれど、個人的には
          > それくらいのほうが安心できます。

          「思想」としては「zlib/libpngライセンスの思想」を採用する形になると思います。
          ただ、思想である故に、それを文書化することは困難です。
          「zlib/libpng ライセンスの既定する範囲」というものが「zlib/libpngライセンス」に明記されていないのが、
          結果的に足枷になっているのだと、自分は考えています。
          • [6417] Re3:独自ライセンス案 みく 2007年10月29日 08:14

            ▼ kobakeさん
            このコードの例だとanonymousさんのコードを使用しなく
            なったのだから完全に削除できるのではないかと思ったり
            するのです。

            私の意見ですが、
            現在各行にコメントされているものを関数コメント部分に
            集めると言うのはありだと思います。修正部分に名前を残
            しているのは、修正コードをマージするときの目印にする
            ことがあるためで、その場所で著作権を主張したいわけで
            はありません。SVNで管理されていますし、ファイルの頭
            や関数の頭にあれば十分だと思います。

            いずれにせよ、私のコードについてはコメントも含めて削
            除してもかまいません。(後から見て、このコメント見苦し
            いなと思うし・・・)

            ライセンスについては、以前にも主張したとおり、
            zlib/libpngライセンスに従います。
            なお、独自ライセンスや、他のライセンスに変更するよ
            うなことがある場合は、開発者のみなさんの多数案にゆ
            だねます。
            • [6422] Re4:独自ライセンス案 kobake 2007年10月30日 00:13

              ▼ みくさん
              > ▼ kobakeさん
              > このコードの例だとanonymousさんのコードを使用しなく
              > なったのだから完全に削除できるのではないかと思ったり
              > するのです。
              >
              > 私の意見ですが、
              > 現在各行にコメントされているものを関数コメント部分に
              > 集めると言うのはありだと思います。修正部分に名前を残
              > しているのは、修正コードをマージするときの目印にする
              > ことがあるためで、その場所で著作権を主張したいわけで
              > はありません。SVNで管理されていますし、ファイルの頭
              > や関数の頭にあれば十分だと思います。

              自分も、プログラマ的にはまったく同じ意見です。
              ただ、それを「ダメ」と言われたことがあったので
              ちょっと慎重になってしまい、こんな流れになってました。。
        • [6412] Re2:独自ライセンス案 maru 2007年10月29日 01:37

          >>6410の続き
          サクラエディタの場合、ライセンスについての考え方は2通りの視点があって、ひとつはサクラエディタへのソースコード流用、つまりプロジェクトの活動そのものや改造版の作成などです。
          ふたつめはサクラエディタ以外のアプリケーションへのソースコードの流用、たとえば開発者の誰かが何かの商用アプリケーションにCMemoryを流用したい場合などです。

          基本的に前者に対しては、ほぼ無制限の権利が暗黙の了解になっていると思います。

          これはサクラエディタの開発に貢献するものかどうか、というあいまいな判断基準になるでしょうが、過去の掲示板などを見てもサクラエディタへのフィードバックを前提とする限り、コードの流用がライセンス上の問題として取り上げられているのを見たことががありません。

          後者についてはいろいろと意見が分かれるでしょうから、これから議論したい、というのが今回の主旨です。
          • [6413] Re3:独自ライセンス案 kobake 2007年10月29日 01:41

            あ、続きを分断してしまいました(汗)。すみません。
            ご意見ありがとうございます。後で返信致します。
          • [6414] Re3:独自ライセンス案 kobake 2007年10月29日 02:10

            ▼ maruさん
            > 私の意見ですが結論から言うと、基本路線は「Unicode化のついでにどんどん書き換えてください」です。
            >
            > オープンソースで共同開発のプロジェクトの場合、
            > A.作者不詳のソースコードや細かい修正の断片が散りばめられるのを嫌って、“わざわざ別の書き方をしてでも"管理上都合の良いソースコードに置き換えるのが望ましい
            >
            > B.度重なる修正でどこが誰のソースコードなのか判別できなくなるケースでは、著作権はプロジェクトが保有する
            >
            > C.比較的小さな変更で、誰が書いても同じ書き方になるケースでは、著作権はプロジェクトが保有する
            >
            > これらA~Cはほぼ社会通念じゃないでしょうか。ただしAについては、そこまで手が回っていない、というのが実情だと思います。

            なるほど。その社会通念がそのまま適用されるのであれば、
            自分が挙げた特約はすべて取り消してしまっても問題無いと思いました。

            UNICODE化作業の経過の中で、ラスティブさんのほうから個人的にメールをいただき、
            「ライセンスには気をつけて、勝手にコード削除するのは控えたほうが良い」的なアドバイスをいただいたので、
            慎重を期して、今回のような独自ライセンスを挙げてみた次第でした。


            > >3.元のライセンスコメントの意味が失われなければ、
            > 考え方は2と同様でよいのではないでしょうか。
            > 逆にBのようにライセンスとしての意味が失われれば、(ライセンス上は)コメント削除もOKかと。
            > 履歴として残したほうが合理的な場合も多いですが。

            そうですね。
            過去のライセンスコメントがコード上の解釈に重要な意味を成すのであれば、
            意図的に残しておく意義はあると思います。


            > >4.権利者との連絡が3ヶ月以上とれない場合、
            > >ライセンスに関わる作業上の制約をすべて無効とします。常識の範囲内で、自由に作業してください。
            > >ただし、それ以降に再び連絡が取れる状態に復帰した場合は、制約を再度有効とします。
            > >制約無効期間中の変更に対しては一切の権利を主張しません。
            > これは難しいですね。連絡が取れない場合、理想としては「元のコードが跡形も無くなるくらい書き換える」でしょうね。
            > 『再び連絡が取れる(~略~)有効とします』のくだりは、プロジェクトの運営に支障を来たす可能性があり危険では?
            > とんでもない偏屈物が現れなければ普通は大丈夫でしょうけど。
            > あと、これは原則としてソースコード提供時に了解が必要だと思いますが、すでにコードが利用されている過去の開発者については、
            > そもそも『3ヶ月以上・・・』の合意が取れません。

            跡形も無く書き換えるついでに、それに付随するライセンスコメントも消して良いかどうか
            不安だったので、この条項を設けました。
            上に挙げられた社会通念を照らし、慣習的な範囲で不要箇所を削除していけるのであれば、
            作業に支障は出そうもないので、この条項も不要そうです。


            (文字数制限により、次記事へ続く)
          • [6415] Re3:独自ライセンス案 kobake 2007年10月29日 02:10

            (>>6414の続き)

            > サクラエディタの場合、ライセンスについての考え方は2通りの視点があって、
            > ひとつはサクラエディタへのソースコード流用、つまりプロジェクトの活動そのものや改造版の作成などです。
            > ふたつめはサクラエディタ以外のアプリケーションへのソースコードの流用、
            > たとえば開発者の誰かが何かの商用アプリケーションにCMemoryを流用したい場合などです。
            >
            > 基本的に前者に対しては、ほぼ無制限の権利が暗黙の了解になっていると思います。
            >
            > これはサクラエディタの開発に貢献するものかどうか、というあいまいな判断基準になるでしょうが、
            > 過去の掲示板などを見てもサクラエディタへのフィードバックを前提とする限り、
            > コードの流用がライセンス上の問題として取り上げられているのを見たことががありません。
            >
            > 後者についてはいろいろと意見が分かれるでしょうから、これから議論したい、というのが今回の主旨です。

            なるほど。
            後者、つまりサクラエディタ以外へのソースコード流用に関するライセンスに関しての
            意見を述べさせていただきますと、
            自分も、zlib/libpngライセンスオリジナルの条項で問題無いと思います。
            • [6419] Re4:独自ライセンス案 maru 2007年10月29日 23:29

              思いのほか反応があるので、良かったです。
              ただ、もしこのまま大勢の人がこのツリーを育てていくとエライことになりそうで不安・・・。

              wikiの方も細かくチェックしますので、長い議論はwikiでも良いことにしましょう。
              http://sakura.qp.land.to/?Develop%2FLicenses

              ▼ kobake さん
              >跡形も無く書き換えるついでに、それに付随するライセンスコメントも消して良いかどうか
              やや乱暴な説明でしたので念のため補足いたしますと、コード&コメントを削除する場合でも、謝辞(ThanksToなど簡易なもの)は記したほうがスマートだと思います。状況や程度によりますが。

              >自分も、zlib/libpngライセンスオリジナルの条項で問題無いと思います。
              了解いたしました。

              ▼ ラスティブ さん

              >すみません出張りすぎました。あくまで運用上の問題です。
              いえいえ、私も今回の提案は、かなり出張ってますから。

              >規約の解釈自体がトラブルの原因とならないよう
              貴重なご意見ありがとうございます。

              実はライセンス明確化の根本的な目的は、新しく開発参加のする人の妨げになりそうな事情をなるべく減らしたい思いから始まっています。
              簡単に言うとなるべく分かりやすく、です。

              この「分かりやすい」には、不明確でない意味と理解しやすい意味の両方が考えられ、どちらも重要だと思っています。

              最後はバランスの問題になりますが、多少の不明確さは残るものの、過去の実績により比較的現実性が高く理解しやすいzlib/libpngは、ひとつの妥協点だと考えます。

              ▼ みく さん
              >以前にも主張したとおり、zlib/libpngライセンスに従います。
              レスいただきありがとうございます。了解いたしました。
              • [6421] Re5:独自ライセンス案 kobake 2007年10月29日 23:59

                プロジェクト内、対外、の両者に対するライセンスの話が混在していて、
                maruさんが意図するところのスレッドの意義から大きく外れてしまった感があります。

                意見を述べる方のためにも、意見を閲覧する方のためにも、意見をまとめる方(maruさん)のためにも、
                情報整理のために、「対外」のみを対象としたライセンスの見解まとめスレッドを
                このスレッドとは別に立て直したほうが良いと思いました。
                そしたら、現存のこのスレッドは「プロジェクト内」に関する議論をするために使えば良いと思います。

                スレッドを変な方向に膨らましてしまってすみません。。。
                • [6423] Re6:独自ライセンス案 maru 2007年10月30日 00:26

                  >このスレッドとは別に立て直したほうが良いと思いました。
                  お気遣いありがとうございます。
                  ご指摘の通り、ツリーが複雑に成長しているので>>dev:5145にスレッドを分けました。
                  そもそも開発版で議論すべき話題でしょうから、ちょうど良かったです。
      • [6416] Re:独自ライセンス案 ラスティブ 2007年10月29日 07:15

        すみません。補足というかなんと言うか、たぶん自分の傲慢で
        フレームを生じさせてしまったように感じるところがあるので、
        消火します。

        ▼ maru さん(>>6410)
        > オープンソースで共同開発のプロジェクトの場合、
        > A.作者不詳のソースコードや細かい修正の断片が散りばめ
        > られるのを嫌って、“わざわざ別の書き方をしてでも"管理上
        > 都合の良いソースコードに置き換えるのが望ましい
        >
        > B.度重なる修正でどこが誰のソースコードなのか判別できなく
        > なるケースでは、著作権はプロジェクトが保有する
        >
        > C.比較的小さな変更で、誰が書いても同じ書き方になるケース
        > では、著作権はプロジェクトが保有する
        >
        > これらA~Cはほぼ社会通念じゃないでしょうか。

        メモメモ φ(..)

        ----

        ▼ kobake さん(>>6411)
        > 代表者さん(げんたさん?)が変更箇所を全部チェックするの
        > でしたっけ?そのような管理方針のことを、どこかで目にした
        > 覚えはあるのですが、どこであったか分かりますでしょうか。
        > 探し直してみたのですが、見つかりませんでした。
        > すみませんが、ご案内していただけると助かります。

        すみません出張りすぎました。あくまで運用上の問題です。
        変更分がすぐさま反映できない事態になったとき(パッチが競合
        しているとかで)、変更者は事情が把握できず、ライセンス違反
        でも起こしたのだろうかと勘違いする人(たぶん自分も含まれる)
        が、公式に明文化することでさらに増えるのではないかと危惧した
        のでした。

        http://members.at.infoseek.co.jp/sakura_editor/repositorymgmt.html


        > 「zlib/libpng ライセンスの既定する範囲」というものが
        > 「zlib/libpngライセンス」に明記されていない

        ご尤もです。

        ----

        体外的に仮に明文化するほうがいいようでしたら、規約の解釈
        自体がトラブルの原因とならないよう、論理的に解釈できるものが
        欲しくて、それでなければ、むしろ思想を掲げるだけに留めて
        おいて欲しい・・・というのが個人的な要望なのでした。
        • [6420] Re2:独自ライセンス案 kobake 2007年10月29日 23:49

          > ▼ kobake さん(>>6411)
          > > 代表者さん(げんたさん?)が変更箇所を全部チェックするの
          > > でしたっけ?そのような管理方針のことを、どこかで目にした
          > > 覚えはあるのですが、どこであったか分かりますでしょうか。
          > > 探し直してみたのですが、見つかりませんでした。
          > > すみませんが、ご案内していただけると助かります。
          >
          > すみません出張りすぎました。あくまで運用上の問題です。
          > 変更分がすぐさま反映できない事態になったとき(パッチが競合
          > しているとかで)、変更者は事情が把握できず、ライセンス違反
          > でも起こしたのだろうかと勘違いする人(たぶん自分も含まれる)
          > が、公式に明文化することでさらに増えるのではないかと危惧した
          > のでした。
          >
          > http://members.at.infoseek.co.jp/sakura_editor/repositorymgmt.html

          変更分がなかなか反映されない場合は、その理由を問い合わせて答えを待つのが
          社会的な行動規範だと思います。
          問い合わせもせずに勝手に不安要素を「想像で」膨らましてしまうような
          特殊なケースまで想定する必要は無いと思います。


          > 体外的に仮に明文化するほうがいいようでしたら、規約の解釈
          > 自体がトラブルの原因とならないよう、論理的に解釈できるものが
          > 欲しくて、それでなければ、むしろ思想を掲げるだけに留めて
          > おいて欲しい・・・というのが個人的な要望なのでした。

          >>6415に書きましたとおり、「対外的には」特約を明文化する必要はまったく感じておりません。

          あくまでも、プロジェクト関係者の作業に支障をきたすような、
          ライセンスの解釈をされた場合に、
          それを「正式に回避するために」特約を設けたかっただけです。

          そのようなライセンスの解釈とは、つまり、
          ラスティブさんから受け取ったライセンスに関する注意のメールに書かれた思想のことです。
          「鋼の掟」とまで書かれてしまっては、非常に強い制約を感じ、
          正直言うと、zlib/libpngライセンスが悪の権化とさえ感じてしまいました。
          この掲示板における議論が進む前までは、
          それがプロジェクトを代表する見解であると解釈しておりましたから、
          「正式に」zlib/libpngライセンスを打破する特約を練り上げたわけです。

          親切にメールをいただき感謝しておりますし、
          今回挙げております、ラスティブさんからのメールに対する自分の見解には、
          決して悪意があるわけでは無いことをご理解ください。

          ただ、ラスティブさんの見解を再度、確認させていただきたいです。
          maruさんが書かれている「社会通念」がラスティブさんの見解の変化に影響を与えたように見受けられますが、
          今の時点で、ラスティブさん的に、コード改変に関する制約はどの程度であるようにお考えでしょうか。

          #個人間のメールに関する内容を掲示板の議論に含めてしまい申し訳ありません。
           ただ、1対1のメールという対話手段は、殊に答えが明確でない議論を行うときは特に、
           第三者の軌道修正が入らないため、危険だと考えます。
          • [6425] Re3:独自ライセンス案 げんた 2007年10月30日 01:10

            >> ▼ kobake さん(>>6411)
            >> > 代表者さん(げんたさん?)が変更箇所を全部チェックするの
            >> > でしたっけ?
            SVN管理にするときに作成した運用ルールでは,基本的にピアレビューを行ったものしかcommitしてはいけないことにしています.別に特に誰がと決めてはいないのですが,他の人のパッチを見るような奇特な人は私とryojiさん位しかいないというのが現実です.
            ピアレビュー強制がcommit速度を落としていることは認識していますが,自分で作ったパッチもryojiさんに突っ込まれることが多いですし複数の目で確認しないとやはり危険.でも見る人がいない→Test Driveにならないと立ちゆかなくなる気がしています.

            >> 変更分がすぐさま反映できない事態になったとき(パッチが競合
            >> しているとかで)、変更者は事情が把握できず、ライセンス違反
            >> でも起こしたのだろうかと勘違いする人(たぶん自分も含まれる)
            そんなことを考える人がいるとはゆめにも思いませんでした.

            変更が反映されない理由:
            - 単に忙しい.(遊び含む)
            - 不具合がある
            - わかりにくい.既存機能に影響がないという確証が得られない.
            - その機能に興味がない
            ↑こういう理由で,大きな変更やマイナーな変更がcommitされづらいので,ノーチェックで単純にパッチを組み合わせただけのテスト版を時々作ってます.
            • [6426] Re4:独自ライセンス案 ラスティブ 2007年10月30日 07:15

              ラスティブです。

              ▼ kobake さん(>>6420)
              > 問い合わせて答えを待つのが社会的な行動規範だと思います。
              ▼ げんたさん(>>6425)
              > そんなことを考える人がいるとはゆめにも思いませんでした.

              orz.

              妄想には気をつけることにします。(でもパッチが統合され
              ないことをわざわざ問い合わせすると、あからさまに
              出張りすぎてしまうし、そんなヘンな所で出張る気はないし、
              でもペンディング状態にあるということはどこかいけない
              ところがあるわけで、ライセンス違反を起こしている可能性も
              考慮に入れ・・・

              あ。必死杉の魔粉が・・・。)

              気を取り直しまして。。。
              以下は、ライセンスに関する感想です。長いので読みたい方だけ
              どうぞ。

              ----

              次に書きますのは私が持つ主観的で、社会的に
              見ると偏っている部分がある感想だということを、
              はじめに申し上げておきます。。。
              (この掲示板に投稿してよかったのかどうか・・・。)

              ・・・・・・続く
            • [6427] Re4:独自ライセンス案 ラスティブ 2007年10月30日 07:18

              (>>6426 からの続き)

              > 「鋼の掟」とまで書かれてしまっては、非常に強い
              > 制約を感じ、正直言うと、zlib/libpngライセンスが
              > 悪の権化とさえ感じてしまいました。

              鋼の掟というのは言い換えると暗黙のルールだと勝手に
              思っています。“悪魔のテイスト”を付けて自虐表現すれば、
              それを破ると、ぷはは異端児だぜちゅどんみたいな感覚に
              陥るような。。限りなく妄想に近いですが。


              > それがプロジェクトを代表する見解であると解釈して
              > おりましたから、「正式に」zlib/libpngライセンスを
              > 打破する特約を練り上げたわけです。

              (・_・;)

              出張りすぎましたすみません orz


              > maruさんが書かれている「社会通念」がラスティブさん
              > の見解の変化に影響を与えたように見受けられますが、
              > 今の時点で、ラスティブさん的に、コード改変に関する
              > 制約はどの程度であるようにお考えでしょうか。

              ライセンスに対する考え方は、以前も今も大きく変わって
              いませんが、>>data:6410 に書かれている社会通念を拝見し
              まして、結構ルーズに考えてもいいものなんだなと、目から
              うろこが落ちたというか、もやもやが解けたという感じです。
              以下に、コード改変の際に自分に課している制限事項を、
              自分が書いたメールの内容から引用します(自分が上書きして
              消しちゃった CMemory.cpp 内にある人の名前を CESI.h に
              引越しし忘れているとかで遂行率が悪くて、お披露目するの
              にはいささか気が引けるのですが。):

              ========================================
              =================

              ・特定の関数内だけの変更の場合:

              変更した関数が書かれているソースファイルだけに変更した
              内容と変更者と適当な日時を書き込んでおきます。ただし、
              その変更によって他のソースコードが元と似ても似つかぬほど
              改変されるようであれば、他作者の権利保護のための適切な
              コメントを該当部分に補う必要があるかと思います。

              ・クラスレベルの大改造の場合:

               3.ソースの頒布物から、この(著作権)表示を削除したり、
                 表示の内容を変更したりしてはなりません。

              上記の zlib/libpng ライセンス条項を強く意識し、変更内容を
              著作権表示とともに書き連ねることが重要です。大改造によって
              消滅するクラスや関数に対しては、そのクラスや関数の生まれ
              変わり先にその経緯と元ソースの著作者情報を記載する・・・
              というのがこのライセンス条項に秘められているマナーのように
              思います。

              ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

              例えば、こおりさん(コード中では Frozen さん)の
              CDocLineMgr.cpp での変更例を見てみますと、削除した理由を
              コメントに書き残していますね。その後自分ならばある程度の
              認知期間を置いてからコメントアウトした部分をばっさり削除
              するという行動パターンを取ります。ココで一番悪いのは、
              経緯や事情を周囲に知らせずに突然削除することではないかなと。

              ========================================
              =================

              kobake さんの場合、事情が周囲に十分に知れ渡っているので、
              削除理由まで気にする必要はないかと思います。

              P.S.
              参考例として取り上げさせていただきました>こおりさん
              • [6429] Re5:独自ライセンス案 kobake 2007年10月31日 00:43

                ▼ ラスティブさん
                > > それがプロジェクトを代表する見解であると解釈して
                > > おりましたから、「正式に」zlib/libpngライセンスを
                > > 打破する特約を練り上げたわけです。
                >
                > (・_・;)
                >
                > 出張りすぎましたすみません orz

                いえいえ、こちらも、勝手に解釈していた節があるので。。

                ラスティブさんは、「出張る」という言葉を、あまり前向きで無い意味で、よく使われるようですが、
                活発に活動することは、むしろ、プロジェクトのために好ましいことだと思います。


                > kobake さんの場合、事情が周囲に十分に知れ渡っているので、
                > 削除理由まで気にする必要はないかと思います。

                了解です。
            • [6428] Re4:独自ライセンス案 kobake 2007年10月31日 00:02

              ▼ げんたさん
              > >> ▼ kobake さん(>>6411)
              > >> > 代表者さん(げんたさん?)が変更箇所を全部チェックするの
              > >> > でしたっけ?
              > SVN管理にするときに作成した運用ルールでは,基本的にピアレビューを行ったものしかcommitしてはいけないことにしています.
              > 別に特に誰がと決めてはいないのですが,他の人のパッチを見るような奇特な人は私とryojiさん位しかいないというのが現実です.
              > ピアレビュー強制がcommit速度を落としていることは認識していますが,自分で作ったパッチもryojiさんに突っ込まれることが多いですし
              > 複数の目で確認しないとやはり危険.でも見る人がいない→Test Driveにならないと立ちゆかなくなる気がしています.

              なるほど。コミットの流れを理解しました (今更で、すみません)。
              ピアレビューの制度は、安易なクオリティ低下を防止するためにも、良い文化だと思います。

              自分が、UNICODE化以降も「密に」開発に関わるかは、気分次第なのでなんとも言えませんが、
              興味を惹かれるパッチに関しては、もしお力になれるのであれば、自分からもレビューに参加させていただきたいと思います。
              (自分がユーザーとして使いたい機能を促進するだけという、自分本位な理由ですが)
      • [6430] 独自ライセンス案取り消し kobake 2007年10月31日 00:57

        プロジェクトにおけるコーディングの作業方針がなんとなく理解できました。
        それを照らし合わせると、自分が挙げた独自ライセンス案は、
        まったくの不要であると思われるので、完全に取り消させてください。


        とりあえず、自分の基本スタンスは>>6410でmaruさんが書かれている「社会通念」と一致します。
        それに、適宜、プロジェクトのローカルルールを適用しています。
        (会社であれば会社のルール、サクラエディタであればサクラエディタのルール)

        今回は、そのローカルルールの把握にズレがありました。

        以下が今までの経緯です。


        無断でUNICODE化始める。割と何も気にせずコード変更しまくり。
        ソースコードの文化 (コーディング規約的なものとか) はソースコードから汲み取りつつ、作業。
        始めの頃は真面目にコメントを付けていたが、変更箇所が100を超えた辺りから、
        コード解釈に意味のないコメント付けを省略し始める。(変更量の膨大さを見誤ってました(汗))
        ↓
        テスト版公開。本家掲示板へアナウンス。
        ↓
        げんたさんから、ある程度自由に作業しちゃって的な
        アドバイス (>>dev:5035とか) をいただいたこともあり、
        引き続きラフに作業。
        ↓
        作業もほどほどに進み、バグも少なくなってきたころ、
        自サイトのほうの掲示板で、anonymousさんにライセンスに関する問い合わせを受ける。
        (この頃、自作クラス等には、ほとんど著作権表記をしていませんでした)
        http://mofmof.nsf.tc/soft/wforum/wforum.cgi?mode=allread&no=48&page=0
        政治的な思考が足枷になるのを避けるため、あえてそういうことを意識から外していたこともあり、
        やはりラフなスタンスで回答。
        そのとき初めて、zlib/libpngライセンス文に目を通す (すみません(汗))。
        ↓
        ラスティブさんからメールにて、ライセンスに関する以下のご注意をいただく。
        ・ライセンスコメントをちゃんと書くこと
        ・ライセンスコメントを消さないこと
        立場的にラスティブさんが元UNICODE化リーダーであったこともあり、
        そのメールがプロジェクトの代表的見解だと解釈し、
        そういった思想がプロジェクトのローカルルールなのだと理解。
        オープンソースプロジェクトへの参加が初めてだったこともあり、
        郷に入れば郷に従え的な感じです。
        ↓
        ルールに従うにしても、ルール適用と実作業を並行して行うのは非効率すぎるので、
        「後から」マージして、ライセンスコメントを整理することに方針を決定。
        そして、あわよくば、ルールそのものを変えてしまおうと画策。
        ↓
        将来のマージ作業も想定しつつ、コーディング作業続行。
        ブランチ作成も近づいてきたので、ライセンスに関する議論を提起しようと、機会を伺う。
        ↓
        ちょうどそれに関するスレッドが立ち上がったので、
        今回の独自ライセンス案を提示。
        ↓
        皆様のコメントから、実はそんなに深く考えなくても大丈夫っぽい空気であることが判明。
        ↓
        独自ライセンス案など無くても快適に作業できそうなので、取り消し。
      • [6432] 独自ライセンス案取り消し 追記 kobake 2007年10月31日 01:19

        自分の、深く考えすぎっぽい意見に対して、皆様ご助言ありがとうございました。

        プロジェクトのローカルルールの解釈における、
        自分が想定していた前提が、議論の途中でコロっと変わってしまったので、
        詳細なご助言に対して、やけにあっさりした返答になってしまったところもあり、
        後で見返してみると申し訳なく思うところもありますが、
        皆様のご助言が、軌道修正の大きな助けになったことは確かです。
        ここで感謝申し上げます。ありがとうございました。
    • [6407] zlib/libpngライセンス弊害 kobake 2007年10月28日 23:08

      特に印象的だった zlib/libpngライセンスの弊害 (と感じられた箇所) を挙げます。


      何年も前にコメントアウトされたコード群が
      削除されずにそのまま放置されている。
      ↓
      zlib/libpngライセンスの制限 (と解釈され得る思想) のせいで、
      誰も削除できなかったのではないでしょうか。
      (単なるコメントアウトされたコードだけであれば削除できたかもしれないが、
      そのコメントアウトブロック内に、ライセンスコメントが含まれているために、
      扱いをどうすれば良いか、判断が付かなくなる)


      実際のコードよりも、それに付随するライセンスコメントのほうが多く、
      可読性が著しく損なわれている箇所がある (CShareData::InitKeyAssign 等)。
      ↓
      zlib/libpngライセンス文からは、
      ライセンスコメントの位置を移動して良いか等の判断が付かないため、
      やはり誰も整理できなかったのではないでしょうか。
      • [6424] RE: zlib/libpngライセンス弊害 げんた 2007年10月30日 01:10

        今頃現れました.

        kobakeさんのこの意見はちょっと考えすぎな気がします.
        >何年も前にコメントアウトされたコード群が
        >削除されずにそのまま放置されている。
        >↓
        >zlib/libpngライセンスの制限 (と解釈され得る思想) のせいで、
        >誰も削除できなかったのではないでしょうか。
        いや,たぶん別に気にしてなかっただけだと思います.
        自分が周辺を直す時は適宜消すようにしていますが,

        あと,プロジェクトによっては削除するなというルールがあるところもあるようで,そういうのになれた人が編集すると,コメントだらけになるのかも... (#if 0~#endifの嵐よりはコメントの方がまだま...うわ~なにを~qあwせdrftgyふじこlp)

        >実際のコードよりも、それに付随するライセンスコメントのほうが多く、
        >可読性が著しく損なわれている箇所がある (CShareData::InitKeyAssign 等)。
        >↓
        >zlib/libpngライセンス文からは、
        >ライセンスコメントの位置を移動して良いか等の判断が付かないため、
        >やはり誰も整理できなかったのではないでしょうか。
        みくさんの意見と重複しますが,修正箇所を明示するのはライセンス上というよりは,誰がいつどこを何のために直したかを一目でわかるようにするためのものと考えます.仕様も流動的ですし,ソースから意図が必ずしも読み取れるとは限りません.

        このあたりはソース管理をしているのだからコメントはリポジトリに書けばよいと考える人と,あくまで編集するのはソースコードであってリポジトリを見ながら作業をするわけではないから,一目で経緯がわかった方が都合がよいと考える人がいるようです.私は後者の方が好みです.

        それとSubversionの公開リポジトリは使い始めてまだ1年半くらいでして,それまでは私が手元のCVSにまとめたものを時々アップロードしていました.(が,見ている人がいたかは不明)

        もっとも,CShareData::InitKeyAssignみたいに同じコメントが各行にあるのを今までの経緯として先頭にまとめるのはウェルカムだとおもいます.
        • [6431] Re2: zlib/libpngライセンス弊害 kobake 2007年10月31日 01:14

          ご助言ありがとうございます。
          >>6430に詳しく書きましたが、
          プロジェクトにおける作業方針とzlib/libpngの解釈にズレがありました。
          自分の個人的スタンスは、ご助言いただいた内容と一致します。

          プログラマ的な「善」(解釈は広いですが)を軸に、ソース整理も引き続き行わせていただきます。
          万一問題があったとしても、それがブランチであれば共同作業時に、パッチであればピアレビュー時に突っ込まれますし。