Hacker News new | past | comments | ask | show | jobs | submit login
RedHat found a way to get around the GPLv2 license intention with contract law (opencoreventures.com)
167 points by andy99 11 months ago | hide | past | favorite | 201 comments



“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


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


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.


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!


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.


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.


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.


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


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


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.


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.


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


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.


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.


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.


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.


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


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.


I think many of us have taken for granted a very broad idea of "the spirit of free software" because of overlapping practices over the past few decades. But I'm not sure these are actually the "intent" of GPLv2, which I think would mean what Stallman et. al were advocating back then.

The GPLv2 is pretty clear about allowing for "hostile" forks, and not about mandating communal behavior from everyone. That is particularly clear in how it offers multiple methods to satisfy obligations to redistribute sources. A vendor like Red Hat can choose whether to make sources generally available to the public or to only respond to requests for sources from their own licensed users. They are moving from the first method to the second. The GPLv2 also doesn't say anything about obligations to receive patches nor offer maintenance or future versions of anything.

I think we've all enjoyed a luxury of people acting beyond the actual license obligations. The voluntary effort to contribute to a communal codebase and broadly share a stream of maintenance releases is very nice. But licensing does not compel all this voluntary effort. I think it is in Red Hat's rights to try to capture some of this business value that has been left on the table, even though I selfishly hope that they will either stub their toes and reverse course, or get out-competed by a new benevolent vendor who sees an opportunity in taking over such a communal role.


> I think we've all enjoyed a luxury of people acting beyond the actual license obligations

and, the largest and most-profitable companies on Earth today have also enjoyed a luxury beyond the actual license obligations.

To "pile on" .. it is not that "the well is running dry".. rather it is an explicit business objective to restrict the distribution of SECURITY UPDATES and in a parallel move, require those security updates to continue to operate with money doing X-y-z. Its not secret.


The GPL is very clear that the software does not come with a warranty or any guarantees of fitness for any purpose. The customer has the code, they are free to fix any bugs or security holes that affect them, but they are not entitled to have other people do that work for them for free.


> The GPL is very clear that the software does not come with a warranty or any guarantees of fitness for any purpose.

It does include a general warranty disclaimer, of course, in many jurisdictions, sone or all of the warranties that would exist without an explicit affirmative warranty offer also can't be negated with a disclaimer, so this may mean less than a naive reader would assume, being unnecessary where the law wouldn’t impose a warranty, and ineffective where it would.


> But I'm not sure these are actually the "intent" of GPLv2, which I think would mean what Stallman et. al were advocating back then.

I don't buy it. If you think about the commercial Unix systems in the 80's that GNU was started as an alternative to, the threat to cut off a customer from all future updates would have been just as prohibitive as it is with Red Hat today. Admittedly, with security being more important now than it was then, it's more critical now to get a steady stream of minor security updates. But being cut off from major updates is prohibitive too, given that most customers expect to stay on the system for years, both now and then. And those commercial Unixes were less compatible with each other than modern Linux distros are with each other, so the switching cost would have been higher. (Disclaimer: I wasn't around in the 80's; this is based on what I've gathered rather than personal knowledge.)

Given that context, let's look at Stallman's definition of free software from 1987, four years before GPLv2: [1]

> The word "free" in [the Free Software Foundation's] name does not refer to price; it refers to freedom. First, the freedom to copy a program and redistribute it to your neighbors, so that they can use it as well as you. Second, the freedom to change a program, so that you can control it instead of it controlling you; for this, the source code must be made available to you.

Here is Stallman waxing poetic on the same concept in 2001 (so after GPLv2, but I think it's fair to say his thinking hasn't changed much): [2]

> A program is free software for you, a particular user, if you have the following freedoms:

> [..]

> Freedom Two is the freedom to help your neighbor by distributing copies of the program.

> [..]

> Freedom Two is the freedom to help your neighbor by distributing copies of the program. Now, for beings that can think and learn, sharing useful knowledge is a fundamental act of friendship. When these beings use computers, this act of friendship takes the form of sharing software. Friends share with each other. Friends help each other. This is the nature of friendship. And, in fact, this spirit of goodwill -- the spirit of helping your neighbor, voluntarily -- is society's most important resource. It makes the difference between a livable society and a dog-eat-dog jungle. Its importance has been recognized by the world's major religions for thousands of years, and they explicitly try to encourage this attitude.

Do you really think the person who wrote this would have been satisfied with 'you can technically share the code with your neighbor, but only if you are ready to immediately migrate away from said code because you can no longer receive updates'?

[1] https://www.gnu.org/bulletins/bull3.html

[2] https://www.gnu.org/philosophy/rms-nyu-2001-transcript.txt


In at least a couple places, the article says what Red Hat is doing is “technically legal” or “technically in compliance” with the GPL.

I don’t find it very useful or enlightening when people start talking about “intention” in this context. If you intend for some particular outcome to happen, you really need to make sure that it’s written into the license! That’s what licenses and contracts and every annoying legal-type thing that exists are for!

On a related topic: Taking a quick scan of GPLv2, this doesn’t even seem to grossly offend the principles or intent of the license - am I reading it wrong, or, when it comes to appropriately distributed software (i.e., bearing notice, license terms, copyright, disclaimer, etc.), it seems to say pretty clearly that source only need to be provided to recipients of the modified program? I guess there’s some ambiguity about what 2(b) could mean?


>>I don’t find it very useful or enlightening when people start

Equally, I dont find it very useful or enlightening when people point out the obvious while ignoring intent completely.

While I agree with some of your premise, nothing is ever perfect, and the interpretation of legal agreements is why many lawyers make lots of money, and why we have 10's of thousands of people employed in the legal profession

So simply saying "will if you wanted X you should have written it down" is a simplistic take on a complex problem. If we could do that we would not have law suits debating the details of contract, nor would we have countless unintended consequences from various laws passed by the various legislative bodies

>Taking a quick scan of GPLv2, this doesn’t even seem to grossly offend the principles or intent of the license -

It does in fact offend the principles which si why GPLv3 was created, and AGPL and other versions of the license to counter some of the "holes" companies like RedHat exploit in GPLv2.

Linux however has always and likely always will resist moving to GPLv3


You're not reading it wrong. The popular understanding of the GPL vs. the actual text of the GPL are two extremely different things.

Red Hat is far from alone in this. If I'm not mistaken, there's a whole cottage industry of WordPress plugin and theme developers who use basically this model. The plugin or theme is GPL'ed because it depends on WordPress, which is GPLed. But they gate the software and require payment to get it. They may also have an agreement that sets out a limit on redistribution for access - if you buy the theme or plugin from them and then set about redistributing it, they're not going to take your money in the future.

I can't think of any good way to close the "loophole" here in a GPL-type license that doesn't essentially force a developer to distribute to anybody they've ever done business with, forever. Any language that would force Red Hat to keep its subscription with an "offending" customer would also tie their hands for cutting off access for other reasons -- because who wouldn't claim that the reason Red Hat cut the subscription was over distribution?


What's the loophole? This is working exactly as intended, no?

GPL is to grant the user of software freedoms. Free as in freedoms, not beer. It's origin was from the user of a printer driver being frustrated they couldn't debug and fix an issue.


The loophole is that as soon as you exercise your rights, you lose future access. So if you want access, you can't exercise your rights.


You have the right to do whatever you want with the software. You don't have the right to force someone else continue to work for you and provide you with updates.


I don’t understand why this isn’t blindingly obvious. A copyright holder releasing their software under an open license is a huge privilege given to their customer. It doesn’t matter what reading they are doing it - marketing, hoping for external contribution, goodwill, etc. - it is their right to choose a license. It is also their right to change their license at any time.

While I’ve not chosen RedHat for my own projects, I used it for nearly two decades at companies where it was already in place. Some of those had support contracts, others didn’t. Based on my experience, RedHat is one of the main reasons Windows didn’t completely take over backend systems. They offered a cohesive, supported server OS that could be run for less than the cost of Windows or Unix servers on nearly any hardware. I could enumerate the things I don’t like about RedHat Linux, but in an enterprise setting, the volumes of documentation, mature and complete set of repositories, and huge community essentially negate my own preferences.

Their new licensing may make them irrelevant going forward, but I’m thankful for all they’ve done overall… except for systemd, burn it with fire! ;-)


