Back

@smxi if at least developers used #GPL / #AGPL, the corporations at least were forced to contribute back in one way or an other, but due to the rampant use of MIT and BSD licenses, they can literally get away without doing anything beneficial for the wider ecosystem while using other people's code (those other people let them do it).

I think the proliferation of MIT and BSD licenses really made the #FreeSoftware free rider problem much worse than it should be.

@nicemicro valid use cases for bsd type licenses: single project (apache,nginx,openssh) where priority is get that tech into everything. Outside those you are working for free for corporations who will never give back. Truly freed code survives because you can't steal it without obligation. This stopped being a debate years ago:
#Gpl: linux,libreoffice,khtml>applewebkit>blink
Bsd/mit: Bsds,openoffice,mozilla

It's funny to see people pretend this is a debate when success of gpl transparent.

@smxi I think that the huge rate of burnout in developers that cause issues time and time again can be traced back to this attitude of "I will license it permissively to get it into everything". When the code gets into everything without compensation, the pressure of responsibility mounts, and bad things happen.

It is my personal belief that one's mental health doesn't worth the "bragging right" of one's code getting into a wide range of proprietary garbage.

@nicemicro to me the core mindbug is open source. Vs #FreeSoftware. If you fall for that trap then one license is as good as another so you'll burn out once reality sets in. I make free software to help the bits of free software ecosystem I can. Free software of course is open source by definition but as ibm-redhat recently showed us the contrary is not necessarily true. Since I've never had any interest in doing unpaid work for billion dollar corporations I used gpl from first day I found it.

@nicemicro Any company that avoids #gpl is openly admitting they want to take without giving back. Those are not desirable partners long term as has been proved over and over. Nor are they reliable or trustworthy. Every gpl project has a possible long term future builtin and every non enforced sharing license project can go like a poof of smoke because it has no true code permanence protection beyond last public commit. Like rhel is trying to do while stealing our code to use their stupid word

@smxi honestly, I don't really mind that much what RedHat is doing. No one is entitled to get updates to a software from you just because you gave them an earlier version.

As long as they don't restrict your GPL guaranteed rights for the software itself, they can condition the future business relationship with their customers on whatever they want.

@nicemicro You seem to be referring to how Red Hat conducted business before they shut down CentOS 8/9.

With their current setup, you as a paying customer get the binary packages, but you don't get the Complete and Corresponding Source Code for your packages.

All you get from them is "[it all comes from the git repos for CentOS Stream, some commits in there, you'll figure it out]". In theory you can find the information, but it's obscured for no reason other than obscuring.

If you redistribute what you got from them, as the GPL requires them to give you the right to do, they will terminate your support contract and access.

@smxi

@clacke @smxi The GPL does not have any clause that makes a user entitled to any future versions or any tech support.

Therefore, it is not a violation of the GPL to terminate business relationship based on an action that is allowed by the license but not allowed by the business agreement.

Red Hat can't come and take away the code they already gave you, and can't stop you redistributing it. They have all the rights to not talk to you any more though.

@nicemicro @smxi If the license requires them to allow redistribution, and if they ensure redistribution has negative consequences, then a reasonable bystander would say they are not allowing redistribution, but are in effect imposing "further restrictions".

But nobody has gone to court over it yet.

@clacke @smxi

I guess one could interpret that "termination of a service contract in case of redistribution" is "applying further restrictions".

My interpretation as a bystander is, that the service contract is an ongoing thing separate from the software, and it being contingent on "no redistribution" is not a restriction on the redistribution of the software itself. I accept though that it is not a 100% unambiguous thing, and could go either way in a jury trial.

@nicemicro @clacke https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/ you don't need to interprete this as an amateur bystander. Sfc did it already. Now if you want to pretend your opinion somehow carries more weight than professional free software license attorneys that's whatever but please remove my @smxi from your response since I respect experts in this area. As I said only people who ignore this seem to have direct financial or work relationship with ibm redhat or their products. Not interesting.

@smxi @clacke Thank you for the link. The article clearly states that there is an active disagreement on the specific issue of "firing a RedHat customer" for exercising rights guaranteed by the software license (paragraph 4, too long to quote here).

It seems to me, that the SFC's biggest worry is that this business model while might not directly violate the GPL, it is very easy to take a small extra step that does. And that is a worry I share and we should keep pressing they don't do it.