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