It’s not about forcing, it’s about someone threatening you with an unfavorable outcome if you exercise your rights. That is (as I said repeatedly) not against the letter of the GPL (IMO). But it’s a chilling effect on exercising your rights.


go with another distro then

red hat is about security and support

those customers will stay

i don't agree with it myself. i think 'go, debian!' but they have their niche, and that's ok. it's their bed. they're making it.


I use Arch and Debian, I never touched any red hat distro IIRC.


Except for how you literally can.


They are providing the source as required. However, a key part of the GPL is that RH's customers should also be able to redistribute the source to anyone else, and RH is preventing that through contract law.


They are, of course, always free to distribute the source to anyone else. RedHat cannot stop that. But if they do distribute the source to anyone else, RedHat is free to stop taking their money and not provide the software and source code to them in the future.

It's shitty, but I can't see any realistic way to close this loophole.


GPL says that you can't impose further restrictions on the people you distribute GPL software to. Everybody should receive the entire set of freedoms unfeterred.

Using contract law (or using blackmail, or using anything else) to restrict redistribution of the source appears to not be in compliance of GPL to me. I can't see how a judge might find otherwise.

The problem is, who has standing here? The Red Hat customer or the copyright holder?


How about we use a different analogy. Google, Facebook, Amazon, Microsoft - they all have patches to the linux kernel which they do not always open source. And nothing in the GPL compels them to open source them so long as they aren't distributed outside the company, and are only used on internal systems.

Let's say an employee with access to those internal kernels, who is under an employment contract and non-disclosure agreement, releases the kernel source code with those patches included. Would the GPL prevent that employee from being fired and/or sued for violation of NDA?

Nope.

>GPL says that you can't impose further restrictions on the people you distribute GPL software to.

That's just the thing. Red Hat does not impose any further restrictions on the software that has been distributed to you. You can continue using RHEL, in theory, even with an expired license. There is no "kill switch".

But Red Hat is not obligated to continue providing you with access to their services, including their software update repositories.


>>Would the GPL prevent that employee from being fired and/or sued for violation of NDA?

That is not even close to being an analogy. In that case the Code, copyright, was not transferred to the employee, They are not operating under the conditions of the GPL at all. As an employee I am not given a "license" to the code as I would be as a customer or licensee of the code.

As such violation of the NDA would have nothing to do with the GPL at all.


> In that case the Code, copyright, was not transferred to the employee, They are not operating under the conditions of the GPL at all.

In this scenario let's say that the patches are GPLv2 licensed and apply to a larger GPLv2 codebase, as opposed to something like a separate kernel module. So the code is, indeed, GPL, and both the built kernels and the source itself are unambiguously a derivative work of GPL code.

And this code is distributed to you as part of your job. It wasn't stolen, it was provided to you with specific terms of use, namely that it only be used within the company.

Is your argument that there can be no legal constraints beyond what "the GPL says" in this situation? That those constraints shouldn't apply, because they infringe your GPL-provided rights?


As the GPL FAQ says, distribution between employees of the same company may not even be considered "distribution" depending on the region. The analogy is stretching this too far.


Fine - so make them third party contractors instead of employees of the same company.

The end result is the same.


No, it's not. Even if they were employees of a different company that is a subcontractor, the jurisprudence is not clear at all.

This is basically the "museum argument" which is quite old. It's an entire different story if you do distribute the software to your subcontractors for their use.


What customers have bought is a support contract, which includes distribution of software under the GPL.

What Red Hat is threatening to do is to stop allowing customers to renew the support contract, and stop allowing customers from buying a new support contract.

The GPL does not (outside of a couple of small details for how to get access to the source) require a software distributor to provide continuing services.

Otherwise you get into all sorts of strange cases, like Alice and Bob are friends working on a GPL project, Bob sends a copy to Eve, who collaborates with Bob. But Alice hates Eve, so stops working with Bob on the project.

The GPL does not prevent that sort of retaliation for redistributing software. If it does, where? Why should forcing continued collaboration be part of freedoms of the GPL?

Switching away from the analogy, where does the GPL say there's a difference if money is involved?


So while I strongly believe this violates the spirit, I disagree about this violating the letter. You are free to distribute, all that will happen is that you lost future access. Trust sounds like a full legal loophole.


