Red Hat & Fedora -- largely stepping out of this ecosystem

[Jeff Law]

I have no illusions that this message is going to change anything at Red 
Hat.  But I feel I need to get this off my chest.  I'm speaking strictly 
for myself, not for my current or any former employer, not for the GCC 
project and not for any other group/organization I might have some 
affiliation with.

--


First a bit of background.  I came to Red Hat via the Cygnus 
acquisition.  My combined service spanned nearly 30 years.  During that 
time I had the opportunity to be involved in the formation of Fedora, 
strategic planning for RHEL while at the same time being able to spend 
much of my time on optimizing compilers.

I left Red Hat in 2021 to refocus on what I really enjoy in a small 
company where I can make a clear difference in the company's direction 
and success.  It was, by far, the most difficult decision in my 
professional career.  I left many friends and colleagues behind.

The point being I had a fantastic career at Cygnus/Red Hat.  I got to do 
and learn things I never could have imagined.  I got to work with many 
amazing people spanning many organizations within the company 
(engineering, sales, marketing, legal, product management, executives, 
etc).   By no means do I consider myself a disgruntled former employee.

--



What Red Hat has done recently is depressing, but not a huge surprise to 
me.  Red Hat struggled repeatedly with how to deal with "the clones". 
The core idea I always came back to in those discussions was that the 
value isn't in the bits, but in the stability, services and ecosystem 
Red Hat enables around the bits.  Arguments for protecting the bits were 
met with something like "if that's what we need to do to be successful, 
then we're failing to provide real value".

At some point in the last 20 years (I forget exactly when) Red Hat was 
looking to codify its values.  Naturally the topic of open source came 
up during those discussions.   When open source didn't make the cut, one 
could say the writing was on the wall -- open source was a means to an 
end.  In my mind that opened the door for numerous changes we've seen in 
subsequent years.

One could see signs of where this was going with the adjustments that 
were made to the exposed RHEL kernel sources some time ago.  Then the 
dissolution of CentOS a couple years back and most recently with the 
lockdown of the RHEL sources.

What Red Hat has done may be technically legal and perhaps good for its 
business.  However, to me it's ethically unconscionable.   Those who 
know me know I'm not an zealot, but I do have a baseline set of ethical 
values and Red Hat crossed that line.


--


Back in 2002 or 2003 when we were trying to figure out how to salvage 
the ill-fated "Red Hat Community Linux Project" resulting in what we now 
  know as Fedora, one of the key concepts that we pushed to the 
executive team at Red Hat was that it was strategically important for 
both Fedora and Red Hat to have a strong association with each other.  I 
think we largely succeeded in building that close association.


I've been a Fedora user since before FC1.  I run Fedora on my laptop. 
When I need a docker image for something, I start with a Fedora image. 
When I need to spin up a server (say to run the GCC CI/CD system) I load 
it with Fedora.   It's an ecosystem I'm technically comfortable in and 
easiest for me to utilize.

That will change across the board this summer.  That's a bit hard for me 
to swallow, but I can't get past that association we built between Red 
Hat and Fedora and Red Hat's recent actions.

I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a 
professional level.  Obviously, I'll do what I need to do to help make 
my employer successful -- but when a choice exists, Fedora/CentOS/RHEL 
won't be where I land going forward.

I wish it hadn't come to this, but I also can't say I'm terribly surprised.

Thanks for your time,
Jeff

[Peter Boy]

Thanks for your writing. A well-balanced and very thoughtful and considered opinion. But
your final decision seems to me rather a short-coming. 


>  Am 27.06.2023 um 00:47 schrieb Jeff Law
> <jeffreyalaw(a)gmail.com&gt;:
>  
>  ...
>  
>  
>  
>  What Red Hat has done recently is depressing, but not a huge surprise to me.  Red Hat
> struggled repeatedly with how to deal with "the clones". The core idea I always
> came back to in those discussions was that the value isn't in the bits, but in the
> stability, services and ecosystem Red Hat enables around the bits.  Arguments for
> protecting the bits were met with something like "if that's what we need to do to
> be successful, then we're failing to provide real value".
>  
>  At some point in the last 20 years (I forget exactly when) Red Hat was looking to codify
> its values.  Naturally the topic of open source came up during those discussions.   When
> open source didn't make the cut, one could say the writing was on the wall -- open
> source was a means to an end.  In my mind that opened the door for numerous changes
> we've seen in subsequent years.
>  
>  One could see signs of where this was going with the adjustments that were made to the
> exposed RHEL kernel sources some time ago.  Then the dissolution of CentOS a couple years
> back and most recently with the lockdown of the RHEL sources.
>  
>  What Red Hat has done may be technically legal and perhaps good for its business. 
> However, to me it's ethically unconscionable.   Those who know me know I'm not an
> zealot, but I do have a baseline set of ethical values and Red Hat crossed that line.
>   
I think there is a difference regarding the clones.

When Red Hat cancelled the academic licenses I switched all the servers I was responsible
for to Scientific Linux, one of the clones. As a public funded University we simply
couldn’t afford the new prices. And there was no such thing as "customers" for
us to pass on higher costs to. The results of our work are available to the company free
of charge.

But cases like OracleLinux, where a commercial company takes another company's work
and uses it to throw a competing commercial product on the market, are something else,
entirely. And they are to be evaluated differently beyond legal licensing issues.

And as much as I disapprove of Red Hat's decisions that led to the end of
ScientificLinux, at the same time I can kind of understand it. But more differentiation of
such circumstances would have been better.

Perhaps it is a quandary, unsolvable without compromise.


>  ...
>  
>  I've been a Fedora user since before FC1.  I run Fedora on my laptop. When I need a
> docker image for something, I start with a Fedora image. When I need to spin up a server
> (say to run the GCC CI/CD system) I load it with Fedora.   It's an ecosystem I'm
> technically comfortable in and easiest for me to utilize.
>  
>  That will change across the board this summer.  That's a bit hard for me to swallow,
> but I can't get past that association we built between Red Hat and Fedora and Red
> Hat's recent actions.
>  
>  I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a professional
> level.  Obviously, I'll do what I need to do to help make my employer successful --
> but when a choice exists, Fedora/CentOS/RHEL won't be where I land going forward.
I See, that outside of a professional level, you no longer want to deal with RHEL /
CentOS. But why Fedora? It’s „sponsored by Red Hat“, yes, but is not subject to the same
commercial and interest-based decisions (at least as far as I know). What's wrong with
continuing to contribute to and shape the future of Fedora, especially with your
independence of Red Hat?


—-
Peter Boy

[Carlos Rodriguez-Fernandez]

The distros that provide commercial support beside RedHat have been sort 
of doing something similar. Canonical provides Ubuntu LTS, a distro with 
5 years of development, and then additional 5 years of maintenance for 
those with subscription. SUSE, also, 5 years major release support for 
OpenSUSE where there is continuous development, and then if you want the 
full 10 years (with the additional 5 years of maintenance), you would 
choose SUSE Enterprise and paid the subscription fee.
Debian provides only 5 years cycle, and no support after that at all.

