Red Hat Universal Base Image and Licensing

The Red Hat Universal Base Image has generated a tremendous amount of buzz, which is great. This also means, I get a ton of questions about it. One of the most popular area of questions is around licensing. If you have licensing questions this blog might help you frame your questions better, but I always recommend consulting legal council. This article will, at a minimum, help you frame your questions in a way that a lawyer can understand. Let's tackle some popular questions:

1. Does UBI let me distribute my container images anywhere I want?

TL;DR - Building on UBI means Red Hat is never going to tell you where or how you can distribute your images. You can distribute your images wherever and however you like.

But, the engineer/lawyer side of my brain has to answer this question in bit more detail. You have to understand what a container image is from a legal perspective. Using container images to deliver your applications means that you are dragging in all of the dependencies, and delivering them together as a single unit with ALL of the licensing restrictions from every piece of software that you included. Furthermore, a container image (really a repository) is a collection of software made up of layers. Here are some real world examples:

• Red Hat Universal Base Image -> Java -> Your Java Application
• Red Hat Universal Base Image -> PHP FPM + Apache -> Your PHP Application
• Red Hat Universal Base Image -> Nginx + Ruby + Rails -> Your Ruby Application

Each layer can contain any number of pieces of software, each with their own licensing restrictions. Notice that the base image is special from a legal perspective. Since it's the foundational layer, its legal restrictions are inherited by any and all layered images built upon it.

That's why Red Hat created UBI, to free up this lowest layer. It's critical to let people distribute their images how and where they want. That's the magic of containers - collaboration. UBI facilitates collaboration on a high quality, supportable base image.

UBI does NOT change the licensing requirements of any of the software built on top of it. Stated another way, the layers you build on top of UBI retain their own licensing - be it open source or proprietary, it's up to you - and, you are still responsible for meeting those license requirements.

Nothing more, nothing less.

2. Can I add RHEL packages if something is missing from UBI?

TL;DR - not if you want to distribute the images, once you add RHEL RPMs onto a UBI image, you are back to redistributing content released under the Red Hat Enterprise Linux end user license. If you are a paying Red Hat customer, this would break the agreement between you and Red Hat. Furthermore receivers of these images wouldn't receive updates for the RPMs you added unless they have Red Hat subscriptions. This puts those end users without Red Hat subscriptions in a bad place.

If you need extra packages, don't add RHEL packages (because they are restricted). Also, don't add CentOS packages (because they will remove supportability). Adding CentOS packages turns the image into a Frankenstein. Neither Red Hat, nor the community will want to support it. You are better off with all UBI or CentOS content. Don't mix and match. The best solution is:

1. File a Bugzilla request at bugzilla.redhat.com
2. Select the proper version of RHEL
3. Select the "distribution" component
4. Prepend "UBI:" do the description. For example "UBI: need tcpdump package"
5. Include a good description of why you need these packages
6. Wait for us to analyze the request and see if it meets a use case we want to support with UBI (major goals around cloud native applications, certified containers, certified operators, and community efforts supporting those)

3. Is the UBI License Open Source?

TL:DR - UBI is not a software license, it's an end user license agreement (EULA) for Red Hat trademarks embedded in our RPM content.

The UBI content set (RPM packages) is made up of many different software components released with many different software licenses (GPL2, GPL3, Apache, BSD, etc). Red Hat complies with all of these licenses by releasing the source code for all of these packages. The UBI EULA gives container image builders and consumers the perpetual right to distribute and redistribute the base layer of container images built on UBI. This is quite similar to what you would get with Fedora, CentOS or Ubuntu base images (but, UBI fully supported when ran on RHEL/OpenShift - the others are not). The UBI EULA does not alleviate users from any of the underlying open source license restrictions (attribution, distribution, etc). Nor does the UBI EULA alleviate users of complying with US law (export control, encryption, etc).

Open source software is open source software, in or out of UBI (or any other base image), and Red Hat trademarks are still Red Hat trademarks.

What's the difference between the UBI EULA and the Red Hat Enterprise Linux EULA?

TL;DR - the the UBI EULA let's you redistribute the UBI base image and RPMs, the Red Hat Enterprise Linux one does not.

The Red Hat Enterprise Linux EULA is essentially just an agreement between paying users of Red Hat bits and Red Hat. It's voluntarily "signed" - but, if a customer breaks it, Red Hat has the legal right to end our relationship with that customer (aka no more support, no more updates for products, etc).

Personally, I think this is a very fair arrangement considering Red Hat contributes heavily to bunches of upstream projects (Fedora, Linux kernel, Kubernetes, etc), thereby giving community users access to very powerful, free (as in beer) software. This "contract to pay" model is also a great way for Red Hat to earn money for the work we do.

The problem is, the world changed. Historically, with RPMs, dependencies were resolved after the application was distributed, at the time when the end users installed the application. A customer installed the application so ISVs and community members didn't have to distribute Red Hat bits. Now, with container images, the dependencies are resolved at build time, before distribution. Container images essentially drag bits of the operating system along when building an application, before distribution. This means that many ISVs and community projects need the right to distribute these bits embedded in container images. And thus, UBI was born to solve this problem.

Check out the two different EULAs here:

• UBI EULA
• Red Hat EULA

Conclusion

Consult your own lawyer for specific licensing and open source compliance questions, but hopefully now you can frame the questions better. I am happy to update this article and Feel free to ask questions.

Follow me on Twitter: @fatherlinux

Originally posted on June 10th 2019 at: https://crunchtools.com/ubi-licensing/