Would the copyright holder (GPL'd software) have standing to sue for Tortious interference, being that the GPL is a contract between the copyright holder and end user?


it's not a restriction if they're never forced to agree to it

giving certain users advantages over others isn't a violation of the license


I think it is exactly as intended. As a developer of an open source project, you are not required to give your source code and _any other derivative of that code_ to _all users_. You are only required to give _each_ user the source code for what has been distributed to them.

Any user is free to turn around and _redistribute_ or modify anything that has already been distributed to them. The user is not required to distribute modified derivative source back to the original developer, unless the user has distributed a running copy of the derivative.

The license says nothing about not being able to _charge_ users for the original executable software. It says nothing about guaranteeing delivery of executable derivatives made by the original author in perpetuity.

In this way, the incentives are aligned to:

1. Produce useful running software that is of the same scale of usefulness and complexity of things such as Chrome and Windows, because these complex software packages have enormous value and cost time and money to make and should be profitable for the maker. 2. Also produce useful running software that the user is allowed to fix or build new, useful derivatives upon through receiving the source. For which they can then charge. Doing so, the original author may decide to not deliver any further derivative executables to the user, meaning that the user is no longer entitled to source code. The user now bears the maintenance burden for their entire product -- which, when distributed, must come with a copy of the source.

I think this allows for users to generate their own commercial value streams from the originator while protecting the originator's ability to make money, and I think it is a good thing. Open source work need not be volunteer work. You want updates, you comply with the terms of the license. You want to make a derivative work for your own profit and redistribute it, fine, but you'll have to renegotiate the price for the originator's updates to get the updates and the corresponding source updates.

Sounds like an excellent way for open-source devs to actually get paid for maintenance work, IMHO. It need not be free as in beer to provide value, and freedom, to users.


RedHat cannot choose to stop doing business with someone because they belong to a protected class, so we have already set the standard that government can force someone to do business with someone else. We can consider 'being forced to follow the contract you agreed to' as an invalid reason to stop doing business. Sure, it'll take a bit more work to get out the kinks compared to the 2 minutes of effort I put into it, but it shows a realistic way to limit this loophole. As with any law, not everyone will follow it, but that is rarely used as a reason to dismiss a law.

Edit: Fixed typo on how the current law works.


Redhat can absolutely stop doing business with someone in a protected class. They can stop doing business with anyone in any protected class.

What they can't do is stop doing business with someone because they belong to a protected class.

You would have to argue that support of the GPL was a religious belief to gain such protections.


That was a typo on my part. I've corrected it.

>You would have to argue that support of the GPL was a religious belief to gain such protections.

Under the current law I don't think there is a path to allow this. I'm suggesting a new law. The reason for the new law would be to close a loophole which lets megacorporations skip having to follow contracts (or even laws, as there is a similar problem there).


That's not relevant to the point, since it's analogous to them choosing not to do business with someone because they redistributed the software. The motivation is not a point that's in question.


> cannot choose to stop doing business with someone belonging to a protected class

Think for a moment. Race is a protected class. How does anyone stop doing business with anyone?


> we have already set the standard that government can force someone to do business with someone else

You really don't want to go there. There's no reason to single out civil rights law when there are all sorts of other examples which are less contentious and less narrowly focused.

For example, common carriers provide a "service to the general public without discrimination" (quoting Wikipedia), where "discriminate" has a far broader meaning than a dozen or so protected classes of most civil rights laws.

Like, the phone company can't restrict people from having a conversation in ancient Egyptian, because they lack a compelling reason.

And common carrier law has existed for centuries.

But that's beside the point. Quoting https://www.ftc.gov/advice-guidance/competition-guidance/gui... :

] In general, a seller has the right to choose its business partners. A firm's refusal to deal with any other person or company is lawful so long as the refusal is not the product of an anticompetitive agreement with other firms or part of a predatory or exclusionary strategy to acquire or maintain a monopoly. This principle was laid out by the Supreme Court more than 85 years ago

The example is almost directly relevant:

] Q: I own a small clothing store and the maker of a popular line of clothing recently dropped me as an outlet. I'm sure it's because my competitors complained that I sell below the suggested retail price. The explanation was the manufacturer's policy: its products should not be sold below the suggested retail price, and dealers that do not comply are subject to termination. Is it legal for the manufacturer to cut me off?

] A: Yes. ...

You wrote "being forced to follow the contract you agreed to".

That makes it sound like you know little about B2B contracts.

The law right now says forces you "to follow the contract you agreed to." You can be taken to civil court if you do not. So you proposal doesn't change things.

Further, literally every contract I've signed has a termination policy describing how either side, at their own discretion, can terminate the contract.

All Red Hat needs to do is terminate the existing contract and offer a new one. Those that don't want the new contract no longer have a contract. Totally legit.


>For example, common carriers provide a "service to the general public without discrimination" (quoting Wikipedia), where "discriminate" has a far broader meaning than a dozen or so protected classes of most civil rights laws.

Why would this be a better example, as this would mean having to argue a similarity for all businesses to be treated as common carriers, or else the new law would be limited only to some businesses which isn't the intent.

The example I gave shows that, with justifiable reasons, the government can limit the ability of any business to refuse service. Now it becomes a question of if working around contracts is a justifiable reason or not.

>The law right now says forces you "to follow the contract you agreed to."

For certain definitions of 'follow'.

>All Red Hat needs to do is terminate the existing contract and offer a new one. Those that don't want the new contract no longer have a contract. Totally legit.

And I'm suggesting a change in the law which expands the reasoning that such decision might be deemed to not be totally legit, just like they can't do so for certain reasons already as we have decided the social good of banning those reasons is worth the government having such power.


> Why would this be a better example

Because it doesn't specifically deal with members of a protected class, and follow-on discussion about which classes should have protection, nor real-world issues like how private clubs and religious organizations can legally discriminate against those protected classes, or how theater and movie productions can require an actor to be of a certain race (a Bona Fide Occupational Qualification).

> the government can limit the ability of any business to refuse service

It's very well understood that the government has that ability. The government can also force a business to allow someone in who is (or is not) not wearing an N95 mask, and also force a business to allow someone in who is exercising open carry.

There are many such examples.

Given that, why single out civil rights law and its associated sets of who may be discriminated against (discrimination against Jets fans is usually not illegal) and explicitly allowing discrimination, along with a dedicated federal agency (the EEOC) to interpret and enforce the law, along with equivalents at the state level?

Is it because you think your proposed changes requires that level of enforcement bureaucracy, and can't be handled by the current criminal or civil code?

> For certain definitions of 'follow'.

The legal definition is all that matters. Give a relevant counter-example.

> I'm suggesting a change in the law which expands the reasoning that such decision might be deemed to not be totally legit

And I pointed you to a Supreme Court interpretation which says that law will be found unconstitutional. United States v. Colgate & Co., 250 U.S. 300 (1919). https://supreme.justia.com/cases/federal/us/250/300/

Your law, should it somehow pass, would be knocked down by the courts. You need a constitutional amendment to justify this level of restraint of free trade.

Civil rights law says that restraint of free trade is possible because there is a tension between the exercise of free trade and the Equal Protection Clause of the 14th amendment, and Congress has the power to find that balance.

