Git 17

**デフォルトの名無しさん** · 2020/09/02(水) 12:18:30.39

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
-
VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2021/01/09(土) 11:02:31.02

GitのホスティングサービスってGitHubとかBacklogとかどこも1ファイル100MBまでとか全体で2GBまでとかに制限してるか、または推奨してる
Gitとしては巨大なリポジトリは分割して複数のリポジトリで管理するのを良しとしてる

**デフォルトの名無しさん** · 2021/01/09(土) 11:06:21.25

ただ、GoogleとかFacebookとかApache Foundationとか巨大なシングルリポジトリでソース管理してるとこも多くて、そういうとこじゃGitは使えない

**デフォルトの名無しさん** · 2021/01/09(土) 11:20:38.94

Androidはrepoという、沢山のgitレポジトリを集めたようなやつになってるよね。
でルートの.repoというディレクトリの下が結構でかくなる。何十GBとか。

**デフォルトの名無しさん** · 2021/01/09(土) 13:01:58.11

>>425
それgitの制限の話なの？
ホスティングサービスとしての容量制限じゃないの？

**デフォルトの名無しさん** · 2021/01/09(土) 13:31:10.98

それくらいがリポジトリ分割の目安ってこと
GitHubとかBitbucketとかたいていのプロジェクトで使うし

**デフォルトの名無しさん** · 2021/01/09(土) 13:34:00.22

Apacheはこんなことしてるし
https://svn.apache.org/viewvc/

**デフォルトの名無しさん** · 2021/01/09(土) 13:54:10.37

>>429
いや説明になってないけど
技術的にgitの限界というなら知りたいとこだが

**デフォルトの名無しさん** · 2021/01/09(土) 13:58:13.20

お前アホだろ

**デフォルトの名無しさん** · 2021/01/09(土) 14:39:15.02

説明できずに逆ギレとはテンプレみたいな奴だな

**デフォルトの名無しさん** · 2021/01/09(土) 17:15:51.87

バージョン管理システムはソースコードを管理するためのもので
差分見たり、ファイルの一部分を取り入れたりできなければ意味がない

100MBとかソースコード（テキスト形式）ではありえないようなサイズは
Git LFSを使ってファイルとして管理するのが推奨されてる

**デフォルトの名無しさん** · 2021/01/10(日) 02:02:28.87

>>417 >>422
このレベルの理解でドヤる奴が多いので混乱する

だいたい >>422 の理解でいいのだけど、
Packfile という仕組みで blob はスナップショットから別のblobとの差分へ変換される
この仕組みはコミット時に動くのではなくて、適当なタイミングで非同期的に行われる

ほぼ公式のこれ読んどけ
https://git-scm.com/book/ja/v2/Git%E3%81%AE%E5%86%85%E5%81%B4-Packfile

**デフォルトの名無しさん** · 2021/01/10(日) 02:10:27.13

>>422 のハードリンクというのは違うか、同じハッシュを参照するだけ

**デフォルトの名無しさん** · 2021/01/10(日) 11:31:03.72

>>435
コミット（というかインデックスファイル作るときなのでadd）したときにはスナップショットが作られる（記事内のlooseオブジェクト）けど、
gcで差分に変換される（=packfile）ってことか。勉強になるわ。
差分はどういうフォーマットなの？たぶんdiffではないよね？

あとハードリンクってのは概念的な類似(inode)から口走っちゃったけど、>>436のつもりです。ブランチと同じようにハッシュ向けるだけ。

**デフォルトの名無しさん** · 2021/01/10(日) 16:45:12.51

>>416だと保存しないとトリガーが発動しないから保存を忘れてしまえば効果が無いな

**デフォルトの名無しさん** · 2021/01/13(水) 21:53:18.46

一番最初のコミットしたファイルにパスワードが含まれるファイルがあるので
パスワードを空にしてそのコミットを修正する方法を教えてください
そのファイルは２回目以降にもぼちぼち編集してますが
パスワードの行は変更しておりません

**デフォルトの名無しさん** · 2021/01/13(水) 21:55:13.38

やっちまったな

**デフォルトの名無しさん** · 2021/01/14(木) 00:17:47.56

>>439
BFG Repo-Cleanerを--replace-textオプションで実行