Red Hat is stopping the free 10 years cycle support provided by clones, 
and going the same route other distros are already in. The difference 
with RedHat is the fact that their free 5 years cycle distro (centos 
stream) is a tiny bit ahead of their subscription 10 years one (rhel). I 
personally don't see it as a deal breaker difference.
Am I missing something about the other distros?

I'm using CentOS Stream 9 hardened in production-level servers, and also 
in personal servers. The tooling, the community maturity, and the 
SELinux support of Enterprise Linux is much better than the alternative 
in my opinion.

I use Fedora for my personal workstation and my kid's computer, and what 
I love the most about Fedora is how it has become the vanguard in 
innovation among Linux distros.

RedHat is just being a for-profit company, aligning itself with the rest 
of Linux distros supported by a company. The only main difference is 
that their "free tier" is slightly ahead of their Enterprise 
subscription one. It depends how big of a deal that really becomes going 
forward, but so far I don't see indications that it will be a big deal. 
They have broken both in the past, the free and the paid.

Their contributions to opensource won't stop. The innovation in Fedora 
won't stop either. Jeff, I hope you reconsider your decision.

Regards,
Carlos R.F.

On 6/27/23 07:40, Peter Boy wrote:
>  Thanks for your writing. A well-balanced and very thoughtful and
> considered opinion. But your final decision seems to me rather a short-coming.
>  
>  
> > Am 27.06.2023 um 00:47 schrieb Jeff Law <jeffreyalaw(a)gmail.com&gt;:
> >
> > ...
> >
> >
> >
> > What Red Hat has done recently is depressing, but not a huge surprise to me.  Red Hat
> struggled repeatedly with how to deal with "the clones". The core idea I always
> came back to in those discussions was that the value isn't in the bits, but in the
> stability, services and ecosystem Red Hat enables around the bits.  Arguments for
> protecting the bits were met with something like "if that's what we need to do to
> be successful, then we're failing to provide real value".
> >
> > At some point in the last 20 years (I forget exactly when) Red Hat was looking to
> codify its values.  Naturally the topic of open source came up during those discussions.  
> When open source didn't make the cut, one could say the writing was on the wall --
> open source was a means to an end.  In my mind that opened the door for numerous changes
> we've seen in subsequent years.
> >
> > One could see signs of where this was going with the adjustments that were made to
> the exposed RHEL kernel sources some time ago.  Then the dissolution of CentOS a couple
> years back and most recently with the lockdown of the RHEL sources.
> >
> > What Red Hat has done may be technically legal and perhaps good for its business. 
> However, to me it's ethically unconscionable.   Those who know me know I'm not an
> zealot, but I do have a baseline set of ethical values and Red Hat crossed that line.
> >
>  
>  I think there is a difference regarding the clones.
>  
>  When Red Hat cancelled the academic licenses I switched all the servers I was responsible
> for to Scientific Linux, one of the clones. As a public funded University we simply
> couldn’t afford the new prices. And there was no such thing as "customers" for
> us to pass on higher costs to. The results of our work are available to the company free
> of charge.
>  
>  But cases like OracleLinux, where a commercial company takes another company's work
> and uses it to throw a competing commercial product on the market, are something else,
> entirely. And they are to be evaluated differently beyond legal licensing issues.
>  
>  And as much as I disapprove of Red Hat's decisions that led to the end of
> ScientificLinux, at the same time I can kind of understand it. But more differentiation of
> such circumstances would have been better.
>  
>  Perhaps it is a quandary, unsolvable without compromise.
>  
>  
> > ...
> >
> > I've been a Fedora user since before FC1.  I run Fedora on my laptop. When I need
> a docker image for something, I start with a Fedora image. When I need to spin up a server
> (say to run the GCC CI/CD system) I load it with Fedora.   It's an ecosystem I'm
> technically comfortable in and easiest for me to utilize.
> >
> > That will change across the board this summer.  That's a bit hard for me to
> swallow, but I can't get past that association we built between Red Hat and Fedora and
> Red Hat's recent actions.
> >
> > I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a professional
> level.  Obviously, I'll do what I need to do to help make my employer successful --
> but when a choice exists, Fedora/CentOS/RHEL won't be where I land going forward.
>  
>  I See, that outside of a professional level, you no longer want to deal with RHEL /
> CentOS. But why Fedora? It’s „sponsored by Red Hat“, yes, but is not subject to the same
> commercial and interest-based decisions (at least as far as I know). What's wrong with
> continuing to contribute to and shape the future of Fedora, especially with your
> independence of Red Hat?
>  
>  
>  —-
>  Peter Boy
>  
>  
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Frank Ch. Eigler]

Jeff Law <jeffreyalaw(a)gmail.com&gt; writes:

>  [...]
>  First a bit of background.  I came to Red Hat via the Cygnus
>  acquisition.  [...]
>
>  One could see signs of where this was going with the adjustments that
>  were made to the exposed RHEL kernel sources some time ago.  Then the
>  dissolution of CentOS a couple years back and most recently with the
>  lockdown of the RHEL sources.
>
>  What Red Hat has done may be technically legal and perhaps good for
>  its business.  However, to me it's ethically unconscionable.   [...] 
Could you elaborate how you see RH's new policy w.r.t. RHEL sources
being different from Cygnus's policy w.r.t. GnuPro sources?


- FChE

[Lee Thomas Stephen]

There was a time when IBM had a popular PC but no popular OS.
Now IBM has a popular OS but no popular PC.
Just an observation.

---
Lee

On Tue, Jun 27, 2023 at 10:24 PM Frank Ch. Eigler <fche(a)redhat.com&gt; wrote:

>  Jeff Law <jeffreyalaw(a)gmail.com&gt; writes:
>
>  > [...]
>  > First a bit of background.  I came to Red Hat via the Cygnus
>  > acquisition.  [...]
>  >
>  > One could see signs of where this was going with the adjustments that
>  > were made to the exposed RHEL kernel sources some time ago.  Then the
>  > dissolution of CentOS a couple years back and most recently with the
>  > lockdown of the RHEL sources.
>  >
>  > What Red Hat has done may be technically legal and perhaps good for
>  > its business.  However, to me it's ethically unconscionable.   [...]
>
>  Could you elaborate how you see RH's new policy w.r.t. RHEL sources
>  being different from Cygnus's policy w.r.t. GnuPro sources?
>
>
>  - FChE
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[David Duncan]

>  I have no illusions that this message is going to change anything at
> Red 
>  Hat.   
It's not really for us as community members to identify a business path and that is a
convenience factor that we typically rely upon to work on things that begin as
experimental and a learning path only to grow into something more reliable and
service-ready. 


>  First a bit of background.  I came to Red Hat via the Cygnus 
>  acquisition.  My combined service spanned nearly 30 years.  During that 
>  time I had the opportunity to be involved in the formation of Fedora, 
>  strategic planning for RHEL while at the same time being able to spend 
>  much of my time on optimizing compilers.
>   
Thank you for your contributions over the years and for continuing to do work at such a
low level. It helps the rest of us stay focused on delivering a great experience to users
knowing that the subsystems we rely upon are not going to fail us and that they deliver
the best performance possible. 