Requiring customers to open carry, or to wear (or not wear) a mask are also based in interpretations of constitutionally allowed powers.

Your proposal does not give any similar justification for restraining free trade.


> RedHat cannot choose to stop doing business with someone belonging to a protected class

RedHat cannot choose to stop doing business with someone because they belong to a protected class

Everyone belongs to a protected class.


The key is not the source code RHEL ships, the key is the list of names of patches RHEL takes from Centos Stream/Fedora to get to a stable LTE environment.

The code is all known, the patches are all known, but which patchsets did get into it is their business model.


It's because when writing a contract, you can't consider all of the corner cases like you might be able to with code. The intention is that to be sharing stuff, where "sharing" and "stuff" is, unfortunately, poorly defined. The feeling is that Red Hat is going against the spirit of the GPLv2 because they're penalizing people for sharing.

Yes, the legal system involves a bunch of minutiae so that a good contract would define "sharing" and "stuff" explicitly but for people that don't want to be lawyers, it is an "annoying legal-type thing" that they really don't want to deal with. It forms opinions for people about the law when the law clashes with the intention of it, so it's useful for others.


The intention is explicitly and obviously that additional restrictions not be placed on these downstream users. The fact that you are only required to transmit to the entire universe is merely limiting the burden placed upon you not delineation of the limit of who can access the source.

If you can't explicitly tell foo they can't do bar but you ensure for practical purposes that they can't use the the expensive thing they paid for and must incur potentially millions in migration costs you are at least in violation of the spirit of the license.


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

The community may be large enough to end-run this. Every month, a new subscriber gets the source code, publishes it, and yeets their subscription. Or, if I'm reading this right, they cancel their subscription so they are no longer under its T&C, and then publish the code.


I think Rocky's Linux propose solution of using AWS Instances is probably the best path. Unless RHEL wants to stop allowing RHEL Licensed Instances from being spun up by AWS Customers and instead having to have people "bring their own license" to AWS which would likely hurt their revenue far more than anything Rock or Alma would have


Hell, someone publish a script up on GitHub to automate the whole process.


I can't imagine this holding up in court.

By analogy, it sounds like I give you the right to walk across a line, but I also have the right to shoot anyone that crosses the line. This has the net effect that you effectively are not allowed to cross the line.


No. The analogy here is this: Every time I hand you your monthly subscription of software, you can do anything allowed by the GPL. However, if you threaten my business, I can stop your monthly subscription.

You have the GPL rights for everything I've given you. I don't have to continue to convey the rights to new things to you if I don't like how you use them.

If Red Hat were selling GPL'ed software for navigation systems to a supplier in Country A and it turned out that they were re-distributing that software to Country B to bomb Country C, nobody would blink if Red Hat refused to stop doing business with that supplier. The imaginary obligations that people have invented around the GPL wouldn't allow Red Hat to discontinue that relationship.


That's not quite how (US) courts work. In the US, licenses and contracts aren't read as by a computer (as coders are used to writing and reading) but by intent. You can follow the letter and be in violation if you intentionally violate the spirit, and vice-versa.

My read is that Red Hat is probably not in compliance, although the second piece of contract law is recourse and damages. It's not clear it's worth anyone's time to prove Red Hat is not in compliance.

Note that there are hundreds of jurisdictions in the world. Red Hat is probably in compliance in most statutory law jurisdictions, at the edge in common law ones, and I can't speak for others.

That's an interesting line to walk. GPL is global, and Red Hat distributes software developed in hundreds of jurisdictions. Any of those software authors could sue in local courts. Most would lose. Some would win.


I'm not convinced that this even violates the spirit of the GPL.

Let's be honest here: Red Hat is still distributing the software widely, but it's making it hard to make exact Xeroxes of RHEL. That's a business problem, not a software freedom problem. CentOS Stream is, at least in my opinion, from a software freedom perspective just as good as RHEL.

You can use it, study it, change it, and redistribute it. AFAIK everything in RHEL makes it into Stream, albeit out of order and hard to re-assemble as an exact copy. But it's not like Red Hat is adding great features to RHEL that it denies to users of Stream.

Compare that to the Open Core folks who are trying to gang up on Red Hat now. There's the core version that has most of the functionality, and then the enterprise features are held back under non-free conditions. You have no recourse if you're using an open core product and they get bought up and the software is discontinued. You can't exercise the four freedoms to hire someone to maintain it for you or DIY it if you don't have the code.

But someday when Red Hat stops making RHEL you can still exercise the four freedoms and ask somebody else to do it for you or DIY it. To me, that's the spirit of the GPL - not that I'm entitled to undermine somebody's business by making exact Xerox copies of their software indefinitely.


> I'm not convinced that this even violates the spirit of the GPL.

It doesn't. And this "loophole" is old.

In days of yore, GPL "compliance" could be "Fine, here's a magtape of the source."--with no build instructions.

This is effectively what RedHat just did.

Andy, you know, I'm kind of sympathetic. If you want "certified" Linux, then you should have to pay the company that went through the grief to go get the certifications.


Right. When I was at Ksplice, RedHat provided their changes to the kernel source as a monolithic patch file, which certainly abides by the letter of the law, but individual patches would have been so much more helpful.


To me it seems similar to sharing Netflix account passwords... which Netflix is now cracking down on.

You're allowed to use the service/software but not allowed to take away new business clients from us by re-sharing the source yourself.


> if you threaten my business, I can stop your monthly subscription.

That business is based on violating a license.


No.


Yes?


My intention was to object to the parent post replying with "No" to something that wasn't a question or a falsehood. I find it annoying and inflammatory and not conducive to good discussion. Since brevity is wit, I thought that would be a good way to get my point across without having to write an explanation like this one.


> something that wasn't [...] a falsehood.

This is a judgement that you personally made, without explanation. The person who you replied to thought that it was a bad analogy, and explained themselves.


No.

Make whatever judgement you like about how good the analogy was. Starting your answer with "no" might be appropriate if someone says "Fortran is a lisp" or "do you think cars can love", but it's not a cool thing to say if someone just states an opinion, regardless of whether or not you liked it.


I guess it’s more like if you cross the line you can’t go to the place where the line is again, which isn’t that much better but it does mean people can legally redistribute it if they are willing to not get any future releases


It's like saying you have freedom of (let's say speech) but not freedom of consequences, so the government will still discriminate against you.

It shouldn't hold up on court and hopefully it won't.


there is no equal protection clause in the GPL

if some users are given access to future products based on good behavior, that doesn't mean anything legally


> I can't imagine this holding up in court.

