GNU-Softwareevaluierung

Software zu GNU beitragen

Wenn man Software geschrieben hat und zum GNU-Projekt beitragen möchte, vielen Dank! Diese Seite enthält einen Fragebogen für die Einreichung des Pakets, so dass wir einerseits erforderliche Informationen erhalten und andererseits so schnell wie möglich eine Bewertung vornehmen können.

Bitte nehmen Sie sich für die Beantwortung des Fragebogens einen Augenblick Zeit. Der vorformatierte Text kann kopiert und auf Ihrem System ausgefüllt werden. Senden Sie den vollständig ausgefüllten Fragebogen bitte an <gnueval@gnu.org> (als Nur Text).

GNU ist nicht einfach nur eine Sammlung nützlicher Programme, sondern ein geschlossenes Betriebssystem, das 100 % freie Software ist. Um das GNU-System technisch schlüssig zu halten, stellen wir sicher, dass alles gut zusammenpasst. Die Begutachter bewerten Programme nicht nur danach wie gut sie sich sowohl technisch als auch philosophisch in das GNU-System einfügen, sondern auch nach Qualität, Benutzerfreundlichkeit und anderen Eigenschaften, die Nutzer erwarten würden. Auf Grundlage der Bewertung des Begutachters entscheidet Richard Stallman, der Chief GNUisance. letztendlich darüber, den Beitrag zum GNU-Projekt zu akzeptieren.

Eine Konsequenz daraus ist, dass wir gewöhnlich kein neues Paket akzeptieren, das substantiell mit einem vorhandenem GNU-Paket überlappt. Für GNU, als ein kohärentes System, ist es besser mit einem gegebenen Paket eine gegebene Aufgabe zu lösen und zu diesem Paket ‑ zusammenarbeitend ‑ beizutragen und zu verbessern, anstatt viele Pakete zu haben, die, jedes eigenständig entwickelt, jeweils andere Teile einer Aufgabe lösen. Ein kleines Programm passt als Teil eines vorhandenen Pakets gleichermaßen oft besser, als ein eigenständiges neues Paket (gegenwärtig hat GNU hauptsächlich aus historischen Gründen eine Reihe solcher überlappender Pakete ‑ das entbindet jedoch nicht vom Leitbild).

Weitere Konsequenz ist, dass die Eingliederung als Projektbetreuer (m/w) zum GNU-Projekt ein etwas formeller Vorgang ist, da man als Projektbetreuer ‑ innerhalb der Grenzen der Betreuung ‑ bereit sein muss, sich für die Mission des GNU-Projekts, für Softwarefreiheit, einzusetzen.

Weitere Informationen zu den GNU-Richtlinien unter Informationen für Paketbetreuer als auch Informationen zum Programmierstil. Bitte beachten Sie die Zusammenfassung der wichtigsten Richtlinien weiter unten, aber auch die entsprechenden vollständigen Dokumente.

Haben Sie bereits ein Freie-Software-Paket freigegeben, mögen aber nicht den Fragebogen ausfüllen bzw. den Anforderungen für offizielle GNU-Pakete entsprechen, empfehlen wir dennoch eine kurze Mitteilung an das Freie-Software-Verzeichnis zu übermitteln. Wir möchten weitestgehend alle freigegebenen Freie-Software-Pakete aufnehmen.

Nochmals vielen Dank für Ihr Interesse an GNU.

Was es für ein Programm bedeutet ein GNU-Paket zu sein

Dies ist eine Erklärung von Richard Stallman, was es für ein Programm bedeutet ein GNU-Paket zu sein, in der auch Allgemein auf die Aufgaben und Verantwortlichkeiten von GNU-Projektbetreuern eingegangen wird.

„Ein Programm zu GNU-Software zu machen bedeutet, dass deren Entwickler und das GNU-Projekt vereinbaren (und auch so im Programm angeben): ‚Dieses Programm ist Teil des GNU-Projekt, veröffentlicht unter der Schirmherrschaft von GNU.‘

Das GNU-Projekt ernennt Paketbetreuer ‑ anfangs den oder die Hauptentwickler oder die Personen, die ernannt werden wollen ‑ die sich für das Paket im Auftrag des GNU-Projekts verantwortlich zeichnen. Wir hoffen es wird nicht passieren, aber wenn sie zurücktreten, suchen wir einen oder mehrere Betreuer (m/w). Das Programm bleibt selbstverständlich ein GNU-Paket, solange bzw. bis sich das GNU-Projekt dafür entscheiden sollte es stillzulegen.