**デフォルトの名無しさん** · 2021/01/16(土) 07:59:32.68

Git って今、SHA-1 と SHA-256 どっち使ってるの？

**デフォルトの名無しさん** · 2021/01/28(木) 07:56:37.51

git switch と git branch があったら、git checkout ってもう使い所ないですか？

**デフォルトの名無しさん** · 2021/01/29(金) 17:38:30.84

自分のHTMLやcssの履歴を残したいのでgitを使い始めたのですが、

コミット(B)した後に、1ファイルの1行だけ修正してからコミット(A)してしまって
前々回のコミット(B)に取り込んで、コミット(A)を消す事はできるのでしょうか？

コミット(B)をrebaseをしてintaractiveを選んだのですが、コミット(A)は消えず
変化もありませんでした、Visual Studio Codeを使用しています

**デフォルトの名無しさん** · 2021/01/29(金) 20:11:30.08

>>444
--> B --> A を
--> B'(B+A) にしたいってことですね。
interactiveを使おうとしているということはコマンドラインは使えますね。

git reset --soft @^ && git commit --amend です。
Aの先に既にコミットしている場合や、作業領域がダーティの場合は、このコマンドではダメなので言ってください。

慣れてないなら、コマンド実行前に git rev-parse @ で表示される文字列をメモっておいてください。

**デフォルトの名無しさん** · 2021/01/30(土) 01:49:46.04

gitとgithubが似たような仕組みって昨日知ったわ
ありがとう

**デフォルトの名無しさん** · 2021/01/30(土) 03:16:40.27

>>445
rebase用にファイルを用意してみたのですが、
rebaseテスト> git reset --soft @^ && git commit --amend
&&は前のコマンドが成功したら次のコマンドを実行するとは思いますが、

発生場所行:1 文字:21
+ git reset --soft @^ && git commit --amend
トークン '&&' は、このバージョンでは有効なステートメント区切りではありません。
&&は対応していないようです。

前のコマンドだけ入力してもエラーでした。
rebaseテスト> git reset --soft @^
fatal: ambiguous argument 'g': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

**デフォルトの名無しさん** · 2021/01/30(土) 10:49:06.16

最後のエラーが謎い…環境を教えて下さい。
・gitのバージョン
・コマンドラインを実行しているシェル(bashではない？)

git reset --soft HEAD^
これはどうなります？

**デフォルトの名無しさん** · 2021/01/30(土) 17:01:38.99

>>448
Visual Studio Codeで動くpower shellだと思います
> git --version
git version 2.24.1.windows.2
でした。

> git reset --soft HEAD^
変化がありました！

自分のレスを引用していますが
>>コミット(B)した後に、1ファイルの1行だけ修正してからコミット(A)してしまって
コミット(A)が消えて、直前に戻ったという感じです。
コミットのアンドゥと言ったところでしょうか。

