[rahen]

At least Debian cannot and will never be bought, will always be there, has an army of contributors (some of them kernel developers), and is basically the only enterprise grade free distribution.

Now just add some RHEL/CentOS containers on top where needed and forget about the RH lock-in.

[imglorp]

> RHEL/CentOS containers ... RH lock-in

So if a non-IP-lawyer reads the redistribution terms of the RH Universal Base Images, there are some very dubious implications in there, such as #22 and #42.

  https://developers.redhat.com/articles/ubi-faq#

Has anyone done a third party analysis of their EULA? My org, an ISV, may need some legal cycles to avoid stepping in this trap.

I'd be just fine avoiding UBI because of that, but there are some orgs whose security posture demands only UBI images are allowed in their domain so ISV's may be forced to pay to play.

[mogwire]

#22 and #42 is how they try to prevent people from adding RPMs from mainstream RHEL. I have seen GitHub repos owned by RH employees that have containers files that require you to attach entitlement cert and the Red Hat cdn repo to install additional packages. It doesn’t violate EULA because they aren’t distributing the image.

RH knows people will try to abuse the free UBI image and install RPMs they shouldn’t be.

I work with Red Hat Partners so I know these rules well.

[parasense]

Yeah, they are base images devoid of copyright/trademark assets like artwork or whatever, and so it goes... just a platform to layer around. Like you wrote the first thing many people want or need, is to layer other RHEL packages, or if the software lacks many dependencies then the ISV just integrates their own software over top, then packages that layer themselves...

Meh

[yjftsjthsd-h]

> I'd be just fine avoiding UBI because of that, but there are some orgs whose security posture demands only UBI images are allowed in their domain so ISV's may be forced to pay to play.

That seems fine IMO; use free OSs wherever possible, but if customers want RHEL just pass the cost through and let them deal with it.

[krnlpnc]

It would be quite nice to see Debian adopt a longer term release model. In a lot of environments that was the deciding factor for RHEL/CentOS. A stable OS with security support for a decade.

The current Debian release cycle is closer to 2 years which means a big increase in testing and OS upgrade cycles.

[yjftsjthsd-h]

https://wiki.debian.org/LTS ?

[krnlpnc]

Yes, LTS support is 2 years.

Debian releases are supported for about half the length of RHEL releases overall, LTS included.

Debian “Stretch” for instance was released in 2017 and support ends 2022, so a 5 year cycle.

RHEL on the other hand has a 10 year cycle, and offers extended support beyond that:

“Red Hat Enterprise Linux Version 8 delivers a ten year life cycle in Full Support and Maintenance Support Phases followed by an Extended Life Phase.”

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

With Debian upgrades are realistically being planned every 2-3 years as the release approaches LTS.

That makes for a lot of extra upgrade work (about 3x more) when compared to the 10 year RHEL life cycle.

[yjftsjthsd-h]

Oh, I see. Yes, that's true, although it would take a rather lot of resources; for a decade of support, you basically need devs who can support each package in the distro independently of upstream. Still, if you're willing to pay for it I expect there are companies who will offer that support.

[phendrenad2]

That, or, package maintainers could decide to maintain their packages for 10+ years. That at least distributes the workload among the package maintainers. Unfortunately, most package maintainers don't like spending time backporting bug fixes etc. and would rather be making shiny new releases (and can you blame them?)

[yjftsjthsd-h]

> and can you blame them?

Exactly; almost nobody wants to maintain old versions like that. For most people, the fun part is writing new stuff, and maintaining old stuff without breaking backwards compatibility is particularly annoying to put up with. I certainly couldn't blame anyone, particularly who was just publishing software for free, for not wanting to deal with all that.