[Twirrim]

The "problem" with Debian is the lifecycle. You get about a 12-24 months at most of security patches, and that's effectively it (the patching model after that is unreliable). That means you've got to allocate resources for upgrading/validating far more regularly than you would with other distributions. Depending on the size of your business, that could get really expensive and disruptive, for negligible benefit.

Canonical Ubuntu has a longer support on their LTS releases, and may be preferable. If you can get past annoyance with things like snaps.

[tsimionescu]

It should be noted, as many businesses are finding out, that you can't redistribute Ubuntu binaries or sources as-is, since they contain registered trademarks of Canonical.

So, if you want to ship Ubuntu-based systems, you actually have to maintain your own version of all of their software stripped of the trademarks and re-compiled, or pay them. It seems Canonical is getting more interested in actually enforcing this, I believe they mostly ignored it for a long time now.

Debian seems like a much simpler alternative than doing all this.

Source: https://ubuntu.com/legal/intellectual-property-policy

> Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries [emphasis mine]. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu. If you need us to approve, certify or provide modified versions for redistribution you will require a licence agreement from Canonical, for which you may be required to pay. For further information, please contact us (as set out below).

[_ea1k]

That is basically the same as what Red Hat used to do. Centos had to be very careful to avoid improper trademark usage in their rebuild.

[maffydub]

Do you have any other references on this?

It seems that it all hinges on what a "modified version" of Ubuntu is. Is redistributing their packages outside of a full disk image a modified version?

[tsimionescu]

Don't have more sources , but my understanding is that Canonical considers that anything other than downloading an Ubuntu disk image from Canonical and hosting that on your own site constitutes a modification.

So, for example, if you take an Ubuntu image, change the default username and password, and re-export it as a new ISO, you have modified the Ubuntu image and can't redistribute it with the *buntu trademarks unless you make an agreement with Canonical. IANAL so don't take my word for it, but this is my honest understanding of what Canonical claims at least.

This does seem to be in agreement with the next item in the FAQ I linked - where they say that using an image that doesn't conform to the IPRights policy from someone else is not recommended since they can't guarantee that it will work with future updates or such - which any modification even of default settings could provoke.

[maffydub]

Thanks! I agree with your reading that changing the default username and password and re-exporting would count as modification.

However, it seems there are plenty of Ubuntu .deb mirrors out there... and there are even instructions at https://help.ubuntu.com/community/Debmirror.

Your previous post said "you can't redistribute Ubuntu binaries or sources as-is, since they contain registered trademarks of Canonical" (emphasis mine), which I think isn't quite true - there has to be some modification involved to fall foul of Ubuntu's IPR.

[tsimionescu]

Oops, you're right, I misspoke - I was thinking about the modification step as a given, but that's not what I said. Apologies for the confusion.

[traceroute66]

> Do you have any other references on this?

Not a reference per-se, but an interesting post on the Nirokey blog "NextBox: Why we Decided for and Against Ubuntu Core"

[1]https://www.nitrokey.com/news/2021/nextbox-why-we-decided-an...

[mistrial9]

learning from their new Masters in Redmond perhaps?

[wazoox]

That's simply not true. All Debian releases have been LTS since 2014, for the following architectures : i386, amd64, armhf and arm64.

All Debian releases get 1 year of full updates after the new release, and at least 5 years of updates in total from their initial publication.

[Twirrim]

After the first couple of years, Debian Security stops patching it. "Debian LTS is not handled by the Debian Security team, but by a separate group of volunteers and companies interested in making it a success.",from https://wiki.debian.org/LTS. It is not the same thing, and the time scales and patching consistency is not on the same scale.

[cramjabsyn]

I tend to agree, if Debian embraced a longer term support model it would attract a lot of enterprise deployments.

RHEL is something like 10 years while Debian is more like 2, 3 if you push it.

[markfeathers]

Stock debian is 5 years with their LTS project, but they have a paid "ELTS" project that adds an additional 5 years. So 5 years for free, 10 total years as a paid support option. https://wiki.debian.org/DebianReleases

[wazoox]

No, all Debian releases are completely supported 3 years (1 full year after the release of the new stable release) and are LTS for 5 years.

[cramjabsyn]

Yes 2 years is the realistic lifespan in service. 3 is pushing it as part of the last year is spent on planning/upgrading. LTS is sub optimal.

[geerlingguy]

And that is why RHEL is so valuable in enterprise.

When you see people still running PHP 5, or Python 2, and not for tiny little nonprofits either... there are large sums of money being thrown over the wall to support that.

[kjs3]

That's probably because people pay to use RHEL, which funds supporting it for 10 years.

[brnt]

> You get about a 12-24 months at most of security patches, and that's effectively it

What if all that effort on CentOS forks was spent on this?

[darkr]

CentOS (and it's forks) never backported security fixes for old software versions; it was always RedHat that took on this grunt work.

Even within that 12-24 month timeline, security fixes are commonly only backported where there is a significant enough security risk in a significant enough package. More resource on this mundane but important task is sorely needed