Open Source Contribution

Policy

Function/Department: Product Development

Region: Global
Effective: 2 February 2021
Legal notice
Copyright © 2023, Blue Yonder Group, Inc. All rights reserved. Blue Yonder is a Registered Trademark of
Blue Yonder Group, Inc. All other company and product names may be Trademarks, Registered
Trademarks or Service Marks of the companies with which they are associated.

Retention policy
The retention period for Blue Yonder documents varies based on the document type and the department,
region, and country associated with the document. For more information, see the Worldwide Record
Retention Policy document.
Policy Management
Policy Owner: Sebastian Neubauer, Staff Data Scientist
Policy Approver(s): Gabriel Kohen, Sr Principal Software Engineer
Next Review Date: 1 March 2024

Revision history
Date Description Modified By Approved By
2 February 2021 Release of Policy Sebastian Neubauer Global E&C Committee

24 February 2022 Annual review Sebastian Neubauer

1 March 2023 Annual review Sebastian Neubauer John Vrankovich, Gabriel

Kohen
Table of Contents
Open Source Contribution Policy 1
Purpose 1
Policy 1
Policy Scope 1
Communication 1
Contribution to Open Source Projects 1
Managing the Lifecycle of a Blue Yonder Contributed OSS Project 2
Net New Open Source Contribution 2
Contributors 3
Decommission a Component 3
Definitions 4
Reference 4
Appendix A: Recommendations 5
 Open Source Contribution Policy

Open Source Contribution Policy

Purpose
In Blue Yonder we embrace contributing to open source to increase the quality of our products (Linus
Law), increase the Blue Yonder brand and attract talent. Furthermore, open source is a cornerstone of
the accessibility of the Blue Yonder Platform for external users. By using widely adopted open source
frameworks and their well-known interfaces, we lower the barrier for users to adopt the Blue yonder
platform as they are likely already familiar with the open source frameworks and libraries.
The purpose of this policy is to protect both, the interests of the company and the interests of the
associates, by establishing a simple, transparent and effective process for open source contributions.
This document is meant to define the mandatory and recommended steps Blue Yonder associates must
or should follow to make sure the release of source code under an open source license is in compliance
with the company, financial, regulatory, and legislative authorities.
In this policy we distinguish between two types of contributions to open source software, contributions
and net new contributions.

Policy

Policy Scope
This policy applies to all Blue Yonder Associates worldwide.

Communication
Unless stated otherwise, the Architecture Review Board (ARB) is responsible for everything around the
contribution of OSS. You are welcome to ask any questions or requests to the ARB in the ARB OSS Teams
channel (see Definitions).

Contribution to Open Source Projects

Contributions can be new features, bugfixes, additions to documentation, or any other contribution to
existing open source projects.
The main concern for Blue Yonder here is the loss of intellectual property or business-related reasons,
whereas the main concerns for the associate are ensuring that contributions are not in violation to their
work contract, potential conflicts of interest, and unclear copyright situations.
For every open source project, before an associate contributes one or more changes, the ARB gets
informed in the ARB OSS Teams channel (see Definitions). The ARB rejects or approves the request
considering the following criteria:

l Is the license that applies to the contribution compatible with the interests of Blue Yonder?

l Is there an unacceptable violation of the intellectual property of Blue Yonder?

l Does the associate hold all the rights for the planned contribution?

l Is there any violation of our code of conduct?

POLI-PRD-GLOB-XX-EN-003 1
Blue Yonder Group, Inc. - Confidential
 Open Source Contribution Policy

l Is there any business-related issue that prohibits the contribution?

l Is there any other issue that might harm Blue Yonder or the associate?

Once the request is approved, the associate or the team can contribute one or more changes without
having to approve each contribution as long as the ARB does not withdraw the approval. Furthermore, if
there is reason to believe that any of the criteria above changed since the approval, the associate or the
team must inform the ARB in the ARB OSS Teams channel (see Definitions).

Note: If you need to sign a CLA in the OSS project for your contribution, you can only sign the CLA
“On behalf of Blue Yonder” after the ARB approved the CLA. In such a case please contact the ARB in
advance (ARB OSS Teams channel, see Definitions).

Note : It is a common practice to make OSS contributions as an individual contributor, without

mentioning explicitly that you are making this contribution “for Blue Yonder”. You cannot use your
Blue Yonder enterprise GitHub account outside of the Blue Yonder enterprise GitHub org, so you have
to use a private GitHub account for any OSS contribution.

IMPORTANT: Being an associate of Blue Yonder, you are not free to contribute anything, whether in
your business hours or in your free time. For example, you might not be legally allowed to open source
a demand forecasting algorithm in your spare time. If you have doubts about a planned private
contribution, if it might violate any law, contract or is a conflict of interest, feel free to contact the ARB
in the ARB OSS Teams channel and ask for guidance. This is not to discourage private contributions;
this is simply to protect you from any future legal matters.

Blue Yonder Github account Private Github account

Non work context l Not possible l Allowed
OSS contribution l If there is a potential conflict of
interest, inform the ARB.

Work context OSS l Not possible l Allowed and recommended

contribution l Follow the OSS Contribution
policy

Managing the Lifecycle of a Blue Yonder Contributed OSS Project

Net New Open Source Contribution