>  --
>  What Red Hat has done recently is depressing, but not a huge surprise to 
>  me.  Red Hat struggled repeatedly with how to deal with "the clones".  
[.
. .]
>  Arguments for protecting the bits were 
>  met with something like "if that's what we need to do to be successful, 
>  then we're failing to provide real value".
>   
I disagree that this is "protecting the bits. The bits are equally available to all
and that's how we do what we do in this Fedora community. I see it as more of a hard
nudge from the comfortable nest of a basic rebuild to determine a pathway forward as a
clone. This is not a bad time to do it. As we move towards more immutable systems and the
use of container-based workloads in production - it's time to ask after whether or not
we should deemphasize these paths forward. This probably sounds bizarre coming from
someone who works hard to preserve the cloud edition experience side by side with the
immutable FCOS and IOT editions, but I recognize that there are places for both and that
the sun will eventually set. 

Furthermore, the CentOS Stream process is stabilizing and consistent with the goals of the
community. I was at devconf.cz recently and I sat down with Tomas and Nikolas from the
Packit team to really dig in to how I can make packit and copr work for more rapid
development and how I can ensure that my builds are consistent with the goals of both the
upstream and downstream communities. 

In my experience with the CentOS community, I have spent countless hours helping users
taint the very kernel they declare they want to preserve to get the results that are
already built into the CentOS Stream experience. I think, just like Mike McGrath and
probably a lot of people, that this is the best code base to expose and that we should be,
as a community, determining how to roll forward. Sure there will be requirements for
freezing support, but there are mechanisms for this already - os-build will give you a
resource for experimentation. There are package manifests to ensure consistency between
states, but just generally, users push forward with the systems they don't purchase
support to run. I am not saying there aren't reasons to freeze updates, etc. There
are, but as CentOS Stream _is_ RHEL in it's next form it is also representative of
where RH would like the community to be. If we as a community care about our evolution,
then the clones should care about it as well. If Red
  Hat as a sponsor identifies that the bar is better set at CentOS Stream it is more a
statement on where they believe that CI/CD and Quality Engineering has set the bar for
user stability. 


>  Back in 2002 or 2003 when we were trying to figure out how to salvage
>
>  the ill-fated "Red Hat Community Linux Project" resulting in what we now 
>    know as Fedora, one of the key concepts that we pushed to the 
>  executive team at Red Hat was that it was strategically important for 
>  both Fedora 
Exactly! And projects like Fedora ELN that Stephen Gallagher, et. al., have dedicated
themselves to supporting are only bringing it closer. 

>  I've been a Fedora user since before FC1.  I run Fedora on my
> laptop.  
I was not as much a part of the division as you were, but I was there as a community
member and contributor. I was out in the field though, putting it on systems that replaced
routing for T1 lines with Fractional T1s and DSL that eventually turned my business users
into Red Hat customers. I get the appeal of a strong union between the two. 

>  That will change across the board this summer.   
[. . .]

I don't see the change, on the contrary, I see a more unified community rallying
around the special interests of the clones similar to the way the Hyperscale SIG unifies
the more advanced requirements of fail-only architectures in CentOS Stream right now.
Those same contributors to the Hyperscale SIG are also supporting work on Fedora Asahi and
Fedora ELN just as fast! ( I am looking at you Davide and Neal). I am betting on the
community to welcome the clones and help them find their dividing lines as well as accept
their fixes and assist them in their CI and validations.  This Red Hat decision didn't
exclude the clones, it just made the fact that the bar has been set higher for community
participation a more clearly defined action IMO. 

>  
>  I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a 
>  professional level.  Obviously, I'll do what I need to do to help make 
>  my employer successful -- but when a choice exists, Fedora/CentOS/RHEL 
>  won't be where I land going forward. 
So I am terribly surprised by the statement that you won't be coming with us. I see
you as someone who could really help the clones be a part of the community and help them
navigate the early introduction into the CentOS Stream and ELN communities.  If you ever
decide to return as a Fedora/CentOS/RHEL user for your own reward, I'll be in the line
that welcomes you back and looks forward to your help. 

-- 
David Duncan