Normalerweise wird der Programmquellcode eines GNU-Pakets auf https://ftp.gnu.org/ bereitgestellt (sofern darauf ein Verweise angelegt und von jedermann erreicht werden kann, kann die Wahl der FTP-Präsenz stattdessen auch frei gewählt werden).

Das bedeutet auch, dass die offizielle Internetpräsenz des Programms unter www.GNU.org/software/<PAKETNAME> abrufbar sein sollte. Wann immer die Internetadresse für die Startseite des Pakets angegeben wird, würde man diese nennen. Es ist in Ordnung, wenn man eine weitere Präsenz für Sekundäres, wie der eigentlichen Softwareentwicklung und Datenbanknutzung, nutzt (bei einem wirklich dringenden Grund können wir eine Ausnahme machen und eine Weiterleitung an eine Internetpräsenz irgendwo anders anlegen).

Für die Entwickler bedeutet es damit einverstanden zu sein, darauf zu achten, dass das Programm gut mit dem Rest des GNU-Systems zusammenarbeitet ‑ und umgekehrt damit einverstanden sind, dass das GNU-Projekt andere GNU-Betreuer ermutigt darauf zu achten, dass auch deren Programme gut damit zusammenarbeiten.

Ein wichtiger GNU-Standard ist, dass Programme gut miteinander zusammenarbeiten. Dies hat vor allem einen praktischen Hintergrund, der von der Funktion des Programms abhängt. Aber es gibt auch einige allgemeine Grundsätze. Bestimmte Teile des GNU-Programmierstils beeinflussen direkt die Ko­hä­renz des Gesamtsystems. Dazu gehören die Standards für Konfiguration und Erstellung eines Programms und die Befehlszeilenoptionen. Diesem Standard zu folgen, ist, soweit anwendbar, für alle GNU-Programme von großer Wichtigkeit.

Ein weiterer wichtiger GNU-Standard ist, dass die Dokumentation von GNU-Programmen im Texinfo-Format erstellt wird. Das ist das Standarddokumentationsformat von GNU, und kann automatisch in verschiedene andere Formate konvertiert werden. DocBook oder ein anderes geeignetes Format kann als Dokumentquelle verwendet werden, solange die automatische Konvertierung in Texinfo gute Ergebnisse liefert.

Soll ein GNU-Programm erweiterungsfähig sein, wird GUILE, die offizielle Erweiterungssprache für das Betriebssystem GNU, als Programmiersprache zur Erweiterbarkeit empfohlen. Bei einigen Programmen gibt es Gründe die Entwicklung anders anzupacken, aber es wird gebeten GUILE einzusetzen, wenn technisch möglich.

Ein GNU-Programm sollte die aktuellste vom GNU-Projekt empfohlene Lizenz-Version verwenden ‑ nicht irgendeine freie Softwarelizenz. Für die meisten Pakete bedeutet dies gegenwärtig die Verwendung der GNU General Public License (GPL), Version 3 oder neuer.

Ein GNU-Programm sollte auch nicht den Gebrauch eines unfreien Programms empfehlen und Nutzer nicht auf irgendwelche unfreie Dokumentation verweisen. Die Kampagne Freie Dokumentation für Freie Software, Warum Freie Software freie Dokumentation braucht, ist ein wichtiger Schwerpunkt des GNU-Projekts. Um unsere Ernsthaftigkeit zu untermauern, dürfen wir unsere Position nicht durch Empfehlung unfreier Dokumentation untergraben.

Gelegentlich gibt es Probleme bei der Terminologie, welche für den Erfolg des GNU-Projekts insgesamt wichtig ist. Wir erwarten von GNU-Programmbetreuern, dass diese befolgt wird. Beispielsweise sollten Dokumentationsdateien und Kommentare im Programm von GNU/Linux-Systemen, nicht von „Linux“ als Betriebssystem als solches, und von Freie Software anstatt „Open Source“ sprechen! Da ein GNU-Programm unter der Schirmherrschaft von GNU freigegeben wird, sollte entsprechend nichts ausgesagt werden, was den Ansichten des GNU-Projekts widerspricht.

