5 ms·

Red Hat is not the example you claim, everything in our products is open source, no piece of Open Stack or RHEL is proprietary software or open core. Even when

Red Hat is not the example you claim, everything in our products is open source, no piece of Open Stack or RHEL is proprietary software or open core. Even when we acquire proprietary software companies, we open source everything. This model works very well for us, but I appreciate that it can be hard to replicate.

zapita 8y ago
When it comes to open-source compliance, I would say RHEL follows the letter of the law but not its spirit. Although the source is available, and I’m sure it’s licensed in a way that meets OSI’s technical definition... it’s unreasonably hard to make useful modifications, contribute them back, or redistribute them. In fact Red Hat deploys specific obsfucation techniques to make it harder for competitors to redistribute RHEL, while technically respecting the OSI definition of “open-source” [1]. I understand the business motivation for playing these sorts of games... but it kind of deflates the notion that Red Hat’s model is anything special or worth emulating. Assuming Redis Labs will accept pull requests and generally follow the process of collaboration casually known as “open source” for their proprietary modules, even if it doesn’t meet the OSI’s technical definition of open source... Then as far as I’m concerned the Redis Labs model is more open, in practice, than RHEL’s. [1] https://lwn.net/Articles/430098/ https://lwn.net/Articles/430098/
- antoncohen 8y ago
  As the above poster said, Red Hat open sources everything. They buy proprietary software companies and open source the software. Red Hat officially sponsors the CentOS project. I'm very familiar[1] with the "obfuscation" you linked to, and I think you are missing context. Red Hat used to ship their Linux kernel source RPMs as vanilla Linux kernels plus a series of patches. They switched to releasing the source RPMs as a fully patched kernel tree. They did this because Oracle started providing commercial support for RHEL (not just Oracle Linux), which is how Red Hat makes money. This had no impact on open source redistributions of RHEL, like CentOS, because they just compile the kernel source without modifying it. AFAIK the kernel is the only package they do that with. [1] There was a kernel bug between RHEL 6 RC and GA, the RCs had individual patches, the GA kernel source RPM was pre-patched. Lack of patches made it harder to track down, but it was still possible by applying the patches to the RC kernel, then diffing the patched RC source against the GA source.
  - lmm 8y ago
    The GPL requires that source be distributed in the preferred form for making modifications. One of the FAQ examples is that if you have a perl script that generates C code you can't just distribute the C code, you have to distribute the perl script that generates it. IMO distributing only the pre-patched source of the kernel is the same kind of violation. The preferred form for making modifications is the original source plus separate patches, that's what the people who are working on that code use.
    - jkaplowitz 8y ago
      My intuition is the same as yours, but I also note that Oracle didn't sue Red Hat over it. This even though they are also among the Linux kernel copyright holders and are one of the most litigious companies known to the tech industry, PR consequences be damned. So maybe their lawyers disagree with us? Or maybe they're institutionally allergic to being a GPL enforcement plaintiff, even in their own strategic interest.
      - cowsandmilk 8y ago
        Not sure that suing is in their strategic interest. Do they publish the oracle Linux kernel prepatched? If so, they wouldn’t want to set a precedent that Red Hat is breaking the GPL.
        jkaplowitz 8y ago
        No idea if they do that, but good point if so.
    - bonzini 8y ago
      IANAL, but I work on the Red Hat kernel. I don't need the patches of the Red Hat kernel in order to make modifications to it. I need the patches from the upstream kernel in order to copy them to the Red Hat kernel, but I often use "--depth=1" clones of git trees, in other words clones without the "patches", and make modifications to them. Patches are useful, of course. They are useful to understand the evolution of the software, to support it, etc. But they are not necessary in order to make modifications to the software. Ten-fifteen years ago it was actually the norm that open source software had private source control repositories and only made periodic releases as tarballs.

zapita 8y ago

When it comes to open-source compliance, I would say RHEL follows the letter of the law but not its spirit. Although the source is available, and I’m sure it’s licensed in a way that meets OSI’s technical definition... it’s unreasonably hard to make useful modifications, contribute them back, or redistribute them. In fact Red Hat deploys specific obsfucation techniques to make it harder for competitors to redistribute RHEL, while technically respecting the OSI definition of “open-source” [1]. I understand the business motivation for playing these sorts of games... but it kind of deflates the notion that Red Hat’s model is anything special or worth emulating. Assuming Redis Labs will accept pull requests and generally follow the process of collaboration casually known as “open source” for their proprietary modules, even if it doesn’t meet the OSI’s technical definition of open source... Then as far as I’m concerned the Redis Labs model is more open, in practice, than RHEL’s. [1] https://lwn.net/Articles/430098/ https://lwn.net/Articles/430098/

antoncohen 8y ago
As the above poster said, Red Hat open sources everything. They buy proprietary software companies and open source the software. Red Hat officially sponsors the CentOS project. I'm very familiar[1] with the "obfuscation" you linked to, and I think you are missing context. Red Hat used to ship their Linux kernel source RPMs as vanilla Linux kernels plus a series of patches. They switched to releasing the source RPMs as a fully patched kernel tree. They did this because Oracle started providing commercial support for RHEL (not just Oracle Linux), which is how Red Hat makes money. This had no impact on open source redistributions of RHEL, like CentOS, because they just compile the kernel source without modifying it. AFAIK the kernel is the only package they do that with. [1] There was a kernel bug between RHEL 6 RC and GA, the RCs had individual patches, the GA kernel source RPM was pre-patched. Lack of patches made it harder to track down, but it was still possible by applying the patches to the RC kernel, then diffing the patched RC source against the GA source.
- lmm 8y ago
  The GPL requires that source be distributed in the preferred form for making modifications. One of the FAQ examples is that if you have a perl script that generates C code you can't just distribute the C code, you have to distribute the perl script that generates it. IMO distributing only the pre-patched source of the kernel is the same kind of violation. The preferred form for making modifications is the original source plus separate patches, that's what the people who are working on that code use.
  - jkaplowitz 8y ago
    My intuition is the same as yours, but I also note that Oracle didn't sue Red Hat over it. This even though they are also among the Linux kernel copyright holders and are one of the most litigious companies known to the tech industry, PR consequences be damned. So maybe their lawyers disagree with us? Or maybe they're institutionally allergic to being a GPL enforcement plaintiff, even in their own strategic interest.
    - cowsandmilk 8y ago
      Not sure that suing is in their strategic interest. Do they publish the oracle Linux kernel prepatched? If so, they wouldn’t want to set a precedent that Red Hat is breaking the GPL.
      - jkaplowitz 8y ago
        No idea if they do that, but good point if so.
  - bonzini 8y ago
    IANAL, but I work on the Red Hat kernel. I don't need the patches of the Red Hat kernel in order to make modifications to it. I need the patches from the upstream kernel in order to copy them to the Red Hat kernel, but I often use "--depth=1" clones of git trees, in other words clones without the "patches", and make modifications to them. Patches are useful, of course. They are useful to understand the evolution of the software, to support it, etc. But they are not necessary in order to make modifications to the software. Ten-fifteen years ago it was actually the norm that open source software had private source control repositories and only made periodic releases as tarballs.