[Carlos O'Donell]

On 6/26/23 18:47, Jeff Law wrote:
>  What Red Hat has done may be technically legal and perhaps good for
>  its business.  However, to me it's ethically unconscionable.   Those
>  who know me know I'm not an zealot, but I do have a baseline set of
>  ethical values and Red Hat crossed that line. 
Why is it ethically unconscionable? There is a lot of confusion around
what has happened and why. What you are saying, and what actually happened
don't line up in my mind :-)

-- 
Cheers,
Carlos.

[Leon Fauster]

Am 29.06.23 um 17:49 schrieb Carlos O'Donell:
>  On 6/26/23 18:47, Jeff Law wrote:
> > What Red Hat has done may be technically legal and perhaps good for
> > its business.  However, to me it's ethically unconscionable.   Those
> > who know me know I'm not an zealot, but I do have a baseline set of
> > ethical values and Red Hat crossed that line.
>  
>  Why is it ethically unconscionable? There is a lot of confusion around
>  what has happened and why. What you are saying, and what actually happened
>  don't line up in my mind :-)
>   

Well, lets start just (and that alone is reprehensible) with untrue 
sentences  that just miscredited the open EL-community (open 
EL-community == all without RH and RH customers). Its just a slap in the 
face of contributers, EPEL maintainers (non @redhat.com owners) and so 
on ...
This is just done to have a bigger gap in the reasoning argumentation.
This is FUD tactic and dignityless for RH. They have reasonable 
arguments to do what they do, but the "style" is ethically unconscionable.


-- 
Leon

[Todd Zullinger]

Carlos O'Donell wrote:
>  On 6/26/23 18:47, Jeff Law wrote:
> > What Red Hat has done may be technically legal and perhaps good for
> > its business.  However, to me it's ethically unconscionable.   Those
> > who know me know I'm not an zealot, but I do have a baseline set of
> > ethical values and Red Hat crossed that line.
>  
>  Why is it ethically unconscionable? There is a lot of confusion around
>  what has happened and why. What you are saying, and what actually happened
>  don't line up in my mind :-) 
Something I'm having trouble with is Red Hat's position that
you can choose to be a customer or to exercise your rights
under the GPL, but you cannot be both.

I don't know how to view that as anything other than
sacrificing the spirit of F/OSS to help the books.

I am sympathetic to the odd/difficult nature of running a
business based on F/OSS.  Until now I thought Red Hat was
doing it pretty well.

I thought Jeff's message was well written.  I am still
struggling with whether I should take the same path. :(

-- 
Todd

[Paolo Bonzini]

> > On 6/26/23 18:47, Jeff Law wrote:
> >> What Red Hat has done may be technically legal and perhaps good for
> >> its business.
>  
>  Something I'm having trouble with is Red Hat's position that
>  you can choose to be a customer or to exercise your rights
>  under the GPL, but you cannot be both. 
The thing is, many people are learning this only now, because things 
indeed have become tougher for people who prepare the RHEL rebuilds, but 
this is not new.  _Nothing_ in the service agreement or in any other 
legal document has changed since last week, the exact same terms have 
been applicable to the extended-support branches since the beginning of 
RHEL.  In fact, as Frank pointed out elsewhere, this is something that 
other companies have been doing for decades as well.

For all the people that are complaining only now that the free beer part 
is taken away, I can't help thinking that it's a bit disingenuous to 
make it about "free as in freedom", when that clause has existed forever.

(As an aside, the service agreement also mentions that any open source 
license overrides the service agreement if needed.  So by definition 
this might be void but it certainly is not a GPL violation).

Paolo

[Piotr Szubiakowski]

Hey!

On Thu, 2023-06-29 at 19:12 +0200, Paolo Bonzini wrote:
>  
>  > > On 6/26/23 18:47, Jeff Law wrote:
>  > > > What Red Hat has done may be technically legal and perhaps good
>  > > > for
>  > > > its business.
>  > 
>  > Something I'm having trouble with is Red Hat's position that
>  > you can choose to be a customer or to exercise your rights
>  > under the GPL, but you cannot be both.
>  
>  The thing is, many people are learning this only now, because things 
>  indeed have become tougher for people who prepare the RHEL rebuilds,
>  but 
>  this is not new.  _Nothing_ in the service agreement or in any other 
>  legal document has changed since last week, the exact same terms
>  have 
>  been applicable to the extended-support branches since the beginning
>  of 
>  RHEL.  In fact, as Frank pointed out elsewhere, this is something
>  that 
>  other companies have been doing for decades as well.
>  
>  
In my opinion, people haven't complained about service agreements
because, till recent changes, RHEL sources were available publicly. The
only important contract was the open-source license of the software.
Now we have both the license of the software and the service agreement.

>  For all the people that are complaining only now that the free beer
>  part 
>  is taken away, I can't help thinking that it's a bit disingenuous to 
>  make it about "free as in freedom", when that clause has existed
>  forever.
>  
What do you mean by "free beer part"? Isn't open-source software free
of charge? Does anybody pay for it?

The question is if RHEL software is still open-source or closed-source. 
At least if I look at the OSI's [1] definition of Open Source, the
situation isn't clear to me.

>  
>  (As an aside, the service agreement also mentions that any open
>  source 
>  license overrides the service agreement if needed.  So by definition 
>  this might be void but it certainly is not a GPL violation).
>  
>  
Yeah, it's hard to say which rules of service agreement are overwriten
by software licenses. Especially that there are quite a few licenses
shipped with the distribution.

Cheers,

Piotr

[1] OSI Open Source Definition

   Introduction

   Open source doesn’t just mean access to the source code.
   The distribution terms of open-source software must comply with the
   following criteria:
   1. Free Redistribution

   The license shall not
   restrict any party from selling or giving away the software as a
   component of an aggregate software distribution containing programs
   from several different sources. The license shall not require a
   royalty or other fee for such sale.
   2. Source Code

   The program must
   include source code, and must allow distribution in source code as
   well as compiled form. Where some form of a product is not
   distributed with source code, there must be a well-publicized means
   of obtaining the source code for no more than a reasonable
   reproduction cost, preferably downloading via the Internet without
   charge. The source code must be the preferred form in which a
   programmer would modify the program. Deliberately obfuscated source
   code is not allowed. Intermediate forms such as the output of a
   preprocessor or translator are not allowed.
   3. Derived Works

   The
   license must allow modifications and derived works, and must allow
   them to be distributed under the same terms as the license of the
   original software.
   4. Integrity of The Author’s Source Code

   The
   license may restrict source-code from being distributed in modified
   form only if the license allows the distribution of “patch files”
   with the source code for the purpose of modifying the program at
   build time. The license must explicitly permit distribution of
   software built from modified source code. The license may require
   derived works to carry a different name or version number from the
   original software.
   5. No Discrimination Against Persons or Groups

   The
   license must not discriminate against any person or group of
   persons.
   6. No Discrimination Against Fields of Endeavor

   The license
   must not restrict anyone from making use of the program in a
   specific field of endeavor. For example, it may not restrict the
   program from being used in a business, or from being used for
   genetic research.
   7. Distribution of License

   The rights attached to
   the program must apply to all to whom the program is redistributed
   without the need for execution of an additional license by those
   parties.
   8. License Must Not Be Specific to a Product

   The rights
   attached to the program must not depend on the program’s being part
   of a particular software distribution. If the program is extracted
   from that distribution and used or distributed within the terms of
   the program’s license, all parties to whom the program is
   redistributed should have the same rights as those that are granted
   in conjunction with the original software distribution.
   9. License
   Must Not Restrict Other Software

   The license must not place
   restrictions on other software that is distributed along with the
   licensed software. For example, the license must not insist that all
   other programs distributed on the same medium must be open-source
   software.
   10. License Must Be Technology-Neutral

   No provision of the
   license may be predicated on any individual technology or style of
   interface.

[Sérgio Basto]

On Thu, 2023-06-29 at 23:57 +0000, Piotr Szubiakowski wrote:
>  Hey!
>  
>  On Thu, 2023-06-29 at 19:12 +0200, Paolo Bonzini wrote:
>  > 
>  > > > On 6/26/23 18:47, Jeff Law wrote:
>  > > > > What Red Hat has done may be technically legal and perhaps
>  > > > > good
>  > > > > for
>  > > > > its business.
>  > > 
>  > > Something I'm having trouble with is Red Hat's position that
>  > > you can choose to be a customer or to exercise your rights
>  > > under the GPL, but you cannot be both.
>  > 
>  > The thing is, many people are learning this only now, because
>  > things 
>  > indeed have become tougher for people who prepare the RHEL
>  > rebuilds,
>  > but 
>  > this is not new.  _Nothing_ in the service agreement or in any
>  > other 
>  > legal document has changed since last week, the exact same terms
>  > have 
>  > been applicable to the extended-support branches since the
>  > beginning
>  > of 
>  > RHEL.  In fact, as Frank pointed out elsewhere, this is something
>  > that 
>  > other companies have been doing for decades as well.
>  > 
>  
>  In my opinion, people haven't complained about service agreements
>  because, till recent changes, RHEL sources were available publicly.
>  The
>  only important contract was the open-source license of the software.
>  Now we have both the license of the software and the service
>  agreement.
>   
First I think this a storm in a teacup .
Second Centos Stream is the RHEL without branding, people in general 
didn't like the idea of Centos be updated before RHEL , when Centos was
updated after RHEL , but that was the main change. 
After whats happened was that not all was updated first in Centos
Stream like kernel (we saw updates with ABI breakage first on RHEL ...
). This announce is mainly , as I read, saying that exceptions will be
over and all will be first on Centos Stream and than in RHEL 



>  > For all the people that are complaining only now that the free
> beer
>  > part 
>  > is taken away, I can't help thinking that it's a bit disingenuous
>  > to 
>  > make it about "free as in freedom", when that clause has existed
>  > forever.
>  
>  What do you mean by "free beer part"? Isn't open-source software free
>  of charge? Does anybody pay for it?
>  
>  The question is if RHEL software is still open-source or closed-
>  source. 
>  At least if I look at the OSI's [1] definition of Open Source, the
>  situation isn't clear to me.
>  
>  > 
>  > (As an aside, the service agreement also mentions that any open
>  > source 
>  > license overrides the service agreement if needed.  So by
>  > definition 
>  > this might be void but it certainly is not a GPL violation).
>  > 
>  
>  Yeah, it's hard to say which rules of service agreement are
>  overwriten
>  by software licenses. Especially that there are quite a few licenses
>  shipped with the distribution.
>  
>  Cheers,
>  
>  Piotr
>  
>  [1] OSI Open Source Definition
>  
>     Introduction
>  
>     Open source doesn’t just mean access to the source code.
>     The distribution terms of open-source software must comply with
>  the
>     following criteria:
>     1. Free Redistribution
>  
>     The license shall not
>     restrict any party from selling or giving away the software as a
>     component of an aggregate software distribution containing
>  programs
>     from several different sources. The license shall not require a
>     royalty or other fee for such sale.
>     2. Source Code
>  
>     The program must
>     include source code, and must allow distribution in source code as
>     well as compiled form. Where some form of a product is not
>     distributed with source code, there must be a well-publicized
>  means
>     of obtaining the source code for no more than a reasonable
>     reproduction cost, preferably downloading via the Internet without
>     charge. The source code must be the preferred form in which a
>     programmer would modify the program. Deliberately obfuscated
>  source
>     code is not allowed. Intermediate forms such as the output of a
>     preprocessor or translator are not allowed.
>     3. Derived Works
>  
>     The
>     license must allow modifications and derived works, and must allow
>     them to be distributed under the same terms as the license of the
>     original software.
>     4. Integrity of The Author’s Source Code
>  
>     The
>     license may restrict source-code from being distributed in
>  modified
>     form only if the license allows the distribution of “patch files”
>     with the source code for the purpose of modifying the program at
>     build time. The license must explicitly permit distribution of
>     software built from modified source code. The license may require
>     derived works to carry a different name or version number from the
>     original software.
>     5. No Discrimination Against Persons or Groups
>  
>     The
>     license must not discriminate against any person or group of
>     persons.
>     6. No Discrimination Against Fields of Endeavor
>  
>     The license
>     must not restrict anyone from making use of the program in a
>     specific field of endeavor. For example, it may not restrict the
>     program from being used in a business, or from being used for
>     genetic research.
>     7. Distribution of License
>  
>     The rights attached to
>     the program must apply to all to whom the program is redistributed
>     without the need for execution of an additional license by those
>     parties.
>     8. License Must Not Be Specific to a Product
>  
>     The rights
>     attached to the program must not depend on the program’s being
>  part
>     of a particular software distribution. If the program is extracted
>     from that distribution and used or distributed within the terms of
>     the program’s license, all parties to whom the program is
>     redistributed should have the same rights as those that are
>  granted
>     in conjunction with the original software distribution.
>     9. License
>     Must Not Restrict Other Software
>  
>     The license must not place
>     restrictions on other software that is distributed along with the
>     licensed software. For example, the license must not insist that
>  all
>     other programs distributed on the same medium must be open-source
>     software.
>     10. License Must Be Technology-Neutral
>  
>     No provision of the
>     license may be predicated on any individual technology or style of
>     interface.
>  
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines:
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue 
-- 
Sérgio M. B.

[Leon Fauster]

Am 30.06.23 um 16:05 schrieb Sérgio Basto:
>  On Thu, 2023-06-29 at 23:57 +0000, Piotr Szubiakowski wrote:
> > Hey!
> >
> > On Thu, 2023-06-29 at 19:12 +0200, Paolo Bonzini wrote:
> >>
> >>>> On 6/26/23 18:47, Jeff Law wrote:
> >>>>> What Red Hat has done may be technically legal and perhaps
> >>>>> good
> >>>>> for
> >>>>> its business.
> >>>
> >>> Something I'm having trouble with is Red Hat's position that
> >>> you can choose to be a customer or to exercise your rights
> >>> under the GPL, but you cannot be both.
> >>
> >> The thing is, many people are learning this only now, because
> >> things
> >> indeed have become tougher for people who prepare the RHEL
> >> rebuilds,
> >> but
> >> this is not new.  _Nothing_ in the service agreement or in any
> >> other
> >> legal document has changed since last week, the exact same terms
> >> have
> >> been applicable to the extended-support branches since the
> >> beginning
> >> of
> >> RHEL.  In fact, as Frank pointed out elsewhere, this is something
> >> that
> >> other companies have been doing for decades as well.
> >>
> >
> > In my opinion, people haven't complained about service agreements
> > because, till recent changes, RHEL sources were available publicly.
> > The
> > only important contract was the open-source license of the software.
> > Now we have both the license of the software and the service
> > agreement.
> >
>  
>  First I think this a storm in a teacup .
>  Second Centos Stream is the RHEL without branding, people in general
>  didn't like the idea of Centos be updated before RHEL , when Centos was
>  updated after RHEL , but that was the main change.
>  After whats happened was that not all was updated first in Centos
>  Stream like kernel (we saw updates with ABI breakage first on RHEL ...
>  ). This announce is mainly , as I read, saying that exceptions will be
>  over and all will be first on Centos Stream and than in RHEL
>   
Someone says or writes it, other reads it, but the reality is that in 
CentOS Stream are always continuously missing parts of RHEL. I do not
complain about it, but its annoying when the narratives that everything
is there are spreaded.

-- 
Leon

[Piotr Szubiakowski]

On Fri, 2023-06-30 at 15:05 +0100, Sérgio Basto wrote:

>  First I think this a storm in a teacup .
>  
I tend to agree. In the worst-case scenario, people like me who try to
use open-source solely and don't pay for open-source will find a
distribution that fits them best. And from Red Hat's perspective, we
don't bring much value anyway.

>  Second Centos Stream is the RHEL without branding, people in general
>
>  didn't like the idea of Centos be updated before RHEL , when Centos
>  was
>  updated after RHEL , but that was the main change. 
>  After whats happened was that not all was updated first in Centos
>  Stream like kernel (we saw updates with ABI breakage first on RHEL
>  ...
>  ). This announce is mainly , as I read, saying that exceptions will
>  be
>  over and all will be first on Centos Stream and than in RHEL
>  
I think we all have a problem understanding what this announcement
means. I do believe CentOS Stream is awesome software. It has to be
since it's close to what RHEL is. My problem with CentOS Stream is that
it's not a distribution of my choice, and I feel forced to use CentOS
Stream. While at the same time, distributions of my choice Fedora,
Scientific Linux, CentOS Linux, Rocky Linux, and AlmaLinux, are
consequently taken down, to a moment that I'm not sure whenever RHEL is
still an open-source software.

Most likely, I'm too paranoid, but I'm
afraid that if Red Hat successfully kills RHEL downstream projects, bad
things will start to happen to CentOS Stream as well.

Cheers,

Piotr

[Carlos Rodriguez-Fernandez]

On 7/1/23 12:33, Piotr Szubiakowski wrote:

>  I think we all have a problem understanding what this announcement
>  means. I do believe CentOS Stream is awesome software. It has to be
>  since it's close to what RHEL is. My problem with CentOS Stream is that
>  it's not a distribution of my choice, and I feel forced to use CentOS
>  Stream. While at the same time, distributions of my choice Fedora,
>  Scientific Linux, CentOS Linux, Rocky Linux, and AlmaLinux, are
>  consequently taken down, to a moment that I'm not sure whenever RHEL is
>  still an open-source software.
>  
It is still as opensource as it is Ubuntu and SUSE. There are no clones 
of Ubuntu LTS with 10 years lifecycle, nor of SUSE Enterprise with their 
10+ lifecyle.

>  
>  Most likely, I'm too paranoid, but I'm
>  afraid that if Red Hat successfully kills RHEL downstream projects, bad
>  things will start to happen to CentOS Stream as well.
>  
I'm afraid that could be the case too. This move will cool down the EL 
community significantly. I'm concerned of the future of EPEL itself. I 
wish RedHat would reduce their prices significantly for wider adoption, 
or just give the first 5 years for free as Ubuntu does.

Regards,
Carlos.

[Jonathan Wakely]

On Sat, 1 Jul 2023 at 20:34, Piotr Szubiakowski wrote:
>  I think we all have a problem understanding what this announcement
>  means. I do believe CentOS Stream is awesome software. It has to be
>  since it's close to what RHEL is. My problem with CentOS Stream is that
>  it's not a distribution of my choice, and I feel forced to use CentOS
>  Stream. While at the same time, distributions of my choice Fedora,
>  Scientific Linux, CentOS Linux, Rocky Linux, and AlmaLinux, are
>  consequently taken down, to a moment that I'm not sure whenever RHEL is
>  still an open-source software. 
I don't know why you're mentioning Fedora here.

Fedora is upstream from RHEL, not downstream. Fedora will not be
"consequently taken down" by this announcement or anything like it.

[Piotr Szubiakowski]

Hey!

>  On Sat, 1 Jul 2023 at 20:34, Piotr Szubiakowski wrote:
>  > I think we all have a problem understanding what this announcement
>  > means. I do believe CentOS Stream is awesome software. It has to be
>  > since it's close to what RHEL is. My problem with CentOS Stream is
>  > that
>  > it's not a distribution of my choice, and I feel forced to use
>  > CentOS
>  > Stream. While at the same time, distributions of my choice Fedora,
>  > Scientific Linux, CentOS Linux, Rocky Linux, and AlmaLinux, are
>  > consequently taken down, to a moment that I'm not sure whenever
>  > RHEL is
>  > still an open-source software.
>  
>  I don't know why you're mentioning Fedora here.
>  
>  Fedora is upstream from RHEL, not downstream. Fedora will not be
>  "consequently taken down" by this announcement or anything like it.
>  
I mentioned Fedora there because it's the distribution of my choice. I
don't think there is any threat to Fedora. The community here is
fantastic and likely can run the project even if companies behind limit
their involvement.

RHEL downstream rebuilds and Fedora were great tools
in my toolbox. They complement each other, and I built all my projects
on top of them. Till recent changes, the OS choice has always been easy
for me.

Cheers,

Piotr

[Frederic Berat]

On Thu, Jun 29, 2023 at 6:41 PM Todd Zullinger <tmz(a)pobox.com&gt; wrote:

>  Carlos O'Donell wrote:
>  > On 6/26/23 18:47, Jeff Law wrote:
>  >> What Red Hat has done may be technically legal and perhaps good for
>  >> its business.  However, to me it's ethically unconscionable.   Those
>  >> who know me know I'm not an zealot, but I do have a baseline set of
>  >> ethical values and Red Hat crossed that line.
>  >
>  > Why is it ethically unconscionable? There is a lot of confusion around
>  > what has happened and why. What you are saying, and what actually
>  happened
>  > don't line up in my mind :-)
>
>  Something I'm having trouble with is Red Hat's position that
>  you can choose to be a customer or to exercise your rights
>  under the GPL, but you cannot be both.
>
>  
Receiving GPL software doesn't give you the right to receive support for
it. It never did, and never will. If that you were in capacity to enforce
any developer that ever provided you a specific version of a software to
give you all future version that you would need in the future, that would
contradict fundamental rights: "You should also have the freedom to make
modifications and use them privately in your own work or play, without even
mentioning that they exist." [1]

Or said the other way around, the fact that Red Hat gives you a binary, and
the sources associated with it doesn't oblige Red Hat to give support for
it nor any future modified version of it. This support obligation is only
tight to the support contract you may have with Red Hat which it may choose
to cancel in any conditions that it sees fit (in accordance to the said
contract). The rupture of this contract does not deprive you from your
rights on the previously received binaries/sources in any way.

[1] https://www.gnu.org/philosophy/free-sw.en.html#redistribute


>  I don't know how to view that as anything other than
>  sacrificing the spirit of F/OSS to help the books.
>  
I am sympathetic to the odd/difficult nature of running a
>  business based on F/OSS.  Until now I thought Red Hat was
>  doing it pretty well.
>
>  I thought Jeff's message was well written.  I am still
>  struggling with whether I should take the same path. :(
>
>  --
>  Todd
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Leslie Satenstein]

I agree with RH's decision.

 I write software and release it as gpl3, source, it and all build Makefiles! I give it
out, and to those, I ask, only to provide me with bug reports or some patch ideas to make
the offering better.


What should I do, if the person I gave the software to, removes my copyright, rebrands the
software and sells my software as their own? Is it right? And when I release a bug fix,
they take it, insert the fix into the rebranded copy they are selling, and they quietly
say, "Screw You, Leslie". 

Suppose I was the government, and I did that same offer to end-users. Would the
redistribution be legit, and even honest, if from the government, and it was for
remuneration?



The right-or-wrong activity is really a discussion about ownership and rules for sharing.
In the Leslie case, Leslie is the owner. In the government case, the people are the
owners. 


What right does a company have the right to clone and rebrand my product and resell it?
Under the gpl3, they have an unenforceable obligation to provide me with bug reports. They
do not have a moral right to redistribute my software as their own, and for remuneration.



In two cases, at least two companies offer Linux as known Red Hat, clones. We understand
that they copy the sources, the bug fixes, and rebrand the software as their own. In most
cases, vanilla in -- vanilla out. But it is not revenue in, revenue shared.


What should Red Hat do to recover the costs for development of new features,
documentation, distribution, bug-fixes, 24/7 support as well, the infrastructure that
allowed an individual to freely download the entire package. The clones have none of those
obligations or costs? Red Hat is financing Centos and Fedora. Moreover, 
visit https://kojipkgs.fedoraproject.org/compose/

to get a small idea of the investment, operating costs, and end-user benefits. Recall, Red
Hat shareholders are not a government body. 
   
Perhaps it is time to provide a gpl4 rule that encompasses or replaces gpl3. 

Leslie Satenstein    
 

    On Thursday, June 29, 2023 at 12:41:44 p.m. EDT, Todd Zullinger <tmz(a)pobox.com&gt;
wrote:  
 
 Carlos O'Donell wrote:
>  On 6/26/23 18:47, Jeff Law wrote:
> > What Red Hat has done may be technically legal and perhaps good for
> > its business.  However, to me it's ethically unconscionable.  Those
> > who know me know I'm not an zealot, but I do have a baseline set of
> > ethical values and Red Hat crossed that line.
>  
>  Why is it ethically unconscionable? There is a lot of confusion around
>  what has happened and why. What you are saying, and what actually happened
>  don't line up in my mind :-) 
Something I'm having trouble with is Red Hat's position that
you can choose to be a customer or to exercise your rights
under the GPL, but you cannot be both.

I don't know how to view that as anything other than
sacrificing the spirit of F/OSS to help the books.

I am sympathetic to the odd/difficult nature of running a
business based on F/OSS.  Until now I thought Red Hat was
doing it pretty well.

I thought Jeff's message was well written.  I am still
struggling with whether I should take the same path. :(

-- 
Todd
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Solomon Peachy]

On Fri, Jun 30, 2023 at 01:41:18PM +0000, Leslie Satenstein via devel wrote:
>  What should I do, if the person I gave the software to, removes my 
>  copyright, rebrands the software and sells my software as their own? 
>  Is it right? And when I release a bug fix, they take it, insert the 
>  fix into the rebranded copy they are selling, and they quietly say, 
>  "Screw You, Leslie". 
In some jurstictions (eg the US) removing your copyright identification 
is infringement all on its own, and you can go after them for statutory 
damages. (See 17 USC 1202 (b) and (c), and 17 USC 1203 (c) (2))

But that's not what has happened here.  Nobody is claiming that they are 
selling RHEL, and nobody has stripped away RH's copyrights.  Now the RH 
*trademarks* are another matter, but RH themselves did that stripping, 
with what they uploaded to CentOS Stream (and CentOS before that).

>  What right does a company have the right to clone and rebrand my 
>  product and resell it? Under the gpl3, they have an unenforceable 
>  obligation to provide me with bug reports. They do not have a moral 
>  right to redistribute my software as their own, and for remuneration. 
Under the GPLv3, there is no "obligation" to provide you, as the author, 
with anything, bug reports or otherwise.  Their only obligations are to 
ensure that everyone they send binaries to also receives the complete 
corresponding source code to those binaries, all under the terms of the 
GPLv3.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libra.chat)

[Leon Fauster]

Am 30.06.23 um 15:41 schrieb Leslie Satenstein via devel:

>      What should I do, if the person I gave the software to, removes
> my
>      copyright, rebrands the software and sells my software as their own?
>      Is it right? And when I release a bug fix, they take it, insert the
>      fix into the rebranded copy they are selling, and they quietly say,
>      "Screw You, Leslie". 
Ask yourself; how does open source methodology works?

Just using your words: Apple Inc. releases a bug fix, RedHat takes it,
insert it into the rebranded copy (RHEL) they are selling ...

https://git.centos.org/rpms/webkit2gtk3/c/f1679e95706409206b768d4f0a03563...


-- 
Leon

[Leslie Satenstein]

Hi Leon. 
I replied inline.

Leslie Satenstein    
 

    On Friday, June 30, 2023 at 11:16:48 a.m. EDT, Leon Fauster via devel
<devel(a)lists.fedoraproject.org&gt; wrote:  
 
 
Am 30.06.23 um 15:41 schrieb Leslie Satenstein via devel:

>     What should I do, if the person I gave the software to, removes
> my
>     copyright, rebrands the software and sells my software as their own?
>     Is it right? And when I release a bug fix, they take it, insert the
>     fix into the rebranded copy they are selling, and they quietly say,
>     "Screw You, Leslie". 
Ask yourself; how does open source methodology works?

Just using your words: Apple Inc. releases a bug fix, RedHat takes it,
insert it into the rebranded copy (RHEL) they are selling ...

https://git.centos.org/rpms/webkit2gtk3/c/f1679e95706409206b768d4f0a03563...

WITH APPLE's invitation/request.  The fix was to help non-applie users make better use
of Apple's offerings.
Leslie
-- 
Leon

_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Carlos Rodriguez-Fernandez]

