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 a surge 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 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 employee’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 that we operate in. We do recognize that open source is more than a development model and that there are ideals behind it; the idea is to respect communities and user’s freedoms, and specifically, the freedoms to use, study, share, and improve the software. SUSE has many engineers who passionately stand behind “free and open source software” and supports 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 “open source” to be software, including its documentation, released under a license that is compatible with OSI’s open source definition to be open source.
The audience of this policy is mainly SUSE employees. However, we hope the policy inspires our partners, customers, and users to follow the same model.
The policy covers two main areas; 1. How we produce open source software. This includes: how we contribute to upstream projects, how we manage the projects where we are ourselves upstream, what legal aspects have to be considered, where code is put, and how to be a good citizen of the open source community.
- How we consume open source software. Which means: how we use it in our products, how we deal with licenses, how we integrate it in our products with our open “factory first” work flow. We have distributed thousands of open source projects as part of our products for more than 25 years and we have learned a thing or two while doing it.
|Commit message||A good explanation and rationale of changes to files under source code management.|
|Contributor||Could be anyone who comments on an issue or pull request, people who add value to the project (whether it’s triaging issues, writing code or documentation, filing bugs, contributing use cases, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). (Taken from https://opensource.guide/leadership-and-governance/ ).|
|Employee||For the purposes of this policy, the term employee includes all individuals working at all levels at all SUSE entities and affiliate businesses, whether permanent, fixed- term or temporary.|
|openSUSE Factory||openSUSE Factory is the source for openSUSE Tumbleweed and the intermediate upstream for select SUSE products.|
|Patch||A patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it.|
|Pull request||Contributions to a source code repository that uses a version control system are commonly made by means of a pull request, also known as a merge request. The contributor requests that the project maintainer pull the source code change, hence the name “pull request”. The maintainer has to merge the pull request if the contribution should become part of the source base.|
|Upstream||Within information technology, the term upstream (and related term “downstream”) refers to the flow of data. An upstream in open source is the source repository and project where contributions happen and releases are made. The contributions flow from upstream to downstream. When talking about an upstream, it’s usually the precursor to other projects and products. One of the best-known examples is the Linux kernel, which is an upstream project for many Linux distributions.|
|Upstream First||Patches are contributed upstream and included downstream only if they become part of the upstream.|
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 to enable our engineers to produce and contribute to open source software.
Contributing to Open Source Projects
SUSE considers itself as a part of the global open source community. When we intend to improve or fix bugs in open source projects, we contribute our modifications to upstream as early as possible.
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 license definition.
There are many ways to contribute to open source projects besides writing code, writing documentation, reporting bugs, helping users, discussing development and more. Apply the spirit of the guideline here as well. Be open, respectful, and collaborate. Use the agreed/accepted license of the upstream project also for non-code contributions provided it is a license that is compatible with the open source license definition.
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 right 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.
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 behavior. See the openSUSE Guiding Principles for an example of how we envision the community for one of our main projects.
Creating new projects
Our ‘Contributing to Open Source Projects’ policy means that we identify collaboration and contribution opportunities with existing upstream projects for new open source projects as well. 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 new projects is GitHub. We have three principal organizations on GitHub: openSUSE, Rancher, and SUSE.
The principal organizations do not imply an exclusive requirement. Other organizations can be created at the discretion of the development team responsible for the project. Example of other organizations in GitHub for projects lead by SUSE are yast, OSInside, and aquarist-labs. Use the respective channels to get in contact with the teams if your project falls under their umbrella.
All projects originated and/or led by SUSE are open for contributions. Contributions by anyone are welcome and encouraged. A contributor, a person creating a Pull Request (PR) or constructively commenting on discussions, is not necessarily a committer. A committer is a person with write access to the project. Contributions are accepted under the conditions of the chosen licenses for both code and non-code.
For projects which are expected to have exclusive committer rights by SUSE and where we - as a company - intend to take full responsibility for the project, SUSE or Rancher are the organizations to use, depending on the scope. To create new projects under the SUSE organization, contact the administrators of the organization at
firstname.lastname@example.org. Rancher projects generally graduate from the rancher-sandbox organization.
For projects which have committer rights for non employees, or for projects which are open to this model, consider the openSUSE GitHub organization. openSUSE administrators can be reached by writing to the public mailing list email@example.com.
When creating new projects it is good practice to add
CONTRIBUTING.md files explaining the project and how to contribute. Projects must have a declared license.
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 license definition, which matches the goal of the project and its interactions with other projects. This applies to both code and non-code licenses; for example consider the Creative Commons license for documentation, Wiki and other non-code artifacts.
We typically don’t use contributor agreements for our own projects, but instead 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.
Consuming Open Source Software
We consume a lot of open source software as users, as a base for products or other projects. We also package a lot of open source software as part of the SUSE distributions.
Note: When running open source software 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 we follow the guidelines below.
Managing Source Code
For all the software we redistribute we keep the source code. This is necessary to comply with the open source software licenses, the spirit of the open source model, and to create a bill of materials for our products which lists all components including dependencies. Bill of Materials should include names, versions, licenses, and upstream URLs for all components.
Managing a copy of the source code means we are creating a downstream copy for each upstream. This allows us to fix problems and apply patches without being dependent on any third party.
By default we follow ‘Upstream First’. Products can also choose to operate under ‘Intermediate Upstream First’.
When using the Open Build Service and following the standard packaging guidelines the management of open source code is mostly taken care of.
Intermediate Upstream First
This principle is a continuation of “Upstream First”.
An “intermediate upstream” is any project that itself has another upstream for which it is a downstream project. It functions as an upstream project for one or more downstream projects.
These “intermediate upstreams” should be open for contribution and public, which adds extra maintenance efforts.
The use of an “intermediate upstream” should be assessed case by case without bias, taking benefits and costs into account.
“Factory First” means that we use openSUSE Factory as an intermediate upstream. “Factory First” is used for select SUSE products. It reduces maintenance effort and leverages the community.
This still includes the responsibility to follow guidelines under “Contributing to Open Source Projects” for all individual upstream projects, such as the Linux kernel.
“Factory First” is strongly recommended for products that are tightly coupled to those that use the “Factory First” model.
“Factory First” applies to all new components for any product opting into “Factory First”. Creating additional intermediate upstreams is strongly discouraged.
SUSE conducts a legal review of the 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 incompatibilities. If you follow the Factory First approach and manage your code in the build service the legal review is automatically part of the process.
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 “@suse.com” email address for contributions.
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.
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.
Reporting a Violation of This Policy
When you are unsure, or have questions or concerns, please discuss them with your manager. They can help you or facilitate help from others.
If you have any inquiries about FOSS compliance at SUSE please contact Ciaran Farrell firstname.lastname@example.org.
Roles and Responsibilities
Employees have the responsibility to follow and familiarize themselves with the policy.
|Public facing version of SUSE Open Source policy||https://opensource.suse.com/suse-open-source-policy|
|The Source of the SUSE Open Source policy||https://github.com/SUSE/open-source-policy|
Proposed changes are reviewed via pull requests to https://github.com/SUSE/open-source-policy/ by policy reviewers and the owner. At least one approval is needed to accept the change in GitHub.
The Policy itself is revisited and republished at least on an annual basis. Pull requests are reviewed in a timely fashion or as needed.
Copyright 2021 SUSE LLC. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.