My imagination has no difficulty with that at all. US courts have a great deal of respect for legal contracts. Unless you can identify a conflict between subscription terms and GPL terms the former probably will survive a court challenge.


It's not like they are the first ones. Anyone remember GRSecurity, especially after their beef with a person called L. Torvalds? They "pulled a red hat" before it was cool. Would be surprised if they were the first ones.


Honestly, the more reactions I see from certain parts of the community, the more I agree with Red Hat’s decision. And I started from thinking it was a bad move.

Also, see Jon “maddog” Hall’s take from a few days ago:

https://www.lpi.org/blog/2023/07/30/ibm-red-hat-and-free-sof...


I agreed with it since the beginning, as Jon “maddog” Hall states, there are plenty of distributions out there.

Thanks for pointing out his take.


> RockyLinux has a work-around that doesn’t violate any subscription agreements and AlmaLinux is adjusting its development model to pull from CentOS Stream.

A bit out of the loop here - what is the workaround?


They run a cloud VM with a paid RHEL AMI and use it to pull the sources. :-).


How long until this work-around is "patched" by RH/IBM?

This is a big part of the reason there's so much uncertainty in the RHEL community right now...


They would need to stop providing sources to all of their clients using rhel in cloud.. doesn't seem possible


Could they not change their contract/license and forbid "exporting" or something?

IBM is big enough to make an example out of a few unlucky individuals, and compel everyone else to play their way.


RH/IBM is bound by a contract where the moment someone spins up one of their VMs, they MUST provide all sources and the recipient is free to redistribute them.

If they forbid this they lose the right to use Linux.


It doesn't work that way, in reality.

Not anyone can just bring a suit to compel compliance - and IBM has much deeper pockets anyway. So even if the suit was righteous, it would be dead and buried long before it saw a court room.

Additionally, the Kernel is only a tiny portion of the RHEL distribution. There's plenty of proprietary RH/IBM code in RHEL, and a ton of non-GPL'ed software too.

Lastly, a RHEL license contract might be updated to explicitly state you are forbidden from distributing RH sources... which would kill Rocky's "work-around" while still being GPL compatible.

GPL isn't some magic bullet like some people believe...


> Not anyone can just bring a suit to compel compliance - and IBM has much deeper pockets anyway. So even if the suit was righteous, it would be dead and buried long before it saw a court room.

Unless it's Oracle that sues them.


> Could they not change their contract/license and forbid "exporting" or something?

Even the people who don't think what they already did was a GPL violation would consider that to be one.


And they can't do that without some customer ban list for AMIs


Is this true? How is this compatible with what other posters are asserting -- that the issue at hand is that Redhat will kill your contract if you start distributing the sources?


When you launch a cloud RHEL VM you don't really have a contract with Red Hat; you have to "agree" to their EULA or whatever, but I don't know if there is any way for AWS to cut off a customer from accessing RHEL. In theory Red Hat could ask AWS to kill your whole AWS account, but would AWS do that?


And anyway even if AWS were to shut your account I guess you'd just need another volunteer to spin another AWS VM to start all over again...


All of this nonsense is excellent reason to avoid using Red Hat, at least outside of a business context. They are the Microsoft of the Linux world.


Wait till you hear about Qualcomm. “Yes it is gpl but your contract with us states that you agree to never ask for source”


Is that legal?


No, but the entire Android ecosystem will collapse if it's challenged, so...


There is no circumvention of the GPL going on, or any loophole in the license being exploited.

It's basically "I'm only going to be your friend and provide you with free software with my cool and useful modifications if you don't redistribute it to your other friends. (Which you're allowed to do, but I just won't be your if I catch you doing that, and won't give you any more)."

There isn't anything the GPL can do about that, without becoming a crazy non-free license. It's entirely out of its scope.

The behavior doesn't step on any user rights, because:

1. It doesn't remove their rights to what they already have (software they have downloaded under the Subscription Agreement).

2. Users do not have a right to enter into or remain in a Subscription Agreement with Red Hat; there is no such right.

3. People have a right to refuse to redistribute something. If you have some GPLed program I want, and I ask for it, you can say no. If you say yes to giving me binaries, then you can't say no to giving the source (for just that specific version of those binaries and nothing more).

4. People have access to the original software; they can make their own distribution from scratch to compete with Red Hat.

There is no intent in the GPL whatsoever to prevent Red Hat's behavior; there is no wording that could even remotely have that interpretation.

The person who came up with the license probably disagrees with the behavior, but he didn't put anything in the license to prevent it and probably wouldn't find it a good idea to try to use a copyright license to try to do that.


Please stop reinforcing the Red Hat ecosystem by using Red Hat derived distros.


the people reading this are not the people making those decisions. Management uses this product as a required element in business contracts, those requirements include security updates. The security updates are not going to be available the day management stops paying. It is explicit.


Maybe. I still see way too much enthusiasm for all these new CentOS replacements in these circles. Those projects are all phenomenally bad ideas and everyone should understand that. People who're convinced in board rooms are getting RHEL anyway, they've little interest in the 'CentOS community'.


I work at a stealth mode database startup. We are not prioritizing RHEL support because of their business decision.


This might be handled via a secondary market in abandoned Red Hat licenses. Offer a nominal amount every few months for a Red Hat customer that's leaving Red Hat. Have them obtain the source, release it, and let their license expire. Talk to someone who liquidates the IP of failed startups. "Localliquidators.com" is in that business. They probably have some license rights available.

Somebody should do this at least once.


This idea isn't new. Does nobody remember Sveasoft? They tried this with regards to alternative WRT54G firmware, back when that was a thing. They ended up failing in the market, to the point that seemingly nobody even remembers the attempt.

Redhat seems to be betting on their size for their staying power. But that size also means there is much more demand for third parties to route around their attempt at creating an inefficient market speedbump. For example, that proposed solution of subscribing to Redhat through a cloud provider, then distributing the source code seems quite straightforward. If they tighten up on that, it would only seem to take a handful of small subscribers comparing the source code they receive to make sure there is no steganographic watermark, and then distributing source through an unrelated entity without fear of reprisal.

I'm sure they will succeed at creating some level of speed bump for companies that want things to just work, but I'd say that ultimately this is just going to lead to another cycle of users moving to the new libre thing, and then Redhat needing to pay to reacquire those customers later.


Isn't some of the code that redhat distributes under GPLv3 or AGPL?

Are the terms there stricter?


Not really in regards to this particular issue. GPLv3 has the same issue in that it only people who receive the binaries are entitled to the source, and 3rd parties technically have no right to demand the source. AGPL is a little broader, but if I don't allow anyone else access to my modified AGPL app, again technically no 3rd parties could demand the source from me.

