5 ms·

That's not accurate. Everything Red Hat does is OSS. Their kernel patches are developed in the open, and available to anyone. The only thing they restrict is bi

That's not accurate. Everything Red Hat does is OSS. Their kernel patches are developed in the open, and available to anyone. The only thing they restrict is binary distribution.

yjftsjthsd-h 9y ago
To belabor the point, it is my understanding that CentOS is literally identical to RHEL minus a couple identifiers (/etc/issue and the like) and a license with a support contract. You can even convert it into RHEL by buying a license and installing a couple packages.
- makomk 9y ago
  CentOS can ship a system that's effectively identical to RHEL because Red Had publish their patched kernel source. What they don't distribute publicly and is only available to customers, under penalty of contract termination if they release it, is the patches that make up their kernel. So non-customers can't easily tell what they've changed, back out patches that break stuff, or cherry-pick patches for non-RHEL use. This is obviously nicer than the gresecuriy approach but there's no obvious reason why it's any more legal.
  - protomyth 9y ago
    If what you say is true, and I have no doubts you are correct, then how is Red Hat's kernel policy different from Grsecurity? They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination. I'm not asserting bad / good. I'm would like to know the difference.
    - mkl 9y ago
      If I understand it correctly, you can distribute Red Hat's source all you want, but it's up to you to figure out which bits of the kernel that is. That extra information is not part of the code.
      - sigjuice 9y ago
        What is the "extra information" in this context?
        mkl 9y ago
        The patch metadata: which lines have changed for what purpose.
        sigjuice 9y ago
        Sorry, I am still not sure what you mean. Could you point me at an example of 'patch metadata'? Thanks!
        sanxiyn 9y ago
        Here is an example of patch metadata, in this case for Debian: https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/series https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian... "Without patch metadata" would be a single file patch.
        sigjuice 9y ago
        Thanks! A CentOS 6 kernel source rpm that I unpacked recently had multiple patch files in it.
    - SwellJoe 9y ago
      "They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination." Red Hat does not contractually bind anyone to not distribute source. They just don't. They distribute the source themselves, without contract or cost. And, Red Hat employs several of the largest contributors to the mainline Linux kernel. Most of the time, if something is in the RHEL kernel, there are people working on pushing it into the mainline kernel either before or after it goes into the RHEL kernel. Red Hat has consistently and for decades worked with the Linux community to build a better kernel. I'm not trying to be a Red Hat fanatic or anything, but they've been trotted out multiple times in this thread as being "just like grsecurity", and it's just flabbergastingly wrong to compare the two.
      - protomyth 9y ago
        Ok, so what is Red Hat contractually binding me not to do? Am I misunderstanding what makomk is trying to say?
        mobilethrow 9y ago
        While Red Hats individual kernel patches are not available, they distribute the "squashed" sources under the terms of the GPL.
        protomyth 9y ago
        Thanks for the answer. Is the removal of the context of the changes generally considered acceptable? We have a Red Hat license, but frankly, I am more a BSD person and our use of Red Hat is a requirement for specific programs.
        SwellJoe 9y ago
        Yes, it is well-understood to be acceptable. In the past, most commercial Linux distributions were developed behind closed doors in private revision control and pushed out as "complete" source packages. We had these conversations back then (~20 years ago), and the community and the companies involved came to mostly agree about what is and isn't OK. That's opened up a lot in recent years, such that these days "open source" usually means, "we have a public git repository", but it does not have to. The GPL provides you some basic rights: you can request the source in a usable form, you can change it, you can redistribute it under the same terms. It does not require access to the process that produced the software. These days, Red Hat develops almost everything way out in the open. Contrary to all of the talk in this thread where folks (mostly just one guy, actually) keeps implying RH are violating the license or making it hard to get and distribute source, you can see discussions and the actual code being worked on months in advance of what will be in RHEL by following Fedora development. Fedora is developed entirely in public repositories and mailing lists, and it is where much of RHEL development takes place (RHEL trails Fedora by about 12 to 18 months, in terms of versions, and things that will be in RHEL next year are in Fedora today). Red Hat is an excellent OSS company who do damned near everything right, IMHO. Any complaints I might have about some of their practices (like I said elsewhere, I liked having a kernel SRPM that was the mainline kernel plus listed patches, and I miss it being that way) pale in comparison to the good they do for the OSS community. Just because they make a lot of money doesn't mean they're cheating the community out of anything.
  - SwellJoe 9y ago
    "but there's no obvious reason why it's any more legal." I don't follow this logic. Red Hat distributes the entire source of the kernels they ship, in a form that anyone can use, change, and redistribute. That satisfies the legal definition and the spirit of the GPL. They do not prohibit their paying customers from enjoying any of the rights guaranteed by the GPL. grsecurity allegedly prohibits people from doing that.
  - ensignavenger 9y ago
    What is the difference between "patched kernel source" and the "patches that make up their kernel"? It sounds like maybe you are saying that they just provide the source from release to release, not the Git (or similar) history with each commit they make. But since they release the source of each release, it sounds like that satisfies the GPL, and giving customers Git history or equivalent is an additional perk.