そのままもう1度同じコマンドを打つと、内容を保持したままコミット(B)が消えたので
そこでコミット(B')みたいな形ではやりたいことはできました。
VSCodeのResrt to Previous Commit -> --soft を押しても同じ結果になりました

2回soft resetをしてからコミットするという感じで目的は達成できそうですが
最初の目的であるrebaseが動かなかったのは何か条件があるのかな・・

**デフォルトの名無しさん** · 2021/01/30(土) 20:10:04.60

目的は果たせたようでよかったです。
powershellは分からないですが、たぶん@と^は使わないほうがいいんだろうと思います。

**デフォルトの名無しさん** · 2021/01/31(日) 22:20:13.70

皆さんってGUIのGitツールって使います？
使っているとしたらオススメとかってありますか？

**デフォルトの名無しさん** · 2021/01/31(日) 22:32:34.38

GUI使うのはIDEのgit連携機能くらいですかね
Visual Studioとか

**デフォルトの名無しさん** · 2021/02/01(月) 00:11:14.51

SourceTree使ってるけど、バージョンアップで時々変なバグ入れてくるのでおすすめしない

**デフォルトの名無しさん** · 2021/02/01(月) 08:42:59.22

>>451
forkいいよ

**デフォルトの名無しさん** · 2021/02/01(月) 08:57:39.78

gitkでツリー確認して操作はコマンドラインだな。

**デフォルトの名無しさん** · 2021/02/01(月) 09:26:55.28

TortoiseGitばっかり使ってる
エクスプローラとの連携が便利だからね、、

**451** · 2021/02/01(月) 12:25:02.13

皆さん、情報提供ありがとうございます。
参考にさせていただきます。

**デフォルトの名無しさん** · 2021/02/01(月) 22:50:03.16

質問させて下さい。
開発の為に開発用branchを作り、開発が完了して、master branchにマージした後、その開発用branchは削除すべきなのでしょうか?
仮に削除するのだとすると、開発用branch内の履歴が消えてしまうような気がするのですが、なにか良い方法はありますか?

よろしくお願いいたします。

**デフォルトの名無しさん** · 2021/02/01(月) 23:09:13.83

>>458
fast forward マージをした？

git log --oneline --decorate --graph --branches --tags --remotes
↑
これを使ってみて

**デフォルトの名無しさん** · 2021/02/02(火) 12:15:14.88

>>451
git bashは一度起動させたらそのまま移動して使い回す
更新履歴見るときだけgitk呼んでる
操作自体はgit bash
過去の履歴が使えるので専用シェルは都合が良い
@win10

**デフォルトの名無しさん** · 2021/02/02(火) 15:24:31.09

git bash 便利だよね

**デフォルトの名無しさん** · 2021/02/02(火) 20:41:40.26

tig便利
元々Linux使ってたけどGit for Windowsに付いてくるようになって嬉しい

**デフォルトの名無しさん** · 2021/02/02(火) 22:19:04.75

mingwのコマンドいっぱい入っているからcygwinがわりにもなるな。

**デフォルトの名無しさん** · 2021/02/04(木) 13:02:56.36

http://to-developer.com/blog/?p=2103

**デフォルトの名無しさん** · 2021/02/04(木) 13:07:15.43

git reset --soft <commit>

<commit> を省いた時の動作って、
git reset --soft HEAD
と同じ意味になる？
マニュアル見ても書いてないように思うんだけど

つまり、
git reset --soft
ってのは、reflog で見れる足跡情報が増えるだけで、
それ以外にはなんにもしないコマンドって理解でいいです？

**デフォルトの名無しさん** · 2021/02/04(木) 13:41:04.22

man git-reset の最初の何行か読めばそう書いてあるだろ

**デフォルトの名無しさん** · 2021/02/04(木) 21:59:36.37

The <tree-ish>/<commit> defaults to HEAD in all forms.

**デフォルトの名無しさん** · 2021/02/08(月) 20:47:02.46

Windows で開発してるうんｋなんで、
git bash を VS Code で植え込んだ時におならが出るくらい感動した

**デフォルトの名無しさん** · 2021/02/09(火) 00:42:35.94

posh-gitも結構いいと思うんだ

**デフォルトの名無しさん** · 2021/02/09(火) 09:55:22.35

Git v2.30.1

**デフォルトの名無しさん** · 2021/02/09(火) 12:33:58.63

powershell はコマンドが長ったらしいだけでもう無理
エイリアス設定できたとしてももう無理
なんか powershell 開いただけで蕁麻疹出る

**デフォルトの名無しさん** · 2021/02/09(火) 12:47:44.22

powershell強力過ぎ、めっちゃ使いやすい

**デフォルトの名無しさん** · 2021/02/09(火) 17:18:41.08

>>472
ちょっとどこが良いのかその良さを bash とか zsh とかと比較して語ってみて

**デフォルトの名無しさん** · 2021/02/09(火) 17:39:51.20

powershellは
bashやzshより使いやすい

**デフォルトの名無しさん** · 2021/02/09(火) 17:51:57.49

小学生のふわっとした紹介すこ

**デフォルトの名無しさん** · 2021/02/09(火) 18:00:37.52

すまん、プレステとサターンどっちが強いってイキってる小学生から成長してないやつがいるとは思わなかった
アレルギーって自分で分かってるんだから好きなの使えばいいのにね

**デフォルトの名無しさん** · 2021/02/09(火) 22:46:56.83

利点を教えてと言っただけなのに、何でどちらが強いとかイキってるとかの話になるんだ…

**デフォルトの名無しさん** · 2021/02/10(水) 00:13:24.97

無理、無理、蕁麻疹出ると畳み掛けた奴が「教えてと言っただけ」と嘯くか
こういう輩が被害者ぶってる様を見る方がよっぽど無理だわ

**デフォルトの名無しさん** · 2021/02/10(水) 00:17:09.45

Powershellは使いやすいのが利点かな

**デフォルトの名無しさん** · 2021/02/10(水) 06:21:29.99

そういう喧嘩はどうでも良くて、
普通に powershell に利点があるなら知りたいだけなんだけど
自分は powershell 全然使い込んでないし

**デフォルトの名無しさん** · 2021/02/10(水) 06:34:31.18

>>480
PowerShellスレで聞けば?

PowerShell -Part 4
https://mevius.5ch.net/test/read.cgi/tech/1577862511/

**デフォルトの名無しさん** · 2021/02/10(水) 10:25:14.26

>>481
教えてくれてありがとう
スレお気に入れてチェックだけはしといてみるよ

**デフォルトの名無しさん** · 2021/02/13(土) 21:10:04.34

PowerShellは.NET Frameworkが使えることが最大の利点。
それ以外のメリットがないのが最大の欠点。

**デフォルトの名無しさん** · 2021/02/13(土) 22:49:51.40

>>483
そういうのをやりたければPowerShellスレでやれ
git関係ないだろ

**デフォルトの名無しさん** · 2021/02/13(土) 23:43:26.18

マイクロソフトの影響が強まっているから仕方ない部分もある

**デフォルトの名無しさん** · 2021/02/14(日) 17:26:13.02

質問です
あるプロジェクトをgit cloneしてローカルでbuildしたのですけど、
その中で必要なSDLのソースが404でダウンロード出来なくて、中断する状況。
メンテナに聞いてみたら"update the git hash."とのこと。
「HASH更新するのね、了解」って思ったんですが、それってどうするの？状態です。
gitのオプション見ても適当なコマンドは見たらないし、cloneしてbuildする位しか
git自体使ってない程度なのでさっぱりさんです。
どなたか教えてください。

**デフォルトの名無しさん** · 2021/02/14(日) 17:35:22.62

そのプロジェクトを明かせばいいんじゃないかな。

**デフォルトの名無しさん** · 2021/02/14(日) 17:41:51.89

ぬ、了解です。
github.com/EmuELEC/EmuELEC
で、Odroid Go Advance用にmake imageしたもので該当エラーになります。
build環境はamd64のdebian9です。

**デフォルトの名無しさん** · 2021/02/15(月) 00:31:17.39

package.mkのPKG_SHA256弄るっぽいです。
すんません、git関係無いかも。

**デフォルトの名無しさん** · 2021/02/15(月) 00:47:31.45

>>489
これで正解だったようです。
お騒がせしました

**デフォルトの名無しさん** · 2021/02/15(月) 11:45:26.57

>>11-12
ありがとう
このやり方でいきます

**デフォルトの名無しさん** · 2021/02/16(火) 00:58:10.08

質問をさせて頂きたいのですが、
GitはGPLらしいのですが、注意することはありますか？
例えばGitを用いて公開したコードは商用利用出来ないのですか？

**デフォルトの名無しさん** · 2021/02/16(火) 01:41:07.50

ライセンスに関わることは正確にやりたいこと言わないと答えられないぞ

なおGPLは商用利用を禁止していない

**デフォルトの名無しさん** · 2021/02/16(火) 07:01:06.32

>>492
gitのソースコードを修正する時になったらまた来てください
それまでは何も気にする必要はありません

**デフォルトの名無しさん** · 2021/02/16(火) 07:01:40.34

git「で」ソースコードを修正するときではなく
git「の」ソースコードを修正するときです

**デフォルトの名無しさん** · 2021/02/16(火) 11:12:05.59

GPLのソフトを組み込んだソフトもGPLになるんだよね
gitを組み込んでる商用IDEはソース公開義務を持つのかな？

**デフォルトの名無しさん** · 2021/02/16(火) 11:19:59.57

gitのソースコードを修正しない限り自由に組み込める
いくらコピーしてもOK。自分で作った部分のソースコード公開の義務はない

**492** · 2021/02/16(火) 17:50:38.97

答えてくれた方ありがとうございました

>>493
Git(やGitHub)でWeb上に公開したコードについてですが、
まあ大体は商用利用ではないと思うのですが、
後々になってお金を頂くようなものを作る可能性もありまして
でも大丈夫なんですね

>>494
つまり、Git自体のコードをどうこうするのではなく、
Gitのサービスを単に利用するだけであれば、
GPLはあまり気にしなくていいということなんですかね？

**デフォルトの名無しさん** · 2021/02/16(火) 18:50:42.51

>>498
GPLは、
a) gitユーザーに自由にgitを使ってもらうために、
b) git開発者・gitを組み込んだプログラム開発者を制限する
ライセンス。
a,bの違いを意識しないといけないからちょっと面倒。

