Notices by Matthew Miller (mattdm@hachyderm.io), page 2

@jbowen

Every change to RHEL, with the exception of short-lived branch patches, goes into CentOS Stream (and then future RHEL).

There is plenty to argue about in details (so I won't), but the big picture is that Red Hat's approach funds engineering which all ultimately goes to open source available to everyone (even when the licenses are permissive), and does not require contributors to grant Red Hat any special power.

I don't think it's perfect — but it's better than the CLA squeeze.

In this latest, they say: "Redis has been sponsoring the bulk of development alongside a dynamic community of developers eager to contribute".

I was just talking to @quaid about this, and he made an excellent point: if your company-sponsored open source project is still 95% company-developed, _you messed up several years ago_.

I know the change to source code publishing for RHEL y-streams went over _poorly_, but I'm proud of this:

Red Hat doesn't pull this "open source obligations for you, but none for us!" trick.

There is _nothing_ that gives Red Hat special rights that other organizations or individuals don't get -- if we want special influence, we have to do it by doing the work, just like anyone else.

@shanecurcuru

I'm not really fond of that list.

Particularly:

* I don't think these are "levels", but rather some (but not all) aspects of openness.

* I don't see how "may accept contributions" relates to "open community" — I mean, they seem unrelated, not just a framing I would put differently

The Redis thing underscores a key point: _open source is not enough_. We need _community built software_ -- free and open source licenses are just one aspect of that.

If a company requires you to assign copyright (or equivalent re-licensing rights) in an asymmetrical way, they will inevitably eventually decide to take that option once they want to cash in on the goodwill you've built for them (let alone the code).

@vwbusguy @msw

Preserving the integrity by removing themselves from it?

@inthehands

They also seem to be losing the war vs content farms, and that is only going to get worse in the next few years.

@emilygorcenski

Well, Holland* and Grand Rapids are quite close, and both are pretty nice places to visit. And Milwaukee — looks like there is a 2½ hour ferry.

* https://www.holland.org/windmill-island-gardens-dezwaan-windmill/ (as pictured)

This standard ain't right.

@arstechnica

These sentences sound like each word was pulled from a hat!

@cabel

Can't argue with perfect, but it's be _even more perfect_ if it only used blocks and colors available at your birth year.

My flight at gate 404 is delayed because... the plane isn't there.

I am not making this up.

@killyourfm @doctormo

Maybe this in Fedora counts? https://jonatoni.fedorapeople.org/Fedora%20Appreciation%20Week%20-%20Flock%202018.pdf

@bconoboy

Aside — I'm not at all keen on Red Hat's "project vs. product" jargon. But that is indeed a whole 'nuther discussion.

@vathpela @bconoboy

Yessss. I was debating which order to use and apparently went with "both and neither at once". I will use the magical Mastodon "edit post" feature.

@bconoboy @doctormo @vathpela

I think _that's_ the RH jargon. _Fedora_ is a project*, and Server, Workstation, KDE Plasma Desktop, CoreOS, Silverblue, Cloud are valuable things the project produces and shares.

* or, as @funnelfiasco says, really a _program_

@maxsteenbergen @Migueldeicaza

Absolutely not. All Red Hat contributions are upstreamed where possible, and made available openly and without restriction at https://gitlab.com/redhat/centos-stream/rpms

That might not match precisely the form of the patch in an specific RHEL release, but those _are_ available alongside the binaries. Most differences are due — ironically contrary to the narrative Miguel is pushing — to getting those changes upstream, benefiting everyone and making patches obsolete.