SUSE Open Source Policy


Organizations today face increasing pressure to become more agile and economically efficient in order to grow, compete and survive. They must leverage digital assets, information and an explosion of new infrastructure software innovation to fuel and enable their digital transformation.

These emerging infrastructure technologies, which are built on open source and Linux, create new levels of freedom and flexibility. As organizations embrace this freedom and flexibility, they demand open source solutions that are reliable, secure and enterprise ready. That’s what we do.

SUSE builds from its Linux heritage and works with an ecosystem of partners and communities to adapt and secure open source solutions backed by superior service and support. We enable customers to manage complexity, reduce cost and deliver business-critical services powering innovation and digital transformation.

Our truly open, open source solutions, flexible business practices, lack of enforced vendor lock-in and exceptional service are more critical to customer organizations than ever before.

Our consistent ability to meet these market demands creates a cycle of success, momentum and growth that allows SUSE to continue to deliver the open source innovation customers need to achieve their digital transformation goals.

Open Source

Open Source is at the heart of the SUSE business and development model. We believe that Open Source is not a zero-sum game but that collaboration in the open benefits all participants and creates a broader base for everybody to build upon. SUSE is proud to be a good citizen and leader of the global open source community. Our approach to Open Source is “Open Source first, upstream first”.

This document provides transparency on how SUSE operates and outlines our engineer’s guidelines on how to deal with Open Source. It might also serve as inspiration for others implementing Open Source policies.

SUSE uses the term “Open Source” for brevity and because it is the clearest descriptor in the context we are operating in. We do recognize that Open Source is more than just a development model and that there are ideals behind it, the ideals to respect users’ freedoms and community, and specifically the freedoms to use, study, share, and improve software. SUSE has many engineers passionately standing behind the ideals of Free and Open Source Software and support these ideals as a company.

When we discuss Open Source Software we refer to the definition of Open Source Licenses by the Open Source Initiative (“OSI”). SUSE considers software, including its documentation, released under a license that is compatible with OSI’s Open Source Definition to be Open Source.

Producing Open Source Software

We develop in the open and publish our code as Open Source. SUSE products are fully Open Source. There are only rare exceptions where we don’t release code as Open Source. Our development model is designed around Open Source to make it easy for our engineers to produce and contribute to Open Source software.

Contributing to Open Source Projects

SUSE considers itself as part of the global Open Source community. When we fix bugs or make other changes we operate under the maxime “upstream first”. That means we contribute all changes back to the community as early as possible so that they become part of the common base we build on.

Contributing Patches

When contributing to Open Source projects, follow the guidelines of those upstream projects. Respect their governance model and contribution policies. Use the license of the upstream project for your contribution provided it is a license that is compatible with the Open Source Definition.

Contributing Non-Code

There are many ways to contribute to Open Source projects other than writing code: Writing documentation, reporting bugs, helping users, discussing development, etc. Apply the spirit of the guideline here as well. Be open, respectful, and collaborate.

Contributor Licensing Agreements

Some projects require a contributor licensing agreement (CLA) which assigns certain rights to the governance body of the project. Before you can contribute to a project which requires a CLA, you need to make sure that SUSE has signed a corporate agreement for the project. SUSE already has agreements in place for many organizations, including Free Software Foundation, OpenStack, Cloud Foundry, Cloud Native Computing Foundation. If the project requires a CLA and is not listed here, contact your manager to establish what needs to be done to make contributions possible. Seek legal assistance if necessary.

Developer Certificate of Origin

Some projects require a Developer Certificate of Origin (DCO). This is typically done by adding a Signed-off-by trailer in the commit message to certify that the committer has the rights to do the contribution and to consent to publish it.

If a project requires a DCO make sure that you are meeting its requirements and follow the upstream guidelines to add your DCO to your contributions.

Creating new projects

Part of our “upstream first” philosophy is that we collaborate with and contribute to, upstream projects for new things too. Before starting a new project, review existing projects and evaluate if something which already exists could be used or the project could become an extension or part of an existing upstream project.

When SUSE starts new projects we usually publish them as Open Source. The standard place for that is GitHub. We have two principal organizations there: SUSE and openSUSE.