It'll be interesting to see if there is some new generation of licenses that require derivatives in source form to be publicly available, but enforcement seems almost impossible.


> [...] licenses that require derivatives in source form to be publicly available

Note, this fails the "desert island test" from Debian's Free Software Guidelines[1].

If someone wants their software to be accepted in the Debian package repositories, they should be aware that using this license might prevent them from doing so.

I'm not opining on whether that's a good policy or a bad policy, only mentioning that that's a thing.

[1]: https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...


Such licenses wouldn't meet the Open Source Definition either (as its a copy of the DFSG) and probably not the Free Software Definition either.

https://opensource.org/osd https://www.gnu.org/philosophy/free-sw.en.html#fs-definition


AGPL provisions kick in for services delivered over a network, basically the SaaS models.

With RHEL some of the code may be under the AGPL (I haven't checked if any of the RHEL packages are actually AGPL), but it's not being offered as a service in a way that should trigger AGPL requirements AFAIK.

GPLv3 doesn't contain any provisions that address this as far as I am aware. It was concerned with things like "Tivoization" and embedded software.

None of the terms in those licenses require the things that everybody seems to want them to require: verbatim publishing of exact source code to everyone everywhere that allows "bug for bug" clones of RHEL and/or continuing a business relationship that forces Red Hat to convey the GPL rights for all RHEL releases no matter what a customer does with those rights.


I hope this makes the RedHat based distros less popular in the long term. We need to get out from under their shadow (and IBMs).


IBM is shitting the bed so badly here.

It was always going to happen. The value of RHEL and goodwill associated with it doesn't clearly flow through to the bottom line, so they were always going kill that golden goose because that is who IBM is. It's sad to watch, though.


This is part of an emerging trend that's a threat to the current symbiosis between open source communities their commercial sponsors.

Many of these companies have nurtured a lot of goodwill with the community and built successful businesses around enterprise customers. Once they're entrenched in the enterprise software business, there is value to be had by cashing in that goodwill and maximizing shareholder value. Even if their current leadership is unwilling to move in this direction, there are plenty of existing enterprise computing companies (e.g. IBM) and private equity firms who will.


GPL v2 part 6:

> You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

I think it can be reasonably argued that a contract designed to defeat the intent of the license is "a further restriction".

The correct remedy is not to require Red Hat to restore their former client's contract.

The correct remedy is that Red Hat, and thus IBM, is no longer licensed to use GPL v2 software.


OK. Let’s say Red Hat Linux Distributors Inc. is the software licensor. And Red Hat Support LLC is the support provider. RHLDI distributes software (and source) in compliance with GPLv2. RHSLLC has a provision in its contract that a support customer may not re-distribute any source that it receives from RHLDI.

Where’s the breach of the GPL? The reference to “You” in that instance, about not being able to impose additional restrictions, would have to be give additional words and meaning not present in the contract for that line to mean what you say it means.

If that’s what the license is supposed to prevent, it really needs to be written in a way that clearly addresses this fact pattern.


No, you're missing the point.

The Linux Kernel is the big GPL v2 fish. It's not a Red Hat licensing to Red Hat situation.


How does one adjust an open source license to make RedHat's redistribution illegal without interfering with distributions that follow the GPL intent?


Where is Oracle in all this? Oracle Linux is a RedHat clone and they sell support contacts and everything that businesses like.


Hopefully the GPLv4 will plug this loophole.


There's no loophole. If you distribute software covered by the GPL, you have to release the source to any person that you distributed the software to, and you have to release it under the same GPL.

The real loophole is enforcement. There's no case law that allows an end user to get standing for GPL software, only the copyright holder can enforce the license.


> you have to release the source to any person that you distributed the software to, and you have to release it under the same GPL.

And this same GPL allows them to further distribute the software to third parties. If you're threatening and intimidating people not to do so, you're subverting the terms of the license.


It isn't a threat or intimidation - it's simply a potential that Red Hat will stop doing business with you.

Imagine for a moment that you're an indie developer and you contract with a company to supply support for a GPL'ed program under the idea that they're using it internally.

Next thing you know, they're taking the code you're providing and offering a subscriber service and undermining your livelihood contracting with other companies.

OK - the GPL says they can do that. The GPL, however, does not require you to keep doing business with them. So, next contract opportunity you refuse to do business with them.

The GPL does not obligate you to re-up with them. Nor should the GPL force Red Hat to supply future updates to customers that threaten its business.

Just because people have become accustomed to Red Hat doing more than it has to do doesn't mean they're perpetually obligated to live up to those expectations.


It absolute is a threat and intimidation. The situation with the indie developer is not comparable. The massive power asymmetry matters.

It just shows that the correct fix isn't some dumb clause that just says "this thing that Redhat did is now forbidden."

A cleverer fix might be to require that the source code be made publicly available.


"The massive power asymmetry matters."

Rules for thee but not for me? What's the boundary for company size that forces public release of code vs. allowing a small company to choose its customers?

If Red Hat's customers find the situation intolerable, they can and will stop paying Red Hat and do business elsewhere. It's not, by and large, Red Hat's customers that are squawking about this - it's people who have decided they're entitled to the clones and are actively undermining Red Hat.


Yes, that's kind of how intimidation works. The mafia doesn't get to claim the shopkeeper is intimidating them.


a) Red Hat's customers are not tiny. There is no massive power asymmetry.

b) Red Hat is not threatening or intimidating anyone any more than the GPL is.

It is simply them defining under what terms you can use their product.


Exactly right, which is why I said it's not a loophole. The loophole is who has legal standing in court. The recipient so far has been found to not have standing. So Red Hat can distribute the software, not even tell you about the GPL, and that's that. Unless the original copyright holder wants to sue them. Which in the famous VMware case, at least in Germany IIRC, the bar to prove infringement or derivative work is impossibly high.

So, the GPL is mostly worth nothing.


> There's no case law that allows an end user to get standing for GPL software

There's case law establishing clearly the doctrine that intended third-party beneficiaries can enforce contract provisions, and that the GPL operates as a contract and not just a bare copyright license. There is not yet case law on third-party beneficiaries under the GPL (though there is plenty of rrason to believe that end users are such under the broader case law on the topic), AFAIK, though SFC v. Vizio, currently proceeding under that theory last I saw status, may well provide it.


It has to be said over and over, unfortunately.

A license or contract is only as good as your ability to enforce it.


