This is a draf space please see openSUSE:Accepted_licences for the official document.

Introduction

We try to only use Open Source licenses. There are different lists of which licenses are acceptable licenses in open source distributions (FSF, OSI, Fedora, Debian), while most of them are similar openSUSE might have its own deviations.

This page is largely inspired from the Fedora project one.

Choosing a license

Skip this if there already is a license. If you are in the position to chose one, e.g. because you are the full and only copyright holder of the project then you should not look at the allowed license list as some of them are not recommended. There are many things that can influence what license one might want to use. An intentionally non-exhaustive list of licenses that are recommended:

AGPL-3.0-only and see below for proxy or use AGPL-3.0-or-later. Use if you feel the GPL does not require sharing their changes in enough situations.
GPL-3.0-only and see below for proxy or use GPL-3.0-or-later. Use if you want people to share changes they make to the work under the same license.
"GPL-3.0-only OR GPL-2.0-only" which (see SPDX) in prose means "The GPL-3.0-only license or (at your option) the GPL-2.0-only license". See below for proxy or use GPL-2.0-or-later. Use when you want to be compatible with both versions of the GPL.
LGPL-2.1 Use if you want people to share changes they make to the library under the same license, but do not want to require people to share the software using the library.
Apache-2.0 if you do not want to require people to share any changes they make to the work.
MIT-0 if you do not want to require people to share their changes nor require giving you credit.

These are roughly ordered by how strong of a copyleft the license is, that means roughly ordered from requiring to share alike more changes to less. Finding the level that is appropriate is complex and thus not described in this text, maybe at a later time we can link to a good explanation.

( The above and openSUSE elsewhere uses SPDX notation to refer to licenses, though SPDX also lists licenses that are not allowed. )

When using -only license variants designate a proxy

To be able to make a license upgrade easy, but also not rely on the FSF for it you can add the following to your project when using the (A)GPL-3.0-only:

"Your Name acts as a proxy to decide if a future version of the GNU General Public License may (at your option) be used as a license for this project / for the content in this repository."

Overview

Software licenses used in openSUSE project should comply with the Open Source Definition.

Licenses in openSUSE Spec Files

Packagers usually come into contact with software licensing through the spec file. A spec file can declare the license(s) for the entire package or for individual subpackages. Licenses should be declared using SPDX shortname format. SPDX and its associated list of licenses is relatively young, however, the list is limited and does not cover all licenses an openSUSE packager will typically have to address. To temporarily work around this limitation, we have created a spreadsheet which contains not only the existing SPDX licenses but also many other licenses which are acceptable for either openSUSE Factory or openSUSE NonFree.

See obs-service-format_spec_file for the list of all recognized licenses. Using a license identifier outside of this list will result into a following build failure.

 E: invalid-license (Badness: 100000) $LICENSE

If you still can't find a suitable license short name there, you should file a bug using the category SUSE Tools -> SUSE Linux Legal Issues.

As well as using a predefined syntax for declaring licenses, openSUSE also recognizes a kind of license grammar in spec files. You can use operators such as 'and' to declare an aggregation of licenses, or 'or' to show that either one or the other license should be chosen. You can also use brackets to gather licenses, for example

License: (MIT or GPL-2.0) and LGPL-2.1+

could be the declaration for a package with an executable binary and a corresponding LGPL-2.1+ licensed library.

Another thing to be aware of when you are writing spec files is that subpackages will inherit the main license of the package if the packager omits to enter a license specifically for that subpackage. This is not always ideal. For example, if you decide to create a separate subpackage for documentation, you should check if the documentation is licensed under e.g. GFDL-1.1 rather than the (e.g.) GPL-2.0+ license of the main package. It is advisable to always add a license to a subpackage - even if the subpackage is coincidentally under the same license as the main package. This makes it immediately obvious to anybody reading the spec file later.

Finally, license texts should always be copied into the package. This is usually done by adding the filename to the %files section using the %license macro in the spec file. Licenses are often found in files with names such as COPYING, COPYING.LIB, LICENSE.txt etc. See [1] for a discussion around that.

Reporting a Violation

If you are in doubt as to whether a particular license conforms with the Open Source Definition, you should file a bug using the category SUSE Tools -> SUSE Linux Legal Issues.

Exceptions

openSUSE:Build_Service_application_blacklist

openSUSE talk:Accepted licences