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.

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.

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

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?

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?

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.

Since being forced to use this terrible communication method in my teams and groups, I’ve been copy-and-pasting good Q&A threads into text files that I push to an enterprise GitHub repo for perma-store. At least that way other engineers and myself can either use GitHub’s search or clone the repo locally, grep it, and even contribute back with PRs. Sometimes from there, turn into a wiki, but that’s pretty rare. My approach is horribly inefficient and so much stuff is still lost, but it’s better than Discord’s search or dealing with Confluence.