That's not what is happening on those patches, Leslie. The RH engineers 
are adding the patches to the package which is basically how backporting 
works (as in all distros that do it), and then adding themselves as the 
maintainers that added the patches. Well documented as it should. They 
did not modify the patches themselves to appears as coming from them or 
RedHat employees.

Going forward, you will see those patches contributions going into 
Centos stream first, and they will be accepted by RH engineers, and then 
they will end up in CentOS Stream distro first, and finally in RHEL.

That's how normally distros operate when they do backporting.


On 6/30/23 08:15, Leon Fauster via devel wrote:
>  
>  Am 30.06.23 um 15:41 schrieb Leslie Satenstein via devel:
>  
> >     What should I do, if the person I gave the software to, removes my
> >     copyright, rebrands the software and sells my software as their own?
> >     Is it right? And when I release a bug fix, they take it, insert the
> >     fix into the rebranded copy they are selling, and they quietly say,
> >     "Screw You, Leslie".
>  
>  Ask yourself; how does open source methodology works?
>  
>  Just using your words: Apple Inc. releases a bug fix, RedHat takes it,
>  insert it into the rebranded copy (RHEL) they are selling ...
>  
>
> https://git.centos.org/rpms/webkit2gtk3/c/f1679e95706409206b768d4f0a03563...
>  
>  
>

