RedHat found a way to get around the GPLv2 license intention with contract law
Red Hat’s new subscription-only distribution of RHEL skirts GPL compliance and violates the spirit of open source.
You're viewing a single thread.
They are not getting around anything - they just won't keep you as a customer if you redistribute the patches. But no one is stopping anyone from exercising their rights under the GPL.
There is a lot of talk about their community reputation and really for me as a FLOSS developer this comes from the work of their engineers in the upstream. We don't care about the downstreams because the people that do pay someone to care about it for them. If anything the only real practical difference for us is it makes it harder to include RHEL/RHEL-like distros in our CI loops. However they are big enough to worry about that themselves.
They are violating section 6 of the GPLv2 by adding further restrictions.
But ignoring that, I haven’t heard anyone discussing what could happen once this anti-GPL angle goes beyond Red Hat. What’s going to happen once internet connected IoT devices or say a company like Tesla pull the same technique. If Tesla kills your account for any reason, you lose all your paid for services and your car becomes a brick.
What further restrictions are they making? You are free to do whatever you want with the source code provided for the binaries they distributed to you.
No, I am no “free” to do whatever I want. I want to distribute that source is strictly allowed under the GPL, but then RH penalizes me for exercising that right by terminating that account. That’s a restriction. How is being penalized for doing what I’m allowed to do not a restriction?
How about yet another angle for you. For example, I download and distribute the source RPM for gcc for the version running on my box. RH terminates my account. Now I want to download and distribute the source RPM for the kernel running on my box. How do I do that with a terminated account?
Section 6 of the GPLv2 states the following:
Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
The way I interpret this, nothing about your ability to "copy, distribute or modify" the code would be violated. "The Program" wouldn't refer to the live, changing copy; only the copy that you received at that point in time which you are still able to redistribute. I point specifically to the wording of "Each time you redistribute the Program" - since newer versions of the Program are no longer being distributed to you, the terms no longer apply for these newer copies. Neither this section nor any other section forbids you from denying access to binaries.
No, I am no “free” to do whatever I want. I want to distribute that source is strictly allowed under the GPL, but then RH penalizes me for exercising that right by terminating that account. That’s a restriction. How is being penalized for doing what I’m allowed to do not a restriction?
They only said "free to do whatever you want with the source code provided for the binaries they distributed to you", which is true? You wouldn't be receiving any further binaries that would require releasing code to you, and you'd still be able to copy/distribute/modify the code that you got up until that point.
How about yet another angle for you. For example, I download and distribute the source RPM for gcc for the version running on my box. RH terminates my account. Now I want to download and distribute the source RPM for the kernel running on my box. How do I do that with a terminated account?
As mentioned above, you'd be perfectly able to redistribute the code associated with the binaries already provided to you. Once your account is terminated, you'd no longer have access to the binaries that you could request the code for.
Please correct me if I'm wrong; IANAL.
They only said “free to do whatever you want with the source code provided for the binaries they distributed to you”, which is true? You wouldn’t be receiving any further binaries that would require releasing code to you, and you’d still be able to copy/distribute/modify the code that you got up until that point.
I would still assert that having contractual penalties for a behavior granted elsewhere is no longer free, hence a "restriction". But this is where I'd love to hear a lawyer's position. "Common sense" and "legal sense" can often be in conflict.
I'm aware I'd be restricted from future binary updates. But my point goes to what the legal definition of what a "restriction" is in this context. The language in this sentence to me is plain, "You may not impose any further restrictions on the recipients’ exercise of the rights granted herein." RH is attempting to limit my behavior by imposing contractual penalties for exercising rights granted under the GPL. Those penalties being imposed are not just restricting access to future binary updates, but forfeiting all current granted privileges and monies already paid under contract, and the termination of that contract. I would consider that a "restriction", but IANAL either.
I would say RH's behavior goes to this GPL FAQ. I would assert that RH's new contract is certainly a "more restrictive basis", but I'd love to hear from an IP/contract lawyer that is familiar with the GPL on this issue.
I would think what RH wants to do with this change would be perfectly fine if they just chose just to let the existing contract with the customer run out without renewal, and not make any changes of terms until expiration, but terminating their contract and the terms granted therein is a restriction, and I suspect will run them afoul in court.
Again, I'd love to hear from a IP/contract lawyer. I've interacted with numerous ones over the years on our RHEL support contract renewals and on a patent litigation case as my company's lead engineer (sucking up two years of my career), and my impression is just that.
As mentioned above, you’d be perfectly able to redistribute the code associated with the binaries already provided to you. Once your account is terminated, you’d no longer have access to the binaries that you could request the code for.
I'm not sure you said here what you mean to? I certainly still have access to the binaries I already downloaded. After all, they're still running on my box! And also under the RHEL contract (old or new), I'm still able to run those binaries indefinitely. But that means I'm also still entitled to the source from RH for those installed binaries since they were originally distributed and installed by RH under the terms of the GPL.
Of course to "work around this", RH could put all sorts of hoops in the way of requesting them via some alternative, manual method and then charging a fee for them. A long time ago, I used to work for a company that charged $250 for a copy of our GPL'd code for each product, and after 6 weeks to fulfill the request, would U.S. mail it to the customer on a QIC tape. I'm curious to see how RH fulfills this aspect of the GPL post-termination.
BTW, this change in the RHEL contract is nothing new. A different company had worked for used to have an 8-figure RHEL support contract, and I was their point of contact with our TAM. Thirteen years ago, we were considering a ELS (Extended Lifecycle Support) contract for RHEL which had a version of this new language in it way back then, so I ended up discussing this issue at length with our TAM. He said we'd only get answers to my questions of how the language wasn't a direct violation of section 6 from RH Legal if and only if we'd sign the contract.
But out of all this, my biggest concern of all this by far is the can of worms RH is opening. What's going to happen when other even less scrupulous companies attempt to run with this possible GPL loophole RH is trying to bust open?
I’m aware I’d be restricted from future binary updates. But my point goes to what the legal definition of what a “restriction” is in this context. The language in this sentence to me is plain, “You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” RH is attempting to limit my behavior by imposing contractual penalties for exercising rights granted under the GPL. Those penalties being imposed are not just restricting access to future binary updates, but forfeiting all current granted privileges and monies already paid under contract, and the termination of that contract. I would consider that a “restriction”, but IANAL either.
I see how it could be interpreted as that now, but I still disagree. To say that restrictions also include the consequences of doing some thing (e.g. you receive no further binaries) implies to me that the definition would be completely up to the user. One might intentionally break the contract to obtain a one-time copy that they weren't technically "restricted" from getting. This seems rife with ambiguouity, which from my understanding would not work well in court. In contrast, "ability to copy/distribute/modify this snapshot of code regardless of what happens afterwards" remains a guarantee.
It has been a day since I last replied, and I am still not a lawyer. I absolutely agree that input from the FSF or a GPL-specialized lawyer would be insightful.
I’m not sure you said here what you mean to? I certainly still have access to the binaries I already downloaded. After all, they’re still running on my box! And also under the RHEL contract (old or new), I’m still able to run those binaries indefinitely. But that means I’m also still entitled to the source from RH for those installed binaries since they were originally distributed and installed by RH under the terms of the GPL.
I thought you'd still have access to the source for the binaries on your box, just that you couldn't ask for the source of newer binaries since they would have already stopped supplying those. I could also be misunderstanding how Red Hat's systems work.
But out of all this, my biggest concern of all this by far is the can of worms RH is opening. What’s going to happen when other even less scrupulous companies attempt to run with this possible GPL loophole RH is trying to bust open?
Alex makes points I would make regarding this - I don't see any loopholes that would violate the four freedoms. At no point would you be unable to copy, distribute, or modify code for the binaries that you have.
In the event that I'm wrong, surely the FSF would be able to handle this and find a solution if they consider it a problem; perhaps in the form of a GPLv4?
Thanks, I appreciate your insights. Was surprised that it's not new from Red Hat.
To say that restrictions also include the consequences of doing some thing (e.g. you receive no further binaries) implies to me that the definition would be completely up to the user.
I would say it's up to a court, not a user, to decide whether or not in the context contract law if those "consequences" are also "restrictions".
Contract law is all about defining actions and the consequences of what happens when those actions are taken or not taken. What's the point of having a granted right if I can't exercise it without a significant, immediate, and direct penalty imposed by the grantor? I would say that's no longer a right.
Section 6 is not just about a grantor taking away any of the four rights, but also about stopping the grantor imposing any further restrictions on the exercise of those rights granted by the GPL. Otherwise, if section 6 was just to protect those four rights by themselves, why wouldn't it just simply say, "The rights granted herein to the recipients, all or in part, may not be revoked under any conditions by the licensor."?
If the language of section 6 were the above alternative, I'd certainly be taking your position. But RH isn't revoking those rights, they are attempting to restrict the exercise of them using penalties, what I believe section 6 is directly trying to prevent. As I mentioned elsewhere, those penalties go way beyond just disabling access to potential future versions of software packages and their matching source. (If that were just the case, I'd also be inclined to agree with your position that losing potential future access by itself would arguably not be a restriction.)
This seems rife with ambiguouity, which from my understanding would not work well in court. In contrast, “ability to copy/distribute/modify this snapshot of code regardless of what happens afterwards” remains a guarantee.
I would say its ambiguous to us (without legal training), but I'd bet the language used in the GPL license is pretty clear to a contract lawyer and would have some legal precedence as well. Lawyers tend to avoid using words and phrases without established precedence behind them.
Back in 1990-1991, I was working for a company that was unhappy shipping its commercial software compiled with GCC under the language of the GPLv1. I was on the team (engineering side) that worked with RMS and his legal team to craft the GPLv2 and LGPL as replacements for the GPLv1 that eventually made everyone involved happy. I wasn't directly involved, but was on the periphery and got to see a lot of the proposed language and reasoning behind it being raised and discussed on both sides. Unfortunately, I don't remember any of it after all this time. But I do remember just how much effort went into practically every word that was (and was not) in that license. That experience though led me to being a GPL supporter for the last 30 years.
I don’t see any loopholes that would violate the four freedoms. At no point would you be unable to copy, distribute, or modify code for the binaries that you have. [...] I thought you’d still have access to the source for the binaries on your box, just that you couldn’t ask for the source of newer binaries since they would have already stopped supplying those. I could also be misunderstanding how Red Hat’s systems work.
Yes, that's a problem. Without your now deleted account, you would lose access the matching source. With RH systems, you have to have a valid, authorized, and logged-in RH account to access the source for a given installed binary package.
As mentioned elsewhere, RH could plug this problem by offering to allow you to request the source for those packages outside of the normal channels such as a charged service for mailing you a DVD or USB stick. But as far as I know, they have not offered this service, hence a GPL violation with their current approach of cancelling your account.
I don’t see any loopholes that would violate the four freedoms. At no point would you be unable to copy, distribute, or modify code for the binaries that you have.
It's not just the four freedoms the GPL protects, but the exercise of them. Maybe there's a chance I've convinced you a little more of the position I have. :) At least I hope you more clearly see it.
Thanks, I appreciate your insights. Was surprised that it’s not new from Red Hat.
And for yours as well.
IBM deserves a lot of blame for a lot of things, but on this one issue, they don't.
The GPL only cares about ensuring the four freedoms are maintained for binaries and their related sources. It has nothing to say about other services you may or may not be asked to pay for. Indeed as you say the GPL allows for reasonable costs to supply source code. We have gotten used to this being ubiquitous and "free as in beer" but it's not really. All this distribution costs someone somewhere money to do.
The four freedoms may say you can run the program for any purpose without restriction but there are definitely other laws that would have a say if you did certain things with those programs.
We have gotten used to this being ubiquitous and “free as in beer” but it’s not really.
Any big company which cannot bear the costs of publishing code to github can just calculate how much it would have costed them, then send the code to me and I'll upload it to github for them and only ask for half of the price. Seriously, I'll halve your "cost". Because it is actually free and they are just bullshitting.
Is this not the same kind of argument companies make against piracy? I think it's not so much a pricing problem than it is a service problem. In the same way that people rely on Steam rather than pirating every single game on the market, it's the services that are offered rather than the price that has to be paid.
Say you go ahead and do this - what guarantees will you make with that price? Guarantees like priority support and timely package updates cost money, which doesn't sound viable unless the big company is setting absurdly high prices, in which case, that just sounds like competition.
I'd rather they didn't have to waste their valuable engineer time supporting the small niche case of some making certain magic binaries a little easier to hack on. Their time can be much better spent working on the upstream project wherever it might be hosted. As long as the license is respected Red Hat can distribute as they want. Indeed you could argue that CentOS stream provides the "preferred form" of code access required for building Red Hat like distros.
This is a storm in a teacup when we have bigger oceans to boil.
The GPL only cares about ensuring the four freedoms are maintained for binaries and their related sources.
No, the GPL goes beyond that. It not only ensures those four freedoms, but also ensures the freedom to exercise them without restriction. That's what the language in section 6 is meant to protect. If RH only limited potential access to future releases of binaries, I see that as fine and not a restriction. But RH is going well beyond that by terminating existing contracts; accounts; technical, web, and support access; and not refunding monies paid in advance for those services. (Theoretically, since they haven't done it to anyone yet that I'm aware of.) If legally those actions are not deemed a "restriction", then I'd agree with you.
