LTS版Linuxカーネル、サポート期間が2年に戻ることに 30
ストーリー by headless
負担 部門より
負担 部門より
LTS 版 Linux カーネルのサポート期間が現在の 6 年間から 2 年間に戻されるそうだ
(ZDNET の記事、
Ars Technica の記事、
Linuxiac の記事、
Linux Journal の記事)。
スペイン・ビルバオで開催された Open Source Summit Europe で Linux Weekly News の Jonathan Corbet 氏が明らかにしたもので、メインテナーに大きな負担をかけて誰も使わなくなった古いバージョンを更新する意味がないなどと説明したという。LTS 版カーネルのサポート期間は 2017 年に 2 年間から現在の 6 年間に延長されていた。現在サポートされている LTS 版カーネル 4.14 / 5.4 / 5.10 / 5.15 / 6.1 のサポート期間に変更はないが、今後の LTS 版カーネルのサポート期間は 2 年間となる。
スペイン・ビルバオで開催された Open Source Summit Europe で Linux Weekly News の Jonathan Corbet 氏が明らかにしたもので、メインテナーに大きな負担をかけて誰も使わなくなった古いバージョンを更新する意味がないなどと説明したという。LTS 版カーネルのサポート期間は 2017 年に 2 年間から現在の 6 年間に延長されていた。現在サポートされている LTS 版カーネル 4.14 / 5.4 / 5.10 / 5.15 / 6.1 のサポート期間に変更はないが、今後の LTS 版カーネルのサポート期間は 2 年間となる。
LTSとGPLの相性が悪い？ (スコア:0)
GPLだとソースコードの公開が必須になるので、LTSのように「必要な人は高いお金を出しても欲しいけど、いらない人にはいらない」というサービスは成立しづらいのかもね。
必要な人が高いお金を出して保守してもらっていても、その成果が公開されて他の人も自由に利用できるとなると、高いお金を出す理由を説明しづらい。
Re:LTSとGPLの相性が悪い？ (スコア:1)
それだと提供しているソフトウェアのほとんどがオープンソースであるRed HatやUbuntuの成立が説明できませんよ。
メインライン(kernel.orgで公開されている)カーネルのLTSが必要とされていないのは、RHELにしろその他の商用ディストリビューションにしろ、その多くは自前でパッチセットを管理していて、メインラインカーネルのLTSを使用していないからです。
たとえばRHEL8は4.18.0, RHEL9は5.14.0がそれぞれ出発点でいずれもLTSではありません。
一方のUbuntuは20.04LTSは5.4.0, 22.04LTSは5.15.0と、バージョンこそLTSですが、後続バージョン(5.4.X, 5.15.X)は使用せず自前でパッチを取り込んでいくスタイルです。
Re: (スコア:0)
カスタマイズ案件なら、自分らに特化した仕様のコードをフィードバックしたくないってのは普通にあると思うけど
LTSみたいな内容の保守サービスに払うお金なんて、いざという時の責任回避、体制は整えてあります的な言い訳のための出費でしょ
「成果が他の人に公開されるのはちょっと……」なんて言うところあるのかなぁ、しかもOSS製品選んどいて
ところでGPLってソフトの利用者に対してコードの提供をするのは義務なわけですが、
ソフトの作者が誰にソフトウェアの使用許諾を与えるか、を制限する条項ってあるんでしたっけ
上の例で言うと、保守を受けている人がGPLに基づいてライセンスされたソフトウェアを第三者に配布するのは当然自由ですが、
コードを書いた保守業者が「誰に」自製のソフトウェアを（もちろんGPLで）ライセンスするかは、自分自身で決められて然るべきな気がします
であれば、保守を受ける側は「あなたに書いてもらったコードを自分たち以外にライセンスしないように、その対価はコレコレ」という契約を結ぶ事自体は可能なような気がします
どうなんでしょう
Re: (スコア:0)
GPLを読んでみたほうが話が早いと思うが。
著作者は複製をコントロールできます。
GPLで配布するのは著作者です。
著作者が(GPLという文書で)再配布先に制限をつけないと言っています。
二次著作物の場合は一次著作者の意向を無視できませんので、
GPLの二次著作物を配布するならGPLで配布するしかない。
GPLv3だったら最後のコメントみたいなことはできます。
配布をうけるのが自分たちだけだったらね。
Re: (スコア:0)
著作権は財産の一種で、売買し、または、契約で引き渡すことができるものです。
したがって、保守業者が保守を引き受ける際に、コードの著作権を依頼者に渡す旨契約していれば、著作権は依頼者に帰属しますから、
GPLであっても、書いた保守業者が誰にライセンスするかを自分で決めることはできません。この場合、それを決めるのは依頼者です。
> ソフトの作者が誰にソフトウェアの使用許諾を与えるか
作者と書くと分かりにくくなってしまいます。上記のように、作者＝著作権者とは限りません。
著作権者は、もちろん、自分で決める権利がありますから、著作権者は制限を受
Re: (スコア:0)
したがって、保守業者が保守を引き受ける際に、コードの著作権を依頼者に渡す旨契約していれば、著作権は依頼者に帰属しますから、
GPLであっても、書いた保守業者が誰にライセンスするかを自分で決めることはできません。この場合、それを決めるのは依頼者です。
GPLv2の保守(二次著作物を作らせる)の場合はグレーだよね。
著作権は依頼者に帰属するけど、その著作権者がGPLv2で再配布OKって言ってるんだから、著作権の帰属で攻めるのは的外れだと思う。
内輪向けに保守させる場合は、FSFがGPL FAQで「配布にあたらない」ということにして対処しているとかいう話だが…
(GPLv2もGPLv3相当の解釈でよいと言っているらしい)
Re:LTSとGPLの相性が悪い？ (スコア:1)
ですから「GPLv2で再配布OK」はあくまで、そのソフトウェアのコピーをもらった人（ライセンスを受けた人）に対して、です。
求められれば誰にでもライセンスしなければならない、などという話ではありません。
もちろん、例えば従業員が、許可なく、ソフトウェアのバイナリを、例えばUSBメモリにコピーするなどして不正に持ち出したとして、
「自分はバイナリを持っているからソースコードをよこせ」などとソースコードの配布を求めてきたとしても、
ソースコードを渡す義務はありませんし、
その従業員が不正に入手したコピーを他人にまたコピーするのは、著作権の侵害になります。
ライセンスされていないからです。
同様に、自社内で従業員に対して業務でバイナリを使用させる場合でも、個々の従業員にソースコードを見せる義務はありません。
そして、誰にライセンスするかは、著作権者、この場合は依頼者が決められます。
ですから、依頼者は、自社で使用するために保守業者に依頼した場合は、「自分らに特化した仕様のコードをフィードバックし」なくて構わないのです。
その保守業者に依頼してできた改造版を他人に配布して儲けようと考えると、また面倒になってきます。
Re: (スコア:0)
だから配布にあたるかどうかが問題なんですよ。ライセンスしないで配布することはできません。
GPLを誰に再配布(ライセンス)するか決めるのは、著作権を持っていなくてもできます。
だから著作権者であるかどうかは的外れと言っているんです。
Re: (スコア:0)
著作権者はGPLv2で再配布OKって言ってるが、保守業者にはそれを配布・提供(ライセンシング)してない
ライセンスのないものを勝手に使えばそれはGPLであろうとライセンス違反
著作権の帰属問題以外の何物でもない
Re: (スコア:0)
自分の知りたいことは、
> 著作権者は、もちろん、自分で決める権利がありますから、著作権者は制限を受けません。
> （略）
> 改造版の使用権を、改造版の著作権者が誰に与えるかは、GPLに制限されたソフトウェアでも、制限されません。
ここだった（著作権の譲渡の話は、直接は関係ないように思う。というか譲渡されてる状況なら、著作権者は利用者である自分自身に対してGPLに基づく利用許諾を与える必要すら無いのでは）
GPLのFAQにも以下のようにあった。上記のコメでも触れられているように、元コメの「保守してもらっていても、その成果が公開されて他の人も自由に利用できる」は、ちょっと誤解があると思う。
GPLは、わたしが機密保持契約(NDA)のもとで改変されたバージョンを開発することを許可していますか?
はい。たとえば、あなたはあるプログラムに改変を加え、そのあなたの変更をクライアントがOKを出すまでリリースしないことに同意するという契約を
Re: (スコア:0)
https://licenses.opensource.jp/GPL-2.0/gpl/gpl.ja.html [opensource.jp]
Re: (スコア:0)
補足しておくと、最後の段落の組み込み機器というのは市販製品を想定しています。他の誰も持っていないような特注の機器であれば当然他の誰もソフトウェアの複製を持っていないのでライセンスの必要はありません。
Re: (スコア:0)
もちろん市販製品であっても、カスタムのファームウェアアップデートを特定の顧客にしか提供せず、その顧客も自分も他者に複製を提供しないような事例であれば、その顧客以外にライセンスする必要はありません。
Re: (スコア:0)
ソースコードは広く公開しなければならないわけではありません
顧客から、GPLのソフトウェアの改造・保守を依頼されて、それら作業を行い、その顧客にバイナリを提供したとしても、
「その顧客に対して、ソースコードを公開すれば」足ります。そして、そのソースコードを入手した顧客は、別に誰にソースコードを公開する義務もありません。
元コメはGPLの制限を誤解しています。
開発者に有償で開発してもらった改造版を、他人に無償で配布しなければならない義務は、バイナリ・ソースのどちらもありません。
また、このように開発者に有償で開発してもらったソフトウェアの著
Re: (スコア:0)
ここって本当ですか?
依頼者が一からソフトウェア開発するにあたって開発者に「GPLでないライセンス」で
開発依頼したのならともかく、既にあるGPLなソフトウェアに対して依頼者が開発者に
修正を依頼した場合、依頼者は開発者にその修正版の配布を制限出来るんでしょうか?
Re: (スコア:0)
著作権を依頼者に帰属させている以上、開発者は修正版を配布する権利を持っていないのでは
GPLなソフトウェアだって、著作権者が利用者に対して許諾してるから、その利用者は別の第三者に配布できるのであって、
好き勝手に配布していいわけではない
Re: (スコア:0)
>> また、このように開発者に有償で開発してもらったソフトウェアの著作権は、依頼者(金を出した人)に帰属すると考えられることから、その開発者に対して、許可なく他人にその改造版>を配布しないように制限することができます。
> ここって本当ですか?
本当だと思います。
GPLは著作物を配布する場合の取り決めです。著作物を第三者に販売・配布しなければGPLは関係ありません。
> 修正を依頼した場合、依頼者は開発者にその修正版の配布を制限出来るんでしょうか?
ですからこれはGPLは関係ありません。依頼者と開発者の契約次第です。
Re: (スコア:0)
公式のGPL FAQから引用してるコメを見る限り、若干メチャクチャだけど、実務を考慮して
「NDA下で会社間取引する場合や社外秘として使う限りは、『配布していないのでセーフ』と『見做す』」
「ただし、機器に組み込んで売った場合は、ソフトの実体が『配布』されるのでGPLが発動するとする」
という風に見える
Re: (スコア:0)
誰が誰に対してという情報が省略されてる上に、配布と提供の区別が付いてないので理解できてないのでは？
配布(広く行き渡るように配ること≒公開)と提供は別
基本的にGPLでは開発者に公開しなくてはならない義務は設けてない、公開はその権利があればしても良いだけ
開発者はNDAで縛られれば公開する権利がなくなる
依頼者がそのソース・ソフトを機器に組み込んで売った場合も、不特定多数に対して公開する義務はない
依頼者が売る製品を買った人に提供する義務はあるだけ
> 「NDA下で会社間取引する場合や社外秘として使う限りは、『配布していないのでセーフ』と『見做す』」
Re: (スコア:0)
そうは言ってもね、転売禁止条項をつけて、実際に不要になった機器を本当に回収して破棄証明しないと
3代前のおじいさんが買ったんです現物はもうないけどソースください
という人が現れたときに対抗できない
Re: (スコア:0)
> そうは言ってもね、転売禁止条項をつけて、
転売禁止条項の追加はGPLのライセンス違反だから、それしたら売ったやつが著作権侵害になる
対抗になっておらず、むしろ自分の首を締めてるだけ
そして現物がないならソースを提供する義務がない
提供されたことが証明されてないからだ
# 後はこれは個人の見解だから言明はしないが、3代も前のものなら基本的にソース提供する必要はないはずだぞ
# 契約上、無期限と永久は全く別だからな。日本の法律なら契約不適合責任で考えれば10年が良いところじゃないかな
Re:LTSとGPLの相性が悪い？ (スコア:1)
前のストーリー見たけど (スコア:0)
当初から意味があるのか効果のほどには疑問符がついていたようだ
Re: (スコア:0)
コメントしようとしたのは次のストーリー [hardware.srad.jp]ではないですか？
Re: (スコア:0)
違った、次の次のストーリー [science.srad.jp]か。
つっこむつもりでボケてしまった…
これはしゃーない (スコア:0)
最新版が6.5.5の最中に、5.15.133とか5.10.197とか5.4.257なんかをメンテする人の気持ちを考えたらそりゃね
しょうじき6.1.55あたりでもよーやるわと思うもの
Re:これはしゃーない (スコア:1)
RedHat「わかったらちゃんとRHELに金払え」
Re: (スコア:0)
オープンスーゼとけウブントゥならただですしー。
結局ディストリ作ってる人は自分たちでカーネルをメンテしちゃうんですよね。そっちのほうが大変だが自由が効くし。んで非LTSを自力メンテナンスしてるから自分たちが見つけた非LTSベースでとっくにサポートが切れてるカーネルの修正をLTSに反映する気も起きない。
実際レッドハットとかカノニカルとかスーゼはLTSカーネルを使ってないでしょ。デビアンも多分そうだな。
概ね毎年LTSカーネルが出るがディストリを作るグループが欲しい機能がLTSカーネルより新しい安定版カーネルに入ってたりするのでそっちを自力で長期メンテナンスする方を選んでしまいがち。LTSカーネルと自分たちのリリーススケジュールも合わないしその手のディストリは大体10年サポートだから後半は自力サポートになるし。
個人のプライベート組はなんでかわかんないけど集まんないみたい。
Re: (スコア:0)
1つだけケチつけるけど、Ubuntuは5年目以降は基本的に有料だぞ（個人利用5台以下など無償利用できる場合もあるものの）。
Re: (スコア:0)
これこそAIさんに古バージョン へ適用するためのコードモーフィングしてもらえばいいんじゃないかな
バージョン毎の影響範囲とかどんどん学習繰り返させてさ