[Michael Catanzaro]

On Fri, Jun 30 2023 at 11:09:41 AM -0700, Carlos Rodriguez-Fernandez 
<carlosrodrifernandez(a)gmail.com&gt; wrote:
>  Going forward, you will see those patches contributions going into
>  Centos stream first, and they will be accepted by RH engineers, and 
>  then
>  they will end up in CentOS Stream distro first, and finally in RHEL. 
Just for the record: no, you'll never see updates like those in CentOS 
Stream because that was a stable branch update after RHEL had already 
branched from CentOS Stream. Those patches will never appear in CentOS 
Stream because I do not push them there.

Michael

[Carlos Rodriguez-Fernandez]

Hi Michael,

We have been told repeatedly that "the source is there" in CentOS 
stream. I can see the scenario that RH branches from CentOS stream to 
create a new minor release, and during QA, a bug is discovered and a 
patch is backported (or created) to fix it internally in your minor 
release branch. However, if that bug wants to be addressed also in the 
next minor release, it will need to appear in the CentOS stream at some 
point, whether via a patch or an entire source version bump.

If that's not the case, then RH is having some long living parallel git 
repo which will eventually create ABI compatibility issues, and it is 
also not what we have been told.

Am I missing something?

Thank you for your feedback.

Regards,
Carlos