For projects which are exclusively maintained by SUSE and where we - as a company - intend to take full responsibility of the project, SUSE is the organization to use. To create new projects under the SUSE organization, contact the administrators of the organization at

For projects which have maintainers or co-maintainers from the community who are not employed by SUSE, or for projects which are open to this model, openSUSE is the organization to use. For openSUSE you can reach the administrators by writing to the public mailing list

No matter where the project lives, it will be open for collaboration and contributions from the community under the conditions of the chosen license. The GitHub organization only reflects the model of maintainership.

We use a couple of other organizations on GitHub - for example, YaST or the Open Build Service. Use the respective channels to get in contact with them if your project falls under their umbrella.

When creating new projects it is good practice to add a and a explaining the project and how to contribute.

When the project is part of a larger Open Source ecosystem, use the license which is usually used in this ecosystem. Otherwise choose a license compatible with the Open Source Definition, which matches the goal of the project and its interactions with other projects.

We typically don’t use contributor agreements for our own projects but rely on the Open Source licenses providing the necessary terms using the “inbound=outbound” model. This means that contributions are made under the same license under which the project is released.

The code you contribute upstream or publish as Open Source as part of your job at SUSE in your work time is copyrighted or otherwise owned by SUSE. Use “SUSE LLC” when attributing the copyright. Use your “” email address for contributions.


Although technical in nature, the Open Source community is first and foremost about people. Treat other people with respect. Be kind, be open, respect the culture of the community you are interacting with and be aware of the diversity of people in that community. Be aware that, particularly in electronic communication, you might misunderstand or misinterpret what others are saying or meaning. The reverse is also true.

Follow any codes of conduct and set a high bar for your own behaviour. See the openSUSE Guiding Principles for an example of how we envision the community for one of our main projects.

Consuming Open Source Software

We consume a lot of Open Source Software as users, as base for products or other projects. We also package a lot of Open Source Software as part of the SUSE distributions.

Using Open Source software is generally fine in most cases. When running it as a service there are some extra considerations necessary such as how to deal with privacy rights etc. These additional considerations are out of the scope for this document and you should seek the necessary advice.

When consuming Open Source in anything we distribute to others there are some guidelines to follow:


All code licensed under an OSI approved license can generally be used. Be careful when combining code with different licenses. Certain licenses are incompatible when combined in the same program. Mere aggregation in the distribution usually does not pose a problem. Consult with the SUSE legal team if you are not sure.

Managing Source Code

For all the software we distribute we need to keep the source code. This is necessary so we can give users and customers the source for the software in compliance with the Open Source software licenses and in the spirit of the Open Source model. We also need the code to be able to fix problems and apply patches without being dependent on any third party.

It is necessary to create a bill of materials for our products which lists all components being used including dependencies. The list should include names, version, license, and upstream URL for all components.

When using the Open Build Service and following the standard packaging guidelines the management of Open Source code is mostly taken care of.

Factory First

When packaging new Open Source software or adding changes to existing packages follow the “Factory First” model. “Factory” is the common code stream all our distributions are based on. It is the immediate source for openSUSE Tumbleweed and it eventually ends up in openSUSE Leap and the SUSE Linux Enterprise distributions. This is a continuation of the “Upstream First” principle on the distribution level. It reduces maintenance effort and leverages the community.

“Factory First” extends to other SUSE products. Packages for all products should generally come from the common code stream our distributions are based on. So for packages you need in any products contribute them to factory first.

SUSE conducts a legal review of code we distribute in order to make sure we have the rights to distribute the code and that there are no legal issues such as license incompabilities. If you follow the Factory First approach and manage your code in the build service the legal review is automatically part of the process.


SUSE is a founding member of the Open Invention Network (OIN). We are committed to the non-aggression patent pool and to reducing patent induced threats to the Linux ecosystem.


When you are unsure, have questions or concerns, please discuss with your manager. They can help you or facilitate help from others.

FOSS Liaison

If you have any inquiries about FOSS compliance at SUSE please contact Ciaran Farrell

Copyright 2018 SUSE LLC. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Generated from v1.0.2