Ein Programm zu GNU-Software und unter die Schirmherrschaft des GNU-Projekts zu stellen, macht die Übertragung des Copyright an die Free Software Foundation (FSF) nicht erforderlich. Das hat damit nichts zu tun und ist eine Frage für sich. Sofern das Copyright an die FSF übertragen wird, wird in dem Fall, sollte jemand gegen die Bedingungen der GNU GPL zuwider handeln, die FSF die GNU GPL für das Programm durchsetzen. Wird das Copyright nicht an die FSF übertragen, liegt die Durchsetzung der Lizenz entsprechend bei dem Urheberrechtsinhaber selbst.

Als Projektbetreuer eines GNU-Pakets wird empfohlen sicherzustellen, in Kontakt mit dem GNU-Projekt zu bleiben. Sollten wir im Zusammenhang mit dem Paket auf ein Problem stoßen, müssen wir entsprechend darüber informieren und absprechen können, wie es gelöst werden kann. Um ein Problem zu lösen, das sich auf mehrere Pakete auswirkt, bitten wir manchmal um Zusammenarbeit mit anderen Projektbetreuern. Dies wird wahrscheinlich nie oder sehr selten geschehen, aber es sollte sichergestellt werden, dass man in jedem Fall von uns kontaktiert werden kann.”

Diese engere Auswahl an Tipps für GNU-Betreuer kann ein nützlicher Überblick über einige zu erledigende Dinge sein, nachdem Ihr Paket Teil von GNU wird.

Weitere Einzelheiten finden Sie in diesen Dokumenten:

• Informationen für Paketbetreuer
• Informationen zum Programmierstil

Um mehr über die Leitgedanken von GNU und Freie Software zu erfahren, lesen Sie bitte diese Aufsätze:

• Über das Projekt ‚GNU‘
• Freie Software. Was ist das?
• Kategorien freier und unfreier Software
• Ruinöse Kompromisse vermeiden
• Zu vermeidende Wörter
• Das GNU-System und Linux
• GNU/Linux: Häufig gestellte Fragen
• Warum „Open Source“ das Ziel Freie Software verfehlt

Fragebogen, um dem GNU-Projekt Software vorzustellen

* General Information
** Do you agree to follow GNU policies?
   If your program is accepted to be part of the GNU system, it means
   that you become a GNU maintainer, which in turn means that you will
   need to follow GNU policies in regards to that GNU program.
   (Summarized above, see maintainers document for full descriptions.)

** Package name and version:

** Author Full Name <Email>:

** URL to package home page (if any):

** URL to source tarball:
    Please make a release tarball for purposes of evaluation, whether
    or not you publicly release it.  If you don't have
    anywhere to upload it, send it as an attachment.

** Brief description of the package:


* Code
** Dependencies:
    Please list the package's dependencies (source language, libraries, etc.).

** Configuration, building, installation:
    It might or might not use Autoconf/Automake, but it must meet GNU
    standards.  Even packages that do not require compilation
    must follow these standards, so installers have a uniform way to
    define target directories, etc.  Please see:
    http://www.gnu.org/prep/standards/html_node/Configuration.html
    http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html

** Documentation:
    We require using Texinfo (http://www.gnu.org/software/texinfo/)
    for documentation, and recommend writing both reference and tutorial
    information in the same manual.  Please see
    http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html

** Internationalization:
    If your package has any user-visible strings, please make them
    translatable to other languages using GNU Gettext:
    http://www.gnu.org/software/gettext/

** Accessibility:
    Please discuss any accessibility issues
    with your package, such as use of relevant APIs.

** Security:
    Please discuss any possible security issues with your package:
    cryptographic algorithms being used, sensitive data being stored,
    possible elevation of privileges, etc.


* Licensing:
   Both the software itself *and all dependencies* (third-party
   libraries, etc.) must be free software in order to be included in
   GNU.  In general, official GNU software should be released under the
   GNU GPL version 3 or any later version, and GNU documentation should
   be released under the GNU FDL version 1.3 or any later version.

   Please see http://www.gnu.org/philosophy/license-list.html for a
   practical guide to which licenses are free (for GNU's purposes) and
   which are not.  Please give specific url's to any licenses involved
   that are not listed on that page.


* Similar free software projects:
   Please explain what motivated you to write your package, and search
   at least the Free Software Directory (http://www.gnu.org/directory/)
   for projects similar to yours.  If any exist, please also explain
   what the principal differences are.


* Any other information, comments, or questions:

Bitte nicht vergessen den Fragebogen an <gnueval@gnu.org> zu senden …

Weitere Möglichkeiten dem GNU-Projekt zu helfen

Es gibt viele weitere Möglichkeiten GNU zu unterstützen, sowohl in technischer als auch nicht-technischer Hinsicht.