Earlier quoted context omitted.
Takedown reasons?
Takedown == getting issued a scary cease-and-desist warning letter by high-paid lawyers.
Red Hat cutting back RHEL source availability
121–130 of 339 posts
Re: Red Hat cutting back RHEL source availability
#122The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…
Re: Red Hat cutting back RHEL source availability
#123I wish this encourages companies to look for more alternatives to RHEL and its clones. There are certainly cases where the stability of RHEL makes sense. But too often teams use them when they need latest versions of software, resulting in pointless packaging work. The worst part about the packaging work is, the tools used to create RPM packages is showing its age. RPM macros, the language for describing packages, is…
> I wish this encourages companies to look for more alternatives to RHEL and its clones. The issue is that there is no alternative. I'm not aware of any distro with its base and all its packages working seamlessly with SELinux enabled. Setting up SELinux in any other distro is, in my experience, an uphill battle. You need to become an SELinux expert to do so. > The worst part about the packaging work is, the tools us…
RHEL has never used that, and Fedora has perennial discussions about killing it because the benefits rarely outweigh the costs anymore
Re: Red Hat cutting back RHEL source availability
#124Earlier quoted context omitted.
I'd argue that IBM's contributions in that timeframe were more about about validating it from a large business perspective than about technical contributions (that tended to focus on large system performance which wasn't actually that important for Linux taking off).
"Large" wasn't a very big standard at the time. Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical. Likewise, a lot of Linux's development inertia and cultural acceptance came from being a ch…
It was certainly needed over time but capabilities from things like RCU out of Sequent weren't that important in the 2000 timeframe. And a lot of IBM's contributions didn't come online until the v4 kernel.
None of this is to minimize IBM's contributions to Linux over time but I'd argue pretty strongly that IBM's endorsement of Linux for enterprises in January 2000 is what really moved the needle in the short run.
Here's what one of the people most directly involved told me a few years ago:
"By the late 90s, it was clear that Linux was becoming more and more important. And we formed a major task force to see to what extent IBM should embrace Linux and this happened in 1999. And the task force came back and said, we absolutely should embrace Linux, that it was going to be an incredibly important part of computing, that we should embrace Linux across all of IBM's offerings. And that IBM should become a major supporter of Linux.
"And I still remember very well in December of ‘99, I called Sam Palmisano, the head of IBM Systems Group. And I said, Sam, the task force recommends that we should embrace Linux. And Sam said, okay, Irving, we will do that. But you have to now come over and run an IBM Linux initiative. And I said to Sam, okay, we were pretty much done with our internet strategy. So I was no longer needed to run the Internet division And I said to Sam, when do you want to announce it? And Sam said, how about now? And I said Sam. It's the Christmas holidays. Maybe we should wait until the new year. And in the second week of January of 2000, we made a major announcement saying that IBM would embrace Linux across all of these offerings. And in fact, later that month in January of 2000, I gave a keynote at LinuxWorld, which was taking place in the Javits Center in New York City, about IBM’s Linux initiative.
"At some level, the rest is history."
Re: Red Hat cutting back RHEL source availability
#125Earlier quoted context omitted.
How does this not violate the GPL?
Why should it violate GPL? RHEL is obliged to provide source code for their GPL packages. You ask for source code, you'll get it. You distribute the source code, RH will terminate the contract with you because they don't want to see you as a customer anymore. They're free to do business with whoever they want, peeking people who will not distribute RH sources. Every party is in their right here. That's my understandi…
Re: Red Hat cutting back RHEL source availability
#126The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…
I have no love for Oracle but I would imagine one of the reasons Oracle embraced RedHat Enterprise Linux early on was the fact they could fork it if it was in their interest - this was tremendous value for RedHat for a time and helped its establishment as leading Linux for Enterprise.
Remember also what RedHat itself "stands on the shoulders of the giants" - there are a lot of packages which RedHat includes. Years ago when I worked at MySQL AB RedHat used to include MySQL packages, say they are covered by their "subscription" but have no revenue share with MySQL AB (as creators)
Note I'm not complaining I'm saying this is exactly how things upposed to work - MySQL got great value from being Open Source and allowing Linux distributions to include it (and make money on it) freely.
Re: Red Hat cutting back RHEL source availability
#127Here are the meeting notes from the RockyLinux people on this subject: https://etherpad.opendev.org/p/resf-rocky-linux-git-c.o-chan...
Re: Red Hat cutting back RHEL source availability
#128Earlier quoted context omitted.
Many startups can only dream of being as long and influential as IBM was .
Champion in patents per year in tech, Red-Hat, 2nd major Java implementation, one of the few vendors in quantum computing. That alone looks quite alright for a dying company.
And we see what IBM has done with leadership in those areas, as well as a long line of other areas where they somehow managed to turn themselves into a 3rd rate competitor despite being in the right place at the right time.
So, you have to ask yourself, for example how its possible that people are falling over themselves to build a RISCv ecosystem from the ground up, when openpower has been around for a decade now, and IBMs been looking for partners there since the original AIM alliance.
Re: Red Hat cutting back RHEL source availability
#129I've been using Red Hat and Fedora since the early RH4 days when the video driver only supported monochrome for my GPU. I'm now going to start switching to something not controlled by a corporation. Yes, I'm not happy about it but it's necessary. The days of being naive about Linux are over. I still consider Fedora one of the best distros out there (bleeding edge and polished as much as possible) and I prefer to use…
Re: Red Hat cutting back RHEL source availability
#130Earlier quoted context omitted.
My Assumption would be Section 1.4 over rides in the case of Source Code which is governed by GPL and implicitly allows redistribution, that is the entire purpose of CopyLeft So the prohibition on "redistribution" in this context would be on the compiled binaries. i.e you could not pay for a subscription and then mirror the yum repos publicly.
You're conflating your legal right to redistribute the software (they can't sue you) to your contractual right to redistribute (them terminating your support contract). They cannot sue you for redistributing the software, or claim damages because you did so. They can ABSOLUTELY tell you that your right to the subscription is terminated if you do so.
> Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your rights to software code under the terms of an open source license
So if the preceding section 1.2(F) and 1.2(G) do prohibit redistribution of SOURCE CODE, then it is in fact limiting your rights under to software code under the terms of an open source license.
1.2(F) and 1.2(G) would limit your right to distribute "software" generally defined a complied code, but not source code.