Net new open source contribution means, we open source a new project based on source code created at
Blue Yonder. Due to the ownership and as it is a new project, some more things need to be considered
compared to contributions to existing OSS projects. Projects that are founded by Blue Yonder are
significantly shaping the “tech brand” of Blue Yonder, so the public image of this publication must be
considered much more than for contributions to existing OSS projects.

POLI-PRD-GLOB-XX-EN-003 2
Blue Yonder Group, Inc. - Confidential
 Open Source Contribution Policy

The main concern for Blue Yonder here is the loss of intellectual property and whether we have enough
resources and incentives to maintain this project sustainably. The main concerns for the associate are
ensuring that contributions are not in violation to their work contract, potential conflicts of interest,
unclear copyright situations, and if the company backs the project with enough resources to be able to
maintain it sustainably.
In order to adhere to the goals of the policy each Blue Yonder project intended to be open source must
go through the following steps. These are mandatory unless stated otherwise:

1. Preparations: If you have an idea to open source a project, first discuss the idea within your team
and all other involved parties. Things to clarify are:

l Does it violate any interest of Blue Yonder or other parties (IP, copyright, code of conduct,
business reasons, …)?

l Does it fit our Blue Yonder “image” (technology, marketing, quality, …)?

l Who are the core maintainers?

l Which OSS license is appropriate?

l Is a DCO sufficient, or do we require a CLA?

2. OSS contribution request to the ARB in the ARB OSS Teams channel (see Definitions).. The ARB
will decide (or delegate) mainly based on your considerations above.

3. Once you have the approval, prepare the actual project in a non-public repository for publication,
including CI/CD automation, documentation, license information. Seek for code reviews from
colleagues, to ensure high quality from the beginning. Make sure to clear the repository repo from
all Blue Yonder internal information (associate or customer names, internal project names, etc…),
best is to squash the complete history.

4. When the preparations are finalized, ask the ARB for the publication in a public repo.

Contributors
We require all contributors to a project contributed by Blue Yonder to sign off contributions with a
Developer Certificate of Origin statement (DCO https://developercertificate.org/ ). The ARB might
require for critical projects that external contributors must sign a Contributor License Agreement (CLA),
but this is only an exception.

Decommission a Component
When Blue Yonder sees a need to decommission / sunset / discontinue the OSS component, the OSS
component team must reach out to the ARB to notify about the decommission intent.
The current Blue Yonder collaborators shall reach out to the component’s community to ask for new
public contributors for the repository. Once found, the new contributors should be assigned, and the
repository should be removed from Blue Yonder’s GitHub organization.
If no interest or public collaborators have been found, the GitHub repository must be removed.
If possible, update any blogs that the component is now maintained by the community or discontinued.

POLI-PRD-GLOB-XX-EN-003 3
Blue Yonder Group, Inc. - Confidential
 Open Source Contribution Policy

Definitions
Term Definition

ARB Blue Yonder Architecture Review Board.

ARB OSS Teams _Architecture Review Board / Open Source Contribution. MS Teams channel. Try
channel to be as verbose as possible: Type of contribution, which OSS project with a link,
purpose of the contribution, is a CLA needed, or any other relevant information.

CLA Contributor License Agreement is a signed contract which clarifies the rights of
both, Blue Yonder and the contributor. An example can be, that the contributor
needs to agree, that Blue Yonder can change the license of the project in future.

DCO Developer Certificate of Origin Which ensures, the author has all the rights of the
contribution and agrees to the license.

Organization The section within GitHub which included all of Blue Yonder’s public repositories.

OSS Open Source Software. Any program / component whose source code is made
available for use or modification as users or other developers see fit. Open source
software is usually developed as a public collaboration and made freely available.

PR Pull requests let you tell others about changes you've pushed to a branch in a
repository on GitHub. Once a pull request is opened, you can discuss and review
the potential changes with collaborators and add follow-up commits before your
changes are merged into the base branch.

Public Repository GitHub.com repository where a Blue Yonder’s open source project shall be
published.

Work Context Any activity with a direct connection to Blue Yonder. Be it a “work order” or a
voluntarily made OSS contribution where Blue Yonder is taking direct advantage
of the contribution.

Reference
l Blue Yonder Yammer Group

l Open Source Policy – The document refers to how Blue Yonder associates can utilize third party
software as opposed to this policy which deals on how to make a Blue Yonder software
component, published as open source to 3rd parties.

l Cybersecurity Policy – This policy should be taken into account when developing any Blue Yonder
software component.

POLI-PRD-GLOB-XX-EN-003 4
Blue Yonder Group, Inc. - Confidential
 Open Source Contribution Policy

Appendix A: Recommendations
Things to consider for a successful net new OSS contribution:

l Is the effort needed for the contribution (documentation, quality, tests, marketing, community
maintenance…) justified?

l Do you have committed “core contributors” that are able to invest enough time? More than one
would be highly recommended.

l We expect the core maintainers to actively grow a community around the project, by writing
blogposts, share on social media and work on reported issues and PRs. Otherwise, the ARB might
decide to decommission the project.

l How does it fit into the existing open source space/market (similar projects, competitors,
compatibilities to other projects, could it also just be a contribution to an existing project, …)?

l Is there a chance, that anyone outside Blue Yonder might take advantage of this project?
Maintaining an open source project really only makes sense if there is a chance of anyone else
then Blue Yonder might take advantage of it.

POLI-PRD-GLOB-XX-EN-003 5
Blue Yonder Group, Inc. - Confidential