They are violating section 6 of the GPLv2 by adding further restrictions.
But ignoring that, I haven’t heard anyone discussing what could happen once this anti-GPL angle goes beyond Red Hat. What’s going to happen once internet connected IoT devices or say a company like Tesla pull the same technique. If Tesla kills your account for any reason, you lose all your paid for services and your car becomes a brick.
I’d rather have an M.2 connector without requiring a HAT.
I’ll stick with my Orange Pi 5 for now which comes with one, tyvm.
At my company, we have around 400,000 servers in production. When we last surveyed them, we found several thousand over 12 years old, with the oldest at 17 years. And that wasn’t counting our lab and admin servers which could run even older because they’re often repurposed from prod decomms.
We had a huge internal effort to virtualize their loads, but in the end, only about 15% were transferred just due to the sheer number of hidden edge cases that kept turning up.
I think they’re trying to simplify the exposed interfaces simplifying everyone else’s job at the expense of making a more complex implementation.
No, I am no “free” to do whatever I want. I want to distribute that source is strictly allowed under the GPL, but then RH penalizes me for exercising that right by terminating that account. That’s a restriction. How is being penalized for doing what I’m allowed to do not a restriction?
How about yet another angle for you. For example, I download and distribute the source RPM for gcc for the version running on my box. RH terminates my account. Now I want to download and distribute the source RPM for the kernel running on my box. How do I do that with a terminated account?
I must be ancient then. I recognized, and I think used, all of those cards/chips.
Some personally. Some at work. At work I used to maintain and MS-DOS / early Windows graphics program. I had to test the program’s compatibility with a stack of graphics cards.
I've written hundreds (thousands?) of GNU Makefiles over the past 30 years and never had a need to unconditionally run particular targets before all others. GNU Make utility is a rule-based language. I'd suggest what you're attempting to do is enforce an imperative programming language model onto a rule-based programming language model, which you're going to run into trouble trying to code in a different language model than the tool's native model.
Can you provide what you mean by check the environment, and why you'd need to do that before anything else?
For example, in the past I've want to determine if and which particular command was installed, so I have near the top of my Makefile:
container_command_defaults = podman docker
container_command_default_paths := $(shell command -v $(container_command_defaults))
ifndef container_command
container_command = $(firstword $(container_command_default_paths))
ifeq ($(container_command),)
$(error You must have docker or podman installed)
endif
endif
Using the := operator with $(shell ...) is a way to run a command while GNU Make is initially parsing your Makefile. Normally, using := assignment operator is antithetical to a rule-based language, so you want to limit its use as much as possible, but unusual exceptions can exist.
I'm also unclear what you mean by "ensure variables are set". What kind of variables?
The above snippet shows how you can check if a makefile variable is set when the Makefile is first parsed, if not, declare an error and exit. (The same approach works for environment variables too.)
Preparing a particular layout ahead of time is not the best approach. I'd suggest a given layout is nothing more than dependencies that should be declared as such.
Also, running specific targets or rules unconditionally can lead to trouble later as your Makefile grows up. You may eventually have additional targets that say provide information about the build's state or run checks or tests. You wouldn't want those targets necessarily to go off and build an entire tree of directories for you or take other unnecessary actions.
If you want to ensure certain directories are present, add those as dependencies for those targets with the | character. For example:
build_directory ?= build
build_make = $(MAKE) ...
targets = ...
all: FORCE | $(build_directory)
$(build_make) $(targets)
$(build_directory):
mkdir -p -- '$@'
Even though I've been writing GNU Makefiles for decades, I still am learning new stuff constantly, so if someone has better, different ways, I'm certainly up for studying them.
As far as I understand, this discussion is still theoretical because Red Hat has not terminated anyone's subscription or account yet due to distributing GPL'd source to a Red Hat product, so everything's an assumption until it happens. Do you know if they have that has been publicly disclosed?
And guess what, they will give it to you.
Have they explained how they will do that after terminating my subscription?
I offered some alternative methods to how Red Hat could be GPL compliant. As far as I know, they have not disclosed such a process that meets the terms of the GPL.
They do not restrict your rights in any way with regards to the software they have already given you.
By terminating access to the source for GPL'd software I've already installed, yes, they have, unless they/you can clarify how they will still allow me to access the matching, buildable source for the binary packages I've already installed on my system.
Normally, I would download the matching source for a package via the dnf or other related tools, but they won't work if my RHEL subscription or account is terminated. I would like to hear this new method. I offered a couple under my earlier post as possible examples.
Anyway, that's inconsequential. By applying any additional restrictions when exercising the GPL granted rights, this violates the GPL. Those restrictions don't have to be on the rights themselves, they just have to come into effect when the rights granted by the GPL are exercised, which in this case, they do.
As quoted earlier, GPLv2 section 6 states, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." It does not say, "You may not impose any further restrictions on the rights granted herein." It's not the rights themselves, but the mere exercise of those rights. As I mentioned before, what good is a right to vote if additional restrictions can be included such as paying a fine or tax? This is what section 6 is meant to prevent others from doing.
A cancelled subscription does not cause me to lose access to the software that has been distributed to me or to any of the rights and freedoms as stated in the licenses ( GPL and otherwise ) for the software that Red Hat has distributed to me.
You keep saying that, but not mentioning how. Would you please clarify for me how I access the buildable source for the exact version and release of a package I have already installed on my system post-termination of my subscription? Maybe I have missed this in Red Hat's publications on this matter?
The subscription is not a software license, it is a contract.
It is a contract that includes licenses that are part of it, so I'm not sure of your point here?
Contract law comes into effect here. And fulfilling or breaking the terms of the licenses included as part of the contract are also in play.
As mentioned, there are certainly ways for Red Hat to terminate aspects of the RHEL support agreement that would comply with the GPL. I certainly accept Red Hat has the rights to terminate future access to newer versions of binaries or sources covered by the GPL. There are ways for them to do that without violating the GPL, and I would like to see them do that, but so far I've not seen how they will comply.
RHEL itself is not licensed under the GPL and so the whole premise is wrong on its face. The subscription agreement is for RHEL itself.
But components of RHEL are licensed under the GPL. The subscription agreement in part is how Red Hat fulfills the terms of the GPL for those components, so could you clarify the point of your statement?
If the RHEL software under the GPL did not rely on a working subscription for fulfilling GPL terms, then that would decouple the RHEL subscription from the GPL and covered components, but I have not seen a description yet of how Red Hat will do that.
Thank you for replying. I've had these points and questions for some time, but I have not seen a good rebuttal from someone GPL knowledgeable with Red Hat's position. If you can clarify and answer the points above, that would help.
To say that restrictions also include the consequences of doing some thing (e.g. you receive no further binaries) implies to me that the definition would be completely up to the user.
I would say it's up to a court, not a user, to decide whether or not in the context contract law if those "consequences" are also "restrictions".
Contract law is all about defining actions and the consequences of what happens when those actions are taken or not taken. What's the point of having a granted right if I can't exercise it without a significant, immediate, and direct penalty imposed by the grantor? I would say that's no longer a right.
Section 6 is not just about a grantor taking away any of the four rights, but also about stopping the grantor imposing any further restrictions on the exercise of those rights granted by the GPL. Otherwise, if section 6 was just to protect those four rights by themselves, why wouldn't it just simply say, "The rights granted herein to the recipients, all or in part, may not be revoked under any conditions by the licensor."?
If the language of section 6 were the above alternative, I'd certainly be taking your position. But RH isn't revoking those rights, they are attempting to restrict the exercise of them using penalties, what I believe section 6 is directly trying to prevent. As I mentioned elsewhere, those penalties go way beyond just disabling access to potential future versions of software packages and their matching source. (If that were just the case, I'd also be inclined to agree with your position that losing potential future access by itself would arguably not be a restriction.)
This seems rife with ambiguouity, which from my understanding would not work well in court. In contrast, “ability to copy/distribute/modify this snapshot of code regardless of what happens afterwards” remains a guarantee.
I would say its ambiguous to us (without legal training), but I'd bet the language used in the GPL license is pretty clear to a contract lawyer and would have some legal precedence as well. Lawyers tend to avoid using words and phrases without established precedence behind them.
Back in 1990-1991, I was working for a company that was unhappy shipping its commercial software compiled with GCC under the language of the GPLv1. I was on the team (engineering side) that worked with RMS and his legal team to craft the GPLv2 and LGPL as replacements for the GPLv1 that eventually made everyone involved happy. I wasn't directly involved, but was on the periphery and got to see a lot of the proposed language and reasoning behind it being raised and discussed on both sides. Unfortunately, I don't remember any of it after all this time. But I do remember just how much effort went into practically every word that was (and was not) in that license. That experience though led me to being a GPL supporter for the last 30 years.
I don’t see any loopholes that would violate the four freedoms. At no point would you be unable to copy, distribute, or modify code for the binaries that you have. [...] I thought you’d still have access to the source for the binaries on your box, just that you couldn’t ask for the source of newer binaries since they would have already stopped supplying those. I could also be misunderstanding how Red Hat’s systems work.
Yes, that's a problem. Without your now deleted account, you would lose access the matching source. With RH systems, you have to have a valid, authorized, and logged-in RH account to access the source for a given installed binary package.
As mentioned elsewhere, RH could plug this problem by offering to allow you to request the source for those packages outside of the normal channels such as a charged service for mailing you a DVD or USB stick. But as far as I know, they have not offered this service, hence a GPL violation with their current approach of cancelling your account.
I don’t see any loopholes that would violate the four freedoms. At no point would you be unable to copy, distribute, or modify code for the binaries that you have.
It's not just the four freedoms the GPL protects, but the exercise of them. Maybe there's a chance I've convinced you a little more of the position I have. :) At least I hope you more clearly see it.
Thanks, I appreciate your insights. Was surprised that it’s not new from Red Hat.
And for yours as well.
IBM deserves a lot of blame for a lot of things, but on this one issue, they don't.
Not what they did on the surface (limiting source to only customers). That’s allowed by the GPL. But they went beyond that which imo makes them non-compliant.
RH will cancel your access/agreement if you share the GPL’d source with others. That’s directly forbidden by section 6 of the GPLv2. RH is free to cancel your agreement when they want, but not because you exercised your rights under the GPL.
Once your agreement is canceled, you also lose access to the matching source for other GPL’d packages installed on your system. RH could offer other methods to be in compliance, but as far as I know, they have not.
I would say that cancelling your subscription is a direct violation of the GPL for two reasons.
For example, say I'm someone who installed RHEL under a subscription. I downloaded the source to the kernel then distributed the SRPM to others leading Red Hat to cancel my subscription/account.
With a cancelled subscription/account, how do I now access the buildable source for say the GCC package I have installed on my system as guaranteed under the GPL?
If Red Hat didn't cancel my subscription/account, but restricted it to only accessing the matching source downloads for the packages on my system, that would be compliant. But they didn't. They killed all my access for matching source which is non-compliant.
If Red Hat provided a service where I could request buildable copies of the source for the packages I have installed , this would be compliant. But as far as I know, they have not.
Cancelling my subscription/account is a violation of Section 6 of the GPLv2 which states, " You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
This clause is to ensure you can freely exercise your rights granted by the GPLv2. Cancelling your subscription/account for no reason other than exercising your rights is a direct violation.
For example, I have the right to vote. If a government body imposes a hefty fine or tax if I attempted to vote, this would be considered further restrictions on my right to vote. This is what Red Hat has done.
Red Hat is certainly free to cancel your subscription/account under the terms of their license, but not when it conflicts with the exercise of rights granted under the GPL.
M.2 is a serious win. That’s why I couldn’t believe the RPi5 didn’t include one natively.
I have a mix of Orange and Raspberry Pis. It all depends on their features, specs, and price point for the job. But if I don’t need a HAT, Orange usually wins out.
And the WARN Act.
They only said “free to do whatever you want with the source code provided for the binaries they distributed to you”, which is true? You wouldn’t be receiving any further binaries that would require releasing code to you, and you’d still be able to copy/distribute/modify the code that you got up until that point.
I would still assert that having contractual penalties for a behavior granted elsewhere is no longer free, hence a "restriction". But this is where I'd love to hear a lawyer's position. "Common sense" and "legal sense" can often be in conflict.
I'm aware I'd be restricted from future binary updates. But my point goes to what the legal definition of what a "restriction" is in this context. The language in this sentence to me is plain, "You may not impose any further restrictions on the recipients’ exercise of the rights granted herein." RH is attempting to limit my behavior by imposing contractual penalties for exercising rights granted under the GPL. Those penalties being imposed are not just restricting access to future binary updates, but forfeiting all current granted privileges and monies already paid under contract, and the termination of that contract. I would consider that a "restriction", but IANAL either.
I would say RH's behavior goes to this GPL FAQ. I would assert that RH's new contract is certainly a "more restrictive basis", but I'd love to hear from an IP/contract lawyer that is familiar with the GPL on this issue.
I would think what RH wants to do with this change would be perfectly fine if they just chose just to let the existing contract with the customer run out without renewal, and not make any changes of terms until expiration, but terminating their contract and the terms granted therein is a restriction, and I suspect will run them afoul in court.
Again, I'd love to hear from a IP/contract lawyer. I've interacted with numerous ones over the years on our RHEL support contract renewals and on a patent litigation case as my company's lead engineer (sucking up two years of my career), and my impression is just that.
As mentioned above, you’d be perfectly able to redistribute the code associated with the binaries already provided to you. Once your account is terminated, you’d no longer have access to the binaries that you could request the code for.
I'm not sure you said here what you mean to? I certainly still have access to the binaries I already downloaded. After all, they're still running on my box! And also under the RHEL contract (old or new), I'm still able to run those binaries indefinitely. But that means I'm also still entitled to the source from RH for those installed binaries since they were originally distributed and installed by RH under the terms of the GPL.
Of course to "work around this", RH could put all sorts of hoops in the way of requesting them via some alternative, manual method and then charging a fee for them. A long time ago, I used to work for a company that charged $250 for a copy of our GPL'd code for each product, and after 6 weeks to fulfill the request, would U.S. mail it to the customer on a QIC tape. I'm curious to see how RH fulfills this aspect of the GPL post-termination.
BTW, this change in the RHEL contract is nothing new. A different company had worked for used to have an 8-figure RHEL support contract, and I was their point of contact with our TAM. Thirteen years ago, we were considering a ELS (Extended Lifecycle Support) contract for RHEL which had a version of this new language in it way back then, so I ended up discussing this issue at length with our TAM. He said we'd only get answers to my questions of how the language wasn't a direct violation of section 6 from RH Legal if and only if we'd sign the contract.
But out of all this, my biggest concern of all this by far is the can of worms RH is opening. What's going to happen when other even less scrupulous companies attempt to run with this possible GPL loophole RH is trying to bust open?
You may like an approach I came up with some time ago.
In my included file that's common among my Makefiles:
# Ensure the macro named is set to a non-empty value.
varchk_call = $(if $($(1)),,$(error $(1) is not set from calling environment))
# Ensure all the macros named in the list are set to a non-empty value.
varchklist_call = $(foreach v,$(1),$(call varchk_call,$v))
At the top of a Makefile that I want to ensure certain variables are set before it runs:
$(call varchklist_call,\
INSTDIR \
PACKAGE \
RELEASE \
VERSION)
I usually do these checks in sub-Makefiles to ensure someone didn't break the top level Makefile by not passing down a required macro.
All of them. Corp directive (now) is that hosts must be updated or reimaged every 90 days.
The GPL only cares about ensuring the four freedoms are maintained for binaries and their related sources.
No, the GPL goes beyond that. It not only ensures those four freedoms, but also ensures the freedom to exercise them without restriction. That's what the language in section 6 is meant to protect. If RH only limited potential access to future releases of binaries, I see that as fine and not a restriction. But RH is going well beyond that by terminating existing contracts; accounts; technical, web, and support access; and not refunding monies paid in advance for those services. (Theoretically, since they haven't done it to anyone yet that I'm aware of.) If legally those actions are not deemed a "restriction", then I'd agree with you.
To solve your DRY problem, you may not realize that you can generate target rules from built-in functions eval and foreach and a user-defined new-line macro. Think of it like a preprocessor step.
For example:
# This defines a new-line macro. It must have two blank lines.
define nl
endef
# Generate two rules for ansible playbooks:
$(eval $(foreach v,1 2,\
.PHONY : ansible.run-playbook$v $(nl)\
\
ansible.run-playbook$v : ensure-variables cleanup-residue | $$(ansible.venv)$(nl)\
ansible.run-playbook$v :;\
... $(nl)\
))
I winged it a bit for you, but hopefully I got it right, or at least right enough you get what I'm doing with this technique.
Again, less than half of RHEL is even software released under the GPL.
I would be completely shocked if this were true. I'm calling BS here.
I used to be my company's primary contact for our Red Hat TAM for almost 13 years. Our TAMs were very proud to claim that all of RHEL was FOSS software, licensed under the GPL or sometimes other FOSS licenses.
I spun up a RHEL 9.2 instance and ran:
$ sudo dnf list --all | wc -l
6671
$ dnf info --all | grep "^License .*:.*GPL.*" | wc -l
4344
$ python -c "print(4344/6673 * 100)"
65.11767351221705
So 65% of RHEL 9's packages are under a GPL license.
Much of the software that is GPL was authored by Red Hat themselves. According to the text of the GPL itself, Red Hat is not required to distribute the code to the totality of the RHEL distribution or even to more than half the code.
Half?!? Again, where are these mysterious numbers coming from?
It doesn't matter if Red Hat authored those packages or not. What matters is if they were distributed under a GPL license. If you're claiming that Red Hat multi-licensed those GPL'd packages that they exclusively wrote so they don't have to comply with the GPL, please point those out to me (or at least a few), so I can check them out.
If they can have someone program a fee in their accounting systems, that means they know exactly what that the fee is and under what conditions it’s applicable. It’s trivial from there to sort, filter, and list them.