**492** · 2021/02/16(火) 20:16:09.71

>>499
ありがとうございます
GPLって書かれてるとちょっとビビってしまいます

**デフォルトの名無しさん** · 2021/02/16(火) 22:18:03.16

GPLで作られたソフトの「ソースコード」を
どうにかしない限り、何の成約もない

**デフォルトの名無しさん** · 2021/02/16(火) 22:22:07.11

>>501
GPLのコードを静的リンクしたらGPLに感染するし、動的リンクもグレーじゃない？

**デフォルトの名無しさん** · 2021/02/16(火) 22:23:33.33

GPLの解説読むとGPLソフトを組み込んだソフトはソース改変してなくてもGPLライセンスになってしまうようにしか受け取れないけどな

◆QZaw55cn4c · 2021/02/16(火) 22:30:30.89

>>502
動的リンクは OK、スタティックリンクは OUT とか、もうほとんど意味不明ですよね
そもそもハードディスクも物理メモリも、メモリ空間も富豪的な現状で、動的リンクの存在価値はどこにあるのでしょうか？

**デフォルトの名無しさん** · 2021/02/16(火) 22:36:23.68

>>502
せやね。リンクしない限りOK

>>503
>ソース改変してなくてもGPLライセンスになってしまう
それはなにをしてもそうならない
ライセンス違反になるだけで、勝手にGPLライセンスになることはない

