Cray/HPE, presumably, has a contract to provide support to the customer with nuclear weapons. If this fix is necessary to that contract, Cray/HPE should set the bounty needed to get it done as part of the necessary cost of fulfilling their contract (if they didn't figure it in, and it's not a cost-plus contract, and it cuts into the profit margin, well, that's the risk you take with fixed-cost contracting.) Free Software may often tend to be free-as-in-beer as well as free-as-in-speech but, where it is, that is as is. If you have special, and especially time-sensitive, needs that aren't as is, you pay someone to do it. It's not a gratis support contract with response time guarantees. As Cray/HPE ought to be well aware, that kind of support is expensive, and doesn't happen if no one is paying.
This feels like the log4j conversation all over again. Cray/HPE knows what the problem is, and they know the developers aren't being paid to fix the bug, the customer is hounding them, not the original developers. This is their problem to solve, they don't get to pretend that it's someone else's fault that they're too cheap to shell out the money for proper maintenance.
If this was a bug in Cray/HPE's own internal software, they would pay a developer to fix it. It's wild as a company to assume that because you're using someone else's stuff for free, your responsibility for maintenance is now their problem as well.
> Hi Bill, per our operational security procedure we can't talk about ieee_arithmetic, especially when we dont get paid.
Good on the developers for saying this. You support people, or you don't get to tell them what to do. And if you're a commercial company taking on a contract that involves nuclear weapons, maybe you devote some resources to making that contract and the software running well, because that's what the client is paying you to do.
So sick and tired of the backwards mentality that giving something away to the world for free means that you now have an additional obligation to fix everyone else's problems for free. The "as is" clauses in Open Source licenses are there for a reason.
Yup, and there's nothing saying Cray, or [customer w/nuclear weapons], or anyone else is required to use that OS package. Perhaps they would have been better off writing their own in this instance.
Or, better yet, they could write a fix and add it to the OS package (kind of the way it's supposed to work - the set of users maintain it so everyone benefits?).
> So sick and tired of the backwards mentality that giving something away to the world for free means that you now have an additional obligation to fix everyone else's problems for free. The "as is" clauses in Open Source licenses are there for a reason.
That's one of the differences between coders and engineers.
Coders just import libraries to avoid re-inventing the wheel. Engineers consider each import as a dependency they'll have to maintain, buy support for or replace. Log4j just highlighted this difference, with some knowing exactly what to patch and others franctically trying to determine if one of the thousands of dependencies they imported into their app actually used it.
Can the theatricality bill, nobody on the GCC bug tracker but you cares if the country that spent two trillion dollars to replace the Taliban in twenty years with the Taliban doesn't seem to have they acumen to fund something they're now critically dependent upon. They can barely get it in gear to fund their own budget each year without a partisan meltdown.
If they could do any of this themselves, you'd be on the golf course.
The customer could easily be Russia, U.K., China, France, India, Pakistan, or some other country with nuclear weapons. Not North Korea, though, because Cray/HPE probably can't do business with North Korea.
NERSC is part of DOE’s Office of Science. Nuclear weapon development is done by DOE’s National Nuclear Security Administration (NNSA), which sponsors labs like Lawrence Livermore and Los Alamos. It definitely isn’t NERSC, NNSA has its own dedicated supercomputers for weapons work.
I very highly doubt France would work with Cray/HPE, or any non-French contractor for that matter, on this. As far as I'm aware, they're working with Bull (now part of Atos).
> I very highly doubt France would work with Cray/HPE, or any non-French contractor for that matter, on this.
If the customer was the Government of France, the line “the customer has nuclear weapons” would be factually accurate irrespective of whether the particular work was on, or even remotely related to, nuclear weapons.
It might not be relevant, but then, even if the work is on a nuclear weapons program, “the customer has nuclear weapons” doesn’t seem relevant to the discussion. Really, short of the case where the customer prefers to motivate software developers with the threat of nuclear annihilation rather than feature bounties, it seems a complete non-sequitur no matter what the work is.
They’re not making a threat. They’re saying it’s important to an org that has thermonuclear weapons. Those people are a very unhumorous lot, and they would not grok why these little libs people would not understand that.
They are obviously not the masters of the domain they think they are, but that happens sometimes in bureaucracies.
According to Bill Long's linkedin page he has ~25 years Fortran experience and holds "principal member" status on a Fortran committee for much of those. Describes himself as a "master" engineer.
Someone with that level of experience and recognition should be capable of either implementing the function themselves, or at the very least have the professional network to know a number of people capable of doing so for HPE.
I would also expect significantly more tact and professionalism.
The email record screams "BOFH bench warmer."
Edit: the more I think about this, the more I think he probably sold himself to HPE as being able to give them what they want from FORTRAN due to his committee membership. Which turned out to not be true, thus placing his salary at risk.
Cray has their own Fortran compiler, so it's quite possible that Bill is forbidden from contributing to other Fortran compilers due to IP issues.
And as you can see from the thread, he's caught in the middle, passing messages between a customer who wants this issue fixed and a team that doesn't want to fix it. That's not a fun place to be - you basically get yelled at by both sides.
The only reason "ip issues" exist is because an employer says so, and they can say otherwise at any time.
If the customer wants something, then you the vendor either give them what they want, or don't.
It's no one else's problem.
There are no "ip issues" preventing an employee from working on a competing product, only from doing so without permission which the employer is free to grant at any time.
This possible issue does not provide any tiniest bit of of excuse, and does not invalidate the critiques at all.
No one is "caught in the middle" in any way that anyone else has any obligation to care about, not even a merely "being a nice and considerate person" obligation.
If the customer wants something, the vendor can absolutely satisfy them any time they want by a number of different means. And certainly this employee is no voiceless intern, is both knowledgeable and empowered enough to inform his employer about those means. If they don't employ any of those means, it's no one else's fault and so no one else's problem.
Well, as a "master engineer" with 25 years of experience, maybe he should just fix it himself instead of expecting unpaid volunteers to jump for him just because he's doing work for the government.
As the bug thread mentions, Bill is paid to work on Cray Fortran. It looks like the issue is that cray is using gfortran (and others) as a regression test suite, and found a bug. Possibly one that surfaced after cray fixed their own similar bug?
But more to the point, the Feds don't hand out cash without a procurement order. In theory USDS can help unblock that, but I doubt they get engaged in clearance required projects.
This is extremely polite while still being direct, I really like things like this.
It makes clear that there is a way they can help, with enough attitude to make clear that the other person is dealing with individuals rather than some magic free subcontractor.
Ah, I disagree. Saying "F2018 conformance will be fixed" implies that the GCC acknowledges "F2018 conformance" is a thing that needs to worked be on and not just a ruse by Bill to get free work done.
The maintainers responded well: they ignored Bill's weird framing and countered his entitlement politely.
Can't really argue with that, I found the actual responses very polite as well. I absolutely criticize nothing.
I don't think "F2018 conformance will be fixed faster if..." implies that there is any actual timeline at all, especially to the presumed target audience. Maybe that's what I'm seeing, that phrasing to me means WONTFIX unless the other party takes some kind of action.
The reason I like it is because it actually specifies what the other party can do to take action without calling them out. Calling them out is still certainly entirely fine. But if the goal is to get a purchase order issued from a negotiation perspective I think it makes sense to basically say "sure, we're willing to work on this seriously if you contribute", which then turns obviously to "I don't code" or "here's your patch", which then obviously turns to them contributing one way or another.
Patience and personal morale justifies a lot though IMO, the maintainers are of course under no obligation to care about any of that one bit, Bill could always have just patched the code and not worried about upstream. Embarrassing.
Beggers are anyone begging, whether a true "poor person" or a rich person wanting a hand out when he can afford the free thing himself, probably without batting an eye.
I think it's just the sad state of the corporate structure at the moment. If a manager requested and got a budget to fix said bug to his superiors, it's his ass that's on the line if things don't work as planned. If same manager said "it's not our fault things don't work" nothing happens to him. Hopefully when the current generation of managers gets replaced they'll be replaced by those that actually understand FOSS and can incentivize fixing these issues. But as it stands everyone, including the shareholders of these big companies, suffer from poorly designed corporate incentives that let FOSS projects stay unmaintained.
The fix can't be necessary because the original report included examples of it working using Intel Fortran and Cray Fortran. So there's an alternative. Also, if the contract specified GNU Fortran, then they would just do it and bill the customer.
My guess is that the customer here is asking because of a mandate to prefer open source solutions wherever possible.
> My guess is that the customer here is asking because of a mandate to prefer open source solutions wherever possible.
I don't think that HPC or the DoE have anything close to such a mandate. My guess is that the request comes from a a user who wants to try compiling their code with gfortran.
Yeah I bet they are being paid well for that contract as well. Maybe they should have bought a commercial fortran if they didn't want the possibility that the developers would tell them to go pound sand (but in a nice way). I'm sure they have the resources to fix it and submit the patch back to gfortran.
If the customer has nuclear weapons, then the customer has magnitudes more money in their couch cushions than would be required to pay to have this functionality implemented. For that matter, they’re probably paying Bill Long’s employer some significant chunk of change, and it would be easy for them to offer to pay for this functionality. But it’s free/oss software, so let’s just keep bugging the maintainers instead.
I wouldn’t because I know better but if I’m reading the tone of the comment correctly I would seriously consider responding “you have nuclear weapons? Great. Fuck off”. Again, don’t say that, but you’re right that they should either bounty it or do the damn patch themselves.
In practice it's also very likely that customer mind boggling amount of bureaucracy, allocating extra penny might require approval from several committees.
That's Cray/HPE's problem then. And if they can't fund bugfixes, maybe they shouldn't be in the business providing support for operations that handle nuclear weapons. And if their client can't allocate funds to keep the software they use secure, maybe they also shouldn't be working with nuclear weapons.
We keep coming up with excuses for why companies can't give Open Source projects money, and they all seem to boil down to: "companies are systemically unable to make secure/stable products, can't adapt to emergencies or pay for fixes even when it's the obviously most efficient way to get the fixes in, and because of that these companies shouldn't be in charge of anything dangerous or important."
Which is maybe not the conclusion those companies would want us to draw, but it seems to be what they're suggesting whenever they hide behind crippling bureaucracy like that somehow makes the situation better instead of worse. It's really irresponsible for Cray/HPE to take on a paid contract like this if they can't handle the job requirements.
What's more likely is that HPE/Cray have so much padding in the contract that paying someone $200/hour to implement the function and appropriate tests and it would be a rounding error on the contract.
I think they would do that, except Mr. Master Engineer with 25 years FORTRAN experience and 20 years as a principal member of a FORTRAN committee would have to explain to his employers why he can't handle this himself.
Either that or he sold himself to HPE as being able to throw his weight around because of his committee membership ("hire me and you'll get what you want from FORTRAN"), and we're seeing narcissistic entitlement when it turns out that's not the case and now his job is at risk.
That's Cray's problem. They're getting money from this customer, and they should be the ones ponying up the money from that contract to cover the development of the feature.
Very much this. I have worked with UN (ILO and WHO) in Geneva and signing a tiny (< $30k) software development contract required two years of extraterrestrial bureaucracy with an ultimate failure in the end.
All parties involved really wanted that software contract to be implemented and that software was in fact done developing and already in production by the time. We just couldn't.
So I can sort of feel Bill's pain. It looks ridiculous from the outside and even more ridiculous from the inside.
> Very much this. I have worked with UN (ILO and WHO) in Geneva and signing a tiny (< $30k) software development contract required two years of extraterrestrial bureaucracy with an ultimate failure in the end.
Pretty sure you meant extraterritorial, but if you really meant extraterrestrial, that would be VERY cool.
Ah. That's not how I interpreted 'extraterrestrial bureaucracy', which at an extreme suggests a mid-level functionary on the ISS, or at least workflows that involve forms sent in triplicate out to a Mars orbiter and back. ;-)
It’s not just the amount of money but where that money is going is a problem. You see this issue with procurement all the time if it’s a non standard channel you’ll encounter difficulties.
I would guess that the customer paying HPE directly to fix this wouldn’t be an issue but good luck explaining what a bounty is to procurement and with all the restrictions that come with government tenders it’s even more complicated as you have no idea who is the end beneficiary of that payment is so all the due diligence you have to do can’t be done or is far more difficult.
You also don’t get the usual contractural provisions that provide guarantees and protections for what you purchase this way.
I recall buying $50-60k worth of hardware at one of my previous employers, with only 2 signatures required, both of which I was able to obtain within the space of an afternoon.
I’ve made proposals to state universities for $20k software projects that required a vote in the state legislature for approval.
Moved on to other projects until after the next legislative session, and the period after where the bureaucracy makes it all happen, then we actually scheduled a start date that was 3 months later, since that was how long it took to get all the resources back from other projects.
Government isn’t run like a household, nor like a business, nor should it be.
I worked on a product where certain capabilities were implemented as required but there was no requirement to display the information to the customer. We had our own internal displays that we could use to view the information. The customer saw our displays one day and wanted them too. We were not allowed to give it to them.
You guessed it- government contract. Support the warfighter my ass.
All the money in the world but these things still take time. Unnecessarily, but still.
The customer has already paid many more magnitudes of money than the software engineers will ever see, but it has already been spent by the contractor on dividends and execs' mansions.
> The customer has nuclear weapons. They do not do "bounty". :)
Not only is this not funny, it would likely have the unfortunate effect of turning off any of the "very, very, very, few individuals"[0] who might be able to help. The fact that the issue apparently remains open after a year and a half seems to attest to that.
Yeah, that sort of entitlement would throw this issue at the bottom of the priority queue for me. They're lucky they even got a nice workaround kludge posted in the thread. Knowing that probably 3 layers of government contractors are being paid fat stacks to accomplish the task of posting breathless "bump, wen fix?" on the maintainer mailing list is salt in the wound. I would have closed the issue right then and there as a wontfix, personally. We shouldn't enable those sort of attitudes towards volunteers.
Definitely nauseating that "Bill Long" probably gets paid $450 an hour for their time but can't manage to just write the patch themselves or find one of the thousands of programmers in their org to deal with it and submit a fix.
I worked for a large defence contractor and getting approval for anyone to pay for that would have been more difficult than actually learning how to fix it myself and fixing it myself. At which point I would never be allowed to contribute the fix back to the original project due to the no code export policy and airgapped network.
I could of course have done a clean room patch at home based on my retained knowledge but quite frankly I probably couldn’t be assed with it by the time I’d got home and eaten dinner due to the depression of working in such a horrible place.
- It's pretty doable to get someone's hours for this, especially within the contractor or one of their DC buddies: there's already a customer and a contractor, and presumably, some sort of purchase vehicle & contract. The words "senior", "support", and "fee" are probably in there in multiple places.
- By (backwards) design, it is much harder for a truly expert OSS dev not in the contractor circle, and even harder, an OSS product org offering maintenance contracts for events like this
- The middle ground becomes sales/lobby-heavy orgs like IBM/RedHat, which introduces another multi-layer technical & political world of pain. I haven't worked with Cray (discussed in the thread), so no comment there. But as seen, we're seeing a chain of well-funded stakeholders being fine with not supporting for a prolonged period, which is cultural red flags.
From 1st hand experience there’s a lot of (IMHO) confusion in these sorts of organizations between maintenance and new features driving this kind of entitlement.
> At which point I would never be allowed to contribute the fix back to the original project due to the no code export policy and airgapped network.
I mean, presumably what you'd be getting approval to do is to take PTO to do the work off-hours for the upstream project as a volunteer, no?
That's the deal most "open-core upstream maintained in public, enterprise SaaS downstream maintained in private" companies offer: "we'll compensate you for the time you spend volunteering as an engineer/maintainer at the Foundation, shipping the code we depend on."
In such a case, the code would never start as work-for-hire as part of a confidential project; and so would never need to be exported from said confidential project. It'd start life as FOSS code living in your personal GitHub repo fork of the upstream.
Probably wouldn’t work in the end described. The only way to get it in would be to get the maintainers to accept the patch, then wait for redhat to pull it in, then wait for a stable OS release, then wait for the IT guys to approve that release for internal use, then wait for the other IT guys to install it on your nodes.
Every time we had an issue the only option was to literally divert the flow of a river around it in some way.
The positive outcome of this was the sheer amount of outside the box thinking practice genuinely lead to some of us gaining semi elite debugging and hacking skills. My own favourite was writing a tool to frig with the IAT in PE files on windows NT so you could inject a new function to wrap vendor DLL functions so we could patch bugs without involving the vendor.
> I worked for a large defence contractor and getting approval for anyone to pay for that would have been more difficult than actually learning how to fix it myself and fixing it myself. At which point I would never be allowed to contribute the fix back to the original project due to the no code export policy and airgapped network.
Unless your software was write-once, compile-once, 'fixing it myself' includes the time it takes to do the initial fix, add unit tests for it, and also the time it takes to patch that fix into every future version of GCC you use - and also ensure that the institution will remember to do so long after you get on the lottery bus.
Given all of the above, it may in fact, be easier to figure out who in your org you can bug to just pay the vendor.
I got around that one place by just writing up a bug report and a it seems like line x of file... this wasn't government and so they wouldn't have cared anyway so i just avoided figuring out the paperwork to contribute.
I wonder if they couldn't "just" put up a misc. software support money pool with a reasonable but in the huge picture small amount of money they can "low complexity" spend on such things?
Considering it took three tiers of management and three facilities department members to replace a coffee machine that had an actual service contract in place already, I think something of that administrative complexity would have been beyond them.
Either that or like most SMEs I’ve worked for they’re actually only using the stuff because it’s “free” by their corrupted definition of “free” which is basically it didn’t have to go through a PO process.
I think in this case that comment was just a funny way of saying both "this is actually for the well known USA nuclear weapons program, which everyone knows uses Crays" as well as "I couldn't get anyone to approve a bounty"
Oh, I didn't understand what that was getting at, beyond the generael idea of trolling the misbehaving requester, but which I thought cored devs don't do in their own bug tracker.
> Hi Bill, per our operational security procedure we can't talk about ieee_arithmetic, especially when we dont get paid.
This is a bit tongue and cheek as sharing just that random bit of information on a true SCI program about the customer would cause “issues”. The customer is obviously DoD/DoE, however bug did not come from the SCI side. If Cray/HPE is the contractor to the customer in supporting this system and the software being used then it is their issue write the fix or pay for a bounty to fix it WITHOUT reveling the customer. Even as a joke as the customer I would be upset.
Any large tech vendor likely has some dealing with certain government agencies. It has been my experience that those customers are NEVER referred to by name in any communications by the vendor and always given generic names like “customer blue”. You may see a bug tagged as customer blue in your bug db, but you did not know what agency that mapped to.
As an OSS maintainer myself writing something like that on the bug tracker would make it less likely to be worked on as this indicates complete disregard for maintainer’s time and efforts.
I know for a fact that I have at least one trillion and multiple billion-dollar companies using a piece of my (somewhat obscure) software. Somehow they’re always the ones asking for urgent fixes and never the ones contributing patches.
> I know for a fact that I have at least one trillion and multiple billion-dollar companies using a piece of my (somewhat obscure) software. Somehow they’re always the ones asking for urgent fixes and never the ones contributing patches.
Release the fixes under the AGPL and offer them paid proprietary licenses to use them.
I suppose threatening to strike GCC developers with nukes might be more effective than bounties, but it also seems like a lot more expensive to carry out.
Sure, but gfortran is part of the GNU Compiler Collection :)
And I think there is C11 support other than optional parts? https://gcc.gnu.org/wiki/C11Status
I don't know, but this more in-depth status page punts with "Library feature, no compiler support required", quite a bit: https://gcc.gnu.org/c99status.html
I can't find a similar page for glibc, so maybe the issue is there?
We used to use ARM proprietary C compilers at my last job doing firmware. Every time a compiler bug was fixed in one version to the next a new one was introduced. So we ended up sticking with a particular version that worked well and keep evaluating new ones till a better one is found. And we paid tons of money for the compilers and support contract back then. Maybe the situation is better these days.
You would be shocked at how much "military critical" software is built on OSS tools, libraries, and code bases. More shocking are the primary contractors charge top rates, contribute little to OSS, and try to hide the OSS usage from the end client.
You'd in turn perhaps be shocked at how much OSS software originates in militaries.
Especially in the software security / cryptography space — if a crypto algorithm isn't literally designed by some military, it's often designed by some mathematicians who were contracted by a military to come up with an algorithm with some particular nice set of properties, who then (probably much later) reused their paid learning to create another algorithm with similar nice properties for public use, but different enough that it doesn't "give anything away" cryptanalytically about its confidential progenitor algorithm.
"Opened" projects like Tor or Ghidra aren't at-all uncommon, either. The unusual part with those projects is that we know where they came from; usually such things are thoroughly scrubbed of their origins and handed over to a maintainer with a public identity, who is to claim that they created it themselves.
That would rather put to waste the effort of scrubbing them, no?
A lot of the reason for the scrubbing isn't confidentiality of authorship per se (though obviously that's important), but rather optics. If people see a FOSS project described as being e.g. "created by the NSA", they'll get skeeved out of using it or contributing to it, even if the NSA is no longer involved (or is only involved in the sense that people who happen to work at the NSA contribute to the project as civilians, in their time off, without the goals of the NSA driving the contributions.)
Most of these opened projects are just a result of people in the organizations seeing a genuinely-good project that was created as a byproduct of some project — probably by some contractors that were actually decent for a change — that nobody internally can get the resourcing to maintain any more, and so is going to be canned and replaced — and thinking they can advocate to give it a new life as a civilian asset. People thinking of the public good, basically. If revealing the origins of the work would void that benefit to the public good, they'll fastidiously avoid doing so.
So, gfortran is used to control nukes. Now I do wonder, how hard would it be for a foreign influence to sneak bugs into an almost-functional module providing the requested feature so that whatever control system gfortran operates faults or fails?
It's not like Cray/HPE are looking deeply into the code, they're too cheap to pitch in any effort themselves, after all, and arithmetic bugs that only appear when calculating orbits or trajectories might just be hidden from most unit tests.
Open source is great for a lot of things, but don't trust a bunch of randos from the internet to maintain your critical defence infrastructure.
Could also just be used for some regression tests. Like compiling and executing the testsuite with different compilers and verifying that there are no unexpected differences in performance and behavior:
This is open source software with access to the source code. Why not just submit a patch on your own? Just bill the customer with "nuclear weapons" for time spent contributing to OSS. Contractor gets paid. Client gets working software. OSS community gets a patch.
Is it incompetence? Is it laziness? Is it bad management? Is it all of the above?
Personally, I would love to get paid to work on OSS on behalf of X company. Much better than re-inventing the wheel, plus with the added benefit of learning something new.
In my opinion that should have been an instant close of the issue. If the customer has the type of money to have a nuclear weapons program then surely they have the money to pay for the software they're relying on. Or maybe since they're apparently paying Bill to handle the software - Bill should take issues he has into his own hands and fix it himself. Sheesh.
My guess is that Cray/HPE does not want to set a precedent where they actually PAY the developers. They want to cheaply "work with" the community to get things done.
Do major projects like GCC maintain a list of developers who are willing to take on paid consulting work with standard contracts to do things like this? The GCC devs could simply point to details page of such an arrangement of it exists as a way to speed up.
"Bounty" may not work in corporate or government environments but consulting is fairly standard and if there's an easy path to enable this, corporate money will more easily flow.
I don't get it. In the OP he shows that the Cray compiler handles this feature. So why not just have the customer use that compiler? Yes there's a license fee but presumably someone from Cray can get a good price on the Cray compiler if they have a customer satisfaction issue.
Gotta love the passive-aggressive sniping at someone politely asking for a timeline for when a fix will be made. Like, the answer is obviously just "without a bounty there is no timeline for a fix" but they can't just leave it at that...
They have way more patience than I do. I’d have pointed out pretty quickly that this “customer” is not a customer of the gfortran team and is therefore irrelevant to the discussion.
Bills response is not professional at all. Maybe it was meant to be taken with humor; but this style of communication does not work in every case. Humility and humbleness would have been a better style here.
Unfortunately this is how software developers are often treated.
I saw it less than an hour ago, on Firefox Android. Perhaps you need to wait a second after your browser first opens the page, for it to fully load so it can scroll down to the comment anchor. Or just search manually for "nuclear".
Clearly, GCC needs a new GPL licensing exception: "You acknowledge that the Program is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility." If Java does it...
I think everyone misunderstood your suggestion as an ethics clause when in reality it's just fluff, as you state later, something to this effect is already mentioned in the warranty clause.
But, I should point out: Someone can acknowledge that something is not designed or intended for a certain purpose but then recognize that despite this, it is perfectly suitable for it. i.e. a butter knife is neither designed nor intended for opening paint cans, but it's perfectly suitable for the task (at least some are).
Moreover, as software is not often stationary these days, what something is designed or intended for changes over time. Does this clause mean that no patches which intend to make the software explicitly usable in the context of a nuclear facility will ever be accepted? Does everyone sign a document saying: "While writing this patch, I made sure that I didn't accidentally think about nuclear facilities and how this patch may make the software more useful in those contexts." ?
Nope, it wouldn't. It's already implied by the general disclaimer of warranty in existing FLOSS licenses; adding that express provision would merely bring some much-needed clarity.
How so? "You acknowledge that X is not designed or intended for use in Y" is not a restriction on using X for Y: it's just telling you in no uncertain terms that the developers of X will not be helping you with any issues if it turns out you are using it for Y. This looks like the exact situation that OP is in, and that the Java provision is designed to guard against.
Why? GPL is a license to permit you to modify and distribute the source code which is normally illegal under copyright law. Nothing more, nothing less.
Well actually, 2 more things: distribute the modifications as well, and to use it without restrictions (Well that, plus making sure anybody who gets a copy gets the same rights).
The latter of the two points happens to be the retroactively added freedom #0 in the FSF's definition of free software[0], which is also repeated in the GPL license text, IIRC somewhere at the top. The Open Source Definition used by the OSI has clauses to a similar effect (See points 5 and 6)[1].
GP's suggestion, adding restrictions on how the software could be used, would run counter to that, conflicting with the very philosophy from which the GPL originates.
Bruce Perens, who originally wrote the Debian Free Software Guidelines[4] (the OSI OSD is based on that), also commented on that in 2019, when the idea to put forward to add ethics based usage restrictions to software licenses[2][3].
17 U.S. Code § 117 means any copying of the program from disk into memory (for example) is not a copyright breach, therefore you do not need to agree to a license like the GPL to run a copyrighted program, only to create additional copies.
Therefore any term saying
"You acknowledge that the Program is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility"
Would be completely meaningless as you wouldn't have to agree to it to run the software.
