Mitä voi paketoida

Kaikkea ei voi paketoida Fedorassa. Useimmat asiat, joita pidetään "vapaina ohjelmistoina" tai "avoimen lähdekoodin ohjelmistoina", ovat sallittuja, mutta niiden määritelmät eivät aina ole johdonmukaisia ja Fedoralla on muutamia erityisvaatimuksia ja poikkeuksia. Tämä on yleiskatsaus tiettyihin vaatimuksiin ja poikkeuksiin, mutta sen ei ole tarkoitus olla tyhjentävä. Jos kysymyksiä herää, Packaging Committee ja Legal Team ovat ensisijaiset paikat, joista saa vastaukset.

Lakiasiat

Joitakin ohjelmia (tai joissain tapauksissa ohjelmiston osia) ei voida paketoida laillisista syistä. Tämä sisältää lisensointiin, patentteihin, tavaramerkkilakiin jne. liittyviä kysymyksiä.

Katso erilaisia esimerkkejä seuraavilta sivuilta.

Luvaton sisältö

On tärkeää tehdä ero tietokoneessa suoritettavan koodin ja sisällön välillä. Vaikka koodi on sallittua (olettaen tietysti, että sillä on avoimen lähdekoodin kanssa yhteensopiva lisenssi, se ei ole juridisesti kyseenalainen jne.), vain tietynlainen sisältö on sallittua.

Sääntö on tämä:

Jos sisältö parantaa käyttöjärjestelmän käyttökokemusta, sisältö on sopiva paketoitavaksi Fedoraan. Tämä tarkoittaa sitä, että esimerkiksi fontit, teemat, leikekuvat ja taustakuvat ovat sopivia.

Sisältö on vielä tarkistettava sisällyttämiseksi. Sillä on oltava avoimen lähdekoodin kanssa yhteensopiva lisenssi, eikä se saa olla juridisesti kyseenalainen. Lisäksi sisällölle on useita lisärajoituksia:

  • Sisältö ei saa olla animoitua, simuloitua tai valokuvattua pornografiaa tai alastomuutta. Internetistä löytyy parempia paikkoja hankkia pornoa.

  • Sisältö ei saa olla loukkaavaa, syrjivää tai halventavaa. Jos et ole varma, kuuluuko jokin osa sisällöstä näihin, se luultavasti kuuluu.

  • FESCo voi tarkastaa kaiken sisällön, ja sillä on viimeinen sana siitä, voidaanko se sisällyttää vai ei.

Esimerkkejä sallitusta sisällöstä:

  • Paketoinnin dokumentaatio tai ohjetiedostot.

  • Toimisto-ohjelmistoissa käytettäviä leikekuvia.

  • Taustakuvat (ei loukkaavia, syrjiviä, joita voi luvallisesti vapaasti levittää).

  • Fontit (avoimen lähdekoodin lisenssillä, ilman omistus-/oikeudellisia ongelmia).

  • Pelitasoja ei pidetä sisältönä, koska pelit ilman tasoja eivät toimi.

  • Ohjelman tai teeman (tai dokumentaation) käyttämän lähdetarballin mukana tuleva ääni tai grafiikka ovat hyväksyttäviä.

  • Pelimusiikki tai -äänisisältö on sallittua, kunhan sisältö on vapaasti jaettavissa ilman rajoituksia ja muotoa ei ole patentoitu.

  • Lähdetarballiin sisältyviä esimerkkitiedostoja ei pidetä sisältönä.

Esimerkkejä sisällöstä, joka ei ole sallittua:

  • Sarjakuvan taidetiedostot

  • Uskonnolliset tekstit

  • Tiedostot patentoiduissa mediamuodoissa

Jos olet epävarma, katsotaanko jotain hyväksytyksi sisällöksi, kysy Packaging Committeelta tai, jos kysymyksesi on oikeudellinen, Legal Team:lta.

Paketit, jotka eivät ole käyttökelpoisia ilman ulkoista koodia

Some software is not functional or useful without the presence of external code dependencies in the runtime operating system environment. When those external code dependencies are non-free, legally unacceptable, or binary-only (with the exception of permissible firmware), then the dependent software is not acceptable for inclusion in Fedora. If the code dependencies are acceptable for Fedora, then they should be packaged and included in Fedora as a pre-requisite for inclusion of the dependent software. Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency).

This also means that packages which are not functional or useful without code or packages from third-party sources are not acceptable for inclusion in Fedora.

Only one kernel package

Fedora allows only a single kernel package; packages containing alternate kernels are not allowed in the distribution. If there are kernel features which would be generally useful, please communicate with the Kernel Team.

No external kernel modules

Fedora does not allow kernel modules to be packaged outside of the main kernel package. You should communicate with the Kernel Team regarding enabling additional kernel modules.

No inclusion of pre-built binaries or libraries

All program binaries and program libraries included in Fedora packages must be built from the source code that is included in the source package. This is a requirement for the following reasons:

  • Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch.

  • Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization.

Content binaries (such as .pdf, .png, .ps files) are not required to be rebuilt from the source code.

If you are in doubt as to whether something is considered a program binary or a program library, here is some helpful criteria:

  • Is it executable? If so, it is probably a program binary.

  • Does it contain a .so, .so.#, or .so.#.#.# extension? If so, it is probably a program library.

  • If in doubt, ask your reviewer. If the reviewer is not sure, they should ask the Fedora Packaging Committee.

Packages which require non-open source components to build are also not permitted (e.g. proprietary compiler required).

When you encounter prebuilt binaries in a package you MUST:

  • Remove all pre-built program binaries and program libraries in %prep prior to the building of the package. Examples include, but are not limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc, *.pyo, *.egg, *.so, *.swf files.

  • Ask upstream to remove the binaries in their next release.

Exceptions

  • Some software (usually related to compilers or cross-compiler environments) cannot be built without the use of a previous toolchain or development environment (open source). If you have a package which meets this criteria, contact the Fedora Packaging Committee for approval. Please note that this exception, if granted, is limited to only the initial build of the package. You may bootstrap this build with a "bootstrap" pre-built binary, but after this is complete, you must immediately increment Release, drop the "bootstrap" pre-built binary, and build completely from source. Bootstrapped packages containing pre-built "bootstrap" binaries must not be pushed as release packages or updates under any circumstances. These packages should contain the necessary logic to be built once bootstrapping is completed and the prebuilt programs are no longer needed. Information about how you should break circular dependencies by bootstrapping can be found here.

  • An exception is made for binary firmware, as long as it meets the requirements documented here.

  • Some pre-packaged program binaries or program libraries may be under terms which do not permit redistribution, or be affected by legal scenarios such as patents. In such situations, simply deleting these files in %prep is not sufficient, the maintainer will need to make a modified source that does not contain these files. See: When Upstream uses Prohibited Code.

Pregenerated code

Often a package will contain code which was itself generated by other code. This often takes the form of configure files or parsing code generated by bison/yacc or lex/flex.

It is required that the original source files from which the code was generated be included in the source package. Generally these files are part of the source archive supplied by upstream, but it may be necessary to fetch those files from an upstream source repository and include them in the source package as separate Source: entries.

It is preferred, but not required, that the tools used to generate such code be free software and included in Fedora.

It is suggested, but not required, that such code be regenerated as part of the build process. The means for doing this are entirely specific to the individual package being built, but it may happen automatically if the necessary dependencies are present at build time.