もし「○○○ライセンスになってしまう」というライセンスの強制上書きが許されるとしたら、
オレオレライセンスを組み込んだソフトは、どんなライセンスのものでも
オレオレライセンスになってしまう。というライセンスだって作れる。

GPLだろうがなんだろうが、そこにオレオレライセンスのソフトを混ぜると
GPL等のライセンス効果はなくなって、オレオレライセンスになってしまう
という強力なライセンスを作れると思うか？

>>504
そういうことだな。標準入出力でやり取りするブリッジプログラムを作れば
GPL感染すること無く利用することができる

**デフォルトの名無しさん** · 2021/02/16(火) 22:38:07.49

> GPLソフトを組み込んだソフトは

これは、同梱という意味じゃないことに注意
当たり前だが、DVDに一緒に配布してもGPLライセンスに感染しない
それはRedHatなどがやってること
LinuxディストリはGPLとそれ以外を一緒に配布している

**デフォルトの名無しさん** · 2021/02/16(火) 22:40:05.12

>>505
ライセンス違反にはなるけどしらを切れというスタンスか

**デフォルトの名無しさん** · 2021/02/16(火) 22:46:13.31

>>507
例えば、逆にGPLのソフトが間違って、互換性がないライセンスのコードを使ってしまったとしよう
もしかしたらそのコードは有料で利用可能にしているコードかもしれない

悪いのはそのGPLソフトだ。どうすべきだと思う？
そのコードを消して謝れば許す？
それとも損害賠償すべきだと思う？
それともGPLのライセンスを、別のライセンスに変更すべきか？

**デフォルトの名無しさん** · 2021/02/16(火) 22:47:24.67

>>507
なんか誤解してる。
ライセンス違反だとしても勝手にGPLになったりしないってこと。

**デフォルトの名無しさん** · 2021/02/16(火) 22:53:40.52

ライセンス違反したことは悪いが、
だからといってGPLに変更すれば許してやるよというのは
傲慢な脅しに過ぎない

ライセンス違反した場合に、GPLに変更するのは
ライセンス違反とい問題を解消するための、選択肢の一つでしかなく
両者の合意、または裁判によって個別に決めることでしかない

