Is anyone on the mailing list aware of anyone who supports older versions of CentOS kernels? Particularly, I am interested in getting security patches added to kernel-3.10.0-514.10.2.el7.src.rpm. Please let me know.
Regards, Ken Y
On Jun 13, 2018, at 4:47 PM, Ken Young kenyis@rogers.com wrote:
Is anyone on the mailing list aware of anyone who supports older versions of CentOS kernels? Particularly, I am interested in getting security patches added to kernel-3.10.0-514.10.2.el7.src.rpm. Please let me know.
As far as CentOS support, only the latest kernel is supported. This really means that *you* are now the only support for old kernels.
You might be able to pay Red Hat for an Extended Update Support release of RHEL7 that has a similar version (kernel-3.10.0-514.51.1.el7) but support ends November 30 2018.
https://access.redhat.com/articles/rhel-eus
— Jonathan Billings billings@negate.org
On 06/13/2018 02:33 PM, Jonathan Billings wrote:
On Jun 13, 2018, at 4:47 PM, Ken Young kenyis@rogers.com wrote:
Is anyone on the mailing list aware of anyone who supports older versions of CentOS kernels? Particularly, I am interested in getting security patches added to kernel-3.10.0-514.10.2.el7.src.rpm. Please let me know.
As far as CentOS support, only the latest kernel is supported. This really means that *you* are now the only support for old kernels.
You might be able to pay Red Hat for an Extended Update Support release of RHEL7 that has a similar version (kernel-3.10.0-514.51.1.el7) but support ends November 30 2018.
The src.rpm for that kernel is probably available somewhere.
On Wed, Jun 13, 2018 at 11:16:55PM -0700, Alice Wonder wrote:
You might be able to pay Red Hat for an Extended Update Support release of RHEL7 that has a similar version (kernel-3.10.0-514.51.1.el7) but support ends November 30 2018.
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
EUS 7.3.x support is going away soon enough that the real answer is to plan to migrate to supported RHEL/CentOS kernels.
On Thu, Jun 14, 2018 at 3:07 PM, Jonathan Billings billings@negate.org wrote:
On Wed, Jun 13, 2018 at 11:16:55PM -0700, Alice Wonder wrote:
You might be able to pay Red Hat for an Extended Update Support release of RHEL7 that has a similar version (kernel-3.10.0-514.51.1.el7) but support ends November 30 2018.
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
EUS 7.3.x support is going away soon enough that the real answer is to plan to migrate to supported RHEL/CentOS kernels.
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi gianluca.cecchi@gmail.com wrote: ...
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
...
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else.
/Peter
On 06/14/18 10:00, Peter Kjellström wrote:
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi gianluca.cecchi@gmail.com wrote: ...
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
...
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else.
GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow.
On the other hand, I will not raise any issue about source of these patched ancient kernels, as my sympathy as human is on RedHat's side: I know how much work that is, and programmers who do that have to feed their families. (This is why BSD style license which is different from GPL in this respect does make sense either).
Valeri
/Peter _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, 14 Jun 2018 10:12:30 -0500 Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 06/14/18 10:00, Peter Kjellström wrote:
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi gianluca.cecchi@gmail.com wrote: ...
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
...
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else.
GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow.
No you are minunderstanding the GPL.
You are only required to provide source to those who got the binary artifact(s). They then have the full GPL rights to further modify etc. In many cases the binaries are distributed to everyone and then so is the source. In other cases (such as RHEL) only source is provided to everyone (but that is fine too).
Consider a simpler case: I make a copy of a existing GPL pkg. I modify this and use it myself. I do not have to share my changes with anyone.
My copy is still GPL though..
..so if I give a copy of the source to a friend it no longer matters (to him/her) wether I made that source public before or not. They can modify or not and make available publicly or not.
Had I sent my friend a binary copy he/she would have had the right to require me to also hand over the source.
None of us would have any obligations to a 3rd party.
/Peter
On 14 June 2018 at 12:16, Peter Kjellström cap@nsc.liu.se wrote:
On Thu, 14 Jun 2018 10:12:30 -0500 Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 06/14/18 10:00, Peter Kjellström wrote:
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi gianluca.cecchi@gmail.com wrote: ...
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
...
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else.
GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow.
No you are minunderstanding the GPL.
You are only required to provide source to those who got the binary artifact(s). They then have the full GPL rights to further modify etc. In many cases the binaries are distributed to everyone and then so is the source. In other cases (such as RHEL) only source is provided to everyone (but that is fine too).
Consider a simpler case: I make a copy of a existing GPL pkg. I modify this and use it myself. I do not have to share my changes with anyone.
My copy is still GPL though..
..so if I give a copy of the source to a friend it no longer matters (to him/her) wether I made that source public before or not. They can modify or not and make available publicly or not.
Had I sent my friend a binary copy he/she would have had the right to require me to also hand over the source.
None of us would have any obligations to a 3rd party.
To back up Peter on this, here are some relevant links from the FSF.
https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you. ==== https://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA Does the GPL allow me to develop a modified version under a nondisclosure agreement? (#DevelopChangesUnderNDA) Yes. For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA.
You can also release your changes to the client under the GPL, but agree not to release them to anyone else unless the client says ok. In this case, too, no GPL-covered code is being distributed under an NDA, or under any additional restrictions.
The GPL would give the client the right to redistribute your version. In this scenario, the client will probably choose not to exercise that right, but does have the right.
====
There are other questions in the FAQ which also cover this.
/Peter _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 06/14/18 11:23, Stephen John Smoogen wrote:
On 14 June 2018 at 12:16, Peter Kjellström cap@nsc.liu.se wrote:
On Thu, 14 Jun 2018 10:12:30 -0500 Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 06/14/18 10:00, Peter Kjellström wrote:
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi gianluca.cecchi@gmail.com wrote: ...
> The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
...
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else.
GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow.
No you are minunderstanding the GPL.
You are only required to provide source to those who got the binary artifact(s). They then have the full GPL rights to further modify etc. In many cases the binaries are distributed to everyone and then so is the source. In other cases (such as RHEL) only source is provided to everyone (but that is fine too).
Consider a simpler case: I make a copy of a existing GPL pkg. I modify this and use it myself. I do not have to share my changes with anyone.
My copy is still GPL though..
..so if I give a copy of the source to a friend it no longer matters (to him/her) wether I made that source public before or not. They can modify or not and make available publicly or not.
Had I sent my friend a binary copy he/she would have had the right to require me to also hand over the source.
None of us would have any obligations to a 3rd party.
To back up Peter on this, here are some relevant links from the FSF.
https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
Yep, found it myself. I stand corrected.
Valeri
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you. ==== https://www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA Does the GPL allow me to develop a modified version under a nondisclosure agreement? (#DevelopChangesUnderNDA) Yes. For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA.
You can also release your changes to the client under the GPL, but agree not to release them to anyone else unless the client says ok. In this case, too, no GPL-covered code is being distributed under an NDA, or under any additional restrictions.
The GPL would give the client the right to redistribute your version. In this scenario, the client will probably choose not to exercise that right, but does have the right.
====
There are other questions in the FAQ which also cover this.
/Peter _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 06/14/18 11:16, Peter Kjellström wrote:
On Thu, 14 Jun 2018 10:12:30 -0500 Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 06/14/18 10:00, Peter Kjellström wrote:
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi gianluca.cecchi@gmail.com wrote: ...
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
...
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else.
GPL requires to provide source if everything derived from the original source to everybody, not only to customers. And RedHat was ever compliant with GPL. Kudos to RedHat! So, if there exist patched kernels of out of support life, they should be downloadable somewhere somehow.
No you are minunderstanding the GPL.
It turns out you are absolutely right. You only have provide modified source to users to whom you distribute derived work. Found it here:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic
I stand corrected. Thanks!
Valeri
You are only required to provide source to those who got the binary artifact(s). They then have the full GPL rights to further modify etc. In many cases the binaries are distributed to everyone and then so is the source. In other cases (such as RHEL) only source is provided to everyone (but that is fine too).
Consider a simpler case: I make a copy of a existing GPL pkg. I modify this and use it myself. I do not have to share my changes with anyone.
My copy is still GPL though..
..so if I give a copy of the source to a friend it no longer matters (to him/her) wether I made that source public before or not. They can modify or not and make available publicly or not.
Had I sent my friend a binary copy he/she would have had the right to require me to also hand over the source.
None of us would have any obligations to a 3rd party.
/Peter
On 2018-06-14, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
It turns out you are absolutely right. You only have provide modified source to users to whom you distribute derived work. Found it here:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic
Not totally relevant to this thread, but relevant to repeating: since the code is still GPLv2, if RedHat shares its code with me, I can still redistribute freely, even though RedHat is not necessarily redistributing to the general public. RedHat can not prevent me from redistribution even though I obtained the code under a paid support contract. (At that point RH has zero obligation to anybody who downloads from me, of course.)
--keith
On 06/15/2018 01:33 PM, Keith Keller wrote:
On 2018-06-14, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
It turns out you are absolutely right. You only have provide modified source to users to whom you distribute derived work. Found it here:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic
Not totally relevant to this thread, but relevant to repeating: since the code is still GPLv2, if RedHat shares its code with me, I can still redistribute freely, even though RedHat is not necessarily redistributing to the general public. RedHat can not prevent me from redistribution even though I obtained the code under a paid support contract. (At that point RH has zero obligation to anybody who downloads from me, of course.)
--keith
Yes they can // well, yes and no.
You agreed to an EULA that says you will not distribute things that you get from that paid subscription. You can do it, and be in violation of the terms of your subscription.
Then, you could lose said subscription privileges. You could modify it for your own use though.
The CentOS team would never distribute anything in that manner. Or allow it to be distributed on CentOS.org machines/services.
On 2018-06-16, Johnny Hughes via CentOS centos@centos.org wrote:
You agreed to an EULA that says you will not distribute things that you get from that paid subscription. You can do it, and be in violation of the terms of your subscription.
Is this enforceable with the GPLv2? IIRC someone who distributes GPLv2 source code is not permitted to restrict other people's ability to redistribute. It could be an interesting legal test (that I don't think CentOS should test :) )
--keith
On 15 June 2018 at 21:07, Keith Keller via CentOS centos@centos.org wrote:
On 2018-06-16, Johnny Hughes via CentOS centos@centos.org wrote:
You agreed to an EULA that says you will not distribute things that you get from that paid subscription. You can do it, and be in violation of the terms of your subscription.
Is this enforceable with the GPLv2? IIRC someone who distributes GPLv2 source code is not permitted to restrict other people's ability to redistribute. It could be an interesting legal test (that I don't think CentOS should test :) )
This gets asked every couple of months for the last 18+ years. This has been the model that pretty much every enterprise company from Cygnus before Red Hat merged with it, to SuSE and Red Hat enforce their contracts. RMS has probably answered it so many times that he has an autoresponder on it.. so I would say ask him and see what he says.
The general way it has been said is that this does not equal what the law sees as an additional restriction on the code. The restriction is on the support contract you have with Red Ha which is not promised in the GPL as being a right you have. The only licenses which do provide that amount and more requirements are code which are covered under the AGPL.
--keith
-- kkeller@wombat.san-francisco.ca.us
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 06/16/2018 02:15 PM, Stephen John Smoogen via CentOS wrote:
On 15 June 2018 at 21:07, Keith Keller via CentOS centos@centos.org wrote:
On 2018-06-16, Johnny Hughes via CentOS centos@centos.org wrote:
You agreed to an EULA that says you will not distribute things that you get from that paid subscription. You can do it, and be in violation of the terms of your subscription.
Is this enforceable with the GPLv2? IIRC someone who distributes GPLv2 source code is not permitted to restrict other people's ability to redistribute. It could be an interesting legal test (that I don't think CentOS should test :) )
This gets asked every couple of months for the last 18+ years. This has been the model that pretty much every enterprise company from Cygnus before Red Hat merged with it, to SuSE and Red Hat enforce their contracts. RMS has probably answered it so many times that he has an autoresponder on it.. so I would say ask him and see what he says.
The general way it has been said is that this does not equal what the law sees as an additional restriction on the code. The restriction is on the support contract you have with Red Ha which is not promised in the GPL as being a right you have. The only licenses which do provide that amount and more requirements are code which are covered under the AGPL.
Right .. they aren't saying you can not distribute .. they are saying if you chose to distribute to non customers .. you can't subscribe. That is not the same thing.
Given that they only do that for extended support items only, and that they open source everything they buy from other companies, and allow for 10 years of building for CentOS. It seems to be they are very much more open than most,
I don't see why its a problem to pay them for the very extended support .. since that is very much harder to maintain than even the normal backporting and releasng of security updates that they do (and provide to all, NOT just customers).
That is, of course, a personal opinion.
On 06/14/2018 08:00 AM, Peter Kjellström wrote:
On Thu, 14 Jun 2018 16:26:27 +0200 Gianluca Cecchi gianluca.cecchi@gmail.com wrote: ...
The src.rpm for that kernel is probably available somewhere.
I'm fairly certain you cannot download the SRPM for EUS kernels. You might if you're a Red Hat customer paying for that product (but don't take my word for it).
...
I agree for the format of release (SRPM), but in any case Red Hat should provide the sources for the changes, as the kernel is GPL-2.0 Then one can manually try to merge them in a patched kernel in some way... Gianluca
Redhat of course complies with the GPL and provide source to the customers that get access to the binary packages. They are not required to provide the sources to anyone else.
/Peter
Yes that's why I said somewhere. At least in the past there have been people who made their own mirrors of RHEL exclusive source packages (which the GPL allows).
I don't know who does now, but someone somewhere probably does.
-
Alice Wonder -
Gianluca Cecchi -
Johnny Hughes -
Jonathan Billings -
Keith Keller -
Ken Young -
Peter Kjellström -
Stephen John Smoogen -
Valeri Galtsev