Software Freedom Conservancy have a legal theory that the GPL functions as both a license and contract and that recipients of GPLed binaries are third-party beneficiaries of the GPL contract. They are also suing Vizio under that theory. Their next court dates are in California in September IIRC.

https://sfconservancy.org/copyleft-compliance/vizio.html


Again the fallacy. GPLv2 allow (1) giving the source code along with the binaries or (2) promise to allow any third-party to obtain those sources for the cost of copying. The Software Freedom Conservancy post shows that Red Hat considers GPL licensing to be a serious matter. Correct, an end user could not enforce a copyright violation, but the copyright owner can assign those rights.

I also think Red Hat is complying with GPL and other licenses, just it is closer to the edge than last month.


Red Hat offers free developer accounts with available downloads of the install ISOs.

I have never seen the source ISOs from this perspective.

However, would it not be trivial for Rocky, Alma, and Oracle to simply use "burner" developer accounts to pull the source ?


It's interesting that the new agreement terms don't mention distributing 'source code' only 'software.'

And the bit about supporting non-Red Hat software, reads as if, you promise you're not going to use Red Hat binary patches to patch Oracle Linux or some other distro, unless you're paying a subscription per instance of said distro.

There's really no restriction in this article about distributing the source itself.

Red Hat may be happy for this confusion to remain.


The whole purpose of gpl is if you want to be a user of software, you should get freedoms. This effectively eliminates those freedoms by saying that if you use those freedoms, you will no longer be a user.

Defeats the whole purpose, definitely a loophole.


you just made 0 sense, you get the freedoms the GPL gives you, the GPL says nothing about you having to continue being a customer of some company


In a practical sense (but not a legal sense), being a user of the software, and being a customer of the company providing the software that you entered into a contract with and paid, are the same thing.


GPLv4 will be fought with sticks and stones.


Sticks and stones may break my bones but Redhat will never paywall the source again.


The current problem arises from the fact that you have to ask for the source code. So companies can retaliate (if you ask us for the source code, we terminate this other contract).

The solution would be to mandate either including the source code when you distribute the software, or a link to something like IPFS that hosts the source code.


> mandate either including the source code

This could cause problems by making the size of binary packages/executables a lot larger because they’d also need the source


Thus the two options


The second option seems a little better but tying it to specific technology like that seems like it might not a great idea

There’s probably a better way to achieve the same effect


IBM just doing what IBM does - sleaze.


Red Hat always planned to do this. They were huge proponents of the GPL Cooperation Commitment [1], and persuaded lots of gullible developers to irrevocably sign over their rights.

1: https://gplcc.github.io/gplcc/


AFAIK this does not sign over any rights. It simply says that the signees support a "cure" period for GPL violations like the GPLv3 has.

This wouldn't help Red Hat much if a rights holder decided that Red Hat was violating the GPL. At worst, or best, it would give Red Hat a little more time to "cure" its violation. It's not a permanent shield against being sued or having rights rescinded for GPL violation.

So - if somebody signed this and decided to talk to Red Hat and Red Hat didn't want to change its EULA or whatever, then they can go ahead and sue or formally rescind Red Hat's GPL rights. (As I understand it. Standard disclaimer that I am not a lawyer, etc.)


Creating additional barriers to rights holders to bring suit can only benefit the entity infringing. Why should the rights holder need to promise anything? Release the software under the rights or face termination of the license as they see fit? If you want back in, bring your checkbook.


That really has no bearing here because regardless of who holds the copyright, what they are doing is permissible under the GPL.


This is not the worst of what Red Hat has done.

https://openinventionnetwork.com/ is #1 on my list.

... Why? Because instead of supporting all FOSS systems. It is Linux only. Thus locking the whole patent protection eco-system they created onto Linux, the platform they created.


It is not 'Linux only' like you or I would understand it. They have an extremely broad definition of the 'Linux System' which includes thousands of programs:

https://openinventionnetwork.com/linux-system/


As long as it runs on Linux.


This is nothing new and it's perfectly compliant with GPLv2.


s/RedHat/IBM - Red Hat the name is just a smoke screen now.


IP protection is driven by $$$ and norms.

Non-S&P500 corporations routinely violate open source licenses a myriad of ways.

If you license something as AGPLv3, Amazon, Microsoft and Google, among other S&P500s, will not integrate it into their service offerings.

Sherlocking happens to everyone big and small. If I work at Microsoft and see AppGet and make WinGet, what can the author do?

Microsoft will pay someone to reimplement X in C#, Google in GoLang, Apple in Swift, etc. etc. These aren't clean room implementations, but this is how they can consume code that is valuable to them.

