Hacker News Reader

Comment by indigodaddy | Hacker News Reader

“The Software Conservancy analysis summarized the conundrum as a pick-your-poison scenario: “In essence, Red Hat requires their customers to choose between (a) their software freedom and rights, and (b) remaining a Red Hat customer.” End-users are allowed to exercise their right to redistribute the code but if they do, they face the consequence of Red Hat canceling their subscription and being cut off from future versions of the software and Red Hat services.”

—- This is the key issue imo. How can you be in compliance with “..if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have.”

… if you make non-redistribution a requirement to even get access to begin with..?

I’m sure I’m misunderstanding though at some level

View on HN

The theory as I understand it is that you have all the expected rights to the binaries you've been provided. But the only thing compelling redhat to provide you future binaries is your contract with them - and exercising those rights jeopardises that contract.

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.

So to receive a product where the GPL dictates you have full right to redistribute that product, you must first enter into a (sub?)contract that says you cannot redistribute it…

If that’s not one hell of an ingenious loophole, I don’t know what is..

You are legally allowed to redistribute it but RedHat is not compelled to continue to have you as a customer.

I even had some person argue (kinda, pretty bad faith arguments) that this is not even against the spirit of the gpl.

No, you can redistribute it. RedHat can't stop you.

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.

Right that ends up being the same thing. They are making your redistribution a violation of that (sub?)contract

That's not the same thing. You can do everything the GPL allows you to do, you are not restricted from that. But RHEL gets to choose who their customers are and they won't choose you. You can't force them to take you on as a customer, no license can

You’re misunderstanding me. RHEL is saying that to be/maintain as a customer, you have to not redistribute the received product, correct?

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.

It's not a loophole. You have every right you were guaranteed by the license. RHEL also has the right to choose their customers. They choose customers who don't exercise the rights granted by the license. This is all fine and compatible.

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

this might be the best way to say it I've seen

The free speech analogy doesn’t hold water for me. Free speech is extremely broad. “You can redistribute” is extremely specific and precise, and RH is effectively stripping this very precise and extremely specific right from you if you want to be/maintain as a “customer”

It doesn't need to hold water for you as long as you get my point. It sounds like you don't though and for some reason "broad" and "precise" are factoring into this for you - you should justify that.

Given the First Amendment is a limitation on the government, let's apply this logic to a government service. If the government was to say, stop you from accessing the public library due to the speech you engage in, but did not criminally punishing you for the speech, would this be a First Amendment violation? I think so.

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.

> 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.

A better analogy may be how we have a right to take apart our electronic devices, but as soon as we do we void the warranty provided by sellers and/or manufacturers. INAL, I don't know if all warranties fall under contract law, but it makes sense to me that at least extended warranties do, and I imagine those are also voided in such cases.

Only if you are ignorant of the Magnuson-Moss warranty act. It is not legal in the United States to blanket void a warranty when a device is taken apart or disassembled. Manufacturers can decline a warranty claim when work down by the owner or another servicer causes an issue, but the warranty remains intact for anything unrelated to the work done. So, as an example, if you repair the plug on your electronic device, and then the keyboard has a fault and a key fails due to a bad keyswitch, they still have to replace the keyboard, as your plug repair has no relation to the failed keyswitch component.

https://www.ftc.gov/business-guidance/resources/businesspers...

https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty...

The key here is future versions of RHEL. They can't and won't cut you off from the version of RHEL that they already distributed to you, but if you use it to build a clone distro, then they don't have to sell you a future version of RHEL.

It isn't quite correct that RedHat is saying that, IIRC from the LWN discussions, the clause is about giving someone who doesn't have a subscription the benefits they would have if they had a subscription. So it would be fine to redistribute in some cases but not others. Probably fine to redistribute every update to entities who already have a subscription, or to redistribute one package to a contractor working on fixing a bug for you etc.

It sound like RedHat has migrated back to a “purchase” model then. You pay once, get your software and do with it as you please and then they ask you kindly to not pay again, kind of like the old days. Sounds good to me.

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.

This is the answer. What RedHat is doing is legal but sneaky. So we can be legal but sneaky too.

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...

Not a lawyer, but I suspect doing this with prior intent would be fraud (since you enter the contract with intent to violate it) and probably get you sued.

I don't think so, the whole point here is that the contract does not - and cannot - bar you from sharing the code. The GPL bars RedHat from imposing additional restrictions on your rights to the code.

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!

