いくら個人事業主だからって法務適当なまま強気に出すぎだろ・・・
【License】ライセンス総合【利用許諾】
いくら個人事業主だからって法務適当なまま強気に出すぎだろ・・・
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
IURCO
OSSのライブラリやフレームワークを使う場合
サイトのページ生成やサービス(WedAPIなど)として公開する場合
使用したOSS等のライセンス表示したほうがいいの？
特定のライセンスで扱いがわからないのならそれを提示しないとエスパーにしかわからない
ライセンス文読めって言えばそれはそうだよな
こたえてくれてありがとう
使用したいコードがMITライセンスなのですが、使いたい部分は全体の10％で、
コードの90％は不要なので削りたいです。
MITはコピーレフトNOで、コピーレフトの要件はwikipediaによると、
＞ 著作物の利用、コピー、再配布、翻案を制限しない
＞ 改変したもの（二次的著作物）の再配布を制限しない
＞ 二次的著作物の利用、コピー、再配布、翻案を制限してはならない
＞ コピー、再配布の際には、その後の利用と翻案に制限が無いよう、全ての情報を含める必要がある（ソフトウェアではソースコード含む）
＞ 翻案が制限されない反面、原著作物の二次的著作物にも同一のコピーレフトのライセンスを適用し、これを明記しなければならない
であり、上記の要件をすべて否定すると改変も出来ないことになりますが、
MITがコピーレフトでないのは、
＞ 二次的著作物へのライセンス適用や、使用可能なソースコードのコピーを義務づけていないため、コピーレフトではない
からであって、コードを削るなどの改変については制限されていないという解釈で良いのでしょうか？
また削った場合の作者はオリジナルの作者のままでいいのでしょうか？
もし不具合があってそちらに連絡がいくのも困るので、
併記してmodified by meのようなことを書けばいいのでしょうか？
別に元のプログラムに問題があるわけではないので、modifiedの部分が適切かはわかりませんが。
では質問を変えます。
改変したコードのライセンス表記はどのようにしたらいいのでしょうか？
混ざって訳わからなくならんようにそれと区別して改変云々を書いておく
アプリのヘルプとかでずらっと箇条書きにしてあればいいのかな？
別途LICENSE.txtや取説にも書く必要ってある？
The icon "beasts-48.png" is taken from Aha-Soft’s Free Retina iconset, and used
under the terms of its license (http://www.aha-soft.com/free-icons/free-retina-icon-set/),
with a link back to the website: http://www.aha-soft.com/.
aha-softのURLが開かないんだがbeasts-48.pngを再配布に使っていいのか？
・素性不明だが、libgccみたいなライブラリのソースの一部を改変・流用
・当該ソースには「GPLランタイムライブラリ例外」の記載
・非GCC、プロプライエタリなコンパイラ利用
・商用利用
・バイナリはエンドユーザーまで配布(販売)
この場合、次の処置が必要という認識でいい？
・ReadmeにGPLソフトを利用している旨とライセンス条件ファイルを添付
・流用ならびに改変したソースを添付するか、要求があれば送付する旨の書面を添付
・ランタイムライブラリ例外が適用されるので、当該ファイル以外は公開不要
商用なので正確には法務担当に確認すべきなのは分かってるが、
前任から引き継いだらこんなことになっていた。
リリースまで余裕はあるので上に報告するための話を考える情報にしたい。
条件を読む限り、一部のソースを流用してランタイムライブラリの形ではなくプログラムに直接組み込んでいると思う
それでは製品プログラムは独立モジュール（Independent Module）とはみなされないはず
https://www.gnu.org/licenses/gcc-exception-faq.html
に『GCCライブラリからなんのソースも含まない限り、それぞれのファイルは「独立モジュール」です』と書いてある
ランタイムライブラリ例外は独立モジュールが
ランタイムライブラリの形でのGPLソフトウェアを利用している場合に対しての許可なので
独立モジュールじゃなければ、例外に該当しない
プログラム全体がGPLになるはず
ご指摘のとおり、ライブラリから切り離したであろう.c/.hをプロジェクトに組み込んで使っています。
この形だともはや「ランタイムライブラリ」じゃないという解釈ですね。
つまり、今回のパターンをクリアにするなら例えば
・libgccから不要な機能を削除したスタティックリンクライブラリlibgcc_dietを作成し
・開発中のソフトウェア(独立モジュール)からlibgcc_diestをリンクする
とすればランタイムライブラリ例外が適用できる可能性がある、ということでしょうか。
当然、libgcc_dietはGPLに従いソース含めて公開することを前提とします。
LGPLの話ではないのでスタティックかシェアードかは関係ない
（FAQにも静的リンク、動的リンクであってもランタイムライブラリ例外は利用可能とある）
https://www.gnu.org/licenses/gcc-exception.html
に独立モジュール（Independent Module）という用語が定義されている
> A file is an "Independent Module" if it either requires the Runtime Library for execution after a Compilation Process, or makes use of an interface provided by the Runtime Library, but is not otherwise based on the Runtime Library.
Google翻訳
> ファイルは、コンパイル・プロセスの後に実行するためにランタイム・ライブラリを必要とするか、またはランタイム・ライブラリによって提供されるインタフェースを使用するが、そうでなければランタイム・ライブラリに基づいていない場合、「独立モジュール」である。
ランタイムライブラリ例外の対象はランタイムライブラリと独立モジュールを組み合わせて作られたターゲットコードへの許可のみ
独立モジュールはコンパイル後だけランタイムライブラリを使う（リンクする）か、
ランタイムライブラリのインターフェースを使用するか、
ランタイムライブラリと一切関係ないかのどれかである必要がある
（いずれの場合も独立モジュールのソースコードにGPLのソースは直接流用されてはいない）
>>759
ランタイムライブラリ例外が導入された経緯を考えると、
ランタイムライブラリがGPLなので、GCCで作った実行ファイルもGPLになるというのを回避するためだけのはず
libgcc_diet の案は一見よさそうに見えるが、
プロプライエタリからの利用を極端に嫌うFSFが
ランタイムライブラリ例外付きGPLのコードを、GPL迂回のための抜け道となるように作るとは思えない
例えば、libgcc_diet がランタイムライブラリを名乗れるのかがちょっと分からない
ランタイムライブラリは著作権者がファイルにランタイムライブラリ例外付きとしてライセンスする必要があるが、
著作権者ではない改変者が libgcc_diet をランタイムライブラリ例外付きGPLでリリースできるのかあたりがとても怪しい
>著作権者ではない改変者が libgcc_diet をランタイムライブラリ例外付きGPLでリリースできるのかあたりがとても怪しい
なるほど。この点は要確認ですね。
ちなみに使っているのは、アーキテクチャ依存のスタートアップコードとCPU固有命令をCからコールするためのインライン化コード。
ちょっと特殊なCPUなので代替コードはなさそう。
多分一から書ける人はほとんど居ないので詰んだ感がする。
スタートアップコードとCPU固有命令のCラッパー部分なら、
756 の libgcc_diet の方法で作った場合、
757 で指摘した『製品プログラムは独立モジュールとはみなされない』
という指摘は当てはまらないね
（libgcc_diet のコンパイルと製品プログラムのコンパイルを別にして、後からリンクするだけ）
ただし依然としてランタイムライブラリ例外付きGPLで libgcc_diet をリリースできるかは不透明
むしろ改変して、例外を適用出来るの？
「GPLライブラリを改変して、LGPLとして使いたい」
ってことになってしまうのかな？
GPLのソースコードと自分のソースコードを混ぜてコンパイルしたら、
757 で言ったとおり「独立モジュール」にならないので例外を適用できないよ
リンク段階なら適用できる
リリースする分には問題ない。もちろん純粋なGPLのコードからはダメだが。
「独立コードであればランタイムライブラリのGPL違反とはならない」という一つのみなので、
派生コードをランタイムライブラリ例外付きGPLでリリースすることは許可されていない
という可能性がありそうに見えます
（ただのGPLなら可）
（どのライセンスもそうだけど）ランタイムライブラリ例外付きGPLにするには著作権者全員の同意が必要で、
libgcc_diet の著作権者として libgcc の著作権者が含まれる訳だけど、
libgcc_diet をランタイムライブラリ例外にするには libgcc の著作権者の同意が必要なんじゃないかと
自分が見落としてるGPLの条項とか、GNUやFSFの見解とかあれば教えてください
LGPLなどリンク例外付きのものはGPLを選択してもよいというオプションが追加されているだけ。
>（どのライセンスもそうだけど）ランタイムライブラリ例外付きGPLにするには著作権者全員の同意が必要で、
それを同意するのがまさにライセンス条項なわけで。
・GPLライブラリ例外となっているライブラリ内のソース抜き出し利用
→ライブラリ例外適用不可
・GPLライブラリ例外のライブラリを変更し、ソース公開しつつそのライブラリにリンク
→ライブラリ例外適用可
ということだと解釈した。
今日さらに調査をした結果分かったこと。
最初のレスで「libgccみたいなライブラリのソースの一部」と書いたが、コレはどうもコンパイラに付属しているCランタイムライブラリのようだ。
ライブラリ全体はlibgccをベースに、アーキテクチャ向け変更を入れ込んでソースごと公開されている。
LICENSEにはランタイムライブラリ例外の旨も付いていた。
これを見ると上で議論のある「GPLランタイム例外が適用されているライブラリを改変し、同じライセンス形態のまま公開」が成立しているように見える。
有料で売ってるコンパイラなのでそこはメーカが問題無いと判断した上で販売していると認識したが、果たして。
というか、この理論が成立しないとlibgccをさまざまなCPU向けに作り変えてもライブラリ例外が適用できなくなってしまうが、そういうものなのだろうか。
7. Additional Terms.
より、適当抜粋
・追加条項はGPLv3のライセンス本体に含めるとあった
・ランタイムライブラリ例外のような許可の追加条項（Additional permissions）は引き継いでも破棄してもいい様子
・許可の追加条項の条項に記載することで、例えば改変された場合に追加条項の削除もできる
・非許可の追加条項は許されていない
GCCランタイムライブラリ例外の条項には改変時の追加条項の削除の条項は見当たらないので、
ランタイムライブラリ例外付きGPLは、ソースをランタイムライブラリ例外付きGPLとしてリリースできるっぽい
まじか……
ランタイムライブラリ例外付きGPLは、シェアードライブラリにする必要がないからLGPLより緩いのか
「今後はAGPLv3に統合してく、特例としてLGPLは作ったが出来ればGPLv3にしろ。
なお他のライセンスは一切使うな。」
って感じだけどなぁ
これってAppendixだから「適用する時の例」であって、
「絶対にこの書き方をしなければならない」って意味では無いですよね？
アプリAがLGPLのライブラリBを呼んだらアプリAはリバースエンジニアリングを禁止できないだろ
Wineの場合ライブラリBがWineになるんだからアプリAがリバースエンジニアリングを禁止している場合は
ライセンス違反になっちゃうんじゃないの？
自分が使うために利用することに制約は無い
Wineのソースコードを改変して配布しようとしているのか？
実質改変され続ける限りは無限？
（そして50年以上改変しないアプリなんて価値が無いし）
GPLはライセンスでプログラムを書いた人が自由に決めてるもので
著作権は法律で決まってて自由に決めれないものだろ
ライセンスは無期限じゃね
ライセンス違反で訴えられるなら使用時に同意した契約に違反したってことになるのかな
【レビュー】手のひらサイズの「PlayStation Classic」を一足先にチェックする-Impress Watch
ttps://www.watch.impress.co.jp/docs/review/review/1155161.html
システムまるっとGPLな訳ないはずだが、どう解釈をするとGPLを回避できるのだろうか
>>778
リバースエンジニアリングNGのWinアプリなら何でも良いよ
GPLを回避とか何言ってるかわけ分からん
著作権に関して無期限の保護期間を設けた法律って、どこかにあるのかな？
無ければ無限の保護期間は法律に反するので認められることは無いと思う。
最初の状態に対して全てに同じ保護期間が適用され続けるのか、改変の度に改変部分のみに個別の保護期間が適用されるのか、改変ごとに新たな保護期間が適用されるのかは知らない。
もしも改変ごとに新たな保護期間が適用されるとしても、それなら改変前のソースにはそれ用の保護期間が適用されているので、そちらの保護期間が先に切れる。
故に保護期間が終了したソースから同じコードを利用できれば、最新のソースの保護期間に縛られないと思う。
というわけで、どんなライセンスの形態であっても、保護期間は同じように考えて良いんじゃないかなと思う。
本を買ったならライセンスに同意したとみなすっていってるようなものだろ
＞最初の状態に対して全てに同じ保護期間が適用され続けるのか、改変の度に改変部分のみに個別の保護期間が適用されるのか、改変ごとに新たな保護期間が適用されるのかは知らない。
GPLでもこの辺りが明記されて無いんだよな
まー今はまだ適用対象が存在しないし、FSFが必要になって来たら明記するんだろうけども
CCやGFDLだとGPLと同様にプロプライエタリな規約と干渉するので困る
MITや2clauseBSD、欲張っても3clauseBSDやApache的なのを探しているんだが
日本でアレやったらGPL厨をはじめとする炎上厨が暴れ回って潰されるよな
ハック系フォーラムでライセンス順守しろってアホか
権利者が文句言うならともかく部外者が権利者のごとく叩いていたりするし
Annaの例だとカスタマーサービスに相談とありますが、毎回相談する必要があるのでしょうか？
Microsoft Speech Platform - Runtime (Version 11)
https://www.microsoft.com/en-us/download/details.aspx?id=27225
Microsoft Annaの商用について
https://answers.microsoft.com/ja-jp/windows/forum/all/microsoft/eaee2c22-a910-4f3b-84d7-28981f80063e
＞Microsoft Anna に限らず、商用利用について個別に許可や判断はしておりません。 [ガイドライン] の範囲内でご利用をお願いしております。
＞ガイドラインを確認しても判断が難しい場合は [カスタマー サービス] に相談された方がいいかもしれません。
ライセンス以前の問題。自分でコピペした内容わからないのか
誰かに必要ないって言ってもらっても意味ないからな
プログラムに組み込んだらGPLライセンスになるのでしょうか？
画像ソフトそのものを組み込まなければ、関係ないですよね？
>自由でないプログラムを開発するために、GNU EmacsのようなGPLの及ぶエディタを使っても良いでしょうか? GCCのようなGPLの及ぶツールを使って自由でないプログラムをコンパイルすることはできますか? (#CanIUseGPLToolsForNF)
> はい、なぜならばエディタやツールの著作権はあなたが書くコードには影響しないからです。法的には、あなたがどんなツールを使っても、あなたがご自分のコードに適用するライセンスに関しては何の制限も課されません。
https://www.gnu.org/licenses/gpl-faq.ja.html#CanIUseGPLToolsForNF
道具として使う分には無関係なのね、ありがとう
WebアプリはApacheかNGINXを利用します。カーネルやライブラリの改変は行いません。
売り物かどうかは関係ないがそのWebアプリが自作なら好きにすれば良い
ただし機器に組み込まれたカーネルやライブラリなどを含むその他の
ソフトウェアのライセンスによってGPLなどは配布するあなたに
面倒な義務が生じるのを忘れずに
ありがとうございます。
組み込み機器だとスタティックリンク扱いになって面倒なことになるかもと
懸念していましたが、そんなこと無いのですね。
実はGPLにしなければいけなかったことが発覚して
過去に遡ってライセンス検証の必要が出てきて
上へ下への騒ぎになってるな
どうすりゃいいんだ
https://github.com/chapagain/php-swiss-ephemeris/blob/master/LICENSE
これ自体はMIT Licenseのようなのですが
大本のswissephemerisのサイトを確認してみると
https://www.astro.com/swisseph/swephinfo_e.htm
ライセンスは、swissephemeris独自の有料プロフェッショナルライセンスかAGPLで使うか、どちらかのようです。
自分が使うのは最初のphp-swiss-ephemerisなので（大本の方は暦の範囲が広い）、
大本のライセンスはガン無視してMIT Licenseで使ってしまってよいものなのでしょうか？
そのgithubに上がっているコードだけで動くものであればMITと思っていいはず。
もちろんそれが嘘である可能性もゼロではないが。
レスありがとうございます！！
MITで出してる人の信憑性の方をじっくり確認して判断しようと思います
（ずいぶん前からやってる人だから大丈夫だとは思うけど、、）
本体はソースコードを伏せるとします。
>> 806
ありがとうございます
dllとして使う分には今までのLGPL通り特に公開しなくて良いのかな？
Copyright (c) ○○ のとこは自分の名前に変えるの？
配布側と利用者側で分けて説明しろよ下手くそがっ
ossのライセンス読んでると改変っていうのが出てくるんですが、例えばpythonでpipインストールしたライブラリをインポートして普通に.pyファイルにライブラリの機能を使うためのコードを書いただけでは改変にはならないのでしょうか…。
あと、例えばBSDのライブラリだけど、インストールに必要な依存ライブラリの中にGPLがある場合、直接BSDのライブラリしかインポートしてなくても、作ったプログラムはGPLになってしまうのでしょうか…
真面目にやるならソフトウェア著作権についての本を1冊読んでみるといい。
難しいところがある
FSFはGPLの影響を受けると主張してるが
関係ないだろと言ってる人もいる
裁判で決着つけるしかなさそうだが判例は
まだ無いんじゃないか
大変参考になります…。
本を買って勉強してみます…。
ちなみに社内利用だけに留めて外部に公開しなければ改変とかしても著作権表示とかソースコード公開とかしなくてもいいんですかね…。（社内でソースコード公開しないというのも変ですが）
暗黙のマナーなの？
俺に一言の連絡も無く買ってに再配布しやがった！許せんやつだ！みたいな作者をみて
ちょっと新鮮な驚きを感じてンだけど。
そんな要求する人がいれば「ライセンスにちゃんと書き足しとけ」っていうのがこのスレ的には正しいだろうけど、関わらない方が正解だな
そうだけど誰か分からないとうっかり関わってしまうかもしれない
というわけで誰がどこでそんなこと言ってるか教えて >>821
怒ってた人は見たことある
昔なんで何だったか忘れたけど
このライブラリと実行ファイルをインストーラに含めて配布する場合、実行ファイルのソース公開義務はないとの認識でよい？
ご存知でしたらお教えいただけませんでしょうか
https://ssd.jpl.nasa.gov/ftp/eph/planets/bsp/
↑ここのde***.bspです。
webで公開する月齢の暦を作るべくこれ（とMITライセンスのskyfieldというpythonライブラリ）を使いたいのですが
探しても明確なところがはっきりしません
使用する場合ソースを開示しなければならないタイプはセキュリティ的によろしくないので避けたいのですが、、
どうぞよろしくお願いいたします
レスを投稿する
ニュース
- 岸田総理「誰ひとり取り残さない社会」実現へ [煮卵★]
- 慶應義塾長が国立大の学費増額を提言「年55万→150万に」 文科省の会合で ★2 [少考さん★]
- “消えない広告” ×マークが押せません!? 「ダークパターン」世界で問題に | NHK [少考さん★]
- 【世帯年収2000万円以上の富裕層】「よく身に着ける洋服のブランド」…ダントツ1位は「ユニクロ」 [ネギうどん★]
- ラランド・サーヤ、“頑張ってない”Ｊ3J3選手からのDMにドン引き「飲んでますか？」に「初めましてだろ、まず」 [ネギうどん★]
- 【俳優】令和の沢尻エリカ事件か！番宣出演の若葉竜也に苦言殺到「態度悪すぎ」「朝から不快」 [ネギうどん★]
- NYM @ LAD ★4
- 【DAZN】フォーミュラ 【F1 F2 F3 P】lap1431
- AFC U23アジアカップ カタール2024★8
- AFC U23アジアカップ カタール2024★9
- NYM @ LAD ★2
- NYM @ LAD ★2
- 昼になったし旦那のチンポしばいてくる
- すまん炎刀・銃って刀なの？
- お昼のどんぐりチェックThread
- 🇺🇸NanG English Club🇬🇧
- 【悲報】大統領候補のロバート・ケネディさん、一族に見捨てられる
- 【速報】また落馬 [452056903]