AlmaLinux's response to Red Hat's policy change
In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released. These updates will be carefully curated to ensure they are 1:1 compatible with RHEL, while not violating Red Hat’s licensing, and will be vetted and tested just like all of our other releases.
Update: Rocky Linux has also sent out a
release on the subject. "There will be no disruption or change for
any Rocky Linux users, collaborators, or partners
".
Posted Jun 23, 2023 2:12 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (196 responses)
https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-y...
Posted Jun 23, 2023 4:47 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (189 responses)
The problem is distros that add nothing, but merely clone RHEL in a bug-for-bug compatible way. It may be permissible according to the licences but what value does it add for anyone? It leaves a bad taste.
Posted Jun 23, 2023 5:55 UTC (Fri)
by omgold (guest, #109541)
[Link] (170 responses)
> Unfortunately the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.
And this sounds quite questionable, in respect to GPL compliance.
Posted Jun 23, 2023 6:24 UTC (Fri)
by gfernandes (subscriber, #119910)
[Link] (4 responses)
I've seen this happen first hand.
Of preventing means RedHat has to dial license, then so be it.
Everyone doesn't play fair unfortunately.
Posted Jun 23, 2023 6:25 UTC (Fri)
by gfernandes (subscriber, #119910)
[Link]
If preventing means dual licensing....
Posted Jun 23, 2023 9:28 UTC (Fri)
by mfuzzey (subscriber, #57966)
[Link] (1 responses)
Posted Jul 3, 2023 12:10 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
(1) Oracle re-badge RHEL.
If I were Red Hat (or pretty much any normal human being) I'd be pretty much pissed off at that.
(And this is different to most "play fair" FLOSS guys, because if I'm taking support money, I'd either find the fix myself and upstream it, or talk to upstream and say "we need it fixed, can we negotiate a fee". As I said in a different post, it's the "warm fuzzies".)
Cheers,
Posted Jul 5, 2023 7:33 UTC (Wed)
by skissane (subscriber, #38675)
[Link]
> I've seen this happen first hand.
I worked at a place once where we were migrating from Solaris to Linux. We already had some SUSE (since we were a big NetWare shop and Novell had positioned the SUSE-based OES as NetWare's successor.) Our DBA told us that in his past experience, installing Oracle RAC on SUSE was a big pain, because Oracle's install scripts had various SUSE-specific bugs, whereas he said on RHEL it all just worked. We asked him to try again, and he did, and once again got stuck, and Oracle Support wasn't being helpful, so we ruled SUSE out. (This was over 15 years ago, so I hope those bugs are all fixed by now.)
We ended up choosing Oracle Linux over RHEL. Why? (1) We had a pre-existing relationship with Oracle Sales, and they were eager to come visit us in person and sell us on using their Linux, meanwhile we struggled to get Red Hat sales team to agree to come out and visit us; (2) Oracle Linux had a free download on their website so we could "try-before-you-buy", we asked Red Hat for the same and all they told us "we'll get back to you on that" and they never did; (3) the support contract price Oracle was quoting us was significantly less than what Red Hat was quoting; (4) since it was mainly to run Oracle products anyway (RDBMS, Forms, Reports, Portal, LDAP), we thought going with Oracle would reduce the possibility of inter-vendor finger-pointing if things went wrong. I can't remember any Linux support tickets being logged while I was there – we hit a few bugs, but they were all in the Oracle products we were running, not in the underlying Linux. We didn't feel like Oracle was "arm-twisting" us, on the contrary it felt like Red Hat wasn't really trying to win our business.
Disclaimer: I used to work for Oracle (after this all happened), so I can't claim to be a completely unbiased source on this topic
Posted Jun 23, 2023 6:26 UTC (Fri)
by joib (subscriber, #8541)
[Link] (164 responses)
Posted Jun 23, 2023 7:21 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (43 responses)
Oh for Groklaw - it was a very good training ground for armchair lawyers - things like the difference between a licence a contract (hint - it's basically a distinction without a difference), what an agreement is, what the law actually says ...
RH abides by the GPL licence. As you say, it provides its own internal sources to anybody to whom it CHOOSES to provide binaries.
In order to get those binaries, you have to pay for a SUPPORT CONTRACT with RH.
The SUPPORT CONTRACT says that as a condition of receiving binaries, you will not re-distribute the source. This is nothing to do with the GPL.
If you break the support contract, RH stops providing binaries (and source).
And there's nothing wrong with that. In particular, the customer's four freedoms are respected, and should RH disappear and stop providing support, the customer is left in the exact same state as they would have been without the support contract :-)
Cheers,
Posted Jun 25, 2023 3:29 UTC (Sun)
by richarson (subscriber, #74226)
[Link] (35 responses)
There is nothing *illegal* with that, but it's all manners of wrong from a FOSS perspective.
Posted Jun 25, 2023 12:42 UTC (Sun)
by pizza (subscriber, #46)
[Link] (34 responses)
"From a FOSS perspective" sounds a lot like the vaunted "UNIX principles" that often gets bandied about.
To be perfectly blunt, the only "wrong" thing most folks have with this is that they might have to pay (or be otherwise inconvenienced) to get exactly what they want.
Posted Jun 25, 2023 14:08 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Eggsackerly!
We are social creatures. Part of society is that we rely on TRADE. And to put it at its most basic, the important thing about trading is that both parties walk away with the warm fuzzies. Your "most folk" seem intent on leaving a very sour taste in RH's mouth - very much the opposite of the warm fuzzies.
Cheers,
Posted Jun 25, 2023 19:01 UTC (Sun)
by richarson (subscriber, #74226)
[Link] (32 responses)
And yes, I know and I'm grateful for all of the development that RH does and all they already contribute, but that's exactly why this action stings so much.
If such a good FOSS company is willing to do this kind of thing to cripple its competitors, what can we expect from others?
Posted Jun 25, 2023 19:23 UTC (Sun)
by pizza (subscriber, #46)
[Link] (30 responses)
The benefit was not one-sided and you well know it.
> If such a good FOSS company is willing to do this kind of thing to cripple its competitors, what can we expect from others?
This really shines a light on the true costs of F/OSS integration efforts, and how nearly nobody is willing to pay for the value they keep saying they want.
But to answer your question, you have only to look at Canonical's ongoing monetizing shenanigans, and of course, "Evil is our middle name" Oracle, whose corporate ethos of underhanded greed is why we can no longer have nice things.
Oh, and Rocky/Alma aren't RH's "competitors".
Posted Jun 26, 2023 20:29 UTC (Mon)
by richarson (subscriber, #74226)
[Link]
Posted Jul 5, 2023 17:59 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link] (28 responses)
Some people seem to think that the "loophole" is only providing source to those they directly distribute RHEL to. In my view, that is specifically what the GPL asks you to do. Is "full compliance" the loophole? Not only that, Red Hat actually goes beyond the requirements of the GPL and provides full source to the world at large via CentOS Stream.
Is the loophole that they enforce contract terms above and beyond the license? I guess I can understand that argument but it just seems very straightforward to me that copyright licenses, trademark licenses, patent licenses, and contracts are all different things that can be managed via individual agreements. Having any one of these agreements individually does nothing to imply the others. For example, getting a Red Hat authored package via the GPL license does not entitle you to support from Red Hat unless you have a contract with them ( even though they may have such agreements in place with others ).
Is the loophole that Red Hat is not offering the entirety of RHEL via the GPL? That is obviously not possible as RHEL is made up of a great many individual components made available a number of licenses ( the GPL being only one ). Also, the GPL itself states quite clearly that an "aggregate" that includes a GPL "covered work" is not in any way itself bound by the GPL. So that cannot be the loophole.
So what is the loophole? Or is it one of the above and I just do not understand specifically what makes the situation so intolerable?
For purely optics reasons I was not in favour of this move. Honestly though, the reaction has caused me to side quite firmly with Red Hat. I have not seen a single justification for why CentOS is not good enough and EXACTLY the RHEL packages have to be available that does not boil down to somebody else wanting to make money off RHEL without paying. It seems that it is the "community" that is focused on free as in beer here and not free as in freedom. Making the copycat distributions work a little harder and making it a little harder to claim absolutely that you are identical to RHEL does not sound like a bad thing at all.
Posted Jul 5, 2023 19:02 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (27 responses)
The authors of GPL software believe that all recipients of that software should be able exercise the Four Freedoms.
Red Hat is shipping GPL software; their entire business is predicated on it.
The recipients of that software get source code. But they cannot exercise the Four Freedoms (specifically Freedom 2) without losing access to the software. Because this can mean loss of livelihood or other serious consequences, _in effect_ they are prevented from exercising Freedom 2, even if _legally_ they are allowed (that is, no one will sue them if they do).
Red Hat is saying "we have agreed to a license (GPL) which requires us to allow you to do X, but if you actually do X that we are required to allow you to do then we'll stop doing business with you". There is an argument to be made about whether that complies with the GPL but even if it does, it's certainly reasonable to believe that what they're doing is against the spirit and intent of F/OSS. And that upsets people.
You can say "well, CentOS is almost the same" which may be true, but it's beside the point: the GPL talks about the actual source, not "almost the same" source. You can say "well, people are cheating RH by taking their work and redistributing it without giving back themselves" and that's true, and very unfortunate, and I can sympathize with them about that. But that's also beside the point of the argument being made above.
Posted Jul 5, 2023 19:39 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
That should read: "...without losing access to FUTURE releases that Red Hat might create."
Under no scenario do they lose access [1] to the software they've already obtained. Nor do they lose access to the complete corresponding source code to this software; if their access to RH systems is cut off -- according to the written offer, RH will supply the complete corresponding source code to your current binaries for $5.
[1] They can't download _new_ copies of said software from Red Hat, but the copies they already have remain fully accessible and functional.
Posted Jul 5, 2023 21:21 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (2 responses)
Yes, correct. I guess I thought that was clear from the context but maybe not. You can fully exercise your Freedom 2, as they must allow, for the software you already have... anything else would be a _clear_ violation of the GPL. However you can only do so under threat that your business may no longer be viable in the future (if you require a Red Hat support contract, which many places do require for various reasons).
Posted Jul 5, 2023 22:46 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
There's nothing that forces you to redistribute GPL software you've received; it's just that you can, if you choose to. And similarly, you can choose not to, for any reason whatsoever.
"I choose to not do X because I get something more valuable in exchange" is not only perfectly legal, but is IMO the fundamental underpinning of all human societies.
Posted Jul 6, 2023 1:04 UTC (Thu)
by madscientist (subscriber, #16861)
[Link]
The reason Red Hat is in a position to make their product in the first place is that they have used work that I (the copyright holder) produced, and I allowed them to redistribute it with the understanding that they would not restrict the freedoms of others that they distributed it to. If the others want to take advantage of the freedoms that I intended them to have, and Red Hat won't allow them to do that without inflicting some harm on them as punishment for exercising that freedom, then they are abrogating that agreement: maybe not according to the courts (we don't know) but certainly morally. If they didn't want to be held to that standard then they should not have made the agreement with me (by using my work). Of course RH is not obligated to support anyone, and they can stop offering support for all sorts of reasons. If their support contract says they won't support anyone who wears loafers without socks, fine with me. But if it says that they will cancel the contract if someone exercises the freedoms they agreed to allow when they redistributed my software, that's a completely different thing and I have to suspect that difference is obvious to everyone. I certainly have no problem with Red Hat restricting the redistribution of non-copyleft software (things under the MIT / BSD license for example). In fact they should absolutely do that if they want to; the copyright holders of that software explicitly said they should feel free to do it. But at least some of us who provide GPL'd software have what I think are clear expectations in return for making it available and in my opinion Red Hat isn't meeting those expectations any longer. Anyway I have no interest in getting into a lengthy back and forth which will no doubt descend ultimately into Godwin's law. The question was asked Honestly, I am asking hoping that somebody with a different perspective can explain to me as I feel like I must not understand and taking that at face value, I've provided an honest explanation to the best of my ability. You may not agree with it but hopefully you understand it, just as I understand your argument... and don't agree with it.
Posted Jul 5, 2023 19:41 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
The problem with that, as I see it, is that the people making this argument are missing one FUNDAMENTAL point. They are telling me that I am NOT ALLOWED TO EXERCISE FREEDOM OF CHOICE, which to me is FAR more important than the Four Freedoms.
Okay, as an individual, Freedom 2 is important to me. But as a company not in the software business, Freedom 2 is much less important than staying alive. In fact, Freedom 2 is pretty much worthless! If I can trade that for something I value, like a support contract, there's simply no valid argument not to.
Why should I act in THEIR best interests, rather than my own?
Cheers,
Posted Jul 5, 2023 20:03 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (21 responses)
And one difficulty with this argument is that Red Hat doesm't say "if you actually do X that we are required to allow you to do then we'll stop doing business with you"; they say "if you do X in a way that lets someone without a Red Hat subscription get the benefit of that subscription, we'll stop doing business with you after a 30 day notice period expires".
In turn, that means that a lot of distribution of Red Hat Enterprise Linux packages isn't going to trigger Red Hat into cutting you off - giving just one to a consultancy so that they can fix it, or sharing source with someone who already has their own Red Hat subscription agreement isn't going to trigger Red Hat cutting you off.
Whether this is, or isn't in the spirit and intent of F/OSS is a different question, but it's not nearly as cut-and-dried as "if you distribute any RHEL SRPMs, you will immediately lose access to RHEL".
Posted Jul 5, 2023 21:35 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (18 responses)
I'm sorry, but this is a distinction without a difference (IMO). Either you have Freedom 2, or you don't. If you have to query the recipient's status to determine if they're allowed to receive the source before you give it to them, otherwise "Consequences", then that's no different _in effect_ than any other proprietary software you happen to have access to the source code for. You are punished for exercising your freedoms that the the software author wanted and expected you to have... "sometimes, with the people we (Red Hat) don't approve of". The punishment won't involve being taken to court but it is there and it can certainly have severe impacts.
Posted Jul 5, 2023 22:52 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Um, if I supply _any_ software to folks in certain countries, I can get thrown in jail. Legally, I'm responsible for making sure that anyone I do business with isn't on one of several "naughty" lists.
By your logic, I therefore don't have Freedom 2 at all.
Posted Jul 6, 2023 9:55 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (16 responses)
Then no-one in the USA has Freedom 2. Supplying software to people on the USA's sanctions list (such as Vladimir Putin) is a criminal offence, and you must, by law, query the recipient's status to make sure that they're not a front for someone on the sanctions list. Similar rules apply in most European countries, although the sanctions list differs - and of course, China and India have their own variations on this theme.
Further, because it's "the benefit of a subscription" that matters, and not the sharing of source, you could well find that sharing just the exact versions of all RPMs in RHEL 9.5 triggers the clause, while sharing the complete kernel source from the version of RHEL you're using on a system does not.
Posted Jul 7, 2023 18:20 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (15 responses)
Or are you just trying to score a point by showing that I didn't take into account completely irrelevant things in the text of my reply, and instead of "you either have it or you don't" I should have explicitly said "Red Hat either allows it or they don't"? I wouldn't think that this was needed if we're engaged in a good-faith discussion as everyone understood what I meant, and also did not mean, but anyway congratulations you got a point.
Posted Jul 7, 2023 18:32 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
To quote you own words, this is a "distinction without a difference. Either you have Freedom 2, or you do not."
Posted Jul 8, 2023 12:45 UTC (Sat)
by madscientist (subscriber, #16861)
[Link]
Posted Jul 7, 2023 20:25 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
You're basically placing your freedoms - specifically Freedom 2 - over and above other peoples' freedoms, specifically their Freedom Of Association and Freedom Of Choice.
Cheers,
Posted Jul 7, 2023 21:27 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
You do not have the right to demand others work for you. That's called Slavery. I thought you fought a war to abolish it.
(And if Red Hat's work isn't worth having, why are you demanding they work for you?)
Cheers,
Posted Jul 10, 2023 15:23 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (10 responses)
First, you can exercise your Freedom 2 right. That's not in doubt - the worst case is that Red Hat will decide that they won't do business with you in future. You can also find that Red Hat go down the same route without you ever exercising your Freedom 2 right - for example, just sharing all the binary RPMs will do that, or even a version list so that someone else can reconstruct a bug-for-bug RHEL from CentOS Stream sources.
But this isn't the only reason for Red Hat to decide not to do business with you - they could decide to not do business with you because your bank is being problematic about transferring payments to them. Or because they have reason to believe that you're a front for a sanctioned entity, and they legally cannot do business with you. Or even because they've decided that entities of your type are not profitable customers. They could also refuse to do business with you because you've got an employee who's suing IBM, or because they think you're likely to be a competitor of theirs.
So, the underlying question to answer: when is it OK for Red Hat to refuse to do business with you in future, and when is it not OK? What is the principle that I can apply to split out "Red Hat is punishing people" from "Red Hat is just exercising its right to Freedom of Association"?
Posted Jul 10, 2023 16:56 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (9 responses)
I believe I've always been careful to qualify this as "without being punished". If I forgot this in some material place I apologize. I fully agree that RH is not saying they will sue you for copyright or license violation if you redistribute.
> So, the underlying question to answer: when is it OK for Red Hat to refuse to do business with you in future, and when is it not OK? What is the principle that I can apply to split out "Red Hat is punishing people" from "Red Hat is just exercising its right to Freedom of Association"?
I already discussed this. We don't have to treat all reasons as equivalent, such that if one reason is OK then all reasons are OK, or if one reason is not OK then no reasons are OK. All reasons are not the same!
The principle you are looking to apply is the license. RH is redistributing software published under the GPL, which contains a clause saying you cannot add "further restrictions" to downstream recipients' use of the software. So, what makes this different from general free association such as the color of socks, bank problems, or not being profitable, is that by distributing the GPL'd software they are agreeing to the terms of the GPL and the GPL has requirements about allowing downstream distribution, while it doesn't say anything about those other things.
In other words, once RH decided to do business with you notwithstanding the color of your socks, the question is can they decide to STOP doing business with you SOLELY because you exercised your GPL rights (not for other reasons, but for THAT reason)?
Whether the support contract clause really constitutes "further restrictions" in a legal sense is up to the lawyers, and whether it is ethically OK is of course up for debate (clearly). But again I entered this thread to explain to people who couldn't understand why there was pushback, exactly what the problem is. I have hopefully done that.
Posted Jul 10, 2023 17:12 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (6 responses)
And I don't think your "without being punished" qualification is useful. You are "punishing" me in the same way by not doing business with me that I want to do, on the terms I want to do business. LWN is "punishing" me by refusing to let me continue my subscription for free, when I don't want to pay them.
Your principle is one that Red Hat already complies with - they do not refuse to do business with you SOLELY for exercising freedom 2, but specifically for using your subscription so that someone else benefits from a Red Hat subscription without having their own subscription.
And no, you've failed to explain why there's pushback, because you're addressing the wrong thing - RH have already promised that you can exercise your Freedom 2 rights per the GPLv2 without any impact on your RH subscription; what you can't do is use your RH subscription (source, binary or other data) to give someone else the benefit of an RH subscription. So, for example, if I took the kernel source from a RHEL subscription and sent it to my friend to help me debug an issue on my RHEL box, that'd be fine. If I sent it over to CQI so that they could use it to address customer issues that are already known to be fixed by RH, that wouldn't be fine.
This nuance is the thing that nobody is addressing - the deal on offer is that if you choose to compete with Red Hat, they will stop dealing with you in future. They'll still comply with the licence, they'll still let you distribute what you have from them - they just won't do business with you in future. I'm still waiting for someone to explain why Red Hat must continue to do business with someone they see as competition, given that RH don't care about you exercising your GPL rights at all if you're not aiming to compete with RH.
Posted Jul 12, 2023 13:06 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (5 responses)
I've already said this is not compliance IMO (although somehow that turned into a totally irrelevant side-discussion about sending software to Putin or North Korea).
The theory under test is that if you don't redistribute the source, or redistribute to only certain people or in certain ways, RH will continue support you. If you do redistribute the source to certain other people, or in certain other ways, they will stop supporting you. The response is that this is against the intent, at least, of the GPL; I will leave the legalities up to others. The GPL (famously) doesn't allow you to make any sort of distinction based on the uses that the software will be put to: you either provide source and you don't restrict them from redistributing it, or you can't distribute at all.
> And no, you've failed to explain why there's pushback, because you're addressing the wrong thing - RH have already promised that you can exercise your Freedom 2 rights per the GPLv2 without any impact on your RH subscription; what you can't do is use your RH subscription (source, binary or other data) to give someone else the benefit of an RH subscription.
Making that kind of distinction, as to what the user is or is not allowed to do with the source and who they are or are not allowed to redistribute it to, is not allowed by the GPL. "No further restrictions" means "no further restrictions". No asterisk.
In every way, the exact point of the GPL is exactly to ensure that "someone else" can get the benefit of the source code. That's the ENTIRE REASON the license exists. If you don't agree with that you should not be distributing GPL'd software.
> I'm still waiting for someone to explain why Red Hat must continue to do business with someone they see as competition, given that RH don't care about you exercising your GPL rights at all if you're not aiming to compete with RH.
If Red Hat decides whether or not to renew support based on some other criteria that has nothing to do with redistributing source code, that would be fine. For example if they don't provide support to ANY Linux vendor, regardless of whether that customer redistributed Red Hat source to anyone ever, I have no problem with that.
But if they provide a support contract then disallow it, and the material difference between users who are allowed to keep their support contract and those who are not is whether or not they take advantage of Freedom 2 with source code they got from Red Hat in a way that Red Hat doesn't approve of, then this is against the intent, at least, of the "no further restrictions" clause.
Posted Jul 12, 2023 13:37 UTC (Wed)
by anselm (subscriber, #2796)
[Link]
“No further restrictions” means you don't get to impose further conditions, on top of what the GPL stipulates, on redistribution of the GPL code. E.g., no redistribution on Sundays, or no redistribution to people south of the equator.
But this is not what Red Hat does. Red Hat doesn't restrict the redistribution of GPL sources that you obtained from Red Hat. Red Hat simply reserves the right, in its own service contract that is completely separate from the GPL, to stop providing services to you under that contract you if you do things that are deemed by Red Hat to be detrimental to Red Hat's business, including using Red Hat 's published source code to offer a competing Linux distribution that is identical to RHEL in all respects except it isn't called RHEL, or otherwise let people take advantage of your Red Hat subscription who don't pay for a Red Hat subscription of their own.
IOW, as long as you deal responsibly with GPL source code from RHEL, including redistribution, Red Hat isn't likely to go after you for breach of contract. They would presumably much rather keep you as a paying customer than kick you out. It's only when you go into active competition with them for market share, based on their own product, that they will take steps to prevent that, which is basically what any business would do, so it's really hard to fault them for that.
Posted Jul 12, 2023 13:52 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
The GPL *DOES*, however, EXPLICITLY allow charging for support, iirc. So if you help people dodge paying, you are acting *against* the explicit intent of the GPL (else why would it mention it?).
Cheers,
Posted Jul 12, 2023 14:54 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
But, importantly, Red Hat aren't restricting your ability to redistribute the GPLv2 software. Go nuts, do it - no matter what you do, you will not have restrictions placed on your ability to redistribute GPLv2 software. Indeed, Red Hat will even supply you the sources you need to do that distribution if you got a binary from them - even if you're not longer a Red Hat customer.
What Red Hat are restricting is your future ability to do business with Red Hat if they think that you're abusing the business terms they asked you to agree to. You have no restrictions at all on your redistribution of Red Hat Enterprise Linux - you can redistribute freely; what you cannot do is demand that Red Hat continue to distribute future versions to you in the future if they choose not to.
Further, Red Hat offer RHEL under GPLv2 3b terms - a written offer. You can continue to get the sources for the latest version of RHEL by taking up Red Hat's written offer, even if they won't let you have a subscription; it's just that you lose access to the Red Hat Knowledge Base, and Red Hat stop pushing updates on you, if they choose to no longer do business with you.
Posted Jul 12, 2023 15:02 UTC (Wed)
by pizza (subscriber, #46)
[Link]
No, the point isn't to ensure that "someone else" gets the benefit of the source code.
The point is to ensure that *the recipient of the software* gets the (full) benefit of the source code.
Nothing in the GPL *forces* the recipient to redistribute it, much less to random third parties. It only says that *IF* they choose to redistribute it, they also pass along the source code (via one of several enumerated methods), with no (additional) restrictions beyond what the GPL allows.
And the GPL does allow for some restrictions; eg with respect to trademark/branding, and crucially to this kerfuffle, support -- The GPL makes it quite clear that support/service/updates lie outside the scope of the GPL, and explicitly states that the mere act of supplying sources is sufficient reason to terminate any support/service agreements, and stop providing further updates.
Posted Jul 12, 2023 16:32 UTC (Wed)
by kleptog (subscriber, #1183)
[Link]
> Making that kind of distinction, as to what the user is or is not allowed to do with the source and who they are or are not allowed to redistribute it to, is not allowed by the GPL. "No further restrictions" means "no further restrictions". No asterisk.
IANAL but doing some research, the distinction between "restriction" and mere "contractual terms" depends on the severity of the penalty, and in most jurisdictions withdrawing service not considered severe because businesses are generally not obliged to continue service anyway. So asterisk or not, it's not so black and white. Elsewhere the word "imposed" is similar, implying something that cannot be negotiated away.
And frankly, the idea that a sentence in a copyright licence could constrain the agreement between two businesses (ie RedHat and a customer) just doesn't pass the smell test. Nowhere in the GPL does it say you can't voluntarily give up some rights in exchange for something else. As long as the conditions only apply to the parties in the contract and are not extreme, all is fine. If the GPL had intended to override standard contract law rights, it should have said so explicitly.
I suppose while it feels like the intent of the GPL was to give people a stick to beat businesses with, the stick is not of unlimited power.
Posted Jul 11, 2023 8:49 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Jul 11, 2023 9:06 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
Here's the rub - Red Hat will not engage in a retaliatory, punitive act specifically for exercising their GPL rights to redistribute. You share code with me (and I don't have an RH subscription), and that's fine, because any reason you have to do so is not to give me "the benefit of your Red Hat subscription".
This is the framing used initially, as far as I can find, by CQI, who sell support for a RHEL rebuild - they've framed it this way because their business model is giving other people the benefit of a Red Hat subscription for a lower price, and by saying that they'll cut you off for doing that (which includes - for example - sharing the list of binary RPM versions available in a given RHEL point release), they've made CQI's business model that bit less tenable.
Posted Jul 14, 2023 13:14 UTC (Fri)
by lproven (guest, #110432)
[Link] (1 responses)
[[Citation needed]]
Not because I am doubting you. I'm not. But I wrote about this, and even got cited by the SFC, and subsequently people are asking me on Twitter for specific chapter & verse from RH EULAs or similar documents, and I don't have them.
I was merely reporting on the conversations I have seen lots of people having online -- including here.
Posted Jul 14, 2023 13:24 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
It's in the Software and Support Subscription Agreement, section 1 (Use of Subscription Services) (specifically in 1.2 (g) through 1.4), as combined with the baseline Enterprise Agreement section 4 (termination).
Posted Jun 25, 2023 19:32 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Because those competitors are freeloading on RH's work, and the alternative for RH is going bust?
As others have pointed out, the target of all these shenanigans is Oracle, who are doing their best to ship (and take money for) an exact copy of RHEL.
Most competitors (SUSE, Debian, Canonical et al) put in a decent amount of engineering work themselves. Red Hat benefits from their work as much as they benefit from Red Hat.
Remember what I said about "the warm fuzzies". Red Hat may not appreciate the co-opetitian from the likes of SUSE and Canonical, but they play fair.
Oracle have not only the will, but the desire AND RESOURCES to use Red Hat's own work as a weapon against them. That's pretty much the definition of a parasite. What do you want Red Hat to do? File for bankruptcy?
Cheers,
Posted Jun 29, 2023 14:35 UTC (Thu)
by dreadedhill (guest, #140784)
[Link] (2 responses)
Redhat is in fact forbidding the redistribution of modifications to open-source code - in direct violation of license.
Posted Jun 29, 2023 15:23 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Forbid != hinder. Forbid != prevent. Forbid != "as if by effectual command
Forbid == command to not do something (not "as if by effectual command").
> Forbid; to refuse to allow something, especially officially, or to prevent a particular plan of action by making it impossible:
(Via a credible dictionary)
Posted Jun 29, 2023 15:34 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Red Hat can NOT enforce any demand that users do not distribute source. Humpty Dumpty would be proud of the GP.
(Actually, like most apocryphal stories, most people DON'T know where that got Knut. He knew EXACTLY what he was doing ...)
Cheers,
Posted Jul 2, 2023 9:53 UTC (Sun)
by SLi (subscriber, #53131)
[Link] (2 responses)
But I'm confused by your mention of the differences between licenses and contracts, and how they aren't that great (the way I'd puti
I don't see how it supports the other things you said. Seems to me it would be the contrary. IIUC, if there is a meaningful distinction between a contract and a license (and according to FSF's interpretation), a contract is something that can do more than a license. According to this theory, in a license you are merely granted in a one-sided way something that you would otherwise not have; it is a pure expansion of your rights. A contract, on the other hand, would allow a two-sided deal where in consideration for some rights you would give up something you would have if you didn't enter into that contract.
So it seems to me that licenses and contracts not being that different can actually only hinder Red Hat. It would mean that a license could bind Red Hat's conduct more than what would be the case if FSF's theory was right.
Posted Jul 2, 2023 10:42 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
If I release something under the GPL, it is an "offer to treat". If a shop puts a price tag on a shelf, it's an "offer to treat".
Both require acceptance by a third party.
The main difference between a licence and a contract is that a licence contains the offeror's acceptance in the offer. A contract doesn't.
Cheers,
Posted Jul 2, 2023 10:49 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
And with a contract, the offeror can refuse to accept the third-party's offer/acceptance.
Cheers,
Posted Jul 5, 2023 17:41 UTC (Wed)
by jmalcolm (subscriber, #8876)
[Link]
Red Hat provides subscribers GPL software via the GPL license and this license empowers them to share the sources. These subscribers agree to contractual terms that specify that they will not. Subscribers that "breach the contract" by distributing RHEL are not subscribers anymore. You are not going to see any GPL license violation suits from Red Hat but you may ( probably will ) see them cancel subscriptions.
Three points that always have to be made in any post regarding this debacle since they are so bitterly misrepresented over and over:
1 -RHEL is a Linux distribution made up of very many packages. Only some of those packages are GPL. Lots of other licenses are used. RHEL contains Red Hat trademarked stuff. RHEL contains Red Hat authored stuff that may not be licensed under the GPL ( thought Red Hat DOES license pretty much all the software they author and contribute to via the GPL - by choice - not force ).
2 - Red Hat makes substantially all their changes available to everybody ( the public ) via CentOS Stream. Red Hat is not taking anything "closed source". What they are doing is obscuring which commit you would have to take for each package to get the "identical" behaviour as their RHEL product. They are not refusing to share source code, they are trying to eliminate exact duplication of their distribution ( not the code -- the packaging if you will ).
3 - With regards to licensing, individual packages are GPL licensed. When the GPL talks about "the work" or a "covered work", it is referring to the individual package. RHEL itself is what the GPL calls an "aggregate". For all those "RHEL has to be licensed under the GPL or it is a violation" folks, here is a sentence pulled verbatim out of the GPL itself ( go read it ): "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate". To say that in a more specific way, according to the actual text of the GPL itself, inclusion of GPL packages in RHEL does not cause the GPL to apply to other parts of RHEL beyond that specific package -- RHEL itself does not fall under the GPL license just because it includes some GPL software. Almost all the bombastic commentary that I read on this completely ignores that this sentence exists. Again, this is not an analysis or opinion, this is the actual wording within the text of the GPL itself.
Posted Jun 23, 2023 7:21 UTC (Fri)
by omgold (guest, #109541)
[Link] (39 responses)
Section 6 of the GPLv2 says: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
So lawyers might have a different opinion on what "impose restrictions" means. Explicitly forbidding redistribution in the terms of the RHEL subscription, IMHO, might very well qualify. Not explicitly stating it, but performing actions of reprisal, like terminating the subscription, might still qualify.
Thus I'm not sure, RHEL is really in compliance.
Posted Jun 23, 2023 10:16 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (16 responses)
The terms do not explicitly forbid redistribution; they grant Red Hat the right (but not the obligation) to consider redistribution a breach of your subscription agreement, where such redistribution acts to give a third party the benefit of your subscription. The one thing they definitely don't grant is a Red Hat trademark licence - but it's fairly well established that trademark restrictions are not restrictions on redistribution.
Given that Red Hat don't automatically terminate your agreement on redistribution, but instead take it on a case-by-case basis, it's not a complete restriction; from the way the agreement is worded, you're not doing anything wrong if you redistribute the SRPMs to a contractor fixing bugs for you (to choose an example), because then they're not getting the benefit of your subscription, you are. Similarly, distributing the SRPMs to someone who buys an appliance from you because you've sold a RH subscription with it is fine - the recipient has a subscription, so isn't a third party benefiting from your subscription.
If Red Hat read their agreements the way I do, then you're mostly fine to redistribute, except when the intent is to clone RHEL or to let someone use CentOS most of the time, but RHEL when RHEL is better.
Posted Jun 23, 2023 10:26 UTC (Fri)
by omgold (guest, #109541)
[Link] (9 responses)
Posted Jun 23, 2023 11:19 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (8 responses)
There are no restrictions on redistribution; no matter what you do, you can redistribute the packages you have as much as you like, and RH won't stop you.
The restrictions are on the RH subscription; redistribute in ways that upset Red Hat, and you lose your subscription (you get a 30 day notice from RH). And it only applies to subscription content; take the RHEL SRPMs, look up the equivalent sources in CentOS Stream, and use the CentOS Stream sources, and you're in the clear - even if the CentOS Stream sources are identical to the RH ones.
Posted Jun 23, 2023 12:44 UTC (Fri)
by omgold (guest, #109541)
[Link] (7 responses)
It could be seen as a similar situation as employers discriminating against employees for behavior which is entirely legal (and morally acceptable), like e.g. forming a labor union. That won't fly either (in case it can be proven, of course).
If I were a lawyer, I would argue, what the intended meaning of that sentence under (6)
> You may not impose any further restrictions on the recipients' exercise of the rights granted herein
should be, if not that it also applies to actions by the redistributor beyond changing the license.
When interpreted like you are doing, the above sentence would be completely redundant, because (2b) already says explicitly, that you cannot change the license:
> You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
Posted Jun 23, 2023 14:20 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
I would be surprised if a judge considered it a restriction; it's scoped by the rest of the agreement to cases where your redistribution has the effect of giving a third party without a Red Hat subscription the benefit of your Red Hat subscription - it is not a general prohibition on redistribution. As an example, with the language RH uses, I could distribute a RH SRPM from my subscription to Collabora for the purposes of having them fix the software and give me a patch that I can apply to my RHEL system, and that would be absolutely fine, even if Collabora engaged in onwards distribution of the SRPM.
It's the scoping of it down to only cases where someone else gets the benefit of your subscription that I think pulls it out of the "general restriction" case; you can redistribute all you like, and on top of that, you can redistribute without affecting your subscription. It's only if you redistribution gives someone without a Red Hat subscription the benefit of your subscription where Red Hat are going to give you your 30 days notice.
Posted Jun 23, 2023 16:39 UTC (Fri)
by Paf (subscriber, #91811)
[Link] (4 responses)
Look, I get that RedHat has created a sufficiently dense legal construct that it will require courts and significant expense that most aren't willing to pay to tear it down. But let's please not try to pretend it's not violating the intent of the GPL, which is that software and source licensed under it be freely redistributable by anyone who is given source or binaries. If redistributing them is punished by no longer selling to that customer, then free redistribution isn't actually allowed.
Like I said, RedHat *may* have created a legal construct that can stand up or at least will be expensive to knock down. But don't pretend it's not violating the intent of the license, if *perhaps* not its letter.
Posted Jun 23, 2023 17:02 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
See, I disagree with your framing - it's an attempt to protect the value of a Red Hat subscription, not to stop you sharing the source code Red Hat received under GPL terms. If you remove the Red Hat authored and owned .spec file from the SRPM, and redistribute the rest, RH's own agreement doesn't stop you from redistributing further, because you've removed the one part that enables people to get the benefit of your subscription agreement.
Posted Jun 25, 2023 0:40 UTC (Sun)
by Paf (subscriber, #91811)
[Link] (2 responses)
Posted Jun 26, 2023 10:08 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
The test in the RH agreement that makes it a breach is not redistribution per se; it's "does this act of redistribution give a third party the benefit of a RH subscription that they are not paying for?".
Thus, if you only redistribute to people with an equivalent or better RH subscription, there's no issue under the subscription agreement. If you are the only entity that benefits from your redistribution (e.g. because you share with a contracting firm like Collabora, who take upstream fixes and apply them to the RHEL SRPM for you), then there's no issue under the subscription agreement.
If your redistribution does not give me the benefit of the RH subscription, then there's no issue under the subscription agreement; my position is that removing the RPM specfile does that, because I can't get the benefit of an RH subscription if I can't build an RPM from the SRPM without repeating the work RH did to write a decent specfile.
The only time there is an issue is if your redistribution gives someone without an RH subscription the benefit of that subscription. At that point, you've breached the agreement, and RH can give you 30 days notice of cancellation of your subscription (plus refuse to do business with you again).
Posted Jun 27, 2023 18:24 UTC (Tue)
by polyergic (guest, #153186)
[Link]
https://www.redhat.com/en/resources/red-hat-enterprise-li...
Specifically, sections 1.2(g) and 1.4 don't appear to be in conflict.
Alma's announcement is pretty poorly communicated here. It's unclear whether their "understanding" of Red Hat's terms are from an independent reading (which could be mistaken) or whether they actually asked a Red Hat representative and were explicitly told that redistributing the source would be against the terms.
Posted Jun 23, 2023 21:27 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link]
Posted Jun 25, 2023 22:48 UTC (Sun)
by xslogic (guest, #97478)
[Link] (5 responses)
(As an aside, it might be nice if the lwn.net FAQ listed things like - how quoting works, which tags are allowed and which ones are denied for an HTML comment. I've figured out quote and span are disallowed and disable preview. The FAQ is the first place I looked for such things when I was trying to write this comment and - well, if it was there and I missed it, I apologise)
Posted Jun 26, 2023 0:01 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
You can require your customer to have a valid RHEL license and/or negotiate the downstream licensing with RedHat.
Posted Jun 26, 2023 9:07 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
All Red Hat can (and will) do is stop doing business with you, as is their right.
Cheers,
Posted Jul 2, 2023 10:00 UTC (Sun)
by SLi (subscriber, #53131)
[Link]
How would you view an arrangement where
1. Red Hat gives you the binaries, 10 years of updates and support and a written offer to provide source in exchange for a large sum of money;
?
Posted Jun 26, 2023 9:15 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
> Doesn't matter that they don't forbid it, as the GP puts it, the GPL specifically forbids adding further restrictions. (Which, I'd strongly argue, this is) Besides which, it makes it mildly negligent to use Red Hat for any product you sell to a third party. (Because you yourself cannot distribute the code to the third party without breaking Red Hats rules...)
Oh - and another little legal nit, they CAN'T be ADDing restrictions, because you have absolutely no GPL rights at the point at which you agree not to re-distribute source, because you don't have any source to distribute!
You may not like it, but at the end of the day EVERYTHING you get from Red Hat is freely available elsewhere. Like in many other industries, they are an integrator. What you are paying for is RH's value-add, and they have every right not to want their competitors to take advantage of it and use it against them.
Cheers,
Posted Jun 26, 2023 13:59 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Incorrect, when the value they add relies on taking software owned by many other people and packaging it.
Their rights there are limited to the permissions given by the copyright holders, within the area of acts that copyright holders can control with licenses.
Posted Jun 23, 2023 10:21 UTC (Fri)
by khim (subscriber, #9252)
[Link] (20 responses)
Why are you looking on GPLv2? GPLv3 clarifies everything nicely: The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. GPLv3 explicitly spells out what RedHat is doing as legal and it's highly unlikely that any GPLv2-only project would ever try to sue RedHat.
Posted Jun 23, 2023 12:51 UTC (Fri)
by omgold (guest, #109541)
[Link] (19 responses)
Posted Jun 23, 2023 18:49 UTC (Fri)
by gfernandes (subscriber, #119910)
[Link] (18 responses)
Posted Jun 23, 2023 19:23 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (9 responses)
I'm not necessarily supporting the GP's viewpoint, but nobody is talking about any kind of a "right to a support service". It is merely said that depriving a subject of a privilege (in this case, a privilege of a support contract) simply because they decided to exercise one of their rights might be construed as pressure.
Posted Jun 23, 2023 20:13 UTC (Fri)
by pizza (subscriber, #46)
[Link] (7 responses)
If I publicly trash a company I'm doing business with, is it reasonable for them to choose to stop doing business with me?
I have the absolute legal right to say those things, so how dare they deprive me of the privilege of being their customer!
Posted Jun 24, 2023 9:02 UTC (Sat)
by ballombe (subscriber, #9523)
[Link] (6 responses)
Reasonnable, yes. Legal ? Not in all circumstance, not in all jurisdiction, fortunately.
There is also a thing called misappropriation of copyright that comes into play.
(Beside jumping straight to the first amendment is a US reflex I did not expect from you !)
Posted Jun 24, 2023 11:49 UTC (Sat)
by pizza (subscriber, #46)
[Link] (5 responses)
In nearly all jurisdictions and circumstances, you cannot be forced to do business with (or employ) someone.
The main exceptions are for "protected classes" which includes things like age, race, and disabilities. There are additional exceptions for regulated monopolies (eg utilities like power/water); they have to provide service to whomever pays.
Other than that, yes, business, just like individuals, have the general right to chose with whom they associate.
> SInce all news outlet are dependent on Microsoft software, none of them can afford to trash clippy ?
If there's a clause in the contract that says that, then sure. (Granted, this might not be a particularly wise thing to fight over; as the saying goes, "never argue with a man who buys ink by the barrel")
But back to the matter at hand -- One can waive all sorts of fundamental human rights in a voluntary contract, so agreeing to not exercise the minor right to distribute some software barely registers as a rounding error on the scale.
> There is also a thing called misappropriation of copyright that comes into play.
What, exactly, is Red Hat "misappropriating"? (Nevermind that copyright is "infringed". trade secrets are "misapproprated.")
Posted Jun 25, 2023 21:11 UTC (Sun)
by ballombe (subscriber, #9523)
[Link] (4 responses)
Not if you make a public offer of service.
> But back to the matter at hand -- One can waive all sorts of fundamental human rights in a voluntary contract,
Not in all jurisdictions. Look up "unconscionability".
>What, exactly, is Red Hat "misappropriating?
As a software author who has no contractual relation with RH, it is my right to license my software in such a way that users of my software enjoy some right related to them. RH deprives me of that right.
Posted Jun 25, 2023 21:42 UTC (Sun)
by pizza (subscriber, #46)
[Link] (3 responses)
Sure, and RH is doing precisely that. "I will do business to the public under these standard terms. If you don't like them, go elsewhere. If you violate these terms, we'll drop you as a customer." What exactly is wrong with this? Why should RH be prevented from having terms or conditions of service?
> Not in all jurisdictions. Look up "unconscionability".
In all jurisdictions, "unconscionability" requires coercion. There is none here.
> As a software author who has no contractual relation with RH, it is my right to license my software in such a way that users of my software enjoy some right related to them. RH deprives me of that right.
How is RH depriving you of the right to license your software as you wish?
Posted Jun 27, 2023 18:10 UTC (Tue)
by ballombe (subscriber, #9523)
[Link] (2 responses)
12 bis/ If you exert pressure or coercion on the recipient of the software (whether by law, contract, agreement, quid pro quo, thread of retaliation or otherwise) with effect of discouraging the recipient of exercising some of the right conveyed by this license, you lose the right conveyed by this license, whether or not the recipient decide to exercise them.
This is far-fetched, but I do not see this as complely illegitimate.
Posted Jun 27, 2023 20:23 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
I'd want to get such a clause checked over with the help of a copyright lawyer.
I agree with the principle, I'd just be concerned about the risk of creating unintended consequences that I didn't want (e.g. accidentally depriving someone of rights because the President of their country is putting pressure on them of the form "do as I say or your family gets tortured" and they put pressure on their downstreams accordingly), and that's where the lawyer helps.
I'd also not want to write the clause in a way where someone evil could say "you're putting pressure on me to not redistribute, because you'll only supply one USB stick with the software on it for free, and I want 1,000,000" and trigger it - again, lawyer can help draft it properly.
I also like paulj's suggestion that you only meet your obligations if you distribute the source publicly, not just to recipients of the binary, for the same idea - but again, would want a lawyer to help me get it right.
Posted Jun 27, 2023 21:15 UTC (Tue)
by khim (subscriber, #9252)
[Link]
This quickly turns into an how many angels can dance on the head of a pin? type of discussion. GPL was played with in a manner similar to what RedHat is doing from very early on. As I have already pointed out: Cygnus was created before Linus have ever dreamed about starting his Freax work. And it was critical for the success of GCC and then, later, GNU: that was how Cygnus earned money. In a hypothetical world where that would have happened chances are high that both GCC and Linux would have never grown to become something significant (indeed, Linux 0.01 RELNOTES says “You may not distibute this for a fee, not even "handling" costs”, without tit-for-tat GPL it would have never went anywhere). Which means that GPL had such clause from the very beginning we would have lived in a very different world. Would that have been BSD-based world or would have someone else invented copyleft? Hard to say, really. But one thing that we can say is that such license wouldn't have been used much at all in any world. And, of course, today it's much too late to try to add such clause.
Posted Jun 23, 2023 23:33 UTC (Fri)
by ballombe (subscriber, #9523)
[Link]
Posted Jun 23, 2023 20:45 UTC (Fri)
by pebolle (guest, #35204)
[Link] (7 responses)
It took me a while to figure out that FTBFS means "fails to build from source". It's a pretty common bug distributions run into. Are these actually GPL violations?
Posted Jun 23, 2023 21:37 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
> The "Corresponding Source" for a work in object code form means all
So it depends on the reason for the build failure:
* They forgot to include a file, update a build script, or some similar problem with the provided source: Probably a violation, but if it's quickly cured then I think nobody is likely to care.
Posted Jun 23, 2023 22:11 UTC (Fri)
by pebolle (guest, #35204)
[Link]
No it does not.
People can release totally defective code under the GPL and still adhere to the license.
Should I trawl the Linux kernel history for build failures? Perhaps I'll find a lawyer willing to take on an juicy target as your employer. As in: "I tried to build configuration Y on target X and it failed. Please wire me a gazillion dollars."
Posted Jun 24, 2023 0:16 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
Surely the only way to FTBFS is to have the source? And if it DIDN'T come with binaries, then it CAN'T be a GPL violation. The easiest way to comply with the GPL is to distribute as source, which discharges all the distributor's liabilities in one stroke.
Cheers,
Posted Jun 24, 2023 0:28 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (3 responses)
And does the GPL really demand that, in order to share code, I MUST share something I DON'T HAVE?
Cheers,
Posted Jun 25, 2023 13:59 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
(And of course, technically correct is the best kind of correct!)
Posted Jun 25, 2023 18:48 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Jun 26, 2023 9:58 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
You can, in fact, do that. As the copyright owner, you do not have to comply with the licence; you can thus give away a binary built only from sources you own the copyright on, but only permit onwards redistribution under GPL terms. As I do not have the source, nor do I have a way to get the source, I cannot redistribute legally.
There's a bit of care needed when doing this, to avoid tripping over estoppel-type concepts, where the court rules that because you've been confusing about what's allowed, I get to redistribute exactly what I got from you, but it can be done.
Posted Jun 26, 2023 9:30 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
To comply with the GPLv2, Red Hat will merely have to provide you – for a limited time – with the corresponding source code for any GPLv2-ed binaries that you already received from them. If you annoy them enough, Red Hat is perfectly within its rights to cut you off from future binaries and their corresponding source, because your access to binaries is not governed by the GPLv2 – it is governed by Red Hat's service contract.
The GPL is all about ensuring that source code is freely available, and therefore nothing in the GPLv2 says anyone must provide binaries at all, let alone provide binaries on an ongoing basis for the indefinite future. In particular, with or without a Red Hat service contract, you're still free to do anything the GPLv2 allows you to do with your existing GPLv2 sources, so section 6 of the GPLv2 is not infringed upon even if Red Hat decide they no longer want to do business with you.
Posted Jun 23, 2023 13:58 UTC (Fri)
by paulj (subscriber, #341)
[Link] (79 responses)
I.e., the ability to discharge source distribution requirements of the GPL by distributing /only/ to those you've given binaries to in the GPL is anachronistic and needs to be removed. It dates from a time when Internet access was not universal, and even when available could be very expensive.
RedHat is pretty good at making source available, but still plays games. There are much worse abusers of this unintended "We've discharged our GPL obligiations by giving source to our customer; whom we've also ensnared in a side-contract with punitive measures if they exercise their GPL rights to distribute" loop-hole in the GPL. E.g., I can think of a certain smallish company operating in open-source networking who have a business model built on this.
I would go further again and say that anyone who deploys modifications to copyleft software into "Production" should be obliged to publish those modifications to all. I.e., to counter the loophole large cloud providers effectively make use of, where they improve copyleft software internally but never give back - some of those companies consider it a competitive advantage (not just laziness and not having time).
Strong copyleft should move to something that model. E.g., https://github.com/pjakma/fopl
BSD for stuff you want to be used everywhere, as utility infrastructure for further development. Strong (in the above sense) copyleft for actual products. That's where my thinking is these days.
Posted Jun 23, 2023 14:13 UTC (Fri)
by pizza (subscriber, #46)
[Link] (11 responses)
HELL no.
There are innumerable practical (and legal!) problems with creating an obligation to potentially unlimited numbers of unrelated third parties.
> I would go further again and say that anyone who deploys modifications to copyleft software into "Production" should be obliged to publish those modifications to al
GPL gets its teeth from *copyright* law. If you don't "copy" (or create a derivative work based on) the software (beyond "the steps necessary to utilize the work") then there is literally no legal basis for that obligation, at least not without some sort of formal contract in place. Meanwhile, licenses that try to approach what you propose exist today, and have become little use beyond "poison pills" for dual-licensed products.
Posted Jun 23, 2023 14:34 UTC (Fri)
by paulj (subscriber, #341)
[Link] (10 responses)
The problem is companies have figured out how to hand-cuff customers, by using option 3 PLUS a side-contract with punitive measures. For me, that needs to be shut off. I dislike the fact there are companies who:
- Have made improvements to software I have contributed to
These companies figured out how (probabilistically at least) to restrict their improvements to copyleft software from making it back to the developers and the public. And I despise that, and those companies.
So option 3 needs to die in copyleft, and it should be just "distribute source to anyone who asks".
Posted Jun 23, 2023 20:50 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
I support that not with both hands, but with all three hands and legs and everything else. Because that's 100% sure way of making sure that free software would, finally, die off and would become just a footnote in history book. You may despise them all you want but these companies are the reason free software is not [completely] dead yet. The GNU crown jewel which kept it relevant for years is, undoubtedly, GCC. And you know what? It was always developed by people who did that thing that you despise. First it was Cygnus and then RedHat (when RedHat bought Cygnus). They always provided things to their subscribers which weren't available to others (e.g. RedHat's version of GCC actually provides that ability that developers want and need: to build your app with latest version of GCC yet still distribute it for that old distro 10 years of support). And that's both reason reason free software is not dead and reason people are buying these subscriptions. If you remove that… RedHat wouldn't die: I'm pretty sure Linus would explain how that's fine with him and that would protect kernel… and almost everything is replaceable. But story of free software movement would be finished at that point. No one would touch GPLed software ever again, except for a few hobbists… and they are not enough to keep GNU viable. Without these companies there would be no one who may keep that thing going. Is that what you want to achieve?
Posted Jun 24, 2023 10:25 UTC (Sat)
by paulj (subscriber, #341)
[Link]
In fact, I would want the ability of the original copyright holders to make use of that model /strengthened/ against the parasites. And what I describe would help with that.
Posted Jun 23, 2023 22:29 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
Posted Jun 23, 2023 23:21 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
"The Affero GPL is written with interactive network applications in mind, e.g., web applications. Its distribution obligations extend only to those who can actually interact with the covered software. Its unclear to me how this applies to non-interactive software, if at all.
It seems much simpler just to make it an unconditional requirement to publish the changes to software in use."
Posted Jul 2, 2023 11:49 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
This runs into export and ITAR controls (at least in the US; presumably other countries have similar issues). The US government does have some strong FOSS usage internally, but forcing that to be *public* would definitely curtail a lot of that use (some due to scared lawyers, but mostly probably due to nobody wanting to do the paperwork).
Posted Jun 24, 2023 9:24 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Most of the time developers don't bother to go looking for downstream modifications, they are too busy with upstream stuff. So just not posting pull requests upstream is often enough that upstream will never see it. It is surprising how many ostensibly FLOSS downstreams don't even bother to submit patches upstream. When I go looking, I even found things like Flathub have patches that aren't submitted upstream, of course traditional distros like Fedora and Debian do that too.
Posted Jun 28, 2023 9:21 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Jun 28, 2023 13:39 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Quoting GPLv3:
6. Conveying Non-Source Forms.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
So, it seems to me that the RHEL subscription system provides "equivalent access" to the SRPMs via the "same place" as the binaries, (eg downloadable via dnf/yum or via a WWW browser) "at no further charge." (This also means that if someone chooses to not download the source at the same time as they get the binaries, your source distribution obligation has ceased; they can't come back months or years later and demand sources under the GPL if you no longer offer binaries to them due to, say, an expired subscription)
(Yes, I realize this is GPLv3, and there's GPLv2-only stuff in RHEL, but I don't think there's anyone who would seriously take a stand on this particular hill. Either way, the "written offer" option can easily point people at a URL.)
Posted Jun 29, 2023 13:05 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link] (1 responses)
Have you tried asking RedHat directly for the source of their modified version(s) of the software(s) which you wrote? What was their response?
I would hope, that they would be receptive.
Posted Jun 29, 2023 13:19 UTC (Thu)
by paulj (subscriber, #341)
[Link]
That comment was about another company. And yes, I and others have tried to get access. Including trying to sign up as customers. But said company vets potential customers.
Posted Jun 23, 2023 14:25 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (23 responses)
WHICH WOULD KILL COPYLEFT STONE DEAD ON THE SPOT!
So if I, out of the goodness of my heart, give ONE person ONE copy of some copyleft software or other, I can now be subjected to an endless stream of *legal demands*, which for whatever reason or other I may be unable to comply with?
NOBODY in their sane mind would undertake that sort of risk.
Cheers,
Posted Jun 23, 2023 14:38 UTC (Fri)
by paulj (subscriber, #341)
[Link] (22 responses)
Also, it does NOT mean randoms can make endless legal demands. Only copyright holders can demand you meet your licence obligations, and take action if you do not.
Posted Jun 23, 2023 14:56 UTC (Fri)
by pizza (subscriber, #46)
[Link] (21 responses)
No, this is not something the GPL requires, at least not uncondtionally.
The GPL enumerates several options for supplying source code, and in v2, only one applies to "any third party". Notably, if you provide source code along with your binaries, or only source code, that discharges your legal obligations to everyone.
Under v3, the language is considerably better, and the rough equivalent clause to what's in v2 now applies to "anyone who possesses the object code" -- but that still only applies if you don't provide sources along with the binaries.
Posted Jun 23, 2023 16:12 UTC (Fri)
by paulj (subscriber, #341)
[Link] (20 responses)
It's so trivial that "publish sources automatically" is pretty much the /easy/ option, as evidenced by all the amateur hackers who routinely put their changes on $GIT_FORGE_SITES.
There is no good reason, in this day age, for companies distributing and profiting off other peoples' copyleft software to not do the same for the changes they make - and be obliged to do so.
Posted Jun 23, 2023 17:00 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
FWIW I completely agree with this.
> It's so trivial that "publish sources automatically" is pretty much the /easy/ option, as evidenced by all the amateur hackers who routinely put their changes on $GIT_FORGE_SITES.
It's not so trivial when your development practices are so sloppy that you have your SUPER SECRET SAUCE intermingled with the OS/platform/whatever bits. And rather than take the risk of exposing your SUPER SECRET SAUCE to the competition (and/or the lawyers of your perhaps-unintentional suppliers) plus the non-zero cost of the process change necessary to always publish sources and the effectively zero risk/penalty of just ignoring the GPL's obligations altogether, it's easy to see why hardly anyone bothers.
Posted Jun 24, 2023 10:14 UTC (Sat)
by paulj (subscriber, #341)
[Link]
Sloppiness isn't really an excuse to not publish the changes you made to other people's copyleft software, where those changes clearly have value - sufficient value at least for you to put those changes into "Production" or have others seek out your changes and contract with you to obtain them.
And the companies with business models that push the envelope on extracting value from open-source, while minimising what they give back, they're generally not sloppy and they know exactly what they're doing. It's a calculated choice by management.
Posted Jun 23, 2023 19:17 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (2 responses)
WHO SAYS THE DISTRIBUTOR IS A COMPANY? And "dirt cheap" depends on circumstances - what is dirt cheap for you might be beyond my means ...
Your original post said "anyone no ifs or buts". Now you're back-pedalling and talking about companies - which is discrimination and not permitted by FLOSS licences ...
What you WANT and what you CAN HAVE are usually two completely different things. This WILL bite you - it's called the "law of unintended consequences". And it is blatantly unfair - it is called "externalisation of costs". Otherwise often (if wrongly) referred to as "the tragedy of the commons".
I have no problem with you benefiting from my work if it costs me nothing. If you demand I pay you for the privilege of giving my work away, how many people do you think will bother?
Cheers,
Posted Jun 24, 2023 10:21 UTC (Sat)
by paulj (subscriber, #341)
[Link] (1 responses)
Now, if someone somewhere fails to do that, and they're not hurting me, am I going to care? No I am not. I am unlikely even to notice.
What I /care/ about is those who take copyleft software, modify it, and then profit from it (by use in their own cloud; or by distributing their changes to customers along with side-contracts with punitive measures making it difficult for customers to exercise their copyleft rights, and turning the changes into somewhat proprietary changes to copyleft software). These entities are parasites. And I want, if I'm in this position with my copyleft software again, to have a licence available to me that gives me the ability to take action. In the past, with GPL software, I could do nothing.
I call them "companies" because these entities invariably are companies. But the exact legal entity matters not.
Posted Jun 24, 2023 15:13 UTC (Sat)
by paulj (subscriber, #341)
[Link]
Posted Jun 24, 2023 0:14 UTC (Sat)
by jwarnica (subscriber, #27492)
[Link] (9 responses)
Posted Jun 24, 2023 10:31 UTC (Sat)
by paulj (subscriber, #341)
[Link] (8 responses)
Also, kids in their basement writing code almost universally will be posting it to github - cause it's so easy, and it means they don't have the expensive of running a server themselves somewhere. The kids that don't are using gitlab or some other forge.
So... the kids in the basement are already doing this as a matter of course, almost universally.
And even if the kid in the basement does not, if they're not running a business parasiting off some copyright holders code, is the copyright holder going to care? No. So it's a nothing burger.
The problem is commercial entities being parasites (by laziness or by intent), and having figured out ways around the GPL, or having business models the GPL never envisaged where distribution never occurs.
Posted Jun 26, 2023 9:55 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (7 responses)
There's two challenges to consider:
The "obvious" answer of "supplying combined source + binary packages ends your obligations" isn't good enough, because that enables BigCos to distribute combined source and binary internally, and never share their changes. Similarly, if you have a "no Internet" clause, you have to scope it very carefully so that BigCo can't set up a subsidiary that does the builds and extinguishes obligations to share because they get source in and binaries out on USB drives.
This feels like a tough set of questions to solve, and I'd love to chat to a copyright lawyer about it, if only I could find one who's interested in chatting about it for free, not as work :-)
Posted Jun 26, 2023 14:11 UTC (Mon)
by paulj (subscriber, #341)
[Link] (6 responses)
"
The licence at present might fail the Desert Island test. However, someone
I would like to add wording to permit the public distribution requirement to
## What about the Debian "Political Dissident" test?
See the above. Pretty much the same thing. Again, if I can find some
https://github.com/pjakma/fopl
Period: It's 24 months in that text at the moment.
And yes, I too would love to talk to a lawyer. Though, I also think both issues are largely moot in practical terms, as per above.
Posted Jun 28, 2023 4:13 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (5 responses)
There are many potential tests in this space too; people who get bullied when the publicly post code, anti-fascist organisations working against nazis, domestic violence victims sharing with their children, intelligence agencies hardening software for other departments/governments, consulting companies providing commercial advantage to their customers through custom features, and probably many more we can all think of.
Personally, I think freedom of association is more important than sharing software changes with the public.
Posted Jun 28, 2023 9:32 UTC (Wed)
by paulj (subscriber, #341)
[Link] (4 responses)
Sometimes with licences and grey areas it may be better to just have a requirement, and then let:
1. The licensor the discretion to decide if the circumstances around some technical violation are extenuating enough to ignore.
I.e., the licensor knows better than anyone what matters to them
2. The potential licensee to decide whether or not they feel comfortable enough with the licensor's judgement in matters of discretion, around the potential violation they feel they must commit and their circumstances justifying, to determine whether to use the software.
I.e., sometimes the difficult to enumerate special cases may be best left to the discretion of the licensors and licensees - rather than complicate the licence with vague, hard to interpret or enforce, likely full of holes, language that may fail to cover many cases anyway.
If you know of clear language that would still generally require public distribution, while giving the right exceptions, I'd love to hear it and incorporate it. Would be really useful.
Posted Jun 28, 2023 9:40 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Jun 28, 2023 9:46 UTC (Wed)
by paulj (subscriber, #341)
[Link]
It harms the main developers. A FOPL like "publish any valuable modifications" (where we can specify value by "good enough others obtained them from you, or you deployed into 'Production'") strengthens the original copyright holders against such parasites, and enables the business models khim has pointed out as being key to some of the biggest success stories in FOSS.
(RedHat is only a partial success story at best - outside of a one-time windfall they gave to FOSS developers of software in RHL, around when they IPOed, only very very few FOSS developers benefit from their success, and they are selective. It's quite possible you watch RedHat employ others, from outside your project, to work on your project, and they won't employ you).
Posted Jun 30, 2023 5:31 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (1 responses)
Posted Jun 30, 2023 9:44 UTC (Fri)
by paulj (subscriber, #341)
[Link]
Where you have some codified set of restrictions, those who may enforce or take action against any breach intrinsically have discretion to do so (modulo some other system that restricts them from /not/ taking action, etc.).
Posted Jun 25, 2023 14:05 UTC (Sun)
by pbonzini (subscriber, #60935)
[Link] (4 responses)
Posted Jun 26, 2023 9:28 UTC (Mon)
by paulj (subscriber, #341)
[Link] (3 responses)
This stuff is cheap and widely available these days.
And anyone who can't afford a cheap source forge thing, hasn't built a copyleft-parasitical business that is going to bother any copyright holder.
Posted Jun 26, 2023 9:46 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Besides, what if I was just a random guy in Nebraska, I died the day after GitHub banned me, and none of my heirs knows what source is, what a forge is and why you put a dollar sign in there. Should they risk being sued for three years?
Posted Jun 26, 2023 14:04 UTC (Mon)
by paulj (subscriber, #341)
[Link] (1 responses)
https://lwn.net/Articles/936004/
The condition in that licence is:
" Make the Source Code of all Your Deployed Modifications publicly
There is no requirement in that to make the source and binary be distributed from same place. Or even that that the place of distribution must remain unchanged over the period.
Posted Jun 26, 2023 14:08 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Jun 24, 2023 9:18 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
https://wiki.debian.org/DesertIslandTest
Posted Jun 29, 2023 8:30 UTC (Thu)
by milesrout (subscriber, #126894)
[Link] (41 responses)
But the whole point of the GPL is to allow users that get binaries to get source code, but to still allow companies like Red Hat to do exactly what they're doing. This isn't unintended.
> I.e., the ability to discharge source distribution requirements of the GPL by distributing /only/ to those you've given binaries to in the GPL is anachronistic and needs to be removed. It dates from a time when Internet access was not universal, and even when available could be very expensive.
It has nothing to do with the Internet. It's an intentional choice by GNU, designed to create a copyleft software licence that gives *users* of the software freedom. Not general access to source to everyone. Source code access to people that use the binaries. That's crucial! Why would someone that doesn't have access to software binaries need to have any access to the source code?
Posted Jun 29, 2023 8:50 UTC (Thu)
by paulj (subscriber, #341)
[Link] (39 responses)
The GPL was indeed structured to require that recipients of modified Free Software would receive or could obtain the modifications, and allow them to redistribute onwards - encouraging the spread.
As explained, the world has moved on. We have cloud companies and companies using restrictive side-contracts, who have figured out how to effectively make their modifications be lost to the rest of society. Their engineers and their customers can not (effectively) pass these modifications on.
Just as the world evolves, so can - and should - copyleft, to *CONTINUE* to serve that aim that RMS had.
Posted Jun 29, 2023 13:12 UTC (Thu)
by pizza (subscriber, #46)
[Link] (38 responses)
Still, requirements to force these cloud companies (etc) to make all source available will also bite everyone else -- Will I have to make all corresponding sources publicly available to the world because I'm using some copyleftplus software to process photos on my laptop? Will everyone running a Debian server behind their home/business/enterprise firewall be effectively forced to maintain their own public source mirror that the world+dog can access?
Requiring source distribution to "the world" regardless of the scope of binary distribution or scope of use is completely impractical. And I should point out that any scope-of-use restrictions run smack into "Freedom Zero".
Far smarter people than I have tried to come up with a solution to this and failed, badly.
Posted Jun 29, 2023 15:25 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
We need to stop doing business with these people, too.
Cheers,
Posted Jun 29, 2023 15:49 UTC (Thu)
by paulj (subscriber, #341)
[Link]
People will choose the licences they believe work best for them.
Note: The same person may choose permissive for one work, and strong copyleft [as intended with FOPL] for another work.
Posted Jun 29, 2023 15:42 UTC (Thu)
by paulj (subscriber, #341)
[Link] (35 responses)
There is no such requirement simply through use.
Posted Jun 29, 2023 17:34 UTC (Thu)
by pizza (subscriber, #46)
[Link] (34 responses)
And I quote:
"Deploy means to use, sublicense or distribute Covered Software other than for Your internal research and development (R&D) and/or Personal Use, and includes without limitation, any and all internal use or distribution of Covered Software within Your business or organization, except for R&D use and/or Personal Use, as well as direct or indirect sublicensing or distribution of Covered Software by You to any third party in any form or manner."
So, yeah, those requirements are triggered simply through "use". Trying to put exceptions for certian kinds of "use" makes that intention abundantly clear.
Posted Jun 29, 2023 19:02 UTC (Thu)
by paulj (subscriber, #341)
[Link] (33 responses)
The examples you gave did not imply modification:
"I'm using some copyleftplus software to process photos on my laptop? Will everyone running a Debian server behind their home/business/enterprise firewall be effectively forced to maintain their own public source mirror that the world+dog can access?"
The vast majority of Debian users havn't modified it, nor have most users of photo software.
My reply was in the context of your examples and, no, everyone running Debian would NOT have to also maintain a mirror.
Posted Jun 29, 2023 19:32 UTC (Thu)
by pizza (subscriber, #46)
[Link] (17 responses)
*compilation* counts as modification, because it's "creating a derivative work". And that license text states that a "Modifications means the Source Code and Executable form of any of the following: [...] B. Any new work that is based on, adapted from, or deriving of the Original Software or previous Modifications."
So, if I compile the software and use it, I have to publish the sources publicly. However, if I obtain the compiled binary from someone else (eg Debian), I don't have to publish the sources.
....It turns out that writing a license is really tricky!
Posted Jun 29, 2023 19:50 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Jun 29, 2023 20:08 UTC (Thu)
by paulj (subscriber, #341)
[Link] (4 responses)
So my understanding was the compilation does not result in a binary that is a derived work. The binary _is_ the work (deriving from the compiler too perhaps, but...). But ICBW.
Regardless, changing the wording to make the intent - deploying or distributing unmodified code shouldn't trigger source distribution requirement - clear would be good.
Thanks.
Posted Jul 2, 2023 16:43 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
What about a compiler with a builtin `-Dsome_internal_function=some_other_internal_function` definition (or similar)? The source isn't modified, but the interpretation is.
Posted Jul 3, 2023 10:49 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (2 responses)
Note that you have a potential loophole any time I can distribute a binary without source, where I can play a shell game to ensure that the entities you can pursue for damages don't deploy or distribute modified code, and the entity that modifies code stops existing the moment you try to get hold of the modified code.
If, instead, you put an obligation on all distributors of binaries to ensure source is available (similar to the one I've drafted in this pull request to your FOPL repo), then the loophole is closed. Note, too, that "ensure source is available" does not necessarily require you to host source yourself - if you get a binary from Debian, and you trust Debian to keep source available indefinitely, then you can rely on that safely. Similarly, in a commercial situation, you can pay Collabora to keep hosting source for the binary they gave you until 2 years after you stop using the binary, and thus not have a problem.
Where it gets murky is when binaries are being passed around between individuals - if I die unexpectedly, then sources I'm hosting may go offline. If you're depending on me to host source for a binary that I created as a modification of someone else's source code, and my hosting goes offline, you're now in a problem case - you may not even have bothered to get a copy of the source before the offlining event. But this is somewhere where I'd consider it reasonable to rely on the discretion of the licensors if it happened, since it's a rare case.
Posted Jul 3, 2023 12:03 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
So if they do modify source, they're under pressure to upstream it :-)
Cheers,
Posted Jul 3, 2023 12:43 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Then you get into the problem of defining "upstream source" sufficiently well to avoid the shell game, without other unintended consequences.
The shell game has party A modify the source, and distribute binaries. Party B gets source and binaries from A, and passes on an unmodified binary to party C. Party C is now in a position to claim that as far as they know, they're distributing binaries from unmodified upstream source; this is backed by an affidavit from party B that they are distributing the binary as supplied to them by party A.
You find out that party C is distributing a binary that doesn't match your source, and start the enforcement process; party C notifies party B who notifies party A, causing party A to be wound up by its owner. Now you have a problem - party C does not have source, but is distributing a binary that's unmodified from the sources party A published (but has stopped publishing now they're out of business). Party B has source, so can seed a new party A, but you've run out of enforcement options, since party B can also prove that they distributed a binary built from unmodified sources from A, and thus they do not have a requirement to publish source, either. Party A does have an obligation to publish their sources, but they no longer exist, so you can't enforce against them.
This is why I've proposed an "ensure people can get the source" requirement, instead of a "distribute sources" requirement - C is then requirement to make sure that people can get the source, but if A is distributing sources, then C meets their requirements by pointing to A's distribution, for as long as A continues to distribute. If A stops distributing, C can't do that any more, and has to find a new way to meet their obligations.
Posted Jun 29, 2023 22:19 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (10 responses)
That's what you say. The GPL, for example, seems to disagree – it talks about “the Program”, either “the Program's source code” or “the Program in object code or executable form”. This makes it clear that to the FSF at least, the source code and executable both represent the same work. Copyright law says that only “original works of authorship” are eligible for copyright, and a compiler isn't an author and does not produce original results (its output is algorithmically determined by its input), so compiling some source code does not make the resulting object code or executable a separately copyrightable work – if the executable is eligible for copyright at all, then only through its corresponding source code.
According to the GPL, a “work based on the Program” is “either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language” – where, given the previous paragraph, “another language” presumably means “source code language”: If the Program is in C and you (as a human author exercising creativity) rewrote it in Rust, for example, you'd be creating a “work based on the Program” that would still fall under the GPL because it is derived from the original C code.
Posted Jun 29, 2023 22:49 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Jun 29, 2023 23:36 UTC (Thu)
by pizza (subscriber, #46)
[Link] (8 responses)
A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work.”
( 17 U.S.C § 101 -- https://www.law.cornell.edu/uscode/text/17/101 )
While I'm sure that definition has been heavily augmented by case law over the years, I don't think anyone could seriously argue that compilation isn't "transformation" or "adaptation" of the source code into executable. But while that (algorithmic and deterministic) transformative compilation creates a derivative of the original work, I agree that it won't meet the creativity threshold for that derived work to become independently copyrightable.
If you think about it, this makes complete sense, and the likes of the GPL relies on the fact that binaries are derivative works of the source code. Because if they weren't, how could the GPL place conditions upon distributing binaries that you compiled yourself?
Posted Jun 30, 2023 0:11 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (7 responses)
That's easy. As far as the GPL is concerned, the source code and the binary represent the same work. Since distributing the work is something that normally, as per copyright law, only the original copyright holder gets to do, the copyright holder – through the GPL – says that as a special gracious exception it's OK for you to distribute the work (in source or binary form) only under certain conditions, which are slightly different for binaries vs. source.
Once more, the object code cannot be a “derived work” of the source code, because works can only be produced by human authors. Monkeys don't qualify, and compilers certainly don't qualify. The thing about “translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation,” etc. is that in all of these a certain amount of creativity and original thought, by humans, is at play. In addition, as you quoted, “A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ‘derivative work.’” (emphasis mine) – but compilers do not create “original works of authorship”; instead they perform a mindless sequence of uncreative, predetermined steps in order to make the source code of the work executable on a computer. Even if you performed the same sequence of steps yourself, as a human, this would change nothing because the compilation steps are not “editorial” – there is no creativity or authorship involved. Hence there is no way in which the executable could be considered a “derivative work” of the source code because it fails the most basic tests of what makes something a “work”, plus it isn't “derivative” in the sense prescribed by copyright law.
Posted Jun 30, 2023 1:20 UTC (Fri)
by pizza (subscriber, #46)
[Link] (6 responses)
They are not the same work; the binary is derived from the source code via a transformative means, ie compiling it.
Consider that a compiled program nearly always includes not just the result of the source code, but 3rd party bits generated or inserted by the compiler. This compiled program is therefore a combination of, and thus derived from, at least two independent works.
This notion of "executables derived from the compiler" is why libgcc, nominally under the GPL, includes an explicit permissive grant to make it clear that binaries resulting from combining your compiled source code with libgcc does not make the result fall under the GPL. [1]
Or are you going to claim that a binary containing bits from your code and bits from libgcc is not somehow derived from both sources?
That said, one can make a reasonable argument that the mechanical transformation process of compilation constitutes fair use [2] of the source code. But to claim fair use you have to concede that what you did was otherwise infringing (ie not permitted by the copyright holder).
Since the GPL excplitly places no restrictions on "use", only distribution, this distinction is moot. However, the FOPL text specifically calls out creating derivatives as something that has field-of-use restrictions.
[1] https://www.gnu.org/licenses/gcc-exception-3.1.en.html
Posted Jun 30, 2023 7:06 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
> They are not the same work; the binary is derived from the source code via a transformative means, ie compiling it.
But, legally, (because mathematically,) they are the same thing!
When you walk into a maths exam, you are given a question paper. Before you leave, you hand in an answer paper. Legally, as far as the law is concerned, their questions and your answers are THE SAME WORK (barring your mistakes, which are your creative input :-)
A binary bears the same relationship to the source as your answers do to their questions.
Cheers,
Posted Jun 30, 2023 11:51 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Source code is rarely purely functional/mathematical, so "mathematically equivalent" isn't "the same thing".
Posted Jun 30, 2023 9:29 UTC (Fri)
by paulj (subscriber, #341)
[Link] (2 responses)
ICBW, but I really did think that it had been established that the binary form of some compiled (as in computer software compiler - not copyright compilation ;) ) software was the /same/ work as any source it was compiled from. This was /not/ originally the case in the early days of software and copyright, IIUC, but then the courts brought in this notion that mechanical transformation (i.e. computer compilation) did not create a new work, but rather the output was the same work.
Posted Jun 30, 2023 9:31 UTC (Fri)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Jun 30, 2023 12:06 UTC (Fri)
by pizza (subscriber, #46)
[Link]
That said, creating that "combined work" is still something disallowed by copyright unless you have permission to do so.
Posted Jun 30, 2023 9:30 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
You obviously don't read what I write.
The executable can't be a “derived work” of the source code because it does not even qualify as a separate work in the first place. A “work” in the sense of copyright law must have a human author and its production must involve a certain minimum amount of original, bespoke creativity. Neither of these preconditions are satisfied by compiler output, which is produced from the source code by a machine (not a human) following a series of rote instructions (which leave no room for originality). As far as copyright law is concerned, the source code of a work and the corresponding binary code are the same thing. The relationship between the source code and the executable is like that between the printed text of a novel and the text of the same novel converted to Braille.
The sort of “derived work” you're thinking about arises, e.g., if a script writer turns a novel into a motion-picture script, or a translator translates an English novel into French. In both these cases, a human being comes up with a separate (but derived) “work”, presumably expending significant creativity in the process, and this is completely different from what a compiler does with source code.
Posted Jun 29, 2023 20:43 UTC (Thu)
by pizza (subscriber, #46)
[Link] (14 responses)
*compilation*, by virtue of creating a derivative work [1], counts as modification, due to this clause: "Modifications means the Source Code and Executable form of any of the following: [...] B. Any new work that is based on, adapted from, or deriving of the Original Software or previous Modifications."
So, if I compile the software and use it, I have to publish the sources publicly. However, you are correct that if I obtain the compiled binary from someone else (eg Debian), I don't have to publish the sources.
....It turns out that writing a license is really tricky!
[1] According to US copyright law, at least.
Posted Jun 29, 2023 21:22 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (13 responses)
And note that there's a loophole lurking here that we definitely want closed: Person A distributes source publicly until they cease to exist. Person B receives a binary from Person A, and forwards it to Person C unmodified, which does not trigger obligations on Person B or Person C. Person A and Person B then turn out to be subsidiary companies of a bigco, which are promptly dissolved.
Hey presto! I have a binary, built from modified sources, where the entity that breached the licence no longer exists to be pursued for copyright infringement, and where the two entities that do still exist and handled it. As Person C still exists, they can distribute the binary, since they haven't modified it, but they don't have the sources.
Yet more reasons to get a lawyer's help.
Posted Jun 30, 2023 9:42 UTC (Fri)
by paulj (subscriber, #341)
[Link] (12 responses)
An entity disappearing is a "loophole" for the GPL 3 year offer as much as for the FOPL. To fix that would require a condition to deposit changes with some specified custodian entity/entities.
Further, it's not really a loophole to worry about. The companies who are trying to (effectively) proprietise copyleft software modifications, do so as part of building some other longer-term business - e.g. a support or consulting business, or cloud. There is for the support/consulting model an explicit leveraging of /future/ relationship status. Such an entity can not avail of a loophole that involves shutting itself down.
Generally, companies trying to restrict their modifications to copyleft software are invested in future revenue from the capital they have invested into making those modifications, and so that isn't really a loophole of use to them, AFAICS.
Posted Jun 30, 2023 10:06 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (11 responses)
That loophole doesn't exist for the GPL 3 year offer, because each entity in the chain is required to provide sources themselves; if Person A disappears, then Person B and Person C are still on the hook for the sources if they distribute a binary. regardless of its modification status.
And the reason it's a problem is that, per the terms of the licence as you've described them, neither Person B nor Person C have to distribute the modified source, even if they possess it, while Person A does have that obligation, but no longer exists for you to enforce against. Person B exists basically so that when you chase Person C for compliance, there's someone who can pass on the sources they got from Person A (but do not have to share) to a new Person D, who takes the place of Person A in the loophole. Rinse, wash, repeat - Person C never shuts down and never has the sources to the binary they pass on, and is running the long term business. Person B exists solely to put Person C in the position of always simply passing on an unmodified binary and never actually having the sources themselves. Person A gets replaced every time there's an attempt to enforce compliance, and the new Person A is seeded by Person B with the modified sources obtained by Person B from the previous Person A.
The result is that I have Person C, who exists long-term, and supports the business case, but who never even has the sources to the modified binary. Person A gets closed down whenever there's a chance that they'll be asked where the sources are, and Person B can honestly say that they're passing on an unmodified binary from Person A to Person C, who distributes it widely. The company that owns all of A, B and C has the sources, including modifications, but you have no practical way to get at those modifications, since the entity doing the modification (and hence with the obligation to publish) stops existing when you try to get the modified sources, and is replaced by a new entity in the shell game
This is why the GPL says that if you pass on a binary, you also acquire obligations to pass on the source code to the people you give the binary to - in the same scenario, Person C has an obligation to pass sources onto you, and thus the fact that Person A has vanished with the sources just puts Person C in a position where they can't distribute the binary at all (modified or not).
Posted Jun 30, 2023 10:40 UTC (Fri)
by paulj (subscriber, #341)
[Link] (10 responses)
So what you're describing is some nefarious distributor of copyleft software, C. C has customers who come along needing modifications to copyleft software.
C has somehow arranged some hidden party to do this modification work for them, via a series of never-ending shell-companies, A_1, ..., A_n. So for customer D_i of C, needing some modification, C somehow arranges for A_i to implement this modification and pass only the /binary/ on to C along with a source offer from A_i, to give to D_i. A_i is then legally collapsed.
How does C induce this hidden party to do this, without any commercial obligation? How does the source code, containing all the modifications to the copyleft software made by A_1, ..., A_i get passed on to A_{i+1}, legally?
I don't see how the GPL prevents this either. Either C availed of 3c (GPLv2), in which case there can be no commercial relationship between B and C or C and D_i, or else C has an obligation themselves to distribute the source - and it's C's problem if they don't have it.
Further, aren't courts well capable of looking through corporate structures and examining the controlling interests? If the same controlling interest is there in A, B and C, well...
Posted Jun 30, 2023 11:08 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (9 responses)
No, I said that in your description of how your licensing offer works, no source obligation falls on B or C. Under the GPLv2 (and v3), both B and C have obligations to provide source since they're providing a binary - and provision of a binary in the GPL is enough to trigger the obligation to provide source.
There is a commercial relationship between A_j, B and C. Only A_x does modifications, and thus, under the terms you've described, only A_x is obligated to publish source code. B gets a binary from A_x with matching source, and is thus able to seed A_x+1 with source when A_x is collapsed. C only gets a binary from B, which was built by A_x.
When a customer of C wants changes made, C relays this to A_m, A_m makes the changes, gives B source and binary. B gives C a binary, which C gives to the customer. Because, under your scheme (but not the GPL) C hasn't modified the sources (indeed, C doesn't have sources to modify), they don't have an obligation to publish or provide sources at all. Under the GPLv2, they'd have to use 3a or 3b, because it's commercial distribution.
And the courts need a reason to "pierce the corporate veil"; if I tried to play this scheme under GPLv2 terms, with C saying they can't provide sources as required by 3a or 3b because B didn't provide source, that's enough for the courts to look at the ownership relationship and deem B and C to be the "same entity" for the purposes of this litigation (and thus require B to disclose source to me directly); in contrast, if C is claiming to not have published sources because it's shipping an unmodified binary it got from B, and B is claiming not to have published sources because it's shipping an unmodified binary it got from A_z, neither B nor C has breached the licence terms, and thus there's no reason to go deeper. The fact that A_z no longer exists (but there's now an A_f filling the same place in the shell game) means that the trail ended with "A_z were obligated to publish sources for 3 years, and did for as long as they existed. A_z no longer exists, so you cannot get compensation from them for their breach, which in any case happened after they were wound up."
Posted Jun 30, 2023 11:48 UTC (Fri)
by paulj (subscriber, #341)
[Link] (8 responses)
The simple answer here is that the definition of "You" and "Your" (i.e. the licensee) in the FOPL would consider A, B, and C to all be one and the same, if they have or are part of the same controlling entity, be that by ownership, management direction, or contractual obligations. The license is granted to one and all, and the obligations extend to one and all the same, or to none.
Further, there is no exception in the FOPL for non-commercial distribution. If you distribute, you must ensure the recipient is informed as to how to get the source code "in a reasonable manner on or through a medium customarily used for software exchange." - while the distributor /could/ point the recipient to a convenient other party providing the source, the /obligation/ remains on the distributor. Your Modifications you must publicly distribute yourself though (and "Your" would consider A,B,C one and the same - so A dissolving doesn't absolve C, cause C has common owners and/or contracts in place with those holding the source).
Maybe the text can be made more robust, suggestions definitely welcome.
Posted Jun 30, 2023 12:49 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (7 responses)
This is one where I'd definitely want a lawyer involved - by my understanding of your definition, if I paid Red Hat to provide me software, then I could end up being "one and the same" with Red Hat because the contractual obligations make us "the same controlling entity".
If the requirement is simply that I must make sure that the source for the binary I am distributing is published in a suitable public location for a minimum of 3 years from the date on which I distribute the binary, regardless of whether I modified it or not, then that's simple - if, in my shell game, Person C tries to claim that they can't do that, then Person C is infringing, and that's the lever needed to have the court open up the entire shell game.
If you try to allow wiggle room for someone who distributes an unmodified binary to not also be on the hook for the source, you open up a loophole. If my obligations are the same whether it's unmodified or modified, but they're limited to "ensuring that the source is published for a period of time", then the loophole closes.
Posted Jun 30, 2023 13:11 UTC (Fri)
by paulj (subscriber, #341)
[Link] (6 responses)
If you distribute a work under the FOPL (whatever form), you must ensure the Source Code is made available too to recipients. Potentially you can refer to someone else's distribution of the same Source Code, so far as is reasonable - the obligation towards the recipients you've distributed to is on you though. If the Source Code you referred to was hosted by someone else, and they go away, you'd better have somewhere else to point to or made a copy. (Would be my reading). There is no explicit limitation on duration, it comes down to reasonableness.
The obligation to publicly make available Modifications that you Deploy (deployed to production, or distributed) explicitly extends to 24 months.
Posted Jun 30, 2023 14:02 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
Talking about "control" over Red Hat is a difficult one to pin down - if I pay Red Hat for support, is that sufficient to give me "control", given that I can use my subscription to direct Red Hat to work on a specific problem for me?
It gets more complex with a consultancy like Collabora, too - I can pay them to work on any OSS problem, pretty much.
Depending on "reasonableness" for duration is also dangerous; you run the risk that one court rules that it's unreasonable for you personally to have taken down your mirror of source code 25 years after you last distributed a binary, because you should reasonably have known that BigCo depended on that mirror to meet their compliance requirements, while a different court rules that it's unreasonable to expect BigCo to keep their mirror up for more than the minimum specified time after deploying to production, since they've deleted the service that used the binary.
Also note that your reading doesn't matter, as the granter of a licence; if a licence is unclear, then in many jurisdictions, the courts are supposed to interpret it in favour of the person relying on it, not you. You need the licence text to be clear, so that the court has only one interpretation to choose from
I would, personally, change it to say that if you distribute or Deploy a binary, you must ensure that the "corresponding Source Code" (to steal language from the GPLv2) is publicly available for a minimum of 24 months after the last distribution or the time when the binary is deleted from production. That sets a nice clear requirement for compliance, biases people towards longer distribution times not shorter ("I think we've removed the binary from production - let's keep the source up, just in case") and has no wiggle room in it that a shell game can play with.
Posted Jun 30, 2023 15:19 UTC (Fri)
by paulj (subscriber, #341)
[Link] (4 responses)
Posted Jun 30, 2023 15:20 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
I've lost the link to where you keep this licence - mind resending it, and I'll give MRs/issues as I see appropriate?
Posted Jun 30, 2023 16:05 UTC (Fri)
by paulj (subscriber, #341)
[Link] (2 responses)
Thanks for your comments, and same for comments by pizza and others.
Posted Jun 30, 2023 16:13 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
It this were to gain any traction, it would need to have some legal input and feedback. Have you considered reaching out to folks like Richard Fontana who has worked on https://github.com/copyleft-next/copyleft-next and submit it to the FSF and OSI for their review?
Posted Jul 3, 2023 12:21 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Posted Jun 29, 2023 9:22 UTC (Thu)
by rschroev (subscriber, #4164)
[Link]
Posted Jun 23, 2023 6:52 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
They are certainly not acting like they accept the premise; they are actively harming their competitors.
> The problem is distros that add nothing, but merely clone RHEL in a bug-for-bug compatible way.
The point of the blog post is that FOSS means allowing all competitors, including clones that solely remove trademarks.
Posted Jun 23, 2023 10:33 UTC (Fri)
by jafd (subscriber, #129642)
[Link] (7 responses)
Here's how. There's a whole layer of proprietary software which is only built, tested, and guaranteed to work on RHEL, and which costs an arm and a leg to buy. Same for über-expensive hardware where drivers only exist for RHEL kernels (I don't know how it is today, and certainly the cloud has shaken this market a lot, but I know there used to be storage hardware for which binary-only drivers existed compiled for RHEL and nothing else). These vendors can benefit from RH providing THE stable-for-a-decade distribution, and Red Hat prospers by reinforcing being the only game in the town with such long support cycle and increasing their footprint. Companies are paying an arm and a leg for that specialised software/hardware already, so obviously they try to also avoid RHEL licensing costs if they can.
Now if the advantage of clones is gone, and given that the compatibility/stability landscape in Linux overall is way better than it has been 15 years ago (count in the whole static compilation/containerisation shebang), and there is Canonical as a competitor and Debian with a large footprint too, these vendors may consider very seriously to provide their software in other ways, since every platform is providing kinda sorta the same support cycle of 5 years as a baseline. Suddenly, providing two/three variants of binaries instead of just one is starting to make business sense, too.
In the end, the size of the pie RH is eating from is going to shrink by their own doing, and who knows if the small pie won't be smaller than the piece RH is enjoying today.
Posted Jun 23, 2023 12:29 UTC (Fri)
by pizza (subscriber, #46)
[Link]
The ones that are truly spending an arm and a leg for that specialized software just pay a few pennies more [1] and get RHEL.
But this isn't about those types of folks. This is about everyone else, that wants a stable, supported [2] platform that they can set up once and forget about for the better part of a decade, without paying for that privilege. [3]
[1] At $job-3, we paid about $50K/person/year for licenses to EDA software that "required" RHEL -- and that was after a hefty discount. RHEL licensing costs would amount to about 1/2 of a percent more.
[2] ie gets bugfixes for all those "gets their own branded web site" bugs
[3] This is the most important requirement.
Posted Jun 23, 2023 15:59 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (5 responses)
100% wishful thinking
Marketshare gained by providing über-expensive hardware or software on something else than RHEL: zero (people who buy über-expensive hardware or software do not care about the RHEL cost).
Money gained by providing über-expensive hardware or software on something else than RHEL: marginal (you can at best charge the difference between RHEL licensing and other OS licensing, why, you think vendors of über-expensive hardware or software would leave the difference in pricing to customers?)
Cost of supporting something else than RHEL: medium to heavy (more qa & support people, more releases cadences to deal with, yet another external partner to agree support contracts with)
Risk of supporting something else than RHEL: high (if you destabilize the steward of the platform you depend on, and bet on the wrong alternative, you will tank with your old platform).
Consider than after declaring their undying hate for distributions (all distributions, including the one you prefer) flatpackers promptly proceeded to build their own all-encompassing simili-distribution. That’s how much ISVs absolutely depend on platform stability and hate multiple competing platforms. Without platform stability, you can spend months preparing a new product, QA it, and then see all those efforts voided, and your competitors steal the show, because the platform you tested against is no longer the platform your customers chose.
ISVs absolutely *love* stable platforms with a stable company in the helm, often with a distant competitor to keep the main player honest, more than that and they’ll complain bitterly about platform fragmentation. Canonical’s entry in the business market did more to destabilize Suse than to harm Red Hat.
It’s the same with iOS vs Android, Playstation vs Xbox, there can be only two platform holders, being third is a miserable place, trying to be fourth will earn you the everlasting enmity of all the third party vendors that earn their livelihood on the main platform and depend on its stability marketshare-wise.
Posted Jun 23, 2023 16:09 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (1 responses)
Posted Jun 23, 2023 16:23 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
Posted Jun 23, 2023 16:33 UTC (Fri)
by jafd (subscriber, #129642)
[Link] (2 responses)
These same people employ beancounters who will jump on each and every possibility to cut costs and make their department perform better on the balance sheet.
Posted Jun 23, 2023 16:54 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (1 responses)
That is why once a platform is established its steward has to work real hard to make it tank. Otherwise risk-avoidance on ISV IHV and customer side makes the position quite secure.
Posted Jun 23, 2023 17:11 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
You want to launch a new platform ? You need to make it worth to ISVs and IHVs to release for your platform in addition to the existing ones, or you need to build enough substitutes yourselves that those ISVs and IHVs get irrelevant. They won’t jump ship just to save *you* a RHEL subscription.
Posted Jun 23, 2023 12:00 UTC (Fri)
by kragil (guest, #34373)
[Link] (1 responses)
Saying RHEL clones add nothing is just plain stupid. They find bugs, report them and help to get them fixed. They add documentation and certainly add value in many more ways.
Nothing is a big word, I am not sure that you know what it means.
Posted Jun 23, 2023 14:22 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Ask any astrophysicist, and I suspect they'll say that when you add up everything in the Universe, the sum total comes to nothing ... :-)
Cheers,
Posted Jun 23, 2023 20:06 UTC (Fri)
by developer122 (guest, #152928)
[Link] (2 responses)
The improvements to "the linux kernel, GNOME, gcc, systemd, and much else" are *charity work.* They bring in zero revenue.
Redhat is first and foremost a packaging company. They take software that others wrote and maintain, and package it for distribution.
To say that they understand "open source means giving up a monopoly" because they do charity work on the side is absurd.
Now, you might say "but they can't (or it's not right to) build a monopoly on the distribution of open source code!"
Posted Jun 23, 2023 20:23 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
In a general sense, no -- Those folks are also actively developing stuff that RH intends to eventually ship as part of RHEL, and those same people can be (and are often) retasked to provide the "support" that RH is selling.
> Redhat is first and foremost a packaging company. They take software that others wrote and maintain, and package it for distribution. They make money by selling official support for this package of the linux operating system. Now, they are trying to make money by having a monopoly on the distribution of this package and charging for access.
So... they're trying to make money by controlling the distribution of the software packaging (and maintaining, and updating, and testing) work that they have performed? How dare they!
You're arguing that RH's packaging (and maintaining/updating/teting) efforts have no inherent value, while simultaneously claiming that RH needs to widely provide those packages because they provides significant value. Come on.
Posted Jun 23, 2023 22:31 UTC (Fri)
by da4089 (subscriber, #1195)
[Link]
> In a general sense, no -- Those folks are also actively developing stuff that RH intends to eventually ship as part of RHEL, and those same people can be (and are often) retasked to provide the "support" that RH is selling.
My former company paid about USD100k/year for RedHat licensing.
We offered a hosted service product. It cost our customers between 100k and 10m annually to use it. We paid Red Hat because we knew that if there was a problem we weren't able to solve internally, we could call Red Hat support and get a "person who wrote the code" on the phone, and if needs be, on site, to solve our problem.
We had two reasons to pay for those RHEL licenses: we trusted their packaging and we trusted that if we needed their support, they would be better than us.
It might look like charity that RH pays salary, and conferences, etc for those people but it's absolutely not. It's the reason we paid $5k/box/year for advanced support.
Posted Jun 26, 2023 13:42 UTC (Mon)
by epa (subscriber, #39769)
[Link] (3 responses)
Obviously somebody receiving a copy of RHEL wouldn't have the support services from Red Hat, unless they paid for a support contract. That is the added value that Red Hat brings.
Posted Jun 26, 2023 13:50 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
The short answers: Because bug-for-bug is what everyone has cargo-culted themselves into wanting, they can't due to RH's trademarks, and it is.
> Obviously somebody receiving a copy of RHEL wouldn't have the support services from Red Hat, unless they paid for a support contract. That is the added value that Red Hat brings.
AFAICT, cutting off future updates is the only penalty for redistributing RHEL verbatim, though I'd imagine it would be a slam-dunk trademark lawsuit if someone really wanted to tempt fate.
Posted Jun 26, 2023 16:08 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Of course, there was all the trademark stuff, you had to strip that out if you wanted to be "bug for bug" compatible with SuSE.
The problem *there*, of course, was that YaST was not Free software back then. If you distributed it, you could not charge ANYTHING (for the media and associated items on it). So I could (quite legit) make copies and give them to my friends. If I were a consultant I could (quite legit) install copies on my customers' computers.
But there was no way I could have made a business stripping the trademarks and *selling* the result as "SuSE in all but name" - that would have been a copyright violation on YaST.
Cheers,
Posted Jun 26, 2023 21:46 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Actually it wouldn't. Red Hat CAN'T use trademark to stop you distributing an unaltered copy of Red Hat (including the Red Hat trademarks), because the trademarks are there to say "this is genuine Red Hat Product". And if it's an exact copy, that's what it is ...
That's why YaST solved that problem with a licence that said you can't charge a fee for anything containing a copy of YaST.
You might be able to claim COPYRIGHT on the trademark, but that would get you into a different legal battle - is a trademark even copyrightable, precisely because it is a purely functional device?
Cheers,
Posted Jun 23, 2023 20:23 UTC (Fri)
by gtb (guest, #3978)
[Link] (5 responses)
To my knowledge, Red Hat Enterprise Linux (RHEL) consists of several hundred Open-Source programs, bundled into a single coherent operating system by code Red Hat wrote. Red Hat, in turn, has always been releasing its "bundling code" under the GNU General Public License (GPL).
So what, if anything, do these new restrictions on Red Hat's _repositories_ change about this licensing policy? And if the answer is "nothing", what is to stop distributors like Alma Linux from simply buying the cheapest available RHEL license and using the code from its repository as before? I understand that distributors would still need to strip the RHEL code from everything that's trademarked, as before. But the code itself is _still_ GPL and they could _still_ use it -- no?
Posted Jun 23, 2023 21:10 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
Previously RedHat's source packages were available for everyone, but binaries were only given to people who purchased subscriptions. Today to get binaries you have to buy subscription and you get binaries and sources at the same time. And RedHat reserves the right to cancel you subscription if they would found out that you share binaries and sources you've got. You can still share what you received before subscription cancellation, but there would be no new, updated packages. Freely sharing sources without binaries was RedHat's innovation, Cygnus did the same thing that RedHat does today since it's inception (e.g. CygWin 1.0 is only available on CD, it's not distributed in any other form). They can. For some time. Enough for RedHat to firmly establish that they are using intermediary to circumvent terms of their subscription and would sue them. It may be quite interesting court case, actually. No one knows what will be the end result, but either way free software sage would end with it.
Posted Jun 24, 2023 20:22 UTC (Sat)
by gtb (guest, #3978)
[Link] (3 responses)
> They can. For some time. Enough for RedHat to firmly establish that they are using intermediary to circumvent terms of their subscription and would sue them.
Thank you for your thoughtful reply, khim! The part I just quoted actually leads directly to the point I don't understand. Two points, actually.
Point #1: Sue them for _what_? The recipients downstream from the intermediary haven't violated Red Hat's license, the GPL. Nor have they signed any ontract with Red Hat that would bar them from exercising their GPL-rights to the fullest. So what would Red Hat sue them _for_?
Point #2: How would Red Hat's prohibition on the intermediary not violate the GPL? The GPL explicitly decrees: "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License."
Source: https://www.gnu.org/licenses/gpl-3.0.txt
(The quoted part is under section 10, "Automatic Licensing of Downstream Recipients".)
So how is Red Hat not "impos[ing] a further restriction " by prohibiting that customers pass their code on? Surely, outright prohibitions are even more restrictive than fees and royalties, the GPL's own examples of restrictions it forbids.
Posted Jun 24, 2023 20:57 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
Because it's not imposing any restriction. It's merely saying that "if you do, we will cease doing business with you". It's your choice - Red Hat cannot do anything to you if redistribute RHEL. All they will (or can) do is refuse to do any further business with you. If that tanks your business, well, it was your choice to antagonise one of your partners.
Cheers,
Posted Jun 25, 2023 14:42 UTC (Sun)
by gtb (guest, #3978)
[Link]
cheers, Thomas.
Posted Jun 24, 2023 21:36 UTC (Sat)
by khim (subscriber, #9252)
[Link]
The important part is that recepient upstream is signing the contract which it doesn't intend to execute, which is called renunciatory breach. RedHat have the right to reject such contract and when someone induced such actions there are also regulations which allow one to prosecute that downstream recepient. It's like buying goods stolen from a supermarket. If you know that what you are buying are stolen goods, or, even worse, ask someone else to steal them for you then what you are performing is a crime — even if you, personally, never go near that supermarket. Why you are bringing GPL again and again? GPL is something between the copyright owner and the RedHat. Contract is between RedHat and downstream. These are two entirely different agreements and even if what RedHat is doing is an actual GPL violation it doesn't pardon downstream for their breach of contract. Because it doesn't stop you from using what you have already received from them. They just
say that if you want to continue to receive updates then you have to comply with the contract. How is it any different from, e.g., what SPEC is doing? Because SPEC explicitly makes it possible to distribute GPL components (but nothing else)? I think RedHat may add such exceptions. It may even add more devious exception and permit you to give away only these GPLed components that RedHat doesn't own 100%. Very fun game would ensue.
Posted Jun 23, 2023 9:15 UTC (Fri)
by jamespow (guest, #125052)
[Link] (5 responses)
Posted Jun 23, 2023 12:54 UTC (Fri)
by philbaker1 (subscriber, #151786)
[Link] (3 responses)
AlmaLinux: "In the immediate term, our plan is to pull from CentOS Stream updates and Oracle Linux updates to ensure security patches continue to be released."
Posted Jun 23, 2023 15:30 UTC (Fri)
by paavaanan (subscriber, #153846)
[Link] (2 responses)
Posted Jun 23, 2023 15:47 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
Well, in that press release, he did say this:
“I believe that open source should always be freely available and completely stable. It should never be hidden behind a paywall, nor should it be controlled by a single company,”
...Which does seem a little disingenuous given that the entire raison d'etre of RockyLinux is to precisely track a single company's commercial product.
Posted Jun 23, 2023 16:06 UTC (Fri)
by paavaanan (subscriber, #153846)
[Link]
Posted Jun 23, 2023 17:41 UTC (Fri)
by tmottabr (guest, #165728)
[Link]
Pay a team of people to reverse engineer the changes. Most stuff is likely from CentOS Stream anyway although not everything.
This is why Alma Linux even said that if they cannot find an alternative to get the sources directly from Red Hat they will use what they can get from CentOS Stream and the everything else they will wait and get from Oracle.
And honestly i really think Oracle Linux is the real target here, Alma Linux and Rocky Linux are just getting hit in the crossfire.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
If so how does RedHat dual licensing change this?
Or is it something else I'm missing?
AlmaLinux's response to Red Hat's policy change
(2) Oracle charge their customer support for rebadged RHEL
(3) Oracle pass the customers' bug reports to RH and do the minimum of support work themselves.
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
By which I clearly and obviously meant "either Red Hat allows Freedom 2, or it does not", as I said in my reply but you cut out. It makes no sense to blame Red Hat for the government's restrictions and no one would realistically think I meant that. But, fine, you also win a point for parsing the text to find a place where it doesn't explicitly disavow the most extreme and ridiculous positions. Congratulations.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
But if they provide a support contract then disallow it, and the material difference between users who are allowed to keep their support contract and those who are not is whether or not they take advantage of Freedom 2 with source code they got from Red Hat in a way that Red Hat doesn't approve of, then this is against the intent, at least, of the "no further restrictions" clause.
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
"... to hinder or prevent as if by effectual command"
AlmaLinux's response to Red Hat's policy change
The law forbids the sale of cigarettes to people under the age of 16.
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
it: this difference was a talking point and a legal theory of FSF, but that's not the direction case law has taken).
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
https://www.redhat.com/licenses/Enterprise_Agreement_Webv...
https://www.redhat.com/licenses/Appendix_1_Global_English...
> This Agreement establishes the rights and obligations associated with Subscription Services and is not intended to limit your
rights to software code under the terms of an open source license.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Doesn't matter that they don't forbid it, as the GP puts it, the GPL specifically forbids adding further restrictions. (Which, I'd strongly argue, this is) Besides which, it makes it mildly negligent to use Red Hat for any product you sell to a third party. (Because you yourself cannot distribute the code to the third party without breaking Red Hats rules...)
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
2. Red Hat would reserve the right in the contract to terminate the contract and keep the money if you request the source.
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
> Section 6 of the GPLv2 says: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
SInce all news outlet are dependent on Microsoft software, none of them can afford to trash clippy ?
I hope not.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
What point to give right to someone if they can just be blackmailed not use them ?
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
> the source code needed to generate, install, and (for an executable
> work) run the object code and to modify the work, including scripts to
> control those activities. However, it does not include the work's
> System Libraries, or general-purpose tools or generally available free
> programs which are used unmodified in performing those activities but
> which are not part of the work. For example, Corresponding Source
> includes interface definition files associated with source files for
> the work, and the source code for shared libraries and dynamically
> linked subprograms that the work is specifically designed to require,
> such as by intimate data communication or control flow between those
> subprograms and other parts of the work.
* Some weird system library incompatibility, compiler mismatch, or other thing that isn't a direct problem with the provided source: Probably(?) not a violation.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
- Make money selling that software, with those improvements, to customers
- Have figured out how to stop their customers ever passing said improvements on to me.
> For me, that needs to be shut off.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
[...cut out a-c...]
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
## What about the Debian "Desert Island" test?
on a desert island is unlikely to have reason to worry about being sued for
licence infringement.
be discharged by distributing to the widest audience physically possible, to
fix this, in a future version.
wording to exempt individuals from the distribution requirement who would
otherwise be put at clear risk to their human rights by state or corporate
actors, then I'll add such wording."
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
available under the terms of this License, for as long as you Deploy
the Covered Software or twenty-four (24) months from the date of
initial Deployment, whichever is longer; through a common and
customary form of distribution for source code (e.g. download from
a web site as a 'tar' archive, or via source-control-mechanism such
as git or hg).
"
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
https://wiki.debian.org/DissidentTest
https://people.debian.org/~bap/dfsg-faq.html
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
*compilation* counts as modification, because it's "creating a derivative work".
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Because if they weren't, how could the GPL place conditions upon distributing binaries that you compiled yourself?
AlmaLinux's response to Red Hat's policy change
[2] One prong of the four-part fair use test [3] is "Transformative uses are those that add something new, with a further purpose or different character, and do not substitute for the original use of the work."
[3] https://www.lib.purdue.edu/uco/fair-use
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
This is not Redhat's core business, and could be phased out with zero impact to the company's viability.
They make money by selling official support for this package of the linux operating system.
Now, they are trying to make money by having a monopoly on the distribution of this package and charging for access.
They have spend the last several years building a monopoly on the availability of the one thing of actual value, their packaging of others' code.
This is the latest step in the (attempted) consolidation of that monopoly.
And indeed, this is where you realize that Redhat doesn't actually understand at all.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
> So what, if anything, do these new restrictions on Red Hat's _repositories_ change about this licensing policy?
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
Wol
AlmaLinux's response to Red Hat's policy change
> The recipients downstream from the intermediary haven't violated Red Hat's license, the GPL.
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change
AlmaLinux's response to Red Hat's policy change