GCC: The customer has nuclear weapons. They do not do “bounty”
gcc.gnu.org
gcc.gnu.org
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.
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?).
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.
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 are obviously not the masters of the domain they think they are, but that happens sometimes in bureaucracies.
When is the last time they stayed within budget?
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.
https://dl.acm.org/doi/10.1145/3418084
I'm aware that sometimes you can get your name on the paper by riding the other author's coattails, but it's interesting.
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.
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.
Bill has no right or ability to compel third parties not involved in the transaction to help him provide that service.
If Bill can't get the job done, that's Bill's problem.
The buck stops with Bill.
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.
> Inquiry from the original site: "Does GCC provide a timeline for when they will conform to F2018?"
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.
The maintainers responded well: they ignored Bill's weird framing and countered his entitlement politely.
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.
(Though when it comes to programming, they have armed themselves with a flint arrowhead.)
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.
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.
Sorry, couldn't resist.
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.
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.
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.
Pretty sure you meant extraterritorial, but if you really meant extraterrestrial, that would be VERY cool.
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.
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.
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.
Done.
In this case, that info probably wasn't useful ;-|
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.
> I also did not test the libquadmath portion. ENOTIME.
> I don't have much time, but
With every statement they added. It's actually like clockwork, every developer after that point said how they had little time.
Then again, I've never particularly desired to work for that line of "customer".
That's how I read it at least.
https://www.forbes.com/sites/adamandrzejewski/2021/11/18/fbi...
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.
That’s the reality of working for such folk.
- 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.
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.
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.
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.
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.
> Hi Bill, per our operational security procedure we can't talk about ieee_arithmetic, especially when we dont get paid.
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.
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.
GCC itself also doesn't have full support for c11 yet. Which was 7 years earlier. So they seem to have other priorities than fulfilling standards
I can't find a similar page for glibc, so maybe the issue is there?
Neither do other, much better funded compilers, to be fair.
Apple/Intel/Microsoft may have lots of money, but that doesn’t mean their C compiler teams get much funding.
I hear people say Apple’s work on clang is limited to their needs, and those may not involve getting full C11 support.
Microsoft also may not need full C11 support for their internal use. That can make getting that a low or zero priority task.
Intel recently moved their backend to LLVM. That doesn’t give me confidence they’re investing heavily there.
Now, gcc technically is volunteer work, but lots of development is done by people paid to do that by their employers.
I am developing software for iOS and the tooling is very bad.
It sure looks good. Nice colours.
clang and icc not.
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.
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.
[1] https://github.com/deptofdefense/AndroidTacticalAssaultKit-C...
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.
And there's lot of legacy code written by a lot of legacy professors.
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.
"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.
Ok screw you Bill.
> We do not do "fix your problems for free". In addition, the bounty for customers with nuclear weapons is automatically 10x the normal bounty. :)
Is what they should have said.
Unfortunately this is how software developers are often treated.
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." ?
> GPL licensing exception
If you instead replaced "exception" with a warranty disclaimer then your intent would've been more clear in your original post.
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].
[0] https://www.gnu.org/philosophy/free-sw.en.html
[1] https://opensource.org/osd
[2] https://perens.com/2019/09/23/sorry-ms-ehmke-the-hippocratic...
[3] https://perens.com/2019/10/12/invasion-of-the-ethical-licens...
[4] https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...
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.