Which technically works because the GPL only concerns the software you've received - it does not concern nor compel the software you've yet you receive.
If that’s not one hell of an ingenious loophole, I don’t know what is..
But you might only be able to do this once. Because what RedHat can do is cancel your contract, and stop you from using RedHat services, and you won't have access to future versions or updates.
So, again, to become a customer and receive a product where the license of that product dictates you CAN redistribute, you MUST first enter into another contract that says if you redistribute the product, it may violate your standing as a customer and jeopardize your chances of receiving any future product.
Of course it’s a loophole, and I really hope it gets to court somehow because I doubt it would stand up. Just my opinion. I don’t know anything about GPL law, but it doesn’t seem logical that this is something that would be able to stand.
I hate to use an anecdote but consider that you have some rights that you may exercise - say, free speech. You then come to me and enter into a contract. I am within my rights to not renew that contract if I dislike the things you say under your pre-existing right to free speech, and in fact, I can put it into our contract that I will cancel it if you exercise that right in a way I don't like.
This is normal and commonplace.
edit: Please do not engage with the anecdote. It's meant to be helpful, not be literally equivalent in a legal sense. This is why I hate anecdotesssss
Another, perhaps more realistic example, is a government employer choosing to fire an employee who was caught using their free speech to advocate for a political challenger to the office they work under. Firing a person is not criminally punishing them, and in general an employer can fire an employee for what they say, but in this specific case, because the First Amendment limits the government, they couldn't do this. If you were working for private political organization, they likely could do this as the First Amendment wouldn't apply to the private organization.
Depends on the state, many have added political beliefs to their anti-discrimination laws, and such an act would be prohibited, but at the federal level this would be fine.
https://www.ftc.gov/business-guidance/resources/businesspers...
https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty...
As long as one subscriber is willing to leave their contract per release, downstream derivatives should have no end of supply for each release. This may not help with patches, but many of those would come from third parties to begin with.
Start a consortium that creates a new LLC or non-profit organization with no ties back to the consortium. That new organization buys a license, and publishes the code until RedHat cuts them off. Start a new one and repeat.
Of course it could become a cat and mouse game, where RedHat starts denying customers it deems suspicious. They start demanding more info of their customers. But all that could be bad for business...
But RedHat is under no obligation to make future sales to you and can drop you as a customer for any reason, including you exercising your legal right to share the code.
So they want to be legal but sneaky? Let the legal but sneaky games begin!
Contract is a meeting of minds honestly intending to perform. If you did not have the good faith intention to perform the contract, it's not just sneaky, it's fraudulent.
1. You purchase release N
2. You distribute the source code to release N.
3. Red Hat terminates you.
4. You needed Red Hat N. You're doing enterprisey things or using software that runs on Red Hat.
5. Red Hat releases N + 1.
6. You try to get release N + 1 from Red Hat, because you're in the ecosystem, doing enterprisey things, using software that runs on Red Hat
7. Red Hat remembers what you did on release N and doesn't offer you release N + 1.
It doesn't quite seem like the purchase model. This barely seems to get you anything over what a Rocky or Alma or whatever scrape to put together with Red Hat damming distribution, so you might as well resort to them right at release N instead of paying Red Hat for it.
Their customers are still entirely free to redistribute under the GPL but Grsecurity is not forced to take people who do so as customers.
I wouldn't praise them that much. Linus himself called the code quality "questionable" at best and for people who care so much about "improving the security landscape" by walling off the very contributions that can help keep others safe online.... I don't really care what they put on their CV I wouldn't want them on my security team.
If true security is something you can only achieve by having "hidden" patches, I don't buy your snakeoil and will gladly take security advice with the people who actually share that information rather than lock it behind a paywall.
Edit: This is not to say if your contributing a lot of time and effort into securing the Linux kernel that you shouldn't get paid, you should. I just think you need to be realistic. If the patches work, cool. Now work on making it capable to be merged into the mainline tree. If your not actively contributing to the product as a whole then the only thing your doing is building a business solely to keep those patches working. That does not inspire confidence with me. God forbid the company go under and all that work never makes it into the main tree. Now you've wasted yours and everyone else's time. You have furthered Cyber Security by exactly 0 points. Good job.
Linus hates them. There's a very long history there.
> for people who care so much about "improving the security landscape" by walling off the very contributions that can help keep others safe online.... I don't really care what they put on their CV I wouldn't want them on my security team.
You have no idea what you're talking about.
edit:
> You have furthered Cyber Security by exactly 0 points.
Notably, despite never upstreaming their work, they are still responsible for inventing the most important mitigations in your computer, including your hardware (ASLR, SMAP, SMEP, to name a few). So no matter what they have absolutely furthered security by much more than 0.
I said it in force, you took it too literally. I don't care who they are or what their "achievements" are. If you care about improving security to the point that you will create patches on top of a open source program and then turn around and lock them behind an EULA that prevents people from sharing that code with the rest of the world you're not helping the security landscape at all. All your doing is making security something that only a select few will actually be able to pay for which is where I take the most issue.
If the GRSecurity team was actually invested in improving the security of the kernel they would be working to submit those patches to mainline. I have not seen any effort to refute this.
Edit: So again, because they work behind closed doors I'm just supposed to take their security contributions at face value without any way to audit what they have done? Again I ask again. How does that improve security? Security through obscurity is not security.
Whatever I do not wish to argue this.
I don't know why you take issue with a company selling a product, especially when they gave it away for decades beforehand.
> If the GRSecurity team was actually invested in improving the security of the kernel they would be working to submit those patches to mainline. I have not seen any effort to refute this.
Upstream has always been extremely hostile to security and security patches. The only reason things have changed at all is because now Google pays Linus's paycheck and a few companies like them control the vast majority of contributions, so if they want security patches to be applied they can make it happen.
That is not how things worked until the last decade or so.
Also, why should they? No one was paying them to do that, or anything for a long time. Why are you dictating that they should spend their time that way? How do you know that would be the best for security? We've all benefited from their approach so clearly what they were doing wasn't so terrible - your browser is randomizing its address space right this very second because of their work.
> Edit: So again, because they work behind closed doors I'm just supposed to take their security contributions at face value without any way to audit what they have done? Again I ask again. How does that improve security? Security through obscurity is not security.
Their patches were open to everyone for decades. You have no idea what you're talking about.
"Hiding" the patches is a monetization strategy. It isn't for security.
Thanks for saying this. They even beat OpenBSD to some stuff. They never seem to get credit.