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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Part of the confusion I find is he’s trying to make a tech joke using something inherently non-technical, states’ names.
I think the joke would have been better and more understandable if it had used different corporate names rather than states. But, of course, that might have been legally problematic.
And the WARN Act.
I’ve done both. I wrote my own scripts to generate the WG config files to handle variations in configure I needed to make for my different networks (masking, IPv6, cross multiple WG networks).
After converting to Tailscale, WG is just an extra level of hassle I can now easily avoid.
Use Tailscale. Much easier to configure and manage than raw WireGuard.
Like IT gives you any time to get anything off a corporate-owned device.
When I got laid off, IT sent a bullet to my laptop immediately kicking me off and completely locking me out of it.
I was supposed to have another 4 days to transition my work. I contacted IT and was told once the bullet goes out, that’s it. Any and all access to everything has been terminated. Might as well just go home and enjoy the extra 4 days because no one’s going to undo a bullet going off early unless it comes from the C-suite. So I did.
Unless Gitlab changed things very recently, you only needed to provide a CC/DC if you wanted the free CI/CD pipeline enabled for your projects. Decline, and everything except the free pipeline works just fine.
A 1979 TV show about a guy who put together a junk spaceship to salvage junk from the moon: Salvage 1.
My teenage self found it entertaining at the time. Hmmm, now where did I leave my parrot? I wonder if he could help me find a copy…
All of them. Corp directive (now) is that hosts must be updated or reimaged every 90 days.
I used to use that approach, but found in the last several years more than half the web sites I use reject email addresses with “+” characters.
I even use several sites that used to take those addresses just fine now reject them. That made me wonder if some common JS package for parsing email addresses got changed.