ライセンスの追加 #2
Comments
|
補足すると、オープンソースの定義に従うと、オープンソースソフトウェアは二次的著作物を同一ライセンスのもとで配布することを許可している必要があります。
しかし、IchigoJam BASICの配布条件によると、改変した版を自由に配布することが不可能であり、オープンソースの定義に矛盾します。（「注意いただきたい」というのは意図がやや不明瞭ですが、「禁止する」の意味合いで使われていると解釈できます） また、GitHubではリポジトリのフォークが容易なため、現状のライセンスのままGitHubで公開し続けることで利用者が意図せずライセンス違反をしてしまう危険性があります。 |
これの禁止がOSSとして認めるには致命的です。 これを認めない限りただのソースアベイラブル止まりです。
という事例はいくつもあり、それを自由に認めなければなりません。
他はOSSライセンスに類似条項があるのでノーカンとします。
↑ただしフォークして修正パッチ作っただけで違反しかねません。問題があるなら商標違反で訴えればいいのでは？ あと、GPL系と商用ライセンスのデュアルライセンスの例はまずまずあります。
|
|
捕捉しますと、ソースを公開すればオープンソースだという認識は、典型的な誤りです。
OSS を名乗りたい場合、最も手軽な手段は OSI Approved Licenses (邦訳) のいずれかを選択して適用する事です。 なお、「ライセンスが明示されていないのは、どんなライセンスよりも厳しいライセンスだ。」という有名な指摘があります。
プレスリリースではオープンソース化と言われていますが、現在このリポジトリ単体ではライセンスが明示されていませんので OSS と言うよりも、上記で指摘される最も厳しいライセンスに近い状態と言えるかもしれません。 10周年のお祝いに水を差すような事を書いてしましましたが、10周年とオープンソース化の決断による新たな門出にお祝い申し上げます。 |
|
詳細なコメント、ありがとうございます！ |
|
プレスリリース、特に「当社の許可」や「譲渡（有償無償は問わない）目的で利用する際」の行はMITライセンスで示されている条件と齟齬が生じているように思います。混乱が生じ得ますのでプレスリリースにも修正を加える必要があろうかと思います。 |
|
ありがとうございます |
|
補足 MITライセンスはクレジット載せて自己責任なら誰でも自由に使ったり改変したりしていいよという寛容寄りのライセンスです。 また、共通事項としてOSSでは商売そのものの禁止や改変の禁止はできません。例えばCC-BY-NCやCC-BY-NDはOSSライセンスではありません。GPLなど（ただしSSPLのように過激化するとOSSから外されてしまいます）のようにソースコード開示義務で商売として成り立ちにくくするのが唯一の対抗手段となります。 OSSライセンスを採用しない場合、「オープンソース化」ではなく「ソースコード公開」が適切な表現です。 |
これに関してはGitHubのTerms of Serviceで「5.他のユーザーへのライセンス付与」として許可されているため、フォークするだけであればGitHubの利用規約内の行為です。
|
|
ライセンスの追加とプレスリリースの修正の対応、ありがとうございます。
これを、「ご注意いただきたい点」として挙げているのは何か特別な理由があるのでしょうか？ |
これを消しただけだとzlibライセンス相当の防御力しかないので、権利表記同梱義務（MITなど）など追加の条件を記すことを推奨します。
おそらくオリジナルと偽ることを禁止したいだけではないでしょうか？「別の名前でオリジナルと偽って配布すること」やMITライセンス流の「権利表記を消したり同梱しないこと」に書き換えるとよいのではないでしょうか？
「オリジナル（未改変）のIchigoJam BASICと偽って配布すること」「改変内容を記さずに配布すること」の方が自然ですが、MITではカバーできないのでライセンス変更を検討ください。（Apache LicenseやGPL系など）
権利表記して自己責任なら自由というMITの条件に反します。金儲けをする場合はサポートで取る（OSSの利用は基本自己責任です。フリーライダーはモルモットや人柱）、GPL系と商用ライセンスとのデュアルにしてソース開示したくない利用者に有料ライセンス契約を迫る、ボードの購入や再販などにIchigoJam BASICの利用目的を制限する追加の（エンドユーザー）ライセンス契約を必須とする（互換OSへの流用を禁じたRHELが参考となりますが更改直後は批判の的になっていました）などの追加手段が必要となります。 |
これを消しただけだとzlibライセンス相当の防御力しかないので、権利表記同梱義務（MITなど）など追加の条件を記すことを推奨します。
おそらくオリジナルと偽ることを禁止したいだけではないでしょうか？「別の名前でオリジナルと偽って配布すること」やMITライセンス流の「権利表記を消したり同梱しないこと」に書き換えるとよいのではないでしょうか？
「オリジナル（未改変）のIchigoJam BASICと偽って配布すること」「改変内容を記さずに配布すること」の方が自然ですが、MITではカバーできないのでライセンス変更を検討ください。（Apache）
権利表記して自己責任なら自由というMITの条件に反します。金儲けをする場合はサポートで取る（OSSの利用は基本自己責任です。フリーライダーはモルモットや人柱）、GPL系にしてソース開示したくない利用者に有料ライセンス契約を迫る、ボードの購入や再販などにIchigoJam BASICの利用目的を制限する追加の（エンドユーザー）ライセンス契約を必須とする（互換OSへの流用を禁じたRHELが参考となりますが更改直後は批判の的になっていました）などの追加手段が必要となります。 個人的な疑問：商用なら(A)GPLのみ、無償なら加えてzlib（またはMIT）も選択可みたいなデュアルライセンスはOSSライセンスとして適切？ |
|
ビジネス的には Copyleft 系と商用のデュアルライセンスの形が一番無難な気がしますがどうなのでしょう。 例:
pull request template については以下が参考になると思います。
もちろん、著作権に関する無知や無理解、あるいは虚偽の申告や悪意を持って GPL 汚染のような事を生じさせられる可能性は残りますが。 |
これは私も気になっているのですが、更新されたプレスリリースで示されている以下の条件
を鑑みるに、商標権の利用料の話だろうと理解しています。 また、MIT ライセンスでは配布自体は自由となるため、150円の義務は無体物であるソフトウェア単体の頒布では生じず、ハードウェアにデプロイして有体物になった上で IchigoJam BASIC の名前を冠した場合にのみ生じる気がしているのですが、この理解も正しいでしょうか？ 万が一そうでない場合、GitHub 上で fork して、それを clone や fork される度に 150 円の支払い義務が生じてしまい大変なことになりますし、これは最早 OSS とは言えなくなりますから、上記の理解は合理的と思いますが如何でしょう？ これは、現在のところ要問合せの事項と思いますが FAQ としてあらかじめ整理されておいた方が良いと思います。 |
FBやMSなどだとコントリビューターライセンス同意書（CLA）に署名させてきたりしますね、手続きの煩雑さはさておきそれで解決しそう？ |
|
[https://gist.github.com/bungoume/3031457 参考：MITライセンスの日本語訳 あとはVS Codeのように公式ビルドは別ライセンスにするという手段もあります。（VSCodiumみたいな派生物はつくられますが） |
現在、このプロジェクトには詳細なライセンスファイルが提供されていないため、ライセンスファイルを追加することを要求します。
また、プレスリリースにはライセンスに関して矛盾した文章が含まれております。
それらを解消するために、Open Source Initiativeが承認したオープンソースライセンスの適用を要求します。
https://www.b-incorp.com/press/202404011000/
The text was updated successfully, but these errors were encountered: