Responsibili es of using third-party so ware in Oracle Products

Congratula ons! You chose your third party so ware wisely, you got your approval, so now you’re set for
life, right?

[Clip of Walter White from Breaking Bad:] “We're just ge ng started.”

Indeed, you’re now at the point where you can begin developing with your approved open source
so ware, but your work is not yet over and there are s ll some things you need to do, before you can
release your product, and a er.

It’s like adop ng a cat. [Picking up Peter Pawker.] You did the hard work to find the right animal for your
home, but once they’re in your home, you have to register them, feed them, post 237 cute YouTube
videos of them doing things cats do, teach them not to scratch the nice couch… [Looking at Peter:]
Yeah…you…

So welcome to the last video in our third party so ware compliance series where we will talk about your
responsibili es when it comes to using open source so ware.

Earlier in this series, we talked about some of the requirements of open source licenses, including one
that is almost universal: a ribu ons. If you distribute third-party code in your product in any way, you
have to give credit where it’s due and let the world know about it. Remember, this is one of the main
reasons why the Third Party License Tracking Applica on exists – that and to give us headaches so strong
that pharmaceu cal companies send balloongrams directly to our team every year.

One of the required steps in the release process for your product is to gather the required a ribu ons
for all distributed open source components. In PLS, there is a Documenta on A ribu on report that will
do this for you: it fetches the appropriate field from every one of your approvals, and concatenates them
all into a giant pile of LEGO bricks just wai ng to be assembled by your team’s talented documenta on
writer into a beau ful house, a house we call a LIUM [show house built of LEGOs], for License
Informa on User Manual. If you don’t have a doc writer, you might luck out and find one wandering
around looking for work outside your local public library.

The doc manager then has to sign off during the release process to confirm that all so ware requiring
these a ribu ons are accounted for and uploaded to oracle.com and/or included with the product. They
are basically the ones saying, “Nope, no infringement here!”

For details on what needs to go into a LIUM, and where to put it, refer to this document maintained by
HQINFO in Global Business Prac ces. You’ll also find this link in our Third Party Approval FAQ under
“What is a LIUM?”

The other requirement common to many open source licenses is providing the original source code for
the component, and, in some cases, any modifica ons that were made. If you recall from our FOSS
License Primer video, weak copyle licenses and strong copyle licenses have a provision that states
customers can ask for the sources for the binaries that we distribute under those licenses. We at Oracle
believe in efficiency — stop laughing! — and we don’t wait for customers to ask, because if they do so
ten years a er we released the product, there may be nobody le to figure out where the sources we
used are located. So our policy is to post the sources for this material to oracle.com at the me we
release the product.

But we at Oracle like to go one step further. Because this requirement extends to all so ware, even
downstream dependencies, trying to iden fy all the so ware with the licenses that require us to share
can be a challenge. It’s like having to share the serial number of every blue brick in your LEGO
house…but some of the walls inside might be blue, too, so it is easy to miss something, and you don’t
want to have to take it all apart again. (I certainly don’t want to pay my kids another twenty bucks to
reassemble this.)

So to make things easier, product teams are instructed to share the sources for ALL open source code in
our products, even when the license does NOT require it. And when it comes to sharing any
modifica ons made, we again try to do it for everything, and not just where necessary. Now if you
remember, permissive licenses allow us to make changes without sharing them, and those can even
include proprietary informa on or secret keys that would be unwise to unleash on the world. In these
cases, you should of course keep those modifica ons within Oracle, but you should s ll share the
sources for the original version of the code so customers have an idea of what’s in the sausage. The steps
to do this and permissible excep ons are all outlined on the Corporate Architecture wiki.

And lastly, before you distribute that code, or push it into produc on environments in our cloud, you
need to make sure any binaries you use are built on our networks. We discussed this in an earlier video
and may have reminded you about it during the approval process so that it would not come to you as a
shock at the last minute, but let’s recap.

Oracle has a Build From Source policy that requires most third party binaries to be built on our networks
for a variety of reasons. For one, third party so ware is increasingly becoming vic m to supply chain
a acks, typosqua ng, and other forms of distribu on involving malicious content disguised as trusted
so ware. Downloading only the original source and building it ourselves reduces the chances of this
so ware being deployed in our products. Maybe the version that was uploaded had some differences, or
maybe it wasn’t the version that was supposed to be uploaded at all.

I know what you’re thinking, and no, this approach is not going to address every security risk. It won’t be
of much use when the malicious ac vity is in the sources, true. But…we don't wear seatbelts on a plane
to protect us from meteor showers, or a pit of falling snakes …yet we s ll wear them.

But this is NOT just about security.

Some open source licenses require that we not only provide the original sources for the third party
binaries we distribute, but that the exact same binaries can be reproduced by a user from those sources
and following our instruc ons. If you’re ge ng your binaries from some repository on the Internet, who
knows what process the uploader followed? There is no sure way to know how third-party binaries were
built, and whether the sources we provide will yield the same result, unless we do it ourselves.