On 7/2/23 07:35, Michael Catanzaro wrote:
>  On Fri, Jun 30 2023 at 11:09:41 AM -0700, Carlos Rodriguez-Fernandez
>
>  <carlosrodrifernandez(a)gmail.com&gt; wrote:
> > Going forward, you will see those patches contributions going into
> > Centos stream first, and they will be accepted by RH engineers, and then
> > they will end up in CentOS Stream distro first, and finally in RHEL.
>  
>  Just for the record: no, you'll never see updates like those in CentOS 
>  Stream because that was a stable branch update after RHEL had already 
>  branched from CentOS Stream. Those patches will never appear in CentOS 
>  Stream because I do not push them there.
>  
>  Michael
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: 
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: 
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Michael Catanzaro]

On Sun, Jul 2 2023 at 08:33:46 AM -0700, Carlos Rodriguez-Fernandez 
<carlosrodrifernandez(a)gmail.com&gt; wrote:
>  Hi Michael,
>  
>  We have been told repeatedly that "the source is there" in CentOS
>  stream. 
The source for the next minor version is there.

>  I can see the scenario that RH branches from CentOS stream to
>  create a new minor release, and during QA, a bug is discovered and a
>  patch is backported (or created) to fix it internally in your minor
>  release branch. However, if that bug wants to be addressed also in the
>  next minor release, it will need to appear in the CentOS stream at 
>  some
>  point, whether via a patch or an entire source version bump. 
Right; nobody wants regressions. In this particular example, the fix is 
there via "an entire source version bump."