GPLに変更することで大損害を受けるのであれば、それは選択肢にならない
その場合は損害賠償を行うことで解決することになるだろう
合意が取れない場合に裁判を行うと、結局そうなる

GPL（事実上無料）にどれだけの損害を認められるか知らんがな
まあGPLを使ったことによる利益とかから算出されるんじゃね？
どうでもいい部分の利用程度なら、損害の程度も低いだろう

**デフォルトの名無しさん** · 2021/02/16(火) 23:07:03.03

いちいち裁判で争ってたら仕事にならんからやっぱりGPLは避けるのが無難だな

**デフォルトの名無しさん** · 2021/02/16(火) 23:11:40.98

ライセンス違反しなければいいだけだろ？
リンクしない限り何も影響なく
自由に利用できる

**デフォルトの名無しさん** · 2021/02/16(火) 23:12:44.65

せっかく開発者が自由に使ってくださいって提供してるんだから
便利に使ってやらなきゃ可哀想だろう
LinuxだってGPLだ。便利に使える。

**デフォルトの名無しさん** · 2021/02/16(火) 23:37:58.40

>>504
GNU公式見解では動的リンクもOUT
Linuxカーネルがとりあえず動的モジュールOKなのはリーナス含む大勢の著作権者が不問にしてるだけ
そして動的リンクの意義はLinuxカーネルみたいなものなら自明だろう

**デフォルトの名無しさん** · 2021/02/16(火) 23:41:52.36

GPL危ない危ない

◆QZaw55cn4c · 2021/02/16(火) 23:43:18.17

>>514
私には自明にはみえませんが‥‥
カーネルモジュールのことをいっているのですか？

**デフォルトの名無しさん** · 2021/02/16(火) 23:45:17.03

>>516
ドライバ全部入りのカーネル使いたいの？
それともドライバ組み込むたびにカーネルリンクしたい？

**デフォルトの名無しさん** · 2021/02/16(火) 23:48:10.64

どっちにしても配布物にGPLなソフトウェアを同梱しなけりゃセーフ

**デフォルトの名無しさん** · 2021/02/16(火) 23:50:06.35

余計なリスクを抱えるのは避けたいからBSD・MIT・Apacheライセンスのライブラリを使うわ

**デフォルトの名無しさん** · 2021/02/16(火) 23:55:13.86

ライブラリをGPLにしてしまうと、静的・動的リンクのためライセンス違反になるので
そうならないようにライブラリ用にLGPLというライセンスが存在する
GPLのライブラリのほとんどはよく読めばLGPLになってるはず

◆QZaw55cn4c · 2021/02/16(火) 23:55:15.05

>>517
MS-DOS では必要に応じてデバイスドライバを後から読み込むことができますが、MS-DOS のデバイスドライバを指して「動的リンク」とは当時は言っていませんでしたよね…
またアプリケーションに関しては、動的リンクはトラブルのもと（アプリではなく動的ライブラリが原因、とか、アプリの記述で手を抜くとアプリが暗黙に得体の知れないところの動的ライブラリをしれっとリンクする、とか）だった気がします
いわゆる Windows の DLL HELL ってやつですよ‥‥

◆QZaw55cn4c · 2021/02/16(火) 23:55:48.59

>>520
それは矛盾と妥協の産物としか‥‥

**デフォルトの名無しさん** · 2021/02/16(火) 23:58:03.77

例えばglibc（GNU C Library）はLGPLなのでリンクしても問題ない

https://en.wikipedia.org/wiki/GNU_C_Library
License LGPLv2.1

**デフォルトの名無しさん** · 2021/02/17(水) 00:00:40.90

>>522
LGPLはもともとLibrary GPLという名前だったことからもわかるように
ライブラリ用のGPLとして作られた

https://www.weblio.jp/content/GNU+LGPL
> LGPLとは、コピーレフトの考えを導入したGNUのライセンスのことである。
> 以前は「Library GPL」の名称で呼ばれていた。
>
> LGPLはGPL（GNU General Public License）をベースとしているが、
> LGPLの元で公開されたソースを利用したソフトウェアを開発しても、
> その独自開発部分のソースコードの公開を強制しないという特徴を持っている。