On Sunday, January 24, 2021 12:31 PM, Mike McGrath <mmcgrath at redhat.com> wrote: > On Sun, Jan 24, 2021 at 11:50 AM Josh Boyer <jwboyer at redhat.com> wrote: > >> On Sun, Jan 24, 2021 at 12:28 PM redbaronbrowser via CentOS-devel >> <centos-devel at centos.org> wrote: >>> >>> On Saturday, January 23, 2021 8:25 PM, Lamar Owen <lowen at pari.edu> wrote: >>> >>> > On 1/23/21 6:55 AM, redbaronbrowser via CentOS-devel wrote: >>> > >>> > > On Friday, January 22, 2021 4:38 PM, redbaronbrowser via CentOS-devel >>> > > centos-devel at centos.org wrote: >>> > > >>> > > > Just to clarify, you mean we should avoid redistributing RPMs not >>> > > > covered by the GPL/LGPL, right? >>> > > > For RPMs that are covered by the GPL and LGPL, it should not violate >>> > > > any agreement to redistribute those to anyone? As long as the form >>> > > > of redistribution doesn't claim the receiver is entitled to Red Hat >>> > > > support, anyone is entitled to the GPL/LGPL covered RPMs? >>> > > >>> > > Mike McGrath, I find it troubling a VP level member of Red Hat, Inc. >>> > > might be implying there exist people that are unentitled to GPL/LGPL >>> > > covered works. If you don't mind, I would like to see if I can get a >>> > > member of the Free Software Foundation involved. >>> > >>> > So, the way I read the subscription agreement and interpret it for >>> > myself and myself alone (that is, this is not legal advice and I am not >>> > a lawyer), redistributing material (any material, not just RPMs or SRPMs >>> > but things like subscriptin-only bugzilla content, kernel patchset >>> > reasons, etc) from my active Red Hat Enterprise Linux subscription is >>> > grounds for termination by Red Hat of my access to subscription >>> > content. They can't take away what I already have, but they can take >>> > away my ability to access future subscription content. >>> > >>> > In a nutshell: my interpretation for myself and myself alone is that I >>> > am free to redistribute the GPL-covered packages. Red Hat is also free >>> > to refuse to continue to do business with me. I thus make the choice to >>> > not redistribute. >>> > >>> > GPL does NOT require distribution to the public software that is >>> > distributed for a fee ( >>> > https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityToPublic >>> > ). If you do actually get a FSF staff member involved, they will >>> > probably tell you the same thing. >>> > >>> > Quoting Bradley Kuhn in a 2011 posting ( >>> > http://ebb.org/bkuhn/blog/2011/03/05/open-core-slur.html ): " I do have >>> > strong, negative opinions about the RHEL business model; I have long >>> > called it the "if you like copyleft, your money is no good here" >>> > business model. It's a GPL-compliant business model merely because the >>> > GPL is silent on whether or not you must keep someone as your customer. >>> > Red Hat tells RHEL customers that if they chose to engage in their >>> > rights under GPL, then their support contract will be canceled. I've >>> > often pointed out (although this may be the first time publicly on the >>> > Internet) that Red Hat found a bright line of GPL compliance, walked >>> > right up to it, and were the first to stake out a business model right >>> > on the line." (and the followup post at >>> > http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html is a good read) >>> >>> I agree with you and didn't expect a FSF member to say Red Hat is doing anything *legally* wrong. >>> >>> Put please re-read that FAQ answer again carefully: >>> >>> "If I distribute GPLed software for a fee, am I required to also make it available to the public without a charge? (#DoesTheGPLRequireAvailabilityToPublic)" >>> >>> "No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public." >>> >>> While it says Red Hat has no obligation to *directly* make GPL software publicly available, it indicates there should be the possibility of it being indirectly publicly available. >>> >>> What Mike McGrath is indicating Red Hat puts a chilling effect on that indirect redistribution of GPL/LGPL works to the "unentitled." >>> >>> So, my expectation is that the FSF member would try to explain why using the word "unentitled" goes against the *spirit* of the GPL/LGPL family of licenses. (And hopefully can phrase it better than I can). >> >> As a general reminder, the GPL and LGPL are source code licenses. The >> source code to the packages in Red Hat Enterprise Linux releases, GPL >> or otherwise, are released on git.centos.org, which requires no >> registration and no terms to accept. The recent announcements around >> CentOS Linux and CentOS Stream did not alter this approach. > > Thanks, Josh. I do have to point out that I made no claims about the GPL, LGPL, or even source code in my original response. It was simply one human talking to another human on a mailing list to try and come to a common understanding of what Red Hat considers ok and not ok. Unfortunately, my words continue to be parsed or taken out of context by some of the more anonymous members of this mailing list who continue to act in bad faith. I'll refrain from commenting on our license and terms in the future. > > For those that want to participate in the RHEL programs, you are all on your own to find whatever counsel you'd like to understand them. > > -Mike Ok, I seeked out counsel on these issues. Here is the findings I got from it. Anyone can make corrections if the counsel I got was invalid. I broke it up into Q&A format to make it easier to read. Q1) Can I have a mirror of RHEL for things like mock or network based installs? A1) Yes, but the EULA requires protecting without fail the Red Hat trademark that is included in all of the RPMs that make up RHEL Q2) Can other third-parties (such as a consultant or customer) access the mirror if they also have valid RHEL licenses? A2) No, the EULA restricts all redistribution of the trademark. Only exception requires a separate written agreement with Red Hat. Q3) What if the the redistribution is accidental such as a misconfiguration or data breach? A3) EULA provides no such exception, it still is the customer's responsiblity Q4) What if a data breach is because of a security issue with the RHEL software itself? A4) EULA provides no such exception Q5) Isn't only the redhat-logos package contain trademarks? A5) No, all RHEL packages specify Red Hat as the vendor in the RPM meta-data Q6) Can I replace that meta-data and then redistribute the modified package? A6) That would break the GPG digital signature. But there are also other instances of the trademark contained inside the RPM data which is a compress cpio archive. Q7) If I am willing to use my own GPG signing key, change the RPM meta-data, decompress and unpack the cpio and search/replace the trademark and then repack it back into a RPM, then can I redistribute it? A7) No, there are cases in which the trademark must remain such as copyright notices. It may no longer be a violation of the EULA to redistribute but it would be in violation of other licenses indicating the statement of copyright can not be modified. Q8) So, if I do everything in Q7 but carefully only replace specific instances of the trademark, then can it redistributed A8) Possibly. I couldn't find any case in which anyone has tried. If a de-branding contains any mistake then it would still be in violating of the RHEL EULA. The established practice is the rebuild with the CentOS provided debranding patches. Q9) If there is a EULA violation by mistake, what is the worst that could happen? A9) Red Hat can ban the user/customer forever from being a RHEL subscriber. They can also seek legal damages for the trademark violation. Q10) Why is Red Hat doing this? A10) I have no proof they are. This is a pessimistic worst case senario read of the EULA. It would also be hard to prove they never have banned someone from RHEL subscriptions for any of the above issues. Unlike a trademark lawsuit, a banning from business services does not involve any court record. Q11) What is a safe way to have a local package mirror for mock or network installs? A11) Stream does not involve the RHEL End User License Agreement at all. Using it instead of RHEL is the legally safest way to accomplish these goals. Hopefully this is helpful for detemining when/how to use RHEL and when to use Stream. I welcome any corrections. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210126/5331c0f9/attachment-0005.html>