>  If that's not the case, then RH is having some long living
> parallel 
>  git
>  repo which will eventually create ABI compatibility issues, and it is
>  also not what we have been told. 
So I'm really primarily here to talk about Fedora and CentOS Stream, 
because we often can't talk very much about RHEL. I'm going to point 
you to this page:

https://access.redhat.com/support/policy/updates/errata/

And in particular this graphic:

https://access.redhat.com/sites/default/files/images/337_rhel_9_life_cycl...

Suffice to say the lifecycle you see here only works if there are lots 
of long-lived parallel branches. ;) Branching does not inherently lead 
to ABI issues. For more info on ABI:

https://access.redhat.com/articles/rhel9-abi-compatibility

Michael

[Leon Fauster]

Am 03.07.23 um 00:41 schrieb Michael Catanzaro:
>  
>  
>  On Sun, Jul 2 2023 at 08:33:46 AM -0700, Carlos Rodriguez-Fernandez 
>  <carlosrodrifernandez(a)gmail.com&gt; wrote:
> > Hi Michael,
> >
> > We have been told repeatedly that "the source is there" in CentOS
> > stream.
>  
>  The source for the next minor version is there.
>  
> > I can see the scenario that RH branches from CentOS stream to
> > create a new minor release, and during QA, a bug is discovered and a
> > patch is backported (or created) to fix it internally in your minor
> > release branch. However, if that bug wants to be addressed also in the
> > next minor release, it will need to appear in the CentOS stream at some
> > point, whether via a patch or an entire source version bump.
>  
>  Right; nobody wants regressions. In this particular example, the fix is 
>  there via "an entire source version bump."
>  
> > If that's not the case, then RH is having some long living parallel git
> > repo which will eventually create ABI compatibility issues, and it is
> > also not what we have been told.
>  
>  So I'm really primarily here to talk about Fedora and CentOS Stream, 
>  because we often can't talk very much about RHEL. I'm going to point you 
>  to this page:
>  
>  https://access.redhat.com/support/policy/updates/errata/
>  
>  And in particular this graphic:
>  
>
> https://access.redhat.com/sites/default/files/images/337_rhel_9_life_cycl...

With the transitioning to "maintenance phase" next summer (EL8), I
assume that for the next 5 years nothing gets pushed into c8s git
anymore??

So, the mentioned mantra is only the half of the story ...

-- 
Leon

[Vít Ondruch]

Dne 03. 07. 23 v 16:13 Leon Fauster via devel napsal(a):
>  Am 03.07.23 um 00:41 schrieb Michael Catanzaro:
> >
> >
> > On Sun, Jul 2 2023 at 08:33:46 AM -0700, Carlos Rodriguez-Fernandez 
> > <carlosrodrifernandez(a)gmail.com&gt; wrote:
> >> Hi Michael,
> >>
> >> We have been told repeatedly that "the source is there" in CentOS
> >> stream.
> >
> > The source for the next minor version is there.
> >
> >> I can see the scenario that RH branches from CentOS stream to
> >> create a new minor release, and during QA, a bug is discovered and a
> >> patch is backported (or created) to fix it internally in your minor
> >> release branch. However, if that bug wants to be addressed also in the
> >> next minor release, it will need to appear in the CentOS stream at some
> >> point, whether via a patch or an entire source version bump.
> >
> > Right; nobody wants regressions. In this particular example, the fix 
> > is there via "an entire source version bump."
> >
> >> If that's not the case, then RH is having some long living parallel git
> >> repo which will eventually create ABI compatibility issues, and it is
> >> also not what we have been told.
> >
> > So I'm really primarily here to talk about Fedora and CentOS Stream, 
> > because we often can't talk very much about RHEL. I'm going to point 
> > you to this page:
> >
> > https://access.redhat.com/support/policy/updates/errata/
> >
> > And in particular this graphic:
> >
> >
> https://access.redhat.com/sites/default/files/images/337_rhel_9_life_cycl...
>
> >
>
>
>  With the transitioning to "maintenance phase" next summer (EL8), I
>  assume that for the next 5 years nothing gets pushed into c8s git
>  anymore??
>  

Just FTR, the c8s EOL was already announced here:

https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-...


Vít

[Kevin Kofler]

Leslie Satenstein via devel wrote:
>  What should I do, if the person I gave the software to, removes my
>  copyright, rebrands the software and sells my software as their own? Is it
>  right? And when I release a bug fix, they take it, insert the fix into the
>  rebranded copy they are selling, and they quietly say, "Screw You,
>  Leslie". 
Removing the copyright is not allowed under the GPL, and in many 
jurisdictions your license cannot even allow that to begin with, but that is 
not what is being done by the rebuilds, so that point is a strawman.

The rest is just how Free Software works and should work.

>  Suppose I was the government, and I did that same offer to
> end-users.
>  Would the redistribution be legit, and even honest, if from the
>  government, and it was for remuneration? 
Same answer as above.

>  What right does a company have the right to clone and rebrand my
> product
>  and resell it? 
That is an essential part of Free Software, of Open Source, and of the GPL 
in particular.

>  Under the gpl3, they have an unenforceable obligation to
>  provide me with bug reports. 
They actually have no such obligation, enforceable or not.

>  They do not have a moral right to redistribute my software as their
> own,
>  and for remuneration. 
That is your very personal interpretation and does not match the Free 
Software definition nor the Open Source definition.

>  In two cases, at least two companies offer Linux as known Red Hat,
> clones.
>  We understand that they copy the sources, the bug fixes, and rebrand the
>  software as their own. In most cases, vanilla in -- vanilla out. But it is
>  not revenue in, revenue shared. 
Guess what, Free Software means this is perfectly acceptable behavior, 
whether you find it fair or not. Life is not fair.

>  What should Red Hat do to recover the costs for development of new
>  features, documentation, distribution, bug-fixes, 24/7 support as well,
>  the infrastructure that allowed an individual to freely download the
>  entire package. The clones have none of those obligations or costs? Red
>  Hat is financing Centos and Fedora. Moreover, visit
>  https://kojipkgs.fedoraproject.org/compose/
>  to get a small idea of the investment, operating costs, and end-user
>  benefits. Recall, Red Hat shareholders are not a government body. 
The clones also have infrastructure costs.

They indeed do not share the development costs, but there is no requirement 
that they do.

>  Perhaps it is time to provide a gpl4 rule that encompasses or
> replaces
>  gpl3. 
A "GPL4" with the kind of rules you imply would no longer be Free Software, 
hence I hope the FSF will never put this kind of terms into any version of 
the GPL.

        Kevin Kofler