From Mageia wiki
Jump to: navigation, search

Acceptable licenses

There are three major sections for packages in Mageia: core, nonfree and tainted.

  • The core sections accepts only free / open source licensed software. This is considered to mean all licenses accepted as 'Free Software licenses' by the Free Software Foundation and all licenses accepted as 'open source licenses' by the Open Source Initiative, and any license which is effectively equivalent to one of these licenses (it uses different language, but the provisions work out to be the same). A list of FSF-approved licenses is available here: all licenses listed under "GPL-Compatible Free Software Licenses" and "GPL-Incompatible Free Software Licenses" are acceptable. A list of OSI-approved licenses is available here.
  • The nonfree section accepts software under a license that is not free or open source, but permits unlimited public redistribution. No list of such licenses is available: packages are assessed on a case-by-case basis.
  • The tainted section accepts software under a license that is free or open source but which cannot be redistributed publicly in certain areas of the world for other reasons such as patent issues.

Licensing guidelines for packages

For package maintainers, Mageia follows the Fedora licensing guidelines, with four important differences. The differences are covered below. In all other respects, please follow the Fedora guidelines. Where Fedora mailing lists are referred to, please substitute the mageia dev mailing list: in other words, all discussion of licensing issues is to take place on the mageia dev mailing list, and if the license of your package changes, you must notify the mageia dev mailing list of this change. Where an email address for a particular individual at Fedora is mentioned, please substitute the equivalent individual in the Mageia community (some name here). Issues to which particular attention must be paid include versioned licenses, and multiple and mixed license cases. Please take particular notice of the various different cases referring to the GPL and LGPL, including the fact that where the source for an application does not specifically state what version(s) of the license apply, it is technically licensed under any version of the license (and so uses the GPLv2+ or LGPLv2+ short name).

Artistic license

The Fedora guidelines consider the original, unclarified Artistic License to be unacceptable. As the Open Source Initiative considers it an open source license, under the Mageia policy, it is an acceptable license for the core repository.

Similar licenses

The Fedora guidelines imply that any software that is not licensed under one of the licenses explicitly approved by the FSF or the OSI cannot be included in main or contrib. However, as explained above, Mageia considers licenses that have effectively the same provisions as an approved license, but phrased in different language, to be acceptable. In this case, the License field in the package should consist of the approved short name for the most similar license, followed by -like. For instance, a package whose license was effectively equivalent to the BSD license would have this field:

 License: BSD-like

Non-free licenses

As mentioned above, the nonfree section in Mageia accepts non-free packages. When working with these repositories, the following strings are acceptable for the License field:

  • Freeware
  • Shareware

Pick the string that best describes the package.
Freeware refers to software which can be redistributed without charge in binary form in its entirety, but which is not under a free or open source license. (Generally access to the source code is restricted).
Shareware refers to software redistributable without charge, which requires payment to the copyright holder or another body in order to use beyond a trial period and/or to obtain additional functionality.
For all non-free packages, the complete license text should be included in the package.

Including license text in packages

The Fedora guidelines state that where the license text is included in the source for the package, it must be included in the compiled package as a documentation file.

In Mageia, when the license requires a copy of the license text to be included with the compiled code, the license text must be included in the compiled package as a documentation file. When the license does not require a copy of the license text to be included with the compiled code, our policy is that the license text should not be included in the package. Lists follow to clarify which licenses require a copy of the license text to be included with the package, and which do not.

Copy of license text required

  • BSD

Copy of license text not required

  • GPL (all versions)
  • MIT

Standard license names

Mageia follows the Mandriva/Fedora license naming convention, and in all cases the names from the Short Name column of the Fedora license list should be used in Mageia.

Licensing of Mageia source RPMs

Unless otherwise specified in the RPM spec file or patch header, all spec files and self-written patches produced by Mageia contributors are MIT-licensed, with the following default license text:

The MIT License (MIT)
Copyright (c) 2010-2016 Mageia.Org

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

For spec files snippets or patches taken from upstream or other distributions, the licensing guidelines of these entities prevail over the above guidelines.