3 ms·

Isn’t GPL the HN’s favorite boogeyman? Boooooo, the license is not permissive enough. Boooo, is not true freedom. Boooo, whatever shall my poor startup with mil

Isn’t GPL the HN’s favorite boogeyman? Boooooo, the license is not permissive enough. Boooo, is not true freedom. Boooo, whatever shall my poor startup with millions in funding do if it’s GPL. Booo, but what about all those lost exposure points because Amazon/Google won’t be using it. But look how are the tables turned if it’s some other guy exercising his rights.

mike_hock 3y ago
> Boooooo [...] booooo Sorry, I fail to see how this addresses any of my points.
bayindirh 3y ago
> But look how are the tables turned if it’s some other guy exercising his rights. If we're talking about IBM/Red Hat here, they are not exercising their rights. Can they close the SRPMs? Yes they can. Can they tell "You can't redistribute this GPL licensed source code", haha, no. They can't even tell you to not redistribute BSD/MIT/Expat/WTFPL[0] code. They can't override these legal texts with EULAs. GPL is working as intended, and irritating corporations the way it should, and yes, what Red Hat done is treason, not because they closed the SRPMs, but the collective things they did. [0]: http://www.wtfpl.net/ http://www.wtfpl.net/
- joshuaissac 3y ago
  Red Hat's customers still have the right to redistribute the GPL-licensed source code from RHEL, but Red Hat may end their business relationship with them if that right is exercised. This is still in line with what the GPL requires of Red Hat.
  - bayindirh 3y ago
    Assuming what you say is true, isn't that threatening the customer to not exercise their rights? Isn't this limiting in a legal and practical sense? How this is ethical, and allows unimpeded distribution of FOSS code? Also, I still need to read and see the agreements myself.
    - joshuaissac 3y ago
      > I still need to read and see the agreements myself. See the 'termination' section of the enterprise agreements from the Red Hat licences page.[1] What constitutes a material breach is specified in Appendix I from the Product Appendices section, and it includes the redistribution of software obtained through the subscription (sections 1.2.f and 1.2.g of Appendix I). > How this is ethical, and allows unimpeded distribution of FOSS code? It is designed to discourage the distribution of the code while keeping Red Hat in compliance with the GPL. So it cannot prevent the customer from exercising their GPL rights, but a continued business relationship with the software vendor is not something that the GPL protects. PaX/grsecurity had used a similar tactic with their Linux kernel patches. 1. https://www.redhat.com/en/about/agreements https://www.redhat.com/en/about/agreements
  - geerlingguy 3y ago
    That's what most are concerned about. For a company that markets themselves as "open" or "the open source company", seeing their original massive OSS project now only achieve what's 'required' and nothing more... that doesn't seem in line with the expectation set over decades of more magnanimous behavior before.
    - eredengrin 3y ago
      > seeing their original massive OSS project now only achieve what's 'required' and nothing more If they were only doing "what's required" they would have ditched their upstream first approach to fixes and the only ones seeing their code would be paying customers, or people who the paying customers distributed the code to. The fact that they are still one of the primary contributors not only to the upstream linux kernel but countless other open source projects pretty much by definition means that they are still going well above and beyond "what's required". If you don't like their direction, fine, but pretending like they are entirely freeloading and doing nothing for the broader open source community really weakens your position.
  - usefulcat 3y ago
    One thing I've been wondering--if a RH customer decides to surreptitiously distribute the source, how is RH going to know which customer did it? I guess they could do something like making each copy of the source unique by slightly varying the non-string white space in the code. I guess the other issue would be that distributions like Alma or Rocky (and, to varying extents, their users) probably value stability and reliability too highly to be comfortable relying on such a janky form of source distribution.

mike_hock 3y ago

> Boooooo [...] booooo Sorry, I fail to see how this addresses any of my points.

bayindirh 3y ago

> But look how are the tables turned if it’s some other guy exercising his rights. If we're talking about IBM/Red Hat here, they are not exercising their rights. Can they close the SRPMs? Yes they can. Can they tell "You can't redistribute this GPL licensed source code", haha, no. They can't even tell you to not redistribute BSD/MIT/Expat/WTFPL[0] code. They can't override these legal texts with EULAs. GPL is working as intended, and irritating corporations the way it should, and yes, what Red Hat done is treason, not because they closed the SRPMs, but the collective things they did. [0]: http://www.wtfpl.net/ http://www.wtfpl.net/

joshuaissac 3y ago
Red Hat's customers still have the right to redistribute the GPL-licensed source code from RHEL, but Red Hat may end their business relationship with them if that right is exercised. This is still in line with what the GPL requires of Red Hat.
- bayindirh 3y ago
  Assuming what you say is true, isn't that threatening the customer to not exercise their rights? Isn't this limiting in a legal and practical sense? How this is ethical, and allows unimpeded distribution of FOSS code? Also, I still need to read and see the agreements myself.
  - joshuaissac 3y ago
    > I still need to read and see the agreements myself. See the 'termination' section of the enterprise agreements from the Red Hat licences page.[1] What constitutes a material breach is specified in Appendix I from the Product Appendices section, and it includes the redistribution of software obtained through the subscription (sections 1.2.f and 1.2.g of Appendix I). > How this is ethical, and allows unimpeded distribution of FOSS code? It is designed to discourage the distribution of the code while keeping Red Hat in compliance with the GPL. So it cannot prevent the customer from exercising their GPL rights, but a continued business relationship with the software vendor is not something that the GPL protects. PaX/grsecurity had used a similar tactic with their Linux kernel patches. 1. https://www.redhat.com/en/about/agreements https://www.redhat.com/en/about/agreements
- geerlingguy 3y ago
  That's what most are concerned about. For a company that markets themselves as "open" or "the open source company", seeing their original massive OSS project now only achieve what's 'required' and nothing more... that doesn't seem in line with the expectation set over decades of more magnanimous behavior before.
  - eredengrin 3y ago
    > seeing their original massive OSS project now only achieve what's 'required' and nothing more If they were only doing "what's required" they would have ditched their upstream first approach to fixes and the only ones seeing their code would be paying customers, or people who the paying customers distributed the code to. The fact that they are still one of the primary contributors not only to the upstream linux kernel but countless other open source projects pretty much by definition means that they are still going well above and beyond "what's required". If you don't like their direction, fine, but pretending like they are entirely freeloading and doing nothing for the broader open source community really weakens your position.
- usefulcat 3y ago
  One thing I've been wondering--if a RH customer decides to surreptitiously distribute the source, how is RH going to know which customer did it? I guess they could do something like making each copy of the source unique by slightly varying the non-string white space in the code. I guess the other issue would be that distributions like Alma or Rocky (and, to varying extents, their users) probably value stability and reliability too highly to be comfortable relying on such a janky form of source distribution.