That's not accurate. Everything Red Hat does is OSS. Their kernel patches are developed in the open, and available to anyone. The only thing they restrict is binary distribution.

yjftsjthsd-h 9y ago

To belabor the point, it is my understanding that CentOS is literally identical to RHEL minus a couple identifiers (/etc/issue and the like) and a license with a support contract. You can even convert it into RHEL by buying a license and installing a couple packages.

makomk 9y ago
CentOS can ship a system that's effectively identical to RHEL because Red Had publish their patched kernel source. What they don't distribute publicly and is only available to customers, under penalty of contract termination if they release it, is the patches that make up their kernel. So non-customers can't easily tell what they've changed, back out patches that break stuff, or cherry-pick patches for non-RHEL use. This is obviously nicer than the gresecuriy approach but there's no obvious reason why it's any more legal.
- protomyth 9y ago
  If what you say is true, and I have no doubts you are correct, then how is Red Hat's kernel policy different from Grsecurity? They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination. I'm not asserting bad / good. I'm would like to know the difference.
  - mkl 9y ago
    If I understand it correctly, you can distribute Red Hat's source all you want, but it's up to you to figure out which bits of the kernel that is. That extra information is not part of the code.
    - sigjuice 9y ago
      What is the "extra information" in this context?
      - mkl 9y ago
        The patch metadata: which lines have changed for what purpose.
        sigjuice 9y ago
        Sorry, I am still not sure what you mean. Could you point me at an example of 'patch metadata'? Thanks!
        sanxiyn 9y ago
        Here is an example of patch metadata, in this case for Debian: https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/series https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian... "Without patch metadata" would be a single file patch.
        sigjuice 9y ago
        Thanks! A CentOS 6 kernel source rpm that I unpacked recently had multiple patch files in it.
  - SwellJoe 9y ago
    "They both alter the kernel and contractually bind the recipient not to distribute the source on pain of contract termination." Red Hat does not contractually bind anyone to not distribute source. They just don't. They distribute the source themselves, without contract or cost. And, Red Hat employs several of the largest contributors to the mainline Linux kernel. Most of the time, if something is in the RHEL kernel, there are people working on pushing it into the mainline kernel either before or after it goes into the RHEL kernel. Red Hat has consistently and for decades worked with the Linux community to build a better kernel. I'm not trying to be a Red Hat fanatic or anything, but they've been trotted out multiple times in this thread as being "just like grsecurity", and it's just flabbergastingly wrong to compare the two.
    - protomyth 9y ago
      Ok, so what is Red Hat contractually binding me not to do? Am I misunderstanding what makomk is trying to say?
      - mobilethrow 9y ago
        While Red Hats individual kernel patches are not available, they distribute the "squashed" sources under the terms of the GPL.
        protomyth 9y ago
        Thanks for the answer. Is the removal of the context of the changes generally considered acceptable? We have a Red Hat license, but frankly, I am more a BSD person and our use of Red Hat is a requirement for specific programs.
        SwellJoe 9y ago
        Yes, it is well-understood to be acceptable. In the past, most commercial Linux distributions were developed behind closed doors in private revision control and pushed out as "complete" source packages. We had these conversations back then (~20 years ago), and the community and the companies involved came to mostly agree about what is and isn't OK. That's opened up a lot in recent years, such that these days "open source" usually means, "we have a public git repository", but it does not have to. The GPL provides you some basic rights: you can request the source in a usable form, you can change it, you can redistribute it under the same terms. It does not require access to the process that produced the software. These days, Red Hat develops almost everything way out in the open. Contrary to all of the talk in this thread where folks (mostly just one guy, actually) keeps implying RH are violating the license or making it hard to get and distribute source, you can see discussions and the actual code being worked on months in advance of what will be in RHEL by following Fedora development. Fedora is developed entirely in public repositories and mailing lists, and it is where much of RHEL development takes place (RHEL trails Fedora by about 12 to 18 months, in terms of versions, and things that will be in RHEL next year are in Fedora today). Red Hat is an excellent OSS company who do damned near everything right, IMHO. Any complaints I might have about some of their practices (like I said elsewhere, I liked having a kernel SRPM that was the mainline kernel plus listed patches, and I miss it being that way) pale in comparison to the good they do for the OSS community. Just because they make a lot of money doesn't mean they're cheating the community out of anything.
- SwellJoe 9y ago
  "but there's no obvious reason why it's any more legal." I don't follow this logic. Red Hat distributes the entire source of the kernels they ship, in a form that anyone can use, change, and redistribute. That satisfies the legal definition and the spirit of the GPL. They do not prohibit their paying customers from enjoying any of the rights guaranteed by the GPL. grsecurity allegedly prohibits people from doing that.
- ensignavenger 9y ago
  What is the difference between "patched kernel source" and the "patches that make up their kernel"? It sounds like maybe you are saying that they just provide the source from release to release, not the Git (or similar) history with each commit they make. But since they release the source of each release, it sounds like that satisfies the GPL, and giving customers Git history or equivalent is an additional perk.