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 – It depends. If you join the Red Hat Partner Connect Program and certify a container, yes – for more information see: Red Hat Extends Partner Offerings to Drive Open Hybrid Cloud Innovation. But, if you’re not part of that program, 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:

How do I distribute the UBI EULA with my image? And, can I distribute my own EULA for the software I put on top of UBI?

You do not need to distribute your own copy of the UBI EULA. A link to the up-to-date EULA is included in every UBI images as a label. This label should not be modified by images builders because it’s what satisfies the distribution requirement. You can easily view the label with the following command:

Command:

podman inspect ubi9 | grep com.redhat.license_terms

Output:

...

com.redhat.license_terms=\"https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI

...

If you need to add your own EULA for your application code, you can add another label during builds. For example, you could build like this:

Command:

podman build --label com.acme_corp.license_terms=\"https://www.amecorp.com/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/

8 comments on “Red Hat Universal Base Image and Licensing

  1. What about closed-source apps packaged on top of UBI, is that OK too?
    The traditional copyleft requirements on the binary itself of course apply:
    – can’t be linked to GPL libs
    – if linked to LGPL libs such as glibc, has to allow replacing the LGPL parts, which in practice means dynamic linking.

    I’m asking about the somewhat novel situation that distributing the app implies distributing the whole image, which I expect includes many GPL parts.
    All binaries in the UBI itself should be covered by Red Hat taking a lot of care that source for RPMs is available online.
    But could the whole resulting image fall under GPL requirements as a derived “covered work”, to release code for the closed-source app too?
    My guess is this falls under what the GPL allows as “aggregate” of independent binaries (https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#section2, https://www.gnu.org/licenses/gpl-3.0.html#section5)?

    BTW, do any legal aspects of UBI change if instead of adding a new layer one “squashes” the derived image?

    [I Am Not A Lawyer; I work at Red Hat but am not involved with UBI, just curious.]

    1. Beni, all very good questions. I will try and answer them. Though I am not a lawyer, I have worked with them closely to launch UBI. I can genuinely say this has been a very unique experience. First note, we do not currently support compiling C/C++ binaries with UBI so we avoid tackling some of these deeper darker GPL questions to an extent. We really only target Python, Ruby, Java, .Net, Golang, Node.js and other high level languages which avoid this problem. We are actually taking a hard look at how to support C/C++ programs, mostly from a technical perspective. I would have to defer to Red Hat legal about dynamically linking versus statically compiling a binary, but right now we don’t support either with UBI. It should be noted that proprietary software has this exact same problem on Linux today. I don’t think there is anything novel with containers.

      Also, with the launch of RHEL 8.2, we just made it much easier for Partners, Customers, and Community members who build on UBI to redistribute source code on their own. This is sort of a risk gradient for entities other than Red Hat. Some will rely on Red Hat to always distribute this code, essentially for them, while others will be more conservative and prefer to pull the source containers and redistribute them, themselves side by side in their own registries. Here are the instructions we published:

      https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index#getting_ubi_container_image_source_code

      As for layers, that’s an easy one. Container layers are just tarballs, so one tarball or two or three, doesn’t matter. Same rules, any body can squash UBI images without affecting redistribution rights. As an aside, I also don’t see why it would affect support as long as they don’t replace a Red Hat library.

  2. This press release suggests that RHEL packages can be added to UBI images and they will still be distributable. “Red Hat Enterprise Linux with certified containers based on Red Hat Universal Base Image (UBI), which now enables partners to include any Red Hat Enterprise Linux user-space packages in UBI-based container images and redistribute them through both official Red Hat and third-party container registries. ”
    This seems to contradict your point 2, unless I’m missing something.
    https://www.redhat.com/en/about/press-releases/red-hat-extends-partner-offerings-drive-open-hybrid-cloud-innovation?sc_cid=701f2000000u72aAAA

    1. Thanks for the notice, I helped work on that press release! Point #2 was true when we launched, but is more nuanced now. I haven’t updated this article, mostly because I forgot about it! I’m going to make a quick update to point #2. Thanks again, it’s much appreciated.

Leave a Reply to fatherlinux Cancel reply

Your email address will not be published. Required fields are marked *