This is correct, and the customer has full rights to redistribute. But the original customer may be limited to paying Red Hat customers only and still remain in full compliance.
What? So far the consensus is "probably is compliant (minimally), but a good set of lawyers may be able to argue either way, depending on the jurisdiction"
As I understand it (not a lawyer!): When you have a business relation with Red Hat (agreed to their T&C) and you choose to use the GPL-ed sources outside of the T&C you agreed, Red Hat has the right to terminate this business relation. The GPL-ed Sources you got during that business relation are under the terms of the GPL and thus it is within your rights after the business relation is terminated to use those sources anyway you like within the terms of the GPL. If you don’t like this arrangement, do not use RHEL.
The GPL does not allow you to put further restrictions on the redistribution of sources. The termination of your business relationship can be argued to be a restriction. It's not settled.
> The termination of your business relationship can be argued to be a restriction.
It's not a very good argument. The GPL does not state nor does it imply a continuing duty to deliver you source code. You have a right to the source which corresponds to the binary you've been delivered. Period.
If I release a new binary to which I hold full copyright, after having delivered GPL sources to you, and I wish to change the license of that software to fully proprietary, your rights are not restricted re: the GPL bits you've previously received. Why? Because you should still have the source to the binary you received from me that was licensed as GPL.
This is mostly true, but there's nuance to that which I believe doesn't make Stream a "fully GPL compliant target for RHEL sources".
Some sources do not hit Stream in a way that makes it possible to rebuild a release of RHEL verbatim, and devs can and have reported issues with compiling against Stream for deployment to RHEL, especially for the latest versions, where Stream and RHEL are diverged for a time.
the fuss is when this whole arrangement goes to an outside party for contract: companies that indemnify their partners; that have compliance requirements by law; that sign contracts to provide service that have strict clauses, all need the commitment of strong contracts with their OS supplier. Those kinds of customers are exactly RHEL customers, in many cases.
I really think this is all due to the Rocky/NASA deal. Their sales team (IBM/RH) must have freaked out. If Rocky can put a deal like that together then so can Oracle.
I felt bad for Mike McGrath when I read his apologetics. The technical guy playing as a pawn in a proxy battle between salespeople and lawyers.
I don't see why to stick to being a JavaScript subset. Yes, in the olden days it was practical with JSON that there is no need to write a dedicated parser, just pass the data to eval(). Nowadays you should not pass anything to eval, apart from metaprogramming purposes (in which case the input is fully in control of the code).
What I miss from JSON5 is a dedicated date/time type (TOML eg. does have it!). I understand that this would be a step beyond mere syntax sugaring, but I'd still prefer this trade off.