In addi on, your customers are not just paying to build the house, so to speak, they’re paying you to
support it when something breaks. If a problem crops up, and you can’t rely on the original builder to fix
the problem fast enough or at all, our customers aren’t going to care, they're just going to look to you to
do it. And if you don’t know HOW to put the house back together, how are you going to meet those
obliga ons?
This policy does contain some excep ons: for example, local builds are not required for so ware that is
only used internally, or for cryptographic so ware that is signed by the original vendor. And the policy
doesn't say that you have to build the code if another team at Oracle has done this – like, say, the Oracle
Linux team. But if nobody else has, the job falls to you. For the complete set of build from source
requirements, refer to the policy page on the Corporate Architecture wiki at the URL shown here.

Okay, you checked all the boxes and your product has been released. Even now, as you move on to
developing the next version, you and others are faced with the task of maintenance.

At the top of your list should be keeping your third-party code up to date.

Typically that means checking for security vulnerabili es and updated versions of any of this so ware at
a regular cadence. Just because something was deemed secure when you released the product doesn’t
mean that this will always be the case. Obviously, new security vulnerabili es can be discovered at any
me and when they are, we need to make sure we’re addressing them as swi ly as possible.

But don't make the mistake of assuming that the only reason to upgrade your third-party so ware is to
address security vulnerabili es. There are all kinds of cri cal problems beyond vulnerabili es that can be
just as damaging to our customers, and you're on the hook for those, too. Furthermore, we don't want
to risk staying on an outdated version and being told by the project maintainers that they can't provide a
fix to a problem, or even a new security vulnerability, because they aren't patching that far back. In fact,
if your release is under Premier Support in Oracle's Life me Support Policy, we are actually obligated to
keep all third-party so ware up-to-date as part of the support agreement. Make upli ing your code as
much of a regular rou ne for your product team as checking out early on Fridays for Margarita Happy
Hour.

And don’t forget about your fourth party dependencies. Except in rare circumstances, like a change in
license, you can upgrade those dependencies without having to go through an en re approval again by
simply upda ng your exis ng business approval. So keep a careful eye on those underlying crypto
libraries, too.

[Show LEGO house going up and down across screen.] Get it? Bouncy Castle.

We also need to regularly check each project to make sure it hasn't been abandoned. We don't want to
be reaching out for help with a cri cal issue only to find that the author has le the world of open source
development behind for a simpler, more peaceful life as a military paratrooper. When so ware we
depend on does fall into disuse, the responsibility for maintaining that so ware in our products then falls
to us. At that point, we treat it just as if it were Oracle code, and subject it to the same rigorous
standards.

Our open source approval policies have a great way of helping you keep track of all these requirements,
with the use of end dates on your business approvals. These end dates serve as regular reminders to do
everything we just talked about at periodic intervals. When the end date is reached on a specific
approval, you can no longer include the so ware for that approval in any new release you plan to put
out, so DO NOT let these sneak up on you. For those BAs that have expired, you can address the issue by
either upgrading the so ware, which resets the clock, reaching out to your security lead to provide an
extension, or making arrangements with your VP to allocate resources for maintaining the code yourself.
Or, failing all that, you can just replace the code with something else. You'll get reminders about
upcoming end dates six months, three months, and one week before that date, and you can sign up
addi onal people (including people you don't like), or even mailing lists, to get those no fica ons as
well. Just make sure they aren't ge ng filtered into your spam folder. Save that for all the reminders
about retaking those other, more basic compliance training classes.

So, to sum up, a er you get your approval, but before you release your product, make sure:

• Gather and publish your a ribu ons into a LIUM

• Post the sources for your open source material to oracle.com, and

• Make sure your binaries are all compliant with our Build from Source policy

Then a er you release product:

• Monitor the end dates on your BAs so you don't find your release blocked

• Check regularly for and apply updates to your third-party code and fourth-party dependencies,
and

• Remediate or bring in-house any abandoned projects

And, of course, p your servers, by which we mean Corporate Architecture. [Holding up mason jar with a
few singles, lots of coins, and various junk.] “Oooh! Free 6-inch sub!”

Now congratula ons are in order for real. You've made it to the end of our third-party compliance
training series, and you're on your way to becoming experts in no me. From here, you can move on to
our tooling series of videos, which will take you through the ins and outs of using the 3rd Party License
Tracking Applica on. Don't worry, they're not like... [poin ng to my face] this.

If you have any concerns or complaints about anything in these videos, please send us an email at the
link you see here. Or, you can post your ques ons on Slack via the #ask-corparch Slack channel where
our AI-generated responses will offer you all kinds of advice – some of it might even be good.

We hope you enjoyed this somewhat unorthodox approach to training and hope that this look at our
third party policies resonated with you in some way. We look forward to helping you in making our
products and services the best on the market. Thank you for watching and good luck.