The contract can not remove your legal rights, but can ask you to give them up in exchange for something. For example, I can not prohibit you from driving you own car, but if I rent it from you, and later you just take it back while my rental term still in effect, it would be a breach of contract, despite the car being legally yours. And if I learn that you never intended to let me drive the car, but still pretended to rent if out, then if would be fraud. Same, my employer can not prevent me from exercising my right you free speech, but some of it - eg disclosing trade secrets - may get me fired and sued for damages. Because by signing employment contract I agreed to give up exercise of some rights - like use if my time and some of my speech - in exchange for the salary. If I didn't I could speak of any secrets and they couldn't do a thing.

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.

Even easier - let's say I send you a bunch of GPL code and tell you I'll pay you 1000 dollars if you never send it to anybody else. Easy money right? If you still send the code, I can't sue you for license violation - GPL allows you to do that. But you certainly took $1000 and didn't do what I paid you for. It's not just legal but sneaky, it's a violation of our contract, despite the fact the license is not violated - two different things.

If I understood what you mean, it doesn't sound like it works in any practical sense, because Red Hat wouldn't take you as a customer for release n + 1.

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.

Well, the law profession wouldn't exist if it weren't for loopholes.

I wouldn't call this a loophole.

Seen this before with some company selling some form of “security” branch of the kernel or similar.

You're thinking of grsecurity, the out of tree Kernel patches from the folks who invented almost every major security mitigation in modern computers, who gave away their patches for free for decades, and then recently moved to only give away their stable patches to customers under the same contractual obligation.

Their customers are still entirely free to redistribute under the GPL but Grsecurity is not forced to take people who do so as customers.

> from the folks who invented almost every major security mitigation in modern computers

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 himself called the code quality "questionable" at best

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.

> You have no idea what you're talking about.

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.

> 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.

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.

>If true security is something you can only achieve by having "hidden" patches, I don't buy your snakeoil

"Hiding" the patches is a monetization strategy. It isn't for security.

> You're thinking of grsecurity, the out of tree Kernel patches from the folks who invented almost every major security mitigation in modern computers

Thanks for saying this. They even beat OpenBSD to some stuff. They never seem to get credit.

One of their customers did leak the grsec code to someone on Twitter at one point, haven't seen any leaks since then though.

Some lawyers figured out how to legally steal IP from all the creators who have contributed to Linux.

My biggest question is how they are going to police this. Will each download contain hidden flags to mark it as your account? How will they be able to discern what account it came from? Sounds like a nightmare to control and may end up costing them more in the long run.

I doubt they will do anything to police it, and I don't think they need to. They're not trying to murder/kill rebuilds, they're trying to make it so that a CTO can't say "I can just use <copy> and it's free RHEL." You could still say "I can just use <copy> and it's close to a free RHEL, but it's not exactly a free RHEL". In the world of support, contracts, and certification, that detail is really important.

This makes me think of the React patent license issue from some years ago.

React was licensed under BSD, but had a patent license that many interpreted as saying if Facebook sued you (among other things) you'd lose rights to any Facebook patents, including any that applied to React. Having rights under the BSD license didn't override that.

Different situation, but same vibe.

Not really the same. Red Hat isn't revoking your ability to use the software you've already received. There's no "kill switch" for RHEL nor does the contract remove your legal rights to use the software you have received.

However, you do lose the right to access Red Hat-provided services, including the software update repositories, should you break the contract.

My understanding of the React license is that it remove[d] your legal rights to use React in any form, immediately, if you sue Facebook for Patent infringement. That's significantly harsher.

Worth noting for the audience - this is a historical issue.

Facebook removed the restriction and changed to a straight forward MIT license in 2017.

You have the right to distribute the code. You don't have a right to be a RHEL customer.

Just like there is a federal law that says you have a write to receive over the air communications, yet there are some states that stop you from driving while receiving those radio communications (i.e., they make radar detectors illegal in the car). The prohibition isn't on using a radar detector (you can walk around all you want with one), but against driving with one.

GPL only provides you rights and freedoms as a customer/end user. Companies are free to choose who their customers/end users are.

IBM can make sure Alma and Rocky aren't their customers, don't legitimately receive the binaries, and therefore under GPL don't have the rights to the source code.

What I think was really happening was that customers who subscribed were:

- subscription for some core systems

- centos elsewhere

I suspect redhat is just going to continue to bleed customers.

Reply on news.ycombinator.com