If you have a speculative meeting with Google about working together, they may engage the quota-driven attorney to patent your work anyway (https://patentpandas.org/stories/company-patented-my-idea).

Let's say you contract to do work for Microsoft as a vendor, but you have "background technologies." That's fine, so you own the copyright to the code. If you make something innovative, your partner at Microsoft - some engineer or PM or whatever - will engage their quota-driven attorney to patent it. So even if contract X says you own the copyright to the code, they lie (by omission) and patent anything interesting anyway.

End users reading HN routinely violate copyright, EULAs, etc. I mean they believe in the rights of the author for AI generated art sometimes, do-not-train robots.txts, and then immediately use a paywall bypass or archive.lol to read an article written by a real human being. They complain about giant corporations violating these GPL provisions and then they go and pirate a video game, a movie, an anime, etc.

What is the cultural norm for stuff you put out there for the public on the Internet? It seems to be, tough cookie! If you purposefully put your stuff on the Internet (as opposed to someone buying something off X and pirating it), you've conceded: "If you have more money than me and if you never want to work with me again, I guess you can do whatever the hell you want."

There's an IP law crisis. We've totally abrogated IP law to capitalism. HN is part of the problem, people talking about laws, contracts, etc. that they themselves were routinely violate from Napster to What.cd, ad blockers, paywall bypassing like Archive.lol, etc. HN users excuse themselves just because the law says one thing, but is unenforceable unless you have a ton of money or something the counterparty has to lose, so you're going to do the norm, you're going to do the thing that you like that makes sense to you.

Nobody forces you to use RHEL or Rocky Linux. You can simply ignore this whole drama in this particular product category. But eventually, the giant corporations will simply copy your code and use it, and even if you have an open and shut case, you won't be able to afford a lawyer, you'll have to go beg. You'll get represented by the Berkman center for free, and you'll still lose. Something's gotta change.


I generally just use MIT and don't care about what others do with my code.

But for a more commercial project I'd probably use a dual license, AGPL + commercial license. Kind of like Qt.


I wholeheartedly agree with the IP crisis.

Maybe we are seeing that, in the end of the day, who was indirectly paying for open source was the government by offering low interest rates so companies could have some space to spare developers?

Why the Open Source is in crisis right now if thats not the case?


"It violates the spirit of the open source software movement"

Says a person promoting open core. I have little interest in hearing lectures about the spirit of open source from open core proponents. None, actually.

There are definitely folks who have standing to talk about Red Hat's decisions around distributing GPL'ed code, but if you're out there promoting open core or primarily make your money with proprietary code, you're not in that group.


Even broken clocks are right twice a day (once if on 24 hour time)


Live by the sword, die by the sword.


> I have little interest in hearing lectures about the spirit of open source from open core proponents. None, actually.

I maintain an open source project.

I'd like to lecture you on how Red Hat is violating the spirit of the open source software movement.

How's Tuesday work for you?


If you wanna swing round and buy the beer, go for it. Or Scotch. I'm partial to a good Scotch.


Reread that sentence again. Particularly the words "from open core proponents"


Just add a redhat clause to it :p

Bit like Facebook just did with Llama

>Meta will open source LLaMa 2, enabling developers to access it freely, with a license requirement for companies with 700 million MAUs.


You know, they could use utility tokens as a way to monetize open source software. Have they looked into it?

In order to do that, they would have to use a strong network effect to lock in their audience and make it more costly to fork the whole ecosystem than just keep paying for the utility.

What is the alternative? Everyone who is silently downvoting — I would LOVE to hear a viable alternative.


(Note: I am engaging in good faith. I'm not arguing against utility tokens, I'm just not sure I get how they're applicable) I read your sibling comment and I'm still not sure I get this:

> they could use utility tokens as a way to monetize open source software

First, who is "they" in this context? RedHat?

> use a strong network effect to lock in their audience and make it more costly to fork the whole ecosystem than just keep paying for the utility

> Maybe -- like in the case of RHEL - it's licensing fees.

I'm trying to parse this and I'm just not following. What's the "monetize open source" business model here with utility tokens? RedHat's current business model is:

"Set up a contract where businesses pay money every month, in exchange for access to RHEL builds and technical support, whether or not they use that tech support in a given month."

I think I conceptually get what a "utility token" is from having a skim through the QBUX site, but... I don't really get how it would change things in this case, other than likely making it more difficult for people to pay for RHEL subscriptions?

> What is the alternative? Everyone who is silently downvoting — I would LOVE to hear a viable alternative.

I think the trick is that the viable alternative is the status quo. You haven't really explained how this would lead to RedHat making more money every month than how they're doing business currently.


But aren't people complaining about the status quo, and RedHat infringing on open source rights?

With the utility tokens approach, they wouldn't need to restrict those rights. I guess that's the point. Whether the people are complaining about Google, Apple, Reddit, Twitter or any number of corporations, it's like, they have no solutions other than 1) complaining, 2) complaining to the government, but regardless of that, anything related to Web3 is dismissed out of hand, leaving no viable alternative solutions at all. I don't think "the status quo" is what people have in mind as a solution when they are complaining.


> But aren't people complaining about the status quo, and RedHat infringing on open source rights?

Yup, people are complaining about the status quo. RedHat may be, in spirit, infringing on the freedoms granted by the GPL, but in practice I would generally bet that RedHat/IBM's lawyers figure that they're not legally doing anything wrong.

If you read between the lines here at who's complaining and what they're complaining about, it's not generally speaking RedHat's paying customers. A few might be but by and large it's people who want to run RHEL-compatible alternatives without buying RedHat's support contracts.

> With the utility tokens approach, they wouldn't need to restrict those rights.

I still don't get what you mean when you say that. Let's say I spin up a corporation called BlueHat. My goal is to make a rock solid, stable, long-term support Linux distribution and provide for-pay technical support for clients. I also want to make a healthy profit while doing so. How would that work with utility tokens? Is there something I'm missing where a utility token would make it feasible to share the complete source and build instructions for the distribution I'm putting together while still having enough revenue to pay everyone every two weeks and have some left over to take home and buy food with?

Edit:

> anything related to Web3 is dismissed out of hand

I am, honest to God, not at all trying to dismiss this. I'm trying to understand how I would set up a business model similar to RedHat within this kind of framework. Developers and techs that I hand-select and hire to provide an OS distribution that we control and provide paid support for, while all of us making enough money to pay our mortgages and buy food every two weeks.


Well, I don't have all the answers for every industry, but the broad strokes as what I said. Utility tokens really only work when you need services of other people in a network, often requested and delivered over a network. They aren't really as useful for software that you can run locally on your computer. So, for example, hosting RedHat software on an Amazon instance, RedHat can work with Amazon to make sure it enforces licensing fees. If Amazon doesn't then RedHat can, theoretically, sue the company or pull its licensing for any further instances, hurting both companies.

But RedHat could launch a new product line centering around servers running their machines, "commoditizing their complements", and doing jobs. Kind of like Adobe turned to SaaS instead of software running on your computer. Or how wordpress.com makes the bulk of the money for Automattic instead of self-hosted Wordpress. They'd have to start managing infrastructure, basically, or partner with Amazon as they already do.

I guess my overall point is that more software should be funded in the beginning using utility tokens, so they never get a big shareholder class and thus never have to go IPO to generate a return. Thus they never have to impress investors on Wall Street earnings calls, by how many rents they've extracted from their ecosystem via greater enshittification.


Ahhh ok, I think that's where the wires got crossed. From your original post, I got the impression that you were suggesting that somehow RedHat's existing business model could be converted to using utility tokens and allow them to freely redistribute all of their RPM sources and build scripts without having their OS distribution cloned.

I suppose my last question, having flipped around through the Qbix site a fair bit and grokking a bunch of the concepts of how it all fits together... I think I get how Qbux move around the network and get distributed to software authors, but how do I convert Qbux into food and rent? Is the expectation that there'll be some kind of exchange set up where I'd periodically auction off my accumulated Qbux?


You're name-dropping utility tokens as if we know what those are but we don't. Somebody needs to explain exactly how these utility tokens would work before we'll take them seriously.


A utility token is a decentralized token you pay to a provider in order to do a service for you. Maybe it's hosting. Maybe it's manual work. Maybe it's AI credits. Maybe -- like in the case of RHEL - it's licensing fees. Think about it like the API credits and quotas that you are given by an API provider, except more decentralized.

You can use trustlines to make it a lot more scalable, meaning the provider only closes out the trustline and posts it to the blockchain to collect the tokens, once in a while, not on every micropayment.

Here is an example: https